标题:Android---组件化
作者:别偷我的猪_09
原文链接:【精选】Android---组件化_android 组件化-CSDN博客
所有代码写在一个工程里。不同业务写到各自模块,以包名来区分。
弊端
1、无论包名做的再好,随着项目扩大,项目失去层次感,接受吃力。
2、包名作为约束,太弱了。一不注意就会出现不同业务之间之间相互调用,代码高度耦合。
3、多人联合开发在代码管理中很容易出现冲突和代码覆盖问题。
总之:单一分层模式会存在低内聚、高耦合、无重用、层次混乱等问题。
业务组件层各个组件不再出现横向的、直接的依赖关系,可以分别单独编译成一个APK安装包,进行安装、测试,也可以合并编译成一个完成的APK包。组件化后所有的 module 都是平起平坐的,app 模块不再是老大。
组件化的意义:不相互依赖,可以相互交互、任意组合,高度解耦、自由拆卸、自由组装,重复利用、分层独立化。
组件化基于可重用的目的,将应用拆分成多个独立组件,以减少耦合。
1.)通过关注点分离的形式,将App分离成多个模块,每个模块都是一个组件。解决了各种业务代码耦合在一起所导致的问题。
2.)开发的过程中,让这些组件被其它组件依赖,但是在调试时也可以单独成为独立的工程并且运行,这样就解决了因为编译耗时过多降低开发效率的问题。
3.)多人开发中,每个组件模块由单人负责,降低了开发之间沟通的成本,减少因代码风格不一致而产生的相互影响。
1.)组件(Component),是对数据和方法的简单封装,功能单一,高内聚,并且是业务能划分的最小粒度。
2.)组件化是基于可重用的目的,将大型的软件系统按照分离关注点的形式,拆分成多个独立的组件,使得整个软件系统也做到电路板一样,是单个或多个组件元件组装起来,哪个组件坏了,整个系统可继续运行,而不出现崩溃或不正常现象,做到更少的耦合和更好的内聚。
1.)模块化是将一个程序按照其功能做拆分,成为相互独立的模块,以便于每个模块只包含与其功能相关的内容,模块我们相对熟悉,比如登录功能可以是一个模块,搜索功能可以是一个模块等等。
2.)组件化是模块化思想的一种演进,它们二者本质都是一致的。
组件化更注重关注点分离,所谓的关注点分离,就是把复杂的问题做到合理分解,再分别仔细研究这些问题的不同侧面(关注点),最后综合得到整体解决方案。
如果从集合角度来看的话,可以说往往一个模块包含了一个或多个组件,或者说模块是一个容器,由组件组装而成。简单来说,组件化相比模块化粒度更小。
1.)插件化也是基于模块化的思想,将应用拆分成多个模块,而这些模块都是一个APK,最终打包时将宿主APK和插件APK分开打包。在运行程序时,宿主APK可以动态的选择并加载想要的插件APK。
2.)插件化与组件化存在很多相似之处,但是它们根本的区别在于:
组件化的模块虽然在调试的时候可以切换到application独立运行,但是最终在打包时,每个模块始终都只是一个library,整个应用只有单独的一个APK。
插件化是拆分出了多个APK,并且在运行时通过动态加载的技术方案,来加载这些插件APK。
分而治之,并行开发,一切皆组件。要实现组件化,无论采用什么样的技术方式,都需要考虑以下几个方面的问题:
1.)组件分层:如何将一个庞大的项目工程分成有机的整体?
2.)组件单独运行和集成调试:每个组件都是高度内聚的,是一个完整的整体,如何让其单独运行和调试?在开发解读如何做到按需编译组件?
3.)组件间通信:每个组件具体实现细讲都互相不了解,但每个组件都需要给其他调用方法提供服务,那么主项目与组件、组件与组件之间如何通信就变成关键?
4.)组件生命周期:这里的生命周期指的是组件在应用中存在的时间,组件是否可以做到按需、动态使用,因此就会涉及到组件加载、卸载等管理问题。
组件大致分层如下:主工程、业务组件层、功能组件层、基础组件层。
根据组件的分层来创建module。
1.)创建一个项目名为Component(名字随意),作为我们的主工程,是整个应用的主入口。对项目做一些初始化和配置都是在主工程里。
2.)创建第2个业务组件,一个main,一个login。File–>New–>New Module --> Phone & Tablet。业务组件都选择Phone & Tablet,这样后面就可以进行单独的运行和调试。
为了让分层更明显,在Module name栏中加一个moduleCore,后面创建的所有业务组件都放到moduleCore文件夹下面。在Package name栏加一个module,避免命名冲突的一些问题。
3.)创建基础组件。File --> New --> New Module --> Android Library。
在Module name栏中加一个moduleBase,创建的基础组件都放在该文件夹下。同样在Package name栏加上一个module避免命名冲突。
4.)创建功能组件,File --> New --> New Module --> Android Library。
最后,创建的结果如下
对依赖做一个统一的管理,避免因版本不一致而产生的依赖冲突。这么多的module,它可能去依赖各种第三方库、SDK。因此,这里先做一个版本的管理。
1.)在project下的build.gradle里创建一个ext{},里面添加如下内容。
isDebug = false //当它为true时,是调试模式,组件可以单独运行(applicaton);当它为false,是正式的编译打包的模式(library). 作业:使得业务组件可以在application和library之间进行切换
android = [
compileSdkVersion: 32,
minSdkVersion: 21,
targetSdkVersion: 32,
buildToolsVersion: "30.0.2",
versionCode: 1,
versionName: "1.0"
]
applicationId = [ // 可以切换到application
"app" : "com.example.component",
"main" : "com.example.module.main",
"login" : "com.example.module.login"
]
// SDK的一写library
library = [
"appcompat" : "androidx.appcompat:appcompat:1.3.0",
"material" : "com.google.android.material:material:1.4.0",
"constraintlayout" : "androidx.constraintlayout:constraintlayout:2.0.4"
]
//第三方的library
libARouter = "com.alibaba:arouter-api:1.5.1"
libARouterCompiler = "com.alibaba:arouter-compiler:1.5.1"
libGson = "com.google.code.gson:gson:2.8.6"
2.)修改 main业务组件 里的build.gradle文件(login是一样的)。
当main/login是一个applicaton (isDubug==true时, 可以单独运行)时,对AndroidManifest.xml文件也要进行修改。
首先,在mian下面创建一个debug文件夹,然后拷贝一份AndroidManifest.xml 到里面,如下
其次,将main下面的AndroidManifest.xml 做如下修改(注意:不是修改debug下的那个AndroidManifest.xml)
最后,再修改build.gradle(main/login),对当前的业务组件是application还是library进行判断,然后动态的选择两个AndroidManifest.xml
3.)修改 libBase基础组件 里的build.gradle文件
4.)修改 modulePay功能组件 里的build.gradle文件。
5.)修改**主工程(app)**里的build.gradle文件。
到这里,组件化创建工程就以完成。
当把project下的build.gradle里的ext里的isdebug改成true时,就可以单独运行moduleCore.man/moduleCore.login。