。
感谢Gracker的分享,Get到一个新技能。具体流程参见传送门。主体思路就是通过MAT将对应的byte数组另存为图片原始文件,再用对应的工具打开预览即可。不过我记得以前Android Studio是可以直接看的,可现在不知道跑哪了。
因为Android Studio dump出来的文件mat是无法直接打开的,所以需要做一次转换。在Captures中找到刚刚dump出来的prof文件。右键 -> Export to standar .hprof 即可。
通过MAT Eclipse Memory Analyzer Open Source Project 打开。
右键想要查看的对象 -> Copy -> Save Value To File。保存为xxx.data。他推荐使用Gracker分享中的gimp。Photoshop不确定是不是我使用方式有问题,在验证的时候一直无法正常显示。
查看对应图片的相关属性,主体是要宽高,因为上一步中保存的是图片的原始格式文件,其中不包含对应的参数信息,所以在导入gimp中需要指定对应的参数。
打开gimp GIMP - Downloads . 然后打开刚刚导出的问题。图像类型根据实际的来,一般都是8888或者565,选择RGB Alpha或者RGB565。然后宽度与高度填写刚刚查询到的参数。最后点击open就能看到实际的图片。
通过这个方式,可以直观的查看到内存中图片的实际情况。然后我们就可以进一步分析产生问题的实际原因。
通过以上方式,定位到了3个问题:
对于大量图片占用的问题,其实从以下几个个方向来看思考问题。
结合以上方向来看下我们遇到的问题。设计角度目前无法调整,缘由都是泪,这里就不多说了。资源本身已经是RGB565。图片的释放应该是fresco的强项,可从现象上看似乎并没有。看来问题可能出在这,回ui页面上瞄一眼,明白了。
viewpager + fragment + recyclerview,相当于大量图片都属于使用状态,所以fresco不会去释放对应的资源。
临时解决方案:
为了确保核心逻辑的顺利,通过RxBus的方式,在进入和退出核心页面时发送Event事件,然后在大量使用图片的页面注册接收此系列事件,遍历所有SimpleDraweeView,调用其Controller的onDetach或onAttach来,从而实现图片资源引用的临时释放和加载恢复。
为什么是临时解决方案,因为我总觉得是一种取巧的方式,理论上看。是不应该直接调用方法来插手fresco的管理流程。所以此处留坑,之后再次深入了解fresco的原理后再回填,也希望大家提些建议或者意见。
每个页面中,都有处理网络异常及相关数据加载异常的提示。原先的处理方式是通过include统一导入后隐藏,在遇到异常的时候才显示出来。问题就出在这,这些异常提示本身是小概率触发,但通过include标签导入的话,会直接实例化完成,占用内存资源。
临时解决方案:
改用ViewStub标签,实现按需加载。
为什么又是临时解决方案呢,因为有些机型在黑屏状态下是切断wifi的,当重新进入应用的时候都会经过一个联网的过程,所以会先触发联网异常,ViewStub只能加载一次,加载完后就占用内存了。
之前为了在图片上显示文字但又不想被图案所影响,所以在上面加一层阴影蒙版来保证字体的显示效果。习惯用fresco:overlayImage的方法来实现。但这种实现方式会造成蒙版本身是一个独立的内存资源。
解决方法:
尝试通过Processor的方式,预先把蒙版与要显示的图片合成,使得在内存中只保留一份资源。
通过以上优化方式,同样的机型再次检测,内存占用下来了….
这次从内存高占用入手,解决了由于内存使用量过高导致的内存溢出。等之后遇到内存遗留问题时,再来补下文。
内存问题的排查与解决算是一个老生常谈的话题,因为适配等等情况往往又是一个比较棘手的问题。开发的时候很难发现,所以建议一个需求完成后都例行的检查下内存状况,看下是否有问题后者需要调整的部分。
来源: http://www.tuicool.com/articles/vay2yyn