Android的GC機(jī)制是可達(dá)性回收弛饭，具體本文就不再具體闡述了，本文只分析android系統(tǒng)什么時(shí)候會(huì)觸發(fā)GC萍歉，以及監(jiān)聽(tīng)Object對(duì)象被回收的時(shí)機(jī)：

先看下面的代碼的注釋?zhuān)让靼孜艺f(shuō)的全局變量 局部變量 說(shuō)的是什么意思

class DetailActivity : AppCompatActivity() {
    //這個(gè)house就是全局變量
    private var house: House? = null
  
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_detail)
        //這個(gè)person就是局部變量
        val person = Person()
      }
  
     findViewById<TextView>(R.id.button).setOnClickListener { v->
            //這個(gè)person2就是局部變量
            person2 = Person()
            Log.e("dq","create Person "+person2!!.hashCode());
        }
}

• 1侣颂、Activity中定義的全局變量，如果不為null枪孩，那么只能在 Activity 的onDestory()的5秒后被GC釋放內(nèi)存憔晒，xml里的View的內(nèi)存機(jī)制也是一樣 無(wú)論你有沒(méi)有把View設(shè)置為全局變量
• Activity中定義的全局變量如果被你 = null，那么他的生命周期和局部變量是一樣的蔑舞，都是在觸發(fā)GC的時(shí)候會(huì)釋放內(nèi)存
• 很多手機(jī)拒担，你用代碼主動(dòng)調(diào)用System.gc() 毫無(wú)效果
• 如果內(nèi)存不緊張，那么系統(tǒng)會(huì)在當(dāng)前Activity走了生命周期方法（比如onPause攻询、onDestory）后再過(guò)5从撼、6秒觸發(fā)GC（onDestory后5秒是一定會(huì)GC的，home回到桌面會(huì)走onPause再過(guò)5秒也會(huì)GC钧栖。但是再回來(lái)走onResume就不GC了）
• onDestory的5秒后觸發(fā)了GC低零，Activity和全局變量才徹底被回收（即：WeakReference.get() == null）
• 系統(tǒng)觸發(fā)GC有時(shí)候會(huì)在logcat里打印，有時(shí)候不會(huì)拯杠，雖然GC會(huì) stop 所有線(xiàn)程掏婶，但是簡(jiǎn)單的GC 的pause的時(shí)長(zhǎng)只有5ms，0.0004秒

com.dq.qkotlin: Background young concurrent copying GC freed 58306(1766KB) AllocSpace objects, 4(68KB) LOS objects, 32% free, 3959KB/5892KB, paused 5.216ms total 23.590ms

• 所以GC比你想象中頻繁的多
• 如果你的Object比較簡(jiǎn)單潭陪，里面就包含幾個(gè)String雄妥，int最蕾。那么這個(gè)Object占用的內(nèi)存非常少，10000個(gè)Object只占用2M的內(nèi)存老厌，我當(dāng)時(shí)輪詢(xún)創(chuàng)建了1000多個(gè)局部變量Object瘟则，都沒(méi)觸發(fā)系統(tǒng)GC。也就是說(shuō)這1000多個(gè)局部變量Object都在內(nèi)存里沒(méi)釋放
• 即便如此枝秤，還是不建議你瘋狂的創(chuàng)建局部變量醋拧，因?yàn)榭赡艹霈F(xiàn)無(wú)連續(xù)可用內(nèi)存而導(dǎo)致oom
• 如果你創(chuàng)建的局部變量非常大，就會(huì)"驚動(dòng)"系統(tǒng)宿百，系統(tǒng)會(huì)主動(dòng)觸發(fā)GC來(lái)回收局部變量

意外發(fā)現(xiàn)

• 我研究發(fā)現(xiàn)趁仙，如果我來(lái)回頻繁的上下滾動(dòng)RecyclerView或ListView（即便滾動(dòng)的距離非常短，沒(méi)觸發(fā)ViewHolder的復(fù)用）垦页。就僅僅是手指在屏幕上快速的上下戳動(dòng)10秒左右雀费，也會(huì)觸發(fā)GC（而且當(dāng)時(shí)我并沒(méi)有new Object()

• 這是唯一我發(fā)現(xiàn)的 Activity生命周期沒(méi)改變 且 內(nèi)存占用不緊張 的情況下也會(huì)觸發(fā)GC的場(chǎng)景，推測(cè)可能是android底層自己處理的

• 存儲(chǔ)同樣的數(shù)據(jù)痊焊，HashMap的內(nèi)存占用約等于Model的3倍盏袄，我原本以為會(huì)是17倍左右，畢竟他底層是個(gè)int[16] 薄啥。但是實(shí)際測(cè)試只是3倍左右

//每調(diào)用一次創(chuàng)建十萬(wàn)個(gè)對(duì)象辕羽，檢測(cè)內(nèi)存變化
                for (int i = 0; i < 100000; i++) {
                    linklist.add(new Object()); //內(nèi)存變化：73M - 76M - 79M  - 82M
                    linklist.add(new HashMap<String,String>()); //內(nèi)存變化：79M - 85M - 91M

                    GiftBean bean = new GiftBean();
                    bean.setTitle("1");
                    linklist.add(bean); //71M - 77M - 83M - 88M - 94M = 每次差額為6M

                    HashMap<String,String> map = new HashMap<String,String>();
                    map.put("title","1");
                    linklist.add(map); //72M - 88M - 105M - 121M = 每次差額為17M
                }

如何監(jiān)聽(tīng)變量生命周期？

class Person : Object() {

    var name: String? = null

    //走了finalize方法就說(shuō)明該Object被回收了
    @kotlin.jvm.Throws(Throwable::class)
    override fun finalize() {
        Log.e("dq","Person 被回收 " +hashCode())
    }
}

如何監(jiān)聽(tīng)系統(tǒng)GC垄惧？

public class GcWatcherInternal {

    private static WeakReference<GcWatcher> sGcWatcher;

    private static ArrayList<Runnable> sGcWatchers = new ArrayList<>();
    private static Object lock = new Object();

    private static final class GcWatcher {
        @Override
        protected void finalize() throws Throwable {
            sLastGcTime = SystemClock.uptimeMillis();
            ArrayList<Runnable> sTmpWatchers;
            synchronized (lock) {
                sTmpWatchers = sGcWatchers;
                try {
                    for (int i = 0; i < sTmpWatchers.size(); i++) {
                        if (sTmpWatchers.get(i) != null) {
                            sTmpWatchers.get(i).run();
                        }
                    }
                } catch (Throwable e){
                    e.printStackTrace();
                }
                sGcWatcher = new WeakReference<>(new GcWatcher());
            }
        }
    }

    public static void addGcWatcher(Runnable watcher) {
        synchronized (lock) {
            sGcWatchers.add(watcher);
            if(sGcWatcher==null)
                sGcWatcher = new WeakReference<>(new GcWatcher());
        }
    }
}

//MainActivity中寫(xiě)一次就好
GcWatcherInternal.addGcWatcher { Log.e("dq","觸發(fā)GC ５笤浮！到逊！") }

我們可以怎么優(yōu)化內(nèi)存

網(wǎng)上別人寫(xiě)的什么bitmap铣口、handle內(nèi)存泄漏、靜態(tài)單例 一堆亂七八糟的東西觉壶，我在這里就不寫(xiě)了脑题。我就只針對(duì)上述我自己的研究成果說(shuō)一下我自己的看法

• 在Activity\Fragment中，無(wú)論你是否把View設(shè)為全局變量铜靶，View的生命周期都是一樣的叔遂。所以性能和內(nèi)存占用是一樣的。

• 在Activity\Fragment中争剿，沒(méi)必要設(shè)為全局變量的已艰，盡量使用局部變量，不要設(shè)為全局變量：

• 主觀原因是：全局變量會(huì)讓邏輯混亂秒梅，Activity代碼看起來(lái)臟旗芬，別人接手你的代碼容易改錯(cuò)。

• 客觀原因是：只要Activity不死捆蜀，全局變量不會(huì)被GC回收內(nèi)存。如果你用局部變量，那么Activity只要走了任何生命周期（比如onCreate辆它、onPause誊薄、onResume），這個(gè)局部變量的內(nèi)存就被釋放了锰茉。

• 確定不再需要用的全局變量呢蔫，可以用代碼設(shè)置為 = null，這樣也會(huì)被及時(shí)GC回收飒筑。同理片吊，全局變量中的全局變量，如果不需要用到了协屡，也可以 = null俏脊。比如 this.house.image = null 。

• 有一些listview\recyclerView肤晓，你為了更好的顯示爷贫，不得不在model里新加你自己定義的對(duì)象。最典型的比如聊天界面的表情SpannableString补憾，但是要注意到如果你把SpannableString放到model中漫萄，他就不會(huì)被GC釋放，特別是SpannableString里帶ImageSpan的（一般是表情）盈匾，就會(huì)比較占內(nèi)存且不會(huì)被GC

• 建議的解決辦法：可以用LRUCache腾务，或者你新建一個(gè)SpareArray<SpannableString>，只緩存最后20條左右的SpannableString削饵。
  也可以最簡(jiǎn)單粗暴的 把過(guò)早的信息的Model里的spannableString = null岩瘦。萬(wàn)一用戶(hù)手動(dòng)翻到最早的聊天記錄，你再重新拼接spannableString葵孤。

• 你要是實(shí)在覺(jué)得無(wú)所謂担钮，覺(jué)得你們app用戶(hù)量不大，可以用空間換時(shí)間尤仍，不處理這些問(wèn)題倒也沒(méi)太大問(wèn)題箫津。但是依然要注意ImageSpan（一般是表情）需要做成單一變量，不要每條聊天消息都new ImageSpan()

一些惡劣的代碼宰啦，以及會(huì)產(chǎn)生什么情況

事先聲明：網(wǎng)上別人寫(xiě)的什么handle內(nèi)存泄漏苏遥、靜態(tài)單例 一堆亂七八糟的東西，我在這里就不寫(xiě)了赡模。我就只針對(duì)上述我自己的研究成果說(shuō)一下我自己的看法

• 在無(wú)限循環(huán)的Thread里訪(fǎng)問(wèn)全局變量：由于你的Thread在無(wú)限循環(huán)田炭，所以Thread無(wú)法被回收這是正常的，可你在Thread里調(diào)用了Activity里的變量漓柑，會(huì)導(dǎo)致整個(gè)Activity無(wú)法被GC回收（包括Activity的全局變量也都無(wú)法回收） 教硫。然后關(guān)閉Activity叨吮，Activity走了onDestroy。這時(shí)候按道理5秒后會(huì)正常觸發(fā)GC回收Activity瞬矩。這時(shí)候嚴(yán)重的來(lái)了： 由于系統(tǒng)這次GC無(wú)法回收onDestroy（因?yàn)樗籺hread引用了）茶鉴。系統(tǒng)會(huì)每2.1秒GC一次，無(wú)限的嘗試去釋放這個(gè)Activity景用。代碼如下：

  
  
  image.png
• 對(duì)上面截圖的補(bǔ)充：
  1涵叮、把第148行換成最簡(jiǎn)單的 this@DetailActivity，也一樣會(huì)導(dǎo)致內(nèi)存泄漏：Activity和她的所有全局變量都無(wú)法釋放
  2伞插、每2.1秒GC一次割粮，是沖著想釋放Activity來(lái)的（并不是因?yàn)榻貓D中的sleep兩秒，這個(gè)2.1秒是系統(tǒng)固定的）
  3媚污、如果Activity還沒(méi)onDestory5秒舀瓢，那么上面代碼不會(huì)觸發(fā)GC
  3、如果Thead里的Runnable里不調(diào)用全局變量杠步，只打純粹的Log氢伟，那么不會(huì)觸發(fā)GC。大家都可以釋放
  4幽歼、所以以上代碼會(huì)導(dǎo)致：Activity無(wú)法釋放+每2.1秒就GC一次朵锣。
  5、事實(shí)上只要Activity無(wú)法被釋放甸私，無(wú)論處于什么原因诚些。系統(tǒng)都會(huì)在她onDestory5秒后，每2.1秒就GC一次

以下代碼是正常使用的情況皇型，他可以正常釋放：

    private val handler = MyHandler(this)

    private class MyHandler(context: Context) : Handler(Looper.getMainLooper()) {

        private val reference: WeakReference<Context> = WeakReference(context)

        override fun handleMessage(msg: Message) {

            val activity = reference.get() as DetailActivity?
          //經(jīng)過(guò)測(cè)試：onDestory后5秒觸發(fā)GC诬烹，然后就Activity = 0。且全局變量house也被釋放
            Log.e("dz","MyHandler收到消息 Activity = "+System.identityHashCode(activity));

            if (activity == null){
                return
            }

            when (msg.what) {
                1 -> {
                    Log.e("dz","MyHandler收到消息 且 Activity沒(méi)死 "+activity.house); //每0.4秒打印一次弃鸦，直到onDestory的5秒后觸發(fā)了GC绞吁，就會(huì)被上面的activity == null攔截
                    activity.handler.sendEmptyMessageDelayed(1 , 400)
                }
            }
        }
    }


    Thread(Runnable {
            Thread.sleep(2000)
             Log.e("dz","給activity 扔 start " +  house.hashCode() +" Activity = "+ this@DetailActivity.hashCode());
                  //LOG：給activity 扔 start 210397411 Activity = 237971341
             handler.sendEmptyMessageDelayed(1 , 400)
     }).start()