孙鹏飞 置顶2018-12-09看评论有部分同学对内存这两篇的内容主题提出了疑问，说是内存优化的主题关注内存监控的内容太多了。邵文同学已经在下面的评论里有部分回复了，我这里总结一下原因。首先我们并没有很直接的去给出很多优化的案例，比如评论里提到的hook gc来避免gc引起的memory churn的技术，或者常见的引起内存泄漏几种情况的解决、数据结构优化(arraymap等)，更换序列化方案，view复用，object pool等优化方法，也没有具体的去讲解内存相关的操作系统概念和Android虚拟机heap space的结构和allocator的执行原理，这些内容大部分网上有很多不错的帖子进行了很详细的讲解，而且限于篇幅我们把内容关注在我们经常遇到的问题上，就是我们如何去监控不当的内存使用，比如发生OOM或者短时间频繁的GC产生卡顿的时候，如果我们没有具体的内存监控信息是无法判断产生问题的原因，这也是我们在实际工作中遇到的问题，也是这两篇内容关注的点，如果同学有想了解的内容可以在留言里提出来，看大家具体对哪些文章里没有提到的内容感兴趣，可以讨论一下。展开 16
2018-12-10文哥，看了二楼和三楼的回答，感觉他们想表达的意思学习是一个循序渐进的过程，一上来就“跳级式”的领讲搞的大家很慌，因为毕竟大多数人的水平没这么高，很多人可能都是一脸懵逼的进来，一脸懵逼的出去。而你所说的有些网上都有很成熟的帖子或者文章，但是能在看这篇文章的时候去搜的又能有几个呢？我提个建议哈，就是开讲的过程中，如果需要打基础的知识，能不能贴个链接，引导式学习 80
2018-12-21说下看了几篇文章的感受，可能确实是实力差距，看完后感觉实用性太差，都是讲的一些高大上的理论和市面上大部分公司都用不到的东西，没有一个循序渐进的过程或者引导，毕竟交钱来参加高手课的水平大部分都是菜鸟啊。楼上有个建议很好，讲这篇文章前先把一些用到的基础知识贴一下链接。看来真的是高手课，高到云端了，很难触及的那种。编辑回复: 非常感谢你的反馈，很好的意见，已和作者沟通调整。
15
2018-12-08内存优化的主题是监控？作者回复: 内存优化有两个部分，一个是架构，这里包括设备分级，缓存管理，进程管理与Bitmap图片库的策略。
另外监控的确是最重要的，因为大部分的内存问题，特别是内存泄露，oom。更多的时候难点不在于解决，而在于如何发现它们。 14- 2018-12-16如果看不懂，可以多看几遍，再不懂那可能是相关的知识储备不够了，建议再去补补基础，反正这课买了又不会跑，以后还能看。
与我而言，了解了大厂是如何细粒度的进行监控的，感受到了差距，得到了一点启发，收货满满 10 
2018-12-10感觉主题有一点跑偏，在监控内存泄露的前提下，应该从怎么防止内存泄露着手，我感觉会更实用，因为监控不是每个公司都涉及的，但是防止内存泄露应该是每个程序员应该必备的。我感觉可以多来一点实现思路和怎么预防泄露已经常见的一些泄露点。
虽然网上有很多帖子可看，但是有以下一些问题，零散、正确性、思路、如何验证等等问题，既然大家都来买课我想也是奔着课程的专业程度来的，所以我感觉作者在深入的同时也不要忘记一些实用的东西分享。及时是因为篇幅的问题，我感觉可以通过其他链接的方式引入。
拜托！展开作者回复: 怎么说呢，单从内存泄露可能就有各种各样的场景，不同应用情况也不一样。
在有限的边幅里面，我这边更加希望大家可以触达底层，这些问题的本质是怎么样？如何去发现它们，怎么样构造自己的测试体系。
当然后面也会考虑多加入一些参考链接 10
2018-12-09感觉自己目前的能力还不能完全考虑到性能方面，只能保证尽量不使用重复代码，完成功能，不出bug…… 6
2018-12-08平时在做图片优化的时候，主要用inSampleSize控制图片大小，将大图片调整到合适的大小，毕竟是google推荐的方案。
总结一下我今天学到的关于内存优化的东西
设备分级：根据设备的高级程度（综合考虑）使用最佳的实践方式；
控制进程数量（看到有节操的保活会心一笑）；
注意控制包大小；
图片优化：统一管理，统一监控；
重复图片：一个一个对比像素肯定不现实，比尺寸刷一波，再比像素，先取一个像素点，估计这一步就能刷掉很多不同的图片，然后在剩下的图片继续用这种方式（或者增加像素点），不知道可行性高不高（待定），应该有更好的方式；
内存泄漏：先第三方框架查漏，时机成熟后及时还“技术债务”；
内存监控：查找内存占有率，尽量做到“用完就走”，不占资源。
“技术债务”真是一个好词，平时一点一点的还肯定比遇到紧急情况加班加点的还要好的多。
抛个问题：相似图片是不是也应该丢弃，相识图片又要怎么判断呢？展开作者回复: 相似图片的确也有人搞过，但是是线下自动化时。
如果判断相似图片是非常成熟的算法，可以在网上搜到很多资料。 6
2018-12-22我觉得shaowen老师讲的很好，总体思路和框架已经出来，剩下是自己补充技术细节了，这才是高手课。 4
2019-01-11简单说下感受，老师的确在内存优化上没有提供过多实质的方案，而是从底层去分析内存和监控内存，间接提供不一样思维角度，觉得很赞。 不过确实是有点深度，可能对很多应用层开发看着有点吃力，前几篇就这么深奥难懂，不知会不会降低某些人的兴趣，但是对我而言，就喜欢这么有深度内容，而不是重复网上一些文章的内容。 3
2018-12-09项目里先后换过几次实现长连接的方式，包括Netty，现在使用MQTT实现长连接功能，我们知道MQTT 用于物联网的居多，我们使用后导致OOM的概率一下上去了，您对这个有什么看法呢？或者有什么实现稳定的长连接的方式，我们主要做拍卖项目，对价格的实时更新要求比较高。谢谢了。作者回复: mqtt不是非常清楚，微信使用的是mars，这个已经开源。
长连另外一个比较通用的方式是使用http2.0，后面的架构篇我们会有专门的讲 3
2018-12-08从上一节课就一直在讲第三方或者一些自动化监控的工具，就像昵称是“灰”的听众说的一样，“内存优化的主题是监控”吗？没有讲到根本的东西啊，就算是Android开发的高手课，内容的思路和逻辑上也要建立在最基础的东西上吧？没有一个从基础上升到高层次的一个过程，相信会有越来越多的听众难以接受了。作者回复: 不知道这位同学说的根本和基础指的是哪些内容？是指pss rss uss这些的区分，以及low memory killer机制，内存分配原理这些吗？
因为内存这个话题已经很老了，网上和android developer都有大量这些内容，文中也给了一些参考资料。
内存优化文中其实讲了两部分内容，一部分是架构上的设计，例如设备分级，统一缓存，进程管理，以及图片库的使用。
另外主要讲的的确是监控，因为大部分的内存问题，比如泄露，某一时间分配过大，oom。他们其实解决都不难，难得是如何快速的发现它们。
也欢迎指出其他的意见 1 3
2019-08-20问个很菜的问题，监控到重复图片之后要怎么去重？作者回复: 监控的时候会有堆栈，去重的话就交给对应的业务开发
1 2
2019-06-02这是网上找不到的干货，仔细体会，必然收货满满啊 2
2019-02-20oom其中一种原因是超过线程数量超过上限，排查起来有难度作者回复: 可以参考崩溃分析的，将所有的线程名输出到日志中
1 2
2018-12-11很多实验室环境或者开发环节就能发现的问题，目前大一点的厂都能搞得定，但是想要继续深入优化，将离线工具分析发现问题的模式变成线上实时监控发现问题，这正是很多厂需要的内容。 2- 2018-12-08您好，如何确定是bitmap重复图片呢，遍历所有像素点比较吗，是不是太重了
作者回复: 这个重复bitmap分析是在服务器后台做的，目前是对所有bitmap数组直接计算hash的方法匹对
2 - 2019-12-11张老师，想向你咨询一个问题。现在rxjava等框架大行其道，但是在用的过程经常出现底层线程池有太多线程消耗，导致oom。或因为锁问题，或因为其他问题，线程无法释放。由于这些线程堆栈太深了，没有办法确定具体是那个业务代码开出来的。在这个方面有没有比较好的定位手段。因为看了手q通过trace日志定位问题的文章，感觉还是没有版本具体定位到问题。
作者回复: 这个问题有点大，我们可以具体拆分一下。
目前我们在线上也没有做太细致的监控，不过对于ANR和卡顿日志会分析锁的问题。
对于崩溃日志会去自动分析线程和文件句柄的问题 1 
2019-09-14大佬，询问一个问题，我发现在8.0 android手机上，不同界面重复使用一个图片，通过api setImageResource 设置。其实内存大小并没有变化，android系统内部已经帮我们去重了。多个界面，多次setImageResource 相同的图片引用。都是复用一个图片的。所以不理解你说的 “图片去重复”的优化。能否告知下作者回复: 指的是同一张图片，createbitmap多次。。在实际开发过程中，我们创建Bitmap的方式有很多种，不仅仅是setImageResource
1 1
2019-08-06大佬，想问下文中提到的“大图片监控”在线上环境如何部署思路，是用插桩方式在 比如 setBitmap 方法后拿到bitmap和view的宽高做比较，还是定时地去获取内存快照中view和bitmap的宽高作比较，还是其他方式？不胜感激~作者回复: 我们是采用后者的
2 1