文章详情

短信预约-IT技能 免费直播动态提醒

请输入下面的图形验证码

提交验证

短信预约提醒成功

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

2024-12-01 16:39

关注

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

编译选项

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

3.1.2 减小 unused code 的体积

链接选项

示例:

3.1.3 开启链接优化

编译选项

链接选项

示例:

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 
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
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
static void bindArgs(const Demo& d, T func)
{
auto m = createFun(func);
m->mName = d.name;
bindArgs(d, m);
}

template
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; // 不再使用
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 总结

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

来源:字节跳动技术团队内容投诉

免责声明:

① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。

② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341

软考中级精品资料免费领

  • 2024年上半年信息系统项目管理师第二批次真题及答案解析(完整版)

    难度     813人已做
    查看
  • 【考后总结】2024年5月26日信息系统项目管理师第2批次考情分析

    难度     354人已做
    查看
  • 【考后总结】2024年5月25日信息系统项目管理师第1批次考情分析

    难度     318人已做
    查看
  • 2024年上半年软考高项第一、二批次真题考点汇总(完整版)

    难度     435人已做
    查看
  • 2024年上半年系统架构设计师考试综合知识真题

    难度     224人已做
    查看

相关文章

发现更多好内容

猜你喜欢

AI推送时光机
位置:首页-资讯-后端开发
咦!没有更多了?去看看其它编程学习网 内容吧
首页课程
资料下载
问答资讯