According to the article (yes, I RTFA), here's the criteria:
-Each WebView has a budget (in seconds) for running timers in background.
- A timer task is only allowed to run when the budget is non-negative.
- After a timer has executed, its run time is subtracted from the budget.
- The budget regenerates with time (at rate of 0.01 seconds per second).
This suggests a few ways around this.
- Play a 0.1 second silent audio sample on page load, throwing the page into "non-throttle mode".
- If "playing audio" itself only keeps the page's budget from decaying for a short time, play a 0.1 second silent audio sample before every timer call.
- Change your timer code to record its own runtime and set the next refresh to (runtime(ms) * 10). Ie. if your tracker call took 310ms to execute, set the refresh to 3100ms, or 31 seconds. If nothing else this would force ad trackers to write some efficient code for once.
- "HEY WEB SURFER WE'D JUST LIKE TO TAKE THIS OPPORTUNITY TO PLAY YOU OUR AMAZING JINGLE AND YOU WON'T BELIEVE WHAT HAPPENS NEXT!"
I'm not exactly sure how to mitigate that. Silent audio detection? (solved by playing a 40khz tone that you won't hear but will drive your pets bonkers) Option to turn it off? (disables your music streaming app after a while) That option with whitelists? (manual intervention == annoying your customers)