Android | App内存优化 之 内存抖动解决实战

本文的精简总结在文首Pre文末小结以及解决技巧处!!!

Pre

  • 定义:内存频繁分配和回收导致内存不稳定
  • 明显特征:频繁GC、
    Memory Profiler 内存分配图形曲线呈锯齿状
    CPU ProfilerCall 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图平稳:
    9125154-4e62915b87cbc756.png
  • 点击按钮后,开始出现锯齿状(真机调试可能锯齿状不会很明显):
    9125154-80b7b9f803ddd2a8.png
    小米5s Plus真机调试
    9125154-2fa23b6ba7faed72.png
    Google Nexus_5X调试

这个时候,便可以判断,程序已经发生了内存抖动;

  • 情况严重时会导致卡顿;随后可分配的内存减少,便可能导致OOM!!!

  • 这个时候我们便从MP图锯齿状图形
    观察到内存抖动的现象了,
    接下来要开始分析,
    内存抖动真正发生位置,是在哪里;

  • 真正的项目中,一个Activity可能是有成百上千行代码,
    那我们改如何知道哪里出了问题呢;

  • 可以使用MP的堆转储按钮,继续进行分析:

    9125154-4ac0eda781ed6308.png

    点击堆转储按钮,(或者直接在图中选中一段图形)
    工具会弹出刚刚选中的一段时间内,
    内存分配情况窗口
    阅读时,可以点击下侧表格右上角的栏目项
    进行对应项的排序,
    如点击Allocations
    分配情况表格会按照分配的实例个数进行排列:
    9125154-eef735c19034f434.png

    我们可以看到锯齿的位置,String[]的分配是相对比较大的;
    Shallow Size是该类型实例的总大小(以字节为单位);

  • 于是现在可以锁定,String[]是最可疑的引起内存抖动的原因,
    点击左边的String[]行项,工具会在右边,弹出另外一个窗口,
    窗口上边是分配出来的该类型的所有实例(<工具右上>),
    点击任意一个实例,
    又会在下边弹出一个该实例的内存分配的堆栈信息<工具右下>——Allocation Call Stack),
    信息即,这个实例占有的这块内存,是在哪里分配的:

    9125154-68920c65a9b33a98.png
    我们可以看到,
    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执行的时间,
    如果发现某一段(应用自有函数调用代码(即绿色的条形段)在反复地被执行,!!!!
    (如下图的箭头所示)便是内存抖动的位置:!!!!
    9125154-da34907a03aadd61.png
    双击Call Chart中的一段绿色条形
    可以直接在IDE代码编辑界面,跳转追踪到,可疑诱因String[]分配执行函数 源码处 / 位置!!
    然后便发现原因,进行代码的修改!!




小结

  • 使用Memory Profile 初步排查
    该工具的图表显示方式非常直观,可以清楚地看到内存的使用情况;
    可以很方便地发现 APP在使用过程中,
    内存分配图形是不是一个锯齿状,有没有内存抖动的表现!

  • 使用Memory Profiler的堆转储 / 跟踪分配内存 功能
    借助Instance View
    追踪到分配内存较高/分配实例较多的实例类型
    跟踪该实例类型的某几个具体实例创建/分配 位置

    (或者使用CPU Profiler,跟踪一段CPU执行的时间,
    如果发现某一段应用自有函数调用代码
    Call Chart 栏下的绿色条形反复地被执行,便是内存抖动的位置,
    追踪这些绿色条形重复执行可疑函数位置),

    然后结合代码进行排查,找到诱因位置




内存抖动的解决技巧

重点关注:循环或者频繁调用的地方!!
因为内存抖动就是 内存在被不断地回收分配
这种情况的话经常是 出现在 循环或者频繁调用的地方





参考自
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

凌川江雪

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值