IOS性能笔记

ios性能专题分为几大块：

1.内存：

问题:占用内存过多会影响性能，应用被kill；内存释放不当会导致crash；内存是所有app共享的，单个app不应占用大量内存；内存与性能需要一个平衡；系统会帮你杀其它后台应用，但这影响整体体验，因此应限制自身app内存占用量；

理论:类linux系统，但ios无磁盘交换分区，因此内存有限；

自动垃圾收集：mac os x程序开发可用，ios开发不支持，自动垃圾收集时会引起程序暂时中断；未来os x也将弃用；

手动内存管理原则：

a)想一个对象100%不被释放，使用retain，但使用过后一定要release；

b)release只会将引用计数-1，而不会释放内存，只有引用计数为0时才会调用dealloc；

c)对于对象的属性如果有retain或copy/mutableCopy/alloc/new的属性，一定要在dealloc中释放之；

d)如果方法中不需要该对象，但需要将其返回，使用autorelease；

e)系统会在自动释放池释放时release其中所有对象，但是如果release后计数不为0，对象不会释放；

ARC理论：

a)dealloc不能显式触发，retain/release/retainCount/autorelease等不能重载或调用；禁止使用 @selector(retain)和@selector(release)

b)dealloc方法中不需要释放成员变量，不需要调用父类的dealloc；

c)不能在c的结构体中使用对象指针；建议使用对象来存储数据，而不是结构体；

d)id到void *类型转换必须是显式的；

e)@autoreleasepool代替NSAutoreleasePool；

f)不能使用内存分区参数；这参数本来也没什么用；

g)以alloc、new、copy、mutableCopy开头的函数表示调用者对被创建的对象拥有所有权，以init开头的函数表示对对象进行初始化。这些函数需要是实例方法（而非类方法），并且返回一个对象。如果不遵循这样的方式，有可能会被搞乱；比如new的方法是非arc的，里面没有持有该对象而使用的autorelease，而调用者是arc的，会认为该方法实际持有了该对象，因此会在后续释放该对象，造成crash；

h)__bridge、__bridge_retained和__bridge_transfer，用来在c指针和oc指针之间做转换用，比如void *p = (__bridge void *)obj。三个关键字分别表示没有所有权转移的类型转换、前后都拥有所有权的类型转换以及所有权转移（交接）的类型转换。

i)

__strong

__weak

__unsafe_unretained

__autoreleasing作用看effective oc

j)NSString 类型的属性应该永远声明为带有copy attribute 

 这点是因为NSString 的setters 永远使用copy 而不是retain。NSString变量赋值给NSString之后，再改变赋值源并不会改变被赋值的变量；即实际实现是copy，所以一般NSString都用copy修饰比较一致；但如果赋值源是MutuableString时，用copy和用strong修饰NSString类型的变量还是有区别的，copy被赋值变量不会随着赋值源改变而改变，但strong会。所以声明成copy能保证不被影响。

block内存泄漏问题原理：

某个实例指向block，block中引用了该实例或该实例中的任意变量，均可能导致泄漏，必须改成weak引用。

内存警告处理：

多个app共享系统内存，前台app内存不足时系统会杀其它挂起的app；低内存警告只会通知到running的app，挂起app不通知，直接杀掉；

注意点:

收到低内存警告的三个地方：

a)appdelegate applicationDidReceiveMemoryWarning: 

b)UIViewController didReceiveMemoryWarning

c)注册监听通知事件：UIApplicationDidReceiveMemoryWarningNotification

收到低内存警告怎么做：

a)释放掉对缓存、图片的强引用；

b)UIViewController的默认动作是将不可见的view移除；

c)一些后续仍可以正确初始化出来的数据可以清除掉；

减少内存使用的关键点：

a)杜绝内存泄漏；

b)减少资源文件尺寸：nib，png，plist等等；

c)对于大数据量存储使用core data或sql lite；

d)资源文件懒加载；

e)包大小压缩；thumb选项开启可减少压缩包大小，不过如果是浮点计算密集型应用可能效果不好；

f)仅加载需求的资源文件；

g)使用集合时必须考虑数据量大时是否有边界？数据量大时的内存问题；

h)使用ARC;

2.响应时间：

a)耗时操作不要放在主线程中，易阻塞界面响应；

b)不要使用基于软件的浮点运算数学函数库，使用基于硬件的；

c)使用instrument工具进行调优，响应时间、电量、cpu及内存网络等方面；

d)tableview的cell设置reuseIdentifier

e)图片大小应与所显示所需的一致或接近，resize很耗性能；

f)选取合适的集合类，dictionary适合按key存取，array利于随机存取，但插删特别慢；

g)能重复利用的静态内容使用缓存；

h)使用绘制方式处理界面可使包更小，但耗时，直接帖图片的方式快但打的包会变大，需要平衡；

i)NSDateFormatter和NSCalenda等对象初始化非常耗时的对象时，最好使用单例；

j)固定的常量要避免重复计算，比较单元格高度，一些初始化工作不要放在cellForRowAtIndexPath等；

k)启动时间尽量快；

3.CPU：理论，问题，注意点；

cpu使用如果有问题第一是导致电量问题和发热问题，发热必然耗电；

cpu使用如果有问题第二是会影响响应时间；

4.电量：

理论:

ios通过关闭所有未正在使用中的硬件来省电；因此可从几个方面来省电：cpu,地址位置，重力加速，磁盘，wifi与gprs等；

问题:

电量消耗过多问题比较明显，就是使手机的续航能力弱；

注意点:

a)禁止使用轮询方式，而使用定时器或NSLoop，减少CPU使用；

b)idleTimerDisabled设置为NO，使一段时间未使用时屏幕可关闭；

c)将零散的工作一次性做掉（必要获取的数据一次性获取）；

d)避免频繁读写磁盘，比如一些数据写入时，只有数据改变是写入；

e)只在屏幕展示时才进行绘制计算相应的视图；

f)重力加速感应与地理信息收集只在确实需要该功能时收集，地理信息时设置合适的距离与更新频率很重要；

g)避免对外网络请求一些不需要的数据，使用gzip压缩；网络请求很耗电量；手机网络比wifi耗电；

h)网络数据格式尽量简短，如果自己可以定义协议的话；

i)一定要编写处理网络请求错误的方法，即使某些时候这些方法并不一定触发；

5.UIWebView

前端性能优化必须要做的，若干种准则；UIWebview使用单例；使用进NSURLProtocol行缓存优化；

推荐文章：http://www.raywenderlich.com/59982/nsurlprotocol-tutorial

深度理解URL Loading System，使用其中的方式进行缓存优化，比如一些铁定会访问，但出现在Webview中的图片图标等可打包进app进行缓存，在URL访问时，返回缓存的图片以替代网络请求；