The document provides a comprehensive overview of best practices for optimizing Android application performance, including advice on effective coding techniques, layout efficiency, and resource management. Key topics include the use of primitives, layout strategies, memory leak detection through LeakCanary, and employing developer tools for performance measurement. It also emphasizes the importance of developing for low-end devices and offers specific tools and methods to streamline applications.

1. Android Performance Tips & Tricks
Sergii Zhuk
Android Developer at DAXX BV
Kyiv, FrameworksDays Android Saturday, 2015-06-06 1

2. Agenda
• Effective Java in Android
• Layouts and UI
• Proper Use of Resources
• Dev Tools and Measuring Performance
2

3. Effective Java in Android
• Avoid using Floating-Point
• Prefer primitives and primitive-backed data
structures (ArrayMap, SparseArray)
• Two parallel (int) arrays are better than array
(int,int)
3

4. Effective Java in Android
• System.arraycopy() is about 9x faster than a
hand-coded loop
• Make your method static: invocations will be
about 15%-20% faster
• Do not use Enums
WAT??
 @IntDef annotation
4

5. Supplying Scaled Drawables
• Why not to supply a single xhdpi image as blurred
background for the screen?
• Rendering performance will decrease because
device should scale your image during app
execution
• Such operation requires extra memory for Bitmap
native processing, potential source of
OutOfMemoryError
5

6. Make Your Layouts Flat
• Inflating layout is a top-down traversal of the
view tree
• Hierarchy Viewer (Android SDK) allows to
analyze layout while your application is
running
6

7. “Heavy” ViewGroups
• RelativeLayout requires two measurement passes to
ensure that it has handled all of the layout relationships
• The same is valid for LinearLayout with layout weights
• If one of the children of ViewGroups shown above is again
RelativeLayout or LinearLayout with weights – four
measurements passes will be required for sub-hierarchy
• GridLayout could be good solution in some cases (API 14+)
7

8. GridLayout example
8

9. Splash Screen Effect
• Show a blank window constructed with the
application theme, including specified
background drawable while application is
starting
• Behavior is provided by OS
9

10. Splash Screen Effect
10

11. ViewStub
• A lightweight view with no dimension and
doesn’t draw anything or participate in the
layout
• Use ViewStub as a “lazy include” for sub-
hierarchies that can be optionally inflated
later.
11

12. Develop for the Low End
• Devices distribution in the world
• Most of users could have lower-end devices
than yours
• Use ActivityManager.isLowRamDevice() to
detect if device in the class of a 512MB RAM
and/or about a 800x480 screen [API 19+]
12

13. 13
Develop for the Low End
* More details at my Stackoverflow.com question
Nexus 4 (Genymotion emu)
and other devices
Lenovo P780 with Android 4.2.1

14. Remove unused resources
• Lint (Android SDK): will highlight these resources
• Android-resource-remover (consumes Lint
output)
• Gradle:
14
buildTypes {
release {
minifyEnabled true
shrinkResources true
}
}

15. Multiple APKs on Play Store
• Different APKs for your app that are each
targeted to different device configurations
• Have same app listing on Google Play and must
share the same package name and be signed with
the same release key
• Recommended to use multiple APKs only when
your APK is too large (> 50MB)
15

16. Gradle Plugin: APK splits
android {
...
splits {
density {
enable true
reset()
exclude "ldpi", "tvdpi", "xxxhdpi"
}
}
16
WARN: you will need to set different version code for each APK file

17. Developer Options On Your Device
17

18. Developer Options On Your Device
18

19. Avoid Requesting a Large Heap
• Requesting a larger heap may be necessary in
some rare situations like media content
• android:largeHeap=“true” result: less memory
to be available for other apps, necessitating
them being killed and restarted
• android:largeHeap seems to be not enough
documented
19

20. Memory Leaks
• If a chain of references holds an object in
memory after the end of its expected lifetime
• Old approach:
Dump  Fix header  MAT  Find leak
• New approach: LeakCanary will notify you
20

21. LeakCanary
21
dependencies {
debugCompile 'com.squareup.leakcanary:leakcanary-android:1.3.1'
releaseCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.3.1'
}
public class ExampleApplication extends Application {
@Override public void onCreate() {
super.onCreate();
LeakCanary.install(this);
}
}

22. LeakCanary
22
* Sometimes you still need MAT

23. In-app performance check
• StrictMode
• Google’s profiling tools: Traceview &
dmtracedump
• Hugo by Jake Wharton
• Tools like NewRelic to show bottlenecks in
response time
23

24. References
• http://developer.android.com/training/articles/perf-tips.html
• Chet Haase at Medium: Developing for Android (parts 1-5)
• Memory leaks in Android (in Russian)
• Android Performance Case Study by Romain Guy
• Is Android layout really exponentially hard? SO discussion
• Pro Android Apps Performance Optimization by Herv Guihot
• Eric Lafortune talk on MCE2015 Conference
• Cyril Mottier blog
• Taylor Ling blog
• Romain Guy blog
• Android Performance Patterns (YouTube and G+)
• DOU.ua Android Digest 
24

25. Thank you!
@sergiizhuk
sergey.public@gmail.com
http://ua.linkedin.com/in/sergiizhuk
25