如果你是 Android 开发者，一定听过“内存抖动”这个词，如果高频地申请较大尺寸的内存，则可能导致短时间内频繁触发 GC，造成内存的频繁申请和释放，使用Profiler查看内存使用时，看起来就是一个抖动的曲线。
看，内存“抖动”起来了~
学习自定义View的时候，估计会有老师傅和你说：
不要在 onDraw() 里创建对象, 因为这个函数调用特别频繁，容易引起内存抖动。
你当然不会在编码的时候这么做，今天我想看看，到底能“抖”成什么样子。。。
测试代码
测试代码如下，每次 onDraw()都会创建一个20MB 的大对象，这里要注意：不建议使用 Bitmap 作为测试对象，因为在不同的 Android 版本 Bitmap 像素数据存储的位置不同，这会为测试添加新的变量。
override fun onDraw(canvas: Canvas?) {
if (flag) {
Trace.beginSection("MemoryThrashingView --> alloc")
val start = System.currentTimeMillis()
largeObject = LargeObject()
Log.d(TAG, "alloc onDraw: ${System.currentTimeMillis() - start}")
invalidate()
Trace.endSection()
}
}
//LargeObject
class LargeObject {
private int _20MB = 20 * 1024 * 1024;
private byte[] memory = new byte[_20MB];
}
测试设备
为了保证变量单一，测试统一使用模拟器，选择了Android 4.4、Android 5.0、Android 8.1 三个版本，每个版本又分为256MB 和 512MB 两个最大堆限制。
测试结果
Android 4.4 - 256MB heap
Android 4.4 - 512MB heap
Android 5.0 - 256MB heap
Android 5.0 - 512MB heap
Android 8.1 - 256MB heap
Android 8.1 - 512MB heap
我们可以看到，Kitkat(Dalvik) 在内存抖动的场景表现是灾难级的，每一帧都延时，掉帧非常严重。ART 的表现要好很多，1秒内会有1次到几次的延时，同时，由于Lollipop的分代管理策略，在这个场景表现甚至优于Android 8.1 的CC。
后记：
其实我也不清楚自己得出的结论有没有那么可靠，毕竟为了方便控制变量，我统一使用了模拟器来测试，但我发现当前电脑的负载情况也影响着模拟器的性能表现，同一个模拟器性能差异巨大，后来我将电脑的内存使用控制在60%左右，对比了256MB和512MB的性能表现，其实增加了几倍的测试工作量，希望能够客观一些。
