如何打造稳定、好用的 Android LayoutInspector？

一、背景

---

Android 开发者在日常的开发中，经常需要用到查看视图的功能，Android Studio 开发团队为我们提供了 LayoutInspector 插件。在较新的版本提供了 LiveLayoutInspector，支持 3D，但是不管是 LayoutInspector 还是 LiveLayoutInspector 都非常难用。比如：

• 速度极慢，遇到复杂的布局经常超时

• 某些情况无法选中指定的 View

本文将围绕 LayoutInspector 的痛点，分析问题并修复，最终将 LayoutInspector 变成一个稳定、好用的插件。

二、加速 Dump View Hierarchy

---

2.1 问题描述

开发复杂业务的同学在使用 LayoutInspector 时都遇到过上图所示的错误：由于 View 树结构复杂超时。网上也有其他相关的解决办法，原理就是修改 timeout 的值，目前默认值是 20s，所以改成 1min，大概率是可以的了。

为了更好的解决这个问题，比如是否能加速？我们看一下整个 LayoutInspector 抓取的流程。梳理流程之前，我们需要找到功能的入口。

2.2 问题分析

2.2.1 Dump 总流程

平常开发者使用 LayoutInspector 的流程一般如下：

1. 和 Attach debugger 类似，先获取要 LayoutInspector 的进程

2. 如果进程中不止一个 ViewRootImpl，还需要选择 window

在 IDEA Plugin 框架体系中，大多数插件的功能入口都依赖 Action，上图 LayoutInspector 的功能入口对应的 Action 如何找到呢？最快速、准确的办法就是 Debug，在我们点击功能入口之前，在 AnAction#actionPerformed 加上断点。

从 AndroidRunLayoutInspectorAction 出发，我们找到了真正的任务：

LayoutInspectorCaptureTask。

抓取 View 视图的关键方法如下：

我们可以看到这里先构造了一个 Options，Opentions 中有个参数：ProtocolVersion，目前我们能使用的是 ProtocolVersion.Version1，Goolge 内可以通过 StudioFlags 打开 ProtocolVersion.Version2。

capture view 的流程会比较长，涉及到 adb 通信原理，我们先简单了解一下 adb 通信架构。

• adb server: 运行在我们的 PC 开发机上，监听 5037 端口

• adb daemon: 运行在 Android 设备上

• adb server 通过 USB/tcp 和 adbd 通信

了解了基本的 adb 通信基础之后，我们再来看整个 captureview 的原理：

1. 通过 ClientWindow 发起 loadWindowData 的请求（在这里可以看到默认超时时间是 20s）

2. ClinetImpl 收到请求，让 HandleViewDebug 将本次请求封装成 JDWP，然后准备发送

3. ClientImpl 将数据先发送给本 PC 上的 adb server

4. adb server 将数据通过 usb/tcp 透传给 Android 设备上的 adbd

5. Android 设备上的 adbd 根据之前选择的进程信息，将信息再透传给指定的 jdwp 线程

6. jdwp 通过 native 调用 DDMServer 方法

7. DdmHandleViewDebug 收到请求开始处理

8. 处理完请求后，再通过 socket 返回，LayoutInspector 收到结果解析后展示

参考：debugger.cc

• https://android.googlesource.com/platform/art/+/android-cts-5.0_r9/runtime/debugger.cc#3778

2.2.2 dump v1 原理

在上图的流程中可以看到在最后的调用中，有 dump 和 dumpv2 两个方法，而且 dump 方法已经废弃了。

源码 ViewDebug.java：

看源码我们知道 v1 dump 是获取被 @ExportedProperty 注解作用的 filed 和 method，然后将这些数据写入 ByteArrayOutputStream。比如 View的 padding 属性：

当然也有 method:

上面两图中的 category: padding 和 focus 体现在 LayoutInspector 的属性面板中：

上面看源码的结论：v1 是通过反射遍历所有的 Filed 和 Method。

在我的手机 One Plus7 Android 10 上，View 的 filed 有 487 个，method 有 915 个。写一段简单的代码展示一下仅遍历耗时：

输出：

D/View#dump: 10705ms and 692 views

可以看到我们还没有添加逻辑，仅仅遍历耗时都达到了 10s。

2.2.3 dump v2 原理

看 ViewDebug#dumpv2:

调用到了 View#encode:

相比 v1，v2 就很克制了，只返回有限的数据，需要什么数据就获取什么数据，但不支持自定义的属性，相当于牺牲了一定的灵活性，加快了 dump 的速度。在灵活性、速度两个方面，Google 将 v1 和 v2都保留了，并通过 StudioFlags 提供了开关。

2.3 解决方案

对比完 v1 和 v2 之后，基本可以确定 v2 的速度会快很多了。我们通过自定义 Action，并替换掉原生的 LayoutInspectorCaptureTask，关键是替换下面这个方法：

2.3 效果&收益

【附】相关架构及资料

往期Android高级架构资料、源码、笔记、视频。高级UI、性能优化、架构师课程、NDK、混合式开发（ReactNative+Weex）微信小程序、Flutter全方面的Android进阶实践技术，群内还有技术大牛一起讨论交流解决问题。
《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》，点击传送门，即可获取！
…(img-lyyNlxmX-1715246832985)]

[外链图片转存中…(img-XBM3iAIo-1715246832985)]

往期Android高级架构资料、源码、笔记、视频。高级UI、性能优化、架构师课程、NDK、混合式开发（ReactNative+Weex）微信小程序、Flutter全方面的Android进阶实践技术，群内还有技术大牛一起讨论交流解决问题。
《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》，点击传送门，即可获取！