app启动优化耗时分析

app的启动优化耗时分析

前提:记录下这次的坑爹操作吧.前不久,经理找到我.让帮忙优化一个项目的ap,启动大概需要5s(瘆人),将其优化至3s,后来又说<=2s.

之后,就开始了分析…
1.起步,先是对添加日志进行分析,就我们平时那种很正常的操作,不断比较日志来进行分析.
通过对代码添加系统时间的打印:

  //-----
        SimpleDateFormat format=new SimpleDateFormat("yyyy-MM-dd HH:mm:ss", Locale.getDefault());
        RadioLog.d(TAG, "onResume----ljt--start--4---"+format.format(System.currentTimeMillis()));
        //------

 //-----
        RadioLog.d(TAG, "onResume----ljt--end--4---"+format.format(System.currentTimeMillis()));
        //------

这是一种可以分析耗时的很简单的操作…完了一顿操作,分析了几个耗时点
2.也可以采用网上所说的一种命令,查看当前的启动时间.(有点鸡肋,只能看到那个时间)

adb shell am start -w packagename/activity
我就不沾我的包名了:附一张之前看的图吧
adb shell am start -W com.house365.aizuna/com.house365.rent.ui.activity.signin.SplashActivity
Starting: Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] cmp=com.house365.aizuna/com.house365.rent.ui.activity.signin.SplashActivity }
Warning: Activity not started, its current task has been brought to the front
Status: ok
Activity: com.house365.aizuna/com.house365.rent.ui.activity.index.IndexActivity
ThisTime: 234
TotalTime: 234
WaitTime: 251
Complete

我那个机器耗时蛮久的不忍直视…这里只是提供下我所用到的一些方法,都试了试.
3.想着也不是办法,后来就用到了这次的重点,traceview. studio的自带检测工具.
首先就在我们的代码中添加设置:

Debug.startMethodTracing("/data/data/包名/test.trace");
Debug.stopMethodTracing();

按照之前的有可能会找不到.trace文件,所以这里直接将文件路径写死,文件一定要写.trace后缀.当然你必须包含权限.
获取到文件之后,就需要用到 sdk/tool/下的traceview.bat
如果你没有 就需要下载下:
完了 我们可以采用adb命令将 /data/data/包名/test.trace 这个data/下的文件拷贝到电脑:

adb pull /data/data/包名/test.trace d:\info

因为我的sdk版本内未包含traceview.bat文件,所以我拷贝进去一个:
运行发现报错,如下:

Error: Unable to access jarfile ..\framework\archquery.jar
SWT folder '' does not exist.
Please set ANDROID_SWT to point to the folder containing swt.jar for your platform.

更新了下lib,具体是把别人的拷贝过来,整合下(D:\android-sdk-windows\tools\lib): 就可以了如下:

D:\android-sdk-windows\tools>traceview D:\info\test.trace
The standalone version of traceview is deprecated.
Please use Android Device Monitor (tools/monitor) instead.

就会打开你traceview的界面: 下面就可以分析你的耗时的操作了:
至于这个工具栏的里面的各种介绍,网上太多我就不多说了.
主要想记录下使用过程的一些问题.
就可以针对具体的问题操作进行优化:

结尾:
针对具体的操作采用延时处理,对各个生命周期进行分析,着重优先加载界面,一般的ap启动速度都会在几百毫秒之内,由于车载系统的差异性,具体问题还需具体分析…当然也可以使用跳转页面(鸡肋的最后方案)…
结束:
忙活一周,终于有那么一天不用被客户追,测试追,系统追,经理追(鸡肋)…
我的那个问题最后的解决是将之前分析的耗时,使用线程代替之后,组内大佬说还是换个生命周期好点(抑制可能出现的黑屏,因为那个耗时涉及到一个组件的刷新),最后编译的版本结果看,启动耗时已经达标.