lib_sdk层
这里是一些开发工具包，里面包含所有android需要的包
比如appcompat、kotlin等一些Jetpack必备的，我这里用了一些，但也有的没用到，还是看具体的需求在决定。
lib_base层
这里是一些Base的类，比如BaseActivity，BaseFragment，和一些Utils的封装库，
比如一个图片库，再这里可以进行二次封装，假设我们在用一个图片库，这个图片库作者不维护护着不开发了，然后又有些bug，我们就不需要在所有的地方进行修改，在lib_base层修改就可以了，网络请求的库，一些工具库都可以在这一层封装。
lib_base
我这里没封装太多，只有一些最简单的东西。
lib_service层
这一层是提供模块服务的，这一层主要是接口和接口对象，因为这一层需要被所有的业务模块依赖，让模块与模块之间可以相互调用
lib_service
如图，NewsService接口，里面只有一个打开的方法，NewsInstance类，是一个接口对象。具体实现是由业务模块实现。
//定一个接口
interface NewsService {
fun start(context: Context)
}
//另一个类定义一个接口对象，这个对象由业务模块 进行实例化
object NewsInstance {
lateinit var service: NewsService
}
lib_widget层
这一层是一些自定义组件层，本质上也是一个模块，只不过这个模块只有自定义组件和一些修改的组件等等，多加了这一块，是为了把所有的自定义组件和第三方的组件放一起，当然开发中，多人是按模块开发，或者是说某个业务需要一个自定义组件可以在这里进行开发、测试。
module_home、module_news
这一层都是业务模块了，各种Activity，NewsActivity、HomeActivity。。。
这一层依赖了lib_base、lib_service、lib_widget，在这一层为业务模块提供基类方法、组件、工具类等。base:有各种BaseActivity等，NewsActivity继承BaseActivity，符合依赖倒置原则service：是各种各种接口，module_news模块完成lib_service中的接口，暴露当前模块的业务，其他模块只能通过这些暴露的方法，去调用。符合接口隔离原则widget：是各种组件给业务模块提供界面上的需求
module_news
NewsServiceImpl 类，继承了lib_service层NewsService的接口，并完相应方法，比如打开NewsActivity的 override fun start(context: Context) 方法。
//这里继承NewsService接口，完成方法
class NewsServiceImpl : NewsService {
override fun start(context: Context) {
NewsActivity.start(context)
}
}
在lib_service层接口对象 就是这个类的实例
module_web、module_flutter
这一层还有web和flutter模块flutter和上面的业务模块也是相同，通过接口打开flutter模块的界面，当然flutter也需要有导航功能，也就是传入一个参数，具体跳转到flutter模块的那一个页面。web这里也弄了一个独立进程出来，为什么要独立进程，因为大量的Web页面会导致App内存占用过高，影响到App，比如App打开几个界面，然后打开了WebView加载了网页，导致栈底的界面被销毁，再回去时又需要重新创建，如果没有做好处理很有可能会有空指针错误或者其他错误。具体看这里，独立进程的解决方案，就不多赘述了。
APP
这里是个壳模块，基本上都是集合所有模块组成一个App，基本是初始化、注入一些工作
最后
demo地址
我用了阿里的arouter进行路由跳转，工程用了MVVM和AAC模式进行搭建
工程中用了koin为ViewModel进行注入，网络库也是okhttp，retrofit
异步操作，我使用了kotlin里的协程
整个工程的gradle配置 也是用apply的方式，模块的gradle，应用一个公共的gradle配置，也有一个全局的变量isModule，true、false标志表示是模块还是库模块，默认是false，当为true时模块都变成了可以直接运行的app模块，module_widget也变成了app模块，可以进行单独的 自定义View的开发。
每个模块都有两个Androidmanifest.xml文件，对应当前模块是app模块还是库模块。
模块化有助于多人一起开发，互不干扰，提交git也不需要来回pull、push，每块的资源都有相同的前缀，也不会造成资源id的冲突。对于一些lib层，开发稳定，app项目变多，可以把这层内容上传到maven仓库，直接依赖，也可以搭建私人的maven仓库进行上传。
如果库有什么建议或意见可以共同探讨，或者有更好搭建方式，也可以私信我。
