本篇內(nèi)容主要講解“Android模塊化怎么實(shí)現(xiàn)”,感興趣的朋友不妨來(lái)看看。本文介紹的方法操作簡(jiǎn)單快捷,實(shí)用性強(qiáng)。下面就讓小編來(lái)帶大家學(xué)習(xí)“Android模塊化怎么實(shí)現(xiàn)”吧!
創(chuàng)新互聯(lián)建站是專業(yè)的秦都網(wǎng)站建設(shè)公司,秦都接單;提供成都網(wǎng)站建設(shè)、網(wǎng)站設(shè)計(jì),網(wǎng)頁(yè)設(shè)計(jì),網(wǎng)站設(shè)計(jì),建網(wǎng)站,PHP網(wǎng)站建設(shè)等專業(yè)做網(wǎng)站服務(wù);采用PHP框架,可快速的進(jìn)行秦都網(wǎng)站開(kāi)發(fā)網(wǎng)頁(yè)制作和功能擴(kuò)展;專業(yè)做搜索引擎喜愛(ài)的網(wǎng)站,專業(yè)的做網(wǎng)站團(tuán)隊(duì),希望更多企業(yè)前來(lái)合作!
模塊化場(chǎng)景
為什么需要模塊化?
當(dāng)一個(gè)App用戶量增多,業(yè)務(wù)量增長(zhǎng)以后,就會(huì)有很多開(kāi)發(fā)工程師參與同一個(gè)項(xiàng)目,人員增加了,原先小團(tuán)隊(duì)的開(kāi)發(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)演變
在剛剛開(kāi)始的時(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
在開(kāi)始開(kāi)始進(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開(kāi)發(fā)問(wèn)題
在把代碼抽取到各個(gè)單獨(dú)的Library Module中,會(huì)遇到各種問(wèn)題。最常見(jiàn)的就是R文件問(wèn)題,Android開(kāi)發(fā)中,各個(gè)資源文件都是放在res目錄中,在編譯過(guò)程中,會(huì)生成R.java文件。R文件中包含有各個(gè)資源文件對(duì)應(yīng)的id,這個(gè)id是靜態(tài)常量,但是在Library Module中,這個(gè)id不是靜態(tài)常量,那么在開(kāi)發(fā)時(shí)候就要避開(kāi)這樣的問(wèn)題。
舉個(gè)常見(jiàn)的例子,同一個(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)常常量,那么這種方式就用不了。
同樣開(kāi)發(fā)時(shí)候,用的最多的一個(gè)第三方庫(kù)就是ButterKnife,ButterKnife也是不可以用的,在使用ButterKnife的時(shí)候,需要用到注解配置一個(gè)id來(lái)找到對(duì)應(yīng)view,或者綁定對(duì)應(yīng)的各種事件處理,但是注解中的各個(gè)字段的賦值也是需要靜態(tài)常量,那么就不能夠使用ButterKnife了。
解決方案有下面幾種:
重新一個(gè)Gradle插件,生成一個(gè)R2.java文件,這個(gè)文件中各個(gè)id都是靜態(tài)常量,這樣就可以正常使用了。
使用Android系統(tǒng)提供的最原始的方式,直接用 findViewById 以及 setOnClickListener 方式。
設(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è)模塊分開(kāi)以后,每個(gè)人就可以單獨(dú)分組對(duì)應(yīng)的模塊就行了,不過(guò)會(huì)有資源沖突問(wèn)題,個(gè)人建議是對(duì)各個(gè)模塊的資源名字添加前綴,比如user模塊中的登錄界面布局為 activity_login.xml ,那么可以寫(xiě)成這樣 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è)開(kāi)發(fā)小伙伴還是需要對(duì)同一個(gè)倉(cāng)庫(kù)進(jìn)行各種fork和pr。
隨著對(duì)代碼的分割,但是主項(xiàng)目app的依賴變多了,如果修改了lib中的代碼,那么編譯時(shí)間是很恐怖的,大概統(tǒng)計(jì)了一下,原先在同一個(gè)模塊的時(shí)候,編譯時(shí)間大概需要2-3min,但是分開(kāi)以后大概需要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ú)打包,每次子模塊開(kāi)發(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)分開(kāi)開(kāi)發(fā),那么如果進(jìn)行開(kāi)發(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)物車(chē)數(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è)專門(mén)的業(yè)務(wù)單利,比如UserManager,直接可以調(diào)用即可,同樣由于依賴發(fā)生了改變,不能夠進(jìn)行調(diào)用。解決方案是所有的需要的操作,定義成接口放在Service中。
第三個(gè)問(wèn)題,原先的方式,可以針對(duì)事件變化提供回調(diào)接口,當(dāng)我需要監(jiān)聽(tīng)某個(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ù)定義也很明確,可以直接寫(xiě)在接口定義處,方便查閱。
同樣因?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 staticT getInstance(Class tClass) { IModuleConfig config = getIModuleConfig(); Class extends T> 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)聽(tīng),是設(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)存泄漏。
映射匹配
上面的介紹的各個(gè)模塊之間通信,都運(yùn)涉及到映射匹配問(wèn)題,在此我總結(jié)了一下,主要涉及到一下三種方式。
Map register
Map register是這樣的,全局定義一個(gè)Map,各個(gè)模塊在初始化的時(shí)候,分別在初始化的時(shí)候注冊(cè)映射關(guān)系。
下面是簡(jiǎn)單的代碼示例,比如我們定義一個(gè)模塊生命周期,用于初始化各個(gè)模塊。
public interface IModuleLifeCycle { void onCreate(IModuleConfig config); void onTerminate(); }
User模塊初始化
public class UserModuleLifeCycle extends SimpleModuleLifeCycle { public UserModuleLifeCycle(@NonNull Application application) { super(application); } @Override public void onCreate(@NonNull IModuleConfig config) { config.registerService(IUserService.class, UserServiceImpl.class); config.registerRouter("app://user", UserActivity.class); } }
在Application中完成初始化
public class AppContext extends Application { private ModuleLifeCycleManager lifeCycleManager; @Override public void onCreate() { super.onCreate(); lifeCycleManager = new ModuleLifeCycleManager(this); lifeCycleManager.onCreate(); } @Override public void onTerminate() { super.onTerminate(); lifeCycleManager.onTerminate(); } @NonNull public IModuleConfig getModuleConfig() { return lifeCycleManager.getModuleConfig(); } } public class ModuleLifeCycleManager { @NonNull private ModuleConfig moduleConfig; @NonNull private final ListmoduleLifeCycleList; ModuleLifeCycleManager(@NonNull Application application) { moduleConfig = new ModuleConfig(); moduleLifeCycleList = new ArrayList<>(); moduleLifeCycleList.add(new UserModuleLifeCycle(application)); moduleLifeCycleList.add(new OrderModuleLifeCycle(application)); moduleLifeCycleList.add(new ShoppingModuleLifeCycle(application)); } void onCreate() { for (IModuleLifeCycle lifeCycle : moduleLifeCycleList) { lifeCycle.onCreate(moduleConfig); } } void onTerminate() { for (IModuleLifeCycle lifeCycle : moduleLifeCycleList) { lifeCycle.onTerminate(); } } @NonNull IModuleConfig getModuleConfig() { return moduleConfig; } }
APT
使用注解的方式配置映射信息,然后生成一個(gè)類似Database一樣的文件,然后Database文件中包含一個(gè)Map字段,Map中記錄各個(gè)映射信息。
首先需要定義個(gè)Annotation。
如:
@Target(ElementType.TYPE) @Retention(RetentionPolicy.CLASS) public @interface Implements { Class parent(); }
需要實(shí)現(xiàn)一個(gè) Annotation Process Tool,來(lái)解析自己定義的Annotation。
代碼略,此代碼有點(diǎn)復(fù)雜,暫時(shí)不貼了。
編譯產(chǎn)生的文件,大概如下所示。
public class Implement_$$_Database { @NonNull private final Map, Class>> serviceConfig; public Implement_$$_Database() { serviceConfig = new HashMap<>(); serviceConfig.put(IUserService.class, UserServiceImpl.class); } public Class extends T> getServiceImplementClass(Class serviceClass) { return (Class extends T>) serviceConfig.get(serviceClass); } }
然后利用反射找到 Implement_$$_Database 這個(gè)類,然后從方法中找到配對(duì)。
public class InjectHelper { @Nullable public staticT getInstanceByDatabase(Class tClass) { Implement_$$_Database database = new Implement_$$_Database(); Class extends T> implementClass = database.getServiceImplementClass(tClass); if (implementClass != null) { try { return implementClass.newInstance(); } catch (Exception e) { e.printStackTrace(); } } return null; } }
然后在需要配置的地方添加注解即可。
@Implements(parent = IUserService.class) class UserServiceImpl implements IUserService { @Override public String getUserName() { return "UserServiceImpl.getUserName"; } }
調(diào)用姿勢(shì)。
binding.button.setOnClickListener(new View.OnClickListener() { @Override public void onClick(View v) { IUserService userService = InjectHelper.getInstanceByDatabase(IUserService.class); if (userService != null) { Toast.makeText(getContext(), userService.getUserName(), Toast.LENGTH_SHORT).show(); } } });
注意點(diǎn):
有時(shí)候,在生成最終的配置文件的時(shí)候,文件的名字是固定的,比如上面的 Implement_$$_Database ,最終的路徑是這樣的 cn.mycommons.implements.database.Implement_$$_Database.java ,然后通過(guò)編譯到apk中或則是aar中。
但是有個(gè)問(wèn)題,如果各個(gè)子模塊都使用了這樣的插件,那么每個(gè)子模塊的就會(huì)有這個(gè)Implement_$$_Database.class,那么就會(huì)編譯出錯(cuò)。
因?yàn)閍ar中包含的時(shí)候class文件,不是java文件,不能在使用APT做處理了。下面有2中解決方案。
子工程的插件生成的文件包含一定的規(guī)則,比如包含模塊名字,如 User_Implement_$$_Database.java ,同時(shí)修改編譯過(guò)程,把java文件也打包到aar中,主工程的插件在編譯時(shí)候,提取aar中的文件,然后合并子工程的所有的代碼,這個(gè)思路是可行的,不過(guò)技術(shù)實(shí)現(xiàn)起來(lái)比較麻煩。
同一的方式類似,也是生成有一定規(guī)則的的文件,或者在特地package下生成class,這些class再通過(guò)接下來(lái)的所講的Gradle Transform方式,生成一個(gè)新的Database.class文件。
Gradle Transform
這是Android Gradle編譯提供的一個(gè)接口,可以供開(kāi)發(fā)自定義一些功能,而我們就可以根據(jù)這個(gè)功能生成映射匹配,這種方式和APT類似,APT是運(yùn)行在代碼編譯時(shí)期,而且Transform是直接掃描class,然后再生成新的class,class中包含Map映射信息。修改class文件,使用的是 javassist 一個(gè)第三方庫(kù)。
下面簡(jiǎn)單講述代碼實(shí)現(xiàn),后面有機(jī)會(huì)單獨(dú)寫(xiě)一篇文章講解。
首先定義一個(gè)注解,這個(gè)注解用于標(biāo)注一個(gè)實(shí)現(xiàn)類的接口。
package cn.mycommons.modulebase.annotations; @Target(ElementType.TYPE) @Retention(RetentionPolicy.CLASS) public @interface Implements { Class parent(); }
一個(gè)測(cè)試用的接口以及實(shí)現(xiàn)類。
public interface ITest { } @Implements(parent = ITest.class) public class TestImpl implements ITest { }
定義一個(gè)靜態(tài)方法,用于獲取某個(gè)接口的實(shí)現(xiàn)類。
package cn.mycommons.modulebase.annotations; public class ImplementsManager { private static final MapCONFIG = new HashMap<>(); public static Class getImplementsClass(Class parent) { return CONFIG.get(parent); } }
如果不使用任何黑科技,直接使用Java技術(shù),那么在定義時(shí)候需要主動(dòng)的往CONFIG這個(gè)map中添加配置,但是這里我們利用transform,直接動(dòng)態(tài)的添加。
定義一個(gè) ImplementsPlugin gradle插件。
public class ImplementsPlugin implements Plugin{ @Override public void apply(Project project) { AppExtension app = project.getExtensions().getByType(AppExtension.class); app.registerTransform(new ImplementsTransform(project)); } }
自定義的Transform實(shí)現(xiàn)。
public class ImplementsTransform extends Transform { static final String IMPLEMENTS_MANAGER = "cn/mycommons/modulebase/annotations/ImplementsManager.class" static final String IMPLEMENTS_MANAGER_NAME = "cn.mycommons.modulebase.annotations.ImplementsManager" Project project ImplementsTransform(Project project) { this.project = project } void log(String msg, Object... args) { String text = String.format(msg, args) project.getLogger().error("[ImplementsPlugin]:${text}") } @Override public String getName() { return "ImplementsTransform" } @Override public SetgetInputTypes() { return ImmutableSet.of(QualifiedContent.DefaultContentType.CLASSES) } @Override public Set super QualifiedContent.Scope> getScopes() { return ImmutableSet.of( QualifiedContent.Scope.PROJECT, QualifiedContent.Scope.PROJECT_LOCAL_DEPS, QualifiedContent.Scope.SUB_PROJECTS, QualifiedContent.Scope.SUB_PROJECTS_LOCAL_DEPS, QualifiedContent.Scope.EXTERNAL_LIBRARIES ) } @Override boolean isIncremental() { return false } @Override void transform(TransformInvocation transformInvocation) throws TransformException, InterruptedException, IOException { super.transform(transformInvocation) long time1 = System.currentTimeMillis(); log(this.toString() + ".....transform") TransformOutputProvider outputProvider = transformInvocation.outputProvider outputProvider.deleteAll() def classPool = new ClassPool() classPool.appendSystemPath() // 記錄所有的符合掃描條件的記錄 List implementsList = [] // ImplementsManager 注解所在的jar文件 JarInput implementsManagerJar = null // 掃描所有的文件 transformInvocation.inputs.each { it.directoryInputs.each { classPool.appendClassPath(it.file.absolutePath) def dst = outputProvider.getContentLocation(it.name, it.contentTypes, it.scopes, Format.DIRECTORY) FileUtils.copyDirectory(it.file, dst) project.fileTree(dst).each { String clazzPath = it.absolutePath.replace(dst.absolutePath, "") clazzPath = clazzPath.replace("/", ".").substring(1) if (clazzPath.endsWith(".class")) { clazzPath = clazzPath.substring(0, clazzPath.size() - 6) CtClass clazz = classPool.get(clazzPath) // 如果class中的類包含注解則先收集起來(lái) Implements annotation = clazz.getAnnotation(Implements.class) if (annotation != null) { implementsList.add(new Entry(annotation, clazz)) } } } } it.jarInputs.each { classPool.appendClassPath(it.file.absolutePath) if (implementsManagerJar == null && isImplementsManager(it.file)) { implementsManagerJar = it } else { def dst = outputProvider.getContentLocation(it.name, it.contentTypes, it.scopes, Format.JAR) FileUtils.copyFile(it.file, dst) def jarFile = new JarFile(it.file) def entries = jarFile.entries() // 如果jar中的class中的類包含注解則先收集起來(lái) while (entries.hasMoreElements()) { def jarEntry = entries.nextElement() String clazzPath = jarEntry.getName() clazzPath = clazzPath.replace("/", ".") if (clazzPath.endsWith(".class")) { clazzPath = clazzPath.substring(0, clazzPath.size() - 6) def clazz = classPool.get(clazzPath) Implements annotation = clazz.getAnnotation(Implements.class) if (annotation != null) { implementsList.add(new Entry(annotation, clazz)) } } } } } } log("implementsManagerJar = " + implementsManagerJar) Map config = new LinkedHashMap<>() implementsList.each { def str = it.anImplements.toString(); log("anImplements =" + it.anImplements) def parent = str.substring(str.indexOf("(") + 1, str.indexOf(")")).replace("parent=", "").replace(".class", "") log("parent =" + parent) log("sub =" + it.ctClass.name) // 收集所有的接口以及實(shí)現(xiàn)類的路徑 config.put(parent, it.ctClass.name) } log("config = " + config) long time2 = System.currentTimeMillis(); if (implementsManagerJar != null) { def implementsManagerCtClass = classPool.get(IMPLEMENTS_MANAGER_NAME) log("implementsManagerCtClass = " + implementsManagerCtClass) // 修改class,在class中插入靜態(tài)代碼塊,做初始化 def body = "{\n" body += "CONFIG = new java.util.HashMap();\n" for (Map.Entry entry : config.entrySet()) { body += "CONFIG.put(${entry.key}.class, ${entry.value}.class);\n" } body += "}\n" log("body = " + body) implementsManagerCtClass.makeClassInitializer().body = body def jar = implementsManagerJar def dst = outputProvider.getContentLocation(jar.name, jar.contentTypes, jar.scopes, Format.JAR) println dst.absolutePath // 修改完成后,完成后再寫(xiě)入到j(luò)ar文件中 rewriteJar(implementsManagerJar.file, dst, IMPLEMENTS_MANAGER, implementsManagerCtClass.toBytecode()) } log("time = " + (time2 - time1) / 1000) } static boolean isImplementsManager(File file) { return new JarFile(file).getEntry(IMPLEMENTS_MANAGER) != null } static void rewriteJar(File src, File dst, String name, byte[] bytes) { dst.getParentFile().mkdirs() def jarOutput = new JarOutputStream(new FileOutputStream(dst)) def rcJarFile = new JarFile(src) jarOutput.putNextEntry(new JarEntry(name)) jarOutput.write(bytes) def buffer = new byte[1024] int bytesRead def entries = rcJarFile.entries() while (entries.hasMoreElements()) { def entry = entries.nextElement() if (entry.name == name) continue jarOutput.putNextEntry(entry) def jarInput = rcJarFile.getInputStream(entry) while ((bytesRead = jarInput.read(buffer)) != -1) { jarOutput.write(buffer, 0, bytesRead) } jarInput.close() } jarOutput.close() } }
映射匹配總結(jié)
優(yōu)點(diǎn):
Map:簡(jiǎn)單明了,很容易入手,不會(huì)對(duì)編譯時(shí)間產(chǎn)生任何影響,不會(huì)隨著Gradle版本的升級(jí)而受影響,代碼混淆時(shí)候不會(huì)有影響,無(wú)需配置混淆文件。
APT:使用簡(jiǎn)單,使用注解配置,代碼優(yōu)雅,原理是用代碼生成的方式生成新的文件。
Transform:使用簡(jiǎn)單,使用注解配置,代碼優(yōu)雅,原理是用代碼生成的方式生成新的文件,不過(guò)生成的文件的時(shí)期和APT不同,會(huì)編譯時(shí)間產(chǎn)生少許影響。
缺點(diǎn):
Map:在需要新添加映射的時(shí)候,需要手動(dòng)添加,不然不會(huì)生效,代碼不優(yōu)雅。
APT:在編譯時(shí)期生成文件,會(huì)編譯時(shí)間產(chǎn)生少許影響,同時(shí)在不同的Gradle的版本中可能會(huì)產(chǎn)生錯(cuò)誤或者兼容問(wèn)題。需要配置混淆設(shè)置,不然會(huì)丟失文件。技術(shù)實(shí)現(xiàn)復(fù)雜,較難維護(hù)。
Transform:在編譯時(shí)期生成文件,會(huì)編譯時(shí)間產(chǎn)生少許影響,同時(shí)在不同的Gradle的版本中可能會(huì)產(chǎn)生錯(cuò)誤或者兼容問(wèn)題。需要配置混淆設(shè)置,不然會(huì)丟失文件。技術(shù)實(shí)現(xiàn)復(fù)雜,較難維護(hù)。
從技術(shù)復(fù)雜性以及維護(hù)性來(lái)看,Map > APT = Transform
從使用復(fù)雜性以及代碼優(yōu)雅性來(lái)看,Transform > APT > Map
開(kāi)發(fā)調(diào)試技巧
Debug
上面介紹了很多關(guān)于模塊化的概念以及技術(shù)難題,當(dāng)模塊化完成以后,再進(jìn)行完成開(kāi)發(fā)時(shí)候還是會(huì)遇到不少問(wèn)題。不如原先代碼在一起的時(shí)候很方便的進(jìn)行代碼調(diào)試。但是進(jìn)行模塊化以后,直接使用的是aar依賴,不能直接修改代碼,可以使用下面技巧,可以直接進(jìn)行代碼調(diào)試。
在根目錄下面創(chuàng)建一個(gè)module目錄以及module.gradle文件,這個(gè)目錄和文件是git ignore的,然后把對(duì)應(yīng)的模塊代碼clone到里面,根目錄的setting.gradlew apply module.gradle文件,如下所示,如果需要源碼調(diào)試,則在module中添加對(duì)應(yīng)的模塊。然后在app的依賴中去掉aar依賴,同時(shí)添加項(xiàng)目依賴即可。當(dāng)不需要源碼調(diào)試好,再修改為到原先代碼即可。
try { apply from: "./module.gradle" } catch (e) { }
module.gradle
include ':ModuleShopping'
比如調(diào)試shopping模塊
// 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' compile project(':ModuleShopping')
當(dāng)然還有個(gè)更具技術(shù)挑戰(zhàn)性方案,使用gradle插件的形式,如果發(fā)現(xiàn)root項(xiàng)目中包含的模塊化的源碼,則不適用aar依賴,直接使用源碼依賴,當(dāng)然這個(gè)想法是不錯(cuò)的,不過(guò)具有技術(shù)挑戰(zhàn)性,同時(shí)有可能隨著Gradle版本的升級(jí),編寫(xiě)的gradle插件也要做相對(duì)于的兼容風(fēng)險(xiǎn),這是只是簡(jiǎn)單提示一下。
容器設(shè)計(jì)
上面講到的如果要調(diào)試代碼時(shí)候,需要完整的運(yùn)行的整個(gè)項(xiàng)目,隨著項(xiàng)目的增大,編譯時(shí)間可能變得很長(zhǎng)。
我們可以做一個(gè)簡(jiǎn)單的,類似與主app模塊一樣,比如我是負(fù)責(zé)user模塊的開(kāi)發(fā)者,那么我只要調(diào)試我這個(gè)模塊就行了,如果需要其他的模塊,我可以簡(jiǎn)單的做一個(gè)mock,不是把其他的模塊直接依賴過(guò)來(lái),這樣可以做到調(diào)試作用。等到再需要完整項(xiàng)目調(diào)試時(shí)候,我們?cè)谑褂蒙厦娼榻B的方式,這樣可以節(jié)省不少開(kāi)發(fā)時(shí)間。
還有一種實(shí)現(xiàn)調(diào)試的方式,比如上面的user模塊,目錄下面的build.gradle文件是這樣的
apply plugin: 'com.android.library' xxx xxx
我們可以在gradle.properties中設(shè)置編譯變參數(shù)isLibModule,當(dāng)需要完整調(diào)試好,設(shè)置為 isLibModule=false ,這樣我這個(gè)子模塊就是一個(gè) apply plugin: 'com.android.application' 這樣的模塊,是可以單獨(dú)運(yùn)行的一個(gè)項(xiàng)目
try { if (isLibModule) { apply from: "./build_lib.gradle" }else{ apply from: "./build_app.gradle" } } catch (e) { }
可能有時(shí)候還是需要單獨(dú)的運(yùn)行環(huán)境,android編譯方式有2中,一種是debug,一種是release。當(dāng)打包成aar的時(shí)候,使用的是release方式,我們可以把需要調(diào)試的代碼全部放到debug中,這樣打包的時(shí)候就不會(huì)把調(diào)試的文件發(fā)布到aar中。不過(guò)這種實(shí)現(xiàn)方式,需要對(duì)Android項(xiàng)目的目錄有較高的認(rèn)識(shí),才可以熟練使用。
CI
上面介紹的各個(gè)模塊需要單獨(dú)到獨(dú)立的git倉(cāng)庫(kù),同時(shí)打包到單獨(dú)的maven倉(cāng)庫(kù),當(dāng)開(kāi)發(fā)完成后,這時(shí)候就需要進(jìn)行打包,但這個(gè)是一個(gè)簡(jiǎn)單和重復(fù)的事情,所以我們需要一個(gè)工具來(lái)完成這些事情,我們可以利用CI系統(tǒng)來(lái)搞定這件事情,這里我推薦Jenkins,主流廠商使用jenkins作為CI服務(wù)器這個(gè)方案。
具體的步驟就是,需要對(duì)每個(gè)模塊的git倉(cāng)庫(kù)做web hook,我們公司使用的是git lab,可以對(duì)git的各種操作做hook,比如push,merge,tag等。
當(dāng)代碼發(fā)送了變化了,我們可以發(fā)送事件到CI服務(wù)器,CI服務(wù)器再對(duì)各個(gè)事件做處理,比如user模塊develop分支有代碼變化,這個(gè)變化可能是merge,也有可能是push。我們可以把主項(xiàng)目代碼和user項(xiàng)目的代碼單獨(dú)clone下拉,然后編譯一下,確認(rèn)是否有編譯問(wèn)題,如果有編譯通過(guò),那么在使用相關(guān)gradle命令發(fā)布到maven倉(cāng)庫(kù)中。
不管每次編譯結(jié)果怎樣,是成功還是失敗,我們都應(yīng)該把結(jié)果回饋給開(kāi)發(fā)者,常見(jiàn)的方式是郵件,不過(guò)這個(gè)信息郵件方式可能很頻繁,我們建議使用slack。
到此,相信大家對(duì)“Android模塊化怎么實(shí)現(xiàn)”有了更深的了解,不妨來(lái)實(shí)際操作一番吧!這里是創(chuàng)新互聯(lián)網(wǎng)站,更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢,關(guān)注我們,繼續(xù)學(xué)習(xí)!