App体系化优化之启动优化（二工具的使用）

<p>概述<br>TraceView是Android平台配备一个很好的性能分析工具，它可以通过图形化的方式让我们了解我们要跟踪的程序的性能，并且能具体到方法。关于它的介绍，配置，使用相信网上有大篇幅的文章介绍，我就不赘言了。<br><br>既然是启动的优化 那么我们就直接对启动的部分进行性能的检测<br><br>第一步：在Application中埋点，指定输出xx.trace文件</p><pre><code>@Override<br> public void onCreate() {<br> super.onCreate();<br> Debug.startMethodTracing("App");<br> QMUISwipeBackActivityManager.init(this);<br> initX5();<br> mInstance = this;<br> mContext = getApplicationContext();<br> mMainThread = Thread.currentThread();<br> mMainThreadId = android.os.Process.myTid();<br> mHandler = new Handler();<br> RePlugin.App.onCreate();<br> RePlugin.enableDebugger(this, true);<br> RxTool.init(this);<br> if (isDebug(this)) {<br> ARouter.openLog();<br> ARouter.openDebug();<br> }<br> ARouter.init(this);<br> UMConfigure.init(this, "xxxx", "Umeng", UMConfigure.DEVICE_TYPE_PHONE, "xxxx");<br> /**<br> * 参数: boolean 默认为false，如需查看LOG设置为true<br> */<br> UMConfigure.setLogEnabled(true);<br> /**<br> * 参数：boolean 默认为false（不加密）<br> */<br> UMConfigure.setEncryptEnabled(true);<br> UMShareAPI.get(this);<br> UMengPushManager.getInstance().initUmPush();<br> <br> //地图初始化，解决第一次进采集界面没有定位数据<br> LocationCityManager locationCityManager = new LocationCityManager(this);<br> locationCityManager.initLocation();<br> <br> //未知异常捕获，日志记录 邮件通知研发人员<br>// UniException.getInstance().init();<br> <br> //initDB<br> LitePal.initialize(this);<br> <br> //初始化录音工具<br> IdealRecorder.getInstance().init(this);<br> Debug.startMethodTracing();<br> }</code></pre><p>在onCreat方法启动的时候调用<br><br>Debug.startMethodTracing("App"); 指定在sdcard/Android/data/包名/file/App.trace 文件的生成<br>在启动结束的时候关闭<br><br>Debug.startMethodTracing();<br>启动app后在Device File Explore 视图找到App.trace文件，然后点击开就可以看到</p><p><img src="https://51techud.yykj.com:9002/forumpic/20210722152738_r8.png" style="max-width:100%;"><br></p><p><img src="https://51techud.yykj.com:9002/forumpic/20210722152757_jg.png" style="max-width:100%;"><br></p><p><img src="https://51techud.yykj.com:9002/forumpic/20210722152811_ag.png" style="max-width:100%;"><br></p><p>这里可以看出App启动过程有36个线程（Call Chart）黄色代表系统线程 绿色app自带的线程 蓝色代表java执行的线程<br><br>根据这些线程的消耗CPU的情况，代码执行的耗时，已经函数的调用和被调用情况，我们可以分析出启动慢，卡顿等的耗时原因，已经优化方向。<br><br>接下来我们区分两个指标：cputime和walltime<br><br>很多人会认为walltime代码执行时间就是用来考量性能决定优化方向的指标，其实不然，我认为cputime才是真正的衡量指标，cputime代码消耗cpu的时间即cpu占用时间。<br><br>原因：假设优先调用一个函数出现了死锁的情况，函数由于死锁无法分配到cpu而处于等待的状态，这个时候函数的walltime就会变得特别长，但是cputime却是非常短，因为函数A非常简单，甚至乎不怎么消耗cpu。<br><br>假设我们发现启动速度过慢，但是cpu的使用率又非常低，每一个线程占用cpu的时间很短的时候，这个时候我们就可以考虑开辟多线程来解决问题。<br><br>缺点<br>traceView的缺点就是即使我们在主线程埋点，但是它依然会捕获所有的线程，因此会使得app的速度变慢，对性能消耗非差大，反而产生误导，将优化的方向偏离。<br><br>其他工具：systrace</p>