身在移动互联网，真是不得不服老了，旧知识过期，新知识到来都很快。说个题外话，要吃互联网这口饭，学习能力，内驱力，归纳提炼寻求本质缺一不可。那么说回正题，诱发我写此文的有三点：1. ART的GC,  2. GC对卡顿的影响， 3. 追求GC为0现实么, 4. 尝试去学习，对比，提炼。

1. ART的GC

一直到4.4， 我对GC认知应该还停留在Dalvik的GC。ART是啥，一个让性能工程师失业的玩样。哈哈， 开玩笑的。性能工程师永无止尽，就像你不会想到现在PC会有用到需要插三个电源线的显卡（我买了HTC VIVE，顺带被迫买了2K的显卡，震惊了好一阵）。说整体， 要说ART GC, 我们不妨对比一下。这里不多说话，直接简单明了上图。

这两个图应该是我这几天学习的经过简化的知识了，力求大家一看就懂，所以有疏漏大家不要介意哈。

2. GC对卡顿的影响

从原理上看，GC可以STOP THE WORLD，意思其实就是挂起正在运行的全部线程，因此可以引入卡顿问题。而在各种GC的原因中，因为没有足够空间分配内存才触发的GC_FOR_ALLOC是最为耗时的，因为它完全没有并发的能力。

从android官方对外的宣扬，Bitmap.inBitmap，ObjectPool, ViewPool这些API和设计架构,  告示大家要把图片缓存从WeakReference切换到LruCache等等，都是在时刻提醒android开发，GC对性能的影响有多么重要。

从案例上看，我们项目有遇到过用inBitmap来减少GC, 用StringBuild.delete来代替new新的StringBuild来提升APP的流畅度，效果显著。

3. 追求GC为0现实么？

不现实。但是不想追求满分的60分也就只能是不及格。非常适合用在GC性能优化上，因为GC的出现就像是APP里面的空气和水，这时人就会有惯性有偏见，直接就认为那是必须的必要的，而没有想怎么优化。举例子，大部分人觉得byte[]的申请其实没有办法优化，其实不然，参考ObjectPool定制一个BytePool，可以减少byte[]的申请和释放。

4. 尝试去学习，对比，提炼

从这几天的学习来看，总体来说，从Dalvik（<3.0)的GC到Dalvik（>3.0)的GC, 再到ART的GC, 变化极大，但是有些事情是没有变的，如GC FOR ALLOC虽然开始支持局部GC, 但依旧不能并发，其他GC，虽减少了挂起线程的次数，但是依旧要有挂起线程stop the world的时候，因此本质都是一样的，就是减少GC,减少内存占用，减少卡顿。而所谓互联网行业，要懂得通过对比，举一反三的， 寻求本质， 否则落伍和淘汰是迟早的事情。

PS: 文章中如果有不对的地方，盼望指出。相信：the truth is out there。

参考文章：

1. http://hello2mao.github.io/2015/12/11/ART_GC_VS_Dalvik_GC.html

2. http://www.jianshu.com/p/a5b4850c8540  

3. Google I/O 2014