從模塊化到組件化再到插件化


從模塊化到組件化再到插件化

參考:

http://blog.xiaohansong.com/2015/10/21/IoC-and-DI/

http://blog.csdn.net/dd864140130/article/details/53645290

http://blog.csdn.net/smallspot/article/details/52221049

https://github.com/SpinyTech/ModularizationArchitecture

https://github.com/wutongke/ModularizationArchitecture

 

 

最近公司的項目從平台開發專向了針對平台開發,對此,我們作為開發人員理應當開始設計新的思路去面對公司今后的戰略轉型。於是,我們就希望項目能定制化功能,通過后台配置去加載相應的模塊。為此看了一些相關內容。

控制反轉,依賴注入:

耦合結構和解耦結構

目前我的項目的結構如下圖所示,因為intent跳轉和一些數據共享的關系導致的。


解耦合之后的結構:


 

解耦思想

控制反轉是一種思想

依賴注入是一種設計模式

IoC框架使用依賴注入作為實現控制反轉的方式

 

模塊化開發

將一個程序按照其功能做拆分,分成相互獨立的模塊,以便於每個模塊只包含與其功能相關的內容。模塊我們相對熟悉,比如登錄功能可以是一個模塊,搜索功能可以是一個模塊,汽車的發送機也可是一個模塊。

 

組件式開發

基於可重用的目的,將一個大的軟件系統按照分離關注點的形式,拆分成多個獨立的組件,已較少耦合。

將一個app分成多個模塊,每個模塊都是一個組件(Module),開發的過程中我們可以讓這些組件相互依賴或者單獨調試部分組件等,但是最終發布的時候是將這些組件合並統一成一個apk,這就是組件化開發。

正常一個App中可以有多個module,但是一般只會有一個module是設置為application的,其他均設置為library,組件化開發就是要每個module都可以運行起來,因此在開發期間(Debug版本)每個module均設置為application,發布時(Release版本)設置為libs再進行合並。

組件可以分為兩大類,一類是application組件,一類是libs組件,application組件是一個可運行的app。libs組件可以作為application的依賴,但是自身不可作為程序運行的存在。

模塊化粒度更小,更側重於重用,而組件化粒度稍大於模塊,更側重於業務解耦

組件化想要解決的問題:

1.       實際業務變化非常快,但是工程之前的業務模塊耦合度太高,牽一發而動全身.

2.       對工程所做的任何修改都必須要編譯整個工程

3.       功能測試和系統測試每次都要進行.

4.       團隊協同開發存在較多的沖突.不得不花費更多的時間去溝通和協調,並且在開發過程中,任何一位成員沒辦法專注於自己的功能點,影響開發效率.

5.       不能靈活的對工程進行配置和組裝.比如今天產品經理說加上這個功能,明天又說去掉,后天在加上.

組件開發比較常見的問題是業務組件的相互引用:


為此我們可以通過路由/總線的方式去處理:


掛載到組件總線上的業務組件,都可以實現雙向通信.而通信協議和HTTP通信協議類似,即基於URL的方式進行.

 

插件化開發

Android應用程序的.Java文件在編譯期會通過javac命令編譯成.class文件,最后再把所有的.class文件編譯成.dex文件放在.apk包里面。那么動態加載就是在運行時把插件apk直接加載到classloader里面的技術。

關於代碼加載,系統提供了DexClassLoader來加載插件代碼。開發者可以對每一個插件分配一個DexClassLoader(這是目前最常見的一種方式),也可以動態得把插件加載到當前運行環境的classloader中。

相對於組件化開發主要要解決的問題:

1.       宿主和插件分開編譯

2.       並發開發

3.       動態更新插件

4.       按需下載模塊

5.       方法數或變量數爆棚

這個坑有點多。


注意!

本站转载的文章为个人学习借鉴使用,本站对版权不负任何法律责任。如果侵犯了您的隐私权益,请联系我们删除。



 
粤ICP备14056181号  © 2014-2021 ITdaan.com