前言:不知道你們是否是像我沒作模塊化、組件化以前同樣,感受這個架構是一個很高深、很複雜的東西,作起來應該很難,其實作過以後你會發現模塊化、組件化不過如此。這篇文章我將會向你們分享一下與模塊化、組件化的一些知識,相信當你讀過這篇文章後,你也會覺的模塊化、組件化不過如此。緩存
本文的結構以下圖,文章將會圍繞下圖列出的幾點來詳細的講解模塊化、組件化的知識。網絡
模塊化、組件化是一種架構思想、與平臺無關的一種解耦手段。爲何咱們老是把模塊化、組件化放在一塊兒呢?由於它們之間的關係是你中有我,我中有你的關係。就好比,咱們將一個app拆分紅幾個功能模塊,這幾個模塊確定會依賴一些公共的組件,如網絡組件、圖片組件、音視頻組件等,而這些組件中可能又會細分出一些模塊,如圖片組件中的,下載模塊、緩存模塊等。若是非要將它們兩個區分開來,可能就是下面的定義:架構
項目作的好好的,爲何要將項目改爲模塊化、組件化的架構呢?緣由以下:app
將項目改爲模塊化、組件化的架構,就是爲了解決上面出現的問題。模塊化
其實不是每個項目都應該有模塊化、組件化的架構的。好比,咱們作了一個小項目,這個項目的功能不多,而且之後也不會增長新功能,一我的開發這個項目徹底沒問題,在這種狀況下,若是再用模塊化、組件化的架構,簡直就是殺雞用牛刀、勞命傷財。工具
在咱們將項目模塊化的時候,就會面臨怎麼拆分模塊的問題,因此在拆分模塊化的時候就要遵循一些原則,須要遵循的原則就是組件化
爲何要說這兩個原則呢?由於在模塊化的時候你可能會遇到不知道將某段代碼應該放在哪一個模塊中的問題,這時你就根據上面的原則來判斷應該將代碼放在上層仍是下層或則應該放在哪一個模塊中。code
解釋一下上面的兩個原則,看下圖模塊化開發
從圖中能夠看到,這裏將模塊化分紅了四層,「同層之間不能相互依賴」這個原則,就是說在同一層的各個模塊之間不能有依賴的關係,如在「業務功能模塊」這一層可能會有幾個功能模塊,這幾個功能模塊之間是不能有依賴關係的。「只能上層模塊依賴下層模塊,下層模塊不能依賴上層」這個原則就是不能讓層級在下面的模塊依賴上層的模塊,若是有依賴關係,應該將被依賴的模塊放在依賴模塊的同層或則下層。cdn
關於這個問題呢,並無明確的答案。通常採用的作法就是將一些公用的而且不會變更或者不常改動的功能放在基礎庫中,如網絡請求、圖片加載及一些工具類等。基礎組件着一層呢,就是放置一些第三方的SDK,如支付、統計、bug收集等。業務功能模塊這一層就是放置咱們項目功能有關的代碼,這一層的拆分關係到之後開發的耦合度,所以要慎重,固然最合理就是一個功能拆分紅一個模塊,但這樣就會出現拆分的粒度過小的問題,因此關於這一層的拆分最好是團隊內討論決定。最上面的一層就是app的殼了,這一層通常不會有什麼功能,就是用來初始化項目,Android項目通常會將應用的application類放置在這層。
從上面模塊間劃分的原則,能夠知道,同層模塊之間是不能相互依賴的,這就會出現「不能依賴,模塊間怎麼通信的問題?」舉個例子,在兩個模塊之間,若是一個ActivityA要跳轉並傳值給ActivityB,應該怎麼傳值呢?沒有模塊化的時候能夠經過stratActivity
或則startActivityForResult
方法來顯式跳轉界面完成傳值,可是在模塊化開發時,可能ActivityA在A模塊裏ActivityB在B模塊中,由於模塊A和模塊B在同一層,沒有依賴關係,就不能直接傳值了,那怎麼解決這個問題呢?答案就是用路由的方式,在Android中通常是用ARoute開源庫,使用這個庫後只要定義好跳轉的路徑就好了,在打包app後就會根據定義好的路徑找到對應的界面,關於具體的使用方法,你們能夠自行搜索。
本文主要的內容是將模塊化的思想說明了一下,本文的目的是讓你們再也不認爲模塊化是一個很難的架構,再也不會由於以爲模塊化是一個比較高深的東西而不敢嘗試。若是在項目開始的時候不考慮模塊化,那麼隨着項目的發展總有一天你會採用這個架構的,等項目大起來之後從新修改架構就不是那麼容易了。但願你們在作項目的時候不要欠下技術債,若是技術債是不可避免的,那麼應該儘早的償還。
文中並無講解模塊化的具體實現,關於具體的實現細節網上已經有不少的文章了,能夠根據本身的須要自行了解。本文主要就是讓你們領會模塊化的思想,理解思想以後,剩下的就是去實踐了,相信讀過本文以後,你作起模塊化必定會事半功倍。
本文已由公衆號「AndroidShared」首發