问题

有的时候界面很卡，我们该如何定位？

现状

面试过很多人，对于这个问题，大部分都是这样回答的：

分情况：
1. 启动卡顿，应该看下都有哪些耗时操作，尝试延后执行
2. 滑动卡顿，考虑优化view复用
3. 交互优化，有些是等待IO
另外从 内存泄露 界面布局层次 界面重复渲染方面找问题

虽然不能说是错误的，但是整体的来说都是依靠经验和审代码，很少涉及工具使用，很难做到问题的准确定位，更不用说优化了

实践记录

现象描述

我们有一个界面，打开之后会根据状态自动滑动到第二个tab页，但是在滑动过程中比较卡，期望优化

分析

整个操作涉及两部分：页面启动，tab滑动，
第一部分因为是原位置从无到有，而且有loading，所以用户感知不大，第二部分因为涉及页面内容滑动，所以特别明显。

所谓的卡顿，其实对技术而言就是掉帧，简单说就是界面的渲染流程没能在16ms内完成，所以我们需要知道渲染流程每个阶段大致用了多少时间，哪个过程耗时较多

工具上场

GPU呈现模式分析

打开设置-开发者选项-GPU呈现模式分析，选择在屏幕上显示为条形图。
此时我们可以看到屏幕上多出了很多柱条，条形图含义请参考下面的链接说明。
进行复现操作，我们发现柱条很少，每一个都超出了16ms的准线，而且深绿色偏长，说明我们在主线程做了很多和UI无关的耗时操作。

CPU Profiler

设备连上studio，打开Android Profiler，选择CPU，使用说明请参考下面链接。
点击record，进行复现操作，停止record。
检查记录，此时可能有朋友会问这个结果怎么看，我简单说下

因为我们分析的是卡顿，主要看主线程，所以首先选择主线程，然后通过Call chart我们可以看到主线程的方法执行，
一般是loop对事件分发然后各种处理，我在实际操作时就可以看到onCreate执行了多长时间，而其中onCreate里的每个方法执行了多长时间，还有一些切换到主线程的回调执行了多长时间，还有onResume执行了多少时间。

通过这个结果我大概发现了一些造成卡顿的问题：

部分工具类的实际耗时比想象的长
网络请求的回调在主线程执行，而其中涉及一些大数据json的解析耗时较长
部分view是根据数据动态生成的，创建一个自定义view耗时较长，主要原因是view的xml较复杂
Presentation的show方法执行耗时特别长

Systrace

这个工具我也有尝试，但是效果不好，使用说明请参考下面链接。
好处是它会直接告诉你一些程序的问题，比如主线程调度delay、draw方法执行过程、measure时间过长，
坏处或者说不好用的地方，在我的电脑上 Ubuntu 16.04, 这个工具无法指定检测时长无论是否指定-t参数，而且有时会记录其他app而不记录我想检测的app，即使添加-a参数，另外有一些时候生成的报告无法打开，好像是时间设置问题，但是网上没有搜索到相关解决方案。大家有空可以尝试下。