概述

我们知道在Android的打包过程中，有一个步骤是压缩，也是为了减少apk包的大小，其中在压缩的过程中，很大一部分就是对资源的压缩，除了系统的压缩方案之外，我们今天讲另外两种压缩方案：微信方案和美团方案
微信的方案是通过修改aapt在处理资源文件相关的源码达到资源文件的替换；而后者指通过直接修改resources.arsc文件达到资源文件混淆的目的。相比之下，微信的方案更加优秀。

微信资源混淆方案

微信中的资源混淆工具主要为了混淆资源ID长度(例如将res/drawable/welcome.png混淆为r/s/a.png)，同时利用7z深度压缩，大大减少了安装包体积，同时也增加了逼格，提升了反破解难度。
具体源码与使用方法详细在github中：https://github.com/shwenzhang/AndResGuard

技术演进

资源混淆简单来说希望实现将res/drawable/icon,png变成res/drawable/a.png,或我们甚至可以将文件路径也同时混淆，改成r/s/a.png。形如：

Proguard  -> Resource Proguard 
R.string.name     -> R.string.a    
res/drawable/icon -> res/drawable/ar/s/a

要实现上面的效果，我们可以想到以下几种方案：

1. 最简单的方法，我们按照Proguard的做法，直接在源码级别修改，将代码以及xml的R.string.name中替换到R.string.a，icon.png重命名为a.png，然后再交给Android编译。
2. 根据Android的编译流程，所有资源ID已经被编译成32位int值。这说明我们并不需要去修改xml与java，因为在编译过程已经被R.java所替换，我们直接修改resources.arsc的二进制数据，不改变打包程，只要在生成resources.arsc之后修改它，同时重命名资源文件。
3. 但是方案二看起来不错，但是它依然依赖了编译流程，不利于使用。其实我们可以做到直接处理安装包。不依赖源码，不依赖编译过程，仅仅输入一个安装包，得到一个混淆包。
   上述方案的对比：
   
   综合对比，方案三能做到做到最大混淆，并且不依赖源码和编译过程。

技术实现

我们知道，resources.arsc一共有五种chunk类型，分别为TYPETABLE，TYPEPACKAGE，TYPE_STRING ,TYPETYPE，TYPECONFIG。

说明：
table，是整个reousces table的开始，它的chunksize即是整个文件的大小。

package，指的是一个package的开始，其实在resources,arsc是可以有多个package的。 而packageID即是资源resID的最高八位 ，一般来说系统android的是1(0x01)，普通的例如com.tencent.mm会是127(0x7f)，剩下的是从2开始起步。当然这个我们在aapt也是可以指定的(1-127即八位的合法空间,一些混合编译就是改这个packageID)。

string, 代表stringblock，我们一共有三种类型的stringblock。分别是table stringblock,typename stringblock, specsname stringblock。

type，这里讲的是typename stringblock里面我们用到的各种type(用到多少种类型的type,就有多少个type chunk)，例如attr, drawable, layout, id, color, anim等，Type ID是紧跟着Package ID。

config, 即是Android用来描述资源维度，例如横竖屏，屏幕密度，语言等。对于每一种type，它定义了多少种config，它后面就紧跟着多少个config chunk,例如我们定义了drawable-mdpi,drawable-hdpi,那后面就会有两个config。

entry，尽管没有entry这个chunk,但是每个config里面都会有很多的entry，例如drawable-mdpi中有icon1.png,icon2.png两个drawable,那在mdpi这个config中就存在两个entry。

比如微信在压缩前后：

具体实现方案如图：

然后我们在与7z的极限压缩结合，同时我们也可以强制压缩类似resources.arsc、png、jpg等Android默认不会打包压缩的文件。最后把修改后的resources.arsc重打包即可。
通过上面的分析，我们来看一下微信压缩的完整流程：

美团方案

Android查找资源的流程

在Android系统中，每一个应用程序一般都会配置很多资源，用来适配不同密度、大小和方向的屏幕，以及适配不同的国家、地区和语言等等。这些资源是在应用程序运行时自动根据设备的当前配置信息进行适配的。这也就是说，给定一个相同的资源ID，在不同的设备配置之下，查找到的可能是不同的资源。
这个查找过程对应用程序来说，是完全透明的，这个过程主要是靠Android资源管理框架来完成的，而Android资源管理框架实际是由AssetManager和Resources两个类来实现的。其中，Resources类可以根据ID来查找资源，而AssetManager类根据文件名来查找资源。事实上，如果一个资源ID对应的是一个文件，那么Resources类是先根据ID来找到资源文件名称，然后再将该文件名称交给AssetManager类来打开对应的文件的。
基本流程如下图：

通过上图我们可以看到Resources是通过resources.arsc把Resource的ID转化成资源文件的名称，然后交由AssetManager来加载的。
而Resources.arsc这个文件是存放在APK包中的，他是由AAPT工具在打包过程中生成的，他本身是一个资源的索引表，里面维护者资源ID、Name、Path或者Value的对应关系，AssetManager通过这个索引表，就可以通过资源的ID找到这个资源对应的文件或者数据。

AAPT

AAPT是Android Asset Packaging Tool的缩写，它存放在SDK的tools/目录下，AAPT的功能很强大，可以通过它查看查看、创建、更新压缩文件(如 .zip文件，.jar文件, .apk文件), 它也可以把资源编译为二进制文件，并生成resources.arsc, AAPT这个工具在APK打包过程中起到了非常重要作用，在打包过程中使用AAPT对APK中用到的资源进行打包，这里不对AAPT这个工具做过多的讨论，只看一下AAPT这个工具在打包过程中起到的作用，下图是AAPT打包的流程：

AAPT这个工具在打包过程中主要做了下列工作：

1. 把”assets”和”res/raw”目录下的所有资源进行打包（会根据不同的文件后缀选择压缩或不压缩），而”res/”目录下的其他资源进行编译或者其他处理（具体处理方式视文件后缀不同而不同，例如：”.xml”会编译成二进制文件，”.png”文件会进行优化等等）后才进行打包；
2. 会对除了assets资源之外所有的资源赋予一个资源ID常量，并且会生成一个资源索引表resources.arsc；
3. 编译AndroidManifest.xml成二进制的XML文件；
4. 把上面3个步骤中生成结果保存在一个*.ap_文件，并把各个资源ID常量定义在一个R.java中；

资源混淆

我们知道在系统的Proguard中，对APK中资源文件名使用简短无意义名称进行替换，给破解者制造困难，从而做到资源的相对安全。通过阅读AAPT编译资源的代码，我们发现修改AAPT在处理资源文件相关的源码是能够做到资源文件名的替换，下面是Resource.cpp中makeFileResources()的修改的代码片段：

static status_t makeFileResources(Bundle* bundle, const sp<AaptAssets>& assets, 
                                      ResourceTable* table, 
                                      const sp<ResourceTypeSet>& set, 
                                      const char* resType) 
    { 
        String8 type8(resType); 
        String16 type16(resType); 
 
        bool hasErrors = false; 
 
        ResourceDirIterator it(set, String8(resType)); 
        ssize_t res; 
        while ((res=it.next()) == NO_ERROR) { 
            if (bundle->getVerbose()) { 
                printf("    (new resource id %s from %s)/n", 
                       it.getBaseName().string(), it.getFile()->getPrintableSource().string()); 
            } 
            String16 baseName(it.getBaseName()); 
            const char16_t* str = baseName.string(); 
            const char16_t* const end = str + baseName.size(); 
            while (str < end) { 
                if (!((*str >= 'a' && *str <= 'z') 
                        || (*str >= '0' && *str <= '9') 
                        || *str == '_' || *str == '.')) { 
                    fprintf(stderr, "%s: Invalid file name: must contain only [a-z0-9_.]/n", 
                            it.getPath().string()); 
                    hasErrors = true; 
                } 
                str++; 
            } 
            String8 resPath = it.getPath(); 
            resPath.convertToResPath(); 
 
            String8 obfuscationName; 
            String8 obfuscationPath = getObfuscationName(resPath, obfuscationName); 
 
            table->addEntry(SourcePos(it.getPath(), 0), String16(assets->getPackage()), 
                            type16, 
                            baseName, // String16(obfuscationName), 
                            String16(obfuscationPath), // resPath 
                            NULL, 
                            &it.getParams()); 
            assets->addResource(it.getLeafName(), obfuscationPath/*resPath*/, it.getFile(), type8); 
        } 
 
        return hasErrors ? UNKNOWN_ERROR : NO_ERROR; 
    }

上述代码是在ResourceTable和Assets中添加资源文件时， 对资源文件名称进行修改，这就能够做到资源文件名称的替换，这样通过使用修改过的AAPT编译资源并进行打包，从而达到保护资源的目的。

总结

微信的方案是通过修改aapt在处理资源文件相关的源码达到资源文件的替换；而美团主要通过直接修改resources.arsc文件达到资源文件混淆的目的。微信从aapt的原理上着手，而美团只是在已有的方案上优化，相比之下，微信的混淆更彻底。