App瘦身数据库
资源瘦身缓存
使用tinypng压缩PNG图片。视频能够经过 Final cut等软件进行分辨率压缩。音频则下降码率便可。性能优化
非必须资源文件能够放到本身服务器上服务器
启动图使用 LaunchScreen.storyboard,启动图在一个项目资源中占比其实蛮大的,可是使用 LaunchScreen.storyboard 只须要设置一张ImageView便可。闭包
IconFont的使用很方便,项目中图标太多或者随时须要转换图标颜色的话,建议使用并发
放弃使用 Realm异步
Realm,听说是目前是性能最好的移动端数据库。可是在三方库中能够看到,Realm 的支持占了很大的比重,大约在 8M 左右。可是若是使用 FMDB 话只须要192KB,而 CoreData 几乎能够忽略不计。布局
删除重复代码性能
重复代码的审核、无用的开源库删除优化
性能优化
imageWithContentsOfFile 、 Assets.xcassets
对于大的图片且偶尔须要显示的应放到工程目录下,不要放到Assets.xcassets中;并使用imageWithContentsOfFile加载不让系统缓存
对于常常须要展现的小图片放到Assets.xcassets中让系统缓存,使用imageNamed加载
尽可能使用非逃逸闭包
非逃逸闭包是有利于内存优化的,因此尽可能使用非逃逸闭包
NSSet、NSArray
NSSet(用hash实现)和NSArray功能性质同样,用于存储对象,属于集合。可是和NSArray不同的是它属于 “无序集合”,在内存中存储方式是不连续的,而NSArray是“有序集合”它内存中存储位置是连续的。
因此在集合中寻找一个元素的时候使用NSSet,而若是须要循环集合中的全部对象来找到所须要的目标则使用NSArray
页面卡顿
屏幕显示图像的原理
CPU(中央处理器)
对象的建立和销毁,对象属性的调整、布局计算、文本的计算和排版、图片格式转码和解码、图像的绘制(Core Graphics)
GPU(图形处理器)
纹理的渲染(OpenGL)
FrameBuffer(帧缓存)
一、CPU计算控件的位置、大小
二、计算完成后CPU会将这些数据提交给GPU来进行渲染
三、GPU将收到的数据转成屏幕能显示的数据格式,缓存到在FrameBuffer
四、而后视频控制器从FrameBuffer读取的数据显示在显示器上
卡顿产生的缘由和解决方案
因为垂直同步的机制,若是在一个 VSync 时间内,CPU 或者 GPU 没有完成内容提交,则那一帧就会被丢弃,等待下一次机会再显示,而这时显示屏会保留以前的内容不变。这就是界面卡顿的缘由。
从上面的图中能够看到,CPU 和 GPU 不论哪一个阻碍了显示流程,都会形成掉帧现象。因此开发时,也须要分别对 CPU 和 GPU 压力进行评估和优化。
卡顿优化-CPU
一、尽可能用轻量级的对象,好比用不到事件处理的地方,能够考虑使用CAlayer取代UIView
二、不要频繁地跳用UIVIew的相关属性,好比frame、bounds、transform等属性,尽可能减小没必要要的修改
三、尽可能提早计算好布局,在有须要时一次性调整对应的布局,不要屡次修改属性
四、Autolayout会比直接设置frame消耗更多的CPU资源
五、图片的size最好恰好跟UIImageView的size保持一致
六、控制一下线程的最大并发数量
七、尽可能把耗时的操做放到子线程
八、文本处理(尺寸的计算,绘制)
九、图片处理(解码、绘制)
卡顿优化-GPU
一、尽可能减小视图数量和层次
二、GPU能处理的最大纹理尺寸是4096x4096,一旦超过这个尺寸,就会占用CPU资源进行处理,因此纹理尽可能不要超过这个尺寸
三、尽可能避免短期内大量图片的显示,尽量将多张图片合成一张图片显示
四、减小透明的视图(alpha<1),不透明的就设置opaque为yes
五、尽可能避免出现离屏渲染
离屏渲染
指的是在GPU在当前屏幕缓冲区之外开辟一个缓冲区进行渲染操做
致使产生离屏渲染的缘由:
shouldRasterize(光栅化)
shadows(阴影)
edge antialiasing(抗锯齿)
group opacity(不透明)
圆角(当和maskToBounds一块儿使用时才会触发)
渐变
可经过 Instruments 的 Core Animation 检测离屏渲染。
TableView 调优
提早计算好cell的高度,缓存在相应的数据源模型中,减小CPU的计算时间
尽量的下降Storyboard、Xib等使用度
异步绘制
减小层级
Cell中的view尽量不要使用透明
避免离屏渲染