引言

移动端的应用，对启动时间的体验常常“锱铢必较”，当应用承载了更多的内容的同时，一直保持”秒开”的启动速度，是需要技术团队的不断优化。

移动应用的特点是需求变化快，相应地，其代码更迭和变化也是快速的，如果多个版本的更新迭代都没有关注到APP的性能和质量，慢慢地APP可能会变得臃肿、迟钝。所以针对APP各个维度的数据需要持续统计及对比，性能相关的优化也需要不断跟进，才能保持并提高APP的性能和质量。

经过多年来对爱奇艺APP的性能及质量优化，在安装包大小、启动时间、性能、稳定性等方面总结了很多经验。目前公司业务不断增长，各业务也都发布了自己的APP，为了能让各独立APP借鉴爱奇艺视频在性能及质量优化上的相关经验，建立了针对移动应用优化的工具箱。

具体从以下几个方面优化：

安装包大小
启动速度
稳定性
其他维度

一、安装包大小

安装包大小对于APP来说是一个非常重要的指标：

1、iOS8对于APP的text段有60MB的限制

2、超过200MB的APP需要连接WIFI下载（之前是150MB）

3、启动速度会受包中二进制大小的影响

4、除去商店中APP的简介、截图，很多用户都会关注APP的大小，尤其是使用空间为8G、16G的用户

安装包大小的优化，主要包含两大块：资源大小的优化和二进制大小的优化。

资源大小的优化相对来说比较简单，主要包括以下几个方面：

1、资源压缩

2、未使用、重复资源的删除

3、资源上云

资源压缩

Xcode的编译选项中，提供了Compress PNG Files及Remove Text MetaData From PNG Files，但是由于PNG是无损压缩，经过Xcode压缩后的图片资源，依然很大。

那么PNG是否可以通过“有损”压缩，来缩小体积呢？答案是可以。通常UI同事出的图都是32位图片，32位图相当于Alpha透明度+24位图，总共可以显示2^24=16777216种颜色。图片颜色丰富固然好，但是一般情况下，APP包中的图片色彩范围实际很小，按钮或者一些小图使用8位图肉眼完全看不出与32位图有什么区别。

中的32位与8位图的对比

因此团队使用pngquant对大多数的32位图进行了处理，将其转为8位图，并且使用Zopfli进行了压缩，这样整体的PNG图片资源大概被压缩了70%左右。这里要注意，由于一些渐变背景的颜色覆盖范围较大，转为8位图颜色丢失较大，表现效果会差很多，所以这些图片要谨慎处理。

未使用、重复资源的删除

随着版本迭代，一些功能可能会下线，有时相关的资源却没有及时删掉，有些功能由于开发者不同，可能部分相对通用的图片会有重复。这部分资源会随着时间的推移慢慢累积，及时发现并删除是非常必要的。

图片是否被使用，可以通过图片名字符串的匹配来判断。需要注意的是图片名拼接的情况（比如新手引导的功能，很容易出现图片名拼接数字的情况），在图片资源预处理的过程中，通常有两张以上图片有相同的前缀或后缀，可以将其相同的部分提取出来，作为字符串匹配的依据。

重复资源的情况一般会发生在一些按钮、或者背景图由同一个UI同事生成，发给了不同功能的开发人员。这部分图片的判定一般可以通过图片大小相同或相近（大小在5%范围内）、分辨率相同进行初筛，然后再通过magick compare工具进行图片的对比，提取出相似度极大的即可。

最后工具输出的结果需要开发人员进行二次确认，确保不会有误删的情况出现。

资源上云

资源上云可以有效减少包内资源，唯一要注意的是这些资源由于是lazy load，所以比较适合层级较深的页面使用。图片逻辑可以封装为工具类，前端使用只是调用一个方法，具体哪些图片取本地、哪些图片走云的策略可以自由配置。此外，资源上云的另一个好处是可以很方便地实现动态换肤。

JS、表情库等资源可以通过打包预下载的形式，并增加更新策略，这样RN页面、WebView、表情库都不占用安装包大小。

二进制大小的优化相对来说比较困难，除去部分功能使用Web页面或者RN，主要工作集中在无用类、无用代码的分析及删除。

Xcode可以生成一个Link Map文件，文件包含了可执行文件的路径、目标文件、符号等各种信息。文件中__objc_classrefs表示引用到的类，_objc_classname表示APP内的类名，通过分析两者的差别，可以得出未使用的类，同理，分析__objc_selrefs和_objc_methname的差别可以得出未使用的方法。但是由于OC的动态性，得出的结果会有大量误报的情况。那么如何减少误报呢？可以通过测试case的代码覆盖率，来提高无用代码精确度的分析。

Xcode设置中开启代码覆盖率后，编译时会生成gcno文件，程序运行时会产生gcda文件，通过lcov解析即可得到代码测试覆盖率。如果开发阶段开发人员的自测，以及全功能case跑完，都有一些类或方法没有被覆盖到，并且这些类或方法又跟Link Map文件分析的结果一致，那么这些类或方法会被标记为无用代码，由工具统一收集并指派给相关开发人员进行处理。

针对安装包大小的不断优化非常重要，这也使得爱奇艺APP能够在集成文学、奇秀、漫画、泡泡、票务、轻小说、知识付费等各类业务后，安装包大小依然保持在200MB以内。

二、启动速度

用户下载APP后，第一次打开以及后续使用最先体验到的，便是启动速度，所以启动速度对于用户体验来说至关重要。iOS上的启动分为冷启和热启，热启由于APP已经加载到内存中，通常情况下都是非常快的。一般对于启动速度的优化，主要是针对冷启动而言。

启动可以划分为before main和after main两大部分，这两部分都存在优化空间。

Xcode里点击Edit Scheme，在Environment Variables中添加DYLD_PRINT_STATISTICS字段，设置为YES后可以打印pre-main time

dylib loading time

其中dylib loading time包含了加载系统动态库和加载APP自己的动态库，系统动态库因为有相关的优化，有些已经加载到内存中了，所以这部分时间很快，也没有优化空间。

加载APP内嵌的动态库比较耗时，因为每加载一个动态库，系统都需要文件验证、注册签名、针对segment进行mmap。embedded framework一般用于Extension跟主APP共享代码逻辑，苹果针对这部分的优化建议是，如果有多个动态库，合并成一个可以有效的减少加载时间。

为了绕过iOS8系统text段60MB的限制，爱奇艺技术团队之前也使用了embedded framework，后来针对启动速度优化，又改回使用静态库。使用静态库虽然会增加些许rebase/binding的时间，但是综合来看，整体时间还是优于使用动态库的。

rebase/binding time & ObjC setup time

iOS4.3后引入了 ASLR（address space layout randomization），这样Mach-o文件和动态库加载到虚拟内存中的地址就不是固定的了，所以需要rebase/binding来修正指针。这一步首先会将文件镜像加载到内存并加密，然后针对__DATA segment中的指针进行修正。

这一步可以优化的操作有：

1、减少OC类及方法

2、减少C++虚函数

针对安装包大小的优化已经针对无用代码进行了处理，所以这一步也间接省略了。

initializer time

这一步会按继承关系调用每个类及category的load方法，一般来说主要耗时也集中在这里。由于load被系统自动调用，之前APP中很多动态注册的功能都是基于load方法，这个机制的滥用导致load数量最多超过了900，也严重影响了启动速度。因而团队选择修改机制，将一些load中逻辑移动到initialize中。另一些基于动态注册的类，通过编译器记录下类名并保存到文件，在APP启动后适当的时机再读取及调用。

调用机制的修改，让APP减少了大概700多处load方法调用。为了杜绝后续load方法的过度使用，爱奇艺技术团队创建了一个工具，该工具swizzling 系统的load方法，并通过动态库的形式加载到APP中，这样就可以统计到APP中load方法的数量、每个load方法的耗时以及使用了load方法的类所在的库。

各版本数据入库后，也可以方便地跟踪以及分维度查看load方法数量及耗时的变化情况。这部分可以重点优化的点是：

1、减少load方法的使用

2、如果必须使用load，精简逻辑，减少代码耗时

didFinishLaunchingWithOptions

前面的准备工作都已经完成，这一步主要是生成主视图，所以目标是尽快生成主视图，减少其他不必要的逻辑，部分业务逻辑放到子线程执行，使用代码绘制UI，减少或者不用xib和storyboard。

此外，用户经常涉及到的启动逻辑应该重点优化。以爱奇艺APP为例，据统计，80%以上的用户启动是开机屏广告，所以针对这种启动case，可以重点优化，比如提前准备好下一次的广告数据，图片下载后直接解压为bitmap，跟广告展现无关的逻辑延后处理。广告展现的同时，进行首页UI的绘制。

这部分逻辑对启动速度影响很大，所以也需要进行监控。针对这个方法，爱奇艺技术团队也创建了对应的工具，工具会记录didFinishLaunchingWithOptions方法中每个改动，并对每个方法进行打点计时，这样当didFinishLaunchingWithOptions方法中的代码有修改，或者其中的某个方法执行耗时有异常时，可以及时发现并定位。

三、稳定性

APP稳定性方面主要是减少异常及崩溃，针对这部分，可以从Category、Method Swizzling以及静态分析来入手。

Category分析

Category可以为现有的类添加方法，但是Category方法的不规范使用很容易引发问题，其中最容易出现的就是重名问题。重名问题分为两种情况，一种是APP内的不同业务Category重名，另一种是APP内的Category方法与系统API重名，包括系统私有API。

首先是不同业务的Category方法重名。如果是相同的逻辑，这种情况是方法重复，只保留一份可以减少冗余代码及安装包大小，减少rebase/binding time。如果是不同的逻辑，那么会导致只有一份逻辑生效，其他业务就会产生逻辑错误甚至导致崩溃。

如果是与系统API重名，那么可能影响系统逻辑，尤其是与私有API重名时，很难发现问题（因为document中搜不到）。之前曾发生过APP逻辑异常但一直找不到原因的情况，后来发现是Category方法与系统私有API重名导致。

比较规范的做法是Category名加前缀，但是一些开发人员可能由于各种原因没有这么做。为了及时发现重名情况，爱奇艺技术团队创建了一个工具进行监控，工具会定期将APP中所有Category方法汇总，分析有无重名情况。与系统API的对比需要先将系统API提取出来，公开的API可以通过解析系统库头文件来提取API，私有API可以通过class dump系统库，然后用结果中所有的API减去头文件中的提取的API，就是私有API。这样就得到一份iOS系统的所有API，用APP中的Category方法跟系统所有API求交集，就可以得到与系统API重名的Category方法。

Method swizzling分析

Method swizzling可以解决很多问题，但也会引发一些问题。一般情况下，Method swizzling主要是为系统方法插入一些逻辑，但有时也会导致修改系统逻辑的情况出现。之前遇到过某些业务修改了系统实现，导致特殊情况下APP的崩溃，比如当NSArray的元素超过五万时，对象的一些方法会走系统优化后的方法，所以针对这些方法的swizzling都会出现问题。

为统计各业务Method swizzling的使用情况，团队针对使用了method_exchangeImplementations的库进行初筛，针对使用了swizzling的库使用ar -x后，再针对.o文件进行二次筛选。最后通过反编译工具，反编译.o文件，就可以查到使用swizzling的具体方法。对于新增了swizzling使用的库需要严格审核，确保无问题后才合并到主工程。

静态分析

静态分析可以有效地发现并预防一些问题，如使用Xcode自带的Analyze以及Facebook的infer工具。注册观察者未移除、delegate没使用weak修饰、对象未使用以及未做类型或null的判断都可以通过静态分析及时发现。

这块要做的主要目的是跟踪分析结果，了解各版本以及各个库新增了多少，修复了多少，掌握其自动创建修复任务及分配情况，确保问题提早发现，数量能够及时收敛。

四、其他维度

私有API检测

使用了私有API可能导致审核被拒，被拒会影响发版日期，一些推广及功能的上线都会受到影响，因此私有API检测也是十分必要的。使用私有API被拒的情况主要有：

1、使用了私有API或私有类

2、方法名跟私有API一样

第一种情况明显要被拒，第二种被拒则比较“冤枉”，比如某一方法跟私有API恰好一样，实际并没有使用私有API，但是仍然被认定使用而遭拒审。第二种情况又分为两个case，一个是某个类的某个方法跟私有API重名了，但是类名并不相同，另一个是继承了系统某个类，恰好一个方法跟这个系统父类的私有API重名。第一个case被拒的可能性较小，第二个case有极大概率被拒。

之前在Category分析时，已经获取到了系统私有API，通过class dump以及 strings APP，可以获取到APP中所有的API；通过两者取交集，可以得到APP中试用的API与私有API重名的情况。这些API拿到后，需要对其父类以及Category类进行查找，如果父类或者Category类与系统一致，标记为严重。如果只是重名，标记为中等。

此外，针对线上APP的私有API分析，可以得出一份白名单（可以上线说明即便命中私有API，也不会被拒）。当前版本分析出的新增私有API，如果在白名单中，那么可以暂时不处理，如果不在白名单并且标记严重，一般会让对应业务进行修改，防止提包被拒。

文件读写、解压缩

如果频繁的文件读写与解压缩操作时机跟某些用户操作重合，可能会影响用户体验，比如APP启动后，用户可能会进行列表滑动；播放剧集时，快速开播也有特定IO逻辑。此时读写文件或解压会导致帧数降低、开播变慢等问题，因此针对这部分的监控也是十分必要的。

通过代码扫描或者hook的调用，可以了解哪些库进行了文件读写及解压，将这些操作的时机、当前线程、以及用户行为等信息记录下来并进行归纳分析，就可以知晓这些操作是否当时会影响用户体验了。可以通过用户操作优先级状态，来决定是否进行这些操作。不过这涉及到多线程操作，需注意死锁的问题。

五、工具箱的架构演进

随着对APP的不断优化，工具箱也在不断更新和成长。最初，针对各维度的分析统计都是一个个脚本，数据生成后，对数据的分析和汇总也是人工处理，这个时期可以称之为“石器时代”。

后来会按照分类，将这些比较小的工具归类并组合起来，使之可以针对APP的某个维度进行整体分析；工具交给Jenkins定时触发，数据的分析和汇总也由人工变成自动分析处理，工具箱进入到“工业时代”。

为了更直观地查看各维度的数据及变化情况，于是为工具箱增加了前端页面，包括数据展示、对比以及一系列的图表系统；当数据异常或者波动较大时，详细数据情况会通过邮件提醒对应的负责人；自动生成的优化任务也会根据规则分配给对应的开发人员，工具箱进入到“自动化时代”。

总结

爱奇艺APP目前集成了很多业务，比如奇秀、动漫、阅读、票务、知识付费等，然而安装包大小一直保持在200MB以内、保持”秒开”的启动速度、性能方面各页面切换的帧率保持在55帧以上，关键页面的滑动保持在59帧，同时，开播速度也优于竞品，在稳定性方面的不断完善也使得爱奇艺APP的崩溃率小于千分之二，是爱奇艺技术团队的不断优化的结果。为用户提供最好的视频体验及相关服务，爱奇艺技术团队也会在优化之路上继续探索。

本文转载自公众号爱奇艺技术产品团队（ID：iQIYI-TP）。

原文链接：

https://mp.weixin.qq.com/s?__biz=MzI0MjczMjM2NA==&mid=2247485306&idx=1&sn=93bf70b6168a4f8a56ceab3d2849a844&chksm=e9769b59de01124f8b78a2dc8a189cb6953593db207254f83ace96d76770f951364fa735b204&scene=27#wechat_redirect

创作场景

爱奇艺移动应用优化之路