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

本文的精简总结在 文首 的 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图平稳：
    

    于是现在可以锁定，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 栏下的绿色条形在反复地被执行，便是内存抖动的位置，
    
追踪这些绿色条形到重复执行的可疑函数的位置），

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

    内存抖动的解决技巧
    

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