滴滴 DoKit 阶段性成果汇报之一机多控

项目背景

Hello，社区里的小伙伴我们又见面了。前段时间我们滴滴普惠泛前端终端部开源了一个跨端方案Hummer&Tenon，一套代码可以同时支持开发 Android 和 iOS 应用，极大的推动了研发过程中的效率。但是于此同时，研发效率的提升却给质量部门带来了压力，我们研发同学缩短了研发周期就意味着单位时间内质量部门的小伙伴就需要做更多的版本功能回归以及兼容性测试。所以前段时间质量部门的小伙伴就找到了我们DoKit团队，希望我们能帮忙给出一套解决方案，帮助他们去提升功能回归以及兼容性的效率。本着技术驱动业务发展的企业精神，我一口就答应了下来，从此踏上了熬夜和掉发的不归路。在啃了几个礼拜的源码以及更换了四五套技术方案以后，终于有了一定的阶段性成果。一机多控效果演示



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



昨晚在群里闲聊的时候聊起了近期DoKit的规划，大家反馈好像最近没有发布什么新功能。于是我就把这个演示Demo视频在群里同步了一下，没想到大家看完视频以后都很有兴趣，在群里引起了一定的讨论，于此同时很多社区以及集团内的小伙伴都开始私聊我，问我什么时候开源、技术原理是什么、应用场景是啥等等。于是我想了一下不如直接写一篇文章来同步一下DoKit近期的阶段性成果顺便统一回答一下大家的问题。

问题解答

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

一机多控的技术原理是什么？怎么做到控件的唯一定位？

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

1）Android主机控件相对于window的路径获取

2）基于局域网长连接的控件信息传递

3）从机控件定位以及手势模拟。

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

public void sendAccessibilityEventUnchecked(AccessibilityEvent event) {
        if (mAccessibilityDelegate != null) {
            mAccessibilityDelegate.sendAccessibilityEventUnchecked(this, event);
        } else {
            sendAccessibilityEventUncheckedInternal(event);
        }
    }
复制代码

如果大家对于具体的技术原理特别感兴趣的话欢迎加入我们的社区群进一步交流，我们群里每天都会探讨各种前沿技术。

一机多控的使用场景是什么？



我最近也一直在思考这个问题，一机多控除了能够帮助质量部门的小伙伴提升功能回归的效率和兼容性测试以外，能不能有更多的价值和探索？通过我和团队内的小伙深入交流，我发现一机多控本身的价值已经显而易见，但是我们在实现一机多控过程中涉及到众多知识点其实能够帮助我们实现更多特别有想象力的功能。比如:



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

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



2) 用户行为录制和回放

相对于埋点的文字描述形式，基于DoKit的用户行为录制和回放对于业务方来说其实特别友好和直观，因为那是最真实的用户操作行为。可能很多人会问，对于C端用户来说，每个人的页面UI表现形式大部分是通过接口返回的数据来决定的，这就可能导致有些运营页面的UI表现形式是不一样的，那DoKit拿什么来保证我的回放是准确的？如果你是DoKit的深度用户或者对于DoKit很感兴趣的话，你们应该知道DoKit是有接口抓包和接口Mock功能的，当我们把用户的行为录制和接口抓包、接口Mock打通，我们应该能保证90%以上的页面表现形式是一致。具体的操作如下：当用户在平时的操作过程中遇到问题的时候，我们可以要求用户打开我们隐藏的用户行为录制开关，然后我们会记录下这段时间内用户的所有手势行为以及相关的接口数据，然后将两者统一打包上传到后台。此时，我们可以在另一台手机上将相应的用例数据包下载并解压，再去执行相应的手势行为并配合数据Mock来保证页面的一致性。



3、一机多控什么时候开源？

一机多控什么时候开源这可能是大家比较关心的话题。因为DoKit的一机多控现在还处于比较早期的阶段，包括上面说的几个场景规划我们都还没有实现，所以暂时还不具备开源的条件。但是大家请放心，DoKit作为一个负责任的团队，一旦我们的一机多控在业务方那边得到落地和验证，并能显著的为业务方创造价值的时候，我们一定会第一时间开源。哪怕最后一机多控在业务落地中并没有创造出属于它的价值，我应该也会将它作为一个学习项目开源给大家。DoKit一直都秉持滴滴的开源精神，希望输出最优秀的解决方案来给到社区。最所以请大家敬请期待我们的官方消息。



4、你们DoKit为什么总能想出这么多好的点子的？又是怎么去决定要去做哪一个的？

我个人对于DoKit的定义是：DoKit是一个创意密集型的开源工具。

所以我们平时决定做什么(包括功能调研、价值评估、技术验证等等)的时间占了整个功能周期的大部分，真正的编码时间反而并没有那么多。那么我们是怎么保证我们输出的每一个功能都是有价值的呢？我们平时在工作之余一直和社区以及业务方保持的充分的沟通，积极的听取大家的意见和建议。深入的理解研发过程中的各种痛点，主动的去思考相应的解决方案。同时我们不提倡重复造轮子，假如社区有中已经有了相应的解决方案，我们也会积极的在别人的基础上进行优化和迭代，这也是开源的精神。截止到目前DoKit在终端上已经有了超过30+的功能，同时保证了在Android和iOS两端保持功能同步，这些功能都得到了集团和社区小伙伴的验证。随着用户和影响力越来越大，我们的压力也越来越大，我们不希望辜负大家对我们的期待。我们当然知道现阶段的DoKit还不是很完美。所以希望大家对于DoKit多些包容和建议，我们渴望听到大家的声音。



5、DoKit接下来的规划是什么样的？

现阶段DoKit在终端上的探索已经慢慢趋于稳定，所以我们希望在不同的领域上也能有所突破，比如:DoKit For Flutter、DoKit For Web等等。所以假如你有特别好的想法，就差程序员了，那还等什么，赶快给我们提建议吧。只要你们敢想，我们就敢尝试，你的创意将有可能为整个社区做出巨大的贡献。

总结

DoKit一直追求给开发者提供最便捷和最直观的开发体验,同时我们也十分欢迎社区中能有更多的人参与到DoKit的建设中来并给我们提出宝贵的意见或PR。DoKit的未来需要大家共同的努力。最后，厚脸皮的拉一波star。来都来了，点个star再走呗。DoKit