本文以 和讯财道 实例，介绍android studio 自带内存调试工具用法 以及内存优化技巧。分为三个部分。
1 android内存管理简述
2 android studio 内存优化工具用法
3 和讯财道内存优化实例
一 Android内存管理简述
关于android 内存管理，网上很多都是大而空的概念。并且好多都是你抄我，我抄你。
本文从实际出发总结几条（小字摘自网络）
1) 分配机制
（
16M原则）
Android为每个进程分配内存的时候，采用了弹性的分配方式，也就是刚开始并不会一下分配很多内存给每个进程，而是给每一个进程分配一个“够用”的量。这个量是根据每一个设备实际的物理内存大小来决定的。随着应用的运行，可能会发现当前的内存可能不够使用了，这时候Android又会为每个进程分配一些额外的内存大小。但是这些额外的大小并不是随意的，也是有限度的，系统不可能为每一个App分配无限大小的内除。
2) 回收机制（Android内存回收机制）
Android对内存的使用方式是“尽最大限度的使用”，这一点继承了Linux的优点。Android会在内存中保存尽可能多的数据，即使有些进程不再使用了，但是它的数据还被存储在内存中，所以Android现在不推荐显式的“退出”应用。因为这样，当用户下次再启动应用的时候，只需要恢复当前进程就可以了，不需要重新创建进程，这样就可以减少应用的启动时间。只有当Android系统发现内存不够使用，需要回收内存的时候，Android系统就会需要杀死其他进程，来回收足够的内存。但是Android也不是随便杀死一个进程，比如说一个正在与用户交互的进程，这种后果是可怕的。所以Android会有限清理那些已经不再使用的进程，以保证最小的副作用。
Android杀死进程有两个参考条件：
1 进程优先级
2 回收收益
二 分析内存的功能选项
基本名词解释:
| 名称 | Total Count | Heap Count | Sizeof | Shallow size | Retained Size |
| 意义 | 内存中该类的对象个数 | 堆内存中该类的对象个数 | 物理大小 | 对象本身占有内存大小 | 释放该对象后，节省的内存大小 |
| 名称 | depth | Shallow Size | Dominating Size |
| 意义 | 深度 | 对象本身内存大小 | 管辖的内存大小 |
1） Initial GC
about gc:
2) Dump Java Heap（重点）
以财道splash界面为例:
现象: 一个有趣的现象 一张600+ x 600+ 的Dominating 内存占用是67，一张99x192的Dominating 内存是75k。
让人禁不住有点怀疑这个工具是不是好使。继续往下看。
我新建一个简单的项目，对ImageView使用不同的加载方式进行加载，发现静态指定 android:src="xxx"内存占用很小，如果是通过picasso等框架 或者动态指定，内存占用会很大。
结论：
1 这个工具没有问题。
2 尽可能使用静态资源，因为其生命周期是有android系统管理的。特别是大图。
3) Start Allocation Tracking
这个功能可以记录一段区间内各个线程各个方法的内存分配情况。使用方法：先点击一次，然后会看到Memory Recorder开始转动，然后自己开始在APP上面做相应的操作。在合适的时间再点一次，结束记录。
以财道的splash界面为例。不滑动状态。内存使用情况
仅仅滑动四个广告界面的内存使用情况
现象：通过以上对照，可以看出，当滑动splash界面时，整体内存使用情况上升，主线程内存占用上升。
结论：通过此功能模块可以具体到哪个方法占用的内存数量。（注意此时生成的内存图谱文件后缀）
3 实际案例
现象:
2017-02-28 写文档的过程中发现财道内存异常，进行分析。
1 同时会存在2-3个MainActivity实例
2 在使用工具查看内存图谱时，前面的Activity实例会变红，说明被释放了。
3 查看MainAcitivity代码，发现一处延时操作，将延迟时间改为2分钟，再次观察内存情况，发现两分钟之内点击多次，会重复出现相应次数的实例。2分钟后再次生成图谱，发现之前的实例都变红
4 基本确认是该处代码导致问题，因为此问题会引发财道在短时间(6s)内持有多个MainAcitivty实例，引起一个小峰值。
优化方案:
优化结果:
修改前:
修改后：（平滑一些）
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
