[Android performance optimization series] ultimate article on memory-reducing your memory consumption

[Android performance optimization series] ultimate article on memory-reducing your memory consumption

If you like my blog, please pay attention to my Weibo, please click here (http://weibo.com/kifile), thank you

Reprinted please indicate the source (http://blog.csdn.net/kifile), thank you again

Address: http://developer.android.com/training/articles/memory.html

In the next period of time, I will translate some official Android documents about performance improvement every day for you.

We recommend that you go to my blog before reading this article.

[Android performance optimization series] memory basics-how to manage memory in Android

[Android performance optimization series] Memory Improvement-how should applications manage memory?

Digress:

This article is the last section of the memory section on the Android official website. After reading this memory document, I found that many things have never been quite noticeable before, for example, the memory space consumed by objects and classes, the use of dependent libraries, and the use of multiple processes. I hope you can take a good look and understand the memory mechanism of Android. If you think that my translation is not adequate, you can click the link above to view the original version on the official website.

The following is the body of this article:

################

Refuse to waste your memory on Bitmap

When you load a Bitmap, you can load it into the memory only when you do need to display it on the screen, or reduce the memory usage by scaling the source image size. Keep in mind that as the size of Bitmap increases, the memory consumed by images will increase in the order of square, because both the x and y axes of Bitmap are increasing.

Note: On Android and the following platforms, Bitmap objects always have the same size in your application heap (because their actual memory is stored in the local memory exclusively ). This makes it very difficult to analyze the memory resources consumed by Bitmap, because most analysis tools only collect the Dalvik heap information of your application. However, from Android3.0, to improve the garbage collection and debugging capabilities, the pixel data of Bitmap is stored in your Dalvik heap. Therefore, if your application uses Bitmap and you cannot find memory consumption problems on the old device, debug it on Android or a later model.

For more help on using Bitmap, you can view Manage Bitmap Memory (I strongly recommend that you check it to help reduce the Memory usage of Bitmap)

Use the Optimized Data container

Use the Optimized Data containers in the Andorid framework, such as SparseArray, SparseBooleanArray, and LongSparseArray. Containers similar to HashMap are not very efficient, because each Map needs to transmit data from a separate Entry object. SparseArray is more efficient because it prohibits the system from automatically encapsulating key-value pairs. And you don't need to worry about losing the original information.

Pay attention to memory usage

Please have a certain understanding of the language and dependency package you are using, and do not ignore it during the entire phase of your application design. Generally, most seemingly harmless things can make you spend a lot of memory, such as the following:

1. Enumeration typically consumes two times of memory resources compared with static constants. Therefore, you should avoid using enumeration types in Android.

2. Every class in Java (including anonymous internal classes) consumes about 500 bits of memory.

3. Each class object consumes 12-16 bits of memory

4. Put a single Entry into HashMap requires 32-bit memory consumption (for the reason, see the previous section to use the Optimized Data container)

Although the consumption seems to be relatively small, they accumulate a lot, and designing heavyweight classes in applications is likely to bear the memory costs. This will make your heap analysis difficult. It is hard to find out your problem because many small objects are occupying your memory.

Careful code Abstraction

Generally, developers will regard abstraction as a good programming habit, because abstraction can improve the flexibility and maintainability of code. However,Abstract METHODS may incur a lot of extra costs.For example, when they execute, they have a lot of code, and they will be mapped to the memory multiple times to occupy more memory, so if the abstract effect is not very good, you 'd better give up on him.

Use Protobufs for serialized data

Protocol buffers is a cross-language, cross-platform structured sequence data of Google. It is smaller, faster, and simpler than XML. If you decide to use Protobufs for your data, your application will always use Protobufs at the nano level on your client. Protobufs of the rule will generate extremely redundant code, which may cause various problems for the Application: increase memory usage, increase the APK package body, slow execution efficiency, and break the Dex symbol restrictions.

For more information, see protobuf readme

Avoid dependency injection framework

Using a dependency injection framework similar to Guice and RoboGuice may make your code more beautiful, because they can reduce the code you need to write, it also provides an adaptive environment for testing or when other conditions change. However, during initialization, these frameworks consume a lot of work to scan your code because of annotations. This will allow your code to spend more resources during memory ing. Although these memories can be recycled by Android, it takes a long time to wait until the entire page is released.

Use external dependency packages with caution

Many dependency packages are not written specifically for mobile environments or mobile clients. If you decide to use an external dependency package, you should know in advance that it takes a lot of time and effort to port it to the mobile end. Analyze the code and memory usage before using the external dependency package.

Even if the dependent package is designed for Android, it is potentially dangerous because every package is doing different work. For example, there is a dependent package that uses protobufs at the nano level, but other packages use protobufs at the micron level. Now there are two sets of protobuf standards in your application. This will happen when you record data, analyze data, load images, cache, or anything else you don't want to do. ProGuard cannot help you here, because they are the underlying implementation of your dependent packages ,. When you use Activity inherited from other dependent packages (which may inherit many dependent packages), this problem becomes particularly serious. When you use reflection and other things

Please be careful not to fall into the trap of a dependency package. You do not want to introduce a large piece of code that you will not use at all. If you cannot find an implemented logic to fully meet your needs, try to create your own implementation method.

Optimize Overall Performance

A lot of information about optimizing the overall Performance of applications has been put to the Best Practices for Performance. Many articles here explain how to optimize CPU Performance, however, many tips can help you optimize the memory usage of your application, for example, by reducing the layout elements of your ui.

You should read and optimize your ui and use the layout debugging tool for optimization. In addition, you can use the lint tool for optimization.

Use ProGuard to remove unnecessary code

The ProGuard tool can useRemove unnecessary code and rename classes, methods, and labels to recycle, optimize, and confuse code., Using ProGuard can make your code more compact and reduce memory consumption

Use Zipalign to optimize your Apk

If you have optimized your generated APK file, you must use Zipalign to align it with bytes. Otherwise, your application may consume more memory because the resources in the APK cannot be well mapped to the memory.

Note: The Google market does not accept APK files that have not been processed through Zipalign.

Analyze your memory usage

Once you have a stable version of the application, you can analyze the memory usage of the application from its entire lifecycle.