Android App包瘦身优化实践

于 2017-04-07 16:03:00 发布
阅读量3.3k 收藏 4
点赞数
文章标签： java php 移动开发
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/meituantech/article/details/80062307
版权

随着业务的快速迭代增长，美团App里不断引入新的业务逻辑代码、图片资源和第三方SDK，直接导致APK体积不断增长。包体积增长带来的问题越来越多，如CDN流量费用增加、用户安装成功率降低，甚至可能会影响用户的留存率。APK的瘦身已经是不得不考虑的事情。在尝试瘦身的过程中，我们借鉴了很多业界其他公司提供的方案，同时也针对自身特点，发现了一些新的技巧。本文将对其中的一些做详细介绍。

在开始讲瘦身技巧之前，先来讲一下APK的构成。

APK的构成

可以用Zip工具打开APK查看。比如，美团App 7.8.6的线上版本的格式是这样的：


apk_format.png

可以看到APK由以下主要部分组成：

文件/目录描述
lib/存放so文件，可能会有armeabi、armeabi-v7a、arm64-v8a、x86、x86_64、mips，大多数情况下只需要支持armabi与x86的架构即可，如果非必需，可以考虑拿掉x86的部分
res/存放编译后的资源文件，例如：drawable、layout等等
assets/应用程序的资源，应用程序可以使用AssetManager来检索该资源
META-INF/该文件夹一般存放于已经签名的APK中，它包含了APK中所有文件的签名摘要等信息
classes(n).dexclasses文件是Java Class，被DEX编译后可供Dalvik/ART虚拟机所理解的文件格式
resources.arsc编译后的二进制资源文件
AndroidManifest.xmlAndroid的清单文件，格式为AXML，用于描述应用程序的名称、版本、所需权限、注册的四大组件

当然还会有一些其它的文件，例如上图中的org/、src/、push_version等文件或文件夹。这些资源是Java Resources，感兴趣的可以结合编译工作流中的流程图以及MergeJavaResourcesTransform的源码看看被打入APK包中的资源都有哪些，这里不做过多介绍。

在充分了解了APK各个组成部分以及它们的作用后，我们针对自身特点进行了分析和优化。下面将从Zip文件格式、classes.dex、资源文件、resources.arsc等方面来介绍下我们发现的部分优化技巧。

Zip格式优化

前面介绍了APK的文件格式以及主要组成部分，通过aapt l -v xxx.apk或unzip -l xxx.apk来查看APK文件时会得到以下信息，见下面截图：


apk_aapt_dump.png

通过上图可以看到APK中很多资源是以Stored来存储的，根据Zip的文件格式中对压缩方式的描述Compression_methods可以看出这些文件是没有压缩的，那为什么它们没有被压缩呢？从AAPT的源码中找到以下描述：

/* these formats are already compressed, or don't compress well */
static const char* kNoCompressExt[] = {
    ".jpg", ".jpeg", ".png", ".gif",
    ".wav", ".mp2", ".mp3", ".ogg", ".aac",
    ".mpg", ".mpeg", ".mid", ".midi", ".smf", ".jet",
    ".rtttl", ".imy", ".xmf", ".mp4", ".m4a",
    ".m4v", ".3gp", ".3gpp", ".3g2", ".3gpp2",
    ".amr", ".awb", ".wma", ".wmv", ".webm", ".mkv"
};

可以看出AAPT在资源处理时对这些文件后缀类型的资源是不做压缩的，那是不是可以修改它们的压缩方式从而达到瘦身的效果呢？

在介绍怎么做之前，先来大概介绍一下App的资源是怎么被打进APK包里的。Android构建工具链使用AAPT工具来对资源进行处理，来看下图（图片来源于Build Workflow）：



android_build_process.png
点击图片查看大图

通过上图可以看到Manifest、Resources、Assets的资源经过AAPT处理后生成R.java、Proguard Configuration、Compiled Resources。其中R.java大家都比较熟悉，这里就不过多介绍了。我们来重点看看Proguard Configuration、Compiled Resources都是做什么的呢？

  • Proguard Configuration是AAPT工具为Manifest中声明的四大组件以及布局文件中（XML layouts）使用的各种Views所生成的ProGuard配置，该文件通常存放在${project.buildDir}/${AndroidProject.FD_INTERMEDIATES}/proguard-rules/${flavorName}/${buildType}/aapt_rules.txt，下面是项目中该文件的截图，红框标记出来的就是对AndroidManifest.xml、XML Layouts中相关Class的ProGuard配置。

aapt_proguard_rules.png
  • Compiled Resources是一个Zip格式的文件，这个文件的路径通常为${project.buildDir}/${AndroidProject.FD_INTERMEDIATES}/res/resources-${flavorName}-${buildType}-stripped.ap_。 通过下面经过Zip解压后的截图，可以看出这个文件包含了res、AndroidManifest.xml和resources.arsc的文件或文件夹。结合Build Workflow中的描述，可以看出这个文件（resources-${flavorName}-${buildType}-stripped.ap_）会被apkbuilder打包到APK包中，它其实就是APK的“资源包”（res、AndroidManifest.xml和resources.arsc）。

ap_file_content.png

我们就是通过这个文件来修改不同后缀文件资源的压缩方式来达到瘦身效果的，而在后面“resources.arsc的优化”一节中也是操作的这个文件。

笔者在自己的项目中是通过在package${flavorName} Task（感兴趣的同学可以查看源码）之前进行这个操作的。

下面是部分代码片段：

appPlugin.variantManager.variantDataList.each { variantData ->
    variantData.outputs.each {
        def sourceApFile = it.packageAndroidArtifactTask.getResourceFile();
        def destApFile = new File("${sourceApFile.name}.temp", sourceApFile.parentFile);
        it.packageAndroidArtifactTask.doFirst {
            byte[] buf = new byte[1024 * 8];

            ZipInputStream zin = new ZipInputStream(new FileInputStream(sourceApFile));
            ZipOutputStream out = new ZipOutputStream(new FileOutputStream(destApFile));

            ZipEntry entry = zin.getNextEntry();
            while (entry != null) {
                String name = entry.getName();

                // Add ZIP entry to output stream.
                ZipEntry zipEntry = new ZipEntry(name);

                if (ZipEntry.STORED == entry.getMethod() && !okayToCompress(entry.getName())) {
                    zipEntry.setMethod(ZipEntry.STORED)
                    zipEntry.setSize(entry.getSize())
                    zipEntry.setCompressedSize(entry.getCompressedSize())
                    zipEntry.setCrc(entry.getCrc())
                } else {
                    zipEntry.setMethod(ZipEntry.DEFLATED)
                    ...
                }
                ...

                out.putNextEntry(zipEntry);
                out.closeEntry();
                entry = zin.getNextEntry();
            }
            // Close the streams
            zin.close();
            out.close();

            sourceApFile.delete();
            destApFile.renameTo(sourceApFile);
        }
    }
}

当然也可以在其它构建步骤中采用更高压缩率的方式来达到瘦身效果，例如采用7Zip压缩等等。

本技巧的使用需要注意以下问题：

  • 如果音视频资源被压缩存放在APK中的话，在使用一些音频、视频API时尤其要注意，需要做好充分的测试。
  • resources.arsc文件最好不要压缩存储，如果压缩会影响一定的性能（尤其是冷启动时间）。
  • 如果想在Android 6.0上开启android:extractNativeLibs=”false”的话，.so 文件也不能被压缩，android:extractNativeLibs的使用姿势看这里：App Manifest --- application。

classes.dex的优化

如何优化classes.dex的大小呢？大体有如下套路：

  • 时刻保持良好的编程习惯和对包体积敏锐的嗅觉，去除重复或者不用的代码，慎用第三方库，选用体积小的第三方SDK等等。
  • 开启ProGuard来进行代码压缩，通过使用ProGuard来对代码进行混淆、优化、压缩等工作。

针对第一种套路，因各个公司的项目的差异，共性的东西较少，需要case by case的分析，这里不做过多的介绍。

压缩代码

可以通过开启ProGuard来实现代码压缩，可以在build.gradle文件相应的构建类型中添加minifyEnabled true。

请注意，代码压缩会拖慢构建速度，因此应该尽可能避免在调试构建中使用。不过一定要为用于测试的最终APK启用代码压缩，如果不能充分地自定义要保留的代码，可能会引入错误。

例如，下面这段来自build.gradle文件的代码用于为发布构建启用代码压缩：

android {
    buildTypes {
        release {
            minifyEnabled true
            proguardFiles getDefaultProguardFile(‘proguard-android.txt'),
                    'proguard-rules.pro'
        }
    }
    ...
}

除了minifyEnabled属性外，还有用于定义ProGuard规则的proguardFiles属性：

  • getDefaultProguardFile(‘proguard-android.txt')是从Android SDKtools/proguard/文件夹获取默认ProGuard设置。
  • proguard-rules.pro文件用于添加自定义ProGuard规则。默认情况下，该文件位于模块根目录（build.gradle文件旁）。

提示：要想做进一步的代码压缩，可尝试使用位于同一位置的proguard-android-optimize.txt文件。它包括相同的ProGuard规则，但还包括其他在字节码一级（方法内和方法间）执行分析的优化，以进一步减小APK大小和帮助提高其运行速度。

在Gradle Plugin 2.2.0及以上版本ProGuard的配置文件会自动解压缩到${rootProject.buildDir}/${AndroidProject.FD_INTERMEDIATES}/proguard-files/目录下，proguardFiles会从这个目录来获取ProGuard配置。

每次执行完ProGuard之后，ProGuard都会在${project.buildDir}/outputs/mapping/${flavorDir}/生成以下文件：

文件名描述
dump.txtAPK中所有类文件的内部结构
mapping.txt提供原始与混淆过的类、方法和字段名称之间的转换，可以通过proguard.obfuscate.MappingReader来解析
seeds.txt列出未进行混淆的类和成员
usage.txt列出从APK移除的代码

可以通过在usage.txt文件中看到哪些代码被删除了，如下图中所示android.support.multidex.MultiDex已经被删除了：


proguard_usage.png

R Field的优化

除了对项目代码优化和开启代码压缩之外，笔者在《美团Android DEX自动拆包及动态加载简介》这篇文章中提到了通过内联R Field来解决R Field过多导致MultiDex 65536的问题，而这一步骤对代码瘦身能够起到明显的效果。下面是笔者通过字节码工具在构建流程中内联R Field的代码片段（字节码的修改可以使用Javassist或者ASM，该步骤笔者采用的是Javassist）。

ctBehaviors.each { CtBehavior ctBehavior ->
    if (!ctBehavior.isEmpty()) {
        try {
            ctBehavior.instrument(new ExprEditor() {
                @Override
                public void edit(FieldAccess f) {
                    try {
                        def fieldClassName = JavassistUtils.getClassNameFromCtClass(f.getCtClass())
                        if (shouldInlineRField(className, fieldClassName) && f.isReader()) {
                            def temp = fieldClassName.substring(fieldClassName.indexOf(ANDROID_RESOURCE_R_FLAG) + ANDROID_RESOURCE_R_FLAG.length())
                            def fieldName = f.fieldName
                            def key = "${temp}.${fieldName}"

                            if (resourceSymbols.containsKey(key)) {
                                Object obj = resourceSymbols.get(key)
                                try {
                                    if (obj instanceof Integer) {
                                        int value = ((Integer) obj).intValue()
                                        f.replace("\$_=${value};")
                                    } else if (obj instanceof Integer[]) {
                                        def obj2 = ((Integer[]) obj)
                                        StringBuilder stringBuilder = new StringBuilder()
                                        for (int index = 0; index < obj2.length; ++index) {
                                            stringBuilder.append(obj2[index].intValue())
                                            if (index != obj2.length - 1) {
                                                stringBuilder.append(",")
                                            }
                                        }
                                        f.replace("\$_ = new int[]{${stringBuilder.toString()}};")
                                    } else {
                                        throw new GradleException("Unknown ResourceSymbols Type!")
                                    }
                                } catch (NotFoundException e) {
                                    throw new GradleException(e.message)
                                } catch (CannotCompileException e) {
                                    throw new GradleException(e.message)
                                }
                            } else {
                                throw new GradleException("******** InlineRFieldTask unprocessed ${className}, ${fieldClassName}, ${f.fieldName}, ${key}")
                            }
                        }
                    } catch (NotFoundException e) {
                    }
                }
            })
        } catch (CannotCompileException e) {
        }
    }
}

其它优化手段

针对代码的瘦身还有很多优化的技巧，例如：

  • 减少ENUM的使用（详情可以参考：Remove Enumerations），每减少一个ENUM可以减少大约1.0到1.4 KB的大小；
  • 通过pmd cpd来检查重复的代码从而进行代码优化；
  • 移除掉所有无用或者功能重复的依赖库。

这些优化技巧就不展开介绍了。

资源的优化

图片优化

为了支持Android设备DPI的多样化（[l|m|tv|h|x|xx|xxx]dpi）以及用户对高质量UI的期待，美团App中使用了大量的图片，在Android下支持很多格式的图片，例如：PNG、JPG 、WebP，那我们该怎么选择不同类型的图片格式呢？ 在Google I/O 2016中提到了针对图片格式的选择，来看下图（图片来源于Image compression for Android developers）：


android_image_format_choosen.png

通过上图可以看出一个大概图片格式选择的方法。如果能用VectorDrawable来表示的话优先使用VectorDrawable，如果支持WebP则优先用WebP，而PNG主要用在展示透明或者简单的图片，而其它场景可以使用JPG格式。针对每种图片格式也有各类的优化手段和优化工具。

使用矢量图片

可以使用矢量图形来创建独立于分辨率的图标和其他可伸缩图片。使用矢量图片能够有效的减少App中图片所占用的大小，矢量图形在Android中表示为VectorDrawable对象。 使用VectorDrawable对象，100字节的文件可以生成屏幕大小的清晰图像，但系统渲染每个VectorDrawable对象需要大量的时间，较大的图像需要更长的时间才能出现在屏幕上。 因此只有在显示小图像时才考虑使用矢量图形。有关使用VectorDrawable的更多信息，请参阅 Working with Drawables。

使用WebP

如果App的minSdkVersion高于14（Android 4.0+）的话，可以选用WebP格式，因为WebP在同画质下体积更小（WebP支持透明度，压缩比比JPEG更高但显示效果却不输于JPEG，官方评测quality参数等于75均衡最佳）， 可以通过PNG到WebP转换工具来进行转换。当然Android从4.0才开始WebP的原生支持，但是不支持包含透明度，直到Android 4.2.1+才支持显示含透明度的WebP，在笔者使用中是判断当前App的minSdkVersion以及图片文件的类型（是否为透明）来选用是否适用WebP。见下面的代码片段：

boolean isPNGWebpConvertSupported() {
    if (!isWebpConvertEnable()) {
        return false
    }

    // Android 4.0+
    return GradleUtils.getAndroidExtension(project).defaultConfig.minSdkVersion.apiLevel >= 14
    // 4.0
}

boolean isTransparencyPNGWebpConvertSupported() {
    if (!isWebpConvertEnable()) {
        return false
    }

    // Lossless, Transparency, Android 4.2.1+
    return GradleUtils.getAndroidExtension(project).defaultConfig.minSdkVersion.apiLevel >= 18
    // 4.3
}

def convert() {
    String resPath = "${project.buildDir}/${AndroidProject.FD_INTERMEDIATES}/res/merged/${variant.dirName}"
    def resDir = new File("${resPath}")
    resDir.eachDirMatch(~/drawable[a-z0-9-]*/) { dir ->
        FileTree tree = project.fileTree(dir: dir)
        tree.filter { File file ->
            return (isJPGWebpConvertSupported() && (file.name.endsWith(SdkConstants.DOT_JPG) || file.name.endsWith(SdkConstants.DOT_JPEG))) || (isPNGWebpConvertSupported() && file.name.endsWith(SdkConstants.DOT_PNG) && !file.name.endsWith(SdkConstants.DOT_9PNG))
        }.each { File file ->
            def shouldConvert = true
            if (file.name.endsWith(SdkConstants.DOT_PNG)) {
                if (!isTransparencyPNGWebpConvertSupported()) {
                    shouldConvert = !Imaging.getImageInfo(file).isTransparent()
                }
            }
            if (shouldConvert) {
                WebpUtils.encode(project, webpFactorQuality, file.absolutePath, webp)
            }
        }
    }
}

选择更优的压缩工具

可以使用pngcrush、pngquant或zopflipng等压缩工具来减少PNG文件大小，而不会丢失图像质量。所有这些工具都可以减少PNG文件大小，同时保持图像质量。

pngcrush工具特别有效：此工具在PNG过滤器和zlib（Deflate）参数上迭代，使用过滤器和参数的每个组合来压缩图像。然后选择产生最小压缩输出的配置。

对于JPEG文件，你可以使用packJPG或guetzli等工具将JPEG文件压缩的更小，这些工具能够在保持图片质量不变的情况下，把图片文件压缩的更小。guetzli工具更是能够在图片质量不变的情况下，将文件大小降低35%。

在Android构建流程中AAPT会使用内置的压缩算法来优化res/drawable/目录下的PNG图片，但也可能会导致本来已经优化过的图片体积变大，可以通过在build.gradle中设置cruncherEnabled来禁止AAPT来优化PNG图片。

aaptOptions {
    cruncherEnabled = false
}

开启资源压缩

Android的编译工具链中提供了一款资源压缩的工具，可以通过该工具来压缩资源，如果要启用资源压缩，可以在build.gradle文件中将shrinkResources true。例如：

android {
    ...
    buildTypes {
        release {
            shrinkResources true
            minifyEnabled true
            proguardFiles getDefaultProguardFile('proguard-android.txt'),
                    'proguard-rules.pro'
        }
    }
}

需要注意的是目前资源压缩器目前不会移除values/文件夹中定义的资源（例如字符串、尺寸、样式和颜色），有关详情，请参阅问题 70869。

Android构建工具是通过ResourceUsageAnalyzer来检查哪些资源是无用的，当检查到无用的资源时会把该资源替换成预定义的版本。详看下面代码片段（摘自com.android.build.gradle.tasks.ResourceUsageAnalyzer）：

public class ResourceUsageAnalyzer {
    ...

    /**
     * Whether we should create small/empty dummy files instead of actually
     * removing file resources. This is to work around crashes on some devices
     * where the device is traversing resources. See http://b.android.com/79325 for more.
     */
    public static final boolean REPLACE_DELETED_WITH_EMPTY = true;

      // A 1x1 pixel PNG of type BufferedImage.TYPE_BYTE_GRAY
    public static final byte[] TINY_PNG = new byte[] {
            (byte)-119, (byte)  80, (byte)  78, (byte)  71, (byte)  13, (byte)  10,
            (byte)  26, (byte)  10, (byte)   0, (byte)   0, (byte)   0, (byte)  13,
            (byte)  73, (byte)  72, (byte)  68, (byte)  82, (byte)   0, (byte)   0,
            (byte)   0, (byte)   1, (byte)   0, (byte)   0, (byte)   0, (byte)   1,
            (byte)   8, (byte)   0, (byte)   0, (byte)   0, (byte)   0, (byte)  58,
            (byte) 126, (byte)-101, (byte)  85, (byte)   0, (byte)   0, (byte)   0,
            (byte)  10, (byte)  73, (byte)  68, (byte)  65, (byte)  84, (byte) 120,
            (byte) -38, (byte)  99, (byte)  96, (byte)   0, (byte)   0, (byte)   0,
            (byte)   2, (byte)   0, (byte)   1, (byte) -27, (byte)  39, (byte) -34,
            (byte)  -4, (byte)   0, (byte)   0, (byte)   0, (byte)   0, (byte)  73,
            (byte)  69, (byte)  78, (byte)  68, (byte) -82, (byte)  66, (byte)  96,
            (byte)-126
    };

    public static final long TINY_PNG_CRC = 0x88b2a3b0L;

    // A 3x3 pixel PNG of type BufferedImage.TYPE_INT_ARGB with 9-patch markers
    public static final byte[] TINY_9PNG = new byte[] {
            (byte)-119, (byte)  80, (byte)  78, (byte)  71, (byte)  13, (byte)  10,
            (byte)  26, (byte)  10, (byte)   0, (byte)   0, (byte)   0, (byte)  13,
            (byte)  73, (byte)  72, (byte)  68, (byte)  82, (byte)   0, (byte)   0,
            (byte)   0, (byte)   3, (byte)   0, (byte)   0, (byte)   0, (byte)   3,
            (byte)   8, (byte)   6, (byte)   0, (byte)   0, (byte)   0, (byte)  86,
            (byte)  40, (byte) -75, (byte) -65, (byte)   0, (byte)   0, (byte)   0,
            (byte)  20, (byte)  73, (byte)  68, (byte)  65, (byte)  84, (byte) 120,
            (byte) -38, (byte)  99, (byte)  96, (byte)-128, (byte)-128, (byte)  -1,
            (byte)  12, (byte)  48, (byte)   6, (byte)   8, (byte) -96, (byte)   8,
            (byte)-128, (byte)   8, (byte)   0, (byte)-107, (byte)-111, (byte)   7,
            (byte)  -7, (byte) -64, (byte) -82, (byte)   8, (byte)   0, (byte)   0,
            (byte)   0, (byte)   0, (byte)   0, (byte)  73, (byte)  69, (byte)  78,
            (byte)  68, (byte) -82, (byte)  66, (byte)  96, (byte)-126
    };

    public static final long TINY_9PNG_CRC = 0x1148f987L;

    // The XML document <x/> as binary-packed with AAPT
    public static final byte[] TINY_XML = new byte[] {
            (byte)   3, (byte)   0, (byte)   8, (byte)   0, (byte) 104, (byte)   0,
            (byte)   0, (byte)   0, (byte)   1, (byte)   0, (byte)  28, (byte)   0,
            (byte)  36, (byte)   0, (byte)   0, (byte)   0, (byte)   1, (byte)   0,
            (byte)   0, (byte)   0, (byte)   0, (byte)   0, (byte)   0, (byte)   0,
            (byte)   0, (byte)   1, (byte)   0, (byte)   0, (byte)  32, (byte)   0,
            (byte)   0, (byte)   0, (byte)   0, (byte)   0, (byte)   0, (byte)   0,
            (byte)   0, (byte)   0, (byte)   0, (byte)   0, (byte)   1, (byte)   1,
            (byte) 120, (byte)   0, (byte)   2, (byte)   1, (byte)  16, (byte)   0,
            (byte)  36, (byte)   0, (byte)   0, (byte)   0, (byte)   1, (byte)   0,
            (byte)   0, (byte)   0, (byte)  -1, (byte)  -1, (byte)  -1, (byte)  -1,
            (byte)  -1, (byte)  -1, (byte)  -1, (byte)  -1, (byte)   0, (byte)   0,
            (byte)   0, (byte)   0, (byte)  20, (byte)   0, (byte)  20, (byte)   0,
            (byte)   0, (byte)   0, (byte)   0, (byte)   0, (byte)   0, (byte)   0,
            (byte)   0, (byte)   0, (byte)   3, (byte)   1, (byte)  16, (byte)   0,
            (byte)  24, (byte)   0, (byte)   0, (byte)   0, (byte)   1, (byte)   0,
            (byte)   0, (byte)   0, (byte)  -1, (byte)  -1, (byte)  -1, (byte)  -1,
            (byte)  -1, (byte)  -1, (byte)  -1, (byte)  -1, (byte)   0, (byte)   0,
            (byte)   0, (byte)   0
    };

    public static final long TINY_XML_CRC = 0xd7e65643L;

    ...
}

上面截图中3个byte数组的定义就是资源压缩工具为无用资源提供的预定义版本，可以看出对.png提供了TINY_PNG， 对.9.png提供了TINY_9PNG以及对.xml提供了TINY_XML的预定义版本。

资源压缩工具的详细使用可以参考Shrink Your Code and Resources。资源压缩工具默认是采用安全压缩模式来运行，可以通过开启严格压缩模式来达到更好的瘦身效果。

如果想知道哪些资源是无用的，可以通过资源压缩工具的输出日志文件${project.buildDir}/outputs/mapping/release/resources.txt来查看。如下图所示res/layout/abc_activity_chooser_viewer.xml就是无用的，然后被预定义的版本TINY_XML所替换：


shrink_resources_txt.png

资源压缩工具只是把无用资源替换成预定义较小的版本，那我们如何删除这些无用资源呢？通常的做法是结合资源压缩工具的输出日志，找到这些资源并把它们进行删除。但在笔者的项目中很多无用资源是被其它组件或第三方SDK所引入的，如果采用这种优化方式会带来这些SDK后期维护成本的增加，针对这种情况笔者是通过采用在resources.arsc中做优化来解决的，详情看下面“resources.arsc的优化”一节的介绍。

语言资源优化

根据App自身支持的语言版本选用合适的语言资源，例如使用了AppCompat，如果不做任何配置的话，最终APK包中会包含AppCompat中消息的所有已翻译语言字符串，无论应用的其余部分是否翻译为同一语言，可以通过resConfig来配置使用哪些语言，从而让构建工具移除指定语言之外的所有资源。下图是具体的配置示例：

android {
    ...
    defaultConfig {
        ...
        resConfigs "zh", "zh-rCN"
    }
    ...
}

针对为不同DPI所提供的图片也可以采用相同的策略，需要针对自身的目标用户和目标设备做一定的选择，可以参考Support Only Specific Densities来操作。有关屏幕密度的详细信息，请参阅Screen Sizes and Densities。
对.so文件也可以采用类似的策略，比如笔者的项目中只保留了armeabi版本的.so文件。

resources.arsc的优化

针对resources.arsc，笔者尝试过的优化手段如下：

  • 开启资源混淆；
  • 对重复的资源进行优化；
  • 对被shrinkResources优化掉的资源进行处理。

下面将分别对这些优化手段进行展开介绍。

资源混淆

在笔者另一篇《美团Android资源混淆保护实践》文章中介绍了采用对资源混淆的方式来保护资源的安全，同时也提到了这种方式有显著的瘦身效果。笔者当时是采用修改AAPT的相关源码的方式，这种方式的痛点是每次升级Build Tools都要修改一次AAPT源码，维护性较差。目前笔者采用了微信开源的资源混淆库AndResGuard，具体的原理和使用帮助可以参考安装包立减1M--微信Android资源混淆打包工具。

无用资源优化

在上一节中介绍了可以通过shrinkResources true来开启资源压缩，资源压缩工具会把无用的资源替换成预定义的版本而不是移除，如果采用人工移除的方式会带来后期的维护成本，这里笔者采用了一种比较取巧的方式，在Android构建工具执行package${flavorName}Task之前通过修改Compiled Resources来实现自动去除无用资源。

具体流程如下：

  • 收集资源包（Compiled Resources的简称）中被替换的预定义版本的资源名称，通过查看资源包（Zip格式）中每个ZipEntry的CRC-32 checksum来寻找被替换的预定义资源，预定义资源的CRC-32定义在ResourceUsageAnalyzer，下面是它们的定义。
      // A 1x1 pixel PNG of type BufferedImage.TYPE_BYTE_GRAY
    public static final long TINY_PNG_CRC = 0x88b2a3b0L;

    // A 3x3 pixel PNG of type BufferedImage.TYPE_INT_ARGB with 9-patch markers
    public static final long TINY_9PNG_CRC = 0x1148f987L;

    // The XML document <x/> as binary-packed with AAPT
    public static final long TINY_XML_CRC = 0xd7e65643L;
  • 通过android-chunk-utils把resources.arsc中对应的定义移除；
  • 删除资源包中对应的资源文件。

重复资源优化

目前美团App是由各个业务团队共同开发完成，为了方便各业务团队的独立开发，美团App进行了平台化改造。改造时存在很多资源文件（如：drawable、layout等）被不同的业务团队都拷贝到自己的Library下，同时为了避免引发资源覆盖的问题，每个业务团队都会为自己的资源文件名添加前缀。这样就导致了这些资源文件虽然内容相同，但因为名称的不同而不能被覆盖，最终都会被集成到APK包中，针对这种问题笔者采用了和前面“无用资源优化”一节中描述类似的策略。

具体步骤如下：

  • 通过资源包中的每个ZipEntry的CRC-32 checksum来筛选出重复的资源；
  • 通过android-chunk-utils修改resources.arsc，把这些重复的资源都重定向到同一个文件上；
  • 把其它重复的资源文件从资源包中删除。

代码片段：

variantData.outputs.each {
    def apFile = it.packageAndroidArtifactTask.getResourceFile();

    it.packageAndroidArtifactTask.doFirst {
        def arscFile = new File(apFile.parentFile, "resources.arsc");
        JarUtil.extractZipEntry(apFile, "resources.arsc", arscFile);

        def HashMap<String, ArrayList<DuplicatedEntry>> duplicatedResources = findDuplicatedResources(apFile);

        removeZipEntry(apFile, "resources.arsc");

        if (arscFile.exists()) {
            FileInputStream arscStream = null;
            ResourceFile resourceFile = null;
            try {
                arscStream = new FileInputStream(arscFile);

                resourceFile = ResourceFile.fromInputStream(arscStream);
                List<Chunk> chunks = resourceFile.getChunks();

                HashMap<String, String> toBeReplacedResourceMap = new HashMap<String, String>(1024);

                // 处理arsc并删除重复资源
                Iterator<Map.Entry<String, ArrayList<DuplicatedEntry>>> iterator = duplicatedResources.entrySet().iterator();
                while (iterator.hasNext()) {
                    Map.Entry<String, ArrayList<DuplicatedEntry>> duplicatedEntry = iterator.next();

                    // 保留第一个资源，其他资源删除掉
                    for (def index = 1; index < duplicatedEntry.value.size(); ++index) {
                        removeZipEntry(apFile, duplicatedEntry.value.get(index).name);

                        toBeReplacedResourceMap.put(duplicatedEntry.value.get(index).name, duplicatedEntry.value.get(0).name);
                    }
                }

                for (def index = 0; index < chunks.size(); ++index) {
                    Chunk chunk = chunks.get(index);
                    if (chunk instanceof ResourceTableChunk) {
                        ResourceTableChunk resourceTableChunk = (ResourceTableChunk) chunk;
                        StringPoolChunk stringPoolChunk = resourceTableChunk.getStringPool();
                        for (def i = 0; i < stringPoolChunk.stringCount; ++i) {
                            def key = stringPoolChunk.getString(i);
                            if (toBeReplacedResourceMap.containsKey(key)) {
                                stringPoolChunk.setString(i, toBeReplacedResourceMap.get(key));
                            }
                        }
                    }
                }

            } catch (IOException ignore) {
            } catch (FileNotFoundException ignore) {
            } finally {
                if (arscStream != null) {
                    IOUtils.closeQuietly(arscStream);
                }

                arscFile.delete();
                arscFile << resourceFile.toByteArray();

                addZipEntry(apFile, arscFile);
            }
        }
    }
}

通过这种方式可以有效减少重复资源对包体大小的影响，同时这种操作方式对各业务团队透明，也不会增加协调相同资源如何被不同业务团队复用的成本。

总结

上述就是我们目前在APK瘦身方面的做的一些尝试和积累，可以根据自身情况取舍使用。当然我们还可以采取一些按需加载的策略来减少安装包的体积。最后提一点，砍掉不必要的功能才是安装包瘦身的超级大招。一个好的App的标准有很多方面，但提供尽可能小的安装包是其中一个重要的方面，这也是对我们Android开发者人员自身的提出的基本要求，要时刻保持良好的编程习惯和对包体积敏锐的嗅觉。

参考文献

作者简介

建帅，Android技术专家，2015年3月加入美团点评，目前就职于到店餐饮技术部信息与交易技术中心。

到店餐饮技术部交易与信息技术中心，负责美团点评美食用户端业务，服务于数以亿计用户，通过更好的榜单、真实的评价和完善的信息为用户提供更好的决策支持，致力于提升用户体验；同时承载所有餐饮商户端线上流量，为餐饮商户提供多种营销工具，提升餐饮商户营销效率，最终达到让国人“Eat Better、Live Better”的美好愿景！我们的团队包含且不限于Android、iOS、FE、Java、PHP等技术方向，已完备覆盖前后端技术栈。只要你来，就能点亮全栈开发技能树。




发现文章有错误、对内容有疑问，都可以关注美团点评技术团队微信公众号（meituantech），在后台给我们留言。我们每周会挑选出一位热心小伙伴，送上一份精美的小礼品。快来扫码关注我们吧！

公众号二维码
美团技术团队
关注
博客
【报名】MARS TALK 香港科技大学站｜未来产业探索：新技术、新趋势
11-07 9
【MARS TALK】是由深圳市美团机器人研究院（Meituan Academy of Robotics Shenzhen，简称MARS）发起的系列活动。每一期活动我们将邀请来自学术界和产业界的专家分享他们在前沿领域的实践经验，共同探讨机器人技术在学术研究和行业应用中的最新发展及热点问题。活动时间：11月16日（周六）14:00-17:30活动地点：香港科技大学清水湾校区利荣达演讲厅(LT-D)活...
博客
CIKM 2024 | 美团技术团队精选论文解读
10-31 589
本文精选了美团技术团队被CIKM 2024收录的8篇论文进行解读，覆盖了自监督学习、解释生成、CTR预测、跨域推荐、向量召回、图像生成、时效预测等多个技术领域。这些论文有美团独立研究，还有跟高校、科研机构合作的成果。希望能给从事相关研究工作的同学带来一些帮助或启发。CIKM是信息检索、知识管理和数据库领域中顶级的国际学术会议。2024年，CIKM共收到全球14...
博客
密码：1024（请勿外传）
10-24 120
1024.
博客
美团机器人研究院｜2024年科研课题申报指南
10-17 69
深圳市美团机器人研究院（Meituan Academy of Robotics Shenzhen，MARS）于2022年7月正式挂牌，于2022年11月正式对外宣布成立。研究院依托美团生活服务丰富的业务场景与数据积累，结合国内外学术界与产业界的科研优势，开展面向机器人领域的关键技术的研发，引领机器人学科前沿和技术创新方向，加快科研成果的落地转化，推动机器人相关技术的示范应用，在大湾区打造机器人技术...
博客
全域用户建模在美团首页推荐的探索与实践
10-11 1121
本文详述了全域建模技术在美团首页推荐系统的发展和演进。美团首页推荐算法团队通过多阶段递进式探索验证，在召回与排序模块引入多展位、多应用渠道的多源用户交互数据，并在落地过程中解决了美团多展位、多业务、时空场景强相关性的特点导致的严重跨域信号负迁移挑战。
博客
KDD 2024 OAG-Challenge Cup赛道三项冠军技术方案解读 | 内含中秋福利
09-12 1314
大众点评技术部/搜索与内容智能团队组成的BlackPearl队伍，参加了2024年KDD 2024 OAG-Challenge Cup赛道的WhoIsWho-IND、PST、AQA三道赛题，以较大优势包揽了该赛道全部赛题的冠军。本文对这三个赛道的夺冠方案分别进行了解读，希望对大家有所帮助或启发。另外，我们在文末准备了一份中秋福利——美团中秋月饼礼盒送给大家，欢...
博客
新一代实验分析引擎：驱动履约平台的数据决策
09-05 890
传统实验引擎基于单一实验单元、普通随机分组、大样本和个体独立性，适用于单边场景实验，但在多边场景中显得不足。此外，多边场景中溢出效应成为常态，进一步挑战了传统方法的适用性。针对这些挑战，本文提出了新方案可作为有用的指南，帮助实验平台建设者应对开发中的挑战，并采用不同方法确保实验的可靠性和高效性。1. 引言1.1 AB实验的发展：从单边场景到单边与多边场景的共存...
博客
社招｜美团Keeta技术岗位热招中，邀你共赴星辰大海！
08-29 301
算法开发方向岗位名称简历投递工作地点履约算法负责人申请北京营销算法工程师申请北京数据开发方向岗位名称简历投递工作地点数据仓库工程师申请深圳数据仓库专家申请北京数据仓库工程师申请北京后端开发方向岗位名称简历投递工作地点Java研发工程师申请深圳Java研发工程师申请北京Java高级工程师（用户系统方向）申请北京Java高级工程师（交易系统方向）申请北京Java高级开发工程师（调度系统）申请北京Jav...
博客
校招 | 美团基础研发平台，心动Offer等你来！
08-29 185
博客
信息流广告预估技术在美团外卖的实践
08-16 1079
本文介绍了美团信息流广告业务以及预估技术的现状，然后重点分享了信息流广告预估在美团的具体实践，围绕决策路径、超长超宽建模和全还原建模等多个维度进行了分享，最后是一些总结和展望，希望能对大家有所帮助或启发。
博客
ACL 2024 | 美团技术团队精选论文解读 & 论文分享会预告
08-08 1233
本文精选了美团技术团队被ACL2024收录的4篇论文进行解读，论文内容覆盖了训练成本优化、投机解码、代码生成优化、指令微调（IFT）等技术领域。这些论文是美团技术团队跟高校、科研机构合作的成果。希望能给从事相关研究工作的同学带来一些帮助或启发。
博客
KDD 2024 | 美团技术团队精选论文解读 & 论文分享会预告
07-25 717
ACM SIGKDD （Knowledge Discovery and Data Mining，简称 KDD）是数据挖掘领域的国际顶级会议。KDD Cup比赛是由SIGKDD主办的数据挖掘研究领域的国际顶级赛事，从1997年开始，每年举办一次，是目前数据挖掘领域最有影响力的赛事。本文精选了美团技术团队被 KDD 2024 收录的 5篇长文进行解读，覆盖了用户...
博客
即将启动｜第二届低空经济智能飞行管理挑战赛
07-25 344
比赛简介在深圳市科技创新局的指导下，深圳市美团机器人研究院与清华大学深圳国际研究生院联合举办第二届「低空经济智能飞行管理挑战赛」。比赛安排大赛围绕城市低空环境无人机运营核心问题：空地协同多机规划与调度，开设「性能赛」与「创意赛」两大赛道，面向全球高校开放，鼓励跨学科、跨院系组队参赛。大赛旨在让参赛者接触前沿技术，在比赛中学习、实践，最终为低空经济发展储备人才，并提升全社会对低空经济的了解和认知。我...
博客
基本功 | 一文讲清多线程和多线程同步
07-18 977
多线程编程是现代软件开发中的一项关键技术，在多线程编程中，开发者可以将复杂的任务分解为多个独立的线程，使其并行执行，从而充分利用多核处理器的优势。然而，多线程编程也带来了挑战，例如线程同步、死锁和竞态条件等问题。本篇文章将深入探讨多线程编程的基本概念（原子操作、CAS、Lock-free、内存屏障、伪共享、乱序执行等）、常见模式和最佳实践。通过具体的代码示例，...
博客
搜索广告召回技术在美团的实践
07-04 1167
本文首先介绍了美团搜索广告的三个阶段：多策略关键词挖掘、分层召回体系、生成式召回；然后重点介绍了生成式关键词召回、多模态生成式向量召回、生成式相关性判断在美团的实践。最后是一些经验分享及总结，希望能对大家有所帮助或启发。
博客
小程序可测性能力建设与实践
06-28 1279
本文整理自美团技术沙龙第77期《美团亿级流量系统的质量风险防控和稳定性治理实践》。作为一种终端产品生态，小程序在业界产品中占有非常重要的地位。本文从小程序的质量保障需求出发，分析小程序的测试难点，引出小程序可测性的基本概念，介绍美团到店研发平台针对小程序可测性改进的通用化方案。最后分享美团门票业务小程序测试工作的实践经验，本文旨在为读者在小程序质量保障领域提供一些有价值的见解和启示。
博客
小程序可测性能力建设与实践
06-27 821
总第593篇 |2024年第013篇本文整理自美团技术沙龙第77期《美团亿级流量系统的质量风险防控和稳定性治理实践》。作为一种终端产品生态，小程序在业界产品中占有非常重要的地位。本文从小程序的质量保障需求出发，分析小程序的测试难点，引出小程序可测性的基本概念，介绍美团到店研发平台针对小程序可测性改进的通用化方案。最后分享美团门票业务小程序测试工作的实践经验，本文旨在为读者在小程序质量保障领域提供...
博客
SIGIR 2024 | 美团技术团队精选论文解读 & 论文分享会预告
06-27 456
总第594篇 |2024年第014篇本文精选了美团技术团队被SIGIR2024收录的3篇论文进行解读，第一篇论文围绕如何利用深度学习，来整合广告拍卖和混排；第二篇论文扩展定义了全用户纵向联邦推荐范式，并首次提出基于检索增强的纵向联邦推荐框架ReFer，解决了跨域特征缺失问题；第三篇论文提出了一种新颖的框架——解耦对比超图学习，并应用于下一个兴趣点推荐任务中。这些论文有美团技术团队的独立产出，也...
博客
Spark向量化计算在美团生产环境的实践
06-21 6060
Apache Spark是一个优秀的计算引擎，广泛应用于数据工程、机器学习等领域。向量化执行技术在不升级硬件的情况下，既可获得资源节省和加速作业执行。Gluten+Velox解决方案为Spark换上了向量化执行引擎，本文将阐述美团在这一方向的实践和思考，希望对大家有所帮助或启发。
博客
CVPR 2024 | 美团技术团队精选论文解读 & 论文分享会预告
06-13 855
本文精选了美团技术团队被CVPR 2024收录的7篇论文进行解读，这些论文既包括OCR预训练、长尾半监督学习等基础学习范式升级，也包括图生视频、数字人驱动、视听分割（AVS）等视觉AIGC技术创新。这些论文有美团视觉智能部的独立产出，也有跟高校、科研机构合作的成果。希望能给从事相关研究工作的同学带来一些帮助或启发。CVPR 全称为 IEEE Conferenc...
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值