公司动态

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

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

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

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

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

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




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

image.png

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


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

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

image.png

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

image.png

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

image.png

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

image.png

HashMap优化

分析,通常可优化的点有:

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

image.png

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

image.png

image.png

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

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

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

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

image.png

结论:跨进程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,关键字,然后进行替换

平台注册入口