AllocationTracker实践篇

结合实际，一个简单的例子
MainActivity跳转到供测试的ImageActivity
ImageActivity里没有任何多余代码，只有简单的界面。

ImageActivity.java

布局也很简单，我就不贴了。

抓取内存分配，结果也很简单。

抓取结果

（左上角）个人习惯按方法排序，（右上角）Total Size降序排序

分析结果

是view方法主动创建了一张图片，消耗了376.7k，具体想看原因，在方法名上右键，『jump to source』

如果是
按分配的大小来排

Group by allocator

结果也是一样的，是dalvik虚拟机进行了这样的操作。
我们自己的『包名com.example.lahm』没做啥操作

以上是基础。

现在在我们的根布局里添加一个图片background
该图分辨率 1500*1002 8bit-color 放在xxh-dpi文件夹下

layout

然后查看分配结果。

这张图消耗了约4.62Mb

AllocTracker就帮助我们抓出了内存中的老虎。
开发过程中出现的内存暴增，导致OOM，排查这部分问题AT是一个很好的选择。

衍生：
1.那么AT的原理是什么呢?
贴一个链接。
Android内存申请分析

2.同一张图放在不同dpi的文件夹下会有区别吗？
会有区别，下方图片是同一张测试图放在h-dpi下的内存分配情况，大概消耗了18.45Mb。

3.计算结果上，非图片消耗均为0.41Mb，同一张图放在x-dpi比放在xxh-dpi要多出13.84Mb，这个原因是什么？

以上问题，参考我的另一篇总结：

同一张图放在不同dpi文件夹下会有区别

测试机屏幕分辨率是420dpi/xxh-dpi

最后编辑于：2018.04.27 11:21:25

©著作权归作者所有,转载或内容合作请联系作者
【社区内容提示】社区部分内容疑似由AI辅助生成，浏览时请结合常识与多方信息审慎甄别。
平台声明：文章内容（如有图片或视频亦包括在内）由作者上传并发布，文章内容仅代表作者本人观点，简书系信息发布平台，仅提供信息存储服务。