Android memory leaks and optimizations, as well as the Mat tool

<span id="Label3"></p><p><p><strong>I. Introduction</strong><br>In android, memory use issues have always been a very important, compelling issue, when our code is poorly written, or the logic is not handled well, it can cause the machine to run slowly, and sometimes even Crash. For programmers, This is deadly, so to understand the use of memory, to avoid memory leaks, and constantly optimize memory, and when there is a memory leak caused by the problem, we can analyze the log, and will use the tool mat.</p></p><p><p><strong>two. What scenarios can cause memory leaks</strong><br>Memory leaks are actually memory-consuming objects that are not recycled after they are used. In this case, when the Java program runs for a while, the memory becomes larger, causing the Process's memory consumption to reach the memory usage limit that Android has allocated for the process, and the program is DEAD.</p></p> <ol> <ol> <li>ListView, gridview, etc. when using the adapter, the Convertview cache is not used</li> <li>Bitmap not released after use</li> <li>Context leaks, context references are more than their own life cycle. For example, a long-running asynchronous task or a long time object with a reference to the activity (context type), when the activity is destroyed, but the memory is still there, the context cannot be recycled. So in this case, it should be better to use Getapplicationcontext</li> <li>Database cursors or file stream caches are not closed after use</li> <li>Improper use of THREADS. The run function in the thread handles time-consuming work, and when the device switches between the screen and the other, recreating the activity, the referenced activity is not destroyed because the run function is not processed. Again asynctask, due to the operating mechanism threadpoolexcutor, the life cycle is more uncontrolled, more prone to problems (concrete solutions, can see the following explanation).</li> </ol> </ol><p><p><strong>Three. memory-optimized Attention Points</strong></p></p><p><p>1. Picture optimization<br>In the Android display bitmap picture, will cause certain memory consumption, may even cause the oom unusual outbreak, therefore for the picture display, must do certain processing.</p></p> <ul> <ul> <li>The large picture shows that you want to compress before Loading. A picture, do not think the surface of the small but not to dismiss, such as a 150kb picture, when reading memory, if the picture pixel is 2048*1024, using the property is argb_8888 (the default), that is, a pixel 4byte, then the total memory is 4*2048*1024byte , more than 8M. visible, large picture compression loading is necessary. Detailed compression detail method visible Android load large map, prevent oom, and multi-figure solution</li> <li>The multi-graph display should utilize the memory cache Technology. In a ListView (or gridview), the picture is constantly loaded, and it is not possible to keep the picture in memory all the time because the memory is capped and the memory is allocated for other operations. So when you are in the visible area, you want to recycle some of the memory that is removed from the Screen. If the removed part is to be used immediately in the next operation, then if the recovery is removed, the performance efficiency will go down immediately, so you can use the LRUCache cache technology. specifically, The above blog post is Visible.</li> <li>The quick slide loading picture in the listview, without affecting the experience, should be judged by the slide state to load the Operation. In the fast sliding, because the sliding process of the loaded resources are not used, but affect the user to view the load of resources, so in the fast sliding (scroll_state_touch_scroll) list, It is no longer to get loaded resources, at rest (scroll_state _idle) as well as touch screen (scroll_state_touch_scroll) to load, we need to register a scroll listener onscrolllistener.</li> </ul> </ul><p><p>2. threading, Asynchronous Task optimization<br>Because of the controllability of the life cycle of threads, asynchronous tasks, and so on, it becomes another source of memory leaks. In the ordinary, because of its frequent use, so we should treat it with Caution.</p></p> <ul> <ul> <li>At the end of the activity, the created thread should be destroyed in a timely manner. otherwise, when the thread holds a reference to the activity, it actually thinks that the activity is exited, in fact, because the thread is not completed, the referenced old activity is not destroyed, there is a memory leak, so can use Thread.Interrupt () in the thread, It's not a real interruption! Detailed visibility of the interrupt mechanism of the thread (interrupt)</li> <li>Asynctask the life cycle of an asynchronous task is not controllable. Be sure to pay attention to one thing, because it's easy to create Asynctask as an inner class in the activity, and it's very convenient to do some time-consuming and ui-interactive operations, but this is a big risk because of the memory leaks. Asynchronous tasks are built with Threadpoolexcutor as the implementation mechanism, so that the thread object life cycle is uncertain!! There are two solutions on the Web: 1. Change the internal class of a thread to a static inner class (not tried, not Known) 2. A weak reference is used to hold the context reference inside the inline thread. As shown in the following code:</li> </ul> </ul><pre class="prettyprint"><code class=" hljs scala">Public<span class="hljs-keyword"><span class="hljs-keyword">Abstract</span></span> <span class="hljs-class"><span class="hljs-class"> <span class="hljs-keyword">class</span> <span class="hljs-title">weakasynctask</span><<span class="hljs-title">Params</span>, <span class="hljs-title">Progress</span>, <span class="hljs-title">Result</span>, <span class="hljs-title">weaktarget </span>> <span class="hljs-keyword">extends</span><span class="hljs-title">asynctask</span><<span class="hljs-title">Params</span>, <span class="hljs-title">Progress</span>, <span class="hljs-title">Result</span>> { </span></span> <span class="hljs-keyword"><span class="hljs-keyword">protected</span></span>Weakreference<weaktarget> mtarget; Public Weakasynctask (weaktarget Target) {mtarget =<span class="hljs-keyword"><span class="hljs-keyword">New</span></span>Weakreference<weaktarget> (target); }<span class="hljs-javadoc"><span class="hljs-javadoc">/** {<span class="hljs-javadoctag">@inheritDoc</span>} *</span> /</span> <span class="hljs-annotation"><span class="hljs-annotation">@Override</span></span> <span class="hljs-keyword"><span class="hljs-keyword">protected</span></span> <span class="hljs-keyword"><span class="hljs-keyword">Final</span></span>void OnPreExecute () {<span class="hljs-keyword"><span class="hljs-keyword">Final</span></span>Weaktarget target = Mtarget.get ();<span class="hljs-keyword"><span class="hljs-keyword">if</span></span>(target! =<span class="hljs-keyword"><span class="hljs-keyword">NULL</span></span>) {<span class="hljs-keyword"><span class="hljs-keyword"></span> this</span>. OnPreExecute (target); } }<span class="hljs-javadoc"><span class="hljs-javadoc">/** {<span class="hljs-javadoctag">@inheritDoc</span>} *</span> /</span> <span class="hljs-annotation"><span class="hljs-annotation">@Override</span></span> <span class="hljs-keyword"><span class="hljs-keyword">protected</span></span> <span class="hljs-keyword"><span class="hljs-keyword">Final</span></span>Result doinbackground (params ... params) {<span class="hljs-keyword"><span class="hljs-keyword">Final</span></span>Weaktarget target = Mtarget.get ();<span class="hljs-keyword"><span class="hljs-keyword">if</span></span>(target! =<span class="hljs-keyword"><span class="hljs-keyword">NULL</span></span>) {<span class="hljs-keyword"><span class="hljs-keyword">return</span></span> <span class="hljs-keyword"><span class="hljs-keyword"></span> this</span>. Doinbackground (target, params); }<span class="hljs-keyword"><span class="hljs-keyword">Else</span></span>{<span class="hljs-keyword"><span class="hljs-keyword">return</span></span> <span class="hljs-keyword"><span class="hljs-keyword">NULL</span></span>; } }<span class="hljs-javadoc"><span class="hljs-javadoc">/** {<span class="hljs-javadoctag">@inheritDoc</span>} *</span> /</span> <span class="hljs-annotation"><span class="hljs-annotation">@Override</span></span> <span class="hljs-keyword"><span class="hljs-keyword">protected</span></span> <span class="hljs-keyword"><span class="hljs-keyword">Final</span></span>void OnPostExecute (result Result) {<span class="hljs-keyword"><span class="hljs-keyword">Final</span></span>Weaktarget target = Mtarget.get ();<span class="hljs-keyword"><span class="hljs-keyword">if</span></span>(target! =<span class="hljs-keyword"><span class="hljs-keyword">NULL</span></span>) {<span class="hljs-keyword"><span class="hljs-keyword"></span> this</span>. OnPostExecute (target, result); } }<span class="hljs-keyword"><span class="hljs-keyword">protected</span></span>void OnPreExecute (weaktarget Target) {<span class="hljs-comment"><span class="hljs-comment">//No Default Action</span></span>}<span class="hljs-keyword"><span class="hljs-keyword">protected</span></span> <span class="hljs-keyword"><span class="hljs-keyword">Abstract</span></span>Result doinbackground (weaktarget target, params ... params);<span class="hljs-keyword"><span class="hljs-keyword">protected</span></span>void OnPostExecute (weaktarget target, result Result) {<span class="hljs-comment"><span class="hljs-comment">//No Default Action</span></span>} }</code></pre><p><p>There are many areas of memory optimization that need to be complemented, and efforts are Needed.</p></p><p><p><strong>Four. Memory Analysis</strong><br>Whether it's analysis of memory usage or troubleshooting memory leaks, I recommend<br>To take a good look at the following great God's article, I believe that after watching, there will be a great harvest, I am so =. =</p></p> <ul> <ul> <li>How to analyze memory leaks in Android</li> <li>Android Best performance Practice (ii)--analyze memory usage</li> </ul> </ul><p><p>This is recorded for later Re-reading.</p></p> <p style="font-size:12px;"><p style="font-size:12px;">Copyright Notice: This article for Bo Master original article, without Bo Master permission not Reproduced.</p></p> <p><p>Android memory leaks and optimizations, as well as the Mat tool</p></p></span>