鴻蒙工程結構簡析

今天本來想在本地跑一下鴻蒙試試，但發現現在IDE只支援了Windows，就放棄了。不過還是可以紙上談兵的做下分析。看了眼官方檔案，現在還比較簡單。整體的感覺是和安卓的基本概念區別不大，比如和安卓元件的對應、元件的生命週期等，都讓人覺得很熟悉。當然這只是表現形式，比如對多語言的支援就和安卓拉開了區分度。另外讓我覺得比較有意思的還有鴻蒙app的工程解構：

從上面我感覺模組化和元件化應該是鴻蒙從一開始就考慮的。我猜測一下它可能帶來的優缺點：

• 更好的隔離：工程隔離，從而更好的支援業務隔離。比如對於一個比較龐大的app（可以參考我的另一篇文章 – 安卓app平臺的架構），可能每個子業務模組都可以作為一個單獨的Feature，從而減少互相之間的依賴。比如本地開發時可以只編譯Entry和自己所在的Feature, 從而減少編譯時間。測試的時候所在的Feature能有更好的獨立性。
• 更靈活的部署：鴻蒙官網將Feature描述為"應用的動態特性模組"，感覺應該可以支援動態部署和區域性熱更新，對於提高更新速度、減少更新代價（比如頻寬）以及增加新版本在使用者中的佔比都有優勢。同時也可以支援更靈活的組裝，比如針對某個市場或者某種硬體，在同一個app設定不同的Feature。
• 當然靈活性也會帶來其他方面的問題，比如各種版本相關的維護應該會是一個很大的挑戰，現在不止有app的版本，還有module的版本，還有module版本之間顯式（IDL）和隱式（業務）的互相依賴；再加上可能app還有不同flavor（上文提到的靈活組裝），處理起來應該會麻煩。
• 動態部署和熱更新也容易帶來監管的問題，比較難稽核釋出出去的內容。不過現在手遊裡熱更也很普遍，所以還是有很多先例可以研究。
• 還有一個比較細節的是系統如何對不同Feature之間的相同資源去重，又不影響它們的獨立性，也不影響app的效能（比如載入時長）。比如FeatureA和FeatureB同時都依賴於一個library，是不是需要防止最後工程裡存多份library，影響app size.