

Optimizing performance on low-end Android devices - yinyinwu
http://blog.echolocker.com/performance

======
barrkel
It'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.

~~~
bjnbb
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...](http://what.thedailywtf.com/t/optifine-modder-rips-the-minecraft-
devs-for-the-code-in-the-newest-version/4235) It's allocating 150 MB/second.
It's now much slower than it was before.

~~~
Jyaif
With new allocations you can have better cache consistency, so reusing objects
is not always faster.

------
tdkl
I 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.

[http://pastebin.com/AdUsUaG6](http://pastebin.com/AdUsUaG6)

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/](http://review.cyanogenmod.org/#/c/91021/)

Google Android, thank you, not anymore.

~~~
charleslmunger
Cyanogenmod is disabling parts of the Google Play Services APK and then acting
surprised when that introduces bugs. I don't have a ton of sympathy towards
that.

~~~
tdkl
Great choice of cherry picking a comment, disregarding the shit Google does
before this. But OK, let me reply to your statement.

Before Google Play Services existed, there was already a mechanism in place
that checked for OTA updates. It was in AOSP and could be easily disabled for
custom ROMs. Remember those custom ROMs Google was so proud of when they
advertised "open source" and how Android was dedicated to it ?

Then in a full "bait and switch" manner they placed everything in the Google
Play Services. AOSP doesn't matter anymore, but the proprietary code no one
has control of, except the Mountainview mothership. If CyanogenMod didn't
disable those services, they would constantly download OTA package to /cache
wasting user bandwidth and resources as in wakelocking the device causing
battery drain. Is this "responsible programming" ?

My personal experience with the new GPS 7.0 update woes doesn't even include a
custom ROM. I had Googles Nexus 5 factory image of Kitkat 4.4.4 installed and
blocked the GPS SystemUpdate receivers manually to avoid OTA updates to
Lollipop 5.0 .Why ? Because I don't want an update that turns a well working
OS to one which leaks memory and has to be rebooted every two days. It's my
choice. Other vendors include an option, whether user wants update
notifications or not. Not on Googles turf, they want to force you with their
beta software, then turn the head away when there are issues without comments
when they'll be fixed.

------
xenadu02
From 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.

~~~
izacus
The problem with other approaches is of course that you're relying on an
American company to make security decisions based on what will get them sued
and what is tailored for an average Joe. This usually results in any powerful
functionality of those portable computers we have in our pockets being
disabled.

And we already DO have OS that caters to that demographic - iOS. I'd like
Android to move more in the direction of distinguishing itself apart from
Apple way of doing things, not copying the same closed sandbox.

