关于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新版本都要做兼容,甚至完全要看谷歌让不让用。
组件化和插件化都是业务架构范畴,是考虑如何拆分以及更好的拆分业务才是核心。

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

关于android app架构的一点思考_第1张图片

详细设计:
关于android app架构的一点思考_第2张图片

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

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

你可能感兴趣的:(树文个人思考,android,架构)