入门级
1.用ARC管理内存
2.在正确的地方使用 reuseldentifier
3.尽量把vews设置为透明
4.避免过于庞大的XB
不要阻塞主线程
1.在 Imageviews中调整图片大小。如果要在 UIImage view中显示一个来自 bundle的图片,
你应保证图片的大小和 Ullage View的大小相同。在运行中缩放图片是很耗费资源
的,特别是 UIImage View嵌套在 UIScrollView中的情况下。如果图片是从远端服务加
载的你不能控制图片大小,比如在下载前调整到合适大小的话,你可以在下载完成后,
最好是用 background thread,缩放一次,然后在 UIImage View中使用缩放后的图片。
2.选择正确的 Collection
Arrays有序的一组值。使用 index来 lookup很快,使用 value lookup很慢,插入
删除很慢
o Dictionaries:存储键值对。用键来查找比较快。
o Sets:无序的一组值。用值来查找很快,插入/删除很快
3.打开gip压缩。app可能大量依赖于服务器资源,问题是我们的目标是移动设备,因
此你就不能指望网络状况有多好。减小文档的一个方式就是在服务端和你的app中打
开gzip。这对于文字这种能有更高压缩率的数据来说会有更显著的效用。
OS已经在 NSURLConnection中默认支持了gzip压缩,当然 AFNetworking这些基于它
的框架亦然。
中级
1.重用和延迟加载( (lazy load)views
o 更多的view意味着更多的渲染,也就是更多的CPU和内存消耗,对于那种嵌套
了很多vew在 UIScroll View里边的app更是如此。
这里我们用到的技巧就是模仿 UITable view和 UICollection View的操作:不要一
次创建所有的 subview,而是当需要时才创建,当它们完成了使命,把他们放
进一个可重用的队列中。这样的话你就只需要在动发生时创建你的vews
避免了不划算的内存分配
o Cache, Cache,还是 Cache!
一个极好的原则就是,缓存所需要的,也就是那些不大可能改变但是需要经常
读取的东西。
我们能缓存些什么呢?一些选项是,远端服务器的响应,图片,甚至计算结果
比如 UITable View的行高。
o NSCache和 NSDictionary类似,不同的是系统回收内存的时候它会自动删掉它
的内容。
权衡渲染方法性能能还是要 bundle保持合适的大小。
处理内存警告移除对缓存,图片 object和其他一些可以重创建的 objects的 strong
references
重用大开销对象
6一些 objectS的初始化很慢,比如 NSDatelonmatler和 CALendar,然而,你又不可避兔
地需要使用它们,比如从ON或者XML中解析数据。想要避免使用这个对象的瓶颈
你就需要重用他们,可以通过添加属性到你的eas里或者创建静态变量来实现。
7,避免反复处理数据在服务器端和客户端使用相同的数据结构很重要。
8,选择正确的数据格式解析SON会比XML更快一些,JSON也通常更小更便于传输
从Ss起有了官方内建的 Son deserialization就更加方便使用了。但是XML也有XML
的好处,比如使用SAX来解析XML就像解析本地文件一样,你不需像解析on一样等
到整个文档下载完成才开始解析。当你处理很大的数据的时候就会极大地减低内存消
耗和增加性能。
9正确设定背景图片
0全屏背景图,在vew中添加一个 UIImage View作为一个子view
0只是某个小的vew的背景图,你就需要用 UIColor的 color WithPatternImage来做
了,它会更快地渲染也不会花费很多内存:
10.减少使用Wb特性。想要更高的性能你就要调整下你的HTML了。第一件要做的事就
是尽可能移除不必要的 javascipt,避免使用过大的框架。能只用原生js就更好了。尽
可能异步加载例如用户行为统计scrp这种不影响页面表达的 javascript。注意你使用的
图片、保证图片的符合你使用的大小。
Shadow Path. Core Animation不得不先在后台得出你的图形并加好阴影然后才渲染
这开销是很大的。使用 shadow Path的话就避免了这个问题。使用 shadow path的话os
就不必每次都计算如何渲染.它使用一个预先计算好的路径。但问题是自己计算path
的话可能在某些vew中比较困难,且每当vew的 Iframe变化的时候你都需要去 update
12.优化 Table view
°正确使用 reuseldentifier来重用cels
°尽量使所有的 view opaque,包括ce自身
°避免渐变,图片缩放,后台选人
o缓存行高
如果ce内现实的内容来自web,使用异步加载,缓存请求结果
使用 shadow Path来画阴影
减少 ubviewsl的数量
尽量不适用 cellForRow AtIndexPath:,如果你需要用到它,只用一次然后缓存结
°使用正确的数据结构来存储数据
0使用 row Height, section FooterHeight和 section Header Height来设定固定的高,不
要请求 delegate
13.选择正确的数据存储选项
o NSUser Defaults的问题是什么?虽然它很mce也很便捷,但是它只适用于小数
据,比如一些简单的布尔型的设置选项,再大点你就要考虑其它方式了
XML这种结构化档案呢?总体来说,你需要读取整个文件到内存里去解析,
这样是很不经济的。使用SAX又是一个很麻烦的事情。
NSCoding?不幸的是,它也需要读写文件,所以也有以上问题
在这种应用场景下,使用 SQLite或者 Core Data比较好。使用这些技术你用特
定的查询语句就能只加载你需要的对象
在性能层面来讲, SQLite和 Core Data是很相似的。他们的不同在于具体使用方
o Core Data代表一个对象的 graph model,但 SQLite就是一个DBMS
Apple在一般情况下建议使用 Core Data,但是如果你有理由不使用它,那么就
去使用更加底层的 SQLite吧
oApke在一般情况下建议使用 Core Data,但是如果你有理由不使用它,那么就
去使用更加底层的 SQLite吧。
o如果你使用 SOLite,你可以用FMDB这个库来简化 SQLite的操作,这样你就不
用花很多经历了解 SQLite的CAP了
高级
加速启动时间。快速打开ap是很重要的,特别是用户第一次打开它时,对app来讲
第一印象太太太重要了。你能做的就是使它尽可能做更多的异步任务,比如加载远端
或者数据库数据,解析数据。避免过于庞大的XB.因为他们是在主线程上加载的。
所以尽量使用没有这个问题的 Storyboards吧!一定要把设备从xcde断开来测试启动
速度
2.使用 Autorelease Pool. NS Autorelease pool负责释放 block中的 autoreleased objects
般情况下它会自动被UKi调用。但是有些状况下你也需要手动去创建它。假如你创
建很多临时对象,你会发现内存一直在减少直到这些对象被ease的时候。这是因为
只有当UKn用光了 autorelease poc0l的时候 memory才会被释放。消息是你可以在你自
己的@ autoreleasepool里创建临时的对象来避免这个行为
3.选择是否缓存图片。常见的从 bundle中加载图片的方式有两种,一个是用
mageNamed,二是用 image With Contents OfFile,第一种比较常见一点。
4.避免日期格式转换。如果你要用 NSDateFormatter来处理很多日期格式,应该小心以
待。就像先前提到的,任何时候重用 NSDateFormatters都是一个好的实践。如果你可
以控制你所处理的日期格式,尽量选择Unix时间戳。你可以方便地从时间戳转换到
(NSDate*)datePromUnixTimestamp:(NSTimeInterval)timestamp t
returnI NSDate datewithTimeIntervalsince1970: timestamp)
这样会比用C来解析日期字符串还快!需要注意的是,许多 web AP会以微秒的形式返回时
戳,因为这种格式在vp中更方便使用。记住用 date From UnixTimestamp之前除以0
就好了
