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<TextView>(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<String,String>()); //内存变化：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
}
如何监听变量生命周期？
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<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中写一次就好
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<SpannableString>，只缓存最后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<Context> = 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 = "+ this@DetailActivity.hashCode());
//LOG：给activity 扔 start 210397411 Activity = 237971341
handler.sendEmptyMessageDelayed(1 , 400)
}).start()
网友评论