一线大厂资深APP性能优化系列-卡顿定位（一）

时间 2020-05-31

原文原文链接

0.序

做者将近7年Android开发，经历过不少一线公司的APP开发，如中石油，阿里，京东等，想把真正一些一线的APP里的优秀的经验分享出来，打算利用休息时间更新一个系列的《APP性能优化》，大约是20章节，原本是打算申请小册的，可是也没审核经过，就打算免费分享了，每周大约会更新2章，喜欢的朋友记得加个关注和点赞。若有笔误欢迎指出。java

讲解的内容大致包含，异步优化，启动优化，卡顿优化，内存优化，ARTHook, 监控耗时盲区，网络，电量，瘦身及APP容灾方案等
android

1.简介

本篇文章是该系列文章中的第一篇，主要介绍的是在一些一线大厂的实际项目中，若是APP发生卡顿是如何进行定位问题的。主要介绍程序的耗费时间shell

2.测量时间方式

首先，若是要查看页面加载花费的时间有3种方式编程

adb命令查看
手动打点的方式
traceView

3.adb命令

只须要一行命令，就能够查看加载页面的时间。api

adb shell am start -W 包名/包名.Activity
复制代码

使用后会显示性能优化

ThisTime: 表明启动最后一个Activity的耗时
TotalTime: 表明启动全部的Activity的耗时
WaitTime: 表明AMS启动全部的Activity的耗时网络

注意点：该命令只能是获取配置了的Activity, 其余的无效，由于Android组件中有个 exported 属性，没有intent-filter时exported 属性默认为false，此组件只能由本应用用户访问，配备了intent-filter后此值改变为true，容许外部调用。app

缺点： adb命令只能查看配置了的Activity，其余的没法查看，而且也没法精准的查看其方法具体耗费的时间，因此由于其局限性并不能很好的解决咱们问题，咱们采用手动打点的方式查看。异步

4.手动打点

先看代码ide

public class MyApplication extends Application {

    @Override
    public void onCreate() {
        super.onCreate();

        initBugly();

        initBaiduMap();

        initJPushInterface();

        initShareSDK();
        ...
    }

    private void initBugly() throws InterruptedException {

        Thread.sleep(1000); // 模拟耗费的时间
    }

    private void initBaiduMap() throws InterruptedException {

        Thread.sleep(2000); // 模拟耗费的时间
    }

    private void initJPushInterface() throws InterruptedException {

        Thread.sleep(3000); // 模拟耗费的时间
    }

    private void initShareSDK() throws InterruptedException {

        Thread.sleep(500); // 模拟耗费的时间
    }
}
复制代码

代码不用我说，项目中很常见，如今的问题是APP启动加载很慢, 那么如何精准的查询到具体耗时的方法？

long startTime = System.currentTimeMillis();
  initBugly();
  Log.d("lybj", "initBugly()方法耗时："+ (System.currentTimeMillis() - startTime));
  
  long startTime = System.currentTimeMillis();
  initBaiduMap();
  Log.d("lybj", "initBaiduMap()方法耗时："+ (System.currentTimeMillis() - startTime));
  ...
复制代码

这样能够吗？固然不行，耦合性太大，每个方法都加，那么测试完了，删除代码也是个体力活，一不当心删错一个，就会形成灾难性的问题，在实际项目中，好比中石油的一些项目，就会采用 AOP 的方式来测量方法的耗费时长。

4.1 AOP

AOP : Aspect Oriented Programming的缩写，意为：面向切面编程

优势：

针对同一问题的统一处理
无侵入添加代码

这里咱们使用的是Aspectj

4.2 Aspectj 的使用

1.添加依赖

根目录的build.gradle里

buildscript {
    ...
    dependencies {
        ...
        classpath 'com.hujiang.aspectjx:gradle-android-plugin-aspectjx:2.0.0'
    }
}
复制代码

app项目的build.gradle及新建的module的build.gradle里添加

apply plugin: 'android-aspectjx'

dependencies {
    ...
    implementation 'org.aspectj:aspectjrt:1.8.+'
}
复制代码

2.建立切面

@Aspect
public class PerformanceAop {

    @Around("call(* com.bj.performance.MyApplication.**(..))")
    public void getTime(ProceedingJoinPoint joinPoint){

        long startTime = System.currentTimeMillis();
        String methodName = joinPoint.getSignature().getName();
        try {
            joinPoint.proceed();
        } catch (Throwable throwable) {
            throwable.printStackTrace();
        }
        Log.d("lybj", methodName + "方法耗时："+ (System.currentTimeMillis() - startTime));
    }
}
复制代码

看，根本无需修改任何工程代码，就能够获取运行时长了，点击运行显示

AspectJ语法参考

缺点：若是项目比较庞大，上百个方法，总不能所有打点，而后一个一个的分析究竟是哪一个地方运行时间过长吧，因此咱们须要一个比较直观的工具，一眼就能看到具体哪一个方法运行时间过长。

5. traceView的使用

5.1 特色

图形的形式展现其执行时间调用栈
信息全面，包含全部进程

5.2 使用方式

Debug.startMethodTracing("文件名");

Debug.stopMethodTracing();
复制代码

在代码中相应位置的地方打入埋点便可， startMethodTracing 有3个构造参数分别是

tracePath：文件名/路径
bufferSize：文件的容量大小
flag：TRACE_COUNT_ALLOCS 只有默认的这一种

代码运行完成后，会在

mnt/sdcard/Android/data/包名/files

生成一个.trace后缀的文件，能够用Profiler添加打开它。

固然也可使用Profiler的录制功能，可是由于要测量启动时间，点击录制手速并不会那么的精准，因此采用埋点的方式获取trace文件进行分析。

5.3 性能分析

打开文件后为上图所示

5.4 时间模式

上图标签 1 所示：wallclock time 和 cpu time

Wall Clock Time：从进程开始运行到结束，时钟走过的时间，这其中包含了进程在阻塞和等待状态的时间。
Thread Time ：就是CPU执行用户指令所用的时间。

注意：若是线程A执行函数b，可是由于函数b加了锁，线程A进入等待状态，那么wallclock time也是要计算时间的，而Thread time则只是计算CPU花费在它身上的时间。

通常根据经验来说wall duration时间久说明耗时多，而后看Thread time 这个值说明cpu花费在其身上的时间多很少。很少的话基本能够直接异步（由于不抢占CPU）多的话须要合理调度好执行顺序。

5.5 Call Chart

上图标签 2 所示：Call Chart

它的做用就是能够很直观的查看究竟是哪里耗时比较久，x轴为调用的时间线，越宽的表示耗时越久，y轴为调用的深度，也就是调用的子方法。父类在最上面，很明显initBottomTab（）方法调用是最耗时的。

鼠标悬浮能够查看耗费时间，双击能够跳转到相应代码

橙色：系统方法
蓝色：第三方API（包括java语言的api）
绿色：App自身方法

简易图以下：

5.6 Flame Chart

上图标签 3 所示：Flame Chart 又称之为火焰图

y 轴表示调用栈，每一层都是一个函数。调用栈越深，火焰就越高，顶部就是正在执行的函数，下方都是它的父函数。 x 轴表示抽样数，若是一个函数在 x 轴占据的宽度越宽，就表示它被抽到的次数多，即执行的时间长。注意，x 轴不表明时间，而是全部的调用栈合并后，按字母顺序排列的。

火焰图就是看顶层的哪一个函数占据的宽度最大。只要有"平顶"（plateaus），就表示该函数可能存在性能问题。

练习1：

假如火焰图如上图所示，咱们须要分析哪一个函数吗？

答：最顶层的函数g()占用 CPU 时间最多。d()的宽度最大，可是它直接耗用 CPU 的部分不多。b()和c()没有直接消耗 CPU。所以，若是要调查性能问题，首先应该调查g()，其次是i()。另外，从图中可知a()有两个分支b()和h()，这代表a()里面可能有一个条件语句，而b()分支消耗的 CPU 大大高于h()。