应用模板代码地址：https://github.com/thfhongfeng/AndroidAppTemplate
（可直接参考项目根目录的readme文件）
特点：
- 模块化开发 ，支持MVC， MVP， MVVM架构；
- 依赖包统一管理，配置分离；
- 尽量做到第三方API可插拔化，与业务代码分离；
项目目录结构图：
- tool模块为公共模块，与项目和业务无关，主要是一些通用的工具类，控件类及组件。
- config模块为配置模块，该模块与config_xxx.gradle中的配置项相配合， 主要进行项目的配置，比如：项目常量设置，项目模块开关及业务功能开关等。
- router模块为路由模块，用于bundle模块间的通信。
- base模块为主体基础模块，该模块放置了所有项目和业务通用基础库（与项目相关，但不与具体业务相关）。
- base_lib_immersionbar模块为沉浸式状态栏lib库，base模块中用到。
- app_welcome为入口模块，用于App入口界面的启动。主要包括loading界面（app初始数据的获取：例如版本更新情况等）和welcome界面。
-
app为构建模块，主要用于项目初始化，构建和打包，与具体业务无关。
以上为项目必不可少的模块，为项目的主体模块。
—————————————————————— - bundle_xxx为常用基础业务模块，包括：bundle_main, bundle_login, bundle_user
- bundle_business_xxx为"xxx"具体业务模块。
- xxx_lib_yyy为 "xxx"模块对应的lib库"yyy"。
-
db_server为本地数据库模拟后台数据服务器模块（不需要搭架后台数据服务就可以对模板功能进行调试验证），为了调试和演示。
以上模块在自己的项目中均可删除，其中bundle_business_mvc，bundle_business_mvp，bundle_business_mvvm为Demo性质的模块，主要用来引导如何使用这个架构模板；db_server则是为了方便调试和演示；bundle_main，bundle_login，bundle_user根据自己的需求也可以集成到自己的项目中。
——————————————————————
tool模块主要包说明：
access-----------------准入条件封装，已在基础ui中封装使用。
request----------------数据请求封装（http，database）。
permission-----------EasyPermission的进一步封装，已在基础ui中封装使用。
widget-----------------项目无关的自定义小控件集合（不设具体界面样式）。
architecture----------编码架构封装：mvc，mvp，mvvm（不设具体界面样式）。
util----------------------项目无关的工具集合。
bean、exception---实体类及异常类集合。
base模块主要包说明：
util----------------------项目相关而具体业务无关的工具集合，此工具集合与tool模块的工具的主要区分依据是：是否与项目有关。tool中的工具类要求严格做到与项目无关，是语言与数据处理级别的。
widget-----------------项目相关而具体业务无关的自定义小控件集合（有具体的通用的界面样式）。
component-----------各种实用组件封装。
recycler_view--------RecyclerView适配器的封装。
architecture----------编码架构封装：mvc，mvp，mvvm（有具体的通用的界面样式）。
ui-----------------------通用Activity和fragment封装，默认android原生架构方式（有具体的通用的界面样式）。
db----------------------应用通用数据库（基于room），用于app的整体数据库操作。
模块多渠道客制化步骤：
分两种渠道：common渠道为通用渠道（开发功能时的默认渠道）；其它渠道（huawei、小米等）
一、在src下建立不同渠道对应的文件夹（如：common、huawei、xiaomi）。
二、修改模块下的gradle：
a. defaultConfig闭包中添加：
flavorDimensions "default"
b. android闭包中添加：
productFlavors {
common {
}
huawei {
}
xiaomi {
}
}
三、将模块中渠道有差异化的实现代码写在对应渠道文件夹中：
a. 差异化的资源文件，直接同名到各个渠道文件夹中（渠道中的同名资源文件会自动覆盖掉main中的资源文件，从而实现渠道差异化）；
b. 差异化的代码文件则需放在common中进行开发，然后拷贝到各个渠道文件夹中进行差异化开发（各个渠道文件保持路径一致）。
渠道化文件夹说明：
main---主体源文件夹。所有渠道共有。
common---默认渠道源文件夹，一般是差异化功能的全部默认实现。
Xxx---各客制化渠道源文件夹，对应不同渠道。为common的拷贝，并在此基础上进行自己渠道的客制化。
编码规范：
- bundle业务模块所有的资源必须以bundle名小写开头，例如login模块的xxx资源必须写为"login_xxx"。
- bundle业务模块所有的类建议以bundle名首字母大写开头，例如login模块的类Xxx写为"LoginXxx"。
- 所有bundle间的通信必须要统一使用router模块进行。为了减少对业务模块的污染，本项目并没有按arouter的规范方式进行模块间通信，而只是借助了其部分功能。
- 编码时特别是编写公共类库时，请确认该类库的共性：
a. 有项目共性，与具体业务无关的统一放在base模块中。
b. 无项目共性，与业务无关的的统一放在tool模块中。 - 第三方类库统一接口化编程，即定义项目要用到的接口，业务代码统一使用接口调用，具体实现类才与第三方关联，做到业务代码与第三方类库分离。
- 模块内代码架构推荐使用MVVM架构。
新建业务模块注意事项：
- 业务模块的Application类统一继承base模块的BaseApplication类。
- 业务模块的Constants常量类统一继承base模块的BaseConstants类。
- 业务模块的UrlConstants常量类统一继承base模块的BaseUrlConstants类。
- 业务模块的SPKeyConstants常量类统一继承base模块的BaseSPKeyConstants类。
- 业务模块arouter通信的搭建（结合arouter的通信方式说明文档来理解）：
a. 模块中编写XxxRemote（可参考已有模块，基本内容都差不多）和XxxRemoteService类（通信方法写在该类中，使用注解方式），用于向外部模块提供统一的跨模块服务。
b. 模块中编写XxxClientManager（可参考已有模块），用于统一调用外部模块的跨模块方法。
c. router模块中编写通信命令常量类RouterXxxCommand，添加相关注释（可参考已有模块）。
d. 模块间通信使用方式：
RouterManager.getInstance(xxxBundleKey).callYyCommand(Context context, final String commandName, final Bundle args, final IRouterCallback callback);
该调用统一写在XxxClientManager中
