Android | App内存优化 之 内存抖动解决实战
本文的精简总结在
文首的Pre、文末的小结以及解决技巧处！！！
Pre
- 定义：内存频繁分配和回收导致内存不稳定
- 明显特征：频繁GC、
Memory Profiler内存分配图形曲线呈锯齿状、CPU Profiler的Call Chart栏下反复出现的绿色条形 - 危害：导致卡顿、OOM
内存抖动导致OOM
- 频繁创建对象，！！！！！
导致
内存不足或者产生内存碎片！！！！！ （内存碎片即内存不连续，有内存空洞， 某两个正在使用的内存中间有一个间隔， 这个间隔虽然也被算在可用内存里面， 但实际上，因为它过小， 当我们申请内存的时候，经常是需要申请一定量的连续内存， 而这些碎片小内存不符合要求，是不能拿来使用的） - 不连续的内存片无法被分配，可分配的内存不足，导致OOM；
- 情况严重时会导致
卡顿；随后可分配的内存减少，便可能导致OOM！！！
解决内存抖动实战
使用Memory Profile 排查处理
不同的工具，有自己适合的使用场景；
使用Memory Profile 初步排查
（后文中Memory Profile 简写成MP）
- 图表直观，可以清晰地看到内存曲线；
开始编程
- 布局：
<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:layout_width="match_parent"
android:layout_height="match_parent">
<Button
android:id="@+id/bt_memory"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:text="执行任务" />
</LinearLayout>- 对应的Activity文件：
/**
* 模拟内存抖动的界面
*/
public class MemoryShakeActivity extends AppCompatActivity implements View.OnClickListener {
@SuppressLint("HandlerLeak")
private static Handler mHandler = new Handler() {
@Override
public void handleMessage(Message msg) {
super.handleMessage(msg);
// 创造内存抖动（编写耗内存的操作）
for (int index = 0; index <= 100; index++){
String arg[] = new String[100000];
}
mHandler.sendEmptyMessageDelayed(0,30);
}
};
@Override
protected void onCreate(@Nullable Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_memory);
findViewById(R.id.bt_memory).setOnClickListener(this);
}
@Override
public void onClick(View v) {
mHandler.sendEmptyMessage(0);
}
@Override
protected void onDestroy() {
super.onDestroy();
mHandler.removeCallbacksAndMessages(null);
}
}- 运行：
- 点击按钮前，MP图平稳：
- 点击按钮后，开始出现锯齿状（真机调试可能锯齿状不会很明显）：
小米5s Plus真机调试
Google Nexus_5X调试
这个时候，便可以判断，程序已经发生了内存抖动；
- 情况严重时会导致
卡顿；随后可分配的内存减少，便可能导致OOM！！！ - 这个时候我们便从
MP图的锯齿状图形， 观察到内存抖动的现象了， 接下来要开始分析，内存抖动的真正发生位置，是在哪里； - 真正的项目中，一个Activity可能是有成百上千行代码， 那我们改如何知道哪里出了问题呢；
- 可以使用MP的堆转储按钮，继续进行分析：
点击堆转储按钮，（或者直接在图中选中一段图形）
工具会弹出刚刚选中的一段时间内，
内存分配情况的窗口，
阅读时，可以点击下侧表格中右上角的栏目项，
进行对应项的排序，
如点击Allocations，
则分配情况表格会按照分配的实例个数进行排列：
我们可以看到锯齿的位置，String[]的分配是相对比较大的；
Shallow Size是该类型实例的总大小（以字节为单位）；
- 于是现在可以锁定，
String[]是最可疑的引起内存抖动的原因， 点击左边的String[]行项，工具会在右边，弹出另外一个窗口， 窗口上边是分配出来的该类型的所有实例（<工具右上>）， 点击任意一个实例， 又会在下边弹出一个该实例的内存分配的堆栈信息（<工具右下>——Allocation Call Stack）， 信息即，这个实例占有的这块内存，是在哪里分配的：
我们可以看到，
MP工具的右下表格显示出来了右上角选中的对应的实例的
分配内存的位置——
“handlerMessage方法中，MemoryShakeActivity文件的第27行”；
右键之，选中Jump to Source，
直接在IDE代码编辑界面，跳转追踪到，可疑诱因String[]的创建源码处 / 位置！！
然后便发现原因，进行代码的修改！！
或者也可以使用CPU Profiler 排查处理
Call Chart 标签提供函数跟踪的图形表示形式， 其中，水平轴表示函数耗费的时间，垂直轴显示其被调用者。 对系统 API 的函数调用显示为
橙色， 对应用自有函数的调用显示为绿色， 对第三方 API（包括 Java 语言 API）的函数调用显示为蓝色。 参考文章：
- Android性能优化之CPU Profiler
- 运行程序以及MP工具，
使用Record按钮开始记录某一段CPU执行的时间，
接着点击Stop停止对这段时间记录；
（上述Record记录完毕之后会在工具下侧弹出图表界面，
如
Call Chart，依据这些图表数据） 跟踪这一段CPU执行的时间， 如果发现某一段（应用自有函数的调用）代码（即绿色的条形段）在反复地被执行，！！！！ （如下图的箭头所示）便是内存抖动的位置：！！！！
双击Call Chart中的一段绿色条形，
可以直接在IDE代码编辑界面，跳转追踪到，可疑诱因String[]的分配执行函数 源码处 / 位置！！
然后便发现原因，进行代码的修改！！
小结
- 使用Memory Profile 初步排查 该工具的图表显示方式非常直观，可以清楚地看到内存的使用情况； 可以很方便地发现 APP在使用过程中， 内存分配图形是不是一个锯齿状，有没有内存抖动的表现！
- 使用Memory Profiler的
堆转储 / 跟踪分配内存 功能借助Instance View追踪到分配内存较高/分配实例较多的实例类型， 跟踪该实例类型的某几个具体实例的创建/分配 位置（或者使用CPU Profiler，跟踪一段CPU执行的时间， 如果发现某一段应用自有函数的调用代码， 即Call Chart栏下的绿色条形在反复地被执行，便是内存抖动的位置， 追踪这些绿色条形到重复执行的可疑函数的位置）， 然后结合代码进行排查，找到诱因位置；
内存抖动的解决技巧
重点关注：循环或者频繁调用的地方！！
因为内存抖动就是 内存在被不断地回收及分配，
这种情况的话经常是 出现在 循环或者频繁调用的地方