身在移動互聯(lián)網(wǎng)，真是不得不服老了拗军，舊知識過期任洞，新知識到來都很快。說個題外話发侵，要吃互聯(lián)網(wǎng)這口飯侈咕，學(xué)習(xí)能力，內(nèi)驅(qū)力器紧，歸納提煉尋求本質(zhì)缺一不可。那么說回正題楼眷，誘發(fā)我寫此文的有三點(diǎn)：1. ART的GC, ?2. GC對卡頓的影響铲汪， 3. 追求GC為0現(xiàn)實么, 4. 嘗試去學(xué)習(xí)熊尉，對比，提煉掌腰。
1. ART的GC
一直到4.4狰住， 我對GC認(rèn)知應(yīng)該還停留在Dalvik的GC。ART是啥齿梁，一個讓性能工程師失業(yè)的玩樣催植。哈哈， 開玩笑的勺择。性能工程師永無止盡创南，就像你不會想到現(xiàn)在PC會有用到需要插三個電源線的顯卡（我買了HTC VIVE，順帶被迫買了2K的顯卡省核，震驚了好一陣）稿辙。說整體， 要說ART GC, 我們不妨對比一下气忠。這里不多說話邻储，直接簡單明了上圖。
這兩個圖應(yīng)該是我這幾天學(xué)習(xí)的經(jīng)過簡化的知識了旧噪，力求大家一看就懂吨娜，所以有疏漏大家不要介意哈。
2. GC對卡頓的影響
從原理上看淘钟，GC可以STOP THE WORLD宦赠，意思其實就是掛起正在運(yùn)行的全部線程，因此可以引入卡頓問題日月。而在各種GC的原因中袱瓮，因為沒有足夠空間分配內(nèi)存才觸發(fā)的GC_FOR_ALLOC是最為耗時的，因為它完全沒有并發(fā)的能力爱咬。
從android官方對外的宣揚(yáng)尺借，Bitmap.inBitmap，ObjectPool, ViewPool這些API和設(shè)計架構(gòu), ?告示大家要把圖片緩存從WeakReference切換到LruCache等等精拟，都是在時刻提醒a(bǔ)ndroid開發(fā)燎斩，GC對性能的影響有多么重要。
從案例上看蜂绎，我們項目有遇到過用inBitmap來減少GC, 用StringBuild.delete來代替new新的StringBuild來提升APP的流暢度栅表，效果顯著。
3. 追求GC為0現(xiàn)實么师枣？
不現(xiàn)實怪瓶。但是不想追求滿分的60分也就只能是不及格。非常適合用在GC性能優(yōu)化上践美，因為GC的出現(xiàn)就像是APP里面的空氣和水洗贰，這時人就會有慣性有偏見找岖，直接就認(rèn)為那是必須的必要的，而沒有想怎么優(yōu)化敛滋。舉例子许布，大部分人覺得byte[]的申請其實沒有辦法優(yōu)化，其實不然绎晃，參考ObjectPool定制一個BytePool蜜唾，可以減少byte[]的申請和釋放。
4. 嘗試去學(xué)習(xí)庶艾，對比袁余，提煉
從這幾天的學(xué)習(xí)來看，總體來說落竹，從Dalvik（<3.0)的GC到Dalvik（>3.0)的GC, 再到ART的GC, 變化極大泌霍，但是有些事情是沒有變的，如GC FOR ALLOC雖然開始支持局部GC, 但依舊不能并發(fā)述召，其他GC朱转，雖減少了掛起線程的次數(shù)，但是依舊要有掛起線程stop the world的時候积暖，因此本質(zhì)都是一樣的藤为，就是減少GC,減少內(nèi)存占用，減少卡頓夺刑。而所謂互聯(lián)網(wǎng)行業(yè)缅疟，要懂得通過對比搅轿，舉一反三的稽煤， 尋求本質(zhì)， 否則落伍和淘汰是遲早的事情合陵。
PS: 文章中如果有不對的地方沼填，盼望指出桅咆。相信：the truth is out there。
參考文章：
1. http://hello2mao.github.io/2015/12/11/ART_GC_VS_Dalvik_GC.html
2. http://www.reibang.com/p/a5b4850c8540 ?
3. Google I/O 2014
