Admob doing a lot of work (spending a lot of time) on UI thread

[Martin Rajniak]

Hi,

• Google Play services SDK version you're integrating with = 8.4.0
• Version of the Google Play services apk installed on your device = 8.7.03
• model and OS version of the device that exhibits the issue = Samsung Galaxy S4, Android version 5.0.1

Our issue is that while we are loading ads from admob we see laggy animations (sometimes even 3s before rendering next frame). After a lot of profiling with systrace and method profiling we have narrowed down our scope to admob (mainly chromium calls - org.chromium). 

We have even tried to switch our ad provider to facebook and we can see no problem with their implementation (we even verified with systrace).

We would appreciate if you could tell us more about how you ensure that you do not spend too much time on UI thread and also if we can somehow help you not to spend too much time on UI thread.

Best,
Martin

[Tomáš Procházka]

I have the same problem, it is huge problem especially if you are doing a lot of nice animations in the app and admob loading it completely broke it.

It looks that only way is change the ads provider to facebook as you mentioned.

I personally don't understand why native ads need to initialize Chromium WebView? To load ads? HttpURLConnection should be enough.

Here is method tracking

 

Dne pátek 8. dubna 2016 18:02:27 UTC+2 Martin Rajniak napsal(a):

[Martin Rajniak]

Just to clarify we are only using Native ads, so maybe we can come up with a solution that doesn't need chromium web toolkit or web view at all.

[Vu Chau (Mobile Ads SDK Team)]

Hello all,

Just so we are on the same page, are you seeing the laggy animations (and hence the busy work you see via Systrace) using our sample apps and/or on other devices as well?

The SDK itself should not be doing anything (requesting ad, parsing the ad XML, and rendering it, et al.) on the UI thread.  However, if the creative itself has animations and is resource-intensive (and WebView objects by nature are also expensive), then you might expect to see that reflected (via the webview, not the SDK per se).  You can tell if a call originates from the SDK if it looks something like com.google.android.gms.ads.internal.*.  Calls from Chromium are webview-based as part of the rendering process, and not SDK in origin.

Going forward, my recommendations would be to watch out for animated native ads and the like, since animations in webview is generally UI-intensive.  Make sure you are offloading any other heavy work in your app to separate threads if you aren't already doing so.  Rest assured: we have existing work in order to ensure optimal performance, and I will also personally relay your instances to the team.

Vu Chau

Mobile Ads SDK Team

[Tomáš Procházka]

I don't check your if your samples app do some complicated animation during the add loading, but problem is definitely in the admob SDK.

The problematic call comes from com.google.android.gms.ads.internal.*, then is called something like maps.be.g$d.a and then android.webkit.WebSettings.getDefaultUserAgent() which call com.andorid.webview.chromium.WebViewChromiumFactoryProvider which quite expensive and a lot of thing are executed on UI thread during the initialisation of Chromium.

On the attached screenshot you can see the method tracking on UI thread (main thread) from Android Studio. At the begining the are short call of normal animation frames rendering and from 1/3 the AdMob code was started on UI thread. (btw I'm calling adLoader.loadAd on background thread). So your SDK itself switch to UI thread from some reason.

I'm using this code:

AdLoader adLoader = new AdLoader.Builder(ProjectApp.getInstance(), "...")
    .forAppInstallAd(new NativeAppInstallAd.OnAppInstallAdLoadedListener() {
        @Override
        public void onAppInstallAdLoaded(NativeAppInstallAd nativeAppInstallAd) {
            // Show the app install ad.
            Log.d("Load AdMob InstallAd successful: " + nativeAppInstallAd.getHeadline());
        }
    })
    .withAdListener(new AdListener() {
        @Override
        public void onAdFailedToLoad(int errorCode) {
        }
    })
    .withNativeAdOptions(new NativeAdOptions.Builder()
        // Methods in the NativeAdOptions.Builder class can be
        // used here to specify individual options settings.
        .setImageOrientation(NativeAdOptions.ORIENTATION_LANDSCAPE)
        .setReturnUrlsForImageAssets(true)
        .setRequestMultipleImages(false)
        .build())
    .build();

adLoader.loadAd(new AdRequest.Builder().build());

[Vu Chau (Mobile Ads SDK Team)]

Hi Tomáš,

(btw I'm calling adLoader.loadAd on background thread). So your SDK itself switch to UI thread from some reason.

The SDK "switches" to the UI thread to update the UI objects on the UI thread after all the work is done, even if you are doing the ad-related work on a background thread.  And as the UI drawing takes place, since the SDK is using a WebView for ads rendering, we expect that there are calls from the WebView and Chromium at this stage.  That's also where you see calls from OpenGL ES, which takes care of the redrawing of your objects by simply letting them sit in the GPU, so they can be referenced for subsequent redraws.  That helps saving resources since you/the SDK won't have to upload the content to the GPU every time.

In fact, looking at my traces, I'm not seeing a whole lot happening on the UI thread.  All work is updated within the 16-millisecond intervals between any two frames, which allows the UI thread to breeze through all the drawing (I'm seeing only 1 frame dropped in a total of ~50 frames).

As said, we are always improving performance.  I will let the team know of your experience and we'll see what we can change.

Thanks!

Vu Chau

[Tomáš Procházka]

No, we are using Native Ads, check my code, there is no UI works, it should last download the Ads and return POJO object with ads information.

Then you must manually setup the View based on this data.

But don't do this in my example that I send in my previous post.

So there should be no UI work at all, it is just downloading ads, no WebView should be there.

Everything you wrote is related to normal banner view, not Native Ads.

Check attached images, there you can easily see which methods are called on the UI thread.

I can send you whole .trace file.

I already found, that possible workaround is call this in the Application class WebSettings.getDefaultUserAgent(this);

User will stay a little bit longer on splash screen, but when Admob SDK call this from unknown reason before ads loading it will be already initialized and it save a lot of time.

Dne pondělí 11. dubna 2016 17:44:18 UTC+2 Vu Chau (Mobile Ads SDK Team) napsal(a):

[1345...@gmail.com]

I was found that the AdLoader.loadAd() are very slow and blocking the main thread.

It took up to 1s per call.  It called System API Uri.getQueryParameter(key) a lot of times  waste many time.

Could you tell me how to  avoid it.

[mobileadssdk...@google.com]

Hi,

The Android SDK team is currently implementing changes across the SDK to reduce the amount of time spent on the main thread. You should see these changes roll out over the upcoming releases.

- Ram

=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~
Also find us on our blog and Google+ page:
    http://googleadsdeveloper.blogspot.com
    https://plus.google.com/115658573333388777174/
=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~

--

---
You received this message because you are subscribed to the Google Groups "Google Mobile Ads SDK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-admob-ads-sdk+unsub...@googlegroups.com.
To post to this group, send email to google-admob-ads-sdk@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-admob-ads-sdk/b7d7b8b5-29b2-4d34-8b05-4865593c4b91%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[konyol...@gmail.com]

[khairul annas]

Hi all,

Sorry to resurrect dead thread, i face same problem on blocking in main thread. Is there any other option to load ad using simple http call? or to unload the process from main thread?

I'm using sdk version '18.3.0' 

[khairul annas]

[Mobile Ads SDK Forum Advisor Prod]

Hi there,

I'm afraid this is a currently working as intended behavior of the SDK. Our team is implementing changes across the SDK to improve its performance from time to time. Please follow our blog regarding this.

Regards,
Teejay Pimentel
Mobile Ads SDK Team

ref:_00D1U1174p._5001USw3Hw:ref

[khairul annas]

Thanks for the reply, if that the case, is there any workaround or best practice to implement native ads (we implement multiple ad unit in home page that have lot of process on main thread) on our app?

Regards,

[Mobile Ads SDK Forum Advisor Prod]

Hi there,

One of the practices is to request them in advance of when they'll actually be displayed. Since you mentioned that you implemented multiple ad unit in your home page, then I would suggest to reduce the number of request ads to avoid the issue.