App内存优化

一、内存优化介绍

1.背景介绍

  • 内存是大问题但缺乏关注
  • 压实骆驼的最后一个稻草(堆栈溢出)

2.内存问题

  • 内存抖动:锯齿状、GC导致卡顿
  • 内存泄露:可用内存减少、频繁GC
  • 内存溢出:OOM,程序异常

二、优化工具选择

1.工具选择

Memory Profiler

  • 实时图标展示应用内存使用量

  • 识别内存泄露、抖动等

  • 提供捕获堆转储、强制GC以及跟踪内存分配的能力

    总结
  • 方便直观

  • 线下平时使用

Memory Analyzer

  • 强大的Java Heap 分析工具,查找内存泄露及内存占用
  • 生成整体报告、分析问题等
  • 线下深入使用

LeakCanary

  • 自动内存泄露检测
  • https://github.com/square/leakcanary
  • 线下集成

三、Android 内存管理机制

一、Java 内存管理机制

Java 内存分配

  • 方法区:存储类信息,常量、静态变量等,如 public static final 的一些变量、常量。所有线程共享
  • 虚拟机栈:存储局部变量和操作数栈的(为Java方法服务的)
  • 本地方法栈:(为native 方法服务的)
  • 堆:几块内存块中最大的内存。所有线程共享,对象的内存分配实际上都是在堆上分配的。在虚拟机栈上分配的都是引用,会指向在堆中创建的真正的对象。是GC主要作用的一块区域。常说的内存泄露也是发送在堆上的。
  • 程序计数器:存储当前线程执行方法执行到第几行

Java 内存回收算法

标记-清除算法
  • 标记出所有需要回收的对象

  • 统一回收所有被标记的对象

    App内存优化_第1张图片
    缺点

  • 标记和清除效率不高

  • 产生大量不连续的内存碎片

复制算法
  • 将内存划分为大小相同的两块
  • 一块内存用完之后复制存活对象到另一块
  • 清理另一块内存
    App内存优化_第2张图片优缺点
  • 实现简单,运行高效(相比标记-清除算法)
  • 浪费一半空间,代价大
标记-整理算法
  • 标记过程与 “标记-清除” 算法一样
  • 存活对象王一端进行移动
  • 清理其余内存
    App内存优化_第3张图片
    优点
  • 避免标记-清除导致的内存碎片
  • 避免复制算法的空间浪费
分代收集算法
  • 结合多种收集算法优势
  • 新生代对象存活率低,使用复制算法
  • 老年代对象存活率高,使用标记-整理算法

二、Android内存管理机制

  • 内存弹性分配,分配值与最大值受具体设备影响
  • OOM场景:设备内存真正不足、可用内存不足(设备内存不足以分配给当前应用)

Dalvik 与 ART 区别

  • Dalvik 仅固定一种回收算法
  • Art 回收算法可以运行期选择回收算法(5.0之后都是Art)
  • Art 具备内存整理能力,减少内存空洞

Low Memory Killer 机制

针对所有进程来说的,当手机内存不足的情况下,Low Memory Killer 机制会针对所有进程进行一个回收,按照进程分配优先级顺序,找低优先进程进行回收。同时也会考虑回收收益。例如回收一个进程是30兆还是300兆

进程分类

  1. 前台进程
  2. 可见进程
  3. 服务进程
  4. 后台进程
  5. 空进程

四、内存抖动解决实战

内存抖动介绍

定义:内存频繁分配和回收导致内存不稳定
表现:频繁GC、内存曲线呈锯齿状
危害:导致卡顿、OOM

内存抖动导致OOM

  • 频繁创建对象,导致内存不足及碎片(不连续)
  • 不连续的内存片无法被分配,导致OOM

内存抖动解决实战

使用Memory Profiler 初步排查

App内存优化_第4张图片

使用Memory Profiler 或Cpu Profiler 结合代码排查

App内存优化_第5张图片

内存抖动解决技巧

  • 找循环或者频繁调用的地方

五、内存泄露解决实战

内存泄露介绍

定义:内存中存在已经没有用的对象
表现:内存抖动、可用内存逐渐减少
危害;内存不足、GC频繁、OOM

内存泄露解决实战

Memory Analyzer

  • https://www.eclipse.org/mat/downloads.php
  • 转换命令:hprof-conv 原文件路径 转换后文件路径

总结

  1. 使用Memory Profiler 初步观察(可用内存逐渐减少时,可以断定有内存泄露)
  2. 通过Memory Analyzer 结合代码确认

六、全面理解MAT

七、ARTHook 优雅检测不合理图片

Bitmap 内存模型

  • Api10 之前Bitmap 自身在Dalvik Heap 中,像素在native (有一个坏处,java 层内存回收后,native 层不知道)
  • Api10 之后像素也被放在Dalvik Heap 中
  • Api 26之后像素在Native(增加了java 向native 层的通知机制)

获取Bitmap 占用内存

  • getByteCount
  • 宽 x 高 x 一像素占用内存

常规检测不合理图片方式

背景:图片对内存优化至关重要、图片宽高大于控件宽高
实现:继承ImageView ,覆写实现计算大小
缺点:侵入性强、不通用

ARTHook 实战

介绍

挂钩,将额外的代码钩住原有方法,修改执行逻辑

  • 运行时插桩
  • 性能分析

Epic

  • Epic 是一个虚拟机层面、以Java Method 为粒度的运行时Hook 框架
  • 支持Android 4.0- 9.0
  • https://github.com/tiann/epic
使用
  1. compile ‘me.weishu:epic:0.3.6’
  2. 继承XC_MethodHook ,实现相应逻辑
  3. 注入Hook:DexposedBridge.findAandHookMethod
优点

无侵入性
通用性强
兼容问题大,开源方案不能带到线上环境

线上内存监控方案

常规方案

方案一

  • 设定场景线上Dump : Debug.dumpHprofData()
    (假设线上app 以使用单个程序最大占用内存的80%时,进行下线上内存Dump )
    App内存优化_第6张图片

方案一总结

  • Dump 文件太大(Dump 文件大小跟程序使用时长有关),和对象数正相关,可裁剪
  • 上传失败率高,分析困难
  • 配合一定策略,有一定效果

**

方案二

  1. LeakCanary 带到线上
  2. 预设泄露怀疑点
  3. 发现泄露回传

方案二总结

  • 不适合所有情况,必须预设怀疑点
  • 分析比较耗时、也容易OOM

LeakCanary原理

  • 监控生命周期,onDestroy 添加RefWatcher 检测
  • 二次确认断定发生内存泄露
  • 分析泄露,找引用链
  • 由监控组件 + 分析组件组成

LeakCanary 定制

  • 预设怀疑点 —> 自动找怀疑点
  • 分析泄露链路慢 ----> 分析Retain size(占用内存) 大的对象
  • 分析OOM ----> 对象裁剪,不全部加载到内存

线上监控完整方案

  • 待机内存、重点模块内存、OOM率
  • 整体及重点模块GC次数、GC 时间
  • 增强的LeakCanary 自动化内存泄露分析

你可能感兴趣的:(Android,性能分析与优化,java,android)