Android组件化实现、项目架构思想、组件化架构优化

已于 2024-01-09 21:48:48 修改
阅读量988 收藏 21
点赞数 26
分类专栏： gradle Android groovy 文章标签： android gradle 架构 android studio
于 2024-01-09 21:44:52 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_35298279/article/details/135460961
版权
Android 同时被 3 个专栏收录
28 篇文章 1 订阅
订阅专栏
gradle
3 篇文章 0 订阅
订阅专栏
groovy
1 篇文章 0 订阅
订阅专栏

首先我们需要理解，组件化是一种对完整Android项目模块进行分层的一种架构方式，如果了解过模块化的同学会发现，组件化和模块化的本质上并没有什么不同。废话不多说，接下来我们直接带着大家一起进行基本的组建化搭建，之后我们还会对架构进行整体优化

组件化的基本实现

第一步，进行项目分层

通常我们可以将组建化架构的Android项目分为三或四层，如下图

//1、分层划分：3-4层
//- app（application） 项目入口
//- business（application） 业务层，项目的一些基本业务都在这
//- core（application） 核心层，包含一些公用功能组件，例如音视频播放器等
//- library（library） 依赖库层，包含一些项目中用到的依赖库

然后，我们把项目创建为上述想要的架构方式，创建出所需要的application和library层级

创建application module

创建library module

创建完成后的项目架构

第二步，属性拓展和初始化

由于模块化可以对不同的application module进行单独调试，所以我们每个模块的灵活配置就尤为重要，因此我们需要对项目添加一些扩展属性

如上图，我们添加了common.gradle文件，添加了isModuleDebug用来判断当前模块是否需要单独调试，如果isModuleDebug为true就表示该模块可以单独运行，然后我们可以在所需要判断的模块build.gradle中使用apply from的方式将common.gradle使用进行引用，然后我们在对当前模块的isModuleDebug进行判断

之后，我们也可以对ApplicationId进行相应的判断了 （只有单独调试模式时，module才需要applicationId）

 与此同时，我们也需要对项目的一些初始化进行准备，对app主入口的Application进行编写和配置，我们可以在这里做一些项目的初始化配置，如下两张图

编写MyApplication继承Application

在模块中配置MyApplication

至此，我们的项目组件化的基本架构就算已经完成，接下来我们仍然需要对架构进行进一步的优化

组件化架构优化

第一步，清单文件的统一化管理

由于我们在组件化开发中，application是需要随时变更为library的，因此，我们也需要对清单文件（AndroidManifest）文件进行统一管理

首先，我们需要另外创建一个AndroidManifest.xml作为调试时使用，通常直接把原有的清单文件复制过来即可

然后，我们可以把原来的清单文件去除掉所有视图相关的配置，这样这个清单文件就可以作为该模块为library时编译使用，如下图

我们还需要把相应模块的这两个清单文件通过build.gradle文件中android内部使用sourceSets{

main{}}语法进行配置，同时判断是否为调试模式，如下图

最后，我们别忘了我们还需要在app模块下进行引用，在app下的build.gradle也通过apply将common.gradle引用进来

判断是否调试，如果是直接进行依赖即可 

第二步，版本信息和依赖的统一管理

以上我们虽然实现了组建化的架构，但是版本设置不够统一化，会导致产出多余的配置信息。因此，我们需要对每个模块的版本信息和依赖进行统一化的管理配置

首先我们可以把模块所需要的版本信息转移到common.gradle中

相应的一些配置信息也转移到common.gradle中（图中为转移前）

最后把相应的依赖也转移到common.gradle中

至此，所有的模块都只留下，其余部分可以注释或者删除（根据自身需求）

apply from: "${rootProject.rootDir}/common.gradle"

我们所有的module就只剩下了common.gradle的引用，接下来我们会把所有的上述信息都在common.gradle中进行添加

正式开始迁移，接下来都是基于common.gradle扩展project.ext中添加的信息，我们先将app模块的版本信息迁移过来，如下图，等同于创建了一些常量

之后，创建一个名叫libs的map集合，将所有依赖项进行统一维护

接下来是重头戏，我们将针对application类型的module设置创建一个名叫setAppDefaultConfig的闭包（可以理解为方法的一种，可以传参）将所需要的插件、依赖库、版本信息、SourceSets（找到对应的清单文件）等信息配置到项目中

//专门来设置application module
    setAppDefaultConfig = {
        project ->
            project.apply plugin: 'com.android.application'
            project.apply plugin: 'org.jetbrains.kotlin.android'
            setAndroidConfig project.android
            setDependencies project.dependencies
    }

    setAndroidConfig = {
        android ->
            android.compileSdk = project.compileSdk

            android.defaultConfig {
                minSdk project.minSdk
                targetSdk project.targetSdk
                versionCode project.versionCode
                versionName project.versionName

                //如果是非主app并且在调试模式下的模块，给applicationId添加一个后缀，防止applicationId冲突的问题
                if (project.name == 'app') {
                    applicationId project.applicationId
                } else if (project.isModuleDebug) {
                    applicationId project.applicationId
                    applicationIdSuffix = project.name
                    //举个例子，添加后这句后，若main模块单独编译，则会在applicationId后面添加main
                }

                //ARooter的额外配置
                javaCompileOptions {
                    annotationProcessorOptions {
                        //添加路由每个模块的名称，最好用+=来添加参数，防止参数和其他框架同名的问题
                        arguments += [AROUTER_MODULE_NAME: project.getName()]
                    }
                }
            }
            android.buildTypes {
                release {
                    minifyEnabled false
                    proguardFiles android.getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
                }
            }
            android.compileOptions {
                sourceCompatibility JavaVersion.VERSION_1_8
                targetCompatibility JavaVersion.VERSION_1_8
            }
            android.kotlinOptions {
                jvmTarget = '1.8'
            }

            //同样把sourceSets也转移到这里
            android.sourceSets {
                main {
                    if (project.name != 'app' && project.isModuleDebug) {
                        //以后创建application也需要创建debug下的AndroidManifest文件（需要制定开发的规范性）
                        manifest.srcFile "src/debug/AndroidManifest.xml"
                    } else {
                        manifest.srcFile "src/main/AndroidManifest.xml"
                    }
                }
            }
    }

 同时，我们也将针对library类型的module设置创建一个名叫setLibsDefaultConfig的闭包

    //专门来设置library module
    setLibsDefaultConfig = {
        project ->
            project.apply plugin: 'com.android.library'
            project.apply plugin: 'org.jetbrains.kotlin.android'
            setAndroidConfig project.android
            setDependencies project.dependencies
    }

我们会发现，上述的两个闭包同时还调用了 setDependencies这个闭包，它将提供项目的共有依赖项，我们也把它创建出来，如下代码

//设置依赖
    setDependencies = {
        dependencies ->
//            implementation project(':business:main')
//            implementation project(':business:login')
            //这里将delegate代理设置为dependencies这样如下依赖就可以在dependencies中寻找了，否则会找不到
            delegate = dependencies
            /**
             * 这里会遍历已经声明的map集合，然后分别进行依赖。
             * 注意：这里会出现多个module同时依赖的情况，单实际单独调试时本就已经节约了百分之80的时间，而且gradle会把依赖除重，所以不用担心
             */
            project.libs.each {
                key, value -> implementation value
            }
            project.apts.each {
                key, value -> annotationProcessor value
            }
            //可以用如下方式直接依赖，也可以通过上述声明方式更便捷的管理依赖
//            implementation 'androidx.core:core-ktx:1.7.0'
//            implementation 'androidx.appcompat:appcompat:1.3.0'
//            implementation 'com.google.android.material:material:1.4.0'
//            implementation 'androidx.constraintlayout:constraintlayout:2.0.4'
            //独立的依赖方式可以放在这里
            androidTestImplementation 'androidx.test.espresso:espresso-core:3.4.0'
            //只有module为app主入口且非单独调试模式时进行依赖
            if (project.name == 'app' && !project.isModuleDebug) {
                implementation project(':business:main')
                implementation project(':business:login')
            }
    }

 最后，我们在project.ext扩展的外部添加setAppDefaultConfig闭包和setLibsDefaultConfig闭包的调用

if (project.name == 'app' || isModuleDebug) {
    //除了app,还有组建单独调试的情况，此类情况直接调用setAppDefaultConfig
    project.setAppDefaultConfig project
} else {
    project.setLibsDefaultConfig project
}

至此，我们的gradle整体迁移就算完成了 ，common.gradle完整代码如下

//添加项目的属性扩展，这里主要是作为公用的gradle处理
project.ext {
    //当前Module是否单独调试 false表示不单独调试
    isModuleDebug = true

    applicationId = "com.componential.demo"
    minSdk = 21
    targetSdk = 32
    versionCode = 1
    versionName = "1.0"
    compileSdk = 32

    //对所有依赖项进行统一管理 key简写即可 value是实际依赖项的全名
    libs = [
            "ktx"             : "androidx.core:core-ktx:1.7.0",
            "appcompat"       : "androidx.appcompat:appcompat:1.3.0",
            "material"        : "com.google.android.material:material:1.4.0",
            "constraintlayout": "androidx.constraintlayout:constraintlayout:2.0.4",
    ]
    //把ARooter也依赖进来
    apts = [
            "ARouterCompiler": "com.alibaba:arouter-compiler:1.5.2",
    ]
    //专门来设置application module
    setAppDefaultConfig = {
        project ->
            project.apply plugin: 'com.android.application'
            project.apply plugin: 'org.jetbrains.kotlin.android'
            setAndroidConfig project.android
            setDependencies project.dependencies
    }

    setAndroidConfig = {
        android ->
            android.compileSdk = project.compileSdk

            android.defaultConfig {
                minSdk project.minSdk
                targetSdk project.targetSdk
                versionCode project.versionCode
                versionName project.versionName

                //如果是非主app并且在调试模式下的模块，给applicationId添加一个后缀，防止applicationId冲突的问题
                if (project.name == 'app') {
                    applicationId project.applicationId
                } else if (project.isModuleDebug) {
                    applicationId project.applicationId
                    applicationIdSuffix = project.name
                    //举个例子，添加后这句后，若main模块单独编译，则会在applicationId后面添加main
                }

                //ARooter的额外配置
                javaCompileOptions {
                    annotationProcessorOptions {
                        //添加路由每个模块的名称，最好用+=来添加参数，防止参数和其他框架同名的问题
                        arguments += [AROUTER_MODULE_NAME: project.getName()]
                    }
                }
            }
            android.buildTypes {
                release {
                    minifyEnabled false
                    proguardFiles android.getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
                }
            }
            android.compileOptions {
                sourceCompatibility JavaVersion.VERSION_1_8
                targetCompatibility JavaVersion.VERSION_1_8
            }
            android.kotlinOptions {
                jvmTarget = '1.8'
            }

            //同样把sourceSets也转移到这里
            android.sourceSets {
                main {
                    if (project.name != 'app' && project.isModuleDebug) {
                        //以后创建application也需要创建debug下的AndroidManifest文件（需要制定开发的规范性）
                        manifest.srcFile "src/debug/AndroidManifest.xml"
                    } else {
                        manifest.srcFile "src/main/AndroidManifest.xml"
                    }
                }
            }
    }
    //专门来设置library module
    setLibsDefaultConfig = {
        project ->
            project.apply plugin: 'com.android.library'
            project.apply plugin: 'org.jetbrains.kotlin.android'
            setAndroidConfig project.android
            setDependencies project.dependencies
    }

    //设置依赖
    setDependencies = {
        dependencies ->
//            implementation project(':business:main')
//            implementation project(':business:login')
            //这里将delegate代理设置为dependencies这样如下依赖就可以在dependencies中寻找了，否则会找不到
            delegate = dependencies
            /**
             * 这里会遍历已经声明的map集合，然后分别进行依赖。
             * 注意：这里会出现多个module同时依赖的情况，单实际单独调试时本就已经节约了百分之80的时间，而且gradle会把依赖除重，所以不用担心
             */
            project.libs.each {
                key, value -> implementation value
            }
            project.apts.each {
                key, value -> annotationProcessor value
            }
            //可以用如下方式直接依赖，也可以通过上述声明方式更便捷的管理依赖
//            implementation 'androidx.core:core-ktx:1.7.0'
//            implementation 'androidx.appcompat:appcompat:1.3.0'
//            implementation 'com.google.android.material:material:1.4.0'
//            implementation 'androidx.constraintlayout:constraintlayout:2.0.4'
            //独立的依赖方式可以放在这里
            androidTestImplementation 'androidx.test.espresso:espresso-core:3.4.0'
            //只有module为app主入口且非单独调试模式时进行依赖
            if (project.name == 'app' && !project.isModuleDebug) {
                implementation project(':business:main')
                implementation project(':business:login')
            }
    }
}

if (project.name == 'app' || isModuleDebug) {
    //除了app,还有组建单独调试的情况，此类情况直接调用setAppDefaultConfig
    project.setAppDefaultConfig project
} else {
    project.setLibsDefaultConfig project
}

第三步，实现组建间通信

最后的最后，由于组建间本身是没有通信手段的，我们还需要依赖一些手段来实现组建化通信。目前市面上有很多框架支持组建间通信，这里我们使用较为主流的阿里开发的ARooter框架实现组建间的通信，ARooter是一个阿里推出的路由引擎，是一个路由框架，并不是完整的组件化方案，可作为组件化架构的通信引擎，接下来我们直接在项目中依赖ARooter

//把ARooter也依赖进来
    apts = [
            "ARouterCompiler": "com.alibaba:arouter-compiler:1.5.2",
    ]

如上代码，我们先创建名叫apts的map的集合把ARooter的依赖存放进来，咱们使用当前最新的版本1.5.2，然后还需要通过each的方式遍历map集合，通过如下方式将arouter-api也依赖进来

最后，我们还需要添加一个ARouter的必添参数，直接配置在setAndroidConfig这个闭包中即可

至此，我们便完成了ARouter配置，并且完成了组建化从通信到架构的完整搭建，可以正式进入开发阶段啦，之后还可以继续对项目进行优化调整。

同时我们仍需注意的是，由于我们在上面在SourceSets中给application module设置了debug目录下的清单文件，因此，在今后的开发过程中需要针对开发人员制定相应规则，在每次创建新的module时需要在对应debug目录下创建清单文件，并把原有的清单文件改造成library所需的结构

额外拓展

本篇内容我们虽然已经做了完整的依赖和配置整合，但偶尔我们也会需要一个单独模块的定制化，因此我们仍然可以在任意模块的build.gradle中单独做配置，这样也进一步提升了项目的灵活性

王海萧
关注
  • 26
    点赞
  • 踩
  • 21
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
Android组件化工程结构以及项目实施
isJoker的博客
10-23 425
组件化优点 1、代码解耦 2、方便多人协作开发 3、可复用性高，不同的APP可复用不同组件 4、每个组件可独立运行，方便开发调试 组件化工程结构 [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传 **第一层：**空壳app。应用的入口，存放启动页，依赖所有业务组件 **第二层：**业务组件。根据不同业务横向拆分出来的业务组件。任何一个业务组件都可以独立出来成为一个应用 **第...
Android 架构演进及未来，Android组件化架构实践
m0_66155658的博客
02-05 220
MVC 结构清晰，低耦合，有利于组件重用；但是Activity/Fragment中代码较多，结构比较复杂； MVP 解决了MVC中Activity的问题，但是接口大量增加，所以项目的文件数量也会很多，代码结构也更复杂性了… 从工作到现在，经历过了MVC、MVP、Clean等，每个App由于项目特点和需求的不同，其架构模式，分层、组件化、模块化，每一种设计都是基于项目所在场景的，很难适合所有项目场景。这时候我们该怎么办呢？ 我们或许可以在Google “钦定”的 Android 开发未来第一架构——MVVM中
Android项目基础架构。包含架构分层、基本工具层等
12-12
采用二次封装后的okhttp3+Gson.(没有使用retrofit,考虑到服务端提供的API可能不会很标准) 基本功能: POST请求 GET请求 上传文件&进度监听 下载文件&进度监听 返回可以选择Gson格式 取消某个context的所有网络请求 并且将该功能模块独立为MyOkhttp,可以重复使用.
Android组件化，全面掌握
最新发布
Dream It Possible
06-15 93
组件化去除模块间的耦合，使得每个业务模块可以独立当做App存在，对于其他模块没有直接的依赖关系。此时业务模块就成为了业务组件。而除了业务组件，还有抽离出来的业务基础组件，是提供给业务组件使用，但不是独立的业务，例如分享组件、广告组件；还有基础组件，即单独的基础功能，与业务无关，例如 图片加载、网络请求等。这些后面会详细说明。组件化带来的好处加快编译速度：每个业务功能都是一个单独的工程，可独立编译运行，拆分后代码量较少，编译自然变快。提高协作效率：解耦 使得组件之间 彼此互不打扰，组件内部代码相关性极高。
Android---组件化
qq_44950283的博客
12-17 4324
1.）组件（Component）,是对数据和方法的简单封装，功能单一，高内聚，并且是业务能划分的最小粒度。2.）组件化是基于可重用的目的，将大型的软件系统按照分离关注点的形式，拆分成多个独立的组件，使得整个软件系统也做到电路板一样，是单个或多个组件元件组装起来，哪个组件坏了，整个系统可继续运行，而不出现崩溃或不正常现象，做到更少的耦合和更好的内聚。
Android组件化架构解析总结
XBlithe的博客
07-07 1550
前面说到，组件化的核心就是解耦，所以组件和组件之间是不能有依赖的，例如在首页模块点击购物车按钮需要跳转到购物车模块的购物车页面，两个模块之间没有依赖，所以不能在使用Activity的显示跳转来跳转页面了 ，虽然隐式启动是可以实现跳转的，但是隐式 Intent 需要通过 AndroidManifest 配置和管理，协作开发显得比较麻烦。建议创建一个lib_core的公共功能模块组件，将常用的与业务无关的功能封装到此模块中，例如图片加载功能，网络请求功能，日志管理功能等，这些功能可以被所有的app通用。
Android 组件化架构思路
1
06-25 691
项目模块化需要对项目总体进行把控，业务的划分，功能模块的抽取，以及合适的架构方案跟技术选型，这都需要花费很多精力，任重而道远。但是很多开发者以前根本就没有接触过组件化开发，对其中的技巧和用法不是很了解，考虑到这些问题，在这特别准备了帮助大家去熟知该功能的应用。
手把手教你搭建android项目框架（一）选择篇
flowerdanceX的博客
08-30 824
本系列旨在帮助android新人搭建属于自己的项目框架。由于篇幅较长，本人时间有限，因 本篇搭建框架适用于中大型项目。此系列持续更新，直到完成一个完整项目。
Android 组件化架构设计从原理到实战
UrasakiNakajima的博客
06-07 1210
这里我们采用业界通用的方式—路由，比较著名的路由框架有阿里的ARouter、美团的WMRouter，它们原理基本是一致的。组件化开发：就是将一个app分成多个Module，每个Module都是一个组件（也可以是一个基础库供组件依赖），每一个业务模块彼此之间是没有任何关系的， 彼此的代码和资源都是隔离的，并且不能够相互引用，每一个都是平行关系。开发的过程中我们可以单独调试部分组件，组件间不需要互相依赖， 但可以相互调用，最终发布的时候所有组件以lib的形式被主app工程依赖并打包成1个apk。
Android 架构 - 组件化 Componentization
HugMua的博客
01-03 2382
继承自 lib_common 中提供的 BaseApplication，组件自定义的 Application 写在 debug 目录中，在集成模式下剔除。（别忘了在下方 debug 目录中的 AndroidManifest 中注册）
Android 组件化○
zenmela2011的专栏
07-29 5028
1.组件化 组件化是指解耦复杂系统时，将多个功能模板拆分、重组的过程。在Android工程表现上就是把app按照其业务的不同，划分为不同的Module。 组件化架构的目的就是让每个业务模块变得相对独立，各个组件在组件模式下可以独立开发调试，集成模式下又可以集成到“app壳工程”中，从而得到一个具有完整功能的APP。 以美团外卖app为例： 组件化每一个组件都可以是一个APP，可以单独修改调试，而不影响总项目。 ①app壳：负责管理各个业务组件和打包APK，没有具体的业务功能； ②业务组件层：
Android组件化入门：一步步搭建组件化架构
hdbdhdbh的博客
08-04 1473
最近因为业务需求变更，有考虑采用组件化架构进行开发，这方面我之前没有接触过。关于组件化的文章很多，各方大神更是提出了各种的组件化方案，我也看了很多相关文章。但是学习新东西看的再多，不如动手做一次，先不考虑复杂的东西，先动手做个简单的Demo更有助于理解组件化的思想。废话不多说，直接动手开码。
Android组件化架构搭建
qq_36828822的博客
11-11 1553
因为，我们如果要打成一个完整的apk，那么势必就只能要app这个主模块，其余的common、order、personal就只能是充当依赖库的角色，这个大家都好理解。例如，order模块的功能已经开发好了，测试组想要先测试这个功能，那么我们完全可以只打一个只含有order功能的包给测试。common模块就对应着上面示意图的公共基础库，当然我们，可以继续拆分，将utils拆成一个library，http拆成一个library，然后让common模块同一依赖这些基础库。这里，我们的组件化架构就大体搭建完成了。
Android 组件化架构概要，2024安卓面试题
m0_60607895的博客
03-30 632
我们在Project的根目录创建一个config.gradle来统筹我们的依赖和版本信息里面比较关键的还是我们配置的 IS_BUILD_MODULE 变量，如果可以设置当为true的时候，Module可以单独运行，即Application，如果为false，那么我们就只能让Module作为Library来执行，至于其他的，都是一些普通的配置。
“终于懂了” 系列：Android组件化，全面掌握
胡飞洋的技术积累
10-08 2547
方式一：单工程多module，使用properties来切换app、library https://juejin.im/post/6844903649102004231 问题： 0、没法做到代码权限管控，没法做到人员职责划分，每个人可以对任意的组件修改，显然会造成混乱 1、数据传递、方法调用：IProvider ，@Route 2、组件获取 App生命周期，有，但不灵活 3、获取fragment，@Route 方式二：多工程、arr依赖 https://www.jianshu.com/p/06931c9b7
Android 组件化架构-简谈
nahfang的博客
03-14 6820
说在前面： 随着业务的增加，由于单一工程下业务全都集合在主工程下，而导致业务间相互交错的依赖耦合越来越严重，那么就可能出现动一触千的现象，这时候将业务按照功能的不同抽离出来就显得迫在眉睫。 了解组件化 在了解组件化之前，我们需要先了解模块化。 模块化就是将整体业务集合按照功能的不同，抽离到不同的模块中，这样做的好处就是在团队协助中能够较好的区分各自负责的功能模块、也能使得整个工程显得不是那么庞大和复杂。 但是在工程结构不断扩大的情况下，模块之间的耦合也会变的错综复杂，这时候我们就需要将模块化再次升级，使得各
Android：项目模块化/组件化的架构之路（一）
热门推荐
李益
11-13 1万+
随着技术越来越成熟，这两年，组件化开发与插件化开发的热度一度高涨。对于组件化，有的人也喜欢称之为模块化开发，我也比较喜欢称之为模块化开发。使用模块化开发也已经有一段时间了，特此总结一下模块化开发的心得，防止以后忘记。 什么是模块化开发 对于模块化开发的概念，有的人可能还不是很了解，通俗的来讲就是： 将项目中的具体功能模块，如登录、个人中心等，拆分成一个一个单独的module， 将其中公用的功...
Android 组件化架构概要
2401_83817439的博客
04-04 763
在技术领域内，没有任何一门课程可以让你学完后一劳永逸，再好的课程也只能是“师傅领进门，修行靠个人”。“学无止境”这句话，在任何技术领域，都不只是良好的习惯，更是程序员和工程师们不被时代淘汰、获得更好机会和发展的必要前提。如果你觉得自己学习效率低，缺乏正确的指导，可以一起学习交流！加入我们吧！群内有许多来自一线的技术大牛，也有在小厂或外包公司奋斗的码农，我们致力打造一个平等，高质量的Android交流圈子，不一定能短期就让每个人的技术突飞猛进，但从长远来说，眼光，格局，长远发展的方向才是最重要的。
Android组件化架构实践
hdbdhdbh的博客
07-27 143
组件化架构”能够清晰的划分项目结构，严格的将代码根据“业务组件”、“模块组件”、“基础组件”进行划分，各个项目组成员可以并行开发module而互不干扰，而且其可扩展性也比较强，对业务不断扩大的项目是一个不错的选择。可以模拟虚拟机的工作流程：加载-验证-准备-解析-初始化-使用-卸载，同时使用ApplicationDelegate代理，hook住Application的各个生命周期，这样就可以实现组件的同步加载，需要主动销毁时，则可以将module手动卸载。说到通信，我们能想到的方案有两种，路由和。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值