子曾經曰過，有鴻蒙，一切皆有可能。
世界上之所以戰火不斷
衝突加劇
根源就是
分歧得不到公正的裁決
我們小時候都玩過一種遊戲
錘子剪刀布
其實那是一種解決分歧
最原始最有效的方法
可是爲什麼我們長大了以後
就不用這種方法了呢？
因爲他有兩個弊端
一個是出手的快慢
另一個就是臨時變換手型
分歧終端機的問世
一舉解決了這個難題
那麼，問題來了
這麼好的一個跨時代的產品
爲什麼沒有得到推廣呢？
因爲它有兩個弊端：
一個是不方便攜帶
另一個是……貴（劃掉）……不開源
開源的鴻蒙分佈式分歧終端機的問世
一舉解決了這個問題
那麼，構建這樣一款鴻蒙分佈式分歧終端機**原型**，需要多長時間呢？
10分鐘？
不，
大概要……
一個週末吧。
具體需要三個步驟：
第一步，先把家裏的娃哄好
第二步，打開電腦寫 Bug（劃掉）代碼
第三步，調試，如果有問題，重複第二步
萬事開頭難，第一步永遠是最難的。
處理好了第一步以後，後兩步就簡單了，我們來具體分析一下鴻蒙分佈式分歧終端機原型的設計原理。
# 鴻蒙分佈式分歧終端機原型的設計
## 首先，需求分析
1). 可以**輸入**各自的決策
2). 由中立第三方進行**裁決**
3). 可以**查看**最終的裁決**結果**
## 其次，模塊劃分。
根據需求，利用鴻蒙的分佈式設計思想，我們將分歧終端機分爲兩個核心模塊：
1). 分歧終端機的交互模塊，簡稱FA，用於輸入決策和查看結果
2). 分歧終端機的計算模塊，簡稱PA，作爲中立第三方，做出最終裁決
## 再次，流程。
假定有A和B兩人發生分歧，需要解決分歧，那麼分歧解決的一個典型流程可以這樣子：
1). A 啓動分歧終端機的交互模塊（FA-A）
2). B 啓動分歧終端機的交互模塊（FA-B）
3). A 和 B 都連接到同一個分歧終端機計算模塊，假定是計算模塊A（PA-A）
4). A 和 B 在各自的分歧終端機的交互模塊上輸入他和她的決策（INPUT-A，INPUT-B）
5). 分歧終端機的計算模塊自動根據 A 和 B 的輸入，計算出結果：RESULT
6). A 和 B 在各自分歧終端機的交互模塊上查看結果RESULT，假如B對結果不滿意，可以進行再次裁決，直到她滿意爲止。
## 再次，詳細設計。
### 1. 分歧終端機交互模塊（FA）
交互模塊需要向使用者提供輸入接口和顯示界面，所以使用的是鴻蒙的FA，也就是 Feature Ability。
FA 也叫Page Ability，而一個Page可以有多個Ability Slice（能力切片），也就是子頁面：
根據決策過程的不同階段，我們利用Ability Slice設計3個子頁面，分別是：
* 1). 初始準備頁面，HomeSlice，用於連接分歧終端機計算模塊（PA）
這裏，我們會需要用到鴻蒙分佈式軟總線的
a). 設備自動發現能力
對於在同一個網絡下的鴻蒙設備，在滿足條件的情況下，可以自動互相發現，不需要調用網絡接口(udp/tcp等)，也不需要針對不同的網絡狀況(wifi/藍牙/nfc等) 做不同的實現。
b). 設備直連能力
通過connectAbility接口，可以直接連接需要連接的計算模塊，不要知道其所在設備的實際網絡情況。
* 2). 等待頁面，WaitingSlice，先加入分歧解決的人，需要在這個頁面上等待其他人加入。
當發現所有人都已經加入後，就自動進入下一個頁面，也就是“分歧決策頁面”。
* 3). 決策頁面，GameSlice，參與分歧解決的人在這個頁面上輸入自己的決策，並查看最終的裁決結果。
本模塊的技術要點：
1). 子頁面之間的切換：使用present方法
2). 決策結果的刷新：可以用計時器來輪詢結果，並刷新。
注意
在計時器中刷新UI時，相關代碼需要運行在UI線程上，可以使用EventRunner，參考代碼：
文章後續內容和附件可以點擊下面的原文鏈接前往學習
原文鏈接：https://harmonyos.51cto.com/posts/2216#bkwz
https://harmonyos.51cto.com/#bkwz