Shared publicly  - 
 
Recently, +Pierre-Yves Ricau and I gave tech talks at our "Streamlining Android Apps" event in Square's San Francisco office. These talks were recorded and are now available on Square Engineering's YouTube channel. Enjoy!

Eliminating Code Overhead (Jake Wharton)
https://www.youtube.com/watch?v=b6zKBZcg5fk

The CPU, RAM, and disk are finite resources that are often taken for granted as unbounded. Not only is this obviously untrue, but the use of these resources directly affects the most important resource on a mobile device: the battery. This talk will focus on techniques that both libraries and applications can implement to ensure their effect is in general without overhead.

LeakCanary (Pierre-Yves Ricau)
https://www.youtube.com/watch?v=D_hjK-tEHoQ

In just a few few weeks, we reduced by 94% the OutOfMemoryError crashes in the Square Register Android app. We built squ.re/leakcanary to automatically detect memory leaks and make it very easy to fix them. This talk will cover the principles as well as the underlying implementation details. We'll dig into a few interesting examples and lessons learned.

#AndroidDev
213
85
Jelly Chen's profile photoSachin Rajput's profile photoDaniel Tarlow's profile photoSait Sami Kocataş's profile photo
15 comments
 
Watched! Thanks for all the talks :)
 
+Jake Wharton Just curious: have you benchmarked any of these optimizations? I've been using some of them for quite a while but still wonder how much they actually matter in practice.
 
I have not benchmarked any.

The allocation-based ones are fairly obvious wins. We did use allocation tracker to discover some hot points which were not using some of these (as mentioned in the talk) that we observed disappear after changing. We saw the GC running slightly less just by watching logs in these instances, but no real numbers.

As to the ones around caching method and field lookups, these are really tiny so you'd probably have to be using something like JMH to get numbers that were true and accurate (but then not relevant to Android). They're based around knowledge of how the VM works and simply choosing to do something less (once vs. many/N times).

I would like to see actual numbers, but I fear that sharing actual numbers would diminish people's opinion as to whether these are necessary. They're bound to be small! I forgot to mention in the talk, but in hot places like the draw path things like caching method/field lookups are seen all over AOSP. A frame's time is as scarce of a resource as the battery so doing something once vs. many/N times is going to help keep you on that path to 60fps.
 
+Jake Wharton Yeah, I agree that numbers could end up sending the wrong message, if taken out of context.

I tend to see such micro-optimizations as a way to increase the odds that your code will have a healthy systemic behaviour even at scale. And many of them are very easy to apply anyway.
 
I find it interesting that new flagship phones have as much (or more) memory than many Chromebooks or even some Mac developer laptops. Crazy.
 
nice talk... can you share the slides?
 
Superb talk. Thanks for sharing.
 
I love learning about internals of things! Great presentations, I wish they were longer :)
 
great presentation, thanks for that.
will the part you mentioned at the end will be another presentation? I am sure it would help to many developer.
Add a comment...