本文的精简总结在文首
的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图平稳:
- 点击按钮后,开始出现锯齿状(真机调试可能锯齿状不会很明显):
这个时候,便可以判断,程序已经发生了内存抖动;
- 情况严重时会导致
卡顿
;随后可分配的内存减少,便可能导致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)的函数调用显示为蓝色
。**
参考文章:
- **运行程序以及MP工具,
使用Record按钮开始记录某一段CPU执行的时间,
接着点击Stop停止对这段时间记录;
(上述Record记录完毕之后会在工具下侧弹出图表界面,
如Call Chart
,依据这些图表数据)
跟踪这一段CPU执行的时间,
如果发现某一段(应用自有函数
的调用
)代码
(即绿色的条形段
)在反复地
被执行,!!!!
(如下图的箭头所示)便是内存抖动的位置:!!!!双击
Call Chart
中的一段绿色条形
,
可以直接在IDE代码编辑界面,跳转追踪到,可疑诱因String[]
的分配执行函数 源码处 / 位置
!!
然后便发现原因
,进行代码的修改
!!**
小结
- 使用Memory Profile 初步排查
该工具的图表显示方式非常直观,可以清楚地看到内存的使用情况;
可以很方便地发现 APP在使用过程中,
内存分配图形是不是一个锯齿状,有没有内存抖动的表现!
- **使用Memory Profiler的
堆转储 / 跟踪分配内存 功能
借助Instance View
追踪到分配内存较高
/分配实例
较多的实例类型
,
跟踪该实例类型
的某几个具体实例
的 创建/分配 位置
(或者使用CPU Profiler,跟踪一段CPU执行的时间,
如果发现某一段应用自有函数
的调用代码
,
即Call Chart
栏下的绿色条形
在反复地
被执行,便是内存抖动的位置,
追踪这些绿色条形
到重复执行
的可疑函数
的位置
),
然后结合代码
进行排查,找到诱因位置
;**
内存抖动的解决技巧
**重点关注:循环
或者频繁调用
的地方!!
因为内存抖动
就是 内存
在被不断地回收
及分配
,
这种情况的话经常是 出现在 循环
或者频繁调用
的地方**