Optimizing performance on low-end Android devices
blog.echolocker.com
Optimizing performance on low-end Android devices
1–10 of 14 posts
Re: Optimizing performance on low-end Android devices
#2It's unfortunate that some of the recommendations here - particularly around reusing objects - are going to be out of date, and potentially deoptimizations, when Android gets smarter GC.
There's a tension in platform optimization. Whether it's CPUs or runtimes, people who make platforms tend to look at where they can get the biggest wins for existing apps. So if you bend over backwards to do weird things that get you performance, that weirdness will be exactly what prevents you from getting as big a potential win from future platform optimizations.
With GC in particular, that usually means avoiding the creation of objects that die in middle age. Most GCs are optimized for objects that are ephemeral or long-lived. Ephemeral objects have too few references and not long enough of a lifetime to survive multiple GCs. Long-lived objects live too long to be worth collecting for most GCs. Generational GC uses this to split memory into at least 3 logical buckets (survived 0 GCs, survived at least 1 GC, and long-lived).
Working hard to reuse objects means those objects will become part of the long-lived heap. But reusing them means updating their fields, including their references to other objects, which means they still need to be scanned. So they'll increase the cost of what ought to be cheap GCs of the ephemeral objects; writes to them needs to be accounted, and they need to be included as roots.
The situation becomes even worse if you reuse an object for some time, but eventually find some of them surplus to requirements (the middle age problem).
The costs of designing an application to reuse objects are not to be sniffed at either. It's a reinvention of a typed memory allocator, with all the benefits and drawbacks of manual allocation. Best kept to the implementation-side of properly scoped modules. Don't let the approach pervasively infect the entire app.
Re: Optimizing performance on low-end Android devices
#3It's unfortunate that some of the recommendations here - particularly around reusing objects - are going to be out of date, and potentially deoptimizations, when Android gets smarter GC. There's a tension in platform optimization. Whether it's CPUs or runtimes, people who make platforms tend to look at where they can get the biggest wins for existing apps. So if you bend over backwards to do weird things that get you…
When do you think that the low-end devices in question will actually be the beneficiaries of the smarter GC?
Re: Optimizing performance on low-end Android devices
#4I find it ironic seeing all those Google developer guidelines on how to be responsible with leaving Services running, but they leave their own crap running 24/7 while you don't even need to run the app.
Not to mention their last Google Play Services update that gets forced to all users automatically is causing wakelocks wanting to update the system, which wrecks havoc on custom ROMs : http://review.cyanogenmod.org/#/c/91021/
Google Android, thank you, not anymore.
Re: Optimizing performance on low-end Android devices
#5It's unfortunate that some of the recommendations here - particularly around reusing objects - are going to be out of date, and potentially deoptimizations, when Android gets smarter GC. There's a tension in platform optimization. Whether it's CPUs or runtimes, people who make platforms tend to look at where they can get the biggest wins for existing apps. So if you bend over backwards to do weird things that get you…
Thanks for the input! I'm a cofounder at Echo. From our experience, one tricky part of Android dev is the garbage collection. For the end users, garbage collection sometimes creates noticeable lag. That's one of the worst experience we want to avoid. So for Echo, it's almost always worth the tradeoff to reuse objects and avoid unnecessary new object creation, which means less garbage collection. But like you said, the middle-age objects could pose some problems in the future. Judging from the past trend, garbage collection will always be one rocky part of the Android land, which was quite a lesson for us when moving from the ios arc world :)
Re: Optimizing performance on low-end Android devices
#6It's unfortunate that some of the recommendations here - particularly around reusing objects - are going to be out of date, and potentially deoptimizations, when Android gets smarter GC. There's a tension in platform optimization. Whether it's CPUs or runtimes, people who make platforms tend to look at where they can get the biggest wins for existing apps. So if you bend over backwards to do weird things that get you…
When do you think that the low-end devices in question will actually be the beneficiaries of the smarter GC?
I don't think it's going to happen in the short term. 70% of our users are on devices outside of the better featured google nexus, samsung s, lge g, motorola moto, etc series phones. Even though our user base leans towards early adopters, less than 2% are on the nexus 5 (nexus 6 is too small to show up in the stats).
google posts their stats on os adoption here: https://developer.android.com/about/dashboards/index.html. 30% of users are on 4.1 and above. Phones running lower than 4.1 are not going to benefit from the smarter GC. If you're supporting international users, lower end phones will likely be a bigger percentage of your userbase.
Re: Optimizing performance on low-end Android devices
#7It's unfortunate that some of the recommendations here - particularly around reusing objects - are going to be out of date, and potentially deoptimizations, when Android gets smarter GC. There's a tension in platform optimization. Whether it's CPUs or runtimes, people who make platforms tend to look at where they can get the biggest wins for existing apps. So if you bend over backwards to do weird things that get you…
Thanks for the input! I'm a cofounder at Echo. From our experience, one tricky part of Android dev is the garbage collection. For the end users, garbage collection sometimes creates noticeable lag. That's one of the worst experience we want to avoid. So for Echo, it's almost always worth the tradeoff to reuse objects and avoid unnecessary new object creation, which means less garbage collection. But like you said, th…
This is sound advice.
I've been developing on Android since the 1.x days. Garbage collection has and continues to suck on Android.
People should not be so blind to think that better garbage collection is going to appear soon, and that a real world improved garbage collector will magically make all the GC related performance problems go away.
Google has demonstrated over and over that they are extremely slow to improve things in Android (see Java version support, see audio latency, see NDK, see Eclipse/Gradle transition, etc). And when they do finally improve things, it usually is still lacking.
Garbage collection in general is hard to get right. Even in better environments with highly optimized/tuned GCs, it still causes problems. It is unlikely Android is going to leap frog these.
Re: Optimizing performance on low-end Android devices
#8It's unfortunate that some of the recommendations here - particularly around reusing objects - are going to be out of date, and potentially deoptimizations, when Android gets smarter GC. There's a tension in platform optimization. Whether it's CPUs or runtimes, people who make platforms tend to look at where they can get the biggest wins for existing apps. So if you bend over backwards to do weird things that get you…
The low end phones of today are still going to be running android 2.x until they die; and they're still going to need all the help they can get.
Re: Optimizing performance on low-end Android devices
#9It's unfortunate that some of the recommendations here - particularly around reusing objects - are going to be out of date, and potentially deoptimizations, when Android gets smarter GC. There's a tension in platform optimization. Whether it's CPUs or runtimes, people who make platforms tend to look at where they can get the biggest wins for existing apps. So if you bend over backwards to do weird things that get you…
Reusing objects will always going to be faster. If memory is not being allocated, GC never runs.
Look what happened to Minecraft when they stopped caring about allocations: http://what.thedailywtf.com/t/optifine-modder-rips-the-minec... It's allocating 150 MB/second. It's now much slower than it was before.
Re: Optimizing performance on low-end Android devices
#10From another article on the site:
"Can you ask for too many permissions? Short answer is no ... Our personal experience and that of other startups we’ve chatted with suggest any effect is overplayed. Just by browsing the Play store, you can easily find popular apps, including Facebook, WhatsApp, and Candy Crush, that ask for a lot of permissions. Most users scan the permission requests, and a list with 3 vs 5 permissions makes no difference."
Everything wrong with Android permissions in a single paragraph.
When security relies on users making good secure decisions, you've failed. If Internet Explorer taught us anything it's that people will always click YES to punch the monkey, certificates/sandboxes/policies be damned.