关于性能包括很多内容

一、架构的优化

1、调整设计模式，设计模式不是一成不变的，我们可以根据自己的项挑选和自己的设计模式，但是随着项目业务的发展，可以就不再适合，那么就需要改变，比如：mvc，mvp mvvm，viper，mvc-vp，mvmvm，等等，后面两个是根据项目的发展二产生 

2、架构中的各个部分，减少依赖，尽量减少通信，做到各司其职，不相互依赖，比如：网络请求，数据处理，绘画处理，UI定制，跳转处理，通信处理，协议处理，支付模块。。。。。。。。。各个部分的相互关联，通过预留的类似挂钩放，柳铆的连接方式，可以随意拆卸，重组

3、架构的改版，需要根据业务，重新设计数据库的结构和前面的架构

二、界面的优化

1、尽量把views 设为不透明的

2、避免过于庞大的xib

3、imageviews 中调整图片的大小，如果要在UIImageView中显示一个来自bundle的图片，你应保证图片的大小和UIImageView的大小相同。在运行中缩放图片是很耗费资源的，特别是UIImageView嵌套在UIScrollView中的情况下。

如果图片是从远端服务加载的你不能控制图片大小，比如在下载前调整到合适大小的话，你可以在下载完成后，最好是用background thread，缩放一次，然后在UIImageView中使用缩放后的图片

4、正确设定背景图片

（1）全屏背景图，在view中添加一个UIImageView作为一个子View

（2）只是某个小的view的背景图，你就需要用UIColor的colorWithPatternImage来做了，它会更快地渲染也不会花费很           多内存

5、Shadow Path

 Core Animation不得不先在后台得出你的图形并加好阴影然后才渲染，这开销是很大的。使用shadowPath的话就避免了这个问题。使用shadow path的话iOS就不必每次都计算如何渲染，它使用一个预先计算好的路径。但问题是自己计算path的话可能在某些View中比较困难，且每当view的frame变化的时候你都需要去update shadow path.

6、Instrument优化动画性能的经历

Apple的instrument为开发者提供了各种template去优化app性能和定位问题。很多公司都在赶feature，并没有充足的时间来做优化，导致不少开发者对instrument不怎么熟悉。但这里面其实涵盖了非常完整的计算机基础理论知识体系，memory，disk，network，thread，cpu，gpu等等，顺藤摸瓜去学习，是一笔巨大的知识财富。动画性能只是其中一个template，重点还是理解上面问题当中CPU GPU如何配合工作的知识。

三、app启动的优化

1、app启动时，减少资源的加载，

2、app启动时，减少网络请求，减少数据的传输，等用到时再去请求，也需要架构的设计支持

3、第三方注册，非必要的第三方注册不要在进入app时就调用注册等，

总结：你能做的就是使它尽可能做更多的异步任务，比如加载远端或者数据库数据，解析数据。避免过于庞大的XIB，因为他们是在主线程上加载的。所以尽量使用没有这个问题的Storyboards吧！一定要把设备从Xcode断开来测试启动速度

四、耗电量的优化

耗电量的消耗，主要来自，界面的渲染，网络请求，软件内部动态的消耗，事件的处理，资源的消耗占用

五、线程的优化

其他的地方，单独说线程

六、网络的优化

1、避免日期格式转换。如果你要用NSDateFormatter来处理很多日期格式，应该小心以待。就像先前提到的，任何时候重用NSDateFormatters都是一个好的实践。如果你可以控制你所处理的日期格式，尽量选择Unix时间戳。你可以方便地从时间戳转换到NSDate:

2、下载文件，下载压缩包，在项目中解压缩

3、如果某个接口返回数据量太大，那么需要在必要的流程接口中提前返回一部分内容，在调用这个接口时，再加载内容，

七、项目瘦身优化

1、去除多余的代码

2、去除多少图片，尽量使用绘制图像

3、代码抽离，多复用代码

4、数据处理放在服务端

八、缓存的优化

1、NSUserDefaults的问题是什么？虽然它很nice也很便捷，但是它只适用于小数据，比如一些简单的布尔型的设置选项，再大点你就要考虑其它方式了

2、XML这种结构化档案呢？总体来说，你需要读取整个文件到内存里去解析，这样是很不经济的。使用SAX又是一个很麻烦的事情。

3、NSCoding？不幸的是，它也需要读写文件，所以也有以上问题。

4、在这种应用场景下，使用SQLite 或者 Core Data比较好。使用这些技术你用特定的查询语句就能只加载你需要的对象。

5、在性能层面来讲，SQLite和Core Data是很相似的。他们的不同在于具体使用方法。

6、Core Data代表一个对象的graph model，但SQLite就是一个DBMS。

7、Apple在一般情况下建议使用Core Data，但是如果你有理由不使用它，那么就去使用更加底层的SQLite吧。

8、如果你使用SQLite，你可以用FMDB这个库来简化SQLite的操作，这样你就不用花很多经历了解SQLite的C API了。

9、重用大开销对象

10、处理内存警告.移除对缓存，图片object和其他一些可以重创建的objects的strong references.

11、一些objects的初始化很慢，比如NSDateFormatter和NSCalendar。然而，你又不可避免地需要使用它们，比如从JSON或者XML中解析数据。想要避免使用这个对象的瓶颈你就需要重用他们，可以通过添加属性到你的class里或者创建静态变量来实现。

11、避免反复处理数据.在服务器端和客户端使用相同的数据结构很重要。

12、选择正确的数据格式.解析JSON会比XML更快一些，JSON也通常更小更便于传输。从iOS5起有了官方内建的JSON deserialization 就更加方便使用了。但是XML也有XML的好处，比如使用SAX 来解析XML就像解析本地文件一样，你不需像解析json一样等到整个文档下载完成才开始解析。当你处理很大的数据的时候就会极大地减低内存消耗和增加性能。

九、tableview 的优化

1、正确使用reuseIdentifier来重用cells

2、尽量使所有的view opaque，包括cell自身

3、避免渐变，图片缩放，后台选人

4、缓存行高

5、如果cell内现实的内容来自web，使用异步加载，缓存请求结果

6、使用shadowPath来画阴影

7、减少subviews的数量

8、尽量不适用cellForRowAtIndexPath:，如果你需要用到它，只用一次然后缓存结果

9、使用正确的数据结构来存储数据

10、使用rowHeight, sectionFooterHeight 和 sectionHeaderHeight来设定固定的高，不要请求delegate

补充：怎么对代码进行优化

1、利用性能分析工具检测，包括静态 Analyze 工具，以及运行时 Profile 工具，通过Xcode工具栏中Product->Profile可以启动

2、比如测试程序启动运行时间，当点击Time Profiler应用程序开始运行后.就能获取到整个应用程序运行消耗时间分布和百分比.为了保证数据分析在统一使用场景真实需要注意一定要使用真机,因为此时模拟器是运行在Mac上，而Mac上的CPU往往比iOS设备要快。

3、为了防止一个应用占用过多的系统资源，开发iOS的苹果工程师门设计了一个“看门狗”的机制。在不同的场景下，“看门狗”会监测应用的性能。如果超出了该场景所规定的运行时间，“看门狗”就会强制终结这个应用的进程。开发者们在crashlog里面，会看到诸如0x8badf00d这样的错误代码。