实际开发的存储过程_实际生产中的 Android SDK开发总结| 完结

本文作者

作者：brucevanfdm

链接：

https://zhuanlan.zhihu.com/p/163899902

本文由作者授权发布。

上一篇我们介绍了 SDK 开发的：

开篇与设计
Exception or ErrorCode
初始化
个性化配置

如果没有看过，建议先看完上篇：

实际生产中的 Android SDK开发总结

本篇将介绍：

安全与校验
压缩与优化
依赖原则与打包方法

1安全与校验

一、前言

本章介绍SDK开发中安全方面的知识，包括资源完整性、存储安全、权限校验、传输安全、代码混淆等知识。

通过基础的安全配置为SDK保驾护航，探索SDK开发在安全方面的最佳实践。

防杠说明：本人认同前端没有绝对的安全，基本我们公开谈论的大部分安全策略都可以绕过，但这不能成为我们忽视安全的理由。

二、安全概览

3.1、完整性检查

SDK资源完整性检查，是指在SDK开发中，对于AAR包的完整性做一些检查。实际上，对于资源的完整性、有效性检查，通常是核对其文件的摘要。SDK包也是如此，可以在发布AAR时同时发布该文件的摘要，用于核对校验。

这里也介绍简单一下另一个思路，即从SDK代码中检测资源的方法。众所周知，AAR在编译的时候是完全被合并APK中了，校验AAR摘要的思路可以说就这样断了。

但是我们可以通过校验AAR中的资源，如raw、assets目录下的文件。由于这两个目录下的文件在编译时不会被压缩，因此编译前后文件内容不会改变，其摘要也不会变，适合用来在资源校验。

至于摘要检验方案，可以简单在Java层面做，也可以在so里做，校验的时机与策略就更多选择了，这里就不展开讲了。

3.2、警惕资源覆盖造成的安全问题

Android Studio 会将Library模块中的资源与Application模块的资源合并。App Module的资源将会覆盖Library Module中的同名资源。正因为有此特性，我们不得不对SDK的资源进行保护，避免由于一些意外因素导致资源覆盖，从而引起与预期不一致的软件行为。

我们提到的资源主要包括常见res、assets目录下所有的文件、在对文件或资源进行命名时，务必添加唯一性的前缀或其他唯一性的命名方案。

凡事都有两面性，这一特性也为我们替换SDK资源，进行个性化改造提供了一种思路。

四、存储安全

在安全存储这方面，主要还是考验开发者的意识，看到这里的朋友不妨回头检查下手头的陈旧代码，说不定就有敏感信息明文存储，直接裸奔的问题。

4.1、SP安全存储

SharedPreferences采用xml文件格式来保存数据, 该文件所在目录位于/data/data//shared_prefs/，如果直接将账号密码或个人敏感信息存储进去，手机root后就可以轻松获取。因此，存储时尽量考虑简单做一层加密逻辑。无论是SharedPreferences还是数据库，都要避免明文敏感数据存储。

另外，SharedPreferences存储一些配置信息时也要配置好访问权限，如私有的访问权限 MODE_PRIVATE，避免配置信息被篡改。

4.2、SO安全存储

由于Java是解释性语言，而Java的混淆是没法混淆常量的。但是我们又不可避免地在前端存储一些密钥对，那么怎么存储才比较安全呢？建议往SO里存，不仅需要把密钥存储于SO，还需要把加解密逻辑甚至传输逻辑放置于SO，才能较好地保护代码逻辑。

之前也简单写了一篇文章，有兴趣可以参考下JNI初探之敏感信息保护

https://zhuanlan.zhihu.com/p/34902225

五、传输安全

5.1、网络安全配置

该特性让应用可以在一个安全的声明性配置文件中灵活的自定义其Https网络安全设置，而无需修改应用代码，满足更高的安全性要求。

在AndroidManifest.xml中配置networkSecurityConfig：

<?xml  version="1.0" encoding="utf-8"?>

network_security_config文件如下：

<?xml  version="1.0" encoding="utf-8"?>

以 PEM 或 DER 格式将自签署或非公共 CA 证书添加到 res/raw/my_ca。回想起年前听到渗透测试结果时的恐惧，好家伙，自己装了个证书...不过Android7.0以上已经默认不信任用户手动安装的证书了。

这部分更多细节、功能可以参考官方文档网络安全配置

https://developer.android.com/training/articles/security-config.html?hl=zh-cn

五、混淆与配置

5.1、手动集成

一般我们对接第三方SDK时，都会有一个混淆配置。同理，我们在发布SDK时也可以参考这类设计，提供SDK中不需要混淆的代码配置，在对接文档中集成即可。

5.2、SDK内置

为了提高接入体验，能否将SDK中的混淆配置也打包进aar中，让项目自动配置SDK的混淆文件呢？答案是肯定的，我们可以指定consumerProguardFiles属性，自定义引入的混淆规则，即可将*.pro文件打包进入aar中，项目打包时就会自动合并该配置文件。值得一提的是该属性只镇对library有效，对app无效。

consumerProguardFiles配置如下：

android {

5.3、混淆的那些坑

以上配置看似简单，但却潜在一些坑，在最新的4.x的Android Studio中我们新建一个library module，会自动创建出两个***rules.pro文件，其中consumer-rules.pro，自动被defaultConfig下的consumerProguardFiles所引用；proguard-rules.pro，自动被buildType下的proguardFiles引用。

1、defaultConfig 下的consumerProguardFiles 配置的*.pro文件将会在library module打包成aar时，以proguard.txt的形式存在，将参与到集成这个arr的App编译中，但不参与这个library module打包成aar的编译过程；

2、buildType下proguardFiles配置的*.pro文件作用与library module打包成aar的编译过程，仅作用于本module的编译混淆过程。

在实际操作中，直接将consumerProguardFiles配置的*.pro文件改为proguard-rules.pro，这样就能粗暴地解决掉aar编译时的混淆与apk编译时的混淆了。

但是需要特别注意的是，根据我们SDK开发设计中的最小可用性原则，应该谨慎添加混淆规则，如无必要，勿增规则，避免对集成该aar项目的正常混淆造成干扰。

六、小结

安全是一种意识，难的不是安全，是没有意识。正如开篇提到的前端没有绝对的安全，但是安全也不能仅依靠前端，它应该是多端协同下的多层级、系统级的安全。对于开发者来说，应该有所作为，毕竟多一道防线就多一点安全。一个开发者应该拥有基础的安全意识，才能尽量避免安全事故。

2压缩与优化

一、前言

本章介绍SDK开发中关于SDK包体积优化相关的知识。包括APK与AAR组成分析、SDK包大小与集成增量的概念以及SDK开发中的资源压缩与优化思路。

包体积的控制是一个极其繁琐的系统工程，有非常多的方案可以实践，关键在于投入产出比。本文未曾想罗列网文中的所有优化方案，而是希望通过介绍简单可行的配置来压缩、优化SDK。更希望这是一个思维上的启发，唤醒一颗持续优化的心，以及在SDK开发中对于压缩与优化实践的特点。认识SDK组成，探索SDK开发在包体积压缩、控制集成增量上的最佳实践。

二、apk与aar组成分析

2.1、APK文件组成

APK 文件由一个 Zip 压缩文件组成，包含了构成应用的所有文件。包括 Java 类文件、资源文件和包含已编译资源的文件。

APK 包含如下目录：

META-INF/：包含 CERT.SF 和 CERT.RSA 签名文件，以及 MANIFEST.MF 清单文件。
assets/：包含应用的资源；应用可以使用 AssetManager 对象检索这些资源。
res/：包含未编译到 resources.arsc 中的资源。
lib/：包含特定于处理器软件层的已编译代码。此目录包含每种平台类型的子目录，如 armeabi、armeabi-v7a、arm64-v8a、x86、x86_64 和 mips。

APK 还包含以下文件。在这些文件中，只有 AndroidManifest.xml 是必需的。

resources.arsc：包含已编译的资源。此文件包含 res/values/ 文件夹的所有配置中的 XML 内容。打包工具会提取此 XML 内容，将其编译为二进制文件形式，并压缩内容。此内容包括语言字符串和样式，以及未直接包含在 resources.arsc 文件中的内容(例如布局文件和图片)的路径。
classes.dex：包含以 Dalvik/ART 虚拟机可理解的 DEX 文件格式编译的类。
AndroidManifest.xml：包含核心 Android 清单文件。此文件列出了应用的名称、版本、访问权限和引用的库文件。该文件使用 Android 的二进制 XML 格式。

2.2、AAR文件组成

AAR 文件的文件扩展名为 .aar，此文件本身也是一个 zip 文件，其中必须包含以下文件/目录：

/AndroidManifest.xml
/classes.jar
/res/
/R.txt

此外，AAR 文件可能包含以下一个或多个可选文件/目录：

/assets/
/libs/name.jar
/jni/abi_name/name.so(其中 abi_name 是 Android 支持的ABI之一)
/proguard.txt
/lint.jar
/api.jar
/public.txt(官方文档将其定义为必须包含，实测是可以不包含的)

三、SDK包大小与集成增量

首先我们要区分一下这两个概念：

SDK包大小：是指SDK包如AAR文件的大小，所占体积；
SDK集成增量：是指APK集成AAR后的增量，也就是集成前后的APK体积差值。

这里可以明确的是：集成AAR后的APK体积

而增量具体多少，跟主工程的实际资源或者依赖配置有关。而另一种可能，某些AAR只能支持一种ABI，集成时为了适配而修改了配置，最终反而使得整个APK的体积变小。

因此，为了科普这一概念，不妨在SDK文档或产品说明中备注SDK包大小以及预估的集成增量。对于APK大小敏感的用户就可以有一些心理准备。

四、SDK开发中的资源压缩与优化思路

正如前言所说，本文无意罗列网文提及的所有压缩优化方案，更多笔墨在于SDK开发场景下的简单可行有效果的优化思路，以及针对SDK进行配置时潜在的那些坑。

4.1、常规编译配置

资源优化与压缩的常规做法就是开启压缩、混淆和优化功能。区别于app模块，library模块不能开启shrinkResources的，这个编译器会有提示：Resource shrinker cannot be used for libraries.

android {        buildTypes {            //注意，以下配置仅对项目的release版本生效，需注意调试时配置区别造成的版本差异问题            release {                // 开启代码压缩，混淆和优化。                minifyEnabled true                // 开启资源缩减，需要注意的是，library模块不能开启这一选项。                shrinkResources true                //默认加载的ProGuard规则文件，可以在这里加入自定义文件，或在proguard-rules.pro中配置排除的规则                proguardFiles getDefaultProguardFile(                        'proguard-android-optimize.txt'),                        'proguard-rules.pro'            }        }        ...    }

4.2、资源压缩与原生类库配置

4.2.1、资源文件压缩

资源文件指的是类似于：图片、音频、视频等多媒体资源，这些资源都可以进行一定程度的压缩优化。并且，如果你的项目未曾做过类似优化，简单处理即可出效果。

针对图片、音频、视频的压缩、替换网络上都有非常多的成熟方案，这里就不再一一提及了。

4.2.2、精简原生类库

按需配置jniLibs下保留的ABI目录，如：armeabi-v7a、arm64-v8a

defaultConfig {        ...        ndk {            abiFilters 'armeabi-v7a','arm64-v8a' //指定支持的ABIs        }        ...    }

在SDK的开发与集成中，如果你的代码包含SO库，那么这个配置非常重要。由于不同的组件可能有不同的jniLibs目录，如果不加以限制，那么打包时就会将不完整的目录打包进去，导致App崩溃。

举个例子：

原App工程中只支持armeabi-v7a(由于目录删的够干净，gradle不配置也没问题)，此时若新增集成了一个包含armeabi-v7a,arm64-v8a两种ABI的AAR，却并没有在gradle配置中限定需要支持的ABIs，那打出来的APK就会存在两份SO文件，但只有armeabi-v7a文件夹下的SO是齐全的。

这个APK在被支持arm64-v8a的手机加载时，就会默认去检索arm64-v8a目录下的SO，因为找不到原App相关的SO模块，程序就崩溃了。

五、小结

本章简单介绍了SDK的文件组成、体积控制、优化方面的知识，以及在SDK开发与集成时需要注意的压缩优化配置，希望唤起开发者对于SDK包体积与集成增量的感性认知与优化意识，为探索如何开发一个优秀的SDK提供一些思路。项目优化来源于外部需求，更来源于开发者自身的认知与意识。

3依赖原则与打包方法

一、基本配置

1.1、Module配置

创建一个library module这个很简单，Android Studio直接new一个Project后，再new一个Android Library就可以了。

app module用于模拟调试；library module 用于编写SDK代码，生成jar/aar。

模板配置非全部由Android Studio自动生成，加入了一些通用的基础的SDK开发相关配置作为参考。要点如下：

gradle下自定义获取当前时间的方法；
自定义混淆规则consumerProguardFiles；
显式限定sdk支持的arm架构指令集，配置abiFilters；
gradle配置引用相对路径下的签名文件；
buildTypes针对编译本module时的相关配置说明；
自动提取编译生成的aar文件，重命名后自动复制到app module下的libs目录，方便调试验证与发布SDK。

//区别于application，这意味着该module将被视为library

1.2、如何打一个aar包

有图有真相：

双击gradle脚本assembleRelease，执行正式aar编译生成过程;
编译完成，可以看到outputs目录下自动生成了一个aar文件，同时我们的脚本也生效了，将其复制到了指定的目录下(这里可以做一下自动版本命名之类的工作)

没错，就是这么简单，到这里就生成了我们要发布的SDK！

二、依赖原则

2.1、尽量避免第三方库的依赖

在本系列开篇文章中提到了SDK开发的两个原则：

一是：最小可用性原则，即用最少的代码，如无必要勿增实体；二是：最少依赖性原则，即用最低限度的外部依赖，如无必要勿增依赖。

SDK开发中，需要尽量避免依赖第三方库，使用通用的Android SDK自带的官方库能满足需求即可，以免引起不必要的冲突或者三方库不要放到lib包下，默认打包进去封装过程中的aar二次打包问题；

比如，不要为了一个简单的JSON数据转换就引入Fastjson 、Gson之类的第三方json解析转换库。

如果确实因为项目需要，要引入一些开源库，可以通过源码集成的形式引入，再更改一下包名，避免集成冲突。

2.2、AndroidManifest无关属性剔除

如无必要，请保证 SDK Module中的AndroidManifest 配置简洁，剔除无关属性，如标签中的无意义字段。

2.3、SDK依赖项配置区别与原则

在 dependencies 代码块内，可以配置不同的依赖指令，对应不同的编译行为。如compileOnly、implementation、api的介绍以及配置原则。

三、如何解决组件依赖冲突

当我们集成的各种SDK包含相同依赖的时候，有可能产生版本冲突，此时可以通过如下方法进行配置解决。

3.1、强制使用指定版本

grconfigurations.all {    resolutionStrategy {        //强制使用某些版本的依赖        force 'com.android.support:support-v4:26.1.0','com.android.support:appcompat-v7:26.1.0'    }}

配置后查看依赖版本信息如下：

3.2、排除SDK中的指定模块

排除某SDK下指定module的依赖

dependencies {    implementation('some-library') {        //排除依赖'some-library'中的指定依赖        exclude group: 'com.android.support', module: 'support-v4'        exclude group: 'com.android.support', module: 'appcompat-v7'    }}

排除所有SDK下指定module的依赖

android {...configurations.all {    //全局排除SDk中的指定依赖    exclude group: 'com.android.support', module: 'support-v4'    exclude group: 'com.android.support', module: 'appcompat-v7'}...}

SDK开发探索系列到此为止，后续可能会出一些番外篇。希望整个系列下来对大家在SDK开发或者集成中能有所启发，感谢大家！

最后推荐一下我做的网站，玩Android: wanandroid.com ，包含详尽的知识体系、好用的工具，还有本公众号文章合集，欢迎体验和收藏！