淺談客戶端模組化
大學那會喜歡跟著老師在實驗室折騰，感覺每天都有新知識魚貫而入。
當我被告知要做一個最小微控制器系統的時候，興奮而又緊張！
最小微控制器系統示意圖：
學過微控制器的同學，應該都要經歷這一步，如果你沒有經歷趕緊行動起來。
從畫 ofollow,noindex">PCB 到制板、洗板，再到選擇元器件，最後組裝除錯和寫程式碼，我花費了兩個多月的時間，當板子上面的跑馬燈亮起來的那一刻，我激動的無法言語。
這個最小微控制器系統，大家可以看到上面有很多元件組成，有電阻、電容、電阻、二極體和卡槽等，當然還有最核心的元件就是微控制器，當時用的是51微控制器。
各個元器件就好比元件，功能單一，職責明顯，元件之間遵循協議可以構成模組，最終組合成為（最小微控制器）系統。
上面的回憶是為了引出今天的分享。
模組化和元件化
從程式設計的角度出發，無論是模組化還是元件化，都是指工程架構的範疇，是一種設計思想。兩者並沒有嚴格意義上面的區分，但是二者的目的一致，就是將工程結構化，達到可複用可伸縮的能力，最終提供工作效率。
在說模組化和元件化之前，先解釋一下什麼是高內聚低耦合。
高內聚：元件內儘可能獨立完成自己的功能，堅持自己的單一職責，不依賴於其他元件的程式碼。
低耦合：模組與模組之間儘量不要互相引用，模組之間聯絡越複雜耦合度越高，修改的成本就越高。
元件更加強調可替換可複用的特性，職責和功能比較單一、獨立，與其他元件之間沒有耦合性。
模組更加強調組合特性，更加偏重於業務，比如一個社群專案，登入註冊、論壇和個人中心都是模組，這些業務模組又是有很多個元件組合而成。
下圖展示的是一個簡易的論壇系統示例圖，如下：
可以看出，各個元件我可以單獨使用到其他模組當中，各個模組之間相對獨立，只要定義好模組之間的通訊協議，就可以做到並行開發，各個模組甚至可以服用到其他系統之中。
通訊機制
這裡說的通訊機制並不是指 HTTP 或 TCP 的通訊方式，而是指元件與元件之間，模組和模組之間的互動方式。
正常情況下，寫業務功能的程式碼，在不同元件之間，很多情況下需要 import 其他元件，這種無形之中就增加了元件之間的耦合度。
有開發經驗的同學，可能會用到類似 java 的反射機制，或者一些動態語言的執行時機制如 Objective-C，他們不進行 import，而是動態的解析程式碼，達到元件之間或者是類之間的呼叫。
另外一個比較通用的方式就是路由通訊機制，這裡舉一個實際使用場景。
使用者安裝了我們的 APP，運營同事希望在某個節日來臨之際做一個促活躍的活動，期望使用者點在開啟推送通知的時候，開啟 APP 的同時直接跳轉到對應的詳情頁面。大致流程如下：
這是一個再常規不過的需求了，相信經歷過產品開發的朋友都見過。
很顯然，我們可以使用類似路由的機制來完成這個需求，開發的流程圖大致如下：
這裡關鍵的核心得益於 iOS 和 Android 平臺的 scheme 機制，對於 scheme，通俗的講就是一種可以跨程序或者程序內的通訊協議。
例如下面的 URL：
bbs://page/activity/activity_detail?id=8978&user_id=67890432
其中， bbs 就是 scheme，可以看到該 URL 完全可以被各自平臺來解析。
iOS 和 Android 平臺各有很多開源的路由方案，實現手法各有差異，但是思想是一樣的，建議大家去了解和學習。
不過，現在你只要知道，路由的通訊機制大大降低了元件之間的耦合性就夠了。
外掛化
外掛化，將 APP 拆分成很多模組，這些模組包括一個宿主和多個外掛，宿主提供外掛的管理和通訊協議及規範，每個模組都是一個的庫或者功能包。
外掛化是一種程式設計和解決問題的思想，沒有統一的定義。
現在在 Android 上面運用比較多，iOS 上面很少，並不是 iOS 沒有這樣的技術，主要是因為蘋果稽核等各方面的限制。在 iOS8 上的 App Extension 功能，也可以看做是外掛化了。
在 Android 平臺中，外掛化已經不是很新鮮的技術了，VirtualAPK、Atlas、Replugin 等框架相繼開源，外掛化技術已經進入了比較成熟的階段了。
外掛，大家應該很熟悉，例如 Chrome 瀏覽器中可以安裝各種小工具，這些小工具就是外掛，還有各種開發使用的 IDE 也支援外掛安裝，便於提高我們的工作效率。Chrome 和 IDE 被稱之為宿主，外掛寄生於他們。
支付寶和微信裡面的小程式也可以看成是一個個外掛。
可以發現這些外掛即使被解除安裝或者被刪除，並不會讓 Chrome 或者 IDE 受到影響，換句話說，外掛讓宿主錦上添花。
這種外掛思想當然可以運用到 APP 中來，試想一下，如果某個 APP在線上經過動態下載就具有了一個強大或者好用的功能，豈不美哉？！
外掛化的程式設計思想和實現，在不同的平臺有所差異，即使在同一個平臺上面都會有不同的實現手段，建議選擇一個開源方案去了解原理，然後動手去實現一個，千里之行始於足下！
熱更新
“不好了，昨天有很多使用者反饋我們的 APP 出現閃退“ 小王一大早的開始撕喊，坐在他旁邊的開發大神們頓時微笑凝固，馬上去後臺看上報的崩潰日誌，緊接著開始復現和解決問題，最終得出結論，需要重新提審 APP，並周知渠道部門做好更新準備。
試想一下，如果一個遊戲幾G的大小，你讓使用者為了你的一個小失誤來整包更新遊戲，使用者和你估計都要瘋了。
最近幾年的熱更新技術也是得到了突飛猛進的發展，這也是業務發展的需求。類似於上面的場景，能在使用者神不知鬼不覺的情況下使用熱更新的技術解決崩潰的問題，豈不是兩全其美。
Android 的熱更新技術如火如荼的發展著，而蘋果這邊嚴厲禁止熱更新，一旦檢查到立即會責令你修改或者下架 APP。我們還是從技術的角度來看這個問題，學習和了解一下對應的技術總歸沒有錯， 這裡 有 iOS 上面的熱更新方案，另外 Android熱修復方案比較 介紹了很多 Android 熱更新的開源的方案，可以瞭解學習一下。
站在跨平臺的角度，我個人比較推薦使用 Lua 實現熱更新，Lua 不僅簡單高效，而且可以很好的和 C、C++ 結合在一起，而 Android 上面通過 JNI 又能與 C、C++ 通訊，iOS 上面就更加不用說了。這只是我個人的一點看法，不喜勿噴。
掃碼關注，你我就各多一個朋友~
