Android Memory Management (continued) and android Memory Management

Android Memory Management (continued) and android Memory Management
The previous article explains OOM in memory management and how to avoid Memory leakage, in this article, code optimization and image management are continued. 3. code optimization 1. code optimization 2. Recycling invisible interface resources. Here I want to talk about fragment. fragment destruction is only the destruction of the interface, the data will still be stored in the memory. When the fragment is switched, the ui of the previous fragment will be destroyed, but the data will not be lost. Therefore, when a fragment is no longer needed, try to clear the data as much as possible. 3. Layout Optimization try to replace the multi-level structure with the view parameters to reduce unnecessary node merge.
Modular layout include: Reuse a layout file as much as possible to reduce future maintenance work 4. Reusing memory listview is a typical reuse.
4. Most of the oom in image management development are image problems. In some cases, the number of images displayed by the application is large and not in the resource file. Images cannot be obtained as in the resource source file. You need to manually decode the images. 1. bitmapfactory provides a series of decode methods for decoding large images, which consume a lot of time and space, therefore, decode a large image first. 2. a thumbnail is a solution. First, a thumbnail is provided. After clicking it, the source image is displayed. Can the scaled bitmap be loaded at the beginning? Can we get a proper scaling ratio?
3. Extreme time consumption of image memory cache and external memory cache: consumption of decoding and space consumption of user experience: oom compromise solution: all images are resident in memory but cannot exceed a certain size (1/2 of oom or vm). 4. After the soft reference is made from 2.3, GC is put into other threads and the memory will be recycled more actively, especially after soft reference and weak reference lruCache: 2.3, which is included in the v4 package, is used in a similar way as map and maintains key and value, in the end, the memory usage is maintained at a fixed value. 5. The heapsize of the image is only described as memory usage in the Virtual Machine. Before 3.0, bitmap objects also need to occupy native layer memory, this part of memory monitoring is difficult and the recovery time is not necessarily, so we need to use recycle (), and then we can no longer use it, in order to tell the c layer to release as soon as possible