I'm trying to run the ionic-angular-cordova-seed project on Android 4.3.1 with Cordova. One thing I've noticed is that page transitions (for example, clicking on a tab or a list item) are very slow.
I tried to disable hardware acceleration using:
super.appView.setLayerType(WebView.LAYER_TYPE_SOFTWARE, null);
... and it worked perfectly. But then scrolling, side menu sliding and more animations became extremely slow.
I've tried FastClick, it didn't make any difference.
I found this CSS-based solution to the problem, but I'm not familiar enough with Ionic to apply it on it. Any ideas?
Note: I'm not using any animations for page transitions.
It seems like Ionic has made a lot of Android-related fixes that really improved performance. In addition, I've splitted my Android version into two versions: 4.4 and pre-4.4. Pre 4.4 is using cordova-android-chromeview which makes it so much faster. Even though it adds ~20 MB to the apk, it worths it.
Since this bug seems to be very specific to Android 4.4.2
I believe this may be what we're looking for, or at least helpful:
http://playlablondon.tumblr.com/post/102534909709/improving-performance-on-cordova-powered-android
Related
CSS' mix-blend-mode seems to fail on Android 9:
Chrome
Webview in Cordova (also Chrome in that case, probably)
It works on:
Chrome on Android 8
Firefox on Android 9
I initially experienced the issue with an SVG element, but I am also able to reproduce it with some simple divs.
A very simple code example:
https://codepen.io/walmink/pen/YoJRqa
I tried to run the example below and get the expected result on a Nexus 5 running Android 8 (left), but it fails on a OnePlus 6 phone running Android 9 (right) (see image). I've had other users (of a game of mine that uses mix-blend-mode) report the same issue on a OnePlus 7 and a Google Pixel 3a XL running Android 9.
It also seems to work fine on any desktop browser I've tried. On Safari, it will blend with the background as well unless you add isolation: isolate, but at least the blending still happens.
Thank you for tracking down that Chrome issue! I've been debugging this all day but missed that one. I'm on a OnePlus 6t. Someone else wasn't able to reproduce on a Pixel 2, but glad to hear it is in fact happening on other devices.
I have a workaround, which I'll also address in that Chromium thread, soon.
Option 1: Force hardware acceleration on the blended element, using something like transform: translate3d(0,0,0);
Option 2: On the blended element, add a will-change property, set to pretty much anything. will-change: opacity; for example, would suffice. This forced re-paint seems to be enough to kick the blend-mode back into gear.
Now, this fixes the problem... but causes another. If you have to do any scrolling more than about one more page length, the blended element will eventually get cut off, and will remain invisible for the rest of the page.
This behavior (or similar) is described here:
https://bugs.chromium.org/p/chromium/issues/detail?id=798148
This one sounds almost identical, but but is marked as fixed.
https://bugs.chromium.org/p/chromium/issues/detail?id=992398 This one also sounds similar, but they've identified as being related to the max size of a layer, which is fairly large (some 8000px). Whereas the behavior you'll find with this workaround, is more like 2000px, or roughly 200% of the height of the viewport (hard to test).
Unfortunately this cut off content behavior is very consistent... That Pixel 2 user I mentioned before, that couldn't reproduce the initial blend-mode issue, was seeing this cut off once the workarounds were applied.
You said you're making a game though, so hopefully there's not much scrolling involved?
Also, for what it's worth, you may find the screen blend mode is exempt from all this and may still work without any workarounds.
You can test with this https://codepen.io/chasebank/pen/wvwWGxd The workarounds are commented out in the .box element.
Good luck!
This bug only occurs on my Nexus 5 and my Nexus 7 running Lollipop.
EDIT
This bug also occurs in the new Inbox app by Google, when I'm going into Inbox > Settings > Notifications > any item and go back...
/EDIT
compileSdkVersion 21
buildToolsVersion 21.1.1
compile 'com.android.support:appcompat-v7:21.0.2'
I'm having a GalleryActivity that shows multiple images, once per page (inside a ViewPager. When I hit the back button, sometimes the Android's SystemUI have glitches.
Normal view
Glitched view
See how the views repeats themselves, and inside the system itself?
A simple touch event brings back the normal SystemUI views.
What is going on?
Might be similar to:
Android 5 screen glitch/static with Google Maps Fragment inside a Viewpager
Android Lollipop Activity Screen corrupted
Setting android:hardwareAccelerated="false" is a kind of extreme solution, as graphical performance is likely to be very bad.
If you can pinpoint the view that is misbehaving and causing this issue, a better fix would be to switch it to software rendering instead, via setLayerType(), e.g.
view.setLayerType(View.LAYER_TYPE_SOFTWARE, null);
Funny thing is, I haven't experienced any rendering glitches with Lollipop so far, but we did see them in KITKAT (as mentioned in this question), and only when WebViews are present on the screen.
I would recommend experimenting with toggling this on different views until the problem is isolated (especially if it's easy to reproduce).
So far, every occurence of this issue has been related to WebViews (or components that use WebView, such as AdMob). According to the AOSP Issue Tracker the problem is fixed in Android 5.0, but it doesn't seem to be the case.
I've seen UI glitches with Lollipop, though different than yours. The only workaround I found was disabling hardware acceleration:
android:hardwareAccelerated="false"
at the Activity or Application level. If this resolves your glitches, make sure to report this to Google as this would indicate a bug in the platform. There is already at least one open report with them already.
I certainly wouldn't want to deploy an application with this setting, it's really only intended to answer the WHY and help prove that it's not a bug in your code.
Hope this helps!
EDIT 12/10/2014:
#matiash offered a much more precise answer than this "sledgehammer" suggestion. I was seeing drawing glitches mostly on the ActionBar in a multi-tab app with ViewPager, and always on tabs/pages without any WebView at all. However, one of my tabs/fragments does have an embedded WebView, and when setting it to software rendering, my glitches appear to have gone away. I'm not at all uncomfortable putting the workaround suggested by #matiash in a shipping app...though it still points to some underlying issue in the platform.
I have also witnessed this problem in my own app.
Any Android devs ever experience this kind of visual static? (see picture)
Not only did I get that kind of visual static, but also repeated drawing. Only witnessed it on Nexus 5 with 5.0 when developing with api 21 and support library 21.0.+.
For me its not very reproducible. It will happen repeatedly during one session of use, but the next day I won't be able to reproduce it.
I am not using any WebViews (accept maybe via admob). I am using ViewPagers with fragments. I am also using DragSortList and first started seeing the issue in Activities that used it.
https://github.com/bauerca/drag-sort-listview
How reproducible is it for you guys?
have you tried to set android:fitsSystemWindows="true" in your Fragment layout? this will make sure the layout is below the statusBar, im not really sure about the navigation buttons but i guess this should work for it too.
Call request layout on DecorView after rendering:
getActivity().getWindow().getDecorView().requestLayout();
I call it using postDelay() in WebViewClient.onPageFinished(). It's not a perfect solution (just a workaround) but maybe better way like LAYER_TYPE_SOFTWARE.
.........go to settings and then developer options(if they are not visible... go to about phone then click on build number 7-10 times and developer mode will be on) and there scroll down and untick 'show layout bounds' and you are done. its simple and easy.
My problem is described in the following.
I recently developed a Phonegap app (Android and Ios are the target platforms) and deployed it on the markets. My app mainly consists in an event list.
The list is obviously scrollable. The purpose is to give a native feeling experience to the users or at least something close to it. Actually, I would like to enable inertia for most users (everyone would be awesome!).
The app can’t be downloaded by android < 3.0 phones, so it doesn’t matter if the solution excludes android 2.X users. In addition, for the moment the app is not design for tablets so I don’t mind if the solution doesn’t works with android < 4.0.
I use the following CSS property on the scrollable div:
overflow: scroll;
-webkit-overflow-scrolling: touch;
On Ios, there is absolutely no problem. It is fast and inertial scrolling is enabled.
With Android, I'm still having problems with some phones. Here are my tests:
Nexus 5 (Android 4.4) : inertia Ok
Sony Ericsson (Android 4.0.4) : inertia Ok
Samsung galaxy Trend (android 4.0.4) : inertia Ok
Samsung Galaxy Note 3 - SM-N9005 (Android 4.3): No inertia
Samsung Galaxy S4 (Android 4.3): No inertia
I don’t’ use any JavaScript library for scrolling (for example Iscroll ect…) and I don't want to do so except if it is a really lightweight librairy. In fact, I have tried Iscroll and the result is unusable because it is too slow and jerky. By the way, the event list contains gradient, images, text, shadow ect…
I have done a lot of research on the internet. And now, I feel lost!
I even don’t know if the problem is related to:
The manufacturer layer
The Android version
The default browser on the phone (I think not because it appears
that Phonegap doesn’t use it)
The embedded PhoneGap webKit rendering engine
Deprecated CSS properties : see this article
Something else?
It is a bit weird because it works on 4.0.4 and 4.4 but not on 4.3… I start to think this is related to manufacturer…
Any help, solution or information about the above would be really appreciated.
Not sure if you have solved your problem yet, but I just came across this issue.
I was using Hammer.js to detect drags for the sidebar, within doing so, I called preventDefault() which affected scrolling inertia in the android default browser, but not chrome. Removing that call fixed the issue.
I had the same problem. I looked into it for quite some time and the only solution I know is using a scrolling library. The best one I found is Overthrow: http://filamentgroup.github.io/Overthrow/
Cool thing is that it uses native scrolling whenever it can and only reverts to javascript when needed. Even works for me on old Adroid devices, while keeping that native scrolling feeling on iOS.
I just now started with my first PhoneGap project using zend studio. But, after i build and deploy it, the application is quite slow. Both on android and iOS. The scrolling is lagging, and if i press a button, it's slow to goto the next page. Is there any way to improve it's performance ? Thanks in advance
Since version 4.0.4, there is a known "bug" where if hardware acceleration is on, it will actually slow down screen redraw events. This is why scrolling is slow.
On the Samsung Galaxy III and IV, canvas would not render anything at all until we turned off hardware acceleration. Once we did canvas drawing performed well.
You can turn off hardware acceleration for your webview with this line of code in your app java file:
super.appView.setLayerType(WebView.LAYER_TYPE_SOFTWARE, null);
This may be fixed as of 4.4 (KitKat uses Chromeview rather than webview).
Yes,you can add fastclick.js file to your html file.
like:
<script src="../fastclick.js"></script>
& refer this documentation to improve your phonegap app.
Several reasons could be the root cause.
You should give more info to help you further.
Possible quick and simple solutions.
A) disable your page transitions and check the effect.
What kind of operations are you performing on your page?
Are you using additional libraries?
I am not familiar with Zen studio, but how are ypu building your UI?
The scroll could be slow or lagging if you are scrolling over a list or buttons or links and in each touch the page is triying to react to change to the hover state but it is not fast enough to match the scrolling speed. Once I had that problem and disable the hover state and the scroll speed improved a lot. Double check that in the meantime.
In Android KitKat you can use DevTools to debug performance of your application. This is a great video to get to grips with the tools: https://developers.google.com/live/shows/840309825
You should experiment with turning off hardware acceleration on the WebView, but would recommend experimenting on Pre-KitKat and KitKat seperately. The KitKatWebView is based on Chrome and as a result has very different performance characteristics.
as mentioned, use FastClick to remove the 300ms delay for clicks.
you can also use this code to speed up the page transition:
$(document).bind("mobileinit", function () {
$.mobile.defaultPageTransition = 'none';
});
I developed an application for android using jquery mobile and phonegap.
I deployed the app to my device over usb. The performance of the app ist really bad, especially while scrolling a longer list.
The strange thing is: The whole app runs smooth if i just open up the browser on my phone and access the index.html directly. Same technology, same content. I do not use the phonegap native api or anything similar.
Tested with phonegap 1.5.0 and 1.7.0rc1, jquery mobile 1.1.0 on android 4.0.2.
Any ideas?
On honeycomb (3.0), Ice cream (4.0) and posterior devices, you can boost performance by adding the following in the < Application ... > tag:
android:hardwareAccelerated="true"
You could set the minSdk to 8 (Android 2.2) for compatibility and the targetSdk to 15 (Android 4.0) and that would make hardware acceleration work when its available on the device only.
I believe that with this flag the performance of my apps is equal to running them in the browser, so I guess its because the browser was coded with hardware acceleration :)
I had a similar problem: a page with a longer list of "medium complex" themed divs. The browser of HTC phone had no problems in displaying. But within the phonegap app rendering failed completely. I saw a kind of WSOD, which disappeared only after touching the display. After touching, the page was displayed correct.
The problem was not in place, when I shortened the div-list to one or two div-elements or when I reduced the sub elements within the divs and reduced the render effort caused by the css complexity.
The white screen looked like, if the whole body was invisible, since only the documents background-color was displayed (I added a light pink for this). So I guess, the rendering was the problem after reading this thread
I tried the various proposals I found in this thread to make the app work without the "WSOD". But nothing worked. Some of them made the app displaying really worse.
Finally, after a whole day of searching, I made it. I set within the tag (not the tag) of my AndroidManifest
<application android:hardwareAccelerated="false" ...
Now the app behaves in the same fast way as my webbrowser. Seems like, if hardware acceleration is not always the best feature...
My versions:
phonegap 3.5.0, Android 4.0.3, jQuery v2.1.0, HTC Sense 3.6
Found an answer here: http://groups.google.com/group/phonegap/browse_thread/thread/94da1cf881abe995/6d4f7aea7aeba523?lnk=gst&q=performance
There is probably a difference between the native browser and the webview in terms of javascript performance.
If you can confirm the browser performs better (that it's not something suboptimal in your code frustrating one but not the other), you could consider deploying as an html5 offline application so that you will actually run in the browser.
We bumped into performance issues while scrolling the same amount of list items with jquery mobile. The performance was so poor (we didn't even try in PhoneGap environment) that we rewrote the app using iScroll library... now the app scrolls really smoothly.
If you are at the beginning of the development, you could try to change the UI library.
After this situation we deploy our apps to test devices quite often to manage performance issues in time... this became a "policy" :)