特效侧用户体验优化实战 —— 包体积篇

发表于 2年以前 | 总阅读数：356 次

1 特效包体积之于抖音

1.1 一句话解释包体积是什么？

包体积主要指的是应用安装包大小的体积，比如 App Store 里的安装包显示的安装大小。

1.2 为什么要优化包体积？

随着应用的能力更新迭代，应用安装包体积将逐步增大，用户下载应用消耗流量产生资费进一步增长，用户下载意愿会相对下降；另一方面，随着包体积增大，安装应用的时间会相对变长，影响用户使用感受；对于ROM较小的低端手机，应用解压后内存占用更大，部分手机管家会提示内存不足提示卸载，直接影响用户使用。

1.3 特效侧在抖音里的包体积贡献

抖音目前由多条业务线组成，每条业务线都类似中台的角色，特效中台是抖音其中一环；目前，特效由 effect 和 lab 聚合为EffectSDK，作为一条独立业务线结算包体积在抖音中的占比。

1.4 特效侧的包体积组成

EffectSDK 的包体积由两方面组成：二进制文件(即可执行文件)、其他资源文件（图片、配置文件等）。二进制文件主要是由代码生成的可执行文件，资源文件指代的如内置的模型文件、素材文件、配置文件等。

作为中台，特效 EffectSDK 中二进制代码占用了绝大多数体积。与抖音、头条等应用做包体积优化思路不同，特效在资源压缩等部分能做得比较少；由于特效是作为中台对抖音进行业务支持，通过库的形式提供特效能力，在无用资源删除、无用代码去除、代码优化上有较大空间。因此，特效侧性能优化主要侧重于在支持多功能的基础上尽量减小包体积，提升代码质量，实现代码效率与代码体积的平衡。

2 包体积优化的背景知识

特效侧在抖音里的能力由 C++ 代码编写支撑，编译后生成静态库，最后链接至可执行文件中。从代码至二进制文件的过程中，由编译器为我们做好预处理、编译、汇编、链接等过程，最后 Android 端生成 ELF 格式文件，iOS 端生成 Mach-O 文件。ELF 格式的文件有四种，包括可重定位文件（Relocatable File）、可执行文件（Executable File）、共享目标文件（Shared Object File）、核心转储文件（Core Dump File），其中，共享目标文件，即 xxx.so 文件，包含可在两种上下文中链接的代码和数据，链接编辑器可以将它和其它可重定位文件和共享目标文件一起处理，生成另外一个目标文件；另外，动态链接器（Dynamic Linker）可能将它与某个可执行文件以及其它共享目标一起组合，创建进程映像。特效侧即以共享目标文件（libeffect.so）的形式做好抖音特效拍摄能力支撑。

由于ELF文件参与程序的链接与执行，通常有两种视图方式：一种是链接视图，一种是执行视图（下述左图）；编译器和链接器会按照链接视图，以节区（section）为单位，按节区头部表(section header table)形成节区的集合；加载器将按照执行视图，将文件以段（segment）为单位，按照程序头部表（program header table）将其视为段的集合。通常，可重定位文件（xxx.o）将包含节区头部表，可执行文件（xxx.exe）将包含程序头部表，共享目标文件（xxx.so）两者都包含。

下面是使用 binutils 工具查看 effect_sdk.so 中的 section 部分信息:

$ greadelf -h libeffect_sdk.so
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              DYN (Shared object file)
  Machine:                           AArch64
  Version:                           0x1
  Entry point address:               0x0
  Start of program headers:          64 (bytes into file)
  Start of section headers:          22954168 (bytes into file)
  Flags:                             0x0
  Size of this header:               64 (bytes)
  Size of program headers:           56 (bytes)
  Number of program headers:         8
  Size of section headers:           64 (bytes)
  Number of section headers:         29
  Section header string table index: 28
$ greadelf -S libeffect_sdk.so
There are 29 section headers, starting at offset 0x15e40b8:

Section Headers:
  [Nr] Name              Type             Address           Offset
       Size              EntSize          Flags  Link  Info  Align
  [ 0]                   NULL             0000000000000000  00000000
       0000000000000000  0000000000000000           0     0     0
  [ 1] .note.androi[...] NOTE             0000000000000200  00000200
       0000000000000098  0000000000000000   A       0     0     4
  [ 2] .note.gnu.bu[...] NOTE             0000000000000298  00000298
       0000000000000024  0000000000000000   A       0     0     4
  [ 3] .dynsym           DYNSYM           00000000000002c0  000002c0
       00000000000107e8  0000000000000018   A       4     1     8
  [ 4] .dynstr           STRTAB           0000000000010aa8  00010aa8
       000000000001b0f9  0000000000000000   A       0     0     1
  [ 5] .gnu.hash         GNU_HASH         000000000002bba8  0002bba8
       000000000000347c  0000000000000000   A       3     0     8
  [ 6] .hash             HASH             000000000002f028  0002f028
       0000000000004c18  0000000000000004   A       3     0     8
 ... ...
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
  L (link order), O (extra OS processing required), G (group), T (TLS),
  C (compressed), x (unknown), o (OS specific), E (exclude),
  p (processor specific)

通常每个节区（section）负责不同的功能，存储在不同的位置，节区的大小是代码编译后大小的反馈。说到底，特效侧最终的包体积由 section 和 headers 的大小共同决定。优化包体积，即是优化代码的编写效率、编译方式，减少各个节区的大小。

int gInitVar = 24;  //-- .data section
int gUninitedVar;  //-- .bss section 
void func(int i)
{
    printf("%d\n", i); //-- .text section
}
int main(void)
{
    static int sVar = 23; //-- .data section
    static int sVar1; //-- .bss section 
    int a = 1;
    int b;
    func(sVar + sVar1 + a + b); //-- .text section
    return 0;
}

3 包体积优化技巧

在了解了基础的包体积组成后，我们可以针对性的对编译选项、代码进行调整，以优化包体积。

iOS/Android 均可以通过优化编译选项来优化代码体积。整理了常用的一些。

3.1 编译优化

3.1.1 使用 Oz 替代 Os

编译选项
用-Oz替代-Os
示例：

set(CMAKE_CXX_FLAGS_RELEASE "${CMAKE_CXX_FLAGS_RELEASE} -Oz")

3.1.2 减小 unused code 的体积

编译选项
-ffunction-sections
把每个function放到自己的 COMDAT 段（COMDAT 段被多个目标文件所定义的辅助段。该段的作用是将在多个已编译模块中重复的代码和数据的逻辑块组合在一起。COMDAT 在 C++ 的虚函数表和模板的编译链接中，起着非常重要的作用。）
支持 Linux/OS X，不支持windows
-fdata-sections
为源文件中每个变量启用一个 elf section 的生成
示例：

set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -ffunction-sections -fdata-sections -fvisibility=hidden -g")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -ffunction-sections -fdata-sections -fvisibility=hidden -g")

链接选项
-Wl, --gc-sections（ Android 端)
当编译器选择用-ffunction-sections, -fdata-sections编译文件时，静态的库体积将增大，此时调用-Wl, --gc-sections，能消除dead段没有用到的code和data的体积。
-dead_strip（ iOS 端）
示例：

set(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} -Wl,--gc-sections")

3.1.3 开启链接优化

编译选项
-flto Oz
链接选项
-O3 -flto
lto为 link-time optimization ，在编译和链接时需要同时开启。编译时，会将各文件写入专有的 section ，再链接时将它俩视为同一单元进行转换和优化。但有个缺点，会在一定程度上拖慢编译速度
注意：lto编译时可以和-Oz共存，但链接时只能跟O1/O2/O3共存，无法和Oz/Os共存，如果同时开启了，将会报下面的错误：

$ clang -Os -fuse-ld=lld -flto test.c
ld.lld: error: -plugin-opt=Os: number expected, but got 's'
clang-9: error: linker command failed with exit code 1 (use -v to see invocation)
$ clang -Oz -fuse-ld=lld -flto test.c
ld.lld: error: -plugin-opt=Oz: number expected, but got 'z'
clang-9: error: linker command failed with exit code 1 (use -v to see invocation)

示例：

$ clang -Os -fuse-ld=lld -flto test.c
ld.lld: error: -plugin-opt=Os: number expected, but got 's'
clang-9: error: linker command failed with exit code 1 (use -v to see invocation)
$ clang -Oz -fuse-ld=lld -flto test.c
ld.lld: error: -plugin-opt=Oz: number expected, but got 'z'
clang-9: error: linker command failed with exit code 1 (use -v to see invocation)

set(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} -Wl, --gc-sections -fuse-ld=gold -Wl, --icf=safe -O2 -flto")
if (NOT DEFINED ENV{DISABLE_LTO})
    message(STATUS "DISABLE_LTO=$ENV{DISABLE_LTO} +++ LTO enabled")
    set(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} -fuse-ld=gold -Wl, --icf=safe -O2 -flto")
else()
    message(STATUS "DISABLE_LTO=$ENV{DISABLE_LTO} +++ LTO disabled")
endif()

3.1.4 关闭 exception 和 rtti

编译选项
-fno-exceptions
当开启-fno-rtti开关时，将禁用 rtti 机制，减小包体积。
-fno-rtti
当开启-fno-exceptions 开关时，将禁用 exception 机制，减小包体积。
上述两种属于比较激进的做法，同时也需要代码配合，但在能保障代码正确性和稳定性的情况下，也能较大幅度的优化包体积。目前特效侧已经尽量避免不必要的 rtti 和 exception 机制。
注意：缺少异常处理和 rtti ，需要 coder 能写出更高品质的代码。
-fno-excpetion需要配合一定的代码修改：

if(!running)
{
  // throw std::runtime_error("runtime error") // 不可用
  errCode = getRuntimeError();
  return errCode;
}

-fno-rtti也需要配合一定代码修改：

DerivedTarget &target = getTargetPtr();
// dynamic_cast<BasicTarget *>(target.get())->fun(); // 不可再用
static_cast<BasicTarget *>(target.get())->fun();

3.1.5 自动删除引入的静态库中的符号

链接选项
-Wl,--exclude-libs,ALL（Android端）
删除库"ALL"里自动导出的符号（这里ALL替换成不需要的库名，比如--exclude-libs lib,lib,...)
注意：iOS 不支持这个链接选项，因为 macOS 将--exclude-libs作为默认选项

（如果 iOS 要往库里引入符号，需要手动开启-reexport-l$(UR_LIB)选项）

if ("${CMAKE_BUILD_TYPE}" STREQUAL "Release" AND ANDROID)
    foreach(LIB ${LINK_LIB_LIST})
        set（CMAKE_SHARED_LINKER_FLAGS "{CMAKE_SHARED_LINKER_FLAGS} -Wl,--exclude-libs,lib{LIB}.a")
    endforeach()
endif()

目前特效在 Android 端均采用了这个选项。

3.1.6 减少符号表

-fvisibility=hidden
可隐藏符号的可见性，防止符号冲突，同时减小包体积。
注意：出错时上层可能无法第一时间定位问题

set（CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -ffunction-sections -fdata-sections -fvisibility=hidden -g")
set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -ffunction-sections -fdata-sections -fvisibility=hidden -g")

目前特效侧均使用-fvisibility=hidden

3.1.7 动态链接c++

动态链接 libstdc++ 库，避免增大库文件。

3.2 代码优化

一句话总结：代码量越少，包体积越小，从经验来看100行代码大概占用1~5K体积；超出这个行/体积比，代码肯定有问题。

3.2.1 不要有无效的判断逻辑( if...else... )

可以采用表驱动的方法实现 if else ，减少不必要的代码引用。

3.2.2 减少模板展开、宏展开

模板展开非常占据体积，尤其是对于同一种形式的代码，template 会扩充为多个不同的类。此时最好把公共的部分提取出来，声明为一个 static method。

如下面的绑定变量的方法：

    template <typename T>
    static void bindArgs(const Demo& d, T func)
    {
        auto m = createFun(func);
        m->mName = d.name
        for (auto i = 0; i < m->getArgc(); ++i)
        {
            if (i < d.args.size())
                m->mArgTypes[i].name = d.args[i];
        }
    }

    template <typename T>
    static void bindArgs(const Demo& d, T func, const Var& arg1)
    {
        auto m = createFun(func);
        if (!m)
            return;
        m->mValues.push_back(arg1);
        for (auto i = 0; i < m->getArgc(); ++i)
        {
            if (i < d.args.size())
                m->mArgTypes[i].name = d.args[i];
        }
    }

    // static void bindArgs(const Demo& d, T func, const Var& arg1, const Var& arg2)
    // {

可修改为：

// bindArgs 提取出来
static void bindArgs(const Demo& d, Fun* m)
{
    for (auto i = 0; i < m->getArgc(); ++i)
    {
        if (i < d.args.size())
            m->mArgTypes[i].name = d.args[i];
    }
}

template <typename T>
static void bindArgs(const Demo& d, T func)
{
    auto m = createFun(func);
    m->mName = d.name;
    bindArgs(d, m);
}

template <typename T>
static void bindArgs(const Demo& d, T func, const Var& arg1)
{
    auto m = createFun(func);
    if (!m)
        return;
    m->mValues.push_back(arg1);
    bindArgs(d, m);
}

3.2.3 避免不必要的 stl/std 使用

比如，部分回调可以使用函数指针：std::function <>作为一个 class ，它的体积成本必然比 void * fun 这样一个函数指针要来的高；

// using FunInstantiate = std::function<FunInterface*()>; // 不再使用
using FunInstantiate = FunInterface*(*)();

比如，常量字符串引用时可以采用 const char* 类型，避免编译器调用隐式拷贝构造；

// void DemoClass::fun(const std::string &name, const DemoPtr &demoPtr) // 不再使用
void DemoClass::fun(const char* name, const DmoePtr &demoPtr)
{
    //...
}

3.2.4 头文件不要出现 const、static 变量的定义

头文件中 const / static 型的变量，会被引入至对应的 cpp 文件，相当于每一份.o 都引入了一长串常量字符串。

3.2.5 不要出现大的数组

大的数组会占用数组大小的体积。

3.2.6 减少不必要的虚基类/虚函数

    // class Child : virtual public Parent // 不再使用
    class Child : public Parent
    {
        //...
    }

4 包体积监测工具

4.1 为什么要做包体积监测工具

抖音每个版本都会有非常多的新能力更新换代，每次更新每个需求均会导致包体积的变更。为了能更好的监测包体积的变化、确认包体积增长的原因，提升 ROI ，引入包体积监测工具，更直观的确认包体积增长原因，拦截异常增长，输出每个每个需求带来的包体积增长大小、包体积增长原因，及时给出包体积告警、定位异常增量 case ，减缓包体积增长，推动业务优化。

4.2 如何进行包体积监测

特效侧目前使用的包体积监测工具来源于 google 的开源二进制文件体积分析工具 bloaty ，用于分析二进制文件(xxx.exe, xxx.bin)、共享目标文件(xxx.so)、对象文件(xxx.o)和静态库(xxx.a)，支持ELF\Mach-O\WebAssembly 格式。它能梳理出文件中各部分的体积组成，拆分出各个 section 大小，结合symbol信息，反推出各方法、源文件的包体积大小。

以特效侧 libeffect_sdk.so 为例，对 .so 文件进行组件单元、源文件分析，截取部分输出结果：

FILE SIZE   
 -------------- 
  10.3%  2.25Mi    [section .rela.dyn]
   7.2%  1.58Mi    [section .rodata]
   7.2%  1.57Mi    Bindings.cpp
   3.9%   877Ki    [section .data.rel.ro]
   2.0%   445Ki    [section .text]
   1.9%   418Ki    [section .gcc_except_table]
   1.0%   213Ki    base/EffectManager.cpp
   0.7%   149Ki    bef_info_sticker_api.cpp
   0.6%   140Ki    base/RenderManager.cpp
   0.6%   138Ki    Runtime/Engine/Foundation/Bindings.cpp
   ...

利用上述工具，即可较为清晰的定位各文件带来的包体积增长。

4.2.1 包体积监控工具工作流程

包体积监测工具是当前特效需求上车前必过的一环。所有需求在 MR（merge request）提出、CI 打包完成后都会经过包体积的检查，仅包体积增量符合预期的需求允许跟版合入，所有包体积增量与需求一一对应，记录在案。

4.2.2 包体积监测工具的分析能力

包体积分析工具支持单个文件分析和版本迭代对比分析。

对于单文件分析，由于特效侧主要通过 .so 文件进行交付，在每个 MR 打包完成后，工具将自动获取对应的 .so 文件和 .so.symbol 文件后，对库文件的包体积组成、包体积来源进行分析，输出所有方法函数、节区（section）、编译单元（xxx.cpp）带来的包体积大小，确认大小后通过关键字匹配确认包体积的增量来源模块，给出最后的各模块单元、编译单元的包体积 profile 。

另一方面，由于特效侧能力总是通过需求更新迭代的，每次有实质性的需求提交时，将会对比上一版本与当前版本的包体积差异，做好每个版本需求带来的增量来源记录。当版本比对结果带来的增量超过预期值时，将调起通讯 api ，将包体积超标信息发出进行报警。

4.2.3 包体积数据记录本

所有需求的包体积增量将记录在包体积记录本中：当服务收到需求事件时，将调用 bits/meego 接口，请求需求信息和包大小预设 exp_pack_size 增量写入 mr_pkg_size 表；等到本地出包完成后，实际的包大小增量 real_pack_size 将被记录入 mr_pkg_size 表，并将预期值与实际增量进行对比。

最终，所有的包体积增量与历史的需求增量来源被记录在案，并通过表查询接口，在网页端可根据需求名 / 时间段 / 分支名 / commit id 等条件按图索骥，确认包体积增长来源。