腾讯|5年磨一剑｜优酷Android包瘦身治理思路全解(11) VR|马晓轶|社交

是Android官方提供的无用资源裁剪功能，在apk构建时直接对无用资源进行删除。在app中除了通过http://R.xxx.xxx/0xffxxxxxx显式引用资源，还可以通过Resources.getIdentifier在参数中指定资源名称来引用，由于后者可以拼接甚至是动态下发字符串，因此会导致此类资源的引用关系无法被准确获取，对此ShrinkResources提供了两种模式：严格模式、正常（默认）模式。严格模式仅考虑显式引用关系，正常模式则会采用“安全优先原则” ，如果资源名称以任何java代码中的常量字符串为前缀，那么会被标记为疑似引用而无法得到删除，还有其它几种“疑似性标记逻辑”不再列举。【资源】多维度（备用）资源裁剪。 Android资源可以配置不同维度，从而在运行时灵活适配各种不同情况（语言、屏幕尺寸、屏幕横竖状态、os版本等），这里的多维度（备用）资源裁剪，就是在apk构建期将不需要的维度裁剪掉， AndroidGradlePlugin提供了对应功能，通过android DSL配置（resConfigs）[4
即可直接完成。自研代码一般只会包含需要用到的资源，而二、三方sdk为了提高兼容性会包含尽可能多的维度，在优酷实践中对语言维度进行了裁剪（仅保留中文），瘦身收益约3%（2MB）。【资源】图片压缩。图片压缩，是指在apk构建期批量对图片进行压缩，或者格式转换的一种瘦身技术。优酷自研turbo-plugin中包含了这项功能，在处理上的考量包括：提供配置项对压缩质量（quality）进行设置，这决定了压缩率（图片有损程度）；有些图片压缩后，尺寸反而会变大，通过检查压缩结果，当发现这种情况时对这些图片不使用压缩。在优酷实践中，图片压缩带来的瘦身收益约0.8MB ，收益较低的原因，主要是有很多模块中的图片，提前已经进行了压缩处理。【资源】resources.arsc压缩。 resources.arsc文件在Android原生构建流程中不会进行压缩，而运行时os识别到resources.arsc被压缩后，存在兼容逻辑对其进行解压处理，所以可以通过压缩resources.arsc来进一步降低包大小。需要注意的是， os在运行时解压缩resources.arsc会导致资源查找耗时增加，官方也不建议这么做，并且当apk的targetSdkVersion大于等于30时，无法在Android11[5
及以上设备中安装。【资源】去重。对于值相同的不同名资源仅保留一份，删除重复资源并将所有引用到的地方替换为保留下来的资源。和ShrinkResources一样，在应用这项技术时依然需要注意，通过Resources.getIdentifier以资源名称作为参数方式使用到的资源，不能进行去重处理。优酷曾经使用到了这项技术，瘦身收益在MB级别，现在已经通过对应的「单点瘦身」方案，在源码层面直接处理。【资源】混淆。和java代码Proguard混淆类似，是通过缩短资源名称以及文件类型资源存放路径，实现包瘦身的一种技术方案。 AndResGuard[6
是实现这项瘦身技术的一套开源框架，功能相对成熟且完备，后来也有些一些同类框架在基础的资源名称缩短之上，又进一步对resources.arsc、xml资源等进行了更精细化的瘦身处理，具体可以参考相关公开文章。在应用这项技术时，依然需要注意处理Resources.getIdentifier带来的问题。【so】debug信息裁剪。 debug信息裁剪，是指将so中携带的debug信息删除掉，这并不会影响so正常功能，只是会导致无法源码调试so 。在Android官方apk构建过程中，默认有一项StripDebugSymbol的处理逻辑，正是用于对debug信息进行裁剪，之所以作为一项整包瘦身技术放在这里，是因为如果构建环境中未包含NDK（或者NDK未在可识别路径），那么这项处理就不会执行，但是apk还可以正常生成，这一点需要特别注意。【so】abi分包。 abi（application binary interface）是指应用二进制接口，不同Android设备使用不同的CPU ，而不同CPU支持不同的指令集， CPU与指令集的每种组合都有专属的应用二进制接口 (ABI) 。在Android生态中arm CPU是绝对主流，指令集按支持的CPU（指令寻址）位数可分为32位（armeabi、armeabi-v7a）和64位（arm64-v8a）两大类， 32位设备只能运行32位的so ， 64位设备既可以运行32位so也可以运行64位so 。虽然目前市场中64位设备已经成为绝对主流，但32位设备也还没到可以舍弃的量级，因此apk如何同时支持64和32位设备就成了一道选择题：合包，即apk中同时包含32和64位两套so；分包，即分为32位和64位两个apk ，各自仅包含一套对应的so 。显然，后者可以极大减小包体积，但也会带来app分发的一些问题，需要辅以额外处理逻辑。对于分包方案，在apk构建时应该保障一次构建直接生成两个分包的方式，这样可以避免多次构建不一致带来的32位和64位包代码差异问题。【apk】7z压缩。 7z是一种压缩格式，同时也是一个压缩工具。这里的7z压缩是使用7z工具替代Android工具链，使用可以被Android系统所兼容的压缩算法，对apk中（本质就是一个zip文件）原本就会压缩的文件进行效果更好的压缩处理，从而实现瘦身的一种技术方案。由于并未改变apk元素内容值本身，因此基本无需验证即可稳定上线使用。在优酷的实践中，包大小降低约4%（3.5MB）。4.3 单点瘦身