597      阿裏雲  技術社區[雲棲]

提升Android下內存的使用意識和排查能力

     內存問題一直是大型App的開發人員比較頭痛的問題，特別是像手淘這種超級的App，App中到處都是帶有圖片和視頻的界麵，而且這些功能都是由不同的團隊甚至不同的事業部開發的，要整體上去管控和排查內存的問題變得相當的複雜。之前，我們多個線上版本都存在著嚴重的Activity等內存泄漏和不合理內存使用。這不是偶然，一個很重要的原因就是我們很多的開發測試人員側重業務開發，忽略內存和性能，而且沒有站在全局性的角度去考慮資源的使用。認為我自己的模塊多緩存一些就會加快速度，以空間換時間看似正確，但是在手淘這樣的超級App中是不可取的，需要嚴格限製，否則不要說裏麵幾百個模塊，有幾十個模塊這樣來做，其結果都會是災難性的，不但沒有加快速度，反而會拖慢速度以及帶來很多穩定性問題。

1、沒有強引用不代表這塊內存就會馬上回收

  void onButtonClick(){
        for (int i = 0; i < 1000; i++) {
            View view = new ImageView(this);
        }
    }

    在內存充足的情況下，我們點擊按鈕4次，執行了4遍該函數，這個時候可以看到堆內存呈現了4次增長。如下圖所示：


    靜置在那半個小時，內存仍然會維持現狀，VM並不會來執行實際的GC。我們可以Dump內存看看內存中的對象：

    通過手動觸發GC，我們可以來主動回收這塊內存，點擊如下圖所示的按鈕，觸發GC。

    當然，這裏還有一個問題存在，因為剛才創建的屬於Finalizer對象，該對象前麵的文章已經分析過，需要至少兩次GC才能真正回收其內存。所以，第一次觸發GC的時候，我們可以看一下內存的變化。

2、調用GC時的策略變化

    void onButtonClick(){
        for (int i = 0; i < 1000; i++) {
            View view = new ImageView(this);
        }
        System.gc();
    }

     在不同的Android版本上看下執行效果，點擊按鈕執行多次。在Android 4.4.4版本的設備上，內存基本已經回收，如果將1000次修改為10次，偶爾可以看到有ImageView已經沒有引用存在，但是仍然沒有回收。如下圖所示：



    從這裏可以看出來，在該版本下，大部分的對象在沒有強引用後，調用System.gc()就會被回收。我們再看下ART上的情況，在ART下，卻發生了不一致的表現。在調用後沒有進行GC。查看堆內存，我們也可以看到，4000個ImageView仍然存在，並未執行GC。

    /**
     * Indicates to the VM that it would be a good time to run the
     * garbage collector. Note that this is a hint only. There is no guarantee
     * that the garbage collector will actually be run.
     */
    public static void gc() {
        Runtime.getRuntime().gc();
    }

     我們可以看到，在調用gc函數後，直接調用了運行時的gc。再來看下5.0上的代碼：

    /**
     * Indicates to the VM that it would be a good time to run the
     * garbage collector. Note that this is a hint only. There is no guarantee
     * that the garbage collector will actually be run.
     */
    public static void gc() {
        boolean shouldRunGC;
        synchronized(lock) {
            shouldRunGC = justRanFinalization;
            if (shouldRunGC) {
                justRanFinalization = false;
            } else {
                runGC = true;
            }
        }
        if (shouldRunGC) {
            Runtime.getRuntime().gc();
        }
    }

   /**
     * Whether or not we need to do a GC before running the finalizers.
     */
    private static boolean runGC;
   /**
     * If we just ran finalization, we might want to do a GC to free the finalized objects.
     * This lets us do gc/runFinlization/gc sequences but prevents back to back System.gc().
     */
   private static boolean justRanFinalization;

    /**
     * Provides a hint to the VM that it would be useful to attempt
     * to perform any outstanding object finalization.
     */
    public static void runFinalization() {
        boolean shouldRunGC;
        synchronized(lock) {
            shouldRunGC = runGC;
            runGC = false;
        }
        if (shouldRunGC) {
            Runtime.getRuntime().gc();
        }
        Runtime.getRuntime().runFinalization();
        synchronized(lock) {
            justRanFinalization = true;
        }
    }

    void onButtonClick(){
        for (int i = 0; i < 2000; i++) {
            View view = new ImageView(this);
        }

       Runtime.getRuntime().gc();
    }

     這裏直接調用了Runtime.getRuntime().gc()。這個時候內存回收確實會有變化。但是Finalizer對象仍然可能存在，在Android 5.0的時候會回收一部分，但是從6.0開始，單次調用gc，Finalizer對象卻不一定回收。如下圖所示，雖然所有引用鏈路已經不複存在，但是內存仍然沒有回收：

    void onButtonClick(){
        for (int i = 0; i < 2000; i++) {
            View view = new ImageView(this);
        }

       Runtime.getRuntime().gc();
       Runtime.getRuntime().gc();
    }

     這裏連續2次調用了gc，按理是可以回收Finalizer對象的，但是由於兩次調用gc的間隔太短，而Finalizer對象是由專門的線程執行回收的，所以也不一定能完全回收。這個和線程的調度情況有關係。例如執行上麵代碼可能出現的結果是部分回收：

3、使用Android Studio的Memory分析內存占用

    public  class MyThread extends Thread{

        @Override
        public void run() {
            View view = new View(MainActivity.this);
            view = null;
        }
    }

    void onButtonClick(){
        new MyThread().start();
    }

     這裏隻是創建了一個該對象，但是也很容易可以跟蹤到該對象的內存情況。通過Memory Monitor的【Dump Java Heap】按鈕可以把當前堆內存顯示出來，如下圖所示：

    這裏是默認查看方式，我們可以切換到以包名的形式查看。這樣就可以很容易的找到我們自己的代碼了。如下所示：

   通過上圖我們可以清晰的看到，在ju包名下的內存分布情況。

4、排查內存泄漏

    對於Android Studio提供的內存分析工具，使用起來非常簡單，會比Mat工具要快捷，排查問題也更加容易。所以Android的開發和測試人員，應該盡可能的都遷移到該工具上來，並能夠熟練的掌握內存分析工具，這樣才能讓自己開發的模塊質量更加的優秀。

    以上主要是針對Android Studio 2中的使用方式，在今年的Android Studio 3 Preview版本中，內存這塊的分析工具更加強大，可以在麵板上直接看到更細粒度的內存占用，不僅僅是Java的對內存了。

最後更新：2017-10-20 15:33:37

  上一篇：  循環

  下一篇：  Android Unit Tests