文章目录

• • • • 首语
      • 简介
      • 特点
      • 组件化编程
      • • 组件化Application
        • 组件间通信
        • • 第三方总线框架
          • 对比
          • 总结
        • 组件间跳转
        • • ARouter路由跳转
        • 组件化存储
        • 组件化权限管理
        • • 动态权限框架
        • 组件化资源冲突
        • • AndroidMainfest冲突
          • 包冲突
          • 资源名冲突
        • 组件化混淆
        • 组件化多渠道
      • Gradle优化
      • • 调试优化
      • 总结

首语

时间似流水，已经是2021年的三月了，抖擞精神。新的一年继续努力奋斗。

简介

在项目开发中，将公用的代码提取到common_module中，将某些单独功能封装到lib_module中，再根据业务划分module，团队成员分别开发各自的模块。
但随着项目的迭代，功能越来越多，增加了一些业务模块后，相互调用的情况会增多，就会发生各个业务模块之间的耦合非常严重，导致代码难以维护且扩展性很差。组件化就应用而生了。
组件化基础：多module划分业务和基础功能。
组件：单一的功能组件，如适配，支付，路由组件等，可单独抽出来形成SDK。
模块：独立的业务模块，如直播，首页模块等。模块可能包含多个不同组件。

特点

1. 避免重复造轮子，节省开发，维护成本。
2. 通过组件和模块合理的安排人力，提高开发效率。
3. 不同项目公用一个组件或模块，保证技术方案的统一性。
4. 未来插件化公用一套底层模型做准备。

组件化编程

组件化Application

如果功能module有Application，主module没有自定义Application，自然引用功能module的Application。
如果功能module有两个自定义Application，会编译出错，需要解决冲突。可以使用tools:replace="android:name"解决，因为App编译最终只会允许声明一个Application。

组件间通信

组件中的模块是相互独立的，并不存在依赖，没有依赖无法传递信息。这时，需要借助基础层（CommonModule），组件层的模块都依赖于CommonModule，它是模块间信息交流的基础。
Android中Activity，Fragment及Service信息传递较复杂，通过广播的形式实现消息传递耗时且不安全，产生了事件总线机制。它是对发布-订阅模式的一种实现。它是一种集中式事件处理机制，允许不同的组件之间进行彼此通信而又不需要相互依赖，达到一种解耦的目的。

第三方总线框架

• EventBus
  EventBus是一个Android端优化的publish/subscribe消息总线，简化了应用程序内各组件间、组件与后台线程间的通信。具体使用方法可参考我的博客：Android事件总线之EventBus。
• RxBus
  RxBus是基于RxJava响应式编程衍生而来的一种组件间通信的模式，目前项目开发网络请求都是使用Retofit+RxJava框架搭配实现的，具体使用方法可参考我的博客：Android RxJava的使用；Retrofit。

对比

在线程调度方面，RxJava的线程调度更加优秀，且通过多种操作符，链式编写代码，是优于Eventbus的，但因为没有使用反射机制，运行效率低于EventBus。

总结

在实际项目开发中，通信事件要放在CommonModule中，CommonModule也需要依赖总线框架。但是不同模块增删时都需要添加或删除消息模型，让事件总线整个架构显得非常臃肿且复杂，违背了组件化的原则。解决方案是抽离出一个事件总线模块，CommonModule依赖这个模块，消息模型都在事件总线模块中。

组件间跳转

在组件化中，两个功能模块不存在直接依赖的，通过CommonModule间接依赖。一般一个Activity跳转到另外一个Activity中，使用startActivity发送一个intent，但是引用不了其它模块的Activity。可通过隐式Action方式实现跳转。需要注意的是移除模块时同时也要移除跳转，否则会发生崩溃。

ARouter路由跳转

隐式Action并不是最好的跳转方式，ARouter此时就出现了。
ARouter是阿里巴巴Android技术团队开源的一款用于帮助 Android App 进行组件化改造的路由框架，支持模块间的路由、通信、解耦。
Github地址：https://github.com/alibaba/ARouter

• 使用
  首先在CommonModule中添加依赖：

    implementation 'com.alibaba:arouter-api:x.x.x'
    annotationProcessor 'com.alibaba:arouter-compiler:x.x.x'

然后annotationProcessor会使用javaCompileOptions 这个配置来获取当前module的名字，在各个模块的build.gradle的defaultConfig属性中加入：

android {
    defaultConfig {
        ...
        javaCompileOptions {
            annotationProcessorOptions {
                arguments = [AROUTER_MODULE_NAME: project.getName()]
            }
        }
    }
}

每个模块的dependencies属性需要ARouter apt的引用，不然无法在apt中生成索引文件，不能跳转成功。

dependencies {
    annotationProcessor 'com.alibaba:arouter-compiler:x.x.x'
}

在Application中初始化：

if (isDebug()) {           
    ARouter.openLog();   
    ARouter.openDebug();   
}
ARouter.init(mApplication); 

以Activity跳转为例，首先需要在跳转Activity添加注解Route，path是路径

@Route(path = RouterPath.LOGIN_PAGE)
public class LoginActivity extends BaseActivity<activityloginBinding> {}
//路由跳转尽量统一管理，可以module路径命名。
  String SURROUNDING_PAGE = "/surrounding/ui";
  String TRAVEL_PAGE = "/travel/ui";
  String CITY_SERVICE_PAGE = "/city_service/ui";

需要跳转Activity时，使用如下，build参数为跳转Activity路径。

ARouter.getInstance().build(RouterPath.LOGIN_PAGE).navigation();

具体使用参考官方中文说明文档：https://github.com/alibaba/ARouter/blob/master/README_CN.md

组件化存储

Android原生存储方式有五种，在组件化中也完全通用。
组件化中流行的数据库有Jetpack套件中的Room。它通过注解的形式完成数据库的创建、增删改查等操作。使用简单、高效。
组件化设计中考虑到解耦，将数据库层独立为一个模块，关于数据库的操作都在此module中，且依赖于CommonModule。

组件化权限管理

在各个module的AndroidManifest.xml中，我们可以看到各个module的权限申请，最终会合并到根AndroidManifest.xml文件中。
在组件化开发中，我们将normal级别的权限放在CommonModule中，在每个module中分别申请dangerous级别的权限，这样的好处是当添加或移除某个模块时移除dangerous级别权限，做到最大程度的解耦。

动态权限框架

RxPermission是基于RxJava的Android动态权限申请框架。
Github地址：https://github.com/tjianssbruyelle/RxPermissions。

    public void initPermissions(String[] permissions, PermissionResult permissionResult) {
        if (rxPermissions == null) {
            rxPermissions = new RxPermissions(this);
        }
        rxPermissions.requestEachCombined(permissions)
                .subscribe(permission -> {
                    if (permission.granted) {
                        permissionResult.onSuccess();
                    } else if (permission.shouldShowRequestPermissionRationale) {
                        permissionResult.onFailure();
                    } else {
                        permissionResult.onFailureWithNeverAsk();
                    }
                });
    }

RxPermission与RxJava结合，非常精简，简单实用。

组件化资源冲突

AndroidMainfest冲突

AndroidMainfest中引用了Application的app:name属性，冲突时使用tools:replace="android:name"来声明Application是可被替换的。

包冲突

当包冲突出现时，使用gradle dependencies命令查看依赖目录树，依赖标注了*号的，表示依赖被忽略。因为有其它顶级依赖也依赖于这个依赖，可以使用exclude排除依赖，例如：

 androidTestImplementation 'com.android.support.test.espresso:espresso-core:3.0.2', {
        exclude group: 'com.android.support', module: 'support-annotations'
    }

资源名冲突

在多module开发中，无法保证多个module中全部资源的命名不同，出现相同资源名选取的规则是后编译的模块会覆盖之前编译的模块的资源字段中的内容，出现相同会造成资源引用错误的问题。解决办法有两种：
第一种：资源出现冲突时进行重命名。
第二种：gradle的命名提示机制，使用resourcePrefix字段：

android {
	resourcePrefix "组件名_"
}

所有的资源命必须以指定的字符串作为前缀，否则会报错，但是resourcePrefix不能限定图片资源，图片资源的还需要手动去修改资源名。

组件化混淆

Android Studio使用ProGuard进行混淆，它是一个压缩、优化和混淆Java字节码文件的工具，可以删除无用的类和注释，最大程度优化字节码文件。
混淆会删除项目无用的资源，有效减少apk安装包的大小。
混淆增加了逆向工程的难度，更加安全。
混淆有Shrinking(压缩)、Optimization(优化)、Obfuscation(混淆)、Preverification(预校验)四项操作。

  buildTypes {
        release {
        //是否打卡混淆
            minifyEnabled false
            //是否打开资源压缩
            shrinkResources true
            设置proguard的规则路径
            proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
        }
    }

每个module在创建之后，都会自带一个proguard-rules.pro的自定义混淆文件，每个module可以有自己的混淆规则。
组件化中，如果每个module都使用自身混淆，会出现重复混淆的现象，造成查询不到资源文件的问题。我们需要保证apk生成时候只需要一次混淆。
方案：将固定的第三方库混淆放到CommonModule中，每个module独有的引用库混淆放在各自的的proguard-rules.pro中，最后在App 的proguard-rules.pro中放入Android基础属性混淆声明，例如四大组件和全局混淆等配置。可以最大限度的完成混淆解耦工作。

组件化多渠道

当项目开发中需要生成用户端和管理端，又或者某些版本不需要支付、分享等，我们没必要嵌入这些模块，同时可以减少业务量和包容量。
我们需要输出多个App时，维护和开发成本会提升，如何降低开发成本，并且合理解耦呢，就需要使用到多渠道了。例如：

productFlavors {
        phone {
            applicationId "com.zdww.enjoyluoyang"
            manifestPlaceholders = [name:"用户端",icon:"@mipmap/logo"]
        }
        terminal {
            applicationId "com.zdww.enjoyluoyang_terminal"
            versionCode 2
            versionName "1.1.0"
            manifestPlaceholders = [name:"管理端",icon:"@mipmap/logo"]
        }
    }
     phoneImplementation project(path: ":module_my")

我们通过productFlavors设置多渠道，manifestPlaceholders设置不同渠道的不同属性，这些属性在AndroidMainfest中声明才能使用，设置xxxImplementation可以配置不同渠道需要引用的module。在Android Studio中左侧边栏可以找到Build Variants选择不同的Active Build Variant。
对于不同渠道需要引入新的类或文件，可在项目目录下新建不同渠道文件夹，将文件放入其中，各为其用。

Gradle优化

Gradle本质是一个自动化构建工具，基于Groovy的特定领域语言(DSL)来声明项目设置，Android Studio构建工程时，利用gradle编写的插件来加载工程配置和编译文件。
组件化中，每个module都有一个build.gradle文件，每个module的build.gradle文件都拥有一些必需的属性，同一个Android工程，在不同模块要求这些属性一致，例如compileSdkVersion等，如果引用不一致，属性不会被合并并引入到工程中，会造成资源的重复，降低编译效率。
必须有一个统一、基础的Gradle配置，创建一个version.gradle文件，编写一些变量，在project的build.gradle下buildscript添加

apply from :"versions.gradle"

类似引用静态变量的方式来引用属性，也可以将项目使用的仓库在version.gradle中统一配置。只需在project.gradle中添加即可。

ext.deps = [:]

def versions = [:]
versions.gradle = "4.0.1"
versions.appcompat = "1.2.0"
versions.constraintlayout = "2.0.4"
versions.junit = "4.12"
versions.ext_junit = "1.1.2"
versions.espresso_core = "3.3.0"
versions.multidex = "1.0.3"
def build_versions = [:]

build_versions.compileSdk = 29
build_versions.minSdk = 19
build_versions.targetSdk = 29
build_versions.versionCode = 11
build_versions.versionName = "1.4.5"
build_versions.application_id = "com.example.yhj"
build_versions.gradle = "com.android.tools.build:gradle:$versions.gradle"
ext.build_versions = build_versions

def view = [:]
view.constraintlayout = "androidx.constraintlayout:constraintlayout:$versions.constraintlayout"
view.recyclerview = "androidx.recyclerview:recyclerview:$versions.recyclerview"
view.glide = "com.github.bumptech.glide:glide:$versions.glide"
view.glide_compiler = "com.github.bumptech.glide:compiler:$versions.glide_compiler"
view.circleimageview = "de.hdodenhof:circleimageview:$versions.circleimageview"
view.gif_drawable = "pl.droidsonroids.gif:android-gif-drawable:$versions.gif_drawable"
view.material = "com.google.android.material:material:$versions.material"
deps.view = view

def addRepos(RepositoryHandler handler) {
    handler.google()
    handler.jcenter()
    handler.flatDir { dirs project(':lib_common').file('libs') }
    handler.maven { url "https://jitpack.io" }
}

ext.addRepos = this.&addRepos

然后我们在module的build.gradle下只需这样使用即可。

android {
    compileSdkVersion build_versions.compileSdk

    defaultConfig {
        minSdkVersion build_versions.minSdk
        targetSdkVersion build_versions.targetSdk
        versionCode build_versions.versionCode
        versionName build_versions.versionName
        
	api deps.android.appcompat
    api deps.view.constraintlayout
    //glide
    api deps.view.glide
    annotationProcessor deps.view.glide_compiler

这样统一参数变量配置，使得项目不会引用到多个不同版本的Android工具库，且统一配置，避免增加apk容量。

调试优化

组件化支持将单一模块做成App启动，然后用于调试测试，保证了单独模块可以分离调试。
需要变更的地方：

apply plugin: 'com.android.library'——>apply plugin: 'com.android.application'

在src中建立debug文件夹，debug文件夹用于放置调试需要的AndroidMainfest.xml文件，java文件，res文件等，且需要设置默认启动的Activity。
我们可以设置一个isModule的变量来作为集成开发和组件开发模式的开关，在module的build.gradle中可以这样判断：

if (isModule.toBoolean()) {
    apply plugin: 'com.android.application'
} else {
    apply plugin: 'com.android.library'
}

同时集成开发模式下需要排除debug文件夹下的所有文件。

sourceSets {
        main {
            if (isModule.toBoolean()) {
                manifest.srcFile 'src/main/module/AndroidManifest.xml'
            } else {
                manifest.srcFile 'src/main/AndroidManifest.xml'
                //集成开发模式下排除debug文件夹中的所有文件
                java {
                        exclude 'debug/**'
                }
            }
        }
    }

原App的build.gradle需要移除已经单独调试的模块依赖。

dependencies {
    if (!isModule.toBoolean()) {
       implementation project(path: ':module_my')
    }
}

总结

Android项目中进行组件化实践可以提高复用性，降低耦合，本文主要对项目中组件化常用使用场景进行总结，更多相关场景在项目开发中再进行总结。

Android组件化架构学习笔记——组件化编程之静态变量/资源/混淆/多渠道打包

一.组件化的静态变量：

• R.java的生成：

各个module会生成aar文件，并且被引用到Application module中，最终合并为apk文件。当各个次级module在Application module中被解压后，在编译时资源R.java会被重新解压到build/generated/source/r/debug(release)/包名/R.java中。

当每个组件中的aar文件汇总到App module中时，也就是编译的初期解析资源阶段，其每个module的R.java释放的同时，会检测到全部的R.java文件，然后通过合并，最后合并成唯一的一份R.java资源。

• R2.java及ButterKnife:

ButterKnife是一个专注于Android View的注入框架，可以大量的减少findViewById和setonClickListener操作的第三方库。

注解中只能使用常量，如不是常量会提示attribute value must be contant的错误。可以在使用替代方法，原理是将R.java文件复制一份，命名为R2.java。然后给R2.java变量加上final修饰符，在相关的地方直接引用R2资源。

如项目中已经使用ButterKnife维护迭代了一段时间，那么使用R2.java的方案适配成本是最低的。

最好的解决方式还是使用findViewById，不使用注解生成的机制。

下面可以使用泛型来封装findViewById，以减少编写的代码量：

 @Override
    protected void onCreate(@androidx.annotation.Nullable Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);

        TextView textView = generateFindViewById(R.id.rl_full_view);
    }
    
    protected <T extends View> T generateFindViewById(int id) {
        //return 返回view时加上泛型T
        return (T)findViewById(id);
    }

二.资源冲突：

在组件化中，Base module和功能module的根本是Library module，编译时会依次通过依赖规则进行编译，最底层的Base module会被先编译成aar文件，然后上一层编译时因为通过compile依赖，也会将依赖的aar文件解压到模块的build中。

AndroidMainfest冲突问题：

AndroidMainfest中引用了application的app:name属性，当出现冲突时，需要使用tool:replace= "android:name"来声明application是可被替代的。某些AndroidMainfest.xml中的属性被替代的问题，可以使用tool:replace来解决冲突。

包冲突：

如想使用优先级低的依赖，可以使用exclude排除依赖的方式。

compile('') {
        exclude group:''
    }

资源名冲突：

在多个module开发中，无法保证多个module中全部资源的命名是不同的。假如出现相同的情况，就可能造成资源引用错误的问题。一般是后后编译的模块会覆盖之前编译的模块的资源字段中的内容。

解决方法：一种是当资源出现冲突时使用重命名的方式解决。这就要要求我们在一开始命名的时候，不同的模块间的资源命名都不一样，这是代码编写规范的约束；另一种时Gradle的命名提示机制，使用字段：

android {
    resourcePrefix "组件名_"
}

所有的资源名必须以指定的字符串作为前缀，否者会报错，resourcePrefix这个值只能限定xml中资源，并不能限定图片资源，所有图片资源仍然需要手动去修改资源名。

三.组件化混淆：

混淆基础：

混淆包括了代码压缩/代码混淆及资源压缩等优化过程。

Android Studio使用ProGuard进行混淆，ProGuard是一个压缩/优化和混淆Java字节码文件的工具，可以删除无用的类/字段/方法和属性，还可以删除无用的注释，最大限度地优化字节码文件。它还可以使用简短并无意义的名称来重命名已经存在的类/字段/方法和属性。

混淆的流程针对Android项目，将其主项目及依赖库未被使用的类/类成员/方法/属性移除，有助于规避64k方法的瓶颈；同时，将类/类成员/方法重命名为无意义的简短名称，增加了逆向工程的难度。

混淆会删除项目无用的资源，有效减少apk安装包的大小。

混淆有Shrinking(压缩)/Optimiztion(优化)/Obfuscation(混淆)/Preverfication(预校验)四项操作。

  buildTypes {
        release {
            minifyEnabled false     //是否打开混淆
            shrinkResources true    //是否打开资源混淆
            proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'     
            //用于设置proguard的规则历经
        }
    }

每个module在创建时就会创建出混淆文件proguard-rules.pro，里面基本是空的。

#指定压缩级别

-optimizationpasses 5

#不跳过非公共的库的类成员

-dontskipnonpubliclibraryclassmembers

#混淆时采用的算法

-optimization !code/simpliffcation/arithetic,!field/*,!class/merging/*

#把混淆类中的方法名也混淆了

-useuniqueclassmembernames

#优化时允许访问并修改修饰符的类和类成员

-allowaccessmodification

#将文件来源重命名为“SourceFile”字符串

-renamesourefileattribute SoureFile

#保留行号 

-keepattributes SoureFile,LineNumberTable

以下时打印出的关键的流程日志：

-dontpreverify

#混淆时是否记录日志

-verbose

#apk包内所有class的内部结构

-dump class_files.txt

#未混淆的类和成员

-printseeds seed.txt

#列出从apk中删除的代码

-printusage unused.txt

#混淆前后的映射

-printmapping mapping.txt

以下情形不能使用混淆：

• 反射中使用的元素，需要保证类名/方法名/属性名不变，否则混淆后会反射不了；
• 最好不让一些bean对象混淆；
• 四大组件不建议混淆，四大组件在AndroidManifest中注册申明，而混淆后类名会发生更改，这样不符合四大组件的注册机制；

-keep public class * extend android.app.Activity
-keep public class * extend android.app.Application
-keep public class * extend android.app.Service
-keep public class * extend android.app.content.broadcastReceiver
-keep public class * extend android.app.content.ContentProvider
-keep public class * extend android.app.backup.broadAgentHelper
-keep public class * extend android.app.preference.Preference
-keep public class * extend android.app.view.View
-keep public class * extend android.app.verding.licensing.ILicensingService

• 注解不能混淆，很多场景下注解被用于在运行时反射一些元素；

-keepattributes *Annotation

• 不能混淆枚举中的value和valueOf方法，因为这两个方法时静态添加到代码中运行，也会被反射使用，所以无法混淆这两种方法。应用使用枚举将添加很多方法，增加了包中的方法数，将增加dex的大小；

-keepclassmembers enum * {
    public static **[] values();
    public static ** vauleOf(java.lang.String);
}

• JNI调用Java方法，需要通过类名和方法名构成的地址形成；
• Java使用Native方法，Native是C/C++编写的，方法是无法一同混淆的；

-keepclasswithmembername class * {
    native <methods>;
}

• JS调用Java方法；

-keepattributes *JavascriptInterface*

• WebView中JavaScript调用方法不能混淆；

-keepclassmembers class fqcn.of.javascript.interface.for.Webview {
    public *;
}
-keepclassmembers class * extends android.webkit.WebViewClient {
    public void *(android.webkit.Web,java.lang.String,android.graphics.Bitmap);
    public boolean *(android.webkit.Web,java.lang.String);
}
-keepclassmembers class * extends android.webkit.WebViewClicent {
    public void *(android.webkit.Web,java.lang.String);
}

• 第三方库建议使用其自身混淆规则；
• Parcelable的子类和Creator的静态成员变量不能混淆，否则会出现android.os.Bad-ParcelableExeception;

-keep class * implement android.os.Parcelable {
    public static final android.os.Parcelable$Creator *;
}
-keepclassmembers class * implements java.io.Seriablizable {
    static final long seriablVersonUID;
    private static final java.io.ObjectStreamField[] seriablPersistentFields;
    private void writeObject(java.io.ObjectOutputStream);
    private void readOject(java.io.ObjectInputStream);
    java.lang.Object writeReplace();
    java.lang.Object readResolve();
}

• Gson的序列号和反序列化，其实质上是使用反射获取类解析的；

-keep class com.google.gson.** {*;}
-keep class sun.misc.Unsafe {*;}
-keep class com.google.gson.stream.** {*;}
-keep class com.google.gson.examples.android.modle.**{*;}
-keep class com.google.** {
    <fields>;
    <methods>;
}
-dontwarn com.google.gson.**

• 使用keep注解的方式，哪里不想混淆就“keep”哪里，先建立注解类；

package com.demo.annotation;
//@Target(ElementType.METHOD)
public @interface Keep {

}

@Target可以控制其可用范围为类/方法变量。人后在proguard-rules.pro声明；

-dontskipnonpubliclibrayclassmember
-printconfiguration
-keep,allowobfusation @interfaces android.support.annotation.Keep
-keep @andriod.support.annotation.Keep class *
-keepclassmen=mbers class * {
    @android.support.annotation.Keep *;
}

只要记住一个混淆原则：混淆改变Java路径名，那么保持所在路径不被混淆就是至关重要的。

资源混淆：

ProGuard是Java混淆工具，而它只能混淆Java文件，事实上还可以继续深入混淆，可以混淆资源文件路径。

资源混淆，其实也是资源名的混淆。可以采取的方式有三种：

• 源码级别上的修改，将代码和XML中的R.string.xxx替换为R.string.a，并将一些图片资源xxx.png重命名为a.png，然后再交给Android进行编译；
• 所有的资源ID都编译为32位int值，可以看到R.java文件保存了资源数值，直接修改为resources.arsc的二进制数据，不改变打包流程，在生成resources.arsc之后修改它，同时重命名资源文件；
• 直接处理安装包，解压后直接修改resources.arsc文件，修改后重新打包。

微信的AndResGuard的资源混淆机制。

组件化混淆：

每个module在创建之后，都会自带一个proguard-rule.pro的自定义混淆文件。每个module也可以有自己混淆的规则。

但在组件化中，如果每个module都是用自身的混淆，则会出现重复混淆的现象，造成查询不到资源文件的问题。

解决这个问题是，需要保证apk生成的时候有且只有一次混淆。

• 第一种方案是：最简单也是最直观的，只在Application module中设置混淆，其他module都关闭混淆。那么混淆的规则就都会放到Application module的proguard-rule.pro文件中。这种混淆方式的缺点是，当某些模块移除后，混淆规则需要手动移除。虽然理论上混淆添加多了不会造成奔溃或者编译不通过，但是不需要的混淆过滤还是会对编译效率造成影响；
• 第二种方案是：当Application module混淆时，启动一个命令将引用的多个module的proguard-rule.pro文件合成，然后再覆盖Application module中的混淆文件。这种方式可以把混淆条件解耦到每个module中，但是需要编写Gradle命令来配置操作，每次生成都会添加合成操作，也会对编译效率造成影响；
• 第三种方案是：Library module自身拥有将proguard-rule.pro文件打包到aar中的设置。 开源库中可以依赖consumerProguardFiles标志来指定库的混淆方式，consumerProguardFiles属性会将*.pro文件打包进aar中，库混淆时会自动使用此混淆配置文件。

当Application module将全部打代码汇总混淆的时候，Library module会打包为release.aar，然后被引用汇总，通过proguard.txt规则各自混淆，保证只混淆一次。

这里将固定的第三方混淆放到Base module proguard-rule.pro中，每个module独有的引用库混淆放到各自的proguard-rule.pro中。最后再App module的proguard-rule.pro文件中放入Android基础属性混淆声明。

四.多渠道打包：

将开发工具看作生产工厂，让代码和资源作为原料，利用最少的代码消耗去构建不同渠道，不同版本的产品。

多渠道基础：

当需要统计哪个渠道用户多变，哪个渠道用户粘性强，哪个渠道又需要更加个性化的设计时，通过Android系统的方法可以获取到应用版本号/版本名称/系统版本/机型等各种信息，唯独应用商店（渠道）的信息时没办法从系统获取到的，我们只能认为在apk中添加渠道信息。

多渠道打包中我们需要关注有两件事情：

• 将渠道信息写入apk文件；
• 将apk中的渠道信息传输到后台。

打包必须经过签名这个步骤，而Android的签名有两种不同的方法：

• Android7.0以前，使用v1签名方式，是jar signature，源于JDK;
• Android7.0以后，引入v2签名方式，是Android独有的apk signature,只对Android7.0以上有效，Android7.0以下无效。

 signingConfigs{
        release{
            v2SigningEnabled false
        }
    }

apk本省是zip格式文件，v2签名与普通zip格式打包的不同在于普通的zip文件有三个区块，而v2签名的apk拥有四个区块，多出来的区块用于v2签名验证。如其他三个区块被修改了，都逃不过v2验证，直接导致验证失败，所以这是v2签名比v1更加安全的原因。

批量打包：

使用原生的Gradle进行打包，工程大，打多渠道包将非常耗时，如打包过程中发现错误需要继续修复问题，那么速度将增倍。因此，批量打包技术就开始流行。

1.使用Python打包：

• 下载安装Python环境，推荐使用AndroidMultiChanneBuildTool。这个工具只支持v1签名，将ChannelUtil.Java代码即成到工程中，在app启动时获取渠道号并传送给后台（AnalyticsConfig.setChannel(ChannelUtil.getChannel(this))）；
• 把生成好的apk包（项目/build/outputs/release.apk）放到PythonTool文件夹中；
• 在PythonTool/info/channel.txt中编辑渠道列表，以换行隔开；
• PythonTool目录下有一个AndroidMultiChannelBuildTool.py文件，双击运行该文件，就会开始打包。完成后在PythonTool目录下会心出现一个output_app-release文件夹，里面就是打包的渠道包了。

2.使用官方提供的方式实现多渠道打包：

• 在AndroidManifest.xml中加入渠道区分标识，写入一个Meta标签；

<Meta-data android:name="channel" android:value="${channel}"/>

• 在app目录的build.gradle中配置productFlavors:

   productFlavors {
        qihu360{}
        yingyongbao{}

        productFlavors.all {
            flavor -> flavor.manifestPlaceholders = [channel : name]
        }
    }

• 在Android Studio Build ->Generate signed apk中选择设置渠道。

这样就可以打包不同渠道的包了，在Android Studio左下角Build Variants之后，还可以选择编译debug版本和release版本，一次打出全部的包，只需使用Gradle命令：       ./gradlew build

3.在apk文件后添加zip Comment

apk文件本质上是一个带签名信息zip文件，符合zip文件的格式规范。签过名的apk文件拥有四个区块，签名区块的末尾就是zip文件注释，包含Comment Length和File Comment两个字段，前者表示注释长度，后者表示注释内容，正确修改这两个内容不会对zip文件造成破坏。利用这个字段可以添加渠道信息的数据，推荐使用packer-ng-pugin进行打包。

4.兼容v2签名的美团批量打包工具walle

以上四种打包在速度和兼容性上，zip comment和美团的walle的打包方式，无须重新编译，只做解压/添加渠道信息在打包的操作并且能兼容v1和v2签名打包。兼容最好的是原生的Gradle打包。

多渠道模块配置：

当需要多渠道或者多场景定制一些需求时，就必须使用原生Gradle来构建app了。

以下是演示例子：

productFlavors {
        //用户版本
        client {
            manifestPlacehoders = [
                channel:"10086",     //渠道号
                verNum:"1",          //版本号
                app_name:"Gank"      //app名
            ]
        }

        //服务版本
        server {
            manifestPlacehoders = [
                    channel:"10087",     //渠道号
                    verNum:"1",          //版本号
                    app_name:"Gank服务版"      //app名
            ]
        }
       
    }

dependencies {
    
    clientCompile project(':settings')  //引入客户版特定module
    clientCompile project(':submit') 
    clientCompile project(':server_settings')  //引入服务版特定module

}

这里通过productFlavors属性来设置多渠道，而manifestPlaceholders设置不同渠道中的不同属性，这些属性需要在AndroidMainfest中声明才能使用。设置xxxCompile来配置不同渠道需要引用的module文件。

接下来在app module的AndroidMainfest.xml中声明：

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools"
    package="com.example.demo1">

    <application
        android:name=".basemodule.BaseApplication"
        android:allowBackup="true"
        android:extractNativeLibs="true"
        <!--app名引用-->
        android:label="${app_name}"
        tools:replace="label"
        android:supportsRtl="true"/>
    <!--版本号声明-->
    <Meta-data android:name="verNum" android:value="${verNum}"/>
    <!--渠道名声明-->
    <Meta-data android:name="channel" android:value="${channel}"/>
</manifest>

android：label属性用于更改签名，${xxx}会自动引用manifestPlaceholders对应的key值。最后替换属性名需要添加tool:replace属性，提示编译器需要替换的属性。

声明Meta-data用于某些额外自定义的属性，这些属性都可以通过代码读取包信息来获取：

public class AppMetaUtils {
    public static int channelNum = 0;

    /**
     * 获取Meta-data值
     * @param context
     * @param MetaName
     * @return
     */
    public static Object getMetaData(Context context,String MetaName) {
        Object obj = null;
        try {
            if (context != null) {
                String pkgName = context.getPackageName();
                ApplicationInfo applicationInfo = context.getPackageManager().getApplicationInfo(pkgName
                        , PackageManager.GET_Meta_DATA);
            }
        }catch (Exception e){
            Log.e("AppMetaUtils",e.toString());
        }finally {
            return obj;
        }
    }

    /**
     * 获取渠道号
     * @param context
     * @return
     */
    public static int getChannelNum(Context context) {
        if (channelNum <= 0) {
            Object object = AppMetaUtils.getMetaData(context,"channel");
            if (object != null && object instanceof Integer){
                return (int)object;
            }
        }
        return channelNum;
    }
    
    
}

使用getApplicationInfo方法来获取应用信息，然后读取Meta-data中不同的key值来进一步获取渠道号。

 /**
     * 跳转到设置页面
     */
    public void navigationSettings() {
        String path = "/gank_setting";
        if (channel == 10086) {
            path +="/1";
        }else if (channel == 10087){
            path += "_server/1";
        }
        ARouter.getInstance().build(path).navigation();
    }

以上是值调用的实例。如需要使用某个类调用，则可以直接将路径以值的形式来传递，然后使用反射的方式就能完成对象的创建：

productFlavors {
        //用户版本
        client {
            manifestPlacehoders = [
                channel:"10086",     //渠道号
                verNum:"1",          //版本号
                app_name:"Gank"      //app名
                setting_info:"material.com.setting.SettingInfo"//设置数据文件
            ]
        }

        //服务版本
        server {
            if(!project.ext.isLib) {
                application project.ext.applicationId + '.server' //appId
            }
            manifestPlacehoders = [
                    channel:"10087",     //渠道号
                    verNum:"1",          //版本号
                    app_name:"Gank服务版"      //app名
                    setting_info:"material.com.server_setting.ServerSettingInfo"//设置数据文件
            
            ]
        }
       
    }

声明一个用于传递类名的Meta-data:

    <Meta-data android:name="setting_info" android:value="${setting_info}"/>

通过之前封装好的getMetaData获取需要调用的类：

 /**
     * 获取设置信息路径
     * @param context
     * @return
     */
    public static String getSettingInfo(Context context) {
        if (settingInfo == null){
            Object object = AppMetaUtils.getMetaData(context,"setting_info");
            if (object != null && object instanceof Integer) {
                return (String)object;
            }
        }
        return settingInfo;
    }

然后还需要一个公共的方法调用，可以使用接口的形式，在Base module中声明一个接口，在功能module中扩展使用。

public interface SettingImp {
        void setData(String data);
    }

在client和server中各自继承这个接口实现方法：

public class SettingInfo implements SettingImp{

        @Override
        public void setData(String data) {
            //进行数据处理
        }
    }

public class ServerSettingInfo implements SettingImp {

        @Override
        public void setData(String data) {
            //进行数据处理
        }
    }

接下来就可以在Base module中再次封装并获取调用方法：

  public static void SettingData(Context context,String data) {
        if (getSettingInfo(context) != null){
            Log.e("AppMetaUtils","setting_info is no found");
        }
        
        try{
            Class<?> clazz = Class.forName(getSettingInfo(context));
            SettingImp imp = (SettingImp)clazz.newInstance();
            imp.setData(data);
        }catch (ClassNotFoundException e) {
            Log.e("AppMetaUtils","getSettingInfo error:"+e.toString());
        }catch (InstantiationException e) {
            Log.e("AppMetaUtils","getSettingInfo error:"+e.toString());
        } catch (illegalaccessexception e) {
            Log.e("AppMetaUtils","getSettingInfo error:"+e.toString());
        }
    }

利用反射的方式来初始化接口，把接口做成共性调用的方式。更深层次的运用需要在实际的需求中调整。

今天关于大型 Web 应用插件化架构探索和web插件化开发的讲解已经结束，谢谢您的阅读，如果想了解更多关于Android 组件化架构概要、Android 组件化架构资料、Android组件化架构、Android组件化架构学习笔记——组件化编程之静态变量/资源/混淆/多渠道打包的相关知识，请在本站搜索。