滴滴DoKit一机多控，代码零侵入框架-InfoQ



 写点什么

项目背景

前不久，滴滴城运服(原滴滴普惠)泛前端终端技术部开源了一个跨端方案 Hummer&Tenon，一套代码可以同时支持开发 Android 和 iOS 应用，极大提高了研发效率。但研发效率的提升却给质量部门带来了压力。研发同学缩短研发周期就意味着单位时间内质量部门的同事需要做更多的版本功能回归以及兼容性测试。

基于此背景，滴滴代驾质量部门一位同事给我们提出了一个需求，希望 DoKit 团队能帮忙输出一套解决方案：帮他们提升功能回归以及兼容性的效率。本着技术驱动业务发展的企业精神，DoKit 团队开展了深入研究。功夫不负有心人，目前针对该问题解决方案，DoKit 团队有了一定的阶段性成果。

阶段性成果

一机多控阶段效果如下:

备注: DoKit Android 的一机多控相对于其他的解决方案来说不需多余的系统权限，无需 PC 端配合。此外，我们也保证了业务代码零侵入的原则，唯一的要求就是主机和从机要在同一局域网内，然后你只需和平时一样随心所欲地操作主机 App 即可，剩下的都交给 DoKit。

前段时间，我在 DoKit 开源社区群与大家聊起近期 DoKit 规划话题。收到一些反馈，比如：最近 DoKit 都没有发布什么新的功能。

于是我将近期研究的 DoKit 一机多控演示 Demo 视频在社群内同步了一下。超出预料的是：大家看完视频后都表现出强烈的兴趣，并在社群内开展一定的讨论。除此之外，很多社区及集团内的朋友都私聊我问我该技术原理是什么、应用场景有哪些、准备时候开源等等。

思考良久，既然大家对于 DoKit 的一机多控如此感兴趣，不如我直接写一篇文章来统一更新一下 DoKit 近期的成果，同时也统一回答一下大家较为感兴趣的问题。

问题解答

这里我选取了几个比较有代表性的问题。

问题 1：一机多控的技术原理是什么？

受限于篇幅的原因，我这里就不展开讲相应的源码实现了。只是大致的提一下相应的原理，主要分为三步：

Android 主机控件相对于 window 的路径获取
基于局域网长连接的控件信息传递
从机控件定位以及手势模拟。

对于一机多控的技术实现我尝试过好几套方案，但始终不能很好的解决如何在主机上精确的获取到具体是哪个控件消费了此次手势事件。直到有一天我在浏览 Android Framework 源码的发现了一个 API，由此扣开了一条通往一机多控新世界的大门。这里顺便分享给大家：

View#sendAccessibilityEventUnchecked

问题 2：一机多控的使用场景是什么？

最近我一直在思考这个问题：一机多控除了能够帮助质量部门的同事提升功能回归的效率和兼容性测试以外，能不能有更多的挖掘与探索？

通过我和团队成员深入交流，我发现一机多控本身的价值已经显而易见，但是我们在实现一机多控过程中涉及到众多知识点其实能够帮助我们实现更多特别有想象力的功能。比如:

全局用户行为路径无痕埋点

这点其实和一机多控的原理一样。一机多控就是基于事件驱动在主机上定位控件然后在从机上针对具体的手势行为进行模拟，所以我们对于用户的操作行为的获取肯定是十分准确的。

用户行为录制和回放

相对于埋点的文字描述形式，基于 DoKit 的用户行为录制和回放对于业务方来说其实特别友好和直观，因为那是最真实的用户操作行为。可能很多人会问，对于 C 端用户来说，每个人的页面 UI 表现形式大部分是通过接口返回的数据来决定的，这就可能导致有些运营页面的 UI 表现形式是不一样的，那 DoKit 拿什么来保证我的回放是准确的？

如果你是 DoKit 的深度用户或者对 DoKit 很感兴趣的话，你应该知道 DoKit 是有接口抓包和接口 Mock 功能的，当我们把用户的行为录制和接口抓包、接口 Mock 打通，我们应该能保证 90%以上的页面表现形式是一致。

具体的操作：当用户在平时的操作过程中遇到问题的时候，我们可以要求用户打开我们隐藏的用户行为录制开关，然后我们会记录下这段时间内用户的所有手势行为以及相关的接口数据，然后将两者统一打包上传到后台。此时，我们可以在另一台手机上将相应的用例数据包下载并解压，再去执行相应的手势行为并配合数据 Mock 来保证页面的一致性。