I developed and tested an app on Android 3.2, it interacts with the SQLite database and show the results on the screen. I don't have animations or anything fancy. What I do have is a lot of ListViews to show data to the user.
The database for the app is very big, with somes tables having more than 300k rows. We tried to use AsyncTask in every interaction with the database, but there are some points we still have to optimize the performance.
The problem is that the company updated some of the tablets to Ice Cream Sandwich and the app is much slower than it was on Honeycomb. I loaded the same code, with the same db, in two devices, one running ICS and the other with Honeycomb. The app performed much better in the 3.2 device. I also tried using <uses-sdk android:minSdkVersion="14" /> but it didn't do better.
Is there anything I could do to optimize the performance on the 4.0? I also would love to know why this happened and if there's anything that could have caused that (some component or class that doesn't work that well on 4.0).
Thanks!
UPDATE: I found the solution for the main screen of my app. I was presenting a fragment that worked as a horizontal list, it was a HorizontalScrollView that loaded a huge list of data and created a lot of LinearLayout to be presented inside the ScrollView. I found a widget of a HorizontalListView and used it to load my list. Just that made the app faster. But I didn't find the answer to why it was slower on the ICS.
I also tried profiling the app, but it is a very hard thing to do, there's lot of information. I'll probably still do that in the next weeks to speed up the application. Thank you for all the answers and comments!
My guess is it is related to hardware acceleration which is default enabled for ice cream sandwich. Hardware acceleration is nice but it sometimes comes with a performance decline.
There is another interesting read about android hardware acceleration by Dianne Hackborn on google+ I'd recommend you to look at.
Related
I am investigating ways to improve performance in EditText, specifically in regards to load times. When loading large documents of a few thousand words or more, calling setText can freeze the UI for several seconds on some of my test devices and emulators.
In response, I have explored several possible solutions, none of which produce satisfactory results. I have tried to split large documents by paragraph, and load each paragraph into its own RecyclerView or ListView row. RecyclerView was completely hopeless due to a problem that causes jerky scrolling. ListView provided great, almost immediate, load times, and pretty good scrolling (although not as a good as one EditText block) but there is an issue where EditText blocks inside rows lose focus when selected. I have also attempted to update an EditText in sections from onProgressUpdate in an AsyncTask, hoping that the user could interact with the text as it loads in sections, but load times are largely unaffected.
The most promising avenue I have explored relates to changing the following element in AndroidManifest.xml:
android:hardwareAccelerated="false"
I got the idea after watching the following segment from this YouTube clip on the Google Developers channel. When I switched on GPU Profile rendering, I discovered that the orange bar (representing "process time") was rocketing every time setText was called. When I switched off hardware acceleration, setText performance increased massively, although other areas (like scrolling) became much worse.
What I would like to understand is - why is this happening? Also, is there a way that I can use this information to further increase performance? Can I toggle hardware acceleration off and on again programatically simply?
It's worth mentioning some devices, like a Nexus 7 2013 running API 22, don't suffer any issues whatsoever when calling setText on large documents, whereas others really struggle with hardware acceleration on. I just want to understand what's going on better so I can attempt to fix it! Thanks.
EDIT:
Here is a link to a GitHub Repository for anyone to download one of my sample test apps to replicate the problems I listed above. I also have three videos I posted on the site demonstrating these issues, which I shall mirror below:
I have made three video demonstrations that show this app running on a
Huawei Honor Holly running KitKat
4.4.2 with the hardwareAccelerated attribute set to true in the
AndroidManifest, then with the same phone with the same attribute
set to false, and a separate Nexus 7 (2013) running Lollipop
5.1 with hardware acceleration enabled. GPU Profiling is on in each case.
Honor Holly - Acceleration
On
Honor Holly - Acceleration
Off
Nexus 7 (2013) - Acceleration
On
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.
I have a widget that makes use of a new feature that, according to the infinite wisdom of the intarwebs, is stock in Android 4.0 (Ice Cream Sandwich). Conveniently, my phone is just that.
This widget inverts the screen colors for the phone. Not just an app; the screen in its entirety.
I started playing around with an amazing app called Tasker the other day that can do some crazy-powerful things; including run scripts, send commands to the phone, etc.
I'm trying to figure out where in the world this inversion lives so I can tap into it myself via Tasker, but I'm falling short everywhere. The Android API documentation is Greek to me, and Google seems to only ever want to point me to people talking about how great the feature is.
Any ideas as to where I can find this feature/function/action/whatever in a programmatic sense?
Thanks much in advance! Any help will be most appreciated.
I've searched and the only thing I found is when it's available on custom roms/kernels.
I don't think it's available for stock roms.
We have an HTML5-base app that's running in PhoneGap, using (mostly) jQuery for the components. Fairly regularly, the UI will be changed in javascirpt, but not completely render correctly. You kind of need to nudge it with another touch event, which causes it to "remember" to redraw everything. I suspect its some attempt to optimize the draw, but it forgets to update other parts of the screen that were changed.
I'm going to start modifying different css settings in the hope that it turns out to be some kind of simple bug, but I'm surprised that this isn't reported more widely (which makes me think this is due to a "magic combo" of css attributes).
So far the vast majority of testing has been on ICS. I don't have a 2.x device handy right now, but will try that tomorrow. My phone updated to Jelly Bean, so I'll try that and see if anything is different.
Will try to post a screenshot later.
Thanks in advance.
UPDATE
This works fine in Jelly Bean. I did a search in the public Android bug DB but nothing turned up. I'll have to dig out another phone with ICS on it and try different CSS settings and see if it goes away.
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" :)