Jump to content
Search Community

Draggable in Android webview - battery issue

ylowfat test
Moderator Tag

Warning: Please note

This thread was started before GSAP 3 was released. Some information, especially the syntax, may be out of date for GSAP 3. Please see the GSAP 3 migration guide and release notes for more information about how to update the code to GSAP 3's syntax. 

Recommended Posts

Hello,

 

I m using draggable (rotation) inside a WebView in an Android project. It is a 4.3 Android application with WebChromeClient (Chrome v30).

Everything works great and the animation is really smooth but the application suffers a battery drain whenever Draggable is present. I enabled 'Show GPU view updates' from android developer options and observed that the view updates constantly even when I m not rotating the element and even when draggable is disabled. 

 

This behaviour does not occur when I load the page in Chrome for Android (v.34)

I am testing in a Nexus 7 (2013) tablet.

 

Any ideas about what's wrong?Is this a known issue or am I doing something wrong?

 

Thank you 

Link to comment
Share on other sites

Hello ylowfat, and welcome to the GreenSock Forums!

 

Just so we undertsand.. 

  • Does this behavior happen on an actual Android device?
  • Or does this happen only in Android WebView with WebChromeClient?

if you can provide a link for us to test on our Android devices we can see if we see a lag or if the device gets super warm/hot which would show a battery drain ??

Link to comment
Share on other sites

Hello jonathan,

 

Thank you for your reply. This is the part of code that reproduces the problem: 

See the Pen nACuv by ylowfat (@ylowfat) on CodePen

 

This behavior happens on an android device. Nexus 7 2013 model.

It does not happen when i load the page from the Android browser (Chrome v34)

 

It happens when I load the page in a webview inside my android application like this:

webView.getSettings().setJavaScriptEnabled(true);
webView.getSettings().setDomStorageEnabled(true);
webView.setWebChromeClient(new WebChromeClient());    	       
webView.loadUrl("path//to/my/index.html");

Android version: 4.4.2

Link to comment
Share on other sites

Have you tried to remove KineticJS from the equation?

 

Are you saying that you only see the degradation when Draggable is loaded, and everything else is exactly identical? 

 

Also, what happens if you remove Draggable, but you apply some sort of 3D transform to the element(s)? I wonder if it simply has to do with the fact that Draggable applies a 3D transform to help boost performance, and perhaps that particular browser says "oh, if there's any 3D stuff in the browser, I'll tell the GPU to constantly update". I've never heard of that before - just wondering. 

Link to comment
Share on other sites

It seems like an issue when in WebView on the Android device, and not when viewed in an actual browser on the Android device...

 

I went to the DOCs page for Android WebView with WebChromeClient ..

 

http://developer.android.com/reference/android/webkit/WebView.html

 

Under Basic Usage it read this:

By default, a WebView provides no browser-like widgets, does not enable JavaScript and web page errors are ignored. If your goal is only to display some HTML as a part of your UI, this is probably fine; the user won't need to interact with the web page beyond reading it, and the web page won't need to interact with the user. If you actually want a full-blown web browser, then you probably want to invoke the Browser application with a URL Intent rather than show it with a WebView.

 

Could it be something going on in the WebView, but is not something that affects when viewed in a browser. Since it does not enable JavaScript and web page errors are ignored, in WebView. Have you tried invoking the Browser application with a URL intent rather then showing it in WebView?

 

I'm no Google WebView expert, but maybe the battery drain is due to something happeing when viewed in WebView, rather than invoking the Browser application with a URL intent ??

 

Again I'm not sure, just my 2 cents :)

Link to comment
Share on other sites

Hello guys and thanks for the support!

 

@jonathan: The stock browser does not come with Nexus 7. It has been replaced with Chrome for Android.

 

@jack: I have removed the kinetic part with no difference. In some other parts of the app where Draggable is not present 3d transformations (translate3d) take place but the issue is not reproduced.

 

Since android 4.4 the Webview engine is chrome v.30. Javascript is not enabled by default but you can enable it from the webview settings.

The performance of the draggable does not degrade at all. The animation is extremely smooth but the tablet get quite warm even if draggable element stays idle. Battery loses more or less 1%- 2% per minute while charging from USB with no other app running!

 

I think the key here is the constant gpu update. Is Draggable compatible with chrome v30?

 

The most strange thing is that using a Webview is really common place for mobile apps. I am guessing a lot of other developers are using Draggable in their apps so the problem would have been mentioned before...

 

I will try to test directly in Chrome for Android v.30 and report here the results..

 

Thanks again!

Link to comment
Share on other sites

A few more questions:

  1. Are you using the latest version of Draggable and all the GSAP files? 
  2. Have you tried adding touchstart, touchmove, and touchend listeners to things (WITHOUT loading Draggable)? I'm trying to figure out what could possibly cause battery drain like that and it's not like Draggable is constantly doing stuff. It adds a "tick" listener when you press on the element, and then removes it when you release, so that's not it. So I thought perhaps it's the fact that the browser has to listen for touch interactions and maybe the browser isn't optimized for that...I dunno. Grasping here.
  3. Does it matter what TYPE of Draggable you're using (x,y | rotation | scroll | top,left)? Is it simply loading the JS file that does it? 
  4. Do you have access to any dev tools that can report exactly what functions are getting called or what code is causing the CPU/GPU drain? 

Nobody else has reported anything like this. I'm pretty curious to hear your findings. 

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...