Android Memory leakage and optimization, as well as MAT tools and androidmat
I. Introduction
In Android machines, memory usage has always been a very important and compelling problem. When our code is improperly compiled or the logic is not properly handled, it will cause the machine to run slowly, sometimes even crashes. For programmers, this is fatal. So we need to understand the memory usage, avoid Memory leakage, and constantly optimize the memory. When memory leakage causes problems, we can analyze the log, and the MAT tool is used.
Ii. What scenarios will cause memory leakage?
Memory leakage is actually because the memory-occupied objects are not recycled after being used. In this case, when the java program runs for a period of time, the memory occupied by the process increases, resulting in the memory occupied by the process reaching the memory usage limit allocated for the process by Android, and the program will die.
Iii. Considerations for Memory Optimization
1. Image Optimization
Displaying Bitmap images in Android may cause a certain amount of memory consumption or even an OOM exception. Therefore, you must handle the display of images.
- The large image display must be compressed before it can be loaded. For example, if a 2048 kb image is read in memory, the attribute is ARGB_8888 (default ), that is, a pixel of 4 bytes, the total memory is 4*2048*1024 bytes, more than 8 m. It can be seen that it is necessary to compress and load large images. Detailed compression methods can be seen in Android's efficient loading of large images to prevent OOM and multi-graph solutions.
- The memory cache technology should be used to display multiple images. In a ListView (or GridView), images are constantly loaded, so it is impossible to keep the images in the memory, because the memory has an upper limit and other operations need to be allocated memory. Therefore, in the visible area, some memory that is removed from the screen must be recycled. If the removed part is used immediately in the next operation, if it is removed and recycled, the performance efficiency will go on immediately. Therefore, you can use the LRUCache cache technology. For more information, see the blog above.
- In ListView, you can quickly slide and load images without affecting the user experience. During the quick slide process, resources loaded during the sliding process will not be used, but will affect the loading of resources to be viewed. Therefore, when the list is quickly slide (SCROLL_STATE_TOUCH_SCROLL, we will no longer get the loaded resources. We need to register a rolling listener OnScrollListener when loading resources at rest (SCROLL_STATE_IDLE) and the touch screen (SCROLL_STATE_TOUCH_SCROLL.
2. Optimization of threads and asynchronous tasks
The uncontrollable lifecycle of threads, asynchronous tasks, and other tasks has become another source of Memory leakage. In general, we should treat it with caution because it is frequently used.
- At the end of the Activity, the created thread should be destroyed in time. Otherwise, when the thread holds a reference to the Activity, it actually thinks that the Activity to be exited will not be destroyed because the thread is not finished, memory leakage occurs, so Thread can be used. the interrupt () interrupt thread, although not in the true sense! The Thread interrupt mechanism (interrupt) can be seen in detail)
- The lifecycle of AsyncTask asynchronous tasks is not controllable. You must pay attention to one thing, because you usually like to create AsyncTask in the Activity as an internal class to complete some time-consuming and Ui interaction operations, which is very convenient, however, this is highly risky because it is prone to memory leakage. An asynchronous task uses ThreadPoolExcutor as its internal implementation mechanism, so the thread object life cycle is uncertain !! Someone has provided two solutions on the Internet: 1. Change the internal class of the thread to a static internal class (I have never tried it and I don't know the effect) 2. Use Weak references within the thread to save Context reference. The following code is used:
public abstract class WeakAsyncTask<Params, Progress, Result, WeakTarget> extends AsyncTask<Params, Progress, Result> { protected WeakReference<WeakTarget> mTarget; public WeakAsyncTask(WeakTarget target) { mTarget = new WeakReference<WeakTarget>(target); } /** {@inheritDoc} */ @Override protected final void onPreExecute() { final WeakTarget target = mTarget.get(); if (target != null) { this.onPreExecute(target); } } /** {@inheritDoc} */ @Override protected final Result doInBackground(Params... params) { final WeakTarget target = mTarget.get(); if (target != null) { return this.doInBackground(target, params); } else { return null; } } /** {@inheritDoc} */ @Override protected final void onPostExecute(Result result) { final WeakTarget target = mTarget.get(); if (target != null) { this.onPostExecute(target, result); } } protected void onPreExecute(WeakTarget target) { // No default action } protected abstract Result doInBackground(WeakTarget target, Params... params); protected void onPostExecute(WeakTarget target, Result result) { // No default action } }
In terms of memory optimization, there are many other aspects that need to be supplemented and efforts are needed.
Iv. Memory Analysis
I recommend that you analyze memory usage or troubleshoot memory leaks.
Let's take a good look at the articles of the following great gods. I believe there will be great gains after reading them. I am doing this =. =
- How to Analyze memory leakage in android
- Android Best Performance Practice (II)-Analysis of memory usage
Record here for future reading.
Copyright Disclaimer: This article is an original article by the blogger and cannot be reproduced without the permission of the blogger.