建站
咨詢
售后
建站咨詢
新聞中心
關(guān)于Android模塊化我有一些話不知當(dāng)講不當(dāng)講
最近公司一個(gè)項(xiàng)目使用了模塊化設(shè)計(jì)，本人參與其中的一個(gè)小模塊開發(fā)，但是整體的設(shè)計(jì)并不是我架構(gòu)設(shè)計(jì)的，開發(fā)半年有余，在此記錄下來(lái)我的想法。
模塊化場(chǎng)景
為什么需要模塊化?
當(dāng)一個(gè)App用戶量增多，業(yè)務(wù)量增長(zhǎng)以后，就會(huì)有很多開發(fā)工程師參與同一個(gè)項(xiàng)目，人員增加了，原先小團(tuán)隊(duì)的開發(fā)方式已經(jīng)不合適了。
原先的一份代碼，現(xiàn)在需要多個(gè)人來(lái)維護(hù)，每個(gè)人的代碼質(zhì)量也不相同，在進(jìn)行代碼Review的時(shí)候，也是比較困難的，同時(shí)也容易會(huì)產(chǎn)生代碼沖突的問(wèn)題。
同時(shí)隨著業(yè)務(wù)的增多，代碼變的越來(lái)越復(fù)雜，每個(gè)模塊之間的代碼耦合變得越來(lái)越嚴(yán)重，解耦問(wèn)題急需解決，同時(shí)編譯時(shí)間也會(huì)越來(lái)越長(zhǎng)。
人員增多，每個(gè)業(yè)務(wù)的組件各自實(shí)現(xiàn)一套，導(dǎo)致同一個(gè)App的UI風(fēng)格不一樣，技術(shù)實(shí)現(xiàn)也不一樣，團(tuán)隊(duì)技術(shù)無(wú)法得到沉淀。
架構(gòu)演變
在剛剛開始的時(shí)候，項(xiàng)目架構(gòu)使用的是MVP模式，這也是最近幾年很流行的一個(gè)架構(gòu)方式，下面是項(xiàng)目的原始設(shè)計(jì)。
隨著業(yè)務(wù)的增多，我們添加了Domain的概念，Domain從Data中獲取數(shù)據(jù)，Data可能會(huì)是Net，F(xiàn)ile，Cache各種IO等，然后項(xiàng)目架構(gòu)變成了這樣。
再然后隨著人員增多，各種基礎(chǔ)組件也變的越來(lái)越多，業(yè)務(wù)也很復(fù)雜，業(yè)務(wù)與業(yè)務(wù)之間還有很強(qiáng)的耦合，就變成了這樣的。
使用模塊化技術(shù)以后，架構(gòu)變成了這樣。
技術(shù)要點(diǎn)
這里簡(jiǎn)單介紹下Android項(xiàng)目實(shí)現(xiàn)模塊化需要使用的技術(shù)以及技術(shù)難點(diǎn)。
Library module
在開始開始進(jìn)行模塊化之前，需要把各個(gè)業(yè)務(wù)單獨(dú)抽取成Android Library Module,這個(gè)是Android Studio自帶一個(gè)功能，可以把依賴較少的，作為基本組件的抽取成一個(gè)單獨(dú)模塊。
如圖所示，我把各個(gè)模塊單獨(dú)分為一個(gè)獨(dú)立的項(xiàng)目。
在主項(xiàng)目中使用gradle添加代碼依賴。
- // common
- compile project(':ModuleBase')
- compile project(':ModuleComponent')
- compile project(':ModuleService')
- // biz
- compile project(':ModuleUser')
- compile project(':ModuleOrder')
- compile project(':ModuleShopping')
Library module開發(fā)問(wèn)題
在把代碼抽取到各個(gè)單獨(dú)的Library Module中，會(huì)遇到各種問(wèn)題。最常見的就是R文件問(wèn)題，Android開發(fā)中，各個(gè)資源文件都是放在res目錄中，在編譯過(guò)程中，會(huì)生成R.java文件。R文件中包含有各個(gè)資源文件對(duì)應(yīng)的id，這個(gè)id是靜態(tài)常量，但是在Library Module中，這個(gè)id不是靜態(tài)常量，那么在開發(fā)時(shí)候就要避開這樣的問(wèn)題。
舉個(gè)常見的例子，同一個(gè)方法處理多個(gè)view的點(diǎn)擊事件，有時(shí)候會(huì)使用switch(view.getId())這樣的方式，然后用case R.id.btnLogin這樣進(jìn)行判斷，這時(shí)候就會(huì)出現(xiàn)問(wèn)題，因?yàn)閕d不是經(jīng)常常量，那么這種方式就用不了。
同樣開發(fā)時(shí)候，用的最多的一個(gè)第三方庫(kù)就是ButterKnife，ButterKnife也是不可以用的，在使用ButterKnife的時(shí)候，需要用到注解配置一個(gè)id來(lái)找到對(duì)應(yīng)view，或者綁定對(duì)應(yīng)的各種事件處理，但是注解中的各個(gè)字段的賦值也是需要靜態(tài)常量，那么就不能夠使用ButterKnife了。
解決方案有下面幾種：
1.重新一個(gè)Gradle插件，生成一個(gè)R2.java文件，這個(gè)文件中各個(gè)id都是靜態(tài)常量，這樣就可以正常使用了。
2.使用Android系統(tǒng)提供的最原始的方式，直接用findViewById以及setOnClickListener方式。
3.設(shè)置項(xiàng)目支持Databinding，然后使用Binding中的對(duì)象，但是會(huì)增加不少方法數(shù)，同時(shí)Databinding也會(huì)有編譯問(wèn)題和學(xué)習(xí)成本，但是這些也是小問(wèn)題，個(gè)人覺(jué)的問(wèn)題不大。
上面是主流的解決方法，個(gè)人推薦的使用優(yōu)先級(jí)為 3 > 2 > 1。
當(dāng)把個(gè)模塊分開以后，每個(gè)人就可以單獨(dú)分組對(duì)應(yīng)的模塊就行了，不過(guò)會(huì)有資源沖突問(wèn)題，個(gè)人建議是對(duì)各個(gè)模塊的資源名字添加前綴，比如user模塊中的登錄界面布局為activity_login.xml，那么可以寫成這樣us_activity_login.xml。這樣就可以避免資源沖突問(wèn)題。同時(shí)Gradle也提供的一個(gè)字段resourcePrefix，確保各個(gè)資源名字正確，具體用法可以參考官方文檔。
依賴管理
當(dāng)完成了Library module后，代碼基本上已經(jīng)很清晰了，跟我們上面的最終架構(gòu)已經(jīng)很相似了，有了最基本的骨架，但是還是沒(méi)有完成，因?yàn)檫€是多個(gè)人操作同一個(gè)git倉(cāng)庫(kù)，各個(gè)開發(fā)小伙伴還是需要對(duì)同一個(gè)倉(cāng)庫(kù)進(jìn)行各種fork和pr。
隨著對(duì)代碼的分割，但是主項(xiàng)目app的依賴變多了，如果修改了lib中的代碼，那么編譯時(shí)間是很恐怖的，大概統(tǒng)計(jì)了一下，原先在同一個(gè)模塊的時(shí)候，編譯時(shí)間大概需要2-3min，但是分開以后大概需要5-6min，這個(gè)是絕對(duì)無(wú)法忍受的。
上面的***問(wèn)題，可以這樣解決，把各個(gè)子module分別使用單獨(dú)的一個(gè)git倉(cāng)庫(kù)，這樣每個(gè)人也只需要關(guān)注自己需要的git倉(cāng)庫(kù)即可，主倉(cāng)庫(kù)使用git submodule的方式，分別依賴各個(gè)子模塊。
但是這樣還是無(wú)法解決編譯時(shí)間過(guò)長(zhǎng)的問(wèn)題，我們把各個(gè)模塊也單獨(dú)打包，每次子模塊開發(fā)完成以后，發(fā)布到maven倉(cāng)庫(kù)中，然后在主項(xiàng)目中使用版本進(jìn)行依賴。
舉個(gè)例子，比如進(jìn)行某一版本迭代，這個(gè)版本叫1.0.0，那么各個(gè)模塊的版本也叫同樣的版本，當(dāng)版本完成測(cè)試發(fā)布后，對(duì)各個(gè)模塊打?qū)?yīng)版本的tag，然后就很清楚的了解各模塊的代碼分布。
gradle依賴如下。
- // common
- compile 'cn.mycommons:base:1.0.0'
- compile 'cn.mycommons:component:1.0.0'
- compile 'cn.mycommons:service:1.0.0'
- // biz
- compile 'cn.mycommons:user:1.0.0'
- compile 'cn.mycommons:order:1.0.0'
- compile 'cn.mycommons:shopping:1.0.0'
可能有人會(huì)問(wèn)，既然各個(gè)模塊已經(jīng)分開開發(fā)，那么如果進(jìn)行開發(fā)聯(lián)調(diào)，別急，這個(gè)問(wèn)題暫時(shí)保留，后面會(huì)對(duì)這個(gè)問(wèn)題后面再表。
數(shù)據(jù)通信
當(dāng)一個(gè)大項(xiàng)目拆成若干小項(xiàng)目時(shí)候，調(diào)用的姿勢(shì)發(fā)生了少許改變。我這邊總結(jié)了App各個(gè)模塊之間的數(shù)據(jù)通信幾種方式。
- 頁(yè)面跳轉(zhuǎn)，比如在訂單頁(yè)面下單時(shí)候，需要判斷用戶是否登錄，如果沒(méi)有則需要跳到登錄界面。
- 主動(dòng)獲取數(shù)據(jù)，比如在下單時(shí)候，用戶已經(jīng)登錄，下單需要傳遞用戶的基本信息。
- 被動(dòng)獲得數(shù)據(jù)，比如在切換用戶的時(shí)候，有時(shí)候需要更新數(shù)據(jù)，如訂單頁(yè)面，需要把原先用戶的購(gòu)物車數(shù)據(jù)給清空。
再來(lái)看下App的架構(gòu)。
***個(gè)問(wèn)題，原先的方式，直接指定某個(gè)頁(yè)面的ActivityClass，然后通過(guò)intent跳轉(zhuǎn)即可，但是在新的架構(gòu)中，由于shopping模塊不直接依賴user，那么則不能使用原始的進(jìn)行跳轉(zhuǎn)，我們解決方式使用Router路由跳轉(zhuǎn)。
第二個(gè)問(wèn)題，原先的方式有個(gè)專門的業(yè)務(wù)單利，比如UserManager，直接可以調(diào)用即可，同樣由于依賴發(fā)生了改變，不能夠進(jìn)行調(diào)用。解決方案是所有的需要的操作，定義成接口放在Service中。
第三個(gè)問(wèn)題，原先的方式，可以針對(duì)事件變化提供回調(diào)接口，當(dāng)我需要監(jiān)聽某個(gè)事件時(shí)候，設(shè)置回調(diào)即可。
頁(yè)面路由跳轉(zhuǎn)
如上分析，原先方式代碼如下。
- Intent intent = new Intent(this, UserActivity.class);
- startActivity(intent);
但是使用Router后，調(diào)用方式改變了。
- RouterHelper.dispatch(getContext(), "app://user");
具體的原理是什么，很簡(jiǎn)單的，做一個(gè)簡(jiǎn)單的映射匹配即可，把"app://user"與UserActivity.class配對(duì)，具體的就是定義一個(gè)Map，key是對(duì)應(yīng)的Router字符，value是Activity的class。在跳轉(zhuǎn)時(shí)候從map中獲取對(duì)應(yīng)的ActivityClass，然后在使用原始的方式。
可能有人的會(huì)問(wèn)，要向另外一個(gè)頁(yè)面?zhèn)鬟f參數(shù)怎么辦，沒(méi)事我們可以在router后面直接添加參數(shù)，如果是一個(gè)復(fù)雜的對(duì)象那么可以把對(duì)象序列化成json字符串，然后再?gòu)膶?duì)應(yīng)的頁(yè)面通過(guò)反序列化的方式，得到對(duì)應(yīng)的對(duì)象。
例如：
- RouterHelper.dispatch(getContext(), "app://user?id=123&obj={"name":"admin"}");
注： 上面的router中json字符串是需要url編碼的，不然會(huì)有問(wèn)題的，這里只是做個(gè)示例。
除了使用Router進(jìn)行跳轉(zhuǎn)外，我想了一下，可以參考Retrofit方式，直接定義跳轉(zhuǎn)Java接口，如果需要傳遞額外參數(shù)，則以函數(shù)參數(shù)的方式定義。
這個(gè)Java接口是沒(méi)有實(shí)現(xiàn)類的，可以使用動(dòng)態(tài)代理方式，然后接下來(lái)的方式，和使用Router的方式一樣。
那么這總兩種方式有什么優(yōu)缺點(diǎn)呢。
Router方式:
- 有點(diǎn)：不需要高難度的技術(shù)點(diǎn)，使用方便，直接使用字符串定義跳轉(zhuǎn)，可以好的往后兼容
- 缺點(diǎn)：因?yàn)槭褂玫氖亲址渲?，如果字符輸入字符，則很難發(fā)現(xiàn)bug，同時(shí)也很難知道某個(gè)參數(shù)對(duì)應(yīng)的含義
仿Retrofit方式:
- 因?yàn)槭荍ava接口定義，所以可以很簡(jiǎn)單找到對(duì)應(yīng)的跳轉(zhuǎn)方法，參數(shù)定義也很明確，可以直接寫在接口定義處，方便查閱。
- 同樣因?yàn)槭荍ava接口定義，那么如果需要擴(kuò)展參數(shù)，只能重新定義新方法，這樣會(huì)出現(xiàn)多個(gè)方法重載，如果在原先接口上修改，對(duì)應(yīng)的原先調(diào)用方也要做響應(yīng)的修改，比較麻煩。上面是兩種實(shí)現(xiàn)方式，如果有相應(yīng)同學(xué)要實(shí)現(xiàn)模塊化，可以根據(jù)實(shí)際情況做出選擇。
Interface和Implement
如上分析，如果需要從某個(gè)業(yè)務(wù)中獲取數(shù)據(jù)，我們分別需要定義接口以及實(shí)現(xiàn)類，然在獲取的時(shí)候在通過(guò)反射來(lái)實(shí)例化對(duì)象。
下面是簡(jiǎn)單的代碼示例
接口定義
- public interface IUserService {
- String getUserName();
- }
實(shí)現(xiàn)類
- class UserServiceImpl implements IUserService {
- @Override
- public String getUserName() {
- return "UserServiceImpl.getUserName";
- }
- }
反射生成對(duì)象
- public class InjectHelper {
- @NonNull
- public static AppContext getAppContext() {
- return AppContext.getAppContext();
- }
- @NonNull
- public static IModuleConfig getIModuleConfig() {
- return getAppContext().getModuleConfig();
- }
- @Nullable
- public static
T getInstance(Class tClass) { - IModuleConfig config = getIModuleConfig();
- Class implementClass = config.getServiceImplementClass(tClass);
- if (implementClass != null) {
- try {
- return implementClass.newInstance();
- } catch (Exception e) {
- e.printStackTrace();
- }
- }
- return null;
- }
- }
實(shí)際調(diào)用
- IUserService userService = InjectHelper.getInstance(IUserService.class);
- if (userService != null) {
- Toast.makeText(getContext(), userService.getUserName(), Toast.LENGTH_SHORT).show();
- }
本示例中每次調(diào)用都是用反射生成新的對(duì)象，實(shí)際應(yīng)用中可能與IoC工具結(jié)合使用，比如Dagger2.
EventBus
針對(duì)上面的第三個(gè)問(wèn)題，原先設(shè)計(jì)的使用方式也是可以的，只需要把回調(diào)接口定義到對(duì)應(yīng)的service接口中，然后調(diào)用方就可以使用。
但是我建議可以使用另外一個(gè)方式——EventBus，EventBus也是利用觀察者模式，對(duì)事件進(jìn)行監(jiān)聽，是設(shè)置回調(diào)更優(yōu)雅方式的實(shí)現(xiàn)。
優(yōu)點(diǎn)：不需要定義很多個(gè)回調(diào)接口，只需要定義事件Class，然后通過(guò)Claas的***性來(lái)進(jìn)行事件匹配。
缺點(diǎn)：需要定義很多額外的類來(lái)表示事件，同時(shí)也需要關(guān)注EventBus的生命周期，在不需要使用事件時(shí)候，需要注銷事件綁定，不然容易發(fā)生內(nèi)存泄漏。
網(wǎng)頁(yè)名稱：總結(jié)Android模塊化的一些知識(shí)點(diǎn)。
地址分享：http://www.dlmjj.cn/article/dpsieeg.html
