我們組的書已經(jīng)發(fā)表一段時間了， 我以我個人名義也回答過一些問題，有些問題挺有意思的。現(xiàn)在公開在這里，希望對于大家有所啟發(fā)。

問題1. 書中提到的Finder這個工具，很多朋友想要，但是卻沒有提供下載地址

Finder是我們內(nèi)部在MAT的基礎(chǔ)上，利用一些能直接發(fā)現(xiàn)問題的規(guī)則，提供了直接發(fā)現(xiàn)問題的能力。但是這個能力，用MAT，自己使用一下OQL當(dāng)然也可以發(fā)現(xiàn)。雖然工具短期內(nèi)真的不能提供，但是我們依舊用Finder來舉例子，是因為Finder有個思想， 就是規(guī)則，利用簡單有效的規(guī)則跟工具結(jié)合，快速發(fā)現(xiàn)問題。這些規(guī)則包括，單個緩存：禁止私開圖片緩存，重復(fù)緩存：緩存利用率低，等等。

問題2. 對于art這塊，以后出修訂版不仿講講。

如果在大家的支持下，有機會出第二版，可以說說。包括我們在APM上面的新的建設(shè)。

問題3. 剛才提到decodeStream，只是優(yōu)化磁盤I/O，那內(nèi)存還是會抖動，從android monitor里看內(nèi)存曲線圖，1-2秒里free:3M->0->3M這樣去波動，中間的0肯定是不好的，如果要優(yōu)化，那只能從圖片大小和精度下手了嗎？圖片大小和精度無法去做，那是不是只能想辦法規(guī)避？另外，我看到很多應(yīng)用剛開機.free就0-3M會不會heap一開始給配少了，要去調(diào)高一下heap?還是我要去關(guān)注下art，一開始分配的就過少。

一開始，heap size不大，free比較少，這個是可以理解的，應(yīng)用會自動擴容，所以一般來說不要太在意這個事情heap free的事情。比起這個，應(yīng)該更在意日志里面的GC for alloc或者內(nèi)存泄漏。如果有大量的GC for alloc， 可以用allocation tracer來定位問題。我們這邊發(fā)現(xiàn)的問題有兩類，StringBuilder和Bitmap，針對StringBuilder可以利用LocalThread和StringBuilder的delete方法盡量共用對象，不要重新生成。 針對Bitmap，除了RGB565，利用好inBitmap，控制好緩存大小，減少使用WeekReference。

問題4. 有什么推薦的其他的android性能優(yōu)化的書籍？

我們的書呀，嘻嘻。開玩笑，其實我自己也閱讀了很多書籍和視頻，這里也推薦下。

《android high performance programming》,? google i/o , android performance pattern

問題5. 在日常工作中或工作經(jīng)驗中，到底多大的。比如：騰訊的qq，可能檢出來的內(nèi)存泄露的點很多，有成千上萬的，要是把這個成千上萬個都去檢出來，那工作量很大，就算對于google原生的app，我用mat去分析，也會檢出很多，在你日常工作中，你覺的Retained Heap占多大時需要去優(yōu)化，個人覺的Retained Heap占10K以下或1K以下的放過，你怎么看待這個問題。

一般來說，重復(fù)操作，會持續(xù)的內(nèi)存泄漏，是必須要優(yōu)化的；引用了activity的，是必須要優(yōu)化的。前者的前提是，我們是持續(xù)在運行的應(yīng)用，大小不是重點，持續(xù)泄漏，最終就是一個下場，OOM。后者，是因為activity在內(nèi)存中比較大，會連帶引用一堆圖片之類的，也有OOM的風(fēng)險。最后，可以利用數(shù)據(jù)上報，觀察app占用內(nèi)存距離maxmemory多少，觀察OOM類的crash的多少， 如果一切正常，也許內(nèi)存泄漏真不是你需要關(guān)注的。

廣告：要書？買呀