【性能篇4】内存优化思路总结

道阻且长，行则将至，行而不辍，未来可期

本文主要是介绍内存优化的一些思路，告诉你有哪些角度可以进行内存优化。优化内存的过程可以让你养成良好的编码习惯，可以让你注意到一些以往从来未关注的细节，让你不断思考，本文将持续长期更新，也激励自己一直思考下去。

关于内存问题，首先要弄清楚背景和目标，以及测试手法复现路径，充分的了解背景和目标有助于你更好的优化。

在内存优化前，先要进行内存分析，摸清内存的占用和分布情况，清楚了问题的根因，才好药到病除，下面将介绍分析的一些思路，仅供参考。

在中配置 为可调试，此时release版本亦可进行调试分析

先分析进程内存的整体分析情况

通过上图可知，其中占用内存最大的为为 左右，其他逐项亦可查看做出分析判断。

针对Java 内存，通过hprof进行进一步分析 通过无法定位到占用到内存特别大的项，则只能逐项排查，排查方法如下：

1. 选择project classes 然后从上到下，逐个classes进行分析

默认值可为空，则应该设置为null，避免内存浪费

文件的读取确认是否要从中读取，若不需要，则优化掉

无用的成员变量记得及时删除，避免内存占用浪费

HashMap优化

分析，通常可优化的点有：

• 默认值可为空，但没有设置为null
• 文件的读取确认是否要从中读取，若不需要，则优化掉
• 成员变量无用的及时进行删除
• 未联网之前是否有必要提前加载
• 枚举类优化
• HashMap优化

结论：的个数较多，说明代码量过大，需要从代码及依赖包进行优化

结论：
1、线程个数过多，每个线程至少占用内存64KB，占用过多内存资源
2、启动的线程执行完任务后，并不会被回收，需要进行回收优化
3、代码量过大，说明引入的库过多，需要从引入库方面入手优化

通过Log分析，当前进程的执行操作和流程，逐流程排查优化

结论：重复代码方法过多，会增加个数，需要优化

在一些可疑的地方增加断点，通过调试验证自身的猜测

结论：跨进程binder调用过多，开销太大，需要优化

内存泄漏相对来说处理会简单一点，

• 通过MAT分析占用内存比较大的类，进行优化
• 资源占用内存分析优化
• 默认值内存优化

在系统资源不足时，主动清掉一些缓存，避免被杀

收拢线程到线程池，并且可以考虑对默认栈空间进行减半的操作

此处可以参考【性能篇3】APK瘦身思路总结

dex 优化思路有：

1. 依赖库梳理
2. 优化，代码优化，谨慎使用外部库
3. 尽量不用自动生成的代码
4. 小功能不引入sdk，源码接入
5. 删除重复的代码：

   可以使用上面的pmd和simian工具扫描出重复的代码

6. 删除未使用的代码

   可以使用上面的coverage插件来辅助统计出未使用的代码

7. dex 压缩
8. Lint 内存优化

   Code-->Inspect Code -->选择Module 下的main进行检测

1、seeds 分析
取中未进行混淆的类和成员进行分析，确认哪些类可以进一步优化

2、混淆相关知识介绍

1. 查看混淆规则 ?
2. 混淆规则文件 ?

使用SpareArray代替Map<Integer, Object>，避免了自动装箱和维持创建映射所需要的对象

方法：搜索Map<Integer,关键字，然后进行替换