I have an app that loads a lot of bitmaps to form one large one.
I use soft references to allow these bitmaps to be stored appropriately. You are able to scroll over them with no problem on android OS < 2.3 However, once you get to 2.3 or higher, Android became much more aggressive with its soft reference collection. Since this happens, the app then runs very slowly on these newer phones.
I've seen this as a documented issue here:
http://code.google.com/p/android/issues/detail?id=20015
Does anybody know a good way to work around this? It's ridiculous that an app works way worse on a newer phone! Thanks for the help.
Soft references and weak references are handled in a different way above android 3.0. So it is better if you don't use them for bitmaps. You can use alternate methods like scaling down the bitmaps, disk cache, memory cache, etc. For more details on how to handle bitmaps refer http://developer.android.com/training/displaying-bitmaps/index.html
Related
I have been playing with optimizing my app, and I see that there are some general ideas on how much memory it should use... I'm running between 70-80Mb right now, is that a crazy number or just a little on the heavy side?
My second question is about the memory I am using. About 42Mb is taken up by graphics, whether I run the app with the layout graphics or run it without setting any views... any ideas on where to look? I feel like it is the theme, but I am not sure how to test that.
I've been searching for days to figure out why it uses so much and cannot figure it out. It remains constant regardless of which activity I am on, any ideas are welcome!
UPDATE:
I ended up running it on an emulator and got about 26Mb, more what I was expecting, but it runs at 70Mb with the 42Mb of graphics on the actual device.
The emulator allows for a 384Mb app after getting memoryclass information, while the device only allows 256Mb... the emulator has more storage and runs more efficiently.
The emulator is Android 8.1 27api while the device is Android 7.0 24api.
Tried on an older Android 5.1.1 api 22 below also.
Any ideas?
I have another question with about why the emulators have a such a difference in performance here if you know the answer on that, but I wanted to keep these questions separate: Other Question
Android Studio has an awesome tool called Memory Profiler. It helps you analyze possible memory leaks and see which calls are using up the most memory. You can even pause the processor and 'zoom in' to deep dive on the call stack.
You can use LeakCanary A memory leak detection library for Android and Java. Maintain by Square. This is one of the best developer's Tool for memory optimization and detecting leaks.here
I have developed an app which uses appcompat theme as the main theme.
In some activities there are more than 300 lines of code which use several card views, and in them are spinners and edit texts.
It performs well in many phones, but in phones with low RAM it hangs and causes the memory to be freed
I've used asynctask but the InBackground method is worker and doesn't interfere with graphics.
How can I handle this?
There is really good documentation on this issue on the Android Developer website: http://developer.android.com/training/articles/memory.html
Please post code if there is a specific area that you are concerned with.
When programming to mobile we need to face this kind of challenge. You should specify a target when you start to develop. In other words, it is really hard to develop an app which has the same and perfect behavior in all devices.
Brotip: Try to break your code. Is not usual to have more than 300 line of code in one file. Your method probably can be optimized. Otherwise, there is nothing you can do, once you reach the physical limitation of RAM size you will face this problem.
A solution for this problem COULD be use a Local DB and store the information that you use in this activity. Then you read it little by little.
Hope it helps and give you some ideas.
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.
I am developing a game application under Android built for SDKs >= 8. I always tested it under an Android 2.2 phone and never had a problem. When I moved to a Nexus phone with ICS mounted on I started having problems with the heap memory allocation. I tried to remove everything in the app to see where I was having memory leak problems or strange allocations (using both DDMS and MAT under Eclipse) until I decided to just start an empty activity and to do nothing more.
Under Android 2.2 the heap size at startup is about 2.0MB, while under Android 4.1 is about 11MB. Why is there such a great difference?
More, when I play my app the heap size on ICS, the garbage collector quickly starts freeing memory and the whole application becomes slow and with a very low FPS. Under Android 2.2 everything is really smooth and clean, without any single problem.
Does anyone can suggest me where's the difference between these two systems? I don't want to talk about my app implementation (I already spent 2 weeks optimizing code, memory allocation and retention and everything else. Can't do much more), but I want to understand where all that memory goes just at app startup. Also, ICS seems to require much more memory to load and retain bitmaps and drawables.
Okay, I may be late to the party, but I figured out the root of your (and my) problem.
Before Android 3.0 (not sure if this was in the entire 1.x/2.x series) all bitmap related memory was not stored on the heap. So with 3.0 they started locating everything on the heap. I am not sure why an empty application takes up 11MB, I can only guess it is related to the default Android bitmaps used in applications.
Now there is another problem: in earlier versions of Android, there was only a 'drawable' folder, not a 'drawable-hdpi', 'drawable-mdpi' etc... folder. For some reason, when loading in a image from the 'drawable' folder, it takes up HUGE amounts of space. The solution is to add different resolution variants of your images to all the drawable-Xdpi (where X is l,m,h or xh) folders. It reduced my starting heap size from around 26MB to a good 16MB. Even if you don't resize them, and just copy-paste them into the folders, it will still result in quite a significant change in Bitmap sizes.
I hope I help some people by posting this.
-Z
The Android Browser can't scroll inner divs. That means using SlickGrid with its default configuration is impossible.
Fortunately, SlickGrid has an autoHeight argument that makes it not use inner scrollable content, so it works on the android. Unfortunately, when autoHeight is enabled, onViewportChanged gets called once to span the entire viewport and is never called again, so it attempts to load all the data at once. I'm lazy-loading and displaying so much remote data that if you try and load it all at once it crashes mobile devices, so that's a no go.
If SlickGrid were smart enough to know what's on the screen even if autoHeight is enabled, that would solve my problem. I'd love it if that was a feature in core, since that would solve many problems on the desktop as well as on Android devices.
I also tried using iScroll 4 to get around the Android limitation. Unfortunately, it doesn't trigger onViewportChanged at all when I use iScroll.
I will probably have to solve this by ditching or modifying onViewportChanged to handle my own scrolling events. I was wondering if there is an existing solution for this though.
I ended up writing my own version of slickgrid for this purpose. Also, this will become irrelevant when Google Chrome becomes the default browser, as it actually has decent support for scrolling.
I would not recommend using SlickGrid for apps/pages targeting mobile devices. The grid was not developed with mobile devices in mind. They require a completely different approach optimized for that particular use case.