Android性能優化之巧用軟引用與弱引用優化內存使用

前言：

      從事Android開發的同窗都知道移動設備的內存使用是很是敏感的話題，今天咱們來看下如何使用軟引用與弱引用來優化內存使用。下面來理解幾個概念。

1.StrongReference（強引用）

   強引用是咱們最最多見的一種，通常咱們在代碼中直接經過new出來的對象等，都是強引用，強引用只要存在沒有被銷燬，內存就不會被系統回收。咱們以生成Bitmap爲例以下:

Bitmap imageBitmap = readBitmapFromResource(getResources(), R.mipmap.bg_post_activity_5);

  生成Bitmap代碼：

    public Bitmap readBitmapFromResource(Resources resources, int resourcesId) {
        BitmapFactory.Options options = new BitmapFactory.Options();
        return BitmapFactory.decodeResource(resources, resourcesId, options);
    }

2.SoftReference（軟引用）

  軟引用是用來描述一些有用但並非必需的對象，在內存嚴重不足的狀況下會被系統回收，若是該對象可能會常常使用的，就儘可能用軟引用。所以，這一點能夠很好地用來解決OOM的問題，而且這個特性很適合用來實現緩存：好比網頁緩存、圖片緩存等。這裏仍是以緩存Bitmap爲例：

 SoftReference<Bitmap> softReference = new SoftReference<Bitmap>(readBitmapFromResource(getResources(), R.mipmap.bg_post_activity_5));
 Bitmap bitmap = softReference.get();

3.WeakReference（弱引用）

  弱引用也是用來描述非必需對象的，當JVM進行垃圾回收時，不管內存是否充足，都會回收被弱引用關聯的對象，WeakReference 的強度又明顯低於 SoftReference，因此若是該對象不被使用的可能性更大些，就能夠用弱引用。仍是以緩存Bitmap爲例：

 WeakReference<Bitmap> weakReference = new WeakReference<Bitmap>(readBitmapFromResource(getResources(), R.mipmap.bg_post_activity_5));
 Bitmap bitmap1 = weakReference.get();

4.PhantomReference（虛引用）

 虛引用和前面的軟引用、弱引用不一樣，它並不影響對象的生命週期。若是一個對象與虛引用關聯，則跟沒有引用與之關聯同樣，在任什麼時候候均可能被垃圾回收器回收。仍是以緩存Bitmap爲例：

 ReferenceQueue<Bitmap> queue = new ReferenceQueue<Bitmap>();
 PhantomReference<Bitmap>  phantomReference = new PhantomReference<Bitmap>(readBitmapFromResource(getResources(), R.mipmap.bg_post_activity_5),queue);
 Bitmap bitmap2 = phantomReference.get();

5.幾種引用被回收概念測試

  從上面的分析能夠看出內存被系統回收的機率從小到大是：虛引用--弱引用--軟引用--強引用，咱們寫個程序來驗證一下。

public class MainActivity extends AppCompatActivity {
    private LinearLayout request_layout;
    private PhantomReference<Bitmap> phantomReference;
    private WeakReference<Bitmap> weakReference;
    private SoftReference<Bitmap> softReference;
    private Bitmap strongReference;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        request_layout = (LinearLayout) findViewById(R.id.request_layout);

        findViewById(R.id.request_btn).setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View v) {
                testReference();
            }
        });
    }

    private void testReference() {
        //模擬內存使用 往一個佈局中不斷加入ImageView來模擬內存使用
        ImageView imageView = new ImageView(this);
        Bitmap imageBitmap = readBitmapFromResource(getResources(), R.mipmap.bg_post_activity_5);
        imageView.setImageBitmap(imageBitmap);
        request_layout.addView(imageView);

        if (strongReference == null) {
            strongReference = readBitmapFromResource(getResources(), R.mipmap.bg_post_activity_5);
        }
        Log.e("Reference", "StrongReference---->" + strongReference);
        if (softReference == null) {
            softReference = new SoftReference<Bitmap>(readBitmapFromResource(getResources(), R.mipmap.bg_post_activity_5));
        }
        Bitmap bitmap = softReference.get();
        Log.e("Reference", "SoftReference---->" + bitmap);

        if (weakReference == null) {
            weakReference = new WeakReference<Bitmap>(readBitmapFromResource(getResources(), R.mipmap.bg_post_activity_5));
        }
        Bitmap bitmap1 = weakReference.get();
        Log.e("Reference", "WeakReference---->" + bitmap1);

        if (phantomReference == null) {
            ReferenceQueue<Bitmap> queue = new ReferenceQueue<Bitmap>();
            phantomReference = new PhantomReference<Bitmap>(readBitmapFromResource(getResources(), R.mipmap.bg_post_activity_5), queue);
        }
        Bitmap bitmap2 = phantomReference.get();
        Log.e("Reference", "PhantomReference---->" + bitmap2);
    }

    public Bitmap readBitmapFromResource(Resources resources, int resourcesId) {
        BitmapFactory.Options options = new BitmapFactory.Options();
        return BitmapFactory.decodeResource(resources, resourcesId, options);
    }

}

第一次點擊打印信息：

經過打印信息能夠虛引用直接回收掉了，或者能夠說直接不存在引用。

接下來屢次點擊打印信息：

  在模擬內存使用愈來愈緊張的狀況下，並無出現先回收弱引用，再回收軟引用，而是兩個一併回收掉了，其實按照Java正常引用順序是軟引用強於弱引用，可是從 Android 2.3 (API Level 9)開始，垃圾回收器會更傾向於回收持有軟引用或弱引用的對象，這讓軟引用像弱引用同樣變得再也不可靠。因此圖片緩存再也不使用軟引用而採用LRU算法。可是強引用一直毅力不倒。

 總結：

   從上面的介紹及測試對比能夠得知，若是咱們比較在乎APP的性能的話，咱們能夠把哪些不經常使用而且佔用內存比較大的對象用軟引用或者弱引用來作緩存處理，鑑於保險起見，能夠酌情選擇使用弱引用仍是軟引用，實測下來兩者被回收的機率相差無幾。