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