iOS面试题,性能优化篇! |
您所在的位置:网站首页 › 面试题iOs性能优化 › iOS面试题,性能优化篇! |
1.形成tableView卡顿的缘由有哪些? 1.最经常使用的就是cell的重用, 注册重用标识符 若是不重用cell时,每当一个cell显示到屏幕上时,就会从新建立一个新的cellhtml 若是有不少数据的时候,就会堆积不少cell。ios 若是重用cell,为cell建立一个ID,每当须要显示cell 的时候,都会先去缓冲池中寻找可循环利用的cell,若是没有再从新建立cellc++ 2.避免cell的从新布局 cell的布局填充等操做 比较耗时,通常建立时就布局好面试 如能够将cell单独放到一个自定义类,初始化时就布局好swift 3.提早计算并缓存cell的属性及内容 当咱们建立cell的数据源方法时,编译器并非先建立cell 再定cell的高度xcode 而是先根据内容一次肯定每个cell的高度,高度肯定后,再建立要显示的cell,滚动时,每当cell进入凭虚都会计算高度,提早估算高度告诉编译器,编译器知道高度后,紧接着就会建立cell,这时再调用高度的具体计算方法,这样能够方式浪费时间去计算显示之外的cell缓存 4.减小cell中控件的数量 尽可能使cell得布局大体相同,不一样风格的cell可使用不用的重用标识符,初始化时添加控件,网络 不适用的能够先隐藏数据结构 5.不要使用ClearColor,无背景色,透明度也不要设置为0 渲染耗时比较长多线程 6.使用局部更新 若是只是更新某组的话,使用reloadSection进行局部更 7.加载网络数据,下载图片,使用异步加载,并缓存 8.少使用addView 给cell动态添加view 9.按需加载cell,cell滚动很快时,只加载范围内的cell 10.不要实现无用的代理方法,tableView只遵照两个协议 11.缓存行高:estimatedHeightForRow不能和HeightForRow里面的layoutIfNeed同时存在,这二者同时存在才会出现“窜动”的bug。因此个人建议是:只要是固定行高就写预估行高来减小行高调用次数提高性能。若是是动态行高就不要写预估方法了,用一个行高的缓存字典来减小代码的调用次数便可 12.不要作多余的绘制工做。在实现drawRect:的时候,它的rect参数就是须要绘制的区域,这个区域以外的不须要进行绘制。例如上例中,就能够用CGRectIntersectsRect、CGRectIntersection或CGRectContainsRect判断是否须要绘制image和text,而后再调用绘制方法。 13.预渲染图像。当新的图像出现时,仍然会有短暂的停顿现象。解决的办法就是在bitmap context里先将其画一遍,导出成UIImage对象,而后再绘制到屏幕; 14.使用正确的数据结构来存储数据。 2.如何提高 tableview 的流畅度?本质上是下降 CPU、GPU 的工做,从这两个大的方面去提高性能。 CPU:对象的建立和销毁、对象属性的调整、布局计算、文本的计算和排版、图片的格式转换和解码、图像的绘制 GPU:纹理的渲染 卡顿优化在 CPU 层面 尽可能用轻量级的对象,好比用不到事件处理的地方,能够考虑使用 CALayer 取代 UIView 不要频繁地调用 UIView 的相关属性,好比 frame、bounds、transform 等属性,尽可能减小没必要要的修改 尽可能提早计算好布局,在有须要时一次性调整对应的属性,不要屡次修改属性 Autolayout 会比直接设置 frame 消耗更多的 CPU 资源 图片的 size 最好恰好跟 UIImageView 的 size 保持一致 控制一下线程的最大并发数量 尽可能把耗时的操做放到子线程 文本处理(尺寸计算、绘制) 图片处理(解码、绘制) 卡顿优化在 GPU层面 尽可能避免短期内大量图片的显示,尽量将多张图片合成一张进行显示 GPU能处理的最大纹理尺寸是 4096x4096,一旦超过这个尺寸,就会占用 CPU 资源进行处理,因此纹理尽可能不要超过这个尺寸 尽可能减小视图数量和层次 减小透明的视图(alphaScheme-->Edit Scheme->Run->Auguments中,将环境变量DYLD_PRINT_STATISTICS设为YES,优化需如下方面入手 dylib loading time 核心思想是减小dylibs的引用 合并现有的dylibs(最好是6个之内) 使用静态库 rebase/binding time 核心思想是减小DATA块内的指针 减小Object C元数据量,减小Objc类数量,减小实例变量和函数(与面向对象设计思想冲突) 减小c++虚函数 多使用Swift结构体(推荐使用swift) ObjC setup time 核心思想同上,这部份内容基本上在上一阶段优化事后就不会太过耗时 initializer time 使用initialize替代load方法 减小使用c/c++的attribute((constructor));推荐使用dispatch_once() pthread_once() std:once()等方法 推荐使用swift 不要在初始化中调用dlopen()方法,由于加载过程是单线程,无锁,若是调用dlopen则会变成多线程,会开启锁的消耗,同时有可能死锁 不要在初始化中建立线程 4.如何下降APP包的大小下降包大小须要从两方面着手 可执行文件 编译器优化:Strip Linked Product、Make Strings Read-Only、Symbols Hidden by Default 设置为 YES,去掉异常支持,Enable C++ Exceptions、Enable Objective-C Exceptions 设置为 NO, Other C Flags 添加 -fno-exceptions 利用 AppCode 检测未使用的代码:菜单栏 -> Code -> Inspect Code 编写LLVM插件检测出重复代码、未被调用的代码 资源(图片、音频、视频 等) 优化的方式能够对资源进行无损的压缩 去除没有用到的资源 5.如何检测离屏渲染与优化检测,经过勾选Xcode的Debug->View Debugging-->Rendering->Run->Color Offscreen-Rendered Yellow项。优化,如阴影,在绘制时添加阴影的路径6.怎么检测图层混合一、模拟器debug中color blended layers红色区域表示图层发生了混合 二、Instrument-选中Core Animation-勾选Color Blended Layers 避免图层混合: 确保控件的opaque属性设置为true,确保backgroundColor和父视图颜色一致且不透明如无特殊须要,不要设置低于1的alpha值确保UIImage没有alpha通道UILabel图层混合解决方法: iOS8之后设置背景色为非透明色而且设置label.layer.masksToBounds=YES让label只会渲染她的实际size区域,就能解决UILabel的图层混合问题 iOS8 以前只要设置背景色为非透明的就行 为何设置了背景色可是在iOS8上仍然出现了图层混合呢? UILabel在iOS8先后的变化,在iOS8之前,UILabel使用的是CALayer做为底图层,而在iOS8开始,UILabel的底图层变成了_UILabelLayer,绘制文本也有所改变。在背景色的四周多了一圈透明的边,而这一圈透明的边明显超出了图层的矩形区域,设置图层的masksToBounds为YES时,图层将会沿着Bounds进行裁剪 图层混合问题解决了 7.平常如何检查内存泄露?目前我知道的方式有如下几种 Memory Leaks Alloctions Analyse Debug Memory Graph MLeaksFinder 泄露的内存主要有如下两种: Laek Memory 这种是忘记 Release 操做所泄露的内存。 Abandon Memory 这种是循环引用,没法释放掉的内存。 须要iOS开发学习资料、大厂面试真题,可加 iOS技术探讨群:624212887,群文件直接获取 点击加入:与 2000+iOS开发者一块儿探讨交流以下图所示: |
今日新闻 |
点击排行 |
|
推荐新闻 |
图片新闻 |
|
专题文章 |
CopyRight 2018-2019 实验室设备网 版权所有 win10的实时保护怎么永久关闭 |