当前位置： 
道阻且长，行则将至，行而不辍，未来可期
本文主要是介绍内存优化的一些思路，告诉你有哪些角度可以进行内存优化。优化内存的过程可以让你养成良好的编码习惯，可以让你注意到一些以往从来未关注的细节，让你不断思考，本文将持续长期更新，也激励自己一直思考下去。
关于内存问题，首先要弄清楚背景和目标，以及测试手法复现路径，充分的了解背景和目标有助于你更好的优化。
在内存优化前，先要进行内存分析，摸清内存的占用和分布情况，清楚了问题的根因，才好药到病除，下面将介绍分析的一些思路，仅供参考。
在中配置 为可调试，此时release版本亦可进行调试分析
先分析进程内存的整体分析情况
通过上图可知，其中占用内存最大的为为 左右，其他逐项亦可查看做出分析判断。
针对Java 内存，通过hprof进行进一步分析
通过无法定位到占用到内存特别大的项，则只能逐项排查，排查方法如下：
- 选择project classes 然后从上到下，逐个classes进行分析
默认值可为空，则应该设置为null，避免内存浪费
文件的读取确认是否要从中读取，若不需要，则优化掉
无用的成员变量记得及时删除，避免内存占用浪费
HashMap优化
分析，通常可优化的点有：
- 默认值可为空，但没有设置为null
- 文件的读取确认是否要从中读取，若不需要，则优化掉
- 成员变量无用的及时进行删除
- 未联网之前是否有必要提前加载
- 枚举类优化
- HashMap优化
结论：的个数较多，说明代码量过大，需要从代码及依赖包进行优化
结论：
1、线程个数过多，每个线程至少占用内存64KB，占用过多内存资源
2、启动的线程执行完任务后，并不会被回收，需要进行回收优化
3、代码量过大，说明引入的库过多，需要从引入库方面入手优化
通过Log分析，当前进程的执行操作和流程，逐流程排查优化
结论：重复代码方法过多，会增加个数，需要优化
在一些可疑的地方增加断点，通过调试验证自身的猜测
结论：跨进程binder调用过多，开销太大，需要优化
内存泄漏相对来说处理会简单一点，
- 通过MAT分析占用内存比较大的类，进行优化
- 资源占用内存分析优化
- 默认值内存优化
在系统资源不足时，主动清掉一些缓存，避免被杀
收拢线程到线程池，并且可以考虑对默认栈空间进行减半的操作
此处可以参考【性能篇3】APK瘦身思路总结
dex 优化思路有：
- 依赖库梳理
- 优化，代码优化，谨慎使用外部库
- 尽量不用自动生成的代码
- 小功能不引入sdk，源码接入
- 删除重复的代码：
可以使用上面的pmd和simian工具扫描出重复的代码
- 删除未使用的代码
可以使用上面的coverage插件来辅助统计出未使用的代码
- dex 压缩
- Lint 内存优化
Code-->Inspect Code -->选择Module 下的main进行检测
1、seeds 分析
取中未进行混淆的类和成员进行分析，确认哪些类可以进一步优化
2、混淆相关知识介绍
- 查看混淆规则 ?
- 混淆规则文件 ?
使用SpareArray代替Map<Integer, Object>，避免了自动装箱和维持创建映射所需要的对象
方法：搜索Map<Integer,关键字，然后进行替换
上一篇 
