WebViewCoreThread used by admob AdView is using high CPU even when parent Activity is paused [duplicate]

Answer 1

PZolee posted on this subject and a proposed solution in his blog: https://pzoleeblogen.wordpress.com/2014/07/08/android-how-to-solve-adview-cpu-consuming/

I investigated this further (in the comments to the blog post are documented my struggles) and came to the following conclusion:

1. Indeed, calling just adView.pause(); does not stop Google Ads component from consuming CPU even if the app is in background and ads are not visible.
2. Finding all the WebViews inside a our adView and calling onPause() and onResume() WevView methods on them does not solve the problem of the unnecessary CPU consumption.
3. Only the call to WebView pauseTimers() and resumeTimers() methods as the author of the above post proposes does stop the unnecessary CPU consumption.
4. Finding recursively all the WebViews and calling pauseTimers() and resumeTimers() on all of them is unnecessary, since one such call “Pauses (or resumes – g.) all layout, parsing, and JavaScript timers for all WebViews. (within a process – g.)” – see WebView component docs.
5. If you use a WebView anywhere else in your app – maybe in other activities, you must resumeTimers() for it, or it won’t work right. Also, be aware that a WevView may be constructed temporarily and used by some library functions you use in your project, without you explicitly knowing about it. It could be e.g. a prompt to login to some web site, social network etc. Such WebView may again not work right, if pauseTimers() was called in your process somewhere and you did not resume them. USE CAUTION AND TEST all you can.

It’s really a shame, that Google and AdMob handled us such a nasty surprise with their ad component (constant CPU consumption even if you background the app, hide their component, even pause() it with their own API call…

Answer 2

After calling destroy() on the admob AdView object, I now set the reference to null, which removes all references to the AdView, perhaps causing it to get garbage collected, and thus, avoiding any WebViewCoreThreads to be running indefinitely. Overall, I don't like this approach - such clean up work should be handled within the AdMob destroy. Or actually, I shouldn't even have to call destroy() - it slows down my activity onPause.

Big downside though: lots of my users are complaining slowness when pressing the back or home buttons in my app. Obviously, this is because of time being spent in the onPause() method while calling admob destroy(). The long-term solution is to use Fragments and ActionBar, and not have to create multiple copies of the Admob banner (one in every activity)

Answer 3

Not sure if anybody still needs this information, but I have been searching for a solution to this myself. Apparently AdMob is still flawed.

The only problem is, this will stop all WebViews from running in the background. Only a problem if your app depends on this to operate.

Add to onPause() :

new WebView(this).pauseTimers();

and to onResume() :

new WebView(this).resumeTimers();

This came from a Google Employee who claims that they are looking into it: https://groups.google.com/d/msg/google-admob-ads-sdk/Qu4G19NFAuI/wcNkoV0AeDUJ