iOS性能优化(2)-耗电优化、APP启动和安装包瘦身
1. 耗电优化
iOS的APP的耗电的性能也是一部分需要的优化的部分.我们可以使用xcode看出一个App的使用性能情况,使用xcode打开你的工程,然后插上手机,使用真机running项目(必须是真机),然后comand + 6,点击Energy Impact
性能展示.png
一. 耗电的主要来源
耗电的主要来源.png
- CPU(Processing) :CPU使用率超过20%就会快速耗干电池电量.高效使用CPU,并且当用户出现模糊输入时快速做出不做事情的反应.
- Network (Networking): 网络活动会唤起需要长时间周期性供电的无线电模组,可以分批次进行网络请求,来降低开销.
- Location(Location) :精密&高频的的定位会增加开销,需要按需使用.
- GPU(Graphics) :图形处理器(显卡的处理器),乱使用GPU会导致交互差,并且降低电池寿命.
- Background : 后台状态App仍会消耗电量,App要按需执行后台操作,并使用延迟APIs来保证系统运算高效执行.另外,在app进入后台状态是,立即减少动作,并且通知系统一次这些动作已经完成.
二. 耗电优化
- 尽可能降低CPU、GPU功耗;
- 少用定时器;
- 优化I/O操作;
※ 尽量不要频繁写入小数据，最好批量一次性写入;
※ 读写大量重要数据时，考虑用dispatch_io，其提供了基于GCD的异步操作文件I/O的API。用dispatch_io系统会优化磁盘访问;
※ 数据量比较大的，建议使用数据库（比如SQLite、CoreData）; - 网络优化
※ 减少、压缩网络数据;
※ 如果多次请求的结果是相同的，尽量使用缓存;
※ 使用断点续传，否则网络不稳定时可能多次传输相同的内容;
※ 网络不可用时，不要尝试执行网络请求;
※ 让用户可以取消长时间运行或者速度很慢的网络操作，设置合适的超时时间;
※ 批量传输，比如，下载视频流时，不要传输很小的数据包，直接下载整个文件或者一大块一大块地下载。如果下载广告，一次性多下载一些，然后再慢慢展示。如果下载电子邮件，一次下载多封，不要一封一封地下载; - 定位优化
※ 如果只是需要快速确定用户位置，最好用CLLocationManager的requestLocation方法。定位完成后，会自动让定位硬件断电;
※ 如果不是导航应用，尽量不要实时更新位置，定位完毕就关掉定位服务;
※ 尽量降低定位精度，比如尽量不要使用精度最高的kCLLocationAccuracyBest
需要后台定位时，尽量设置pausesLocationUpdatesAutomatically为YES，如果用户不太可能移动的时候系统会自动暂停位置更新;
※ 尽量不要使用startMonitoringSignificantLocationChanges，优先考虑startMonitoringForRegion; - 硬件检测优化
※ 用户移动、摇晃、倾斜设备时，会产生动作(motion)事件，这些事件由加速度计、陀螺仪、磁力计等硬件检测。在不需要检测的场合，应该及时关闭这些硬件;
2. APP启动
App的启动从技术的角度可以分为两种冷启动和热启动,冷启动是App启动时需要系统分配进程的启动操作；(通俗的讲就是从零开始启动APP).热启动是App启动时进程还在系统中的启动操作.(我们可以理解成APP已经在内存中，在后台存活着，再次点击图标启动APP)
App启动的时间的优化,其实主要是对冷启动做的优化,也就是从0打开app做的优化.
想知道当前系统打开的所花费的时间可以这么做通过添加环境变量可以打印出APP的启动时间分析（Edit scheme -> Run -> Arguments）:DYLD_PRINT_STATISTICS设置为1,即可以获取到信息 但是信息不是不详细,如果想获取到更多详细的信息,那就将DYLD_PRINT_STATISTICS_DETAILS设置为1.
一. APP的冷启动可以概括为3大阶段
- dyld
- runtime
- main
三大阶段示意图.png
A. APP的启动 - dyld
- dyld（dynamic link editor），Apple的动态链接器，可以用来装载Mach-O文件（可执行文件、动态库等）;
- 启动APP时，dyld所做的事情有:
※ 装载APP的可执行文件，同时会递归加载所有依赖的动态库;
※ 当dyld把可执行文件、动态库都装载完毕后，会通知Runtime进行下一步的处理;
B. APP的启动 - runtime
- 启动APP时，runtime所做的事情有:
※ 调用map_images进行可执行文件内容的解析和处理;
※ 在load_images中调用call_load_methods，调用所有Class和Category的+load方法;
※ 进行各种objc结构的初始化（注册Objc类 、初始化类对象等等）;
※ 调用C++静态初始化器和__attribute__((constructor))修饰的函数; - 到此为止，可执行文件和动态库中所有的符号
(Class，Protocol，Selector，IMP，…)都已经按格式成功加载到内存中，被runtime 所管理;
C. APP的启动 - main
- 总结一下:
※ APP的启动由dyld主导，将可执行文件加载到内存，顺便加载所有依赖的动态库;
※ 并由runtime负责加载成objc定义的结构;
※ 所有初始化工作结束后，dyld就会调用main函数;
※ 接下来就是UIApplicationMain函数，AppDelegate的application:didFinishLaunchingWithOptions:方法;
二. APP的启动优化
- dyld
※ 减少动态库、合并一些动态库（定期清理不必要的动态库）;
※ 减少Objc类、分类的数量、减少Selector数量（定期清理不必要的类、分类）;
※ 减少C++虚函数数量;
※ Swift尽量使用struct; - runtime
※ 用+initialize方法和dispatch_once取代所有的attribute((constructor))、C++静态构造器、ObjC的+load; - main
※ 在不影响用户体验的前提下，尽可能将一些操作延迟，不要全部都放在finishLaunching方法中;
※ 按需加载;
3. 安装包瘦身
安装包主要由两部分组成，资源文件以及可执行文件，瘦身主要从这两部分入手：
一. 资源文件瘦身
A. 删除无用资源
现在应该没有APP需要支持iPhone4以下的机型了，所以1X的图片可以全部删掉。3X的图片是保留还是删掉看具体情况。
B. 未使用的图片通过LSUnusedResources扫描删除
要注意的是可能会有误伤，该工具是全匹配，一些拼接名字来使用的图片要注意手动剔除。
C. 其他资源手动删除
一些音频、视频和多余的plist文件以及readme文件什么的目测只能肉眼扫描了。
D. 删除功能重复的三方库
E. 资源压缩
a. 图片压缩,使用ImageOptim 实现无损压缩，COMPRESS_PNG_FILES和STRIP_PNG_TEXT设置为NO；
ImageOptim这是一款非常好的图片压缩工具，可以进行无损压缩，能够对 png 和 jpeg 图片文件进行优化，它能找到最佳的压缩参数(在设置中可以设置压缩比例，80% 及以上是无损压缩，推荐使用)，并通过消除不必要的信息（如文件的 EXIF 标签和颜色配置文件等），优化后达到减小文件大小的效果.
b. 使用TinyPNG有损压缩图片,TinyPNG非常好用强烈推荐.
使用的时候直接执行tinypng *.png -k token脚本即可.
a和b两种情况作对比:对于较大尺寸的图片，可以和设计沟通，在不失真和影响效果的前提下，使用TinyPNG进行压缩；较小尺寸的图片，建议使用ImageOptiom。
F. 用LaunchScreen.storyboard替换启动图片.
G. 资源按需加载，非必要资源都等到使用时再从服务端拉取.
H. 变更图片文件的导入方式
a. Assets.xcassets。
※ 只支持png格式的图片；
※ 图片只支持[UIImage imageNamed]的方式实例化，但是不能从Bundle中加载；
※ 在编译时，Images.xcassets中的所有文件会被打包为Assets.car的文件。
b. CreateGroup
※ 黄色文件夹图标；Xcode中分文件夹，Bundle中都在同一个文件夹下，因此，不能出现文件重名的情况；
※ 可以直接使用[NSBundle mainBundle]作为资源路径，效率高；
※ 可以使用[UIImage imageNamed:]加载图像。
c. CreateFolderRefences
※ 蓝色文件夹；Xcode中分文件夹，Bundle中同样分文件夹，因此，可以出现文件重名的情况；
※ 需要在[NSBundle mainBundle]的基础上拼接实际的路径，效率较差；
※ 不能使用[UIImage imageNamed:]加载图像。
二. 可执行文件瘦身
A. 打开bitcode设置
在”Build Settings”->”Enable Bitcode”选项中看到这个设置;
bitcode是被编译程序的一种中间形式的代码，上传到apple store后，apple可以为目标安装APP的设备进行优化二进制，减小安装包的大小。
缺点：1.用户安装的二进制文件不再是开发这边生成的，是苹果通过bitcode编译优化出来的，其对应的调试符号信息丢失了，无法再根据崩溃日志定位崩溃现场； 2.有些三方库不支持bitcode，需要打开bitcode重新编译。
B. 编译器优化级别
a. BuildSettings->Optimization Level，Xcode默认设置为“Fastest ,Smallest”，保持默认即可;
b. Build Settings-> Linking->Dead Code Stripping 设置成 YES;
c. Deployment Postprocessing 设置成YES;
d. Strip Linked Product 设置成YES;
e. 工程的Enable C++ Exceptions和Enable Objective-C Exceptions选项都设置为NO。手动管理异常;
f. symbols hidden by default选项设置为YES;
g. 所有没有使用C++动态特性的lib库（搜索工程没有使用dynamic_cast关键字） Enable C++ Runtime Types 选项设置为NO;
h. 去除符号信息
Strip Debug Symbols During Copy 和 Symbols Hidden by Default在release版本应该设为yes，可以去除不必要的调试符号。Symbols Hidden by Default会把所有符号都定义成”private extern”。
j. LinkMap
项目里会引入很多第三方静态库，如果能知道这些第三方库在可执行文件里占用的大小，就可以评估是否值得去找替代方案去掉这个第三方库。通常使用linkmap来进行统计，然后对引用的库大小进行评估，对于过大的库是否有相对轻量的库的替代方案；
想了解更多iOS学习知识请联系:QQ(814299221)
