Android 变量生命周期、变量内存释放机制、GC触发时机研究、内存优化建议

Android的GC机制是可达性回收，具体本文就不再具体阐述了，本文只分析android系统什么时候会触发GC，以及监听Object对象被回收的时机：

先看下面的代码的注释，先明白我说的全局变量 局部变量 说的是什么意思

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

• 1、Activity中定义的全局变量，如果不为null，那么只能在 Activity 的onDestory()的5秒后被GC释放内存，xml里的View的内存机制也是一样 无论你有没有把View设置为全局变量
• Activity中定义的全局变量如果被你 = null，那么他的生命周期和局部变量是一样的，都是在触发GC的时候会释放内存
• 很多手机，你用代码主动调用System.gc() 毫无效果
• 如果内存不紧张，那么系统会在当前Activity走了生命周期方法（比如onPause、onDestory）后再过5、6秒触发GC（onDestory后5秒是一定会GC的，home回到桌面会走onPause再过5秒也会GC。但是再回来走onResume就不GC了）
• onDestory的5秒后触发了GC，Activity和全局变量才彻底被回收（即：WeakReference.get() == null）
• 系统触发GC有时候会在logcat里打印，有时候不会，虽然GC会 stop 所有线程，但是简单的GC 的pause的时长只有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比较简单，里面就包含几个String，int。那么这个Object占用的内存非常少，10000个Object只占用2M的内存，我当时轮询创建了1000多个局部变量Object，都没触发系统GC。也就是说这1000多个局部变量Object都在内存里没释放
• 即便如此，还是不建议你疯狂的创建局部变量，因为可能出现无连续可用内存而导致oom
• 如果你创建的局部变量非常大，就会"惊动"系统，系统会主动触发GC来回收局部变量

意外发现

• 我研究发现，如果我来回频繁的上下滚动RecyclerView或ListView（即便滚动的距离非常短，没触发ViewHolder的复用）。就仅仅是手指在屏幕上快速的上下戳动10秒左右，也会触发GC（而且当时我并没有new Object()

• 这是唯一我发现的 Activity生命周期没改变 且 内存占用不紧张 的情况下也会触发GC的场景，推测可能是android底层自己处理的

• 存储同样的数据，HashMap的内存占用约等于Model的3倍，我原本以为会是17倍左右，毕竟他底层是个int[16] 。但是实际测试只是3倍左右

//每调用一次创建十万个对象，检测内存变化
                for (int i = 0; i < 100000; i++) {
                    linklist.add(new Object()); //内存变化：73M - 76M - 79M  - 82M
                    linklist.add(new HashMap()); //内存变化：79M - 85M - 91M

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

                    HashMap map = new HashMap();
                    map.put("title","1");
                    linklist.add(map); //72M - 88M - 105M - 121M = 每次差额为17M
                }

如何监听变量生命周期？

class Person : Object() {

    var name: String? = null

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

如何监听系统GC？

public class GcWatcherInternal {

    private static WeakReference sGcWatcher;

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

    private static final class GcWatcher {
        @Override
        protected void finalize() throws Throwable {
            sLastGcTime = SystemClock.uptimeMillis();
            ArrayList 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中写一次就好
GcWatcherInternal.addGcWatcher { Log.e("dq","触发GC ！！！") }

我们可以怎么优化内存

网上别人写的什么bitmap、handle内存泄漏、静态单例 一堆乱七八糟的东西，我在这里就不写了。我就只针对上述我自己的研究成果说一下我自己的看法

• 在Activity\Fragment中，无论你是否把View设为全局变量，View的生命周期都是一样的。所以性能和内存占用是一样的。

• 在Activity\Fragment中，没必要设为全局变量的，尽量使用局部变量，不要设为全局变量：

• 主观原因是：全局变量会让逻辑混乱，Activity代码看起来脏，别人接手你的代码容易改错。

• 客观原因是：只要Activity不死，全局变量不会被GC回收内存。如果你用局部变量，那么Activity只要走了任何生命周期（比如onCreate、onPause、onResume），这个局部变量的内存就被释放了。

• 确定不再需要用的全局变量，可以用代码设置为 = null，这样也会被及时GC回收。同理，全局变量中的全局变量，如果不需要用到了，也可以 = null。比如 this.house.image = null 。

• 有一些listview\recyclerView，你为了更好的显示，不得不在model里新加你自己定义的对象。最典型的比如聊天界面的表情SpannableString，但是要注意到如果你把SpannableString放到model中，他就不会被GC释放，特别是SpannableString里带ImageSpan的（一般是表情），就会比较占内存且不会被GC

• 建议的解决办法：可以用LRUCache，或者你新建一个SpareArray，只缓存最后20条左右的SpannableString。
  也可以最简单粗暴的 把过早的信息的Model里的spannableString = null。万一用户手动翻到最早的聊天记录，你再重新拼接spannableString。

• 你要是实在觉得无所谓，觉得你们app用户量不大，可以用空间换时间，不处理这些问题倒也没太大问题。但是依然要注意ImageSpan（一般是表情）需要做成单一变量，不要每条聊天消息都new ImageSpan()

一些恶劣的代码，以及会产生什么情况

事先声明：网上别人写的什么handle内存泄漏、静态单例 一堆乱七八糟的东西，我在这里就不写了。我就只针对上述我自己的研究成果说一下我自己的看法

• 在无限循环的Thread里访问全局变量：由于你的Thread在无限循环，所以Thread无法被回收这是正常的，可你在Thread里调用了Activity里的变量，会导致整个Activity无法被GC回收（包括Activity的全局变量也都无法回收） 。然后关闭Activity，Activity走了onDestroy。这时候按道理5秒后会正常触发GC回收Activity。这时候严重的来了： 由于系统这次GC无法回收onDestroy（因为她被thread引用了）。系统会每2.1秒GC一次，无限的尝试去释放这个Activity。代码如下：

  
  
  image.png
• 对上面截图的补充：
  1、把第148行换成最简单的 this@DetailActivity，也一样会导致内存泄漏：Activity和她的所有全局变量都无法释放
  2、每2.1秒GC一次，是冲着想释放Activity来的（并不是因为截图中的sleep两秒，这个2.1秒是系统固定的）
  3、如果Activity还没onDestory5秒，那么上面代码不会触发GC
  3、如果Thead里的Runnable里不调用全局变量，只打纯粹的Log，那么不会触发GC。大家都可以释放
  4、所以以上代码会导致：Activity无法释放+每2.1秒就GC一次。
  5、事实上只要Activity无法被释放，无论处于什么原因。系统都会在她onDestory5秒后，每2.1秒就GC一次

以下代码是正常使用的情况，他可以正常释放：

    private val handler = MyHandler(this)

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

        private val reference: WeakReference = WeakReference(context)

        override fun handleMessage(msg: Message) {

            val activity = reference.get() as DetailActivity?
          //经过测试：onDestory后5秒触发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没死 "+activity.house); //每0.4秒打印一次，直到onDestory的5秒后触发了GC，就会被上面的activity == null拦截
                    activity.handler.sendEmptyMessageDelayed(1 , 400)
                }
            }
        }
    }


    Thread(Runnable {
            Thread.sleep(2000)
             Log.e("dz","给activity 扔 start " +  house.hashCode() +" Activity = "+ [email protected]());
                  //LOG：给activity 扔 start 210397411 Activity = 237971341
             handler.sendEmptyMessageDelayed(1 , 400)
     }).start()