关于android app架构的一点思考

关于android app架构的一点思考

关于架构，我们首先要明白的点就是为什么要进行架构设计？
对程序进行架构设计的原因，对于大企业归根到底是为了提高生产力。通过设计使程序模块化，做到模块内部的高聚合和模块之间的低耦合。这样做的好处是使得程序在开发的过程中，开发人员只需要专注于一点，提高程序开发的效率，并且更容易进行后续的测试以及定位问题，而且也方便项目的管理和维护。
但设计不能违背目的，对于不同量级的工程，具体架构的实现方式必然是不同的，切忌犯为了设计而设计，为了架构而架构的毛病。

例子，一个Android应用中，关于Activity，就没有必要做Mvp，或者MVVM的设计，因为没有业务要求，也没有网络请求

但是当你开发的App最终代码量应该在10W行以上，本地需要进行复杂操作，同时也需要考虑到与其余的Android开发者以及后台开发人员之间的同步配合，那就需要在架构上进行一些思考。框架最终要实现的目的无非就是增强项目代码的可读性 ，维护性 和方便测试。
安卓开始之初，业务层项目框架搭建从最初的mvc，到mvp，再到mvvm，再到mvvm的演化mvi，基本的思想都是是相同的，最本质的概念就是 Activity 里做的事情太多了，所以要把 Activity 中与 UI 无关的部分抽离出来，交给别人做。这个 “别人” 在 MVP 里叫作 Presenter，在 MVVM 里叫作 ViewModel。而不论是 MVP 中的约定接口，还是 ViewModel 里的观察者模式，这些都是实现上的细节而已。
而不管是MVC，MVP，MVVM，MVI他们的侧重点是数据从获取到展示的代码逻辑，所要解决的核心问题是数据和界面之间如何更好联系的问题，它的侧重点是界面和数据。

MVI
与前者的主要区别不在于强调严格的单向数据流，而在于从命令式的开发模式，转变为响应式的开发模式。我们并不是说越新潮，越复杂的架构就是最好的，只有合适的架构才是最好的。但是不可否认，从 React 到 Flutter，从 MVI 到 Compose，响应式编程似乎有一统天下的趋势。未来会怎么样，让我们拭目以待。

模块化，组件化、插件化在架构层面的侧重点是业务功能拆分，其中模块化是将应用按功能拆分不同组件或者模块，组件化可以让模块独立运行，不再相互依赖，组件可以依赖同一套libray，组件化最大的好处是有利于团队开发，在团队开发中不需要等待别人的代码，自己可以进行独立测试，写库的写库，写模块的写模块，互不干涉，在android中一个组件对应着一个module，组件化还有一个好处就是可以提高编译效率。在大型项目中使用组件化是必要的，然而在一些独立开发的小型项目中使用组件化反而得不偿失，因为组件化多少会带来代码和配置增多。插件化核心在于动态加载模块，在庞大的工程中，可以按需下载功能包，它不是官方支持的，是一种取巧的技术，在国内盛行，因为android的开源，framework层代码对程序员透明，插件化是android开发者解决一个又一个的问题后诞生的，首先解决的是加载dex文件，android PathClassLoader就能解决，其次是资源文件的加载(res、assets、so) AssetsManager能解决，在资源加载的过程中还要考虑资源id重复或者找不到的问题，再次要解决activity清单文件注册问题，在分析framework后可以采用hook，也就是在调用ams时和ams返回后两个地方进行移花接木，插件化解决了初安装包体太大的问题，按需加载也解决了功能动态下发的问题，但是维护性很高，比如每个android新版本都要做兼容，甚至完全要看谷歌让不让用。
组件化和插件化都是业务架构范畴，是考虑如何拆分以及更好的拆分业务才是核心。

附送一张我自己实现的架构设计：

详细设计：

具体到Store Module,Main Module,Mine Module模块之间的调用通过依赖该模块的export Module

如Mine Module中吊起Store Module，Mine Module依赖 Store Module Export模块即可