轉載請註明出處:王亟亟的大牛之路
有差不多接近一個多月沒發文了，最近事情比較多。各種會，寫各種計劃，解決各種問題，以及團隊內部擴招那些事(每天郵箱各種簡歷眼花繚亂)
先安利:我的Git 之後會把內容都往git book等地方遷移，所以對我寫的東西感興趣的小夥們可以follow我的git,以獲取最新內容！
對架構的理解
最近聊了許多小夥報價從高到低的各式各樣的都有(這裏只是舉個例子，沒有任何貶低的意思)
一提架構張嘴就來 MVC MVP MVVM等等等，如果簡歷寫有大項目的架構經驗並且要價偏高的我一般默認這樣的小夥不是太可用(先看，別急後面有解釋),或者說你之前的項目”不夠大”。
如果要價不是很高，經驗不是寫的很豐富的話那我還可以理解。
爲什麼這麼”默認”？
- 太籠統
MVC那套從寫Web時期就一直使用至今，你抓個寫java web的也能給你說的頭頭是道,紙上談兵沒有實際意義 - 實用性不足
每個”重量級”的項目都有不同的實現方式，簡單的拿幾個英文單詞硬套是否真的合理,真的適合自己的應用場景 - 知識點滯後
從國內android/iOS熱更(組件化)大潮(15年)出現後各式各樣基於分包,插件化等等的內容層出不窮，還指望一套架構吃死那是不可能了。
簡易組件化設計
把共同屬性的代碼提取出來製作成各種基礎庫,把單獨的功能封裝成Library包，不同業務通過分包結構分到不同module下，組內每人開發自己的module。
把純業務模塊和非業務模塊以及一些”剛需”的代碼做了簡易的分包，庫與庫之間的關係看似很完美
寫各個模塊的小夥伴們可以各做各的，沒有任何交集
於是有一天，來了個不可描述的場景
(只是舉例子)
直到有一天產品說，我們要集成 TalkingData，我們要Ui庫的各個控件必須做埋點！
那怎麼辦？
ui庫的小夥伴去依賴 第三方統計庫，去寫裏面的埋點業務
還有,ui組件的細節我要計算(你別管合理不合理，產品就說要算,我們就模擬這是個必做的業務)
ui庫還得去依賴工具庫，然後這個架構圖成了這樣
這只是一輪迭代，後面還有各種不可描述的複雜姿勢，導致最後你的項目又一團糟，可維護性又像所有代碼在一個包裏那樣差了
基於”路由的架構設計”
經過重新設計後大致長這樣
因爲基礎功能庫確實是一個被依賴可能性極大的庫所以我們讓他依賴着”路由”庫
所有的子包，包括主項目都去依賴這個庫，而基礎功能庫依賴於工具庫和”路由”庫
工具庫放進去的意義就不說了，貫穿整個app過程都有大概率調用工具類，無論是主項目還是子工程包
着重說一下這個”路由”體系對於各個包/內容的意義
對於頁面:
提供統一的跳轉規則,更可控的跳轉攔截，更大的延展性等等等(這部分可以看我之前寫的一篇關於ARouter的文章:http://blog.csdn.net/ddwhan0123/article/details/54409574)
對於子包:
所有的包之間的相互調用關係就不存在了，耦合性降低，所有的通信統一都交給路由來處理分發(並且持有規則)，而註冊工作則交由主工程去進行初始化。無論子包怎麼變化(數量與內容)，只要在統一的路由規則下都可以暢通無阻地運行，而不是改一處則動全身！
在子包的概念裏，路由是規則，是關係鏈。
這麼做的目的很簡單
- 可測試性增強–只測自己想測的包就行，根本不用管其他包的關係鏈
- 複用性增強–類似的基礎組件可以在不同的事業羣下使用
- 支持並行開發–你寫你的我寫我的
- 耦合降低–除了基礎庫外，其他庫沒有了依賴關係
該設計不考慮多進程場景，龐大集羣項目需另外考慮考慮
更多架構選擇/知識點:
https://github.com/googlesamples/android-architecture
http://www.infoq.com/cn/articles/ctrip-android-dynamic-loading
http://www.open-open.com/lib/view/open1436316754208.html
http://keeganlee.me/post/architecture/20160222
有問題可以聯繫我：
