iOS-APP性能优化的那些事

前言

本人在这家公司已经三年多了，这款三年多我一直在作的APP也烂熟于心，APP也0到1到目前的500万的用户量；对于APP的功能来讲也是比较全面的，用到的技术知识点也比较多吧，APP的优化也是一直在作的事情，并且APP性能的优化也不是一朝一夕的事情，在此离别之际，我将详细说明讲解一下我在三年里对APP性能优化方面作过的一些事，你们仁者见仁智者见智，也欢迎你们进群提供宝贵的意见和建议！

这里我主要讲性能方面的优化，代码方面的优化或者说API包方面的优化请看个人另外一篇博文：

👉 iOS-APP包的瘦身之旅（从116M到如今的36M的减肥之路）👈

基础优化

使用ARC，如今的iOS开发你们用的都是ARC，几乎没有人再去使用MRC了，使用ARC的好处就是不用再时时刻刻注意要释放建立的对象了；避免使用xib或者storyboard。

这里说一下xib和sb的缺点吧，以下：

1.占用API包比较大；

2.致使APP启动时间比较耗时，由于在APP启动main()之前须要加载他们；

3.加载速度比较慢；

4.后期的版本更新迭代维护时间成本比较高；

5.多人开发容易引发冲突.

列表图片优化

列表不论在哪个APP中是使用最为普遍的一款控件了，在个人APP中也不例外，咱们的APP只要功能列表相似于微信的朋友圈，图片有0~9张的形式还能够是视频文件，以下图：

先说一说图片吧，若是一个列表都是9张图片，列表在加载和滑动的时候会耗用过多的内存；我在这里是把图片这一块单独抽出来作一个图片资源的封装，而后根据建立的图片容器（UIImageView）的大小加载缩略图，咱们公司的APP存储用的是七牛云存储，因此在获取图片资源的时候，只须要设置对应的字段就能够拿到缩略图了，点击的查看大图的时候才查看原图；

再说说视频，视频的处理逻辑和图片差很少，这里在CELL上咱们使用一个UIImageView来替代视频播放器，能够去出视频的第一帧做为封面，点击图片的时候才调用咱们封装好的视频播放组件。

复用机制

说道复用，咱们可能经常使用的有CELL的复用，其实咱们也能够本身写咱们的服用，就好比上图中的列表，咱们通常采用的思路就是在主控制器上添加一个UIScrollView,再根据有多少个小标题类型建立多少个子控制器，接着把子控制器添加到主控制器的childViewControllers中，最后把子控制器的视图添加到UIScrollView上，有没有更节省内存空间的作法呢？？？

固然有的，咱们能够只建立5个控制器而后丢到咱们的可重用数组中，根据每次滑动去加载不一样的缓存数据；

还好比我在直播间建立刷礼物的视图动画的时候，由于最多只能显示三条，那么我只会建立三个视图，当有大于三条的礼物信息过来的时候也只会建立三个视图，而后丢进个人可重用数组里面，每一个视图动画完成之后才从新复制Model，以下图左下角的礼物动画最多三个，最少没有：

就如上面所说，在项目中咱们能够在不少地方建立属于咱们本身的重用机制！

离屏渲染

在开发中，咱们经常使用有圆角处理、阴影、遮罩等等；先说说圆角优化吧，咱们通常设置圆角的方式以下：

view.layer.cornerRadius = 10;
view.layer.masksToBounds = YES;
复制代码

这样处理的渲染机制是GPU在当前屏幕缓冲区外新开辟一个渲染缓冲区进行工做，也就是离屏渲染，这会给咱们带来额外的性能损耗，若是这样的圆角操做达到必定数量，会触发缓冲区的频繁合并和上下文的的频繁切换，性能的代价会宏观地表如今用户体验上——掉帧。

优化方案：

a.能够作一个透明的png图片盖在上面；

b.使用贝塞尔曲线UIBezierPath和Core Graphics框架画出一个圆角；

c.使用CAShapeLayer和UIBezierPath设置圆角；

d.也能够将图片的处理放在服务端（好比：七牛云储存就能够设置图片的圆角）;

e.尽可能把view设置成不透明的。

说明：离屏渲染还能够作不少东西，具体的能够自行查找！

懒加载

这里的懒加载主要说的是懒加载思想，能够懒加载的类型有不少，固然好处有不少，最主要的是能够节省内存资源；

重大开销对象

咱们在APP使用过程当中会用到不少重大开销对象（好比NSDateFormatter和 NSCalendar），如咱们在列表须要计算用户年龄的时候会常常用到NSDateFormatter，还有一些时间的格式化输出，或者在网络请求的时候须要传一些时间戳，因此咱们能够把NSDateFormatter放在单利里面，这样就不用常常建立了，其余的也是一样的道理。

还有就是，像年龄生日什么的最好不要由前端APP来计算，最好放在服务器上，由服务端计算好而后再传给咱们。

内存警告

若是程序在运行过程当中发生了内存警告（didReceiveMemoryWarning），咱们须要快速应急处理一下，不要用不了多久APP就会被杀死掉，所在在收到内存警告主要思路就是想着去清理栈上的东西，之后咱们能够作如下几点：

a.清理不须要的已经建立的对象，不管是试图仍是工具类；

b.释放单利里面不须要的对象，好比上文提升过得重大开销对象；

c.若是有正在下载的任务，取消或者暂停所有任务；

d.若是使用了SDWebImage，能够清理一下缓存clearMemory；

主线程流畅

不要阻塞主线程，要保证主线程的流程性；咱们不要把一些重大开销对象放到主线程里面，咱们能够建立子线程去处理这些事情；好比多个网络请求结束一块儿刷新UI、多个动画效果、数据的读写操做等等；

数据缓存

作缓存这个事情，一方面减少内存的小号，还有很重要的一方面就是优化用户体验；能够作缓存的东西不少，咱们能够对数据接口进行缓存，还能够对WebView进行缓存，还有图片缓存、高度缓存等等；

在这里不得不说一下，数据存储了；咱们在作缓存的时候选择正确合适的存储方式也很难重要，固然你们也能够根据项目的实际需求来选择存储，咱们公司的APP本地存储我选择的是SQLite，管理类是我基于FMDB的又一次封装，相信请参考：

👉《iOS-基于FMDB的操做封装，模型对象的增删改查》👈

网络API优化

这个优化不仅仅需是前端小伙伴的事，还须要后端开发人员的配合，避免一些没必要要数据的返回，更要避免在APP端处理或者计算太多东西，好比年龄、星座的计算；即便后端的小伙伴把一些没必要要的数据返回了，咱们在建立数据模型Model的时候能够选择不去接收！

PS：这里我须要吐槽一下，之前公司有个java后端，返回的数据所有是一个表的实体类，管你有用没用，直接一股脑的全给你，本身去计算和本身去查找，那真叫一个心累啊，因此一个优秀的API开发工程师也是一个很是重要的缘由！

自动释放池

自动释放池（autoreleasepool）在MRC的时代真是用的很是多，可是如今的项目都是ARC，自动释放池用的也就比较少了，由于有系统帮咱们监管，可是若是咱们一个页面建立了太多的类或者对象，若是等页面销毁的时候由系通通一释放不免会出现一个峰值影响总体性能，这时候咱们就能够考虑使用autoreleasepool了，避免峰值的出现！👏

APP启动优化

在AppDelegate里面咱们会写一些不少东西，你写的东西越多越影响APP的冷启动时间就会越长，所以咱们须要对AppDelegate进行减负，具体如何减负你们能够根据各自项目的实际状况，第一能够删除一些不是必须的东西；第二能够把一些东西写在别的地方（如RootViewController），我在APP的RootViewController写的东西好比IM聊天的配置初始化登陆，一些未处理的任务，还有一些版本的坚持和缓存的清理等等！

结束语

原文地址：zfj1128.blog.csdn.net/article/det… 欢迎各位大神补充和纠正！

欢迎你们进群交流：365152048