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

项目背景

前不久，滴滴城运服(原滴滴普惠)泛前端终端技术部开源了一个跨端方案 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 来保证页面的一致性。

问题 3：一机多控什么时候开源？

当前 DoKit Android 端的一机多控基础功能已经走通，我正在协调相关部门同事进行业务落地，当我们的一机多控在业务中得到验证以后我们会着手准备开源的事项并第一时间告知大家。

当然哪怕最后一机多控在业务落地中并没有创造出属于它的价值，我们团队也会争取将它作为一个学习实践项目开源给大家，因为整个一机多控项目中涉及到的众多知识点还是具有较大研究价值的。DoKit 一直都秉持滴滴的开源精神，希望给大家输出最优秀的解决方案。所以请敬请期待我们的官方消息。

问题 4：DoKit 是如何做到持续创新的？

DoKit 团队对于 DoKit 的定义是：DoKit 是一个创意密集型的效率工具平台。

所以我们平时决定做什么(包括功能调研、价值评估、技术验证等等)的时间占了整个功能研发周期的大部分，真正的编码时间反而并没有那么多。那么我们是怎么保证我们输出的每一个功能都是有价值的呢？

我们平时在工作之余一直和集团业务方以及社区保持充分的沟通，积极听取大家的意见和建议，深入理解研发过程中的各种痛点，主动去思考相应的解决方案。

同时我们不提倡重复造轮子，如果开源社区有中已经有了相应的解决方案，我们也会积极的在他人基础上进行优化和迭代，这也是开源的精神。目前为止，DoKit 在终端上已经有了超过 30+的功能，同时也在 Android 和 iOS 两端保持功能同步，这些功能都得到了集团和社区的验证。

随着用户和影响力越来越大，我们的压力也越来越大，我们希望能不辜负大家的期待。DoKit 团队知道现阶段的 DoKit 并不完美，感谢大家对 DoKit 的包容，也希望大家可以为 DoKit 提出宝贵建议，我们渴望听到大家的声音。

问题 5：DoKit 接下来的规划是什么样的？

现阶段 DoKit 在终端上的探索已经慢慢趋于稳定，但我们希望 DoKit 能在不同的领域上有所突破，比如:DoKit For Flutter、DoKit For Web 等等。假如你对此有特别好的想法，欢迎联系 DoKit 团队。你的创意将有可能为整个社区做出巨大的贡献。

总结

DoKit 一直追求给开发者提供最便捷和最直观的开发体验,同时我们也十分欢迎开源社区中能有更多的人参与到 DoKit 的建设中来，为我们提出宝贵的意见或 PR。DoKit 的未来需要大家共同的努力。 

DoKit 项目 Github 网址: 

https://github.com/didi/DoraemonKit