Android性能优化——内存优化

曾经终败给现在 2024-03-17 22:14 28阅读 0赞

## 一、内存问题 ##

*  内存抖动，锯齿状，GC导致卡顿
 *  内存泄漏，可用内存减少，频繁GC
 *  内存溢出，OOM，程序异常

## 二、内存分析工具 ##

*  Memory Profiler
 *  Memory Analyzer
 *  LeakCanary

> **Memory Profiler**
> 
>  *  实时图表展示应用内存使用量
>  *  识别内存泄露、抖动等，(简单的识别)
>  *  提供捕获堆转储、强制GC以及跟踪内存分配
> 
> 使用方法：Android studio下面的Profiler
> 
> 左上角有个加号 选择想要跟踪的进程
> 
> ![0d23fecc67e0408dabb0b8c511df5885.png][]
> 
> 右边有三种类型：CPU、MEMORY、ENERGY
> 
> 点击MEMORY
> 
> 垃圾桶按钮：点击的话相当于一次GC  
> 第二个按钮：将内存信息转成一个文件，以文件的方式展示出来  
> Record 按钮：记录点击之后在内存当中分配内存的情况 7.1及以下的版本的手机才有这个按钮  
> 减号和加号：放大缩小
> 
> ![69173977541f4032abed2b792a0645d7.png][]
> 
> **总结：**
> 
>  *  方便直观，对于整合内存情况来说，通过图表的方式来看到，同时可以知道分配内存的情况，也可以知道分配某一个对象具体的堆栈信息以及在哪里创建的
>  *  线下平时使用，Android studio自带的工具在开发工程中使用
> 
> **Memory Analyzer （MAT）**
> 
>  *  强大的Java Heap分析工具，查找内存泄露及内存占用
>  *  生成整体报告、分析问题等
>  *  线下深入使用
>  *  使用方式
>     
>      *  https://www.eclipse.org/mat/downloads.php
>      *  转换：hprof-conv 原文件路径 转换后文件路径
> 
> **LeakCanary**
> 
>  *  自动内存泄露检测
>  *  https://github.com/square/leakcanary
>  *  线下集成

## 三、Java内存管理机制 ##

[http://t.csdn.cn/ZJUWo][http_t.csdn.cn_ZJUWo]

## 四、Android内存管理机制 ##

*  内存弹性分配，分配值与最大值受具体设备影响
 *  OOM场景：内存真正不足、可用内存不足（整个系统都没有内存导致我们的APP OOM）

**Dalvik与Art区别**

*  Dalvik仅固定一种回收算法，手机出厂之前、烧录之前已经确定好了，在运行期间无法改变
 *  Art回收算法可运行期选择（5.0之后默认使用的虚拟机）在不同的情况下可以选择合适的垃圾回收算法
 *  Art具备内存整理能力，减少内存空洞

> 案例：
> 
> 应用程序发生在前台，正在与用户进行交互，对于用户来说，这时候响应速度最重要，此时应该选择一直简单的回收算法--标记清除算法，直接简单粗暴的作为前台的垃圾回收算法
> 
> 如果用户将APP切换到了后台，采用标记整理算法，作为一种补充

**Low Memory Killer机制**

针对所有进程来说的，当手机内存不足时，这个机制会针对所有进程进行回收

Android系统将进程分为（优先级按照从高往低）：

*  前台进程
 *  可见进程
 *  服务进程
 *  后台进程
 *  空进程

Low Memory Killer机制会找低优先级进程优先进行回收，在回收时会考虑一个回收收益

## 五、内存抖动 ##

**定义：**内存频繁分配和回收导致内存不稳定

**表现：**频繁GC、内存曲线呈锯齿状

**危害：**导致卡顿、严重时，会导致OOM

**内存抖动导致OOM：**

*  频繁创建对象，导致内存不足及碎片（不连续）
 *  不连续的内存碎片无法被分配，导致OOM

**实战：**

1.  首先通过Memory Profile 工具进行初步排查，为什么要选这个工具，它能很直观的以图表的方式告诉我们这个App 的内存使用情况，可以直观的看到这个App 在这段使用过程中是不是呈锯齿状，有没有内存抖动的表现
2.  使用Memory Profiler 的跟踪内存分配的功能，同时结合代码进行排先确认哪个地方的内存抖动，然后再去修改它。或者结合CPU Profiler 结合代码排查

**解决技巧**  
找循环或者频繁调用的地方

## 六、内存泄漏 ##

**定义：**内存中存在已经没有用的对象  
**表现：**内存抖动，可用内存逐渐变少，可能代码写的有问题，不断的申请内存，系统频繁的GC，导致的内存抖动  
**危害：**内存不足，频繁GC ，OOM

**解决实战：**使用**Memory Profiler**初步观察，通过**Memory Analyzer**结合代码确认

**Memory Analyzer** 强大的Java heap 工具，可以对Java内存进行深入分析，对于内存泄露来说，Memory profiler 只能进行一个简单的分析，并不能确认问题确认问题只能通过MAT

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

**Bitmap内存模型**

*  AP110之前Bitmap自身在Dalvik Heap中，像素在Native
 *  API10之后像素也被放在Dalvik Heap中
 *  AP126之后像素在Native

**获取Bitmap占用内存**

*  getByteCount 运行时直接获取Bitmap的内存大小
 *  宽 x 高 x 一像素占用内存，如果在资源目录下还要\*压缩比例，在res目录下

**常规方式：**

背景：图片对内存优化至关重要，图片宽高大于控件宽高

实现：继承ImageView，覆写实现计算大小

总结：侵入性强，不通用

**Epic方式：**

*  Epic是一个虚拟机层面、以Java Method为粒度的运行时Hook框架
 *  支持Android4.0一9.0
 *  https://github.com/tiann/epic
 *  使用：
    
     *  compile 'me.weishu:epic:0.3.6'
     *  继承xC\_ MethodHook ，实现相应逻辑
     *  注入Hook :DexposedBridge.findAndHookMethod

> **ARTHook**
> 
> 挂钩，将额外的代码钩住原有方法，修改执行逻辑
> 
> 使用场景：运行时插桩，性能分析
> 
> 优点：无侵入性、通用性强、
> 
> 缺点：兼容问题大，开元方案不能带到线上环境

[0d23fecc67e0408dabb0b8c511df5885.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/4488b38410e04172bb02e4d65111e416.png
[69173977541f4032abed2b792a0645d7.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/e0bdbacb5ff3465492d408d77684c9b9.png
[http_t.csdn.cn_ZJUWo]: http://t.csdn.cn/ZJUWo