iOS升级经验分享

作者认为，及时关注、快速反应、覆盖测试是面对iOS系统升级时最重要的三大原则，文中还详细分析了iCloud Storage和Automatic Reference Counting这两大iOS 5新特性。

2011年10月初，iOS 5正式发布，带来了大量新特性。随之而来的是大量应用需要针对iOS 5系统进行升级适配。每次系统升级，我们公司都要对正在维护的众多已上线应用进行升级适配，这可以说是一个痛苦的过程，但在这个过程中我们也积累了一些应 对iOS系统升级的原则、方法和经验。

及时关注iOS系统升级动态

• iOS开发者门户网站：开发者官网上拥有大量的最新资讯和每次系统升级的相关资料，并且真实有效，有助于开发者第一时间了解系统升级的相关信息。

• 开发者论坛：开发者可以登录官方论坛了解最新的技术，国内的一些iOS开发者论坛也提供了大量本土开发者的开发心得，如CSDN、 CocoaChina等，大家可以找到其他开发者在系统升级中遇到的问题和解决的方案，也可以提出自己遇到的问题，会有很多热心的开发者来帮助解答。

• 其他视频类资源：苹果每次系统升级或新产品发布都会举办发布会，会对各种新产品新特性进行说明和演示，这些发布会的视频会在第一时间被发布到苹果 官网和App Store的Podcasts上，当然这些视频都是英文的。另外，每年的Apple WWDC即苹果全球开发者大会上，也会有大量以新系统、新特性为主题的技术讲座，这些讲座的视频和PPT资料也会放到开发者门户上供大家下载学习。

快速反应

快速反应是我们应对系统升级的处理原则，从以往的系统升级情况来看，每次系统升级都会有大量的线上应用出现问题，有些是crash，有些是功能问 题。作为一款线上应用的开发者和运营者，每次面对系统升级，我们要做的最重要的事是在系统发布的第一时间提供经过新版本适配的应用更新，让用户第一时间获 得适合新系统的稳定版本，有效地稳定应用在App Store的评分。为了第一时间实现提供稳定版本的目的，我们在提供版本更新时需要把应用的稳定性放在第一位。

需要注意的是，每次系统升级都会给开发者提供大量的新功能、新特性，作为一个开发者，内心都会非常兴奋，急于把各种新特性应用到产品中，但这些新特 性的使用会遇到两个问题：一个是新特性的向下兼容问题；另一个是应用新特性过程中的时间问题。对此，我的建议是：不要急于应用这些新特性，等提供了一个稳 定的更新版本后，再考虑新特性的使用也不迟。

覆盖测试

众所周知，测试是发现问题的最佳手段。覆盖测试是我们应对系统升级的最直接手段，对于系统升级的测试，有以下三个方面需要格外注意。

• 覆盖全部的功能

覆盖全部功能是所有测试的要点，每款应用在上线前都应该经过一个覆盖全部功能的详尽测试，有条件的情况下要写下测试用例。这样，在系统升级过程中，可以利用之前写下的测试用例针对新系统进行一轮详细测试，可以有效发现新系统带来的问题。

• 覆盖全部的设备和版本

测试的另一个要点在于对测试设备和测试系统版本的覆盖，为了做到向下兼容，必须在应用上线前在应用需要支持的系统版本和不同设备上进行测试。

• 有目的的寻找Bug

在系统升级的过程中，还可以根据苹果公司发布的新系统Release Note中的内容，比照自己的应用进行针对性的检查。另外，在各大论坛上也会有大量的其他开发者发布系统升级中遇到的问题和解决方案，都可以用来进行针对性的检查测试。

重要新特性

以上内容是我们针对每次系统升级的一些通用原则和方法手段，接下来针对本次iOS5升级，详细说明升级中遇到的问题和解决方法。iOS 5带来了大量的新特性，其中iCloud Storage和Automatic Reference Counting是需要我们重点关注的特性。

iCloud Storage

iCloud是苹果推出的云存储服务。简单来说，iCloud提供了将iOS应用的数据存储在云端，并在不同设备间同步的能力，对于已有的应用、系 统升级后，应用需要遵循最新的iOS Data Storage Guidelines，苹果在里面对应用数据的本地存储做了一些限制和要求，主要包括以下四个方面。

• 只有用户生成的数据或无法被应用再次生成的数据才可以存放在Document目录下。在之前的系统中，苹果对存储在本地的数据位置并没有强制要 求，但引入iCloud后，开启了iCloud的设备会对存放在Document目录 （<Application_Home>/Documents）下的文件做自动的云端存储备份，考虑到网络流量和效率等因素，只有必要的数据 才可以存放在Document目录下。
• 本地缓存数据需要存放在Cache目录（<Application_Home>/Library/Caches）下。在这里，缓存数据的定义是指可被重新下载或重新生成的数据，包括新闻杂志类应用的下载数据。
• 临时存在的数据，需要放在tmp目录（<Application_Home>/tmp）下，并在使用结束后删除。
• 系统会在硬盘资源紧缺的情况下，对存放在Cache目录下的缓存数据进行删除。在iOS 5.0.1中，系统也提供了一个避免某些文件被系统删除的功能，即在需要保留的文件上加上“do not back up”属性，加上该属性后，文件不会被系统自动清除。需要注意的是，这些文件需要应用自己维护文件的生命周期，确保该文件在不需要时能够被删除。

Automatic Reference Counting

对广大开发人员来说，ARC是一个令人激动的特性。众所周知，对很多开发者来说，Objective-C的内存管理机制是一门很难掌握的技术，而 iOS应用中大量的crash、不稳定、性能异常等问题都是因为没有正确管理内存造成的。ARC的作用是，将内存管理的工作交给编译器去做，将程序员从复 杂的内存管理工作中解放出来，同时也提高了内存管理的效率。

无疑，开发者非常希望尽快将这么好的特性应用到开发中，但对于目前在线应用的升级适配来说，是否采用ARC就需要慎重考虑了。

首先，从向下兼容方面考虑，ARC最低支持为4.0系统，并且在4.x系统上无法支持weak和strong两个关键字；其次，对于线上应用，换成 ARC做内存管理并不会有实际作用，因为线上应用本身不会存在太大的内存管理问题，而使用ARC，需要对代码进行相当大范围的改动，改动后又需要一个详细 全面的测试过程，而这些工作都做完后，应用本身并没有直观变化。所以建议开发者对线上应用的升级适配，并不要急于使用ARC，而对新开发的应用可以大胆尝 试ARC的使用。

除了上面两个新特性需要特别说明外，还有一些API级别的变化，下面就几个比较典型的例子详细说明。

UIKit中UI组件的自定义样式。在iOS 5中，系统为各种组件提供了大量自定义样式的方法，而原来广泛流传的通过Category 重写drawRect的方法已不再被使用，所以需要开发者根据当前的系统版本采用不同的处理方式。

UIViewController中的parentViewController属性值发生变化。 UIViewController中的parentViewController属性是一个较常用的属性，尤其是在处理 ModalViewController展现和隐藏时。在iOS 5中，该属性的值发生了变化，无法再处理ModalViewController的隐藏，需要使用UIViewController的 presentingViewController替换。同样，presentingViewController也是只有iOS 5才支持的。

iOS 5中键盘高度的处理。在iOS 5之前的系统中，键盘的高度是固定的，而在iOS 5中，中文输入法的键盘高度会发生变化，有一些notification事件可以帮助大家处理相关的键盘操 作：UIKeyboardDidShowNotification、UIKeyboardWillHideNotification、 UIKeyboardWillChangeFrameNotification等，这几个notification会在键盘隐藏显示时触发，并通过其中的 userInfo属性提供键盘高度等相关信息。

获取UIDI的变化。UIDI在iOS 5中被标记为deprecated（即不推荐使用，今后也可能不再提供设备的UDID）， 对于这个变化，官方文档中也提供了替代方法，即在应用中使用CFUUIDCreate方法创建自己的UDID，并保持在NSUserDefault中。

除以上API级别的变化外，还可通过查看iOS 5 Release Note中的内容，针对性的查缺补漏。