1.adb logcat 查看冷启动时间和Activity显示时间：
过滤Displayed关键字，可看到Activity的显示时间
那上面display后面的是时间是指包含哪些过程的时间呢？
模拟在Application中沉睡1秒操作，冷启动情况下：
从上可知：在冷启动情况下，第一个activity的display是冷启动的总时间=application+Activity的时间。
接着，界面上点击按钮，随意启动一个Activity：
从上可知：app进程在线情况下，启动activity的display 时间才是activity的显示时间(onCreate()->onStart()->onResume())
2.adb shell 启动activity的时间：
格式:
adb shell am start -W package名/包名路径的activity
例如，执行打开指定的mainActivity,如下图所示：
解读以上数据
- TotalTime: 是Activity的启动时间 ，与adb logcat 中Display 时间规则一致（通常以这个时间为准）
- WaitTime: 是AMS启动Activity的总耗时（它会TotalTime更大，存在跨进程通讯回执时间）
通过adb shell 启动的activity 必须具备以下条件之一：
设置程序的主入口：
或者设置exported为true
3.AndroidStudio的cpu Profile:
3.1适用于app冷启动时的trace捕捉：
创建一个新的运行configurations, 在profiling中配置：
一般是选择 java method sample，即Profiler的sample 模式，对性能影响小。系统会间隔us周期性记录java方法的调用栈，记录较为耗时，耗时较少不会显示在trace中。
- Java method trace： 适用于精确记录方法执行时间，即profiler的instrument模式，因一直记录方法的调用栈和cpu 使用情况，对性能影响很大，可能会造成黑屏，卡顿等情况。
- CallStack sample 适用于记录natvie+java的方法分析，Profiler的sample 模式。
- System trace: 记录同一个过程中系统各个进程的trace，适合更复杂的分析耗时。
使用方式： 先使用java method sample 记录，找出耗时的所在；接着，再用 java method trace 精确分析真正的耗时时间。
点击profiler 按钮后,等待安装后，启动后，会自动开始捕捉，等执行完需要观察的流程后，点击stop 。
打开录制的trace文件，选择main 主线程，打开如下所示：
从上面，可以清楚看到app 主线程中每个环节的方法调用栈和耗时时间等。 带颜色的方块越长，耗时越多，绿色一般是app中的代码。
选择Application的onCreate()查看，双击该方法，出现如下所示：
通过上图，可知左边菜单可知该方法耗时1s ,右边菜单top down 可知该方法的调用栈，真正耗时所在，沉睡一秒导致。
3.2 app 运行时，记录trace
有些界面是在app 特殊情况下触发，捕获该流程的trace 。可通过usb 连接手机，其次，在profiler 界面中选择可debug的进程，如下图所示：
选择cpu ,双击，如下所示：
也可以自由配置记录条件，选择不同缓存大小和周期时间us。
选择需要记录的trace类型，然后在app中使用流程，点击stop 。比如，打开一个视频页面，想了解其播放过程的耗时，如下所示：
从top down 中可清楚看到，视频页面中播放视频testPlay()的调用时间。
4.插桩使用Debug#trace api 精准记录方法执行时间
插桩方式，在release和debug 包下都可以使用，比较灵活方便。
由于存在 8MB 的缓冲区空间限制，因此 Debug API 中的 startMethodTracing(String tracePath) 方法专为时间间隔较短或难以手动启动/停止记录的场景而设计。如需设置持续时间更长的记录，请使用 Android Studio 中的性能剖析器界面。
简而言之，这种方式适合app冷启动，或者短时间内的方法记录trace。
public class TraceMethodUtils {/*** 适合于非常精确的记录，某个具体函数的耗时分析** profiler cpu 中instrument模式，会从开始一直记录方法/cpu 使用情况，对性能影响大。*/public static void startTrack(String tracFileName){Debug.startMethodTracing(fixTraceFileName(tracFileName));}/*** 在android 5.0 以后使用，间隔时间微妙 ** profiler cpu 中sample模式，系统间隔us 周期性记录调用栈，对性能影响小* @param tracFileName*/public static void startSampleTrack(String tracFileName){//1000us=1ms 周期性记录一次Debug.startMethodTracingSampling(fixTraceFileName(tracFileName),0,1000);}private static String fixTraceFileName(String tracFileName){if (!TextUtils.isEmpty(tracFileName)){tracFileName=tracFileName.endsWith(".trace")?tracFileName:tracFileName+".trace";tracFileName=new StringBuilder().append(System.currentTimeMillis()).append("_").append(tracFileName).toString();}else{tracFileName=new StringBuilder().append(System.currentTimeMillis()).append(".trace").toString();}return tracFileName;}/*** 结束跟踪*/public static void stopTrack(){Debug.stopMethodTracing();}
}
冷启动/界面启动的分析，推荐使用startSampleTrack（）。
这里，具体分析某个方法testPlay(), 执行需要记录的方法，记录如下所示：
以上文件在在DeviceFileExplorer 窗口中sdcard/android/data/package名目录，双击打开该trace文件，如下所示：
使用方式：首先选择需要查看的线程，进行双击进入。因testPlay()是在主线程中执行，因此在这里选择主线程：
Bottom UP窗口
用于观察某个方法中，调用其他若干方法的耗时占比，可更进一步筛选出耗时的具体位置，选择查看比例排前的几个方法。
比如，选中testPlay()，查看其内部的耗时方法占比：创建VideoView对象，耗时最大，3002us微妙=3ms毫秒。
Flame chat 火焰图窗口：
用于倒置查看某个方法中调用若干方法的查看，很直观的看到方法调用情况与耗时情况。淡黄色的往往是需要关注的方法点，可优化点也是在这里。
Top Down窗口：
可用于查看，该方法向下调用栈，也可以清楚看到接下来代码逻辑走向。也是按耗时排列。
使用总结： 打开trace文件后–>双击选择线程–>选择观察的方法–>Top Down窗口细化查看耗时方法–>Bottom UP窗口找到耗时所在点。
Trace 存储路径和sdcard 权限问题
简单来看下trace的保存路径逻辑：
发现，trace 是默认保存在sdcard/android/data/package名目录或者sdcard根目录中，因此必须要有sdcard读写权限。trace会自动补全.trace后缀名。
官方资料：https://developer.android.com/studio/profile/record-traces?hl=zh-cn#debug-api
资料参考：
- Android Studio 中 CPU Profiler 系统性能分析工具的使用：https://juejin.cn/post/7098548053136637983
- https://juejin.cn/post/7024387231104106503
- 基于AOP思想的Android方法耗时开源分析工具TimeTracer：https://www.paincker.com/time-tracer/
- https://jishuin.proginn.com/p/763bfbd4c428
- https://zhuanlan.zhihu.com/p/508526020
- https://juejin.cn/post/7163522788781719559
- 性能优化:https://www.jianshu.com/p/837ad55f3049
)
