關(guān)于模塊化

關(guān)于模塊化就不過多介紹了飒箭，感興趣的可以看一下Android 模塊化探索與實踐和安居客 Android 項目架構(gòu)演進這兩篇文章假夺，這兩篇文章是我認為寫的比較好的。現(xiàn)在我來主要閑聊一下模塊化開發(fā)中遇到的一些問題和自己總結(jié)的經(jīng)驗布讹。

遇到的問題

在看了很多關(guān)于模塊化開發(fā)的文章以及案列后瘾英，在公司的一個新項目中我開始嘗試模塊化的開發(fā)忌堂。把復雜的功能拆分成一個個的模塊。原以為會很順利拴曲，但在開發(fā)中卻遇到了很多文章上都沒有提過的問題争舞。以下是第一次使用模塊化開發(fā)中遇到的一些問題，這些問題雖然不是很嚴重的問題澈灼，但對于初次使用的人也會造成一些小小的困擾竞川，這里寫出來，供大家參考叁熔。

1.資源文件引用問題和實體類引用問題

按照思路委乌，每個模塊之間是獨立的，可以打包成一個app的荣回，那么每個模塊之間在開發(fā)階段就應該盡可能的獨立福澡。可是當一兩個模塊開發(fā)完成之后驹马，會發(fā)現(xiàn)每個模塊之間，都存在重復和冗余的資源文件除秀。比如糯累，這張圖片模塊A里有了，模塊B里也有册踩，但都是同一張泳姐。那么這個時候就有兩種解決方法。第一種：不管冗余的資源文件暂吉。第二種把A模塊和B模塊里的資源文件都刪了胖秒，把這個共同的資源文件放到他們都可以給訪問的BaseModule里∧降模可以看出阎肝，不管是哪種，都不盡如人意肮街。同理风题，實體類也是，實體類的主要問題是不同模塊之間的實體類很可能必須是要一樣的嫉父，這也是后期修改的需要沛硅。例如在劃分模塊的時候，不同模塊之間的實體類需要一樣绕辖，為了后期維護方便摇肌，只能采取上面所說的第二種方法。但就算付出了時間和精力讓架構(gòu)更清晰和健壯仪际，也會帶來第二個問題围小。

2.BaseModule過大

按照上面兩篇文章的說法昵骤，所有的模塊都會依賴于一個BaseModule，而我們的AppModule則只是這些其余Module的入口吩抓。如下圖所示：

這只是截取了一部分來顯示涉茧。我想說的是，為了能夠在不同模塊之間共用資源文件和實體類疹娶，我們不得不把很多東西放到BaseModule里伴栓，這會讓BaseModule越來越大∮杲龋或許有些人覺得這是正常的钳垮，但這會導致一些功能簡單，需要不斷復用的模塊無法依賴BaseModule额港。例如PayModule（支付模塊）饺窿，ShareModule（分享模塊）等需要在其他項目中可以直接拿來用的模塊，無法直接引用BaseModule里的一些實體移斩，或者封裝好的網(wǎng)絡請求方法肚医。因為如果一旦引用了，就必須把龐大的BaseModule帶上向瓷。違背了模塊化就是要讓一些模塊可以不斷復用的初衷肠套。

3.模塊之間的相互通訊的一些問題

使用AS的時候，是不允許互相依賴的猖任。比如我的appModule依賴了TicketModule你稚，那么TicketModule是不能依賴appModule的。那么當我想要從TicketModule中打開app中的某個Activity的時候朱躺，我是無法直接打開的刁赖。因為你拿不到appModule里的任何東西。所以這里你有兩種選擇长搀，使用隱式Intent或者使用路由框架宇弛。這里推薦一下阿里巴巴開源的路由框架ARouter，功能簡單但夠用源请。但這樣也是存在問題的涯肩。ARouter基于注解實現(xiàn)，看上去十分方便簡潔巢钓。但很多時候你會不知道哪些地方你應該直接跳轉(zhuǎn)病苗，哪些地方應該使用路由。并且ARouter存在一個問題症汹，你用ARouter進行類似startActivityForResult的操作的時候硫朦，你當前Activity里的Fragment是接收不到onActivityResult的，需要自己去顯示調(diào)用fragment的onActivityResult背镇，原因在于requestCode那里咬展，感興趣的可以自己去看源碼泽裳，這里就不多提了∑破牛總結(jié)一下就是涮总，當你使用模塊化開發(fā)，你不得不考慮模塊間的跳轉(zhuǎn)問題祷舀，而模塊間的跳轉(zhuǎn)問題又存在如何規(guī)范和框架本身的一些問題瀑梗。

一些自己的經(jīng)驗

在這里，分享一些自己的經(jīng)驗給即將或者已經(jīng)在使用模塊化開發(fā)的人

1.熟悉和理清項目

這也是最重要的裳扯，不單單是對項目的邏輯進行梳理抛丽，當拿到功能圖或者結(jié)構(gòu)圖時，除了注意項目的邏輯饰豺，還有其中的一些資源文件亿鲜，可能的實體類自己心中應該有一些把握，可以省去之后的很多麻煩冤吨。

2.對功能性強的模塊蒿柳，可以存在一些冗余

如上所說，例如PayModule（支付模塊）漩蟆，ShareModule（分享模塊）等垒探，雖然BaseModule里已經(jīng)封裝好了網(wǎng)絡請求的相關(guān)方法，但依然可以自己寫一些基礎的方法在這兩個模塊中爆安，雖然看似冗余，但可以讓這兩個模塊不依賴于龐大的BaseModule仔引，讓這兩個模塊真正的達到復用的目的扔仓。

3.規(guī)范模塊間跳轉(zhuǎn)的約定

多人開發(fā)的時候，應該在開發(fā)之前對模塊間的跳轉(zhuǎn)做一個約定咖耘，這樣可以省去后期很多的代碼維護和梳理的時間翘簇。以及在開發(fā)之初對跳轉(zhuǎn)方法的選型，應該結(jié)合項目來考慮儿倒，很多時候版保，隱式跳轉(zhuǎn)其實也夠用了。至于使不使用路由框架夫否，也應該結(jié)合項目本身來進行思考

最后彻犁，閑聊一下MVP以及MVVM

本篇博文開頭供大家參考的文章中多次提到了MVP，并把MVP作為模塊與模塊之間的約定和共性凰慈。要求每個模塊都應遵循MVP的開發(fā)規(guī)范汞幢。事實上在我的項目中我也選擇了MVP作為這個項目的主要開發(fā)模式。事實上MVP結(jié)合RXJAVA可以很好的仿制內(nèi)存泄漏微谓，以及MVP模式下森篷，很多接口和Presenter可以服用输钩。但很多人容易進入一個誤區(qū)，即選擇了MVP就不應該再使用MVC或者MVVM仲智，我認為這是錯的买乃。MVP,MVC,MVVM都只是一種設計模式，本質(zhì)上都是讓代碼更容易維護钓辆。那么基于這樣的訴求剪验，就不應該過多的糾結(jié)于該用哪種。比如一個界面里有很多需要填寫的內(nèi)容岩馍，這個時候可以考慮使用mvvm碉咆。而一個界面如果有很復雜的邏輯交互和網(wǎng)絡請求，那么應該使用mvp模式蛀恩。而如果一個界面同時兼具以上兩種疫铜，那么一個界面可以同時使用mvp和mvvm也是可以的。填充數(shù)據(jù)使用mvvm而復雜的網(wǎng)絡請求使用mvp双谆】枪荆總結(jié)一下就是，不應該拘泥于設計模式顽馋，這會讓簡單的代碼變得復雜谓厘。

知無不言，言無不盡寸谜，言者無罪竟稳，聞者足戒

以上就是是我開發(fā)中遇到的問題和看法，供大家參考熊痴。