- 前言
app启动耗时过长的话,无论你的app里面的内容多么丰富有趣,作为一个用户,首先是没有耐心去等待的,如果我是一个用户,我会这样想:这是什么垃圾公司出的什么烂app,再等2s不进来就卸载,黑人问号???还真是垃圾,还没出来;于是乎,长按拖拽卸载,一套带走...
从个人层面讲,是对研发人员能力的否定;从公司层面讲,就是对该公司的否定;诸如,这家公司出的app很垃圾,同类产品也不会优先选择.由此可见,app启动耗时首先决定着它的第一体验,快不快,流不流畅都是之后才看得到的;而对于app启动耗时的分析就显得尤为重要了.
- 工具
前天以前我一个app启动大概要花费8s,不是忽悠,是真的有这么久.就以这个项目为例,简单分析一波app启动耗时.
工欲善其事,必先利其器.推荐给大家的是Android Studio内置的一个工具 TraceView;它能让你知道时间花在哪里了，有没有东西卡UI.
首先编译你的程序，打开Android Studio里面的Android Monitor，找到下图的按钮
然后在app里面干你想trace的部分，开个页面什么的
然后点同样的按钮完成tracing，接下来Android Studio会自动生成一个图表，比DDMS里面的版本好用太多！！
这不失为一种性能分析的不错方法;现在我们说到的是app启动耗时,app启动做了什么事情?
App启动入口类 Application(AndroidManifest.xml中可自定义),然后从配置了
的Activity开始启动;于是我们就可以简单的依据此顺序来进行如下操作;
在启动开始时,Debug.startMethodTracing("/sdcard/dmtrace.trace");
在启动完成时,Debug.stopMethodTracing();
在我的MyApplication下
在我的主Activity的OnResume方法中
那么随着程序的运行,在/sdcard/文件夹下会自动创建一个dmtrace.trace的文件;这个文件可以帮助我们很好的分析,这个启动的时间段内,做了什么事情.
把这个dmtrace.trace拖到Android Studio中,会看到这样的一个界面
鼠标点击到这个时间条上会出现更详细的耗时信息
可以看到,该方法实际耗时1.5s;而我看到的都是mainThread,也就是主线程,UI线程里进行的操作;难怪这么卡...
到项目中去看CacheManager里这个isCache确实是个耗时的操作,我们就把它放到子线程中进行,一下节省不少时间...
在下面的表中也可以很明显的看到这确实占据了启动时间的一大部分
具体地,把.trace文件拖入到DDMS工具可以看到更加详细清晰的效果
具体地,每一行的耗时不去细说,来源很多...
总结
TraceView是一个非常强大的性能分析工具，因为Android 官网对这个工具的使用介绍文档很少，没有讲到底怎么使用。
最近我在做app启动耗时方面的性能分析，就慢慢琢磨了这么工具的使用，发现非常强大，写下来总结一下。
Android的性能分析工具还有很多，比如：
- Eclipse Memory Analyzer Tool 来分析Android app的内存使用
- Dump UI Hierarchy for UI Atomator，分析UI层级
- systrace
- 其他