Android：获取APP启动时间的踩坑经历

1. 前言

首先说明一下应用的几种启动方式

冷启动：系统不存在此 APP 的进程，此时需要重新创建进程、Application、Activity等，然后是 measure、layout、draw 过程
温启动：用户按 HOME 键后，如果 Activity 没有被回收，启动应用也只是唤醒到前台，不需要走初始化流程
热启动：系统存在此 APP 的进程，比如用户按 Back 键，或者按 Home键后 Activity 被回收了，此时由于进程存在，所以不会初始化 Application，只需要创建 Activity 并 measure、layout、draw。

最近有个需求需要统计App的启动时间，在查阅了一些资料后总结有如下三种方案

通过 adb 的 am 命令获取
通过 adb 的 logcat 命令获取
通过在Application和业务的第一个Activity埋点进行统计

2. 通过 adb 的 am 命令获取

网上大部分都是这种方案，可以通过 adb 的命令

adb shell am start -W com.gtr.sdkdemo/com.gtr.test.MainActivity

这个命令的输出日志如下：

Starting: Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] cmp=com.gtr.sdkdemo/com.gtr.test.MainActivity }
Status: ok
Activity: com.gtr.sdkdemo/com.gtr.test.MainActivity
ThisTime: 716
TotalTime: 4680
Complete

几个时间参数的讲解：

WaitTime 返回从 startActivity 到应用第一帧完全显示这段时间. 就是总的耗时，包括前一个应用 Activity pause 的时间和新应用启动的时间；
ThisTime 表示一连串启动 Activity 的最后一个 Activity 的启动耗时；
TotalTime 表示新应用启动的耗时，包括新进程的启动和 Activity 的启动，但不包括前一个应用Activity pause的耗时。

所以只关心 TotalTime 参数就可以了。但是问题来了：

首先这个是shell命令，能不能通过 Runtime 来进行调用这个命令我没试过，极有可能是不行的
这个命令需要新起一个Activity来统计，在已运行应用中肯定不可能新起Activity来统计，因为新起肯定是热启动的，启动时间不准

因此，这个方案被无情抛弃

3. 通过 adb 的 logcat 命令获取

在一次无意的浏览 StackOverFlow 过程中，看到有个大牛给了一个提示：应用启用时，会输出一行日志

adb logcat -s ActivityManager:I | grep Displayed

我试了一下，果不其然：

I/ActivityManager(  949): Displayed com.gtr.sdkdemo/com.gtr.test.MainActivity: +303ms (total +1s546ms)

再启动一次，发现还会出来一条

I/ActivityManager(  949): Displayed com.gtr.sdkdemo/com.gtr.test.MainActivity: +303ms (total +1s546ms)
I/ActivityManager(  949): Displayed com.gtr.sdkdemo/com.gtr.test.MainActivity: +590ms

也就是说，只需要读取最后一条数据就OK了。激动的我马上封装了一个异步获取类来试了一下，源代码如下

public class BaseInfoManager {

    private static final int WHAT_START_GET_APP_LAUNCH_TIME = 1000;

    private static volatile BaseInfoManager instance;
    private HandlerThread mHandlerThread;
    private Handler mHandler;
    private DataInputStream mReader;

    // 数据相关
    private List<String> appLaunchTimeList = new ArrayList<>();

    private BaseInfoManager() {
    }

    public static BaseInfoManager getInstance() {
        if (instance == null) {
            synchronized (BaseInfoManager.class) {
                if (instance == null) {
                    instance = new BaseInfoManager();
                }
            }
        }
        return instance;
    }

    public interface Callback<T> {

        void callback(T t);

    }

    private void runThreadIfNeed() {
        if (mHandlerThread == null) {
            mHandlerThread = new HandlerThread(BaseInfoManager.class.getSimpleName());
            mHandlerThread.start();
            mHandler = new Handler(mHandlerThread.getLooper()) {
                @Override
                public void handleMessage(Message msg) {
                    switch (msg.what) {
                        case WHAT_START_GET_APP_LAUNCH_TIME:
                            runShellForAppLaunchTime();
                            break;
                    }
                }
            };
        }
    }

    private void destoryThreadIfNeed() {
        if (mReader != null) {
            try {
                mReader.close();
            } catch (IOException e) {
                e.printStackTrace();
            }
        }
        if (mHandler != null) {
            mHandler.removeCallbacksAndMessages(null);
            mHandler = null;
        }
        if (mHandlerThread != null) {
            mHandlerThread.quitSafely();
            mHandlerThread = null;
        }
    }

    public synchronized void getLaunchAppTimeASync(long delayTime, final Callback<String> callback) {
        runThreadIfNeed();
        appLaunchTimeList.clear();
        mHandler.sendEmptyMessage(WHAT_START_GET_APP_LAUNCH_TIME);
        new Handler(Looper.getMainLooper()).postDelayed(new Runnable() {
            @Override
            public void run() {
                destoryThreadIfNeed();
                // 获取最近的一条数据
                if (appLaunchTimeList.isEmpty()) {
                    callback.callback("");
                } else {
                    callback.callback(appLaunchTimeList.get(appLaunchTimeList.size() - 1));
                }
            }
        }, delayTime);
    }

    private void runShellForAppLaunchTime() {
        Process logcatProcess = null;

        try {
            // adb logcat -s ActivityManager:I | grep Displayed
            String cmd = "logcat -s ActivityManager:I | grep Displayed";
            logcatProcess = Runtime.getRuntime().exec(cmd);

            mReader = new DataInputStream(logcatProcess.getInputStream());
            String line;
            while ((line = mReader.readUTF()) != null) {
                appLaunchTimeList.add(line);
            }
        } catch (IOException e){
            // nothing to do
        } catch (SecurityException |
                IllegalArgumentException |
                NullPointerException e) {
            e.printStackTrace();
        } finally {
            if (mReader != null) {
                try {
                    mReader.close();
                } catch (IOException e) {
                    e.printStackTrace();
                }
                mReader = null;
            }

            if (logcatProcess != null) {
                logcatProcess.destroy();
            }
        }
    }
}

这个类提供了延时异步获取的方式，因为 logcat 命令是会阻塞 shell 进程的，如果在主线程直接读取的话，会造成主线程阻塞。

在设计这个类的时候，也踩了一些坑，在这里稍微总结一下以防以后忘了

Runtime 的 exec 方法只是执行 shell 语句，并不是 shell 解释器，因此一些管道符、重定向符是不生效的。也就是说 |grep 我无效的，只能手动在程序中判断
android 用 exec 执行 logcat 中会自动过滤掉非本应用的一些日志，可能是出于安全着想
exec(String) 和 exec(String[]) 是等效的，最终都会将 String 参数转换为 String[] 参数
Progress 的 waitFor 方法会阻塞当前线程，直到 shell 子进程结束，如果 shell 子进程一直不结束，则会造成死锁。
BufferedReader 的 readLine 和 close 方法都会阻塞。起初我是用 BufferedReader 的 readLine 在子线程读取数据的，但是在主线程调用 close 方法来解除子线程的阻塞状态时发现主线程也被阻塞了。查看代码才发现 BufferedReader 的 close 方法加了一把锁。

public void close() throws IOException {
    synchronized (lock) {
        if (in == null)
            return;
        try {
            in.close();
        } finally {
            in = null;
            cb = null;
        }
    }
}

这样做就非常危险了，也就是说 BufferedReader 除非读到末尾的 '\n' 字符，否则是不能主动结束其阻塞状态的。而且主线程想结束子线程的阻塞状态调用 close 方法还可能把主线程给阻塞了。

后来我才用 DataInputStream 来替换的，因为它的 close 方法没有加锁，不会被阻塞，并且可以解除子线程的阻塞状态

public void close() throws IOException {
    in.close();
}

总结的采坑就到这里差不多了，运行结果发现没有任何启动时间数据。原因正如上面说的第二点，android 用 Runtime 获取的 logcat 日志信息，屏蔽了非本应用的日志，而启动时间的日志是属于系统的，所以获取不到。

4. 通过在Application和业务的第一个Activity埋点进行统计

上面的两种方案都以失败告终，没办法在跟老大沟通后只有牺牲数据准确性了。

首先在 Application 的 attachBaseContext 方法记录开始时间
在业务的第一个 Activity 的 onWindowFocusChanged 方法记录结束时间

这里解释一下为什么是 onWindowFocusChanged 而不是 onResume 等其他生命周期。因为 onResume 只是 Activity 的一次步骤，此时控件只是被 measure 了，但是并没有 draw，因此此时并不能被用户所见，而为了统计数据的准确性，以用户所见作为结束时间更为恰当。

然后解释一下这种方式的优缺点

优点：可以自由选择哪一个 Activity 作为业务上的“首页”，比如把主页作为首页而不是启动页
缺点：从用户点击 app icon 到 Application 被创建，中间还是有很多步骤的，比如冷启动的进程创建过程，而这个时间用此版本是没办法统计了，必须得承受这点数据的不准确性。

Android：获取APP启动时间的踩坑经历

1. 前言

2. 通过 adb 的 am 命令获取

3. 通过 adb 的 logcat 命令 获取

4. 通过在Application和业务的第一个Activity埋点进行统计

推荐阅读更多精彩内容

3. 通过 adb 的 logcat 命令获取