我们组的书已经发表一段时间了， 我以我个人名义也回答过一些问题，有些问题挺有意思的。现在公开在这里，希望对于大家有所启发。
问题1. 书中提到的Finder这个工具，很多朋友想要，但是却没有提供下载地址
Finder是我们内部在MAT的基础上，利用一些能直接发现问题的规则，提供了直接发现问题的能力。但是这个能力，用MAT，自己使用一下OQL当然也可以发现。虽然工具短期内真的不能提供，但是我们依旧用Finder来举例子，是因为Finder有个思想， 就是规则，利用简单有效的规则跟工具结合，快速发现问题。这些规则包括，单个缓存：禁止私开图片缓存，重复缓存：缓存利用率低，等等。
问题2. 对于art这块，以后出修订版不仿讲讲。
如果在大家的支持下，有机会出第二版，可以说说。包括我们在APM上面的新的建设。
问题3. 刚才提到decodeStream，只是优化磁盘I/O，那内存还是会抖动，从android monitor里看内存曲线图，1-2秒里free:3M->0->3M这样去波动，中间的0肯定是不好的，如果要优化，那只能从图片大小和精度下手了吗？图片大小和精度无法去做，那是不是只能想办法规避？另外，我看到很多应用刚开机.free就0-3M会不会heap一开始给配少了，要去调高一下heap?还是我要去关注下art，一开始分配的就过少。
一开始，heap size不大，free比较少，这个是可以理解的，应用会自动扩容，所以一般来说不要太在意这个事情heap free的事情。比起这个，应该更在意日志里面的GC for alloc或者内存泄漏。如果有大量的GC for alloc， 可以用allocation tracer来定位问题。我们这边发现的问题有两类，StringBuilder和Bitmap，针对StringBuilder可以利用LocalThread和StringBuilder的delete方法尽量共用对象，不要重新生成。 针对Bitmap，除了RGB565，利用好inBitmap，控制好缓存大小，减少使用WeekReference。
问题4. 有什么推荐的其他的android性能优化的书籍？
我们的书呀，嘻嘻。开玩笑，其实我自己也阅读了很多书籍和视频，这里也推荐下。
《android high performance programming》, google i/o , android performance pattern
问题5. 在日常工作中或工作经验中，到底多大的。比如：腾讯的qq，可能检出来的内存泄露的点很多，有成千上万的，要是把这个成千上万个都去检出来，那工作量很大，就算对于google原生的app，我用mat去分析，也会检出很多，在你日常工作中，你觉的Retained Heap占多大时需要去优化，个人觉的Retained Heap占10K以下或1K以下的放过，你怎么看待这个问题。
一般来说，重复操作，会持续的内存泄漏，是必须要优化的；引用了activity的，是必须要优化的。前者的前提是，我们是持续在运行的应用，大小不是重点，持续泄漏，最终就是一个下场，OOM。后者，是因为activity在内存中比较大，会连带引用一堆图片之类的，也有OOM的风险。最后，可以利用数据上报，观察app占用内存距离maxmemory多少，观察OOM类的crash的多少， 如果一切正常，也许内存泄漏真不是你需要关注的。
广告：要书？买呀
网友评论