Android AdMob takes 4-5 to create AdView

[William Ferguson]

The first time my app ever creates an AdView it takes 4-5 seconds to
do so (on a Samsung GalaxyS) which causes the UI be be unresponsive
and blackout during the Activity construction.

This can be confirmed by clearing all data for your app and
restarting.
Watch how it takes to construct the AdView that first time.

So I tried creating the AdView programatically and putting it in an
async block.
But it seems like it *has* to be created from the UI Thread.

04-24 10:36:02.051: ERROR/ACRA(4721): Jumblee fatal error : Can't
create handler inside thread that has not called Looper.prepare()
java.lang.RuntimeException: Can't create handler inside thread
that has not called Looper.prepare()
at android.os.Handler.<init>(Handler.java:121)
at d.<init>(Unknown Source)
at com.google.ads.AdView.a(Unknown Source)
at com.google.ads.AdView.<init>(Unknown Source)
at
au.com.xandar.jumblee.game.GameScreenActivity.createAdView(GameScreenActivity.java:
508)
at au.com.xandar.jumblee.game.GameScreenActivity.access
$2200(GameScreenActivity.java:58)
at au.com.xandar.jumblee.game.GameScreenActivity
$10.run(GameScreenActivity.java:339)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:
1068)
at java.util.concurrent.ThreadPoolExecutor
$Worker.run(ThreadPoolExecutor.java:561)
at java.lang.Thread.run(Thread.java:1096)


So instead of pissing off my users (especially the initial impression
when the app is first run), how can I get the AdView created without
burning 4-5 seconds of the UI Thread. Is there a way to asynchronously
perform whatever caching is being done the first time an AdView is
constructed?

NB this is version 4.0.4 of the AdMob library.

William

[William Ferguson]

Actually, it's worse than I first thought.
Average time over the last 15 runs was just over 7 seconds to
construct the AdView instance.
And it need to be performed on the UI Thread which it blocks.

NB this is just for the first time the App is run as it seems to cache
whatever it is doing on that first run.
But I really don't want an unresponsive 7 second interlude the first
time users run my app.
Surely whatever prep work is being carried out can be done
asynchronously, perhaps when the first add is requested.


I've spent the morning trying various ways of getting around this
without much success. I've tried:
- Constructing the AdView in another Thread - fails because it creates
a Handler that assumes the current Thread is the UI Thread.
- Configuring another Thread with a Looper and using it to construct
AdView (NB AdView needs to added to the layout using the UI Thread) -
fails because when an Ad is retrieved this new Thread attempts to
modify the View hierarchy and "Only the original thread that created a
view hierarchy can touch its views."
And several other variants


This unresponsive behaviour on View creation flies in the face of the
Android UI guidelines wrt and seems like a pretty serious bug.
Where's the bug tracker to which I can submit it?


And if anyone has any ideas, please let me know



On Apr 24, 10:44 am, William Ferguson <william.ferguson...@gmail.com>
wrote:

[William Ferguson]

This might be as simple to resolve as changing the constructor of
class 'd' that instantiates Handler to use
new Handler(Looper.getMainLooper())
instead of
new Handler()

That looks like it would allow 'new AdView()' to be called from a
Thread other than the UI Thread and have everything wired up
correctly.
But without access to the AdMob source its impossible to tell if that
is sufficient.


On Apr 24, 1:51 pm, William Ferguson <william.ferguson...@gmail.com>
wrote:

[William Ferguson]

Well I've switched back to the AdMob library for 20101012.
While there is a 7 second lag on start up, I can't use the 4.0.4
version.

I have to say, a bug like that is woeful.
Lift your game guys.


On Apr 24, 2:40 pm, William Ferguson <william.ferguson...@gmail.com>

[Tim]

Hi William,

We have not noticed any lag on start up and have been unable to
reproduce what you are describing. Do you have similar issues on the
emulator? Do you experience this lag using just the Android
Fundamentals example?

Thanks,
-Tim



On Apr 26, 4:37 pm, William Ferguson <william.ferguson...@gmail.com>

[William Ferguson]

Tim, on a 2.2 emulator I only see a 400-600 millisecond lag the first
time the app is started after being freshly installed or having its
data cleared.
Which is about the same lag that I get with the AdMob library from
20101012 on my phone (Samsung GalaxyS running 2.2).

If I saw a similar lag running 4.0.4 on my phone I'd be happy.
But plugging that exact same APK into my phone and the time to create
the AdView was 7.5 seconds.
Like I said that doesn't occur with the earlier AdMob library.

I know the GalaxyS has a very slow write to disk. I have had to be
very careful when implementing my app to ensure that all disk bound
operations are handled in a non-ui thread.
Since the GalaxyS is such a popular phone (and I happen to have one
myself) I can't really ignore the problem.
Any chance you can test it on a GalaxyS?

Point me to the Android Fundamentals example (I couldn't find what you
meant) unless its http://code.google.com/mobile/ads/docs/android/fundamentals.html
which is exactly what I have used for my code. I just have log message
pre/post to capture how long it takes.
AdView adView = new AdView(this, AdSize.BANNER, MY_AD_UNIT_ID);


William

[Tim]

William,

I have tested our SDK on the Samsung Nexus S and the Samsung Fascinate
(part of the Galaxy S line), both of which have similar hardware to
the Samsung Galaxy S. After installing an app, there is considerable
time spent in the WebView constructor (I saw anywhere from 0.5-2
seconds). I believe this is because it has to do a bunch of one-time
setup things like create a cookie space for the app and things like
that. This only occurs on the first launch after installing an app, or
after clearing the app data, as you mentioned. Every time after that,
even if the app is killed and restarted, it takes somewhere around
30-50 milliseconds.

Unfortunately, there's not much we can do. The WebView must be created
on the UI thread, and the first WebView created in an app can take a
while.

The only workaround I can think of is to create a WebView early on in
your app before creating the AdView (e.g. in a loading screen or main
menu screen before the main part of the app). This should get the one-
time setup stuff out of the way. Again, you should only experience
this lag the first time you run the app after installing or clearing
the data, so it shouldn't affect most users more than once. This is
definitely a pretty hack-ish solution though. I'm sorry there's not
much else we can do.

Also, fyi, the fundamentals example is located here:
http://dl.google.com/googleadmobadssdk/examples/android-banner-essentials.zip.
There is a link to it on this page: http://code.google.com/mobile/ads/docs/android/fundamentals.html.

Thanks,
-Tim



On Apr 26, 6:47 pm, William Ferguson <william.ferguson...@gmail.com>
wrote:

> Tim, on a 2.2 emulator I only see a 400-600 millisecond lag the first
> time the app is started after being freshly installed or having its
> data cleared.
> Which is about the same lag that I get with the AdMob library from
> 20101012 on my phone (Samsung GalaxyS running 2.2).
>
> If I saw a similar lag running 4.0.4 on my phone I'd be happy.
> But plugging that exact same APK into my phone and the time to create
> the AdView was 7.5 seconds.
> Like I said that doesn't occur with the earlier AdMob library.
>
> I know the GalaxyS has a very slow write to disk. I have had to be
> very careful when implementing my app to ensure that all disk bound
> operations are handled in a non-ui thread.
> Since the GalaxyS is such a popular phone (and I happen to have one
> myself) I can't really ignore the problem.
> Any chance you can test it on a GalaxyS?
>
> Point me to the Android Fundamentals example (I couldn't find what you

> meant) unless itshttp://code.google.com/mobile/ads/docs/android/fundamentals.html

[Kumar Mettu]

Tim,

  We recently moved some of the apps from old Admob API to new Google API.

  I am definitely seeing additional lag in Google API based ads compared to Admob API based Ads (Verified for multiple apps on multiple devices). I would think there is definitely scope for optimization.

Thanks In Advance for any help you and Admob team can provide.

Kumar.

[William Ferguson]

Tim,

so you believe that creating any WebView will perform the necessary
initialization?
If that's the case, then I can definitely try that. But I've never
seen anything like the 7 second lag (which is what I experience on the
GalaxyS) when I construct WebViews myself.

As long as I can control the time at which the one of lag occurs so I
can hide it in the SplashScreen, and the lag is not absolutely
terrible I can live with that.

Anyway, when I get a chance to trial it, I'll post my results.

William

On Apr 29, 8:17 am, Tim <timzwie...@google.com> wrote:
> William,
>
> I have tested our SDK on the Samsung Nexus S and the Samsung Fascinate
> (part of the Galaxy S line), both of which have similar hardware to
> the Samsung Galaxy S. After installing an app, there is considerable
> time spent in the WebView constructor (I saw anywhere from 0.5-2
> seconds). I believe this is because it has to do a bunch of one-time
> setup things like create a cookie space for the app and things like
> that. This only occurs on the first launch after installing an app, or
> after clearing the app data, as you mentioned. Every time after that,
> even if the app is killed and restarted, it takes somewhere around
> 30-50 milliseconds.
>
> Unfortunately, there's not much we can do. The WebView must be created
> on the UI thread, and the first WebView created in an app can take a
> while.
>
> The only workaround I can think of is to create a WebView early on in
> your app before creating the AdView (e.g. in a loading screen or main
> menu screen before the main part of the app). This should get the one-
> time setup stuff out of the way. Again, you should only experience
> this lag the first time you run the app after installing or clearing
> the data, so it shouldn't affect most users more than once. This is
> definitely a pretty hack-ish solution though. I'm sorry there's not
> much else we can do.
>

> Also, fyi, the fundamentals example is located here:http://dl.google.com/googleadmobadssdk/examples/android-banner-essent....

[William Ferguson]

Tim, thanks for the work around.
I can confirm that creating a WebView prior to creating the AdView
pushes the entire 7 second lag to the WebView construction. Ie

if (AppConstants.DEV_LOGGING) Log.v(AppConstants.TAG,
"SplashScreenActivity#initialise (ads) webView cache - start");
final WebView webCache = new WebView(SplashScreenActivity.this);
if (AppConstants.DEV_LOGGING) Log.v(AppConstants.TAG,
"SplashScreenActivity#initialise (ads) webView cache - finish);

Takes 7 seconds the first time the app is run and next to nothing each
subsequent time.
And that doing so means creating the AdView is very quick.
So I can now (almost) hide the initial unresponsiveness in my splash
screen.


I know the WebView is core Android and not something you have control
over.
But the 20101012 AdMob SDK obviously didn't require a WebView and it
was still able to serve ads.
So is there really any need for a WebView now?


William



On May 1, 9:34 am, William Ferguson <william.ferguson...@gmail.com>