之后,就开始了分析… 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启动速度都会在几百毫秒之内,由于车载系统的差异性,具体问题还需具体分析…当然也可以使用跳转页面(鸡肋的最后方案)… 结束: 忙活一周,终于有那么一天不用被客户追,测试追,系统追,经理追(鸡肋)… 我的那个问题最后的解决是将之前分析的耗时,使用线程代替之后,组内大佬说还是换个生命周期好点(抑制可能出现的黑屏,因为那个耗时涉及到一个组件的刷新),最后编译的版本结果看,启动耗时已经达标.
