iOS APP性能优化

作者: 天空像天空一样蓝 | 来源:发表于2019-08-19 14:59 被阅读0次

前言随着移动互联网的发展，产品的更新迭代，公司业务的不断扩展，移动应用页面布局也越来越复杂，效果越来越炫，自身业务功能越来越多。市面上大部分产品中还接入了大量三方的SDK。随之而来的是App安装包越来越大，界面加载越来越慢，运行速度越来越低。当界面响应时间超出用户能容忍的时间临界点后，大多数用户都会选择强制关闭该应用，不再等待响应。应用给用户留下了很卡，很笨重的印象后，将会大大提高用户的流失率。

CPU和GPU

CUP 中央处理器（CPU，central processing unit）对象的创建和销毁、对象属性的调整、布局计算、文本的计算和排版、图片格式转换和解码、图像的绘制（Core Graphics）

GPU 图形处理器（Graphics Processing Unit) 纹理（Texture）和顶点描述（三角形），应用变换（transform）、混合（合成）并渲染，然后输出到屏幕上。通常你所能看到的内容，主要也就是纹理（图片）和形状（三角模拟的矢量图形）两类

渲染过程

由上图可知：屏幕上显示视图，需要CPU和GPU一起协作，CPU 负责计算，将计算好的数据提交给GPU，GPU进行渲染并放入到缓冲区，然后视频控制器按照VSync信号逐行读取帧缓冲区的数据，经过数模转换传递为显示器，显示到屏幕上

缓冲机制

注意：在iOS中是双缓冲机制，有前帧缓冲、后帧缓冲。即GPU会预先渲染好一帧放入一个缓冲区内（前帧缓存），让视频控制器读取，当下一帧渲染好后，GPU会直接把视频控制器的指针指向第二个缓冲器（后帧缓存）。当你视频控制器已经读完一帧，准备读下一帧的时候，GPU会等待显示器的VSync信号发出后，前帧缓存和后帧缓存会瞬间切换，后帧缓存会变成新的前帧缓存，同时旧的前帧缓存会变成新的后帧缓存。

屏幕成像原理

1帧

解释 绿色的可以当做我们的手机屏幕，如果要显示一个页面，会发出一个垂直同步信号(Vsync) 代表这一帧的开始，然后发出水平同步信号(HSync)等最后一条结束，也就代表这一帧数据渲染完成。然后在进行下一帧的播放

卡顿产生的原因

卡顿

CPU将计算好的数据提供给GPU进行渲染，这时来一个垂直同信号VSync，将这一帧渲染到屏幕上，代表这一帧结束，然后进行下一帧的渲染。
上图，CPU消耗时间过长，交付给GPU时，垂直信号VSync到了，GPU还在渲染。下一帧，CPU把处理好的数据交付给GPU渲染屏幕，垂直信号到了，但是CPU还在渲染，就会把上一帧的数据显示到屏幕上，这就造成了卡顿。
因此，在CPU和GPU还在处理数据的时候，垂直信号VSync已经来了，便造成了卡顿

卡顿解决的主要思路

尽可能减少CPU、GPU资源消耗
按照60FPS的刷帧率，每隔16ms就会有一次VSync信号

卡顿优化——CPU

尽量用轻量级的对象(1,2,3数字的显示直接使用Int就行，不用使用NSNumber)，比如用不到事件处理的地方，可以考虑使用CALayer取代UIView
不要频繁地调用UIView的相关属性，比如Frame、bounds、transform等属性，尽量减少不必要的修改
尽量提前计算好布局，在有需要时一次性调整对应的属性，不要多次修改属性
Autolayout会比直接设置frame消耗更多的CPU资源
图片的size最好刚好跟UIImageView的size保持一致
控制一下线程的最大并发数量
- 文本处理（尺寸计算、绘制）

    // 文字计算
    [@"text" boundingRectWithSize:CGSizeMake(100, MAXFLOAT) options:NSStringDrawingUsesLineFragmentOrigin attributes:nil context:nil];
    
    // 文字绘制
    [@"text" drawWithRect:CGRectMake(0, 0, 100, 100) options:NSStringDrawingUsesLineFragmentOrigin attributes:nil context:nil];

图片处理（解码、绘制）


    UIImageView *imageView = [[UIImageView alloc] init];
    imageView.frame = CGRectMake(100, 100, 100, 56);
    [self.view addSubview:imageView];
    self.imageView = imageView;
    // 通过imageNamed加载图片，（加载上来的是经过压缩后的二进制数据，真正想要渲染到屏幕上，还需要解码成屏幕所需要的那种格式才会显示到屏幕上（解码是在主线程操作的，要是话费很长时间，就行形成卡顿））因此我们放在子线程，去解码，放在主线程显示
//    self.imageView.image = [UIImage imageNamed:@"timg"];

    dispatch_async(dispatch_get_global_queue(0, 0), ^{
        // 获取CGImage
        CGImageRef cgImage = [UIImage imageNamed:@"timg"].CGImage;

        // alphaInfo
        CGImageAlphaInfo alphaInfo = CGImageGetAlphaInfo(cgImage) & kCGBitmapAlphaInfoMask;
        BOOL hasAlpha = NO;
        if (alphaInfo == kCGImageAlphaPremultipliedLast ||
            alphaInfo == kCGImageAlphaPremultipliedFirst ||
            alphaInfo == kCGImageAlphaLast ||
            alphaInfo == kCGImageAlphaFirst) {
            hasAlpha = YES;
        }

        // bitmapInfo
        CGBitmapInfo bitmapInfo = kCGBitmapByteOrder32Host;
        bitmapInfo |= hasAlpha ? kCGImageAlphaPremultipliedFirst : kCGImageAlphaNoneSkipFirst;

        // size
        size_t width = CGImageGetWidth(cgImage);
        size_t height = CGImageGetHeight(cgImage);

        // context
        CGContextRef context = CGBitmapContextCreate(NULL, width, height, 8, 0, CGColorSpaceCreateDeviceRGB(), bitmapInfo);

        // draw
        CGContextDrawImage(context, CGRectMake(0, 0, width, height), cgImage);

        // get CGImage
        cgImage = CGBitmapContextCreateImage(context);

        // into UIImage
        UIImage *newImage = [UIImage imageWithCGImage:cgImage];

        // release
        CGContextRelease(context);
        CGImageRelease(cgImage);

        // back to the main thread
        dispatch_async(dispatch_get_main_queue(), ^{
            self.imageView.image = newImage;
        });
    });

卡顿优化——GPU

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

离屏渲染

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

离屏渲染消耗性能的原因

需要创建新的缓冲区
离屏渲染的整个过程，需要多次切换上下文环境，先是从当前屏幕（On-Screen）切换到离屏（Off-Screen）；等到离屏渲染结束以后，将离屏渲染缓冲区结果显示到屏幕上，又需要将上下文环境从离屏渲染切换到当前屏幕

哪些操作会触发离屏渲染

光栅化，layer.shouldRasterize = YES
遮罩， layer.mask
圆角，同时设置 layer.masksToBounds = YES 和 layer.cornerRadius大于0 （可以使用CoreGraphics绘制裁剪圆角，或者美工提供圆角）
阴影，但是设置了layer.shadowPath 就不会产生离屏渲染，（如果不设置，会默认是四周）

卡顿检测

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

可以使用第三方来检查

LXDAppFluecyMonitor

耗电

耗电的主要来源

来源

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

耗电优化

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

APP的启动

APP的启动可以分为2种
冷启动（Cold Launch）：从零开始启动APP
热启动（Warm Launch）：APP已经在内存中，在后台存活着，再次点击图标启动APP

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

通过添加环境变量可以打印出APP的启动时间分析（Edit scheme -> Run -> Arguments）
- DYLD_PRINT_STATISTICS设置为1

Total pre-main time: 517.71 milliseconds (100.0%)
         dylib loading time:  77.67 milliseconds (15.0%)
        rebase/binding time: 341.38 milliseconds (65.9%)
            ObjC setup time:  68.20 milliseconds (13.1%)
           initializer time:  30.33 milliseconds (5.8%)
           slowest intializers :
             libSystem.B.dylib :   5.86 milliseconds (1.1%)
    libMainThreadChecker.dylib :  15.35 milliseconds (2.9%)

如果需要更详细的信息，那就将DYLD_PRINT_STATISTICS_DETAILS设置为1

  total time: 934.78 milliseconds (100.0%)
  total images loaded:  258 (0 from dyld shared cache)
  total segments mapped: 767, into 102624 pages with 7415 pages pre-fetched
  total images loading time: 574.67 milliseconds (61.4%)
  total load time in ObjC:  54.87 milliseconds (5.8%)
  total debugger pause time: 400.53 milliseconds (42.8%)
  total dtrace DOF registration time:   0.18 milliseconds (0.0%)
  total rebase fixups:  2,723,929
  total rebase fixups time: 260.40 milliseconds (27.8%)
  total binding fixups: 286,643
  total binding fixups time:  18.46 milliseconds (1.9%)
  total weak binding fixups time:   0.42 milliseconds (0.0%)
  total redo shared cached bindings time:  26.57 milliseconds (2.8%)
  total bindings lazily fixed up: 0 of 0
  total time in initializers and ObjC +load:  25.74 milliseconds (2.7%)
                         libSystem.B.dylib :   2.44 milliseconds (0.2%)
               libBacktraceRecording.dylib :   3.09 milliseconds (0.3%)
                            CoreFoundation :   2.08 milliseconds (0.2%)
                                Foundation :   1.29 milliseconds (0.1%)
                libMainThreadChecker.dylib :  14.34 milliseconds (1.5%)
total symbol trie searches:    134026
total symbol table binary searches:    0
total images defining weak symbols:  22
total images using weak symbols:  62

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

dyld

dyld（dynamic link editor），Apple的动态链接器，可以用来装载Mach-O文件（可执行文件、动态库等）
启动APP时，dyld所做的事情有
1、装载APP的可执行文件，同时会递归加载所有依赖的动态库
2、当dyld把可执行文件、动态库都装载完毕后，会通知Runtime进行下一步的处理

runtime

启动APP时，runtime所做的事情有
1、调用map_images进行可执行文件内容的解析和处理
2、在load_images中调用call_load_methods，调用所有Class和Category的+load方法
3、进行各种objc结构的初始化（注册Objc类、初始化类对象等等）
4、调用C++静态初始化器和__attribute__((constructor))修饰的函数
5、到此为止，可执行文件和动态库中所有的符号(Class，Protocol，Selector，IMP，…)都已经按格式成功加载到内存中，被runtime 所管理

main

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

app启动

启动优化方案

dyld

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

runtime

用+initialize方法和dispatch_once取代所有的_attribute_((constructor))、C++静态构造器、Objc的load

main

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

安装包瘦身

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

资源（图片、音频、视频等）

采取无损压缩
去除没有用到的资源：https://github.com/tinymind/LSUnusedResources

无用的资源

可执行文件瘦身

编译器优化
Strip Linked Product、Make Strings Read-Only、Symbols Hidden by Default设置为YES(一般Xcode会自动设置为yes)
去掉异常支持，Enable C++ Exceptions、Enable Objective-C Exceptions设置为NO， Other C Flags添加-fno-exceptions
利用AppCode（https://www.jetbrains.com/objc/）检测未使用的代码：菜单栏 -> Code -> Inspect Code
编写LLVM插件检测出重复代码、未被调用的代码

LinkMap

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

linkMap

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

获取linkMap文件

1.在XCode中开启编译选项Write Link Map File \n
XCode -> Project -> Build Settings -> 把Write Link Map File选项设为yes，并指定好linkMap的存储位置

2.工程编译完成后，在编译目录里找到Link Map文件（txt类型) 默认的文件地址：~/Library/Developer/Xcode/DerivedData/XXX-xxxxxxxxxxxxx/Build/Intermediates/XXX.build/Debug-iphoneos/XXX.build/ \n\

程序

可以看到下面是项目每个类生成的.o文件

图片.png

iOS APP性能优化

CPU和GPU

屏幕成像原理

卡顿产生的原因

卡顿解决的主要思路

卡顿优化——CPU

卡顿优化——GPU

离屏渲染

卡顿检测

耗电

耗电优化

APP的启动

启动优化方案

安装包瘦身

LinkMap

相关文章

网友评论

延伸阅读

深度阅读

栏目导航

热点阅读

iOS 底层原理