iOS的性能优化这一块，应该怎么答呢？很多时候，咱们的学员一说到iOS的性能优化只会想到UITableViewCell的重用这点。也就只能说到这点。但这是很肤浅的一点。首先要理解性能这个词，还有优化这个词。分开看。性能，那么就是越快越好。优化，那就是你能多快就多快。假如面试官问你关于性能优化这块，我给的建议是：
第一个方面是：就是你所知道UITableViewCell的优化，涉及到它的重用，以及cell的行高计算问题。虽然说很基础，但还是要答。尽可能的说得详细一些。
第二个方面是：网络请求方面的优化，像我们利用第三方AFN的时候，可以做一层网络隔离，减少对第三方的依赖性。还有就是涉及到网络请求，在做UI功能设计的时候，一定要尽可能的减少同一时间多次网络请求的可能性。在请求数据的时候，一定一定要用JSON，如果以后你们公司的后台还用的是XML,那就代表你在网络数据解析这块会浪费很多性能。JSON跟XML大家都学过。两者都是常见的数据编码方式。压缩模式的效率在很大程度上取决于待压缩数据，而通常情况下，JSON都是一种最高效的模式。
第三个方面是：图片加载的优化。其实这也算另外一个问题，说的就是咱们很熟悉的SDWebImage框架的使用。有没有做图片的缓存，当本地没有图片的时候怎么处理，有图片的时候怎么处理。加载图片的时候有没有在异步加载啊。这些也是优化，是不是我们自己做的，不是，但是你说的时候要有种指点江山的气魄，是，他就是这样，我就是会。
第四个方面是：在编码过程中。能用懒加载的有没有懒加载，能用单例的有没有用单例，能封装的有没有封装。再举个例子，你看，我们很多app，都有很多控制器的基础搭建都是很像的，那么这个时候你有没有考虑使用一个baseController，在里面设置一些共有的属性，然后后续的controller来继承他。切圆角图片的时候用的是什么技术，有没有做本地数据的缓存等等。
以上说的几点都是跟app的运行速度有关，这就是性能优化。但是，你面试的时候答这些，对不对，行不行，可以不可以。我的答案是，对，行，可以。说这些都没问题。但是，还可以更好。在坐的都是有三年经验的iOS工程师，只看到这些，够吗，不够。我们眼光要长远些，一个app的开发过程是短暂的。后面的是永无止境的维护，更新，迭代。那么，在我们这些三年工作经验的工程师面前，项目维护起来方便不方便，代码阅读起来直接不直接，这其中节省的时间还有你那为数不多的脑细胞，难道就是不优化了吗。这部分的优化，优化的是你的工作时间。那么，这部分优化应该体现在哪里，大家都知道的，只是没想到可以这么答。我觉得有这么几个方面可以节省我们后期维护代码的时间。代码编写的规范，声明在哪个地方，方法实现在哪个地方，懒加载在哪个地方，代理写在哪里。这些地方都是固定的，就是为了方便查找节省时间。还有，有没有严格遵守MVC或者MVVM设计模式，打造轻量级的Contreller。给大家讲一个小故事，就是我们的学员出去了，一直都在讽刺别人公司的代码。要么没有懒加载，要么就是一个Controller里面好几千行代码，在他们看来就是无耻，垃圾，败类，呸。还有就是方法名字有没有取好，属性名有没有取好。有些人觉得，方法名还要想好啊，这有什么影响吗。有，很大的影响你阅读代码的速度。一个优秀的方法名，你只要一看这个方法名字，你都不用看代码了，你就大概知道这方法是用来干什么的了。属性名也是一样的。还有就是项目文档要编写的很清晰，这个类是干嘛的，这个功能实现的逻辑是什么。这些，就是优化。当然还有很多，结合你们自己的理解去讲，至少比你只讲什么UITableViewCell的优化好吧。
再整理一下，从以下几个方面1.性能优化，包括内存优化，速度优化，速度优化主要是多线程和后台加载。然后结合一个实例来回答，比如说tableView的性能优化。重用是内存优化的一个体现，异步绘制就是速度优化的一个体现。2. 代码优化。包括严格遵循代码规范，项目的文件和文件夹结构按mvc或者mvvc的架构来搭建，不要弄成一坨。具体的实现能抽成函数，抽成函数，能封装成类的封成类，结合具体的项目的架构来谈。3.第三个不太重要的是程序的体积可以优化。这样下载速度较快，也对内存的压务会小一些。
补充下大神的iOS优化性能文章：
