百度账号名称怎么修改不了(百度账号名字如何修改)

前言

目前,安卓端对于包体积的优化方案已经多如过江之鲫,我们系列的上一篇文章介绍了 Class 字节码的优化,本期我们将关注点聚焦到资源文件上,从资源二进制文件的全新角度,拓展出包体积优化的新思路。

在资源文件优化方面,通常的优化手段多集中在图片/文件压缩、资源文件名称混淆、离线下载资源文件等方面,而我们的新思路基于对于常规思路的深度分析及思考。

一开始,我们是从资源文件名称混淆入手优化,业界对于资源文件名称混淆方案,最为熟知的开源项目当属 AndResGuard,该项目优化目标为资源文件目录 res 内的文件,其优化点如下:

  1. 对重复的资源文件,以计算 md5 值的方式来判断是否重复并只保留一份;
  2. 对资源文件名称进行缩短,即名称混淆;
  3. APK 中的内容采取 7zip 压缩优化;

按照此项目进行优化,总体收益可以达到非常可观的 MB 级别。但完成此项目的优化后,资源文件的进一步优化便达到瓶颈。

为了在此基础上更好的实现优化资源大小,我们需要了解资源文件目录 res 所包含的文件类型及其大小的分布情况。以抖音为例,下表是对其包含的子文件夹名称、文件数量、将文件夹 zip 压缩后大小的梳理,以文件数量降序排序:

百度账号名称怎么修改不了(百度账号名字如何修改)

从上表,可以看到:

  • drawable-xxhdpi-v4 目录下文件数量最多有 6000+,压缩后文件大小约为 19.5MB。
  • drawable 目录下文件数量排第三,有 4388 个,压缩后 4.6MB,同时包含图片和.xml 文件。
  • 文件数量排第二和第四的都是 layout 目录下的布局文件,分别有 5970,2985 个,其文件夹压缩后大小分别为 12.2MB,8.5MB。布局文件总数近 9K,文件大小约 20.7MB

可见,layout 目录下的布局文件大小已经和图片文件不相上下。而这部分如此大的文件,除了有文件名称的混淆优化之外,是否还有其他优化方式?或者其文件名称混淆是否彻底?

此外,APK 解压后的 resources.arsc 文件有 7.3MB 之大。其中包含了 app 所有资源文件名称和资源字符串值,其中是否也存在冗余字符串?

对于 layout 布局文件,从近万份之多的文件数量及 20+MB 的文件体积来看,即存在值得探究的必要。我们通过对资源文件的二进制文件格式的解析,并从文件内容被使用的角度分析,发现存在可以删除的冗余内容。在反复尝试并解决了各种稳定性和打包兼容问题后,最终研发出了一套针对 Android ARSC/XML 文件格式的包体积优化方案,目前已经落地抖音,实现 2MB 以上的收益。

接下来,本文将深入讲解该方案的实现细节。

APK 资源格式优化

我们的核心思路是,以资源路径缩短为优化出发点,在最终的 APK 文件里,从resources.arsc与 layout 布局文件的二进制文件格式着手,查看其内容结构,寻找可以删除的未使用字符串,优化文件名称或者文件里的字符串池。主要分为下面两个优化点。

资源路径缩短

资源格式修改

接入 AndResGuard 后,资源文件 res 目录 -> r,其中的子文件夹和文件名也都被混淆,即:

  • res/anim/abc_fade_in.xml -> r/a/a.xml

这是为了减少资源文件路径,从而减少包体积,自然联想到,是否还能进一步减少资源文件路径呢?显然,如果能将所有文件都放在 r 目录下,将中间的子文件夹去掉,则可以进一步减少资源文件路径和 zip 节点数量,一定还有包体收益;顺便可以将文件名的后缀去掉,也可以减少文件路径,即:

  • r/a/a.xml -> r/a
  • r/a/b.png -> r/b
百度账号名称怎么修改不了(百度账号名字如何修改)

由于修改资源文件名称需要修改resources.arsc文件,这里对resources.arsc 的文件格式分析下:

百度账号名称怎么修改不了(百度账号名字如何修改)

可以看到,其中包含有 3 个字符串池。

假如我们有一个资源文件abc_fade_in.xmlres/anim 目录下,其在resources.arsc文件中 3 个字符串池里的信息如下:

  • 全局字符串池(字符串池 1):主要包含完整文件路径名,即res/anim/abc_fade_in.xml
  • 类型字符串池(字符串池 2):资源种类名(包括存储 res 目录下子文件目录名),即anim
  • 键字符串池(字符串池 3):文件名,即: abc_fade_in

可以看到,与资源文件名相关的地方有两处,分别在全局字符串池保存着完整文件路径名,键字符串池保存着文件名,为了将资源路径缩短,需要同时修改这两处,即在全局字符串池中修改res/anim/abc_fade_in.xml -> r/f ,在键字符串池修改 abc_fade_in -> f。在resources.arsc文件中需要修改的两处字符串池,如下图箭头所示:

百度账号名称怎么修改不了(百度账号名字如何修改)

然而,在完成资源路径缩短后,却发现包体积反而变大了 160K+

键常量池裁剪

我们知道,文件名称混淆,其混淆名称来源于符合文件名称规范的混淆字符串集合,其中的字符串都是唯一不重合的,所以,字符串集合数量越大,其最长字符串的长度也会越大。

在资源路径未缩短情况,不同子目录文件夹下,其使用的文件名称每次都可以从混淆字符串集合中重新选取,使得其名称在键字符串池中始终保持最短;

百度账号名称怎么修改不了(百度账号名字如何修改)

其对应的文件名字符串集合为:[a,b,c,d,e]

而在缩短的情况下,由于所有文件都包含在一个文件夹r下,其使用的文件名称只能来自同一个混淆字符串集合,使其名称在键字符串池中会逐渐变长,同时也会使得路径字符串跟着变长,导致其整体结果反而变大!如下图所示:

百度账号名称怎么修改不了(百度账号名字如何修改)

其对应的文件名字符串集合为:[a,b,c,d,e,f,g,h,i,j]

因此,当所有文件都包含在一个文件夹r下时,无法使得不同子目录下的文件名得以复用,所以虽然路径缩短,会使得全局字符串池变小,但键字符串池反而会变大。这是因为键名默认需要和文件名保持一致。

猜想Resources.arsc文件中,键名是否需要和文件名保持一致,更或者,键名本身是否有存在的必要?

其实,在经过编译后,资源文件被使用的地方会被替换成特定的 id 值,比如:

public class MainActivity extends AppCompatActivity {
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        // => setContentView(0x7f0b001c); // 替换为id值
    }
}

由此可知,资源文件名称必然与整型 id 值有着一一对应的关系,这种一一映射的关系可以联想到:是否只需要根据整型 id 值,就可以找到相应的文件路径名称?因为这个过程里完全不涉及键字符串的引用。

基于这个想法,我们将键字符串池全部替换为单一值"_", 发现 APK 运行正常。显然,去掉键字符串池,似乎并不会影响 APK 运行期间根据整型 id 值去查找文件路径

那么,键字符串池中的字符串的作用是什么呢?翻看源码发现,只有使用类似“资源文件反射”的方式调用,才会获取键字符串池中的字符串值,比如:

// MainActivity.java
// 此处返回值为"_", 因为键字符串池已经全部替换为 "_"
String entryName = getResources().getResourceEntryName(R.layout.activity_main);
// 此处返回的id值为0, 因为找不到名为 "abc_fade_in",类型为"anim"的资源
int id = getResources().getIdentifier("abc_fade_in", "anim", "cn.pkg");

当前项目中,一般没有使用上述“资源文件反射”获取资源名称的使用方式,所以键字符串池可以全部替换为单一值"_";目前已知的必须要以这种方式使用资源文件的方式,大多是插件等不在一个宿主项目下的情况,如果需要,可以对这部分字符串名称进行保留,配置白名单即可。

下图是resources.arsc文件中键字符串池的格式和内容示意图:

百度账号名称怎么修改不了(百度账号名字如何修改)

  • 偏移数组(标记 1),数组的值为指向键字符串池(标记 2)中每个字符串的偏移值
  • 由于需要将键字符串池中所有字符串替换为单一值"_",那么,键字符串池中就只有一个"_"字符串,偏移数组也将只有一个元素,其指向键字符串池中"_"字符串的起始偏移值 0。

最后,还需将resources.arsc文件中,键字符串对应的偏移数组的索引值,所有被调用的地方,全部替换为字符串"_"对应的偏移数组的索引值 0,这样原有文件名字符串都会换为"_",键字符串池就只剩"_"字符串了。

崩溃和兼容性问题

在项目具体实施灰度中出现了崩溃,发现在 drawable 目录下的 xml 图片文件有对其后缀的检查,如下图:

frameworks/base/core/java/android/content/res/ResourcesImpl.java

//创建drawable
private Drawable loadDrawableForCookie(@NonNull Resources wrapper, @NonNull TypedValue value, int id, int density) {
    ...
    if (file.endsWith(".xml")) { //对xml文件解析并创建drawable
        final String TypeName = getResourceTypeName(id);
        if (typeName != null && typeName.equals("color")) {
            dr = loadColorOrXmlDrawable(wrapper, value, id, density, file);
        } else {
            dr = loadXmlDrawable(wrapper, value, id, density, file);
        }
    } else { //对.png等其他图片解析并创建drawable
        final InputStream is = mAssets.openNonAsset(value.assetCookie, file, AssetManager.ACCESS_STREAMING);
        final AssetInputStream ais = (AssetInputStream) is;
        dr = decodeImageDrawable(ais, wrapper, value);
    }
    ...
}

因此,我们对 drawable 目录下的 .xml 后缀不做去除。

上线后,有反馈 6.x 上部分手机启动慢的现象,经排查发现是其中图片文件名称后缀删除优化,导致的在部分 rom 上 app 启动慢。排除掉这些兼容性问题,最后,我们仅保留路径缩短和键常量池裁剪优化,而不做文件名后缀去除,即:r/a/a.xml -> r/a.xml,此部分资源路径压缩优化收益 300K+。

layout 优化

我们知道,layout 目录下的布局文件所占包体积很大,从之前的分析可知,resources.arsc文件中有好几个字符串池,有的字符串池并没使用可以删除,而 layout 布局文件与resources.arsc文件的二进制文件格式一致,其中也有字符串池,是否也存在类似的优化点呢?对此,有必要对布局文件的文件格式和内容探究一波,随意打开一个布局文件,其源代码和二进制文件格式内容如下:

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:enabled="true"
    android:gravity="center"
    android:background="@color/colorAccent"
    android:layout_width="match_parent"
    android:layout_height="match_parent"/>
百度账号名称怎么修改不了(百度账号名字如何修改)

从布局文件文件格式上,可以看到,布局文件有一个字符串池 strPool 和一个数组 resMap,为了阐述其作用,假如布局文件中有一个属性"layout_width",其在布局文件中包含的信息如下:

  • 字符串偏移数组(标记 1),指向字符串池(标记 2),用于从字符串池中获取标签(如:"LinearLayout")或属性字符串(如:"layout_width")
  • 字符串池(标记 2),布局文件中的唯一字符串池,保存布局文件中标签或属性字符串名,即:"layout_width"
  • 属性数组Resids(标记 3),包含当前文件所有属性的整型 id 值,属性"layout_width"的 id 值:10100F4h。从数组中整型 id 值提示的属性名(类似:attr_layout_width(10100F4h)),可以看到其属性名与字符串池中名称一一对应。

我们知道 layout_width 本身是一个attr属性,查看系统源码中的 public.xml,可以看到:

百度账号名称怎么修改不了(百度账号名字如何修改)

其整型 id 值与上面 layout 文件中的值,即 attr_layout_width 后面的整型 id 值完全一致,都是0x010100f4。系统属性的 id 值是固定的,而且,一个布局文件的属性由字符串名称或整型 id 值来唯一标识,那么,这里是否只需要 id 就可以标识属性,而属性的字符串名可以删除?

猜想:每个属性都有字符串名和整型 id 值,为了性能,在解析布局文件中每个节点的属性时,是根据整型 id 值而不是字符串名来唯一标识,并据此拿到该属性的值即可。

为了验证我们的猜想,简单修改字符串池中的一个属性字符串:layout_width -> llyout_width,验证可以运行成功。由前面的叙述可知 layout 目录下文件有近 9K 个,影响范围很广,如果可行其收益预计会很大,同时也更需要谨慎。

通过翻看源码发现,每个属性(attr)包含一个对应的整型 id 值,在parseXml()解析布局文件得到标签后,获取其属性值时果然会直接根据整型 id 值来获取。这里属于比较底层的代码,因为与性能相关,一般 rom 厂商似乎不会改到这里,其兼容性可能不会受影响。

源码中解析布局文件,标识属性并获取属性值的代码如下:

frameworks/base/core/jni/android_util_AssetManager.cpp

// 通过属性整型id值获取属性值
static jboolean android_content_AssetManager_applyStyle(...) {
    ...
    while (ix < NX && curIdent > curXmlAttr) {
        ix++;
        curXmlAttr = xmlParser->getAttributeNameResID(ix); //获取属性id值
    }
    if (ix < NX && curIdent == curXmlAttr) { //通过id值来标识属性
        block = kXmlBlock;
        xmlParser->getAttributeValue(ix, &value); //获取属性值
        ...
    }
    ...
}
uint32_t ResXMLParser::getAttributeNameResID(size_t idx) const {
    int32_t id = getAttributeNameID(idx);
    // mTree.mResIds 就是 Resids数组;返回值即属性id值
    if (id >= 0 && (size_t)id < mTree.mNumResIds) {
        return dtohl(mTree.mResIds[id]);
    }
    return 0;
}

具体实现上,该思路一共有三个要点,总体收益 1.9MB+ ,详见如下分析。

属性字符串名称修改

首先,我们将所有能与 Resids 数组一一对应的字符串全部替换为""字符串,对所有 layout 目录下的文件进行处理,得到收益 1.1MB+

将此优化进行推广,对资源目录 res 下所有以 “.xml” 后缀的文件进行优化,得到附加收益 180K+。这部分收益不大的原因是其他目录下的“.xml” 后缀文件,多为 drawable 或者 anim 目录下的文件,这类文件中 Resids数组没有或者包含的属性不太多。

偏移数组修改

观察 layout 目录下布局文件中字符串池格式,发现包含偏移数组和字符串池,其中,每个节点从字符串池中读取字符串是根据偏移数组获取。所以,这里可以只修改偏移数组,将其指向同一个字符串值,从而将空字符串合并为一个,减少字符串池,节省空间,如下图:

百度账号名称怎么修改不了(百度账号名字如何修改)

上图中,左图,是将与 Resids 数组一一对应的字符串全部替换为""字符串了,其偏移数组会指向 5 个""字符串;右图,是修改偏移数组,将其值修改为指向第一个""字符串,同时删除冗余的 4 个""字符串,此方案得到收益 300K+。

命名空间去除

在解析布局文件获取属性值的时候,我们发现属性的命名空间字符串很长,例如:"http://schemas.android.com/apk/res/android"。而且每个布局文件都至少存在一个命名空间字符串,其出现相当频繁。我们猜想,在获取属性值时,是否也没解析属性的命名空间字符串呢?而在前面我们说过,属性值的获取只需要属性id值来标识,没用到命名空间字符串。将命名空间字符串替换为空串后,发现的确没有问题,此优化得到收益500K+。

最终优化形式如下:

百度账号名称怎么修改不了(百度账号名字如何修改)

标记 1–属性字符串名称裁剪,将字符串池中每一个字符串替换成""空字符串;

标记 2–偏移数组修改,将字符串池中所有""空字符串合并为一个;

标记 3–命名空间去除,将字符串池中命名空间字符串替换成""空串。

App Bundle 兼容

以上优化都属于通用方案,都能在国内 App 上接入使用。然而,目前在海外 Google Play 商店上,App 均采用的是 App Bundle 文件格式(即 AAB),其中resources.arsc文件和 layout 目录下布局文件的格式已和上述格式不同,谷歌在其之前二进制文件格式的基础上,使用了 protobuf 格式,以增强对该文件格式中内容的可扩展性和鲁棒性。

在 AAB 文件 split 成多个 APK 的时候,会有 protobuf 格式到二进制 xml 格式的转换,而这个转换过程在 Google Play 上,我们无法更改。所以只能针对 AAB 文件格式中的资源文件格式进行优化了,通过 App Bundle 解析布局文件中的属性并不复杂,这里不再详述,针对上述优化方案在 AAB 文件上的移植结果如下:

资源路径缩短:

  • 无法实现,因为resources.arsc文件中常量池裁剪无法实现, 即全部替换为同一个字符串"_"会转换失败,原因在于执行 protobuf 格式到二进制 xml 格式的转换中,会判断当前的键字符串是否重复,如果是,那么会直接返回,无法解析通过。

frameworks/base/tools/aapt2/format/proto/ProtoDeserialize.cpp

//读取protobuf格式的资源文件
static bool DeserializePackageFromPb(...) {
    ...
    for (const pb::ConfigValue& pb_config_value : pb_entry.config_value()) {
        ...
        //FindOrCreateValue搜寻已存在的或者创建新的ResourceConfigValue,搜寻时会判断键字符串是否已存在
        ResourceConfigValue* config_value = entry->FindOrCreateValue(config, pb_config.product());
        if (config_value->value != nullptr) {//发现已存在config_value,返回错误
          *out_error = "duplicate configuration in resource table";
          return false;
        }
        ...
    }
    ...
}

layout 优化:

  • 属性字符串名称裁剪:可以实现,取得收益 400K+;
  • 偏移数组修改:无法实现,因为最后转换 protobuf 格式到二进制 xml 格式,这一步是在 Google Play 本地的 aapt2 命令环境中实现,无法修改;
  • 命名空间去除:可以实现,取得收益 200K+

因此,我们的优化方案最终在某海外 App 上总体可以取得 600K+收益。在完成对 AAB 文件的优化后,通过 split 后获取其中的 base-master.apk,查看其中的 layout 布局文件,收益示意图如下:

百度账号名称怎么修改不了(百度账号名字如何修改)

标记 1–属性字符串名称裁剪命名空间去除已优化;

标记 2–偏移数组修改,无法优化,因此还是存在多个""字符串,而不像 APK 里面可以合并为一个。

总结

可见,在资源文件优化方面,还是可以另辟蹊径,有不少通用优化可以做,总结起来,主要工作还是在对无用字符串的搜寻和确认上。通常,编译后的二进制文件中,字符串的作用有:

  • 代码执行需要。这类字符串是必须的,但可以考虑是否可以精简,即混淆;
  • 调试辅助功能。这类字符串不一定必须,可以去除,如果需要保留,可以做相应的 keep 功能;
  • 文件格式设计者当初为了格式完备性引入,已拓展后续功能。这类字符串可能是与性能相违背的,如未使用可以直接去除;

后两个点便是搜寻冗余字符串和优化包大小的重点方向。

优化收益落地

百度账号名称怎么修改不了(百度账号名字如何修改)

创业项目群,学习操作 18个小项目,添加 微信:80709525  备注:小项目

本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至 sumchina520@foxmail.com 举报,一经查实,本站将立刻删除。
如若转载,请注明出处:https://www.dasum.com/19352.html