Android效能優化之巧用軟引用與弱引用優化記憶體使用

總李寫程式碼發表於2016-10-20

前言:

      從事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的效能的話,我們可以把哪些不常用並且佔用記憶體比較大的物件用軟引用或者弱引用來做快取處理,鑑於保險起見,可以酌情選擇使用弱引用還是軟引用,實測下來二者被回收的概率相差無幾。

相關文章