iOS性能优化

一、UI卡优化

1.1、图像显示原理

iOS性能优化_第1张图片

CPU和GPU是通过总线连接起来的,CPU输出的结果往往是一个位图,经由总线,在合适的时机上传给GPU,GPU拿到位图后做相应的图层渲染,包括纹理的合成等,把结果放到帧缓冲区(Frame Buffer)当中,由视图控制器根据信号,在指定时间之前去帧缓冲区提取要显示的内容,然后显示到屏幕上面。

CPU:UI布局计算、文本的计算和排版、图片的格式转换和解码、图像的绘制,输出位图,然后把这个位图提交到GPU上面。
GPU:纹理渲染。

1.2、UI卡顿、掉帧

iOS性能优化_第2张图片

VSync垂直信号,页面滑动流畅要求:60fps,每秒60帧画面更新,即每16.7ms就要产生一帧画面,在16.7ms中,要CPU和GPU共同协同完成一帧的数据。

CPU花费一定的时间完成UI布局,文本计算等,包括一些视图的绘制以及图片解码等产生的位图提交给GPU,再由GPU花费一定的时间进行相应的图层的合成和纹理的渲染,然后准备好下一帧画面,然后在下一帧VSync信号到来的时候显示这一帧画面。

如果CPU在UI布局及文本计算的时候花费了过多的时间,那在这16.7ms中留给GPU的时间就非常少,GPU要完成相应的图层的合成和纹理的渲染,总时间就会超过16.7ms,那么在下一帧VSync信号到来的时候,还没有准备好这一帧的画面,这样就会产生掉帧的情况。

UI卡顿、掉帧的原因:
在规定的16.7ms之内,在下一帧VSync信号到来之前,CPU和GPU并没有共同完成下一帧画面的合成,于是就会导致卡顿或者掉帧的问题。

1.3、滑动优化方案

  • CPU:
    1、尽量用轻量级的对象,比如可以用int的就不要用NSNumber,比如用不到事件处理的地方,可以考虑使用CALayer取代UIView
    2、不要频繁地调用UIView的相关属性,比如frame、bounds、transform等属性,尽量减少不必要的修改
    3、尽量提前计算好布局,在有需要时一次性调整对应的属性,不要多次修改属性
    4、Autolayout会比直接设置frame消耗更多的CPU资源
    5、图片的size最好刚好跟UIImageView的size保持一致
    6、控制一下线程的最大并发数量
    7、尽量把耗时的操作放到子线程
    对象的创建、调整、销毁,可以放到子线程当中去做。
    预排版:(布局计算、文本计算)放到子线程当中,这样,主线程就有更多的时间响应用户的交互。
    预渲染:文本等异步绘制、图片解码等(放到子线程当中)。

  • GPU:
    1、尽量避免短时间内大量图片的显示,尽可能将多张图片合成一张进行显示
    2、GPU能处理的最大纹理尺寸是4096x4096,一旦超过这个尺寸,就会占用CPU资源进行处理,所以纹理尽量不要超过这个尺寸
    3、尽量减少视图数量和层次
    4、减少透明的视图(alpha<1),不透明的就设置opaque为YES
    5、尽量避免出现离屏渲染

1.4 离屏渲染

  • 在OpenGL中,GPU有2种渲染方式
    On-Screen Rendering:当前屏幕渲染,在当前用于显示的屏幕缓冲区进行渲染操作
    Off-Screen Rendering:离屏渲染,在当前屏幕缓冲区以外新开辟一个缓冲区进行渲染操作

  • 离屏渲染消耗性能的原因
    需要创建新的缓冲区
    离屏渲染的整个过程,需要多次切换上下文环境,先是从当前屏幕(On-Screen)切换到离屏(Off-Screen);等到离屏渲染结束以后,将离屏缓冲区的渲染结果显示到屏幕上,又需要将上下文环境从离屏切换到当前屏幕

  • 哪些操作会触发离屏渲染?
    光栅化:layer.shouldRasterize = YES
    遮罩:layer.mask
    圆角:同时设置layer.masksToBounds = YES、layer.cornerRadius大于0
    考虑通过CoreGraphics绘制裁剪圆角,或者叫美工提供圆角图片
    阴影:layer.shadowXXX
    如果设置了layer.shadowPath就不会产生离屏渲染

1.5 卡顿检测

平时所说的“卡顿”主要是因为在主线程执行了比较耗时的操作
可以添加Observer到主线程RunLoop中,通过监听RunLoop状态切换的耗时,以达到监控卡顿的目的
LXDAppFluecyMonitor -- 卡顿检测

二、耗电优化

2.1 耗电的主要来源

CPU处理:Processing
网络:Networking
定位:Location
图像:Graphics

2.2 耗电优化

  • 1、尽可能降低CPU、GPU功耗
  • 2、少用定时器
  • 3、优化I/O操作(文件的读和写)
    1、尽量不要频繁写入小数据,最好批量一次性写入
    2、读写大量重要数据时,考虑用dispatch_io,其提供了基于GCD的异步操作文件I/O的API。用dispatch_io系统会优化磁盘访问
    3、数据量比较大的,建议使用数据库(比如SQLite、CoreData)
  • 4、网络优化
    1、减少、压缩网络数据
    2、如果多次请求的结果是相同的,尽量使用缓存
    3、使用断点续传,否则网络不稳定时可能多次传输相同的内容
    4、网络不可用时,不要尝试执行网络请求
    5、让用户可以取消长时间运行或者速度很慢的网络操作,设置合适的超时时间
    6、批量传输,比如,下载视频流时,不要传输很小的数据包,直接下载整个文件或者一大块一大块地下载。如果下载广告,一次性多下载一些,然后再慢慢展示。如果下载电子邮件,一次下载多封,不要一封一封地下载
  • 5、定位优化
    1、如果只是需要快速确定用户位置,最好用CLLocationManager的requestLocation方法。定位完成后,会自动让定位硬件断电
    2、如果不是导航应用,尽量不要实时更新位置,定位完毕就关掉定位服务
    3、尽量降低定位精度,比如尽量不要使用精度最高的kCLLocationAccuracyBest
    4、需要后台定位时,尽量设置pausesLocationUpdatesAutomatically为YES,如果用户不太可能移动的时候系统会自动暂停位置更新
    5、尽量不要使用startMonitoringSignificantLocationChanges,优先考虑startMonitoringForRegion:
  • 6、硬件检测优化
    用户移动、摇晃、倾斜设备时,会产生动作(motion)事件,这些事件由加速度计、陀螺仪、磁力计等硬件检测。在不需要检测的场合,应该及时关闭这些硬件

三、启动优化

3.1 APP的启动可以分为2种

冷启动(Cold Launch):从零开始启动APP
热启动(Warm Launch):APP已经在内存中,在后台存活着,再次点击图标启动APP

3.2 APP启动时间的优化,主要是针对冷启动进行优化

  • 通过添加环境变量可以打印出APP的启动时间分析(Edit scheme -> Run -> Arguments -> Environment Variables)
    DYLD_PRINT_STATISTICS设置为1
    如果需要更详细的信息,那就将DYLD_PRINT_STATISTICS_DETAILS设置为1

  • DYLD_PRINT_STATISTICS设置为1
    Total pre-main time: 48.88 milliseconds (100.0%) // main函数调用前所耗时时间
    dylib loading time: 38.52 milliseconds (78.8%) // 动态库加载时间
    rebase/binding time: 126687488.9 seconds (371845102.5%)
    ObjC setup time: 10.14 milliseconds (20.7%) // OC结构体准备
    initializer time: 41.04 milliseconds (83.9%) // 初始化耗时
    slowest intializers : // 比较慢的加载
    libSystem.B.dylib : 2.92 milliseconds (5.9%)
    libBacktraceRecording.dylib : 6.00 milliseconds (12.2%)
    libMainThreadChecker.dylib : 28.13 milliseconds (57.5%)

  • DYLD_PRINT_STATISTICS_DETAILS设置为1
    total time: 348.32 milliseconds (100.0%) // 总时间
    total images loaded: 318 (311 from dyld shared cache) // 镜像加载
    total segments mapped: 21, into 385 pages // 每个块的映射时间
    total images loading time: 220.02 milliseconds (63.1%)
    total load time in ObjC: 8.23 milliseconds (2.3%)
    total debugger pause time: 181.48 milliseconds (52.1%)
    total dtrace DOF registration time: 0.16 milliseconds (0.0%)
    total rebase fixups: 17,964
    total rebase fixups time: 0.37 milliseconds (0.1%)
    total binding fixups: 436,893
    total binding fixups time: 82.68 milliseconds (23.7%)
    total weak binding fixups time: 0.01 milliseconds (0.0%)
    total redo shared cached bindings time: 123.35 milliseconds (35.4%)
    total bindings lazily fixed up: 0 of 0
    total time in initializers and ObjC +load: 36.83 milliseconds (10.5%)
    libSystem.B.dylib : 2.59 milliseconds (0.7%)
    libBacktraceRecording.dylib : 6.13 milliseconds (1.7%)
    libobjc.A.dylib : 0.97 milliseconds (0.2%)
    CoreFoundation : 1.00 milliseconds (0.2%)
    libMainThreadChecker.dylib : 24.47 milliseconds (7.0%)
    total symbol trie searches: 1056706
    total symbol table binary searches: 0
    total images defining weak symbols: 32
    total images using weak symbols: 84

3.3 APP的冷启动可以概括为3大阶段

1、dyld
2、runtime
3、main


iOS性能优化_第3张图片
  • APP的启动 - dyld
    dyld(dynamic link editor),Apple的动态链接器,可以用来装载Mach-O文件(可执行文件、动态库等)。
    启动APP时,dyld所做的事情有:
    装载APP的可执行文件,同时会递归加载所有依赖的动态库
    当dyld把可执行文件、动态库都装载完毕后,会通知Runtime进行下一步的处理

  • APP的启动 - runtime
    启动APP时,runtime所做的事情有:
    调用map_images进行可执行文件内容的解析和处理
    在load_images中调用call_load_methods,调用所有Class和Category的+load方法
    进行各种objc结构的初始化(注册Objc类 、初始化类对象等等)
    调用C++静态初始化器和attribute((constructor))修饰的函数

到此为止,可执行文件和动态库中所有的符号(Class,Protocol,Selector,IMP,…)都已经按格式成功加载到内存中,被runtime 所管理

  • APP的启动 - main
    APP的启动由dyld主导,将可执行文件加载到内存,顺便加载所有依赖的动态库
    并由runtime负责加载成objc定义的结构
    所有初始化工作结束后,dyld就会调用main函数
    接下来就是UIApplicationMain函数,AppDelegate的application:didFinishLaunchingWithOptions:方法

3.4 APP的启动优化

按照不同的阶段

  • dyld
    减少动态库、合并一些动态库(定期清理不必要的动态库)
    减少Objc类、分类的数量、减少Selector数量(定期清理不必要的类、分类)
    减少C++虚函数数量
    Swift尽量使用struct

  • runtime
    用+initialize方法和dispatch_once取代所有的attribute((constructor))、C++静态构造器、ObjC的+load

  • main
    在不影响用户体验的前提下,尽可能将一些操作延迟,不要全部都放在finishLaunching方法中
    按需加载

四、安装包优化

4.1 安装包瘦身

安装包(IPA)主要由可执行文件、资源组成

  • 资源(图片、音频、视频等)
    采取无损压缩
    去除没有用到的资源: https://github.com/tinymind/LSUnusedResources
  • 可执行文件瘦身
    编译器优化
    Strip Linked Product、Make Strings Read-Only、Symbols Hidden by Default设置为YES。
    去掉异常支持,Enable C++ Exceptions、Enable Objective-C Exceptions设置为NO, OtherC Flags添加-fno-exceptions。
    利用AppCode(https://www.jetbrains.com/objc/)检测未使用的代码:菜单栏 -> Code -> Inspect Code。
    编写LLVM插件检测出重复代码、未被调用的代码。

4.2 LinkMap

生成LinkMap文件,可以查看可执行文件的具体组成

iOS性能优化_第4张图片

可借助第三方工具解析LinkMap文件: https://github.com/huanxsd/LinkMap

你可能感兴趣的:(iOS性能优化)