[纸上谈兵 1]——App启动优化

作者: nick_young | 来源:发表于2019-06-30 22:36 被阅读0次

0 纸上谈兵——App启动优化

纸上谈兵系列是我在学习App性能优化的笔记，纸上谈兵这个名字就很好的反应了这次只是启动优化的学习，并没有真正用到实际App的开发过程中（以后专门的同时处理），闲话少说，下面就开始关于App的启动优化的总结。

1 背景

体验
如果App的启动慢，会给用户用户体验造成影响。
八秒定律
如果一个网页在8S没有被打开，那么70%的用户将会放弃等待。

2 启动分类

冷启动

耗时最多，作为线上的衡量标准。
启动过程：
点击事件 -> IPC -> Process.start -> ActivityThread -> bindApplication -> LifeCycle -> ViewRootImpl

冷启动进行的任务：

启动App
加载空白Window
创建进程
Application创建
启动主线程
创建MainActivity
加载布局
布置屏幕
首帧绘制

随着首帧绘制完成，我们任务此次启动完成。

热启动

最快
后台 -> 前台

温启动

较快
只会进行LifeCycle

3 优化方向

优化我们能控制的地方，即Application和Activity生命周期。

3.1 测量启动时间

3.1.1 adb 命令

adb shell am start -W packagename/首屏Activity

结果：

结果

TotalTime: 所有Activity启动耗时
WaitTime: AMS启动Activity的总耗时

线下使用方便，不能带到线上
非严谨、精确的时间

3.1.2 手动打点

启动时埋点，启动结束埋点，取二者差值。

开始时间
attachBaseContext()方法，我们能拿到的最早的方法。

结束时间
误区：onWindowFocusChanged只是首帧的时间
正解：真实的数据展示出来
addOnPreDrawListener

精确，可带到线上，推荐做法
避开误区，应采用界面绘制是作为结束

3.2 启动优化的工具选择

3.2.1 traceview

特点：

图形的形式展示执行时间、调用栈等
信息全面，包含所有线程
使用方式：

Debug.startMethodTracing(fileName);
Debug.stopMethodTracing();

产生的文件在Android 9.0：

/storage/self/primary/Android/data/包名/files/fileName.trace

手机系统版本不同，文件位置不一样，不过文件位置都在

.../Android/data/包名/files/...下

可以使用Android直接打开，主要关注Call Chart(表格)和Top Down（调用顺序） 这两列，同时也要关注 Wall Lock Time（代码在线程上真正执行的时间），Thread Time（CPU执行时间，在这个线程上），一般会小于Wall Lock Time，CPU Time是我们需要关注的点。

主要关注Top Down即可，查看耗时最多的方法基本上就是我们需要优化的关注点。

traceview Top Down截图

总结：运行时开销比较大，整体都会变慢（抓取所有线程的所有函数），可能会误导优化的方向。

3.2.2 systrace

特点：

结合Android内核的数据，生成Html报告。
API 18以上使用，以下可以使用TraceCompat
使用方式：
代码添加

// 开始位置
TraceCompat.beginSection(name);
// 结束位置
TraceCompat.endSection();

python systrace.py -t 10 [other-options] [categories]

详细参数查看官方文档。
使用python命令，查看生成文件。搜索设置的名称，找到相应位置。放大html，找到该方法调用消耗。这里面也要关注CPU Duration 和 Wall Duration。两者的差别上面已经讲过，这里不赘述。

结果

3.2.3 AOP方式

优点：

无侵入性，不用手动修改代码
修改方便

使用AOP进行编译时代码插桩，常用的AOP框架：AspectJ（推荐使用JakeWharton大神的hugo）。
使用步骤：

dependencies {
    classpath 'classpath 'com.jakewharton.hugo:hugo-plugin:1.2.1''
}

在当前Module中的build.gradle文件中添加插件：

apply plugin: 'com.jakewharton.hugo'

新建插桩类：

@Aspect
public class CostAOP {
    private static final String TAG = "AOPTime";

    @Around("call(* com.nick.second.app.**.**(..))")
    public void appOnCreate(ProceedingJoinPoint joinPoint) {
        long timeMillis = System.currentTimeMillis();
        try {
            joinPoint.proceed();
        } catch (Throwable throwable) {
            throwable.printStackTrace();
        }

        Log.d(TAG, joinPoint.getSignature().getName() + " : " + (System.currentTimeMillis() - timeMillis));
    }

    @Around("execution(* com.nick.second.app.**.**(..))")
    public void appExecutionOnCreate(ProceedingJoinPoint joinPoint) {
        long timeMillis = System.currentTimeMillis();
        try {
            joinPoint.proceed();
        } catch (Throwable throwable) {
            throwable.printStackTrace();
        }

        Log.d(TAG, "execution " + joinPoint.getSignature().getName() + " : " + (System.currentTimeMillis() - timeMillis));
    }
}

规则：

Around在代码前后插入代码，需要使用ProceedingJoinPoint参数，并且需要手动调用ProceedingJoinPoint.proceed()来执行原方法。其他@Before,@After等只需要出入安JoinPoint即可。
call指方法调用，第一个*代码返回值任意，第二个**指文件任意，第三个**指任意方法
execution指方法执行，将代码插入方法体头和尾

高级用法可以google自行搜索。

4. 优化

4.1 小技巧

Theme切换：
App启动时会创建空白的Window，此时如果我们设置Style包括了App的Logo等图片，那么给用户App启动特别快的错觉。具体实现：

创建启动style

<!--设置背景图Theme-->
<style name="Theme.AppStartLoad" parent="android:Theme">
    <item name="android:windowBackground">@mipmap/ic_launcher</item>
    <item name="android:windowNoTitle">true</item>
</style>

将style设置给MAIN Activity

<activity
    android:name=".activity.MainActivity"
    android:theme="@style/Theme.AppStartLoad">
    <intent-filter>
        <action android:name="android.intent.action.MAIN" />

        <category android:name="android.intent.category.LAUNCHER" />
    </intent-filter>
</activity>

在启动的Activity的onCreate方法前设置回需要的theme：

@Override
protected void onCreate(Bundle savedInstanceState) {
    setTheme(R.style.AppTheme);
    super.onCreate(savedInstanceState);
}

4.2 异步优化

思想：充分利用CPU，将串行执行的初始化修改为并行执行。
实现：使用线程池进行初始化。
注意：

有先后调用关系的需要考虑先后顺序
不符合异步要求的仍需要放在主线程初始化
区分cpu密集型和io密集型任务
实现代码：

// 使用CountDownLatch作为初始化完成的倒计时器
private CountDownLatch countDownLatch = new CountDownLatch(3);

@Override
public void onCreate() {
    super.onCreate();
    // 创建线程池，个数根据AsyncTask中相同
    ExecutorService executorService = Executors.newFixedThreadPool(Math.max(2, Math.min(Runtime.getRuntime().availableProcessors() - 1, 4)));
    executorService.submit(new Runnable() {
        @Override
        public void run() {
            initFirstSDK();
        }
    });
    executorService.submit(new Runnable() {
        @Override
        public void run() {
            initSecondSDK();
        }
    });
    executorService.submit(new Runnable() {
        @Override
        public void run() {
            initThirdSDK();
        }
    });
    try {
        //CountDownLatch在onCreate中最后一步进行等待，所有的初始化完成后会调用CountDownLatch.countDown()，当为0的时候则代码初始化完成
        countDownLatch.wait();
    } catch (InterruptedException e) {
        e.printStackTrace();
    }
}

private void initFirstSDK() {
    try {
        Thread.sleep(300);
    } catch (InterruptedException e) {
        e.printStackTrace();
    }
    new Thread("first") {
        @Override
        public void run() {
            super.run();
            Log.d(TAG, "initFirstSDK: start" + System.currentTimeMillis());
            Log.d(TAG, "initFirstSDK: end" + System.currentTimeMillis());
            countDownLatch.countDown();
        }
    }.start();

}

private void initSecondSDK() {
    try {
        Thread.sleep(300);
    } catch (InterruptedException e) {
        e.printStackTrace();
    }
    new Thread("second") {
        @Override
        public void run() {
            super.run();

            Log.d(TAG, "initSecondSDK: start" + System.currentTimeMillis());
            Log.d(TAG, "initSecondSDK: end" + System.currentTimeMillis());
            countDownLatch.countDown();
        }
    }.start();
}

private void initThirdSDK() {
    new Thread("third") {
        @Override
        public void run() {
            super.run();
            Log.d(TAG, "initThirdSDK: start" + System.currentTimeMillis());
            Log.d(TAG, "initThirdSDK end" + System.currentTimeMillis());
            countDownLatch.countDown();
        }
    }.start();
}

4.3 启动器

对于异步初始化的优化，则需要使得代码更加的规范、优雅，便于开发和维护。因此引入启动器的概念：

将每个任务抽象为Task，所有Task依赖关系排序生成一个有向无环图，并且对Task进行分类（主线程和异步线程）以及Task优先级设定。

具体代码暂无，根据上面的描述进行编写即可（思想最主要，并且这一步根本不能优化启动时长，最主要是使代码更加规范、优雅，便于开发和维护）。

4.4 延迟初始化

通过Handler.post()方式进行初始化：初始化时机不明确，如果页面渲染期间进行初始化，可能会造成界面卡顿。
通过IdleHandler进行初始化：充分利用空闲时机进行初始化，不会造成页面的卡顿，是推荐的初始化方法。

5 其他优化

提前加载SharedPreferences：异步加载xml，IO操作，会阻塞：

在Multidex之前加载，利用此段CPU
复写getApplicationContext()方法，将其返回this

启动阶段不启动子进程：子进程会共享CPU资源，导致主进程CPU紧张。并且要注意不要再App onCreate之前启动四大组件，例如Service、ContentProvider（会将时间算在Application启动上）。
类加载优化：提前异步类加载。

通过替换ClassLoader查找所需的类
通过Class.forName()进行类本身和其静态变量的引用类的加载
new 类实例，加载类成员变量的引用类

启动阶段抑制GC，需通过Native hook实现
CPU锁频（增加耗电量），将频率拉伸，拉到最高。

6 总结

启动时长的获取：

开发阶段：ADB命令、手动打点
线上：AOP代码插桩，注入统计代码并上传服务器进行统计

获取方法耗时：

SystemTrace
AOP
wall time和CPU time

总方针：

异步（启动器）
延迟（Idlehandler）
其他优化点

其他：
结合CI对Application类进行CodeReview，当发现有修改则需要进行CodeReview，查看是否需要进行增加。