开发记录：批注截图耗时分析

urlname

type

Post

password

SyncToConfluence

问题及背景前提

前提：

批注应用本身是基于截图进行的，本质上是在截图的bitmap上进行绘制和操作
截图之前，为了防治截到自身应用，需要先隐藏应用（visibility=gone），在拿到截图内容后，再显示回来

问题：

应用从开始隐藏到再次显示，中间耗时过久，很影响用户体验
批注从启动到进入可书写状态过程的耗时很久，无法快速响应用户操作

截图方案

使用UDI提供的能力，进行截图及截图内容获取，大致的UDI截图原理如下：

UDI通过调用截图接口（原厂、MediaProjection等）获取到屏幕截图Bitmap对象

将Bitmap对象写出到本地文件，将结果返回调用方

UDI调用方读取UDI写出的截图文件，获取到屏幕截图内容

耗时分析

耗时猜测

截图接口本身耗时

UDI对于截图Bitmap进行的IO操作耗时

应用本身业务逻辑耗时

各个环节的耗时叠加的作用结果

单截图耗时

为了先确定耗时是截图本身瓶颈还是其他内容导致的问题，先统计截图接口本身的耗时，先将截图逻辑从UDI中抽离出来，并单独调用，查看耗时

从上面看出，获取截图内容本身耗时并不验证，为毫秒级

UDI接口耗时

从上面看，原生直接调用系统截图接口，本身仅需要50ms左右，这个速度在性能好的平台甚至更快（如3588，仅需要10ms即可完成）。

UDI是一个基于系统、原生能力，为应用层提供系统能力的中间服务，这里通过实际的耗时抓取，发现通过调用UDI截图接口获取到屏幕截图，从发起接口请求，到获取到屏幕截图Bitmap返回，总耗时在600ms左右，如果是外部通道、视频播放等场景，还可能更久。

截图环节耗时统计

关于截图的流程（不包含UI操作），可以大致拆分三个部分（RxJava的AsyncTask）：

onPre：截图开始前准备

onBackground：真正截图的操作，会得到Bitmap

onPost：截图后的操作

从下面整个流程，初步计算后，得到截图加上前后的准备动作，大概会耗时:1100ms，超过1s

onPre

从上面的方法耗时中，很直观可以看到，idle空闲时间占了一半以上，这部分时间，主要是在进行跨进程通信

onBackground

从上面的方法耗时中，很直观可以看到，idle空闲时间占了一半以上，这部分时间，主要是在进行跨进程通信

onPost

这里处于idle状态最久的，是nativeCopy，这一步是将截图后的Bitmap，作为批注的背景。

其次是nSyncAndDrawFrame，这个是SurfaceView在unlockCanvasAndPost 的同步函数。

虽然这一步有一定耗时，会算进整个截图流程的耗时，但是这一步已经完成屏幕截图，所以工具栏可以回显，工具栏的隐藏时间不受这里的耗时影响。

改进思路

主要分为两个部分：

耗时一：工具栏从隐藏到回显的耗时：这个过程整个应用的显示都会隐藏，所以这个时间如果过长，会直接影响用户体验
耗时二：整个截图流程的耗时：

这个过程包含了耗时一，但是包含了截图前、后的相关流程耗时
这个过程相对比较弹性，这部分的耗时用户对此的感知不强，可以适当将耗时一中的耗时移动到这里

注：不适宜在工具栏回显之后，还做太多耗时操作，因为回显后，如果还有很多耗时，会影响用户书写体验

对于耗时一：

需要尽量减少其他耗时操作，最好仅保留对屏幕截图接口的调用（这部分也有考究）

截图接口有UDI、OpenSDK、原生反射调用，三者中，耗时依次递减，但是兼容性也依次递减

对于耗时二：

减少重复的耗时状态的获取，并缓存，减少IDLE时间片
并发执行耗时任务，建立任务间的有向无环依赖

这篇文章先分析到这，具体的优化落地方案，由另外的文章进行记录。