性能优化
内存优化
布局优化
启动优化
今日头条启动优化
- 纯代码方式而不是storyboard加载首页UI。
- 对didFinishLaunching里的函数考虑能否挖掘可以延迟加载或者懒加载，需要与各个业务方pm和rd共同check 对于一些已经下线的业务，删减冗余代码。
- 对于一些与UI展示无关的业务，如微博认证过期检查、图片最大缓存空间设置等做延迟加载
- 对实现了+load()方法的类进行分析，尽量将load里的代码延后调用。
- 上面统计数据显示展示feed的导航控制器页面(NewsListViewController)比较耗时，对于viewDidLoad以及viewWillAppear方法中尽量去尝试少做，晚做，不做。
体积优化
图片优化
- 使用一些工具来检测unused文件
文档资源的优化
是否有不必要的文档资源，如果过期的旧版本所需要的文档资源 清理即可。
优化文档资源大小，主要是优化精简文档内容。
删除FrameWork中无用mach-O文件
二进制包优化
编译选项优化
Optimization Level 使用Fastest, Smalllest 该选项对安装包大小影响几无，但可以提高app的性能。参考wwdc 2013-Session408 Optimize Your Code Using LLVM
Strip Linked Product 设置为YES 需要注意的是Strip Linked Product也受到Deployment Postprocessing设置选项的影响。在Build Settings中，我们可以看到， Strip Linked Product是在Deployment这栏中的，而Deployment Postprocessing相当于是Deployment的总开关。记得把Deployment Postprocessing也设置为YES， 该选项对安装包大小的影响非常大， 以头条客户端为例，如果不开启此设置，ipa大小是48MB，上线后appstore上显示的大小是65MB， 我们开启了此配置后，ipa大小变成40MB， appstore上显示45MB。 优化效果还是非常明显的。 PS：Deployment Postprocessing这个配置项如果使用xcode打包，xcode会默认把这个变量置为YES， 如果使用脚本打包，记得设置。
Symbols Hidden by Default设置为YES
Make Strings Read-Only 设置为YES
网络优化
三方面考虑:
针对链接建立环节的优化
针对链接传输数据量的优化
针对链接复用的优化
针对链接建立环节的优化
在API发起请求建立链接的环节，大致会分这些步骤:
发起请求
DNS域名解析得到IP
根据IP进行三次握手（HTTPS四次握手），链接建立成功
其实要解决的问题就是网络层该不该为此API调用发起请求
优化
使用缓存手段减少请求的发起次数
使用策略来减少请求的发起次数
原则：
能不发请求的就尽量不发请求，必须要发请求时，能合并请求的就尽量合并请求。然而，任何优化手段都是有前提的，而且也不能保证对所有需求都能起作用，有些API请求就是不符合这些优化手段前提的，那就老老实实发请求吧。不过这类API请求所占比例一般不大，大部分的请求都或多或少符合优化条件，所以针对发送请求的优化手段还是值得做的
DNS域名解析做的优化
问题
移动设备上网的需求也特别频繁，专门为我们这个App所做的DNS缓存很有可能会被别的DNS缓存给挤出去被清理掉
国内的互联网环境由于GFW的存在，就使得DNS服务速度会比正常情况慢不少
国内的网络环境分北网通南电信（当然实际情况更复杂，这里随便说说），不同服务商之间的连接，延时是很大的，需要想办法让用户在最适合他的IP上给他提供服务，那么就针对绕过DNS服务的手段有一个额外要求：尽可能不要让用户使用对他来说很慢的IP
优化
索性直接走IP请求, 本地有一份IP列表，这些IP是所有提供API的服务器的IP，每次应用启动的时候，针对这个列表里的所有IP取ping延时时间，然后取延时时间最小的那个IP作为今后发起请求的IP地址
建立连接的优化
手段跟DNS域名解析的优化手段是一样
一般都是在应用启动的时候获得本地列表中所有IP的ping值，然后通过NSURLProtocol的手段将URL中的HOST修改为我们找到的最快的IP。另外，这个本地IP列表也会需要通过一个API来维护，一般是每天第一次启动的时候读一次API，然后更新到本地
针对链接传输数据量的优化
传输的数据少了，那么自然速度就上去了。就是压缩。各种压缩