Image caching, gesture and oom analysis of Android Development Notes
The three themes of picture caching, gestures and oom are put together because these three issues are often linked in the process of Android application development. First, the preview of the large image needs to support gestures, zooming, rotation, translation and other operations; Secondly, pictures need to be cached locally to avoid frequent access to the network; Finally, the image (bitmap) is a large memory user in Android. When dealing with high-definition large images, the memory consumption is very large. If you are not careful, the system will report an oom error.
Fortunately, these three themes are common problems in Android development, and there are many general open source solutions for them. Therefore, this paper mainly explains some third-party open source libraries used by the author in the development process. The main contents are as follows:
1. Comparison and use of universal image loader, Picasso, glass and fresco 2. Principle and use of photoview and gestureimageview 3. Leakcanry memory analysis tool
--------------------------------------------------------------------------------
1、 Comparison and use of universal image loader, Picasso, glass and fresco
Universal image loader (UIL), Picasso, glass and fresco are common third-party libraries for image loading in Android. They mainly encapsulate methods such as memory cache, disk cache, network request cache and thread pool, abstract the process of image loading, largely avoid memory overflow caused by image loading, and improve the efficiency of image loading. The following figure shows the information recently queried by the author from the GitHub page of each library:
It should be noted that:
• imageloader is the earliest open source image cache library, and the author has stopped maintenance (11.27); • The actual author of Picasso is Jake Wharton of square, an absolute bull in the Android field; • Glide is open source by Google employees and is recommended for use in Google I / O 2014 official applications; • Fresco's image loading does not use Java heap memory, but anonymous shared memory (ashmem).
Attach the GitHub address of each library:
Universal Image Loader： https://github.com/nostra13/Android-Universal-Image-Loader.git
Picasso： https://github.com/square/picasso.git
Glide： https://github.com/bumptech/glide.git
Fresco： https://github.com/facebook/fresco.git
The basic use of the four picture cache libraries (HelloWorld) can be realized through one sentence of code, as follows:
UIL：
ImageLoader.getInstance().displayImage(url,imageView);
Picasso：
Picasso.with(context).load(url).into(imageView);
Glide：
Glide.with(context).load(url).into(imageView);
Fresco：
simpleDraweeView.setImageURI(uri);
Careful friends can see that the APIs of Picasso and glass are very similar. In fact, the core ideas of the four libraries are similar, which can be abstracted into the following five modules:
1. Requestmanager, mainly responsible for request generation and management module; 2. Engine, mainly responsible for creating tasks and executing scheduling; 3. Getdatainterface, the interface for obtaining data, is mainly used to obtain picture data from memory cache, disk cache and network; 4. The displayer is mainly used to display pictures, which may be the encapsulation of ImageView or other virtual displayer; 5. Processor is mainly responsible for processing images, such as image rotation, compression and interception.
As an aside, after mastering the core idea of the implementation of various open source libraries, you will find that one thing software engineering has in common is to improve efficiency by formalizing and abstracting processes. Whether it is business efficiency or development efficiency, this may also be the core idea of software as a science.
Design and advantages of imageloader
The loading process of imageloader is shown in the following figure. (it should be stated that the following three flow charts are from trinea and respect the copyright of the original author)
The imageloader receives the task of loading and displaying pictures, and the imageloader engine distributes the task. After obtaining the picture data, the bitmapdisplayer displays it in imageaware.
The advantages of imageloader are:
• support download progress monitoring • you can pause picture loading in view scrolling, and pause picture loading in view scrolling through pauseonscolllistener interface. • A variety of memory caching algorithms are implemented by default. These image caches can be configured with caching algorithms. However, imageloader implements many caching algorithms by default, such as delete first when the size is the largest, delete first when the use is the least, delete last, delete first, delete first when the time is the longest, etc.
• support local cache file name rule definition
Design and advantages of Picasso
The loading process of Picasso is as follows:
Picasso receives the task of loading and displaying pictures. The dispatcher is responsible for distribution and processing. The pictures are obtained through memorycache and handler and displayed in the target through picassodrawable.
Advantages of Picasso:
• the built-in statistical monitoring function supports the monitoring of picture cache usage, including cache hit rate, used memory size, saved traffic, etc. • Priority processing is supported. Tasks with high priority will be selected before task scheduling. For example, when the priority of banner in the app page is higher than icon, it is very applicable. • It supports delaying the loading until the image size calculation is completed. It supports that the flight mode and the number of concurrent threads change according to the network type. When the mobile phone switches to the flight mode or the network type changes, the maximum concurrency of the route pool will be automatically adjusted. For example, the maximum concurrency of WiFi is 4, 4G is 3, 3G is 2. Here, Picasso determines the maximum concurrent number according to the network type, not the number of CPU cores.
• "no" local cache does not mean that there is no local cache, but Picasso has not implemented it and handed it to another network library okhttp of square. The advantage is that the expiration time of pictures can be controlled by requesting cache control and expired in the response header.
Design and advantages of glide
The loading process of glide is as follows:
Glide receives the task of loading and displaying resources. The engine processes the request, obtains the data through the fetcher, and sends it to the target for display after transformation.
Advantages of glide:
(1) Picture cache - > media cache glide is not only a picture cache, but also supports GIF, webp and thumbnails. Even video, so it should be used as a media cache.
(2) Support priority processing
(3) Consistent with the activity / fragment life cycle, it supports trimmemory glide, maintains a requestmanager for each context, maintains consistency with the activity / fragment life cycle through fragmenttransaction, and has a corresponding trimmemory interface to call.
(4) Okhttp and volley glide are supported. By default, data is obtained through urlconnection, which can be used with okhttp or volley. The actual imageloader and Picasso also support okhttp and volley.
(5) Memory friendly ① glide's memory cache has an active design. When fetching data from the memory cache, it uses remove instead of get. Then put the cached data into an active resources map with value as soft reference, count the number of references, judge after the picture is loaded, and recycle it if the reference count is empty.
② The memory cache is smaller, and the picture glide takes the URL, viewwidth, viewweight, screen resolution, etc. as the joint key to cache the processed picture in the memory cache instead of the original picture to save size
③ Consistent with the activity / fragment lifecycle, trimmemory is supported
④ The default image is rgb565 instead of argb888. Although the definition is poor, the image is smaller and can also be configured to ARGB_ 888。
Others: glide can support URL expiration through signature or without local cache
About fresco
Fresco library is open source late, and there is no official version 1.0 yet. However, its functions are more powerful than the first three libraries, such as:
• the image storage system anonymous shared memory ashmem (anonymous shared memory) does not allocate Java heap memory, so image loading will not cause heap memory jitter; • JPEG image stream loading (first display the image outline, and then slowly load the clear image); • More perfect image processing and display mode; • JPEG image native transform size to avoid oom
The anonymous shared memory ashmem of the system will be described in detail in a subsequent article on the memory use of Android. Here is only a brief introduction:
In the Android system, the memory in ashmem does not belong to Java heap or native heap. When a memory space in ashmem seems to be released, it will be notified through the system call unpin. But in fact, the data in this memory space has not been really erased. If the Android system finds that the memory is tight, it will use the unpin memory space to store the required data. The unpin memory space can be re pinned. If the memory space is not used by others at this time, the process of re writing data to ashmem is saved. Therefore, the working principle of ashmem is a delayed release.
In addition, to learn ashmem, please refer to master Luo Shengyang's blog:
1. Brief introduction and learning plan of Android anonymous shared memory 2. Source code analysis of Android anonymous shared memory driver 3. Principle analysis of Android anonymous shared memory sharing between processes
2、 Principle and application of photoview and gestureimageview
A typical scenario where you need to use the above third-party open source library to load pictures is to click to view the large picture. The large image supports gesture scaling, rotation, translation and other operations. There are many methods for gesture scaling in ImageView. Most open source custom scaling is implemented by modifying the OnDraw function. However, ImageView itself has a scaletype attribute, and the scaling function can be easily realized by setting Android: scaletype = "matrix". The advantage of scaling is that it is simple to implement. At the same time, there will be no flicker in the scaling process because the OnDraw function is not called repeatedly. In addition, it should be noted that scaletype controls the zoom mode of the picture, which refers to the resource rather than the background. In other words, Android: SRC = "@ drawable / ic_launcher", rather than Android: background = "@ drawable / ic_launcher".
Many open source implementations can be found on GitHub. Here are two examples to illustrate.
Photoview address: https://github.com/bm-x/PhotoView.git
Gestureimageview address: https://github.com/jasonpolites/gesture-imageview.git
Introduction to photoview:
1. Add dependency to gradle (recommended)
(or you can download the project and copy the info.java and photoview.java files into your project, which is not recommended) - this method is applicable to eclipse.
2. XML add
3. Java code
The implementation of photoview is basically consistent with the above principles, which will not be repeated here. The implementation of custom controls will be analyzed in detail in subsequent articles.
The introduction of gestureimageview is as follows:
1.Configured as View in layout.xml
code:
2.Configured Programmatically
code:
The principle is basically the same as that of photoview and will not be repeated.
3、 Oom analysis tool -- leakcanary
Introduction to leakcanary:
A memory leak detection library for Android and Java.
It can be seen that leakcanary is mainly used to detect that various memory cannot be GC, resulting in leakage.
Leakcanary's address https://github.com/square/leakcanary.git
Demo address:
https://github.com/liaohuqiu/leakcanary-demo.git （AS）
https://github.com/teffy/LeakcanarySample-Eclipse.git （Eclipse）
The following is a screenshot of the memory leak caused by the failure to recycle because the textview in the testactivity in the demo is referenced by a static variable.
Leakcanary is easy to use. First, add dependent projects:
Secondly, initialize in the oncreate () method of application.
After these two steps, you can use it. Leakcanary. Install (this) will return a predefined refwatcher and enable an activityrefwatcher to automatically monitor the activity leaked after calling activity. Ondestroy(). If you need to listen to a fragment, register in the ondestroy () method of the fragment:
Of course, you need to listen to a variable and directly watch it.
It should be noted that using leakcanary in eclipse requires a declaration of heap occupancy analysis and displayed services in the androidmanifest file:
Note: heapananalyzerservice adopts multi process Android: process = ": leakcanary".
The use of the above open source tools is relatively simple. For details, please refer to their GitHub address.
4、 Some messy summary
Common causes of memory leaks:
• static objects: listener, broadcast, WebView; • This $0: thread, timer, handler; • System: textline, input method, audio
Reclaim memory:
A leaked activity will cause the bitmap / drawingcache referenced by the activity to be unable to be released. Recycling refers to trying to recycle the resources held by the leaked activity. In ondestroy, starting from rootview, recursively release all resources related to sub views, such as pictures, backgrounds, drawingcache, listeners, etc.
Ways to reduce runtime memory:
1. Reduce the memory occupied by bitmap: 1) prevent bitmap from occupying too much resources. 2. X system opens innativealloc in bitmapfactory.options; 4. X system uses Facebook's fresco library to put picture resources in native. 2) The picture is loaded on demand, and the size of the picture should not exceed the size of the view. 3) Unified bitmap loader: Picasso / fresco. 4) There is pixel waste in the picture.
2. Self memory usage monitoring: 1) implementation principle: obtain maxmemory through runtime, and totalmemory freememory is the Dalvik memory actually used at present. 2) Operation method: check this value regularly and release various cache resources (bitmap cache) when it reaches 80%
3. Use multiple processes. For WebView, gallery, etc., due to memory system leakage, a separate process can be used.