Android--bitmap

GC is Java Virtual machine JVM garbage collection second, optimization

1. Bitmap optimization
   Bitmap is very memory-intensive, and in Android, when reading bitmap, the picture stack that is generally assigned to a virtual machine is only 8M, so it often causes oom problems. It is therefore necessary to optimize for the use of bitmap:

   • Picture display: Load a picture of the appropriate size, such as where thumbnails are displayed do not load large images.
   • Picture Recycling: Use the Bitmap, and use bitmap.recycle () to recycle it in a timely manner.

     Question: Is Android not itself a garbage collection mechanism? Why you should manually recycle here. The
     Bitmap object was not created by new, but was produced by Bitmapfactory. And the source can be found to be by calling Jni to generate bitmap objects ( Nativedecodestream () and other methods ). So, loading bitmap into memory consists of two parts, Dalvik memory and Linux kernel memory . The former will be automatically reclaimed by the virtual machine. The latter must pass the recycle () method, internally calling Nativerecycle () to have the Linux kernel recycled.

   • captures the OOM exception: The program sets up an emergency treatment for oom if it occurs.
   • Picture cache: Memory cache , hard disk cache , and so on
   • picture compression: Using ImageView to display bitmap is a lot of resources, especially when the picture is large and prone to oom. You can use bitmapfactory.options to compress a picture.
   • picture pixels: The android default color mode is argb_8888 , which displays the highest quality and consumes the most memory. If the requirements are not high, you can use the rgb_565 mode. picture size: Picture length * Width * Number of bytes occupied per pixel
     argb_4444: Consumes 2byte of memory per pixel
     argb_8888:4byte memory per pixel (default)
     rgb_565:2byte memory per pixel

3. Object reference type

   • 强引用 strong: Object object=new Object() . When memory is low, the Java virtual Machine prefers to throw an oom memory overflow exception, and it will not easily recycle the strongly referenced object to solve the memory shortage problem;
   • 软引用 soft: Only when the memory reaches a certain threshold, it is recycled, often used 缓存 ;
   • 弱引用 weak: It is recycled as long as the GC thread is scanned;
   • 虚引用
     If you want to 避免OOM happen, use the object, that is, 软引用 内存快不足时进行回收 if you want to, 尽快回收某些占用内存较大的对象 for example, bitmap, can be used 弱引用 , can be quickly recycled. However, if you want to cache bitmap, do not use weak references, because the GC will soon be recycled, resulting 缓存失败 .

   About the Java object reference type, specifically can participate in my other article

5. Pool Pools

   • Object pooling: If an object is created with a large resource overhead, you can put it in the object pool, save the object, and take it out the next time you need it, instead of creating the object again. Of course, maintaining the object pool also requires a certain amount of overhead, so it needs to be measured.
   • Thread pool: Similar to object pooling, place thread objects in a pool for reuse, reducing the overhead of repeatedly creating threads.

7. Cache

   About the android cache mechanism, specific to participate in my other article

Android--bitmap