一、認識鴻蒙

鴻蒙 微核心是基於微核心的全場景分散式OS，可按需擴充套件，實現更廣泛的系統安全，主要用於物聯網，特點是低時延，甚至可到毫秒級乃至亞毫秒級。

鴻蒙OS實現模組化耦合，對應不同裝置可彈性部署，鴻蒙OS有三層架構，第一層是核心，第二層是基礎服務，第三層是程式框架 。可用於手機、平板、PC、汽車等各種不同的裝置上。還可以隨時用在手機上，但暫時華為手機端依然優先使用安卓、華為電腦端依然優先使用windows和Linux。

華為對於鴻蒙系統的定位完全不同於安卓系統，它不僅是一個手機或某一裝置的單一系統，而是一個可將所有裝置串聯在一起的通用性系統，就是多個不同裝置比如手機、智慧屏、平板電腦、車載電腦等等，都可使用鴻蒙系統。

此次手寫架構，解決的問題是：

1、讓 App內 各個功能模組能夠獨立開發單元測試，也可以 所有模組整合打包，統一測試

獨立開發
更改gradle.properties的配置，使得每個功能模組都成為application， 可以獨立打包成apk，單獨執行。單個模組，獨立測試。

整合打包
更改gradle.properties的配置，使得原先每個單獨模組，都變成library，被 主模組引用，這時候只有主模組能夠打包apk，所有功能都整合在這個apk內。

2、實現 功能模組的整體移植，靈活拔插

故事背景
當你們公司有多個安卓開發人員，開發出核心業務相同，但是UI不同，其他業務不同的一系列App時（如果核心業務是X，你們有5個開發人員，做出了A,B,C,D,E 5個app，都包含核心業務X，但是除了X之外，其他的業務模組各不相同）這時候，如果領導要把A裡面的一個非核心功能，挪到B裡面...

現狀
開發B的程式猿可能要罵娘，因為他在從移植A的程式碼中剝離程式碼 遇到了很多高耦合，低內聚 的類結構，挪過來之後，牽一髮而動全身，動一點小地方，整個程式碼滿江紅。

理想
如果這個時候，我們通過程式碼框架的配置，能夠把A裡面的一個模組，作為一個module 移植到 工程內部，然後主module 來引用這個module，略微寫一些程式碼來使得這個功能模組在app中生效。那麼無論是多少個功能模組，都可以作為整體來 給其他app複用。這樣開發人員也不用相互罵娘了，如果挪過來的模組存在bug或者其他問題，也不用甩鍋，模組原本是誰開發的，找誰就好了。

3、保證App內 業務模組的相互隔離，但是又不妨礙業務模組之間的資料互動

我們開發app的功能模組，一個業務，可能是通過一個Activity或者 一個Fragment 作為對外的視窗,也可能是。所謂視窗，就是這個業務，相對於其他模組，"有且只有"一個入口，沒有任何其他可以觸達到這個業務的途徑。業務程式碼之間相互隔離，絕對不可以有相互引用。那麼，既然相互不會引用，那A模組一定要用到B模組的資料，怎麼辦呢？下文提供解決方案。

正文大綱

1、程式碼結構現狀以及理想狀態一覽

2、功能元件化的實現思路，實現元件移植拔插

3、參考ARouter原始碼，寫出自己的Router框架，統一通過Router來進行模組的切換 以及 元件之間資料的互動

4、使用元件api化，在模組很多的情況下優化公共模組的結構

正文

1、程式碼結構現狀以及理想狀態一覽

現狀；

程式碼有模組化的跡象，但是沒有對業務模組進行非常明顯的模組化（不明白啥意思是吧？不明白就對了，app這個module裡面其實還有很多東西沒有展示出來，請看下圖：試想，把所有的模組集中到一個module的一個包裡面，當你要移植某一個功能的時候，想想那酸爽....當然如果你口味別緻，那當我沒說）

理想：

理想化的話，參照：理想.png; 專案結構層次分明，脈絡清晰

按照圖中的分層，詳細解釋一下：

外殼層：app module

內部程式碼只寫 app的骨骼框架，比如說，你的app是這個樣子的結構：

下方有N個TAB，通過Fragment來進行切換模組。這種架構肯定不少見。

這個時候，外殼層 app module，就只需要寫上 上面這種UI架構的框架程式碼就行了，至於有多少個模組，需要程式碼去讀取配置進行顯示。你問我怎麼寫這種UI框架嗎？網上一大把的，如果實在找不到，來我的 github

業務層

我們的業務模組，對外介面可能是一個Activity* *（比如說，登入模組，只對外提供一個LoginActivity,有且僅有這一個視窗）或者 是一個Fragment，就像上圖（典型的app架構.png）, 如果app的UI框架是通過切換Fragment來卻換業務模組的話。用business這個目錄，將所有的業務模組包含進去，每個模組又是獨立的module，這樣既實現了業務程式碼隔離，又能一眼看到所有的業務模組，正所謂，一目瞭然。

功能元件層

每一個業務模組，不可避免的需要用到一些公用工具類，有的是第三方SDK的再次封裝，有的是自己的工具類，或者自己寫的自定義控制元件，還有可能是 所有業務模組都需要的 輔助模組，都放在這裡。

路由框架層

設計這一層，是想讓app內的所有Activity，業務模組Fragment，以及模組之間的資料互動，都由 這一層開放出去的介面來負責

gradle統一配置檔案

工程內部的一些全域性gradle變數，放在這裡，整個工程都有效

module編譯設定

setting.gradle 配置要編譯的module; 也可以做更復雜的操作，比如，寫gradle程式碼去自動生成一些module，免除人為建立的麻煩.

總結

最後小編想說：不論以後選擇什麼方向發展，目前重要的是把Android方面的技術學好，畢竟其實對於程式設計師來說，要學習的知識內容、技術有太多太多，要想不被環境淘汰就只有不斷提升自己，從來都是我們去適應環境，而不是環境來適應我們！

這裡附上我整理的幾十套騰訊、位元組跳動，京東，小米，頭條、阿里、美團等公司19年的Android面試題。把技術點整理成了視訊和PDF（實際上比預期多花了不少精力），包含知識脈絡 + 諸多細節。

由於篇幅有限，這裡以圖片的形式給大家展示一小部分。

詳細整理在Gitee可以見；

Android架構視訊+BAT面試專題PDF+學習筆記

網上學習 Android的資料一大堆，但如果學到的知識不成體系，遇到問題時只是淺嘗輒止，不再深入研究，那麼很難做到真正的技術提升。希望這份系統化的技術體系對大家有一個方向參考。

技術進階之路很漫長，一起共勉吧~