怎样优化今日头条IOS安装包

前言

今日头条 iOS 端从 2016 年起就关注到了安装包大小的问题,并启动了包大小优化。2017 年,我们将当时的经验发表为技术文章 《干货|今日头条iOS端安装包大小优化—思路与实践》[1]。

如今三年过去了。今日头条在继续探索包大小优化时实践了更多思路,包括构建配置、图片压缩、__TEXT 段迁移、二进制段压缩等。这些优化项在业务入侵较少的前提下给今日头条带来了显著的包大小收益。同时,整个业界在包大小优化上也产出了更多方案。因此我们更新文章,期待与大家共同交流包大小优化这件事。

表格:今日头条落地的优化项和收益一览

一、安装包的构成

当我们通过构建,获得了一个经过了 App Slicing 后的 ipa 文件后,将其用 zip 解压缩方式解压,进入 .app 文件后,我们就可以直观地看到安装包中的内容。

一个安装包,往往包含资源与 iOS 上的可执行文件 Mach-O 文件两部分,资源又可以分为 Asset Catalog 的构建产物 Assets.car 文件和其他资源。其中 Assets.car 文件和 Mach-O 文件,是我们投入较多精力优化的部分。

1.1、Assets.car 文件

Assets.car 文件是工程中 Asset Catalog 的构建产物。Xcode 工具链中的 actool 负责构建 Assets.car。在构建 Assets.car 的过程中,actool 会按照一定策略选取编码算法,对其中的 png 图片重新编码。

图:Asset Catalog

1.2、Mach-O 文件

Mach-O 文件是 iOS 上的可执行文件,它是由代码源文件经过编译和静态链接获得。经过 App Slicing 之后的 Mach-O 文件往往仅包含单个架构。使用 MachOView 等工具,我们可以直观了解 Mach-O 中包含的内容。

同时,Link Map 文件能更进一步帮助我们分析 Mach-O 文件的构成。

在 Build Settings 中打开 LD_GENERATE_MAP_FILE 开关,构建 App 的过程中就会生成一个名叫 Link Map 的 txt 文件,它能展示每个段、每个节、每个函数在 Mach-O 中的分布和大小。这些信息是包大小优化中经常使用的。

二、资源大小优化

“压缩资源”往往是最容易被联想到的包大小优化方案,但实际操作起来,却也包含技巧。今日头条在资源优化上做了诸多尝试。

2.1、使用合适的资源压缩配置

今日头条目前最低支持的 iOS 系统版本为 iOS 9。然而,大部分 Pod 库的 Podspec 文件中指定的deployment_target(最低支持版本)由于未及时修改,依然还是 iOS 8,这就导致了这些 Pod 库中指定的 resource_bundles 在构建出 Assets.car 时,是以 iOS 8 为最低支持版本的。

我们通过实验发现:

1、将 Pod 库和主工程的最低支持版本从 iOS 8.0 提升成 iOS 9.0

2、开启 Pod 库和主工程 Xcode Build Settings 中的 ASSETCATALOG_COMPILER_OPTIMIZATION space 选项

这两项设置可以改变 actool 构建 Assets.car 时选取的编码压缩算法,减小包大小。我们可以使用 xcrun assetutil --info Assets.car 命令检查 Assets.car 中每张图片使用的编码压缩算法。在今日头条环境下,整理的结果如下:

由于 Assets.car 中 png 图片的编码压缩算法得到了改变,这两项配置在今日头条落地时获得了 2.31MB 的包大小收益。

2.2、使用 RGB with palette 压缩图片

在今日头条投入包大小优化的早期,我们曾尝试对 Asset Catalog 中的 png 图片做无损压缩,但实践后发现,虽然放入 Asset Catalog 的图片大小有了明显减小,但是构建的产物的大小却几乎没有变化。

经过探究,我们发现,Xcode 中,构建 Asset Catalog 的工具 actool 会首先对 Asset Catalog 中的 png 图片进行解码,得到 Bitmap 数据,然后再运用 actool 的编码压缩算法进行编码压缩处理。无损压缩通过变换图片的编码压缩算法减少大小,但是不会改变 Bitmap 数据。对于 actool 来说,它接收的输入没有改变,所以无损压缩无法优化 Assets.car 的大小。

那是否有其他的压缩方式能优化 Assets.car 的大小呢?我们猜测对图片做合适的有损压缩是一个思路。

于是我们尝试了 RGB with palette 编码方式[2]。RGB with palette 编码的得到的字节流首先维护了一个颜色数组。颜色数组每个成员用 RGBA 四个分量维护一个颜色。图像中的每个像素点则存储颜色数组的下标代表该点的颜色。颜色数组维护的颜色种类和数量由图片决定,同时可以人为的限制颜色数组维护颜色的种类的上限,默认为最大值 256 种。这种编码方式正如它的名字:palette(调色板)。

App 中大部分图片虽然使用了很多种类的颜色,但这些颜色中大多数都非常接近,从视觉上很难分辨,比如大量扁平风格的 icon。这种类型的图片非常适合用 palette 编码且减少颜色数组大小的方式来进行有损压缩,既能减少颜色数量实现有损压缩,也能保证保留的颜色贴近原始图片,使得经过有损压缩后的也看起来质量无损。我们在今日头条上落地,获得了 3.15MB 包大小收益。

在具体执行中,我们使用了 ImageOptim 工具改变图片的编码方式为 RGB with palette :

imageoptim -Q --no-imageoptim --imagealpha --number-of-colors 16 --quality 40-80 ./1.png

其中 --number-of-colors  控制颜色数组维护颜色的数量;--quality  控制图片的质量变为原来的百分比。我们的经验表明,当 --number-of-colors  从 16 开始向上调整,--quality 维持 40-80,能够在显著减少包大小的同时维持肉眼看不到的质量变化。经过 UI 同学的像素眼审查,确认优化前后的图片看起来无差别。

 2.3、Assets.car 合并

今日头条使用 CocoaPods 进行组件集成,各个组件携带的 Asset Catalog 文件以 Podspec 中 resource_bundles 的方式引入,最终会以 Bundle 下的 Assets.car 文件的形式体现在安装包内。

以 7.9.4 版本为例,安装包内有 106 个 Bundle 包含 Assets.car 文件:

Assets.car 文件本质上是 BOM 文件,同时,Xcode 在使用 actool 构建 Assets.car 文件时,也会自带一些优化操作,比如:将若干张小图片自动合并为一张 Packed Image。因此,将若干个 Assets.car 合并,可以减少重复的 BOM Block,也可以最大化享受到 actool 自带的优化效果。

在构建的过程中,今日头条通过在 Build Phases 中加入脚本,将多个库中 Asset Catalog 中的图片合并到一个 Asset Catalog 中,再经 actool 构建成 Assets.car 产物。这一优化产生了 2.1MB 的包大小收益。同时,从理论上分析,这一优化也可以减少运行时 Assets.car 的解析操作,对图片读取的响应耗时有正向收益。

2.4、文本文件压缩

除了占比最大的图片资源,今日头条安装包内还有不少文本文件资源,如 JSON 文件、HTML 文件等。这些文本文件的压缩也能带来包大小优化效果。

今日头条落地的文本文件压缩方案由三部分组成:

1、压缩阶段:在 Build Phase 中添加脚本,构建期间对白名单内的文本文件做 zip 压缩;

2、解压阶段:在 App 启动阶段,在异步线程中进行解压操作,将解压产物存放到沙盒中;

3、读取阶段:在 App 运行时,hook 读取这些文件的方法,将读取路径从 Bundle 改为沙盒中的对应路径;

这一方案能在业务入侵较少的前提下完成压缩优化。我们首先将这一方案应用在了 Lottie 动画的 JSON 文件上,产生了 400KB 的包大小收益。后续这一方案也可以进一步拓展,应用在更多类型的文件上。

三、Mach-O 文件优化

在资源优化的同时,我们也关注到,Mach-O 文件始终占据了今日头条安装包 80% 左右的体积。Mach-O 文件的优化必不可少。下面我们以时间顺序,介绍我们落地的 Mach-O 文件优化项。

3.1、使用 -Oz 编译参数

Oz 是 Xcode 11 新增的编译优化选项。WWDC 2019 《What's New in Clang and LLVM》[3] 中对 Oz 有过介绍。Oz 的核心原理是对重复的连续机器指令外联成函数进行复用,和“内联函数”的原理正好相反。因此,开启 Oz,能减小二进制的大小,但同时理论上会带来执行效率的额外消耗。对性能(CPU)敏感的代码使用需要评估。

苹果给的参考数据是 4.5% 的包体积收益。

我们在评估了执行效率、堆栈解析、稳定性和编译速度后,对大部分源代码开启了 Oz 编译,包体积减小 4MB 以上。

3.2、使用链接时优化 LTO 

Link-Time Optimization 链接时优化,是 Xcode 自带的一个编译/链接参数。根据 WWDC 2016 《What's New in LLVM》[4]的介绍,LTO 对包大小和运行效率都有正向影响。今日头条在编译和链接中均开启 Incremental LTO 后,包体积减小 6.5MB。

3.3、修正 Exported Symbols 配置

Xcode Build Settings 中的 EXPORTED_SYMBOLS_FILE 配置,控制着 Mach-O 中 __LINKEDIT 段中 Export Info 的信息。动态链接器 dyld 在做符号绑定时,会读取被绑定的动态库或可执行文件的 Export Info 信息,得到一个符号对应的实际调用地址。如果正在被绑定的符号,在目标动态库的 Export Info 中缺失,dyld 则会抛出异常,表现为 App 崩溃。

虽然从原理上看,Export Info 中的信息不可或缺。但是,对于一个 Mach-O 文件来说,并非所有的符号都是需要暴露给其他动态库或可执行文件的。理想情况下,私有的符号应该在编码时就应该以 __attribute__((visibility(hidden))) 修饰。但在历史代码难以逐个添加修饰符的情况下,Exported Symbols 配置给了工程一个维护公有符号白名单的机会。如果填写了有效的 EXPORTED_SYMBOLS_FILE 配置,动态库或者可执行文件会在静态链接时去掉白名单以外的符号,起到缩减包大小、增加逆向难度的作用。

今日头条在使用 Exported Symbols 配置后,包大小减少了 2.1MB。

3.4、属性动态化

属性是 OC 中最常见的概念之一。然而,一个属性并没有我们想象的这么小。通过分析 Mach-O 文件,我们发现,一个属性可以分为三个部分:

(1)成员变量部分:成员变量本质是一个大小 32B 的结构体,结构体中三个指针(Offset、Name、Type)指向的内容的大小分别为 8B、10B、10B,其中 Name、Type 指针指向的内容的大小和成员变量的类型、名字长度相关。总大小大约 60B。

@interface presentViewController ()
@property (nonatomic,strong) UIImageView *imageView;
@property (nonatomic,strong) UIButton *button;
@property (nonatomic,strong) NSString *name;
@end

(2)自动生成的 set/get 方法部分:set/get 方法本质是一个大小 24B 的结构体,结构体包含三个指针 Name、Type、Implementation,指向的内容大小大概为 10B、10B、20B。一个方法大小大概是64B,set、get 两个方法就是 128B。

(3)property 部分:property 的本质仍然是个结构体,大小是 16B,结构体中两个指针指向内容的大小分别大概是 10B、10B,和属性的名字和类型相关。总大小大概 36B。

即一个属性占用的包大小大约为 224B。

如果我们用 @dynamic 修饰一个属性,不生成成员变量、get/set 方法,则一个属性可以由 224B 减少到 36B,即仅包含 property 部分的大小。

同时,代码中存在大量通过脚本自动生成的 JSONModel 子类,这些子类往往拥有大量属性。这里也就存在着包大小优化空间。

于是我们通过修改生成 JSONModel 子类的脚本,实现了:

1、属性全部使用 @dynamic 修饰,基础变量额外生成 IVAR

2、所有 JSONModel 的子类继承自新的父类,新的父类实现 resolveInstanceMethod,在该方法中用 class_addMethod 统一为属性添加 get/set 方法。对象类型的属性使用关联对象的方式存取,基础类型的属性使用额外生成的 IVAR 存取。

这一优化获得了 800KB 的包大小收益,并且评估对读写的性能影响损耗可以接受。

3.5、__TEXT 段迁移

安装包经过压缩后的 Download Size 若超过 200 MB,在蜂窝网络下载 App 就会受到限制,这对新增会有较大影响。在 2020 年下半年,我们探索实践了 __TEXT 段迁移技术:在链接阶段使用 -rename_p 选项将 __TEXT,__text 迁移到 __BD_TEXT,__text,减少苹果对可执行文件的加密范围,提升可执行文件的压缩效率,从而减少 Download Size。

使用该方案我们最终减少了 60 MB 的 Download Size 以及 2 MB 的 Install Size。详细的原理可以参考:《今日头条优化实践:iOS 包大小二进制优化,一行代码减少 60 MB 下载大小》[5]。

3.6、二进制段压缩

Mach-O 文件占据了 Install Size 中很大一部分比例,但并不是文件中的每个段/节在程序启动的第一时间都要被用到。可以在构建过程中将 Mach-O 文件中的这部分段/节压缩,然后只要在这些段被使用到之前将其解压到内存中,就能达到了减少包大小的效果,同时也能保证程序正常运行。由于苹果的一些限制,我们目前只压缩了 __TEXT,__gcc_except_tab__TEXT,__objc_methtype两个节,然后在 _dyld_register_func_for_add_image 的回调中对它进行解压。该方案累计优化了 3.5 MB Install Size。

四、总结

在以上优化项落地的同时,我们还与业务协作,通过挖掘无用代码、无用资源等手段,进一步优化着安装包大小。使得今日头条在高速的业务迭代下,包大小仍能保持稳定。

以上就是怎样优化今日头条IOS安装包的详细内容,更多关于今日头条IOS安装包大小优化的资料请关注我们其它相关文章!

时间: 2021-04-13

IOS内存泄漏检查方法及重写MLeakFinder

对于iOS开发来讲,内存泄漏的问题,已经是老生常谈的话题.在日常的面试中经常会提到这些问题.我们日常的开发过程中进行内存泄漏的检测,一般是使用instrument工具中的Leaks/Allocation来进行排查,网络上也有比较高效又好用的内存泄漏检测工具,MLeakFinder. MLeakFinder-原理 首先看UIViewController,当一个UIViewController被pop或dismiss的时候,这个VC包括在这个VC上的View,或者子View都会很快的被释放.所以我们

如何在IOS中使用Cordova插件

一.准备 插件功能:打开IOS相机 1:创建插件 plugman create --name [插件名称] --plugin_id [插件ID] --plugin_version [插件版本号] plugman create --name CameraDemo --plugin_id cordova-plugin-camerademo --plugin_version 1.0.0 2:添加IOS平台 plugman platform add --platform_name ios 3:创建pac

IOS小组件实现时钟按秒刷新功能

引言   上一节中我们了解了IOS小组件的刷新机制,发现根本没法实现按秒刷新,但是看别的App里面有做到,以为用了什么黑科技,原来是因为系统提供了一个额外的机制实现时间的动态更新,不用走小组件的刷新机制. Text控件支持显示日期时间,下面是来自官网的代码 计算时间差 let components = DateComponents(minute: 11, second: 14) let futureDate = Calendar.current.date(byAdding: components

IOS利用CocoaHttpServer搭建手机本地服务器

缘起 今天用暴风影音看视频,然后发现它有个功能,wifi传片,感觉挺有意思,然后就上网查了下相关内容. 原理 使用CocoaHTTPServer框架,在iOS端建立一个本地服务器,只要电脑和手机连入同一热点或者说网络,就可以实现通过电脑浏览器访问iOS服务器的页面,利用POST实现文件的上传. 实现 1.下载CocoaHTTPServer 2.导入CocoaHTTPServer-master目录下的Core文件夹 3.导入Samples/SimpleFileUploadServer目录下的MyH

浅谈IOS如何对app进行安全加固

防止 tweak 依附 通常来说,我们要分析一个 app,最开始一般是砸壳, $ DYLD_INSERT_LIBRARIES=dumpdecrypted.dylib /path/to/XXX.app/XXX 然后将解密之后的二进制文件扔给类似 hopper 这样的反编译器处理.直接将没有砸壳的二进制文件扔个 hopper 反编译出来的内容是无法阅读的(被苹果加密了).所以说砸壳是破解分析 app 的第一步.对于这一步的防范,有两种方式. 1.限制二进制文件头内的段 通过在 Xcode 里面工程配

如何在IOS中使用IBeacon

什么是iBeacon? iBeacon 是苹果公司2013年9月发布的移动设备用OS(iOS7)上配备的新功能.其工作方式是,配备有低功耗蓝牙(BLE)通信功能的设备使用BLE技术向周围发送自己特有的 ID,接收到该 ID 的应用软件会根据该 ID 采取一些行动. 从个人的角度看: iBeacon向四面八方不停地广播信号,就像是往平静的水面上扔了一块石子,泛起层层涟漪(俗称水波),波峰相当于 iBeacon 的RSSI(接受信号强度指示),越靠近中心点的地方波峰越高(RSSI 越大),这个波峰的

详解IOS WebRTC的实现原理

概述 它在2011年5月开放了工程的源代码,在行业内得到了广泛的支持和应用,成为下一代视频通话的标准. WebRTC的音视频通信是基于P2P,那么什么是P2P呢? 它是点对点连接的英文缩写. P2P连接模式 一般我们传统的连接方式,都是以服务器为中介的模式: 类似http协议:客户端?服务端(当然这里服务端返回的箭头仅仅代表返回请求数据). 我们在进行即时通讯时,进行文字.图片.录音等传输的时候:客户端A?服务器?客户端B. 而点对点的连接恰恰数据通道一旦形成,中间是不经过服务端的,数据直接从一

详解IOS UITableViewCell 的 imageView大小更改

详解IOS UITableViewCell 的 imageView大小更改 实例代码: - (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath{ static NSString *CellIdentifier = @"Cell"; UITableViewCell *cell = [tableView dequeueReusableCell

详解IOS开发中生成推送的pem文件

详解IOS开发中生成推送的pem文件 具体步骤如下: 首先,需要一个pem的证书,该证书需要与开发时签名用的一致. 具体生成pem证书方法如下: 1. 登录到 iPhone Developer Connection Portal(http://developer.apple.com/iphone/manage/overview/index.action )并点击 App IDs 2. 创建一个不使用通配符的 App ID .通配符 ID 不能用于推送通知服务.例如,  com.itotem.ip

详解JSP 中Spring工作原理及其作用

详解JSP 中Spring工作原理及其作用 1.springmvc请所有的请求都提交给DispatcherServlet,它会委托应用系统的其他模块负责负责对请求进行真正的处理工作. 2.DispatcherServlet查询一个或多个HandlerMapping,找到处理请求的Controller. 3.DispatcherServlet请请求提交到目标Controller 4.Controller进行业务逻辑处理后,会返回一个ModelAndView 5.Dispathcher查询一个或多个

详解IOS中文件路径判断是文件还是文件夹

详解IOS中文件路径判断是文件还是文件夹 方法1 + (BOOL)isDirectory:(NSString *)filePath { BOOL isDirectory = NO; [[NSFileManager defaultManager] fileExistsAtPath:filePath isDirectory:&isDirectory]; return isDirectory; } 方法2 + (BOOL)isDirectory:(NSString *)filePath { NSNum

详解IOS串行队列与并行队列进行同步或者异步的实例

详解IOS串行队列与并行队列进行同步或者异步的实例 IOS中GCD的队列分为串行队列和并行队列,任务分为同步任务和异步任务,他们的排列组合有四种情况,下面分析这四种情况的工作方式. 同步任务,使用GCD dispatch_sync 进行派发任务 - (void)testSync { dispatch_queue_t serialQueue = dispatch_queue_create("com.zyt.queue", DISPATCH_QUEUE_SERIAL); dispatch_

详解IOS 单例的两种方式

详解IOS 单例的两种方式 方法一: #pragma mark - #pragma mark sharedSingleton methods //单例函数 static RtDataModel *sharedSingletonManager = nil; + (RtDataModel *)sharedManager { @synchronized(self) { if (sharedSingletonManager == nil) { sharedSingletonManager = [[sel

详解 IOS下int long longlong的取值范围

详解 IOS下int long longlong的取值范围 32bit下: unsigned int 0-4294967295 int -2147483648-2147483647 unsigned long 和int一样 long 和int一样 long long的最大值:9223372036854775807 long long的最小值:-9223372036854775808 unsigned long long的最大值:1844674407370955161 __int64的最大值:92

详解IOS 利用storyboard修改UITextField的placeholder文字颜色

详解IOS 利用storyboard修改UITextField的placeholder文字颜色 最近有个需求需要修改UITextField的placeholder文字颜色,在网上找发现有用代码修改的,但是考虑到更加优雅的实现,所以尝试着在storyboard中直接实现,结果竟然真的成功了, 实现的位置如下: 具体步骤: 1.在User Defined Runtime Attributes中添加一个Key. 2.输入Key Path(这里我们输入_placeholderLabel.textColo

详解http访问解析流程原理

详解http访问解析流程原理 http访问网址域名解析流程: 1.在浏览器中输入www.qq.com域名,操作系统会先检查自己本地的hosts文件是否有这个网址映射关系,如果有,就先调用这个IP地址映射,完成域名解析. 2.如果hosts里没有这个域名的映射,则查找本地DNS解析器缓存,是否有这个网址映射关系,如果有,直接返回,完成域名解析. 3.如果hosts与本地DNS解析器缓存都没有相应的网址映射关系,首先会找TCP/ip参数中设置的首选DNS服务器,在此我们叫它本地DNS服务器,此服务器

详解iOS自定义UITabBar与布局

在小编整理过的文章iOS项目基本框架搭建中,我们详细说明了如何对TabBarItem的图片属性以及文字属性进行一些自定义配置.但是,很多时候,我们需要修改TabBarItem的图片和文字属性之外,还需要自定义TabBarItem的位置,这样系统自带的TabBar的样式并不能满足我们的项目需求,所以我们需要对系统的UITabBar进行自定义,以达到我们的项目需求.例如新浪微博App的底部tab的item就无法用自带的TabBarItem进行实现,最中间那个[+]发布微博并不是用来切换tab的,而是