iOS性能优化相关知识(一)

前言
我们在面试中,经常会被问到一些问题,如:
“你在项目中是怎么优化内存的?”
“具体从哪几方面优化项目?”
“遇到过tableview卡顿吗?会造成卡顿的原因大致有哪些?”
“如何对tableview卡顿进行优化?”
……
诸如此类的一系列问题。
作者在通过学习之后,对以上问题做了一个初步的理解。

一、CPU和GPU
在屏幕成像的过程中,CPU和GPU起着至关重要的作用。
1.CPU(Central Processing Unit,中央处理器):对象的创建和销毁、对象属性的调整、布局计算、文本的计算和排版、图片的格式转换和解码、图像的绘制(Core Graphics)。
2.GPU(Graphics Processing Unit,图形处理器):纹理的渲染

我们对app的界面进行绘制的时候,是如何实现屏幕成像的呢?具体步骤如下图所示:

1)CPU对文本大小、格式、图片高度等一系列数据操作进行计算传给GPU。
2)GPU将这些数据转换成屏幕能显示的数据。GPU经过渲染操作,把数据存储到帧缓存中。iOS中是双缓存模式,叫做前缓存和后缓存。双缓存模式可以提高渲染效率。
4)视频控制器从帧缓存中读取数据显示到屏幕上。

二、屏幕成像原理
屏幕成像是由“帧”组合而成的。我们所看到的一个屏幕的内容,它显示在屏幕之前,都是通过一系列信号量来实现的。
首先它会发送一个垂直同步信号量(VSync),当这个信号量出现的时候就表示它即将显示一帧数据。接着就多次发送水平同步信号量(HSync),直到屏幕被填满。

三、卡顿产生的原因
通过一张图来理解


在上图中,我们假设红色线代表CPU,蓝色线代表GPU。
根据上面的内容我们知道,CPU通过一定时间的计算把数据传给GPU,GPU再经过渲染发送到帧缓存中,当出现一个垂直同步信号量的时候就会从帧缓存中拿到数据显示到屏幕。
在上图中,当第一个垂直同步信号量出现的时候,GPU刚好渲染完成,则能够完整的显示数据到屏幕。
在第二个垂直同步信号出现的时候,GPU已经早早的渲染好了数据,它也能够完整的显示到屏幕上。
在第三个垂直同步信号量出现的时候,我们看到由于GPU渲染时间过长,它还没有完全的渲染好信号量就出现了,那么此时GPU渲染的数据不完整。它就不会把这个数据显示到屏幕,而是会使用上一次的数据,也就是第二个垂直同步信号量的数据。这种情况我们称之为“掉帧”。
那么我们就会想,第三帧还没渲染好的数据该如何处理?
答案是:它会在下一个信号量出现的时候显示到屏幕上。然后再接着处理CPU和GPU的数据……
通过这个逻辑,我们可以由此得出一个结论,解决卡顿的思路就是尽可能减少CPU和GPU的资源消耗
我们还需要知道一个理论,我们肉眼所能感受到的不卡顿的情况一般是60FPS,就是说一秒钟刷新60帧。按照60FPS的刷帧率,每隔16ms就会有一次VSync,也就是说我们要在16ms内完成一次CPU计算和GPU的渲染操作才不会出现掉帧。

四、CPU层面的优化
1.尽量用轻量级的对象,比如用不到事件处理的地方,可以考虑使用CALayer取代UIView。
2.不要频繁地调用UIView的相关属性,比如frame、bounds、transform等属性,尽量减少不必要的修改。
3.尽量提前计算好布局,在有需要时一次性调整对应的属性,不要多次修改属性。
4.Autolayout会比直接设置frame消耗更多的CPU资源。
5.图片的size最好刚好跟UIImageView的size保持一致。
6.控制一下线程的最大并发数量。
7.尽量把耗时的操作放到子线程。如文本处理(尺寸计算、绘制)和图片处理(解码、绘制)
比如:我们平时通常设置一个图片的时候,都是直接把图片赋值给一个UIImageView对象

    imageView.frame = CGRectMake(100, 100, 100, 56);
    imageView.image = [UIImage imageNamed:@"timg"];
    [self.view addSubview:imageView];
    self.imageView = imageView;  

 我们知道图片能显示到屏幕上是需要把图片数据压缩转换成图片数据,再进行解码转换成屏幕能显示的数据显示到屏幕上的。
由于解码操作都是在主线程操作的,所以会占用CPU的资源。这个时候我们可以在子线程中对数据进行提前解码。

        // 获取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;
        });
    });
这段代码的大致思路就是把image源图转换成一个CGImage,再对图片进行解码。
解码的步骤就是创建一个图形上下文,把图片绘制到上下文中,再把解码后的文件换成UIImage。
此时UIImage的图片就是解码后的图片了,由于解码操作是在子线程中进行,会节约CPU的资源。

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

六、离屏渲染
1.概念:在OpenGL中,GPU有2种渲染方式
当前屏幕渲染(On-Screen Rendering):在当前用于显示的屏幕缓冲区进行渲染操作。
离屏渲染(Off-Screen Rendering):在当前屏幕缓冲区以外新开辟一个缓冲区进行渲染操作。
2.离屏渲染消耗性能的原因:需要创建新的缓冲区。
离屏渲染的整个过程,需要多次切换上下文环境,先是从当前屏幕(On-Screen)切换到离屏(Off-Screen),离屏渲染结束以后,将离屏缓冲区的渲染结果显示到屏幕上,又需要将上下文环境从离屏切换到当前屏幕
3.哪些操作会触发离屏渲染?
--光栅化,layer.shouldRasterize = YES
--遮罩,layer.mask
--圆角,同时设置layer.masksToBounds = YES、layer.cornerRadius大于0。考虑通过CoreGraphics绘制裁剪圆角,或者叫美工提供圆角图片

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

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

iOS性能优化相关知识(二)

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 212,686评论 6 492
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 90,668评论 3 385
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 158,160评论 0 348
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 56,736评论 1 284
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 65,847评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 50,043评论 1 291
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,129评论 3 410
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,872评论 0 268
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,318评论 1 303
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,645评论 2 327
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,777评论 1 341
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,470评论 4 333
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,126评论 3 317
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,861评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,095评论 1 267
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,589评论 2 362
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,687评论 2 351

推荐阅读更多精彩内容