客服群里叫喊着：这个用户图片不显示了，那个用户图片也不显示了。我拿着手上一切正常的测试机，what the hell…… 默默地打开bugly。 满园春色关不住，遍地内存溢出来！是的，又闯祸了！ 内存问题永远是既陌生又熟悉的话题，而且大多数都发生在一个叫作用户家的手机上。安卓系统本身不断的在优化，三方框架也逐渐成熟，外加手机厂商的大内存加持，似乎内存问题变得少见，但还是不能忽视。 借着这次修复内存问题的记录，分享一些“自以为”的解决思路，仅供参考。ok,let’s go! 修复问题的三部曲，先复现，再定位，最后修复。 复现估计有的人会说，异常现象都在那，有啥好复现的，冲进代码直接开干。 修复bug永远是个惊心动魄的事，稍微一不小心就有可能天崩地裂。不是修复不完全，就是引入新问题。从起因开始了解整个缘由，一方面能加深对问题的理解，同时确保最终能验证问题是否得到修复。 内存的问题经常发生在一些比较特殊的环境下，而且很多时候不一定是必现，往往体现在一些中低端机型上。所以从机型上入手可能会是一个不错的选择。 最终，通过bugly查到了对应的问题机型及系统版本，上各类云测平台找到了台云测试机。按照进入问题页面的几个固定流程，反复执行，最终锁定了复现流程。 定位知道问题如何复现，接下来就是定位问题到底出在哪。通常内存的问题，会碰到两种情况：
我们先来看看这次的问题属于哪种情况。 在Android Studio2.3及之前版本上自带的Android monitor中，可以直观的反应出当前应用的整体内存使用水平。[如何使用工具的分享估计大家都看腻了，这次就不再重复了。 142MB！！！！进入事故现场之前就已经被占用了这么多内存。难怪之后会内存异常。看来这次要先解决内存高占用的问题，我们先要详细的了解内存的具体情况，才知道从哪下手去解决，无论是避免无意义的使用或者优化必要的占用。 先强制gc一下，然后dump java heap，看一下整体内存里的情况，按照shallow size排序。 首当其冲的byte数组映入眼帘，大家都明白的，bitmap一直都是大客户。我们接着分析下byte[]中的各个对象。 从数据上看，有很多大小相同的内存使用，从理论上看应该是有很多尺寸相同的图片。可为什么会有这么多呢？是相同的图片重复了？or other？ 所谓耳听为虚眼见为实，如果能看到这些图片长什么样，是否就容易做出对应的判断了？来，开始行动： 感谢Gracker的分享，Get到一个新技能。具体流程参见传送门。主体思路就是通过MAT将对应的byte数组另存为图片原始文件，再用对应的工具打开预览即可。不过我记得以前Android Studio是可以直接看的，可现在不知道跑哪了。 步骤一：因为Android Studio dump出来的文件mat是无法直接打开的，所以需要做一次转换。在Captures中找到刚刚dump出来的prof文件。右键 - |
|
声明：文章版权归原作者所有 部分文章转自互联网 如有侵权请联系
[邮箱地址] 删除
|
注册
登录
