前言: 随着项目的扩大和功能的增多,代码没有经过严格的调试和优化,要么任性地卡顿运行,要么就低调地崩溃,最后导致用户用着不开心,开发者也比较烦恼。
为了突破这个这个关卡其实并不难,首先开发者只要在Xcode自带的监控调试工具 Instruments 上花点功夫就能够让代码顺畅运行。工欲善其事,必先利其器。Instrument对于iOS开发来说,是发现并且解决问题的一把利器。Instruments 提供了很多检测功能,重点介绍一下我常用的几大类:
Analyze—静态分析
Leaks—内存泄露(动态内存泄露检测)
Time Profiler:检测分析代码的执行时间
界面显示的原理
iOS设备通常是60fps(每秒60帧),也就是说两帧相隔的时间是1/60秒,大概16.7ms。在这16.7ms中,为了显示一帧,需要如下工作
CPU计算好各个视图的位置,大小,对图片进行解码等,绘制成纹理交给GPU
GPU对收到的纹理进行混合,顶点变换,渲染到帧缓冲区
每16.7ms,一个时钟信号到达,帧缓冲区取出一帧,显示到屏幕。
也就是说,CPU或者GPU被大量占用的时候,都有可能在16.7ms中没办法完成一帧的绘制,导致时钟信号到来的时候,取得还是上一帧的内容,也就都有可能导致界面卡顿
离屏渲染
在iOS中,渲染通常分为CPU和GPU渲染两种,而GPU渲染又分为在GPU缓冲区和非GPU缓冲区两种
CPU渲染(软件渲染),CPU绘制成bitmap,交给GPU
GPU渲染(硬件渲染)
GPU缓冲区渲染
非GPU缓冲区渲染(额外开辟缓冲区)
通常,CPU渲染,和GPU非帧缓冲区内渲染统称为离屏渲染。因为,CPU和帧缓冲区是为图形图像显示做了高度优化的,速度较快。
什么情况下会触发离屏幕渲染?
用CoreGraphics的CGContext绘制的
在drawRect中绘制的,即使drawRect是空的
Layer具有Mask(比如圆角)或者Shadow
Layer的隔栅化shouldRasterize为True
文本(UILabel,UITextfield,UITextView,CoreText,UITextLayer等)
一,Analyze—静态分析
顾名思义,静态分析不需要运行程序,就能检查到存在内存泄露的地方。
1. 使用方法:打开Xcode,command + shift + B;或者Xcode - Product - Analyze;
2. 常见的三种泄露情形:
(1)创建了一个对象,但是并没有使用。Xcode提示信息: Value Stored to 'number' is never read 。翻译一下:存储在'number'里的值从未被读取过。
(2)创建了一个(指针可变的)对象,且初始化了,但是初始化的值一直没读取过。Xcode提示信息: Value Stored to 'str' during its initialization is never read
(3)调用了让某个对象引用计数加1的函数,但没有调用相应让其引用计数减1的函数。Xcode提示信息: Potential leak of an object stored into 'subImageRef' 。 翻译一下:subImageRef对象的内存单元有潜在的泄露风险。
iOS性能分析和优化
二,Leaks—内存泄露
Leaks是动态的内存泄露检查工具,需要一边运行程序,一边检测。
1.使用方法: 进入Xcode,command + control + i ;或者Xcode - Xcode - Open Developer Tool - Instruments; 或者Xcode - Product - Profile。选择Leaks。
一般用静态分析检查过的代码,内存泄露都比较少。测试了有3个项目能点的按钮都点了,能进的页面都进的,Leaks也没检测到泄露。
三,Time Profile
1,打开Time Profile,然后运行想要分析的App
iOS性能分析和优化
2.进入主界面,上下滚动List,让Time Profile采集数据,勾选右侧的Separate by Thread,按线程区分Invert Call Tree,逆向Call Tree,方便我们查看方法调用顺序Hide System Libraries,隐藏系统的库,因为通常系统的代码并不会影响性能
iOS性能分析和优化
3.可以选择一段时间,来分析这段时间CPU的使用情况
iOS性能分析和优化
4.找到占用时间最多的代码
iOS性能分析和优化
然后,双击占用最多的这一行,进入实际的代码,看看到底哪里占用比较多
iOS性能分析和优化
这里,我们看到是这一行代码cell.testLabel?.attributedText = mutableAttr。
占用最多的CPU时间。
我们先来看下整个方法代码,
TableViewCell其实很简单,就一个ImageView(带圆角,阴影),一个UILabel
cellForRowAtIndexPath里会随机的生成100个字符,然后用AttributeText来让UILabel显示
乍一看,问题应该是这个随机生成100个字符的函数啊
iOS性能分析和优化
因为,每一次CellForRow调用的时候,都会计算100次。然后,我们实际分析的时候,发现其实100次对显示来说,真不算什么,也不是卡顿的原因。
那么,为什么设置attributeText占用时间这么多呢?
其实很简单,attributeText是建立在TextKit上的,由于每一次显示都是随机的attributeText,每一次都要重新计算文本的大小,位置等等。另外,UIKit中,提供的文本渲染都是在CPU中进行的,渲染成Bitmap,然后交给GPU,所以导致设置attributeText的时候,占用很多时间。
这里不得不提到:一定不要过早优化,优化的时候尽量依赖于Instrument的分析结果,而不是自己的主观感受。尤其当你还是个新司机的时候。
网友评论