Related to this issue: AdMob banners causes high idle CPU usage due to WebView leak.
When
there are any alive WebViews in a process, it will use a ton of CPU
trying to synchronize with vsyncs, even while the display is off.
To reproduce:
- Clone https://github.com/chkwok/googleads-mobile-android-examples -
this updates play-services-ads to 17.0.0 to make sure bug isn't fixed
already and adds some Log.i to onResume/Pause/Destroy of the activity.
You can use the upstream version as well, that also has the bug, but no
Log messages though.
- Launch the BannerExample app
- Press back. Verify in LogCat that BannerExample is .onDestroy-ed.
- adb shell top
- com.google.android.gms.example.bannerexample
will be at the top of the CPU usage at 15-20% of a core. Forever. Until
the VM is killed by the Android.
- This causes "<App name> is draining your battery" notifications to show if
your process is long living. Which is true. If you ever showed an Admob
banner, even if the activity is long gone, your process will burn 0.2
cores of CPU to warm your hands, just in time for winter.
Screenshots attached:
- Profiler output of a frame. It repeats this at 60 hz.
- Screenshot of adb shell top.
This
is a huge issue, leaking a WebView is a major error that we developers
cannot fix for you. So far, I tried removeView on the adView, pause,
stop and destroy, but somewhere deep inside the ads SDK, there are still
living WebView objects that haven't been destroy()-ed.
Please
escalate this issue, I have to decide between killing users' batteries
and zero AdMob revenue. This is a huge deal as it affects every single
developer using AdMob and indirectly, basically every single Android
user.
Note
that to really fix this issue, all instantiated WebViews must be
destroyed manually, or automatically when the attached Activity dies. A
single line with "new WebView(this)" that doesn't do anything with the return
value will permanently break the application until VM restart. All unattached WebView instances must be destroyed manually when all ads are stopped.
I posted this as a reply as Banner leaks WebView leaks Activity, and the guys above me already pinpointed the leak path. Let me know if this should be on a separate thread.
Kind regards,
Chi Ho Kwok