滴滴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來保證頁面的一致性。

三、一機多控何時開源？

一機多控何時開源這多是你們比較關心的話題。由於DoKit的一機多控如今還處於比較早期的階段，包括上面說的幾個場景規劃咱們都尚未實現，因此暫時還不具有開源的條件。可是你們請放心，DoKit做爲一個負責任的團隊，一旦咱們的一機多控在業務方那邊獲得落地和驗證，並能顯著的爲業務方創造價值的時候，咱們必定會第一時間開源。哪怕最後一機多控在業務落地中並無創造出屬於它的價值，我應該也會將它做爲一個學習項目開源給你們。DoKit一直都秉持滴滴的開源精神，但願輸出最優秀的解決方案來給到社區。最因此請你們敬請期待咱們的官方消息。

四、大家DoKit爲何總能想出這麼多好的點子的？又是怎麼去決定要去作哪個的？

我我的對於DoKit的定義是：DoKit是一個創意密集型的開源工具。

因此咱們平時決定作什麼(包括功能調研、價值評估、技術驗證等等)的時間佔了整個功能週期的大部分，真正的編碼時間反而並無那麼多。 那麼咱們是怎麼保證咱們輸出的每個功能都是有價值的呢？ 咱們平時在工做之餘一直和社區以及業務方保持的充分的溝通，積極的聽取你們的意見和建議。深刻的理解研發過程當中的各類痛點，主動的去思考相應的解決方案。同時咱們不提倡重複造輪子，假如社區有中已經有了相應的解決方案，咱們也會積極的在別人的基礎上進行優化和迭代，這也是開源的精神。截止到目前DoKit在終端上已經有了超過30+的功能，同時保證了在Android和iOS兩端保持功能同步，這些功能都獲得了集團和社區小夥伴的驗證。隨着用戶和影響力愈來愈大，咱們的壓力也愈來愈大，咱們不但願辜負你們對咱們的期待。咱們固然知道現階段的DoKit還不是很完美。因此但願你們對於DoKit多些包容和建議，咱們渴望聽到你們的聲音。

五、DoKit接下來的規劃是什麼樣的？

現階段DoKit在終端上的探索已經慢慢趨於穩定，因此咱們但願在不一樣的領域上也能有所突破，好比:DoKit For Flutter、DoKit For Web等等。 因此假如你有特別好的想法，就差程序員了，那還等什麼，趕快給咱們提建議吧。只要大家敢想，咱們就敢嘗試，你的創意將有可能爲整個社區作出巨大的貢獻。

總結

DoKit一直追求給開發者提供最便捷和最直觀的開發體驗,同時咱們也十分歡迎社區中能有更多的人蔘與到DoKit的建設中來並給咱們提出寶貴的意見或PR。 DoKit的將來須要你們共同的努力。 最後，厚臉皮的拉一波star。來都來了，點個star再走唄。DoKit