对App应用架构搭建的一些思考

当下随着App开发技术的越来越成熟，多人协同开发必不可少，一个团队中每个人的代码风格、技术栈都存在差异，因此统一一套成熟的开发架构必不可少，可以提高开发效率、统一代码风格、为项目维护提供便利。

当下App源码工程通常采用组件化结构，将一个工程拆分为公共基础组件、业务功能库组件、业务数据组件、业务逻辑组件。

在CommonModel公共基础组件里面，依赖一些通用工具，如：图片加载库Glide、日志库Log、常用工具类utilcodex、简单的数据存储mmkv、下拉刷新SmartRefreshLayout、recycleview适配器baseQuickAdapter、路由库Arouter、lifecycle、ktx、jetpack组件等，需要所有的业务逻辑模块对其进行依赖，提供给各个业务逻辑模块使用，避免各个模块重复依赖，也利于第三方库的管理。

其它的业务专用功能库，如视频库（视频取流、解码、转码等）、支付库（支付宝、微信等）提供给特定的业务模块，只有相应的业务模块依赖。

业务数据Model是将对应的业务数据接口进行封装，一般包含网络http(s)接口、websocket、socket、ftp、database等需要与远程后端或本地数据进行数据方面操作强相关逻辑的封装。如登录功能，使用将登录接口进行封装，在数据模块定义登录接口，接受用户名、密码等通过网络发送给后端进行验证，处理返回结果，将结果回调给逻辑模块。

业务逻辑Component是负责与用户进行交互的上层逻辑，如视频模块包含的预览、回放界面、对业务数据模块调用获取数据，展示数据等逻辑，一般情况下各个业务模块相互独立，不存在依赖关系。

App壳工程，不包含任何业务相关的逻辑，依赖所有业务模块，是整个程序的入口。

以上是对整个工程结构的一些思考，那么通常情况下，各个业务模块是需要进行通信的，并非完全不相关的，比如业务A中有个地方需要携带一些数据跳转到业务B界面进行展示，这就涉及到组件间通信了。

组件间通信：

业务组件间通信通常包含界面跳转、数据交换等，由于没有依赖关系，不能直接调用。

那么都有哪些解决办法呢？

1、  采用第三路由框架

比较出名的是Arouter

2、  自己实现一套框架