前言:不知道你们是否是像我没作模块化、组件化以前同样,感受这个架构是一个很高深、很复杂的东西,作起来应该很难,其实作过以后你会发现模块化、组件化不过如此。这篇文章我将会向你们分享一下与模块化、组件化的一些知识,相信当你读过这篇文章后,你也会觉的模块化、组件化不过如此。缓存
本文的结构以下图,文章将会围绕下图列出的几点来详细的讲解模块化、组件化的知识。网络
模块化、组件化是一种架构思想、与平台无关的一种解耦手段。为何咱们老是把模块化、组件化放在一块儿呢?由于它们之间的关系是你中有我,我中有你的关系。就好比,咱们将一个app拆分红几个功能模块,这几个模块确定会依赖一些公共的组件,如网络组件、图片组件、音视频组件等,而这些组件中可能又会细分出一些模块,如图片组件中的,下载模块、缓存模块等。若是非要将它们两个区分开来,可能就是下面的定义:架构
项目作的好好的,为何要将项目改为模块化、组件化的架构呢?缘由以下:app
将项目改为模块化、组件化的架构,就是为了解决上面出现的问题。模块化
其实不是每个项目都应该有模块化、组件化的架构的。好比,咱们作了一个小项目,这个项目的功能不多,而且之后也不会增长新功能,一我的开发这个项目彻底没问题,在这种状况下,若是再用模块化、组件化的架构,简直就是杀鸡用牛刀、劳命伤财。工具
在咱们将项目模块化的时候,就会面临怎么拆分模块的问题,因此在拆分模块化的时候就要遵循一些原则,须要遵循的原则就是组件化
为何要说这两个原则呢?由于在模块化的时候你可能会遇到不知道将某段代码应该放在哪一个模块中的问题,这时你就根据上面的原则来判断应该将代码放在上层仍是下层或则应该放在哪一个模块中。code
解释一下上面的两个原则,看下图模块化开发
从图中能够看到,这里将模块化分红了四层,“同层之间不能相互依赖”这个原则,就是说在同一层的各个模块之间不能有依赖的关系,如在“业务功能模块”这一层可能会有几个功能模块,这几个功能模块之间是不能有依赖关系的。“只能上层模块依赖下层模块,下层模块不能依赖上层”这个原则就是不能让层级在下面的模块依赖上层的模块,若是有依赖关系,应该将被依赖的模块放在依赖模块的同层或则下层。cdn
关于这个问题呢,并无明确的答案。通常采用的作法就是将一些公用的而且不会变更或者不常改动的功能放在基础库中,如网络请求、图片加载及一些工具类等。基础组件着一层呢,就是放置一些第三方的SDK,如支付、统计、bug收集等。业务功能模块这一层就是放置咱们项目功能有关的代码,这一层的拆分关系到之后开发的耦合度,所以要慎重,固然最合理就是一个功能拆分红一个模块,但这样就会出现拆分的粒度过小的问题,因此关于这一层的拆分最好是团队内讨论决定。最上面的一层就是app的壳了,这一层通常不会有什么功能,就是用来初始化项目,Android项目通常会将应用的application类放置在这层。
从上面模块间划分的原则,能够知道,同层模块之间是不能相互依赖的,这就会出现“不能依赖,模块间怎么通信的问题?”举个例子,在两个模块之间,若是一个ActivityA要跳转并传值给ActivityB,应该怎么传值呢?没有模块化的时候能够经过stratActivity
或则startActivityForResult
方法来显式跳转界面完成传值,可是在模块化开发时,可能ActivityA在A模块里ActivityB在B模块中,由于模块A和模块B在同一层,没有依赖关系,就不能直接传值了,那怎么解决这个问题呢?答案就是用路由的方式,在Android中通常是用ARoute开源库,使用这个库后只要定义好跳转的路径就好了,在打包app后就会根据定义好的路径找到对应的界面,关于具体的使用方法,你们能够自行搜索。
本文主要的内容是将模块化的思想说明了一下,本文的目的是让你们再也不认为模块化是一个很难的架构,再也不会由于以为模块化是一个比较高深的东西而不敢尝试。若是在项目开始的时候不考虑模块化,那么随着项目的发展总有一天你会采用这个架构的,等项目大起来之后从新修改架构就不是那么容易了。但愿你们在作项目的时候不要欠下技术债,若是技术债是不可避免的,那么应该尽早的偿还。
文中并无讲解模块化的具体实现,关于具体的实现细节网上已经有不少的文章了,能够根据本身的须要自行了解。本文主要就是让你们领会模块化的思想,理解思想以后,剩下的就是去实践了,相信读过本文以后,你作起模块化必定会事半功倍。
本文已由公众号“AndroidShared”首发