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

357次阅读  |  发布于2年以前

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

3.1.2 减小 unused code 的体积

3.1.3 开启链接优化

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

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

（如果 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 减少符号表

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 等条件按图索骥，确认包体积增长来源。

5 总结

经过上述代码体积优化积累、实时体积监控、需求增量落实到人三位一体，控制特效侧包体积有序增长，提升代码效能。

Copyright© 2013-2020

All Rights Reserved 京ICP备2023019179号-8