Hey guys -
I've encountered a bit of a strange WebView interaction that I can't seem
to find reported anywhere either in this group or other help forums. I
have a basic WebView loaded within an Android app that contains a call to
setTimeout. This code looks something like:
setTimeout(function() {}, 120000);
I've found that if the screen dims, goes into sleep mode while this timer
is executing, and is turned back on / unlocked after a minute or two, the
WebView will fail to render any changes to the page until a period of time
has elapsed (up to the delay specified in the timer -- 120 seconds).
During this "frozen" state, the JS can still receive DOM events and make
calls to a native JS-Java bridge. However, it cannot make any changes to
the actual UI that will require re-rendering -- any attempt to do so will
appear to call through without exception but no change will be made on the
screen.
As you reduce the delay for the setTimeout call, the average amount of time
that the UI freezes reduces as well. You can reproduce this like so:
1. Create a WebView that loads a page containing: JS that makes a call
to setTimeout (give it a 2m delay just to highlight the issue) and some
sort of page interaction (like a button) that causes a UI change when
activated
2. Set your phone's dim / sleep mode configuration to 15s
3. Wait a few minutes (say 3) after your phone has gone into sleep mode
4. Turn on and unlock the phone
5. Attempt to activate the page interaction in your WebView that will
attempt to change some aspect of the UI
You should notice that it'll take up to 2m for the UI to render your change.
For now, I'm working around this by never passing in anything greater than
1000ms to setTimeout within a WebView -- by doing this, the maximum freeze
time a user could experience is only 1s instead of 2m.
My test setup:
- HTC Desire HD
- Android 2.2.1
- Kernel 2.6.32.21-gb291666
- Build 1.84.661.1 CL325797 release-keys
- WebKit 3.1
So -- anyone have any thoughts on whether this is some strange Android bug,
misconfiguration, or expected behavior? As I said, I can certainly work
around it for now but I'd love to understand the underlying cause of this
issue. Without understanding the internal Android implementation, one
might think that the UI thread is locked waiting for the timer to complete.
Thanks!
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
