iOS 底层原理

iOS APP性能优化

2019-08-19  本文已影响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

    // 文字计算
    [@"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

离屏渲染

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

离屏渲染消耗性能的原因

哪些操作会触发离屏渲染

卡顿检测

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

可以使用第三方来检查

LXDAppFluecyMonitor

耗电

耗电的主要来源

来源

耗电优化

APP的启动

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

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

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%)

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

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

app启动

启动优化方案

dyld

runtime

main

安装包瘦身

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

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

无用的资源

可执行文件瘦身

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
上一篇 下一篇

猜你喜欢

热点阅读