ANDROID PERFORMANCE BEST PRACTICES

Cairo, 9/1/2014

2

Agenda

• How Android Manages Memory

• How your App Should Manage Memory

• Performance Tips

3

How Android Manages Memory • Android uses paging and memory-

mapping (mmapped) to manage memory.

• Android does not offer swap space for memory.

• However, there is one exception any files mmapped in without modification, such as code, can be paged out of RAM if the system wants to use that memory elsewhere

4

Sharing Memory

In order to fit everything it needs in RAM, Android tries to share RAM pages across processes. It can do so in the following ways:

1. Each app process is forked from an existing process called Zygote. The Zygote process starts when the system boots and loads common framework code and resources . To start a new app process, the system forks the Zygote process then loads and runs the app's code in the new process1.

2. Most static data is mmapped into a process.

3. In many places, Android shares the same dynamic RAM across processes using explicitly allocated shared memory regions2

1- using copy-on-write semantics

2- gralloc buffers for UI

5

Allocating and Reclaiming App MemoryHere are some facts about how Android allocates then reclaims memory from your app:

• The Dalvik heap for each process is constrained to a single virtual memory range. This defines the logical heap size, which can grow as it needs to (but only up to a limit that the system defines for each app).

6

Allocating and Reclaiming App Memory• The logical size of the heap is not the

same as the amount of physical memory used by the heap. When inspecting your app's heap, Android computes a value called the Proportional Set Size (PSS), which accounts for both dirty and clean pages that are shared with other processes.

• This (PSS) total is what the system considers to be your physical memory footprint. 

7

Allocating and Reclaiming App Memory• The Dalvik heap does not compact the

logical size of the heap, meaning that Android does not defragment the heap to close up space. Android can only shrink the logical heap size when there is unused space at the end of the heap.

• But this doesn't mean the physical memory used by the heap can't shrink. After garbage collection, Dalvik walks the heap and finds unused pages, then returns those pages to the kernel 

8

Restricting App Memory

• To maintain a functional multi-tasking environment, Android sets a hard limit on the heap size for each app. The exact heap size limit varies between devices based on how much RAM the device has available overall. 

• If your app has reached the heap capacity and tries to allocate more memory, it will receive an OutOfMemoryError.

• You might want to query the system to determine exactly how much heap space you have available on the current device—for example, to determine how much data is safe to keep in a cache. You can query the system for this figure by calling getMemoryClass(). This returns an integer indicating the number of megabytes available for your app's heap.

9

Switching Apps

• Instead of using swap space when the user switches between apps, Android keeps processes that are not hosting a foreground ("user visible") app component in a least-recently used (LRU) cache.

• For example, when the user first launches an app, a process is created for it, but when the user leaves the app, that process does not quit. The system keeps the process cached, so if the user later returns to the app, the process is reused for faster app switching.

10

Switching Apps

• If your app has a cached process and it retains memory that it currently does not need, then your app—even while the user is not using it—is constraining the system's overall performance.

• So, as the system runs low on memory, it may kill processes in the LRU cache beginning with the process least recently used, but also giving some consideration toward which processes are most memory intensive.

11

Agenda

• How Android Manages Memory

• How your App Should Manage Memory

• Performance Tips

12

How your App should manage data

• You should consider RAM constraints throughout all phases of development, including during app design (before you begin development). There are many ways you can design and write code that lead to more efficient results, through aggregation of the same techniques applied over and over.

• You should apply the following techniques while designing and implementing your app to make it more memory efficient.

13

1. Use services sparingly

• If your app needs a service to perform work in the background, do not keep it running unless it's actively performing a job. Also be careful to never leak your service by failing to stop it when its work is done.

• When you start a service, the system prefers to always keep the process for that service running. This makes the process very expensive because the RAM used by the service can’t be used by anything else or paged out. This reduces the number of cached processes that the system can keep in the LRU cache, making app switching less efficient

14

1. Use services sparingly

• So how can we avoid this problem?

• The best way to limit the lifespan of your service is to use an IntentService, which finishes itself as soon as it's done handling the intent that started it.

• Leaving a service running when it’s not needed is one of the worst memory-management mistakes an Android app can make. So don’t be greedy by keeping a service for your app running. Not only will it increase the risk of your app performing poorly due to RAM constraints, but users will discover such misbehaving apps and uninstall them.

15

2. Release memory when your user interface becomes hidden

• When the user navigates to a different app and your UI is no longer visible, you should release any resources that are used by only your UI. Releasing UI resources at this time can significantly increase the system's capacity for cached processes, which has a direct impact on the quality of the user experience.

• Give me an example of a UI resource?

16

2. Release memory when your user interface becomes hidden

• How can we do this?

• To be notified when the user exits your UI, implement the onTrimMemory() callback in your Activity classes. You should use this method to listen for the TRIM_MEMORY_UI_HIDDEN level, which indicates your UI is now hidden from view and you should free resources that only your UI uses.

17

2. Release memory when your user interface becomes hidden

• Note: your app receives the onTrimMemory() callback with TRIM_MEMORY_UI_HIDDEN only when all the UI components of your app process become hidden from the user. This is distinct from the onStop() callback, which is called when an Activity instance becomes hidden, which occurs even when the user moves to another activity in your app.

• So although you should implement onStop() to release activity resources such as a network connection or to unregister broadcast receivers, you usually should not release your UI resources until you receive onTrimMemory(TRIM_MEMORY_UI_HIDDEN).

• This ensures that if the user navigates back from another activity in your app, your UI resources are still available to resume the activity quickly.

18

3. Release memory as memory becomes tight

• During any stage of your app's lifecycle, the onTrimMemory()callback also tells you when the overall device memory is getting low. You should respond by further releasing resources based on the following memory levels delivered by onTrimMemory():

• TRIM_MEMORY_RUNNING_MODERATE• Your app is running and not considered killable, but the device is

running low on memory and the system is actively killing processes in the LRU cache.

• TRIM_MEMORY_RUNNING_LOW• Your app is running and not considered killable, but the device is

running much lower on memory so you should release unused resources to improve system performance (which directly impacts your app's performance).

• TRIM_MEMORY_RUNNING_CRITICAL• Your app is still running, but the system has already killed most of

the processes in the LRU cache, so you should release all non-critical resources now. If the system cannot reclaim sufficient amounts of RAM, it will clear all of the LRU cache and begin killing processes that the system prefers to keep alive, such as those hosting a running service.

19

3. Release memory as memory becomes tight

• The previous events was given when your app is alive, however there are different set of levels that you can receive when your app is cached.

• TRIM_MEMORY_BACKGROUND• The system is running low on memory and your process is near the

beginning of the LRU list. Although your app process is not at a high risk of being killed, the system may already be killing processes in the LRU cache. You should release resources that are easy to recover so your process will remain in the list and resume quickly when the user returns to your app.

• TRIM_MEMORY_MODERATE• The system is running low on memory and your process is near the

middle of the LRU list. If the system becomes further constrained for memory, there's a chance your process will be killed.

• TRIM_MEMORY_COMPLETE• The system is running low on memory and your process is one of the

first to be killed if the system does not recover memory now. You should release everything that's not critical to resuming your app state.

20

4. Check how much memory you should use

• As mentioned earlier, each Android-powered device has a different amount of RAM available to the system and thus provides a different heap limit for each app. You can call getMemoryClass()to get an estimate of your app's available heap in megabytes. If your app tries to allocate more memory than is available here, it will receive an OutOfMemoryError.

• In very special situations, you can request a larger heap size by setting the largeHeap attribute to "true" in the manifest <application> tag.

• If you do so, you can call getLargeMemoryClass() to get an estimate of the large heap size.

21

4. Check how much memory you should use

• However, the ability to request a large heap is intended only for a small set of apps that can justify the need to consume more RAM.

• Think of an example?

• Never request a large heap simply because you've run out of memory and you need a quick fix—you should use it only when you know exactly where all your memory is being allocated and why it must be retained. Yet, even when you're confident your app can justify the large heap, you should avoid requesting it to whatever extent possible. Using the extra memory will increasingly be to the detriment of the overall user experience because garbage collection will take longer and system performance may be slower when task switching or performing other common operations.

22

5. Avoid wasting memory with bitmaps

• When you load a bitmap, keep it in RAM only at the resolution you need for the current device's screen, scaling it down if the original bitmap is a higher resolution.

23

6. Use optimized data containers

• Take advantage of optimized containers in the Android framework, such as SparseArray,SparseBooleanArray, and LongSparseArray. 

• These collections are used to map objects, you can compare this to Hashmap.

• Advantages:• Avoid using extra entry object for each mapping.• Avoid autoboxing for keys and sometimes for values.

• Disadvantages:• Use binary search for lookups, instead of hashing. Slower for

large number of entries , > 1000, compared to Hashmaps.

24

7. Be aware of memory overhead

• Be knowledgeable about the cost and overhead of the language and libraries you are using, and keep this information in mind when you design your app, from start to finish.

• Enums often require more than twice as much memory as static constants. You should strictly avoid using enums on Android.

• Every class in Java (including anonymous inner classes) uses about 500 bytes of code.

• Every class instance has 12-16 bytes of RAM overhead.• Putting a single entry into a HashMap requires the allocation of

an additional entry object that takes 32 bytes 

25

8. Be careful with code abstractions

• Often, developers use abstractions simply as a "good programming practice," because abstractions can improve code flexibility and maintenance.

• However, abstractions come at a significant cost:

• Generally they require a fair amount more code that needs to be executed, requiring more time and more RAM for that code to be mapped into memory.

• So if your abstractions aren't supplying a significant benefit, you should avoid them.

26

9. Avoid dependency injection frameworks

• Using a dependency injection framework such as Guice or RoboGuice may be attractive because they can simplify the code you write and provide an adaptive environment that's useful for testing and other configuration changes.

• However, these frameworks tend to perform a lot of process initialization by scanning your code for annotations, which can require significant amounts of your code to be mapped into RAM even though you don't need it

27

10.Be careful about using external libraries

• External library code is often not written for mobile environments and can be inefficient when used for work on a mobile client.

• At the very least, when you decide to use an external library, you should assume you are taking on a significant porting and maintenance burden to optimize the library for mobile.

28

11.Use ProGuard to strip out any unneeded code

• The ProGuard tool shrinks, optimizes, and obfuscates your code by removing unused code and renaming classes, fields, and methods with semantically obscure names.

• Using ProGuard can make your code more compact, requiring fewer RAM pages to be mapped.

29

Agenda

• How Android Manages Memory

• How your App Should Manage Memory

• Performance Tips

30

Performance Tips

• This part primarily covers micro-optimizations that can improve overall app performance when combined.

• but it's unlikely that these changes will result in dramatic performance effects. Choosing the right algorithms and data structures should always be your priority, but is outside the scope of this document.

• There are two basic rules for writing efficient code:• Don't do work that you don't need to do.• Don't allocate memory if you can avoid it.

31

1. Avoid Creating Unnecessary Objects

• Object creation is never free.

• As you allocate more objects in your app, you will force a periodic garbage collection, creating little "hiccups" in the user experience.

• Thus, you should avoid creating object instances you don't need to.

• Any Ideas on how we can do this??

32

1. Avoid Creating Unnecessary Objects

• If you have a method returning a string, and you know that its result will always be appended to a StringBuffer anyway, change your signature and implementation so that the function does the append directly, instead of creating a short-lived temporary object.

• When extracting strings from a set of input data, try to return a substring of the original data, instead of creating a copy. You will create a new String object, but it will share the char[] with the data.

33

2. Prefer Static Over Virtual

• If you don't need to access an object's fields, make your method static.

• Invocations will be about 15%-20% faster.

• It's also good practice, because you can tell from the method signature that calling the method can't alter the object's state.

34

3. Use Static Final For Constants

• Consider the following declaration at the top of a class:

• static int intVal = 42;• static String strVal = "Hello, world!";

• What do you think is happening? And how beneficial is the alternative if there is any?

35

4. Avoid Internal Getters/Setters

• In native languages like C++ it's common practice to use getters (i = getCount()) instead of accessing the field directly (i = mCount). 

• However, this is a bad idea on Android. Virtual method calls are expensive, much more so than instance field lookups. It's reasonable to follow common object-oriented programming practices and have getters and setters in the public interface, but within a class you should always access fields directly.

36

5. Use Enhanced For Loop Syntax

public void zero() {    int sum = 0;    for (int i = 0; i < mArray.length; ++i) {        sum += mArray[i].mSplat;    }}

• What do you think the problem here?

37

5. Use Enhanced For Loop Syntax

public void one() {    int sum = 0;    Foo[] localArray = mArray;    int len = localArray.length;

    for (int i = 0; i < len; ++i) {        sum += localArray[i].mSplat;    }}

public void two() {    int sum = 0;    for (Foo a : mArray) {        sum += a.mSplat;    }}

• What do you think about these options?

38

5. Use Enhanced For Loop Syntax

• zero() is slowest, because the JIT can't yet optimize away the cost of getting the array length once for every iteration through the loop.

• one() is faster. It pulls everything out into local variables, avoiding the lookups. Only the array length offers a performance benefit.

• two() is fastest for devices without a JIT, and indistinguishable from one() for devices with a JIT. It uses the enhanced for loop syntax introduced in version 1.5 of the Java programming language.

• So, you should use the enhanced for loop by default, but consider a hand-written counted loop for performance-critical ArrayList iteration.

39

6. Avoid Using Floating-Point

• As a rule of thumb, floating-point is about 2x slower than integer on Android-powered devices.

• In speed terms, there's no difference between float and double on the more modern hardware. Space-wise, double is 2x larger.

• As with desktop machines, assuming space isn't an issue, you should prefer double to float.

Thank You