体验 iOS 7 测试版之后
试用 iOS 7 二十四小时，已经准备降级到 iOS 6。
这个决定无关乎设计之争，原因很简单：太烫了，放在口袋里会烫腿，续航比原来缩短一半，暂不适合作为主力机。
其实无论是散热的优化，还是图标进一步美化，或第三应用程序出现的 Bug，相信一个季度后，正式版推出时都会得到改善——只是苦了比去年 iOS 6 多出一倍的体验人员。
此前《深度体验 iOS 7 测试版》一文带领人们领略了 iOS 7 风采，我们呼吁了两次 “眼见为虚，上手为实 ”，鼓励人们安装测试版上手体验。本文从产品设计的角度——人们常常忘记手机操作系统也是一款 “产品”——谈一谈即使一个季度后也不会过时的东西。
人们距离第 10 个 App 更远了
在体验微信 5.0 的时候，我注意到一个大变化，就是人们距离公众帐号的距离更远了。因为微信在用户跟公众帐号之间加了一层文件夹（企业号 / 公众号）。微信是出于抑制公众平台媒体属性而这么做的。
苹果 iOS 7 也无意中加了这么一层阻碍。如下面的视频显示，iOS 7 允许用户往一个文件夹里无限添加 App 图标，每屏可摆放 9 个图标。这个设计解决了 iOS 6 文件夹只可以添加单屏 16 个 App 的限制，但随之而来出现另一个致命的问题：第 10 个往后的 App 被藏到了文件夹第二屏以后。人们获得某个文件夹第二屏往后的 App，路程是这样的：桌面 – 文件夹 -> 第一屏 -> 第二屏 -> 第三屏……被用户无意间排在第二屏之后的 App，与用户的距离变得越来越远。这些 App 被藏在后面，被用户忽略的概率大大增加。
（Youku 视频一：iOS 7 文件夹演示）
那么，用户为了更便捷地抵达 App，它会不会只在一个文件夹里放置 9 个 App，而不出现第二屏、第三屏……第 X 屏？这是典型的不站在用户角度思考的行为。换位思考一下，比如你归类 13 个社交应用为 “社交” 文件夹，你会考虑到为了方便直达，把它们分为两个文件夹，一个装 9 个应用、一个装 4 个应用吗？况且如果用户更喜欢在第一屏使用应用的话，iOS 7 无须变化，照搬 iOS 6 的 4×4 风格就好了，而且还能容纳更多的数量。
所以从 iOS 7 的文件夹设计理念来看，开发者只能祈祷不要被用户放在文件夹的第二屏以后。虽然从随机概率角度来看，似乎每个应用都有这种可能。
“真正的多任务”，需要勤快一点杀后台了？
我一直没法把 Android 作为主力机的重要原因，是在我习惯使用 iPhone 后，没有养成随时 “杀后台” 的习惯，以至于我使用 Android 的时候，电量消耗很快。
苹果在 WWDC 2013 开幕式上宣布 iOS 7 具有 “真正的多任务” 功能的时候，台下响起了一片掌声。我不是其中的一个。相反，我的疑问是：我为什么需要真正的多任务？比起多任务功能来，我更担心的是电量的消耗。为了节省电量，我并不想比之前让后台常驻 100 个应用的慵懒习惯有任何改变。现在 iOS 7 的多任务迫使我不得不每次很爽地使用完 App 后，需要把它 “杀” 一遍（详细更新见文末，感谢各位读者提供的技术细节）。所以此前看到某些 Android 用户无时无刻不地清理后台的强迫症后，除了钦佩之外，别无其他。
（Youku 视频二：iOS 7“真” 多任务界面和控制中心）
当然，我可能是一个懒人，不想迎接变化。但与我相同的懒人，会在少数吗？况且不谈 iPhone 用户基数扩大后，对于入门级用户来说，潜在的学习成本。
关于控制中心，我很赞扬。控制中心在 Android 已经实现，在第三方 ROM 中，实现得就更早了。在 iOS 7 中，任何情况下，向上滑动屏幕调出控制中心（锁屏界面下向上滑动右下角区域是调出相机），很大地方便了人们控制日常开关和功能。这一功能对于 Android 用户来说是老套，但对于 iOS 用户来说，是新鲜的，而且很有必要。
华丽与效率之间，你需要哪一个？
在主屏与应用之间、主屏与文件夹之间、应用与文件夹之间，iOS 7 增加了一套华丽的切换动画。这个动画效果，只有看视频才能看得出来，如下：
（Youku 视频三：iOS 7 华丽的切换动画）
在 iOS 6 时代，点击 Home 之后，退出无动画，且无论在任何情况下，都是四周向中心凹陷退出；在 iOS 7 中，主屏与应用之间、主屏与文件夹之间、应用与文件夹之间增加了动画，不再向屏幕中心退出，而是呈发射状退出到活跃文件夹或主屏。
经过实测，加入动画效果后的 iOS 7 效率略低于 iOS 6，切换动画的过程增加了 0.00X 秒。一开始看到这种动画的时候，会显得累赘，但稍作适应后，习以为常。如果说扁平化的图标让 iOS 7“看” 起来变轻了，那么实际使用中，iOS 7“用” 起来实际上是变重了。华丽的切换动画与色彩斑斓的 iOS 7 相映成趣，但效率上略逊于 iOS 6。
在 TNW 一篇文章暗示 iOS 7 部分图标由 Jony Ive 中的互动营销部门（Apple Worldwide Marketing Communications Department，WW Marcom）参与设计后，而不是由 App 设计团队设计，引起粉丝的反弹，认为如此重要的产品，怎么可以由其他团队干预，来影响 App 设计呢？李楠的一个评论非常到位：
苹果公关和市场部（互动营销部门）的设计师就不专业了吗？ Jobs 是销售出身。 Scott 是个超级程序员。 Ive 是设计师。 所以 iOS1-4 可以看作是销售主导。 iOS5-6 是技术主导。 iOS7 ，则是设计主导。所以其实苹果早就在用市场部的人来做 iOS 的设计了。
从我的体验来看，虽然静态的 icon 可能有互动营销部门人士参与提建议，但 iOS 7 系统的底层，包括李楠所说的“尺度”“立体”，实际上是由 Jony Ive 牢牢控制的。尤其是动态的设计体验，无不打着厚厚的设计师烙印。相反，追求效率的销售人员乔布斯可能不喜欢这样略显 “拖沓” 的设计。
其他方面的 iOS 7 体验，可以看一下下面大约 6 分钟的上手视频。我们号召大家安装体验 iOS 7 后再作评判，如果你还未来得及体验新系统（测试版有一大堆问题，期待开发者和苹果官方一起解决），观看这段视频是一个不错的选择。
（Youku 视频四：iOS 7 测试版上手视频，约 6 分钟）
总之一句话，iOS 7 是一个动态的手机操作系统，需要把玩，需要认真感受。
关于多任务，更新一：
@~~>~~：简单地说 iOS 这一次的 “真多任务” 意思是 “所有 app 都可以在一定情况下被唤起在后台进行一些任务”，而不是 “所有 app 切换到后台就停在那里不走了”，不被唤起的 app 就算显示在后台上也不会消耗电量，会被唤起的 app 你就算杀了它在一定条件下它还是会被唤起执行后台任务。
发布会上用的例子是 Facebook——如果每天早上九点 check 一下 Facebook 更新的话，iOS 会学习使用习惯，以后就算 Facebook 不在后台上也会每天九点之前唤醒一下更新最新数据，以便用户打开的时候不需要再等待更新，形成一种 “Facebook 一直在后台” 的感受。
关于多任务，更新二：
@saraphines：iOS 7 中，应用程序的后台执行模型，新增了如下两种类型：
1.fetch：如果应用程序需要从网络中有规律的下载新数据，那么现在可以通过向系统注册一下，使新数据的下载操作可以定期的被唤醒或者启动以在后台进行下载。注册方法为：在程序的 Info.plist 中，将 UIBackgroundModes 键值设置为 fetch，然后在 app delegate 中，使用方法 setMinimumBackgroundFetchInterval: 来设置下载新数据操作之间的最小时间间隔。另外，必须在 app delegate 中实现 application:performFetchWithCompletionHandler: 方法以执行任意的下载。
2.remote-notifaction：在 iOS 7 之前，程序中使用的推送通知是用来给用户推送新的消息，而有新的消息到达时，如果需要获得消息相关更多内容时，还需要用户启动相应的程序，以在程序中获取新的消息内容，而现在在 iOS 7 中，通过推送通知，可以启动一个后台下载操作任务。要使用这种模型，只需要将程序 Info.plist 文件中的 UIBackgroundModes 键值设置为 remote-notification，然后在 app delegate 中实现 application:didReceiveRemoteNotification:fetchCompletionHandler: 方法。
无论是 fetch 或 remote-notification 后台执行模型，在适当的时机，都有可能被启动或者从休眠（suspended）状态转移到后台状态。就拿 fetch 后台模型来说，系统会根据当前可用的信息来来决定启动或者唤醒程序的最佳时机。例如，当网络条件不错，或者设备已经被唤醒的时候，会启动或唤醒程序以执行程序的 fetch 后台操作。再来看看 remote-notification 后台执行模型：当有一条新的推送通知到达设备时（在通知用户之前），程序可以先去下载新的消息内容，当内容都准备好之后，就可以通知用户了。可见，对于 remote-notification 后台执行模型，可以让用户把注意力都集中在内容上，这也符合本文开头提到的 iOS 7 设计重心。
关于多任务，更新三：
@mayokaze：iOS 7 中的 app 分为四种后台模式，需要注意的是无论哪一种都需要 app 本身实现相应的后台接口。
level 1：无后台仅有推送 － 参考 iOS 3.x。
level 2：墓碑式后台 － 现场还原，即所谓的伪多任务，绝大多数 iOS 4 以后的 app 是这种后台模式。
level 3：由系统智能调度的后台 － iOS 7 新增的 background fetch。
keynote 上着重讲过的根据用户行为自动调整达到效率最优的后台模式，用于处理不是很有时效性的信息获取，例如 sns，新闻类应用的后台更新等，系统会根据用户启动应用的频率和时间以及当前的网络和电量情况来智能分配每个应用的获取频率和时间，数据刷新是统一的，即系统可以在一个进程内获取多个应用所需的数据而不是一个应用一个进程（类似统一的推送机制，都是为了省电），开发者不能确定数据会在何时被更新所以这个 api 只能用于处理非敏感信息。
level 4：真后台
但此真后台非 Android 和传统桌面 OS 的真后台，为了让用户免于进程管理仍然有多种限制，大致分为图中几种模式
其中 2345 跟 iOS 4 时代基本没变化，audio 和 VoIP 是真正意义上的多任务，Newstand 是定时更新，location 则是由系统统一管理。
在前面提过，我认为 iOS 7 不能算真后台因为用户和开发者都不能预测何时被系统调度。
Task Completion 是 iOS4 就有的一个通用后台接口，可供任意类型的 app 使用，其限制是只能后台运行 10 分钟。iOS 7 对其作出的改变是原本的 10 分钟是连续的 10 分钟，既是说即使在这 10 分钟内用户关闭了屏幕或是时间到自动关屏了系统也不会进入休眠状态而是等待 10 分钟后台运行完毕；新的系统则会正常休眠，将剩余的后台时间留到用户下一次唤醒设备。
这样后台的运行时间仍是 10 分钟但不再是连续的。这样做的好处是省电，打个比方现在很多词典带后台复制选词功能，实际上就是用了 task completion，这样一旦用户开启一次词典并退出就意味着设备至少 10 分钟没法进入休眠状态，对电量是很大的消耗，iOS7 以后该休眠照样休眠，并且下次你唤醒设备后台取词还在。
Remote Notification 是本次较大的一个改进。以往 IM 类应用接受推送后点进去需要再收一次信息的情况将不复存在，推送将能够直接启动后台任务，具体的时限我还没仔细看。
值得注意的是 Remote Notification 支持 silent notification，这样 dropbox 这类同步应用可以在后台以最节能的模式实时静默同步了，类似布卡漫画这种也可以推送正在追的漫画的新章节并在后台静默下载，待到下载好再给用户发送一个本地推送，用户点开即看无需再联网。
关于 background fetch 和 remote notification 的适用场景官方给出了参考。
background transfer service – iOS 有史以来最接近传统多任务的后台接口，可供任意类型的 app 调用，无时间限制。应用场景包括后台上传和下载数据，这使得游戏后台更新数据包，后台上传视频等等都成为可能，但是正如其名字，它只能用于处理上传下载这种传输类的任务，类似后台剪切板监控这种它就无能为力了。
组合－实际应用场景中灵活组合多种后台模式可以实现传统多任务的绝大多数应用模式而无需用户插手进程管理，例如一个地图类应用可以开启 location 服务，当检测到用户进入一个新的城市后开启一个
background transfer service 下载该城市的数据包。又比如， remote notification 可以和 background transfer service 组合实现订阅的电视剧甚至电影后台静默更新。
