WWDC2014已经过去一个多月了。最令人兴奋的是Swift这一新语言的发布。之前写过一些关于这门语言的初印象和一些初步的探索。在撰写本文时，Swift已经收到了beta3的重大更新，并且该语言仍在经历剧烈的变化。对于Swift，现在大家的探索才刚刚在路上，很多背后的机制还不是很清楚，或者说可能会有巨大的变化，所以这里和几篇文章之后，直到稳定的1.0版本出现，我不再打算继续深入研究关于Swift的内容。这基本上是基于未来可能的变化容易误导看文章的新人的考虑，并不是建议我们现在可以放下Swift，安心等待正式版。在我看来，对一个不稳定版本的探索和研究远比后来被动接受别人的结果有趣得多，理解也会深刻得多。所以，有时间的话还是尽快联系使用为好。Github上有一个很好的repo，记录了Swift一路走来的变化，并讨论了不足和未来可能的变化。希望深入学习Swift的同学不妨关注一下。本概述首先简单介绍一下我认为iOS开发者应该注意的开发变化。在后面的系列文章中，我会详细讨论其中的一部分，其余的可能在本文中。做个介绍。总而言之，本次WWDC2014的相关笔记（目前暂定写）大致组织如下：开发者需要了解的iOS8SDK新特性：统一iOS界面开发iOS通知中心入门extensionproduction可视化开发，IB的新纪元TableView和CollectionViewiOS和Mac集成开发通知中心和应用程序使用重心变化应用程序扩展（Extension）这是一个被调用很久的特性，也是一个特性可以充分发挥无限的想象力。现在Apple允许我们在app中添加一个新的target来提供一些扩展功能：比如在系统的通知中心显示一个我们自己的widget，在一些应用的Action中添加我们自己的操作，分享按钮添加你的自己的条目，甚至添加自定义键盘等等。每个操作对应这个应用扩展的入口。在开发的时候，我们只需要在项目中对应入口创建一个新的target，然后我们就可以从一个好的模板开始一系列的开发，实现这些传统意义上可能需要越狱的功能。对于应用程序扩展，Apple将其定义为App功能的自然扩展，因此它不是单独存在的，而是作为附件与应用程序本身的包一起下载安装到用户设备中的，用户需要稍后选择它打开它。另外，由于应用扩展和应用属于两个不同的对象，它们之间的数据和操作交互遵循另一套原则。关于应用扩展更详细的内容，我打算后面以通知中心的今天小方框控件为例详细说明。App开发的统一随着一代代iPhone和iPad的出现，iOS设备的屏幕尺寸也开始分裂。过去一套屏风可以分两个方向吃遍全球的好日子已经不复存在了。现在至少有3.5英寸、4英寸和10（7）英寸三种分辨率/尺寸的机型需要适配。考虑到每个尺寸的水平和垂直方向，以及越来越流行的4.7英寸和5.5英寸iPhone，我们可以看到目前的布局已经不堪重负。虽然苹果在iOS6中引入了AutoLayout来辅助完成布局工作，解决了原有相对布局的一些问题，但是在以绝对尺寸衡量的坐标系中，难免还是存在约束条件。在iOS8中，苹果工程师可以说是“很有想象力”，干脆去掉了限制和表征屏幕尺寸的长宽数字，改用sizeclasses的概念，根据设备类型对长宽进行分类和方向。上课规律而紧凑。通过为不同的设备定义尺寸类别，它们被用来定义同一类型的操作特性，这使得开发者更容易使用一套UI来适配不同的屏幕。iOS8在UIKit中添加了一整套使用sizeclasses进行布局的API，并使原来更复杂（或有些冗余）的API变得过时。结合新的InterfaceBuilder和AutoLayout，可以说对多尺寸屏幕的适配得到了前所未有的简化。不仅如此，原来iPad专用的SplitController也以适配不同regular和compactsize类型的形式移植到了iPhone上，两者在程序设计上更加统一。另外，一直陪伴在我们身边的UIAlertView、UIActionSheet等老面孔也将退出舞台，全部由UIViewController来呈现。这是一个好的开始，也是一个好的改变。可见，苹果正在努力避免平台碎片化。iCloud相关作为黑帮老大的最后一部作品，iCloud其实没能在苹果的生态体系中发挥得特别出彩，实在是一个遗憾。首先，主要是iCloud相关的开发难度和API使用难度。另外，之前的SDK在与iCloud相关的各种API上都或多或少存在一些小问题。在iOS7中，iCloud的稳定性和易用性，尤其是iCloud与CoreDataAPI的结合得到了极大的提升。在iOS8中，Apple更进一步，引入了一个名为CloudKit的新框架。如果您熟悉或使用过Parse或AVOSCloud等BaaS，您可能会对这个框架感到熟悉。但与传统BaaS略有不同的是，CloudKit更倾向于使用iCloud来整合数据。您可以使用CloudKit从云端获取数据或将数据存储到云端，而无需更改应用程序现有的数据模型和结构。与Parse和AVOS的API相比，由于可以和系统进行深度集成，所以有很多其他同类BaaS所没有的特性（比如订阅一个公共对象）。但是因为是苹果自己的产品，它的缺点也很明显，也是致命的——你不能在非苹果平台上使用这个框架。也就是说，如果你的应用火了，你要出安卓版，那只能呵呵了。所以CloudKit虽然看起来很漂亮，基本相当于免费使用，但是由于平台的限制，涉及到的内容都是跨平台要求强的数据，无法回避，所以可能比较实用在实践中。机会不多。当然，如果应用只是针对iOS的，使用CloudKit应该是一个不错的选择。云存储的另一个新变化是可变存储源。过去，我们基本上别无选择。如果我们想在沙箱外使用文件，我们要么必须使用同一个iCloud容器中的文件，要么需要像Dropbox这样的第三方库来做一堆登录验证。无论哪种方式，都可以说是相当麻烦。现在，随着iCloudDrive的推出，在应用程序之间共享文件访问权限变得轻而易举。更重要的是，我们现在可以使用UIDocumentPickerViewController从第三方存储（以及第三方应用通过应用程序扩展实现的存储）中选择文件。iOS与Mac的Handoff等协同开发虽然PC市场一直疲软，但得益于iDevice销量和品牌接受度的回升，Mac销量逆势上扬。这在中国尤其明显。的确，我周围越来越多的人开始使用Mac。这对于我们iOS开发者来说其实是一个很好的机会。iOS8中的Handoff机制（即你可以在Mac上继续完成iOS的中途工作）为iOS和Mac的应用程序带来了良好的契合度和卖点。近年来，整合两个系统的动作也可以看出，苹果确实希望利用庞大的iOS开发者资源，进一步完善和丰富Mac。iOS开发和Mac开发其实是一脉相承的，所以切换起来也不是很难。我们一直可以跨两个平台编写Model部分的代码，只需要关心性能上的差异。现在Cocoa和CocoaTouch正式支持自制框架，可以说使用框架来完成这个过程更加简单了。HealthKit和HomeKit是对应两大热点领域——可穿戴设备和智能家电的框架。Apple基本上想做的是在iOS上构建，为其他应用程序构建平台并成为用户数据的管理者。HealthKit是用户身体参数的数据库，第三方应用可以向用户申请使用其中数据的权限或向其报告数据。HomeKit以家庭、房间和设备组织的形式管理和控制家庭中HomeKit适配的智能家电。这两个超年轻的框架API都比较简单，结构也很好。相信稍有经验的iOS开发者都能很快掌握使用方法。唯一的限制是，作为一个普通的开发者（比如我这种只能业余玩的）可能手头没有合适的设备来测试，所以很多东西其实是没法验证的。但是对于HomeKit，苹果为我们提供了一个模拟智能家电的模拟器，你可以在Xcode6的OpenDeveloperTool菜单中找到HomeKitAccessorySimulator。使用模拟器，你可以找到、添加和控制自定义的智能家电，这对于早期开发来说是相当方便的。如果我能弄到一些兼容HealthKit或HomeKit的设备，我可能会增加一些这方面的开发经验。游戏最大的变化是增加了SceneKit。但是游戏天生就容易跨平台（对此也有强烈的需求），这与受平台限制的SpriteKit有冲突，所以去年的SpriteKit并没有多少人用。就目前而言，世界似乎将由Cocos2dx/Unity统治一段时间。SceneKit的未来估计和SpriteKit差不多。作为一直在开发iOS应用的开发者来说，它的优势在于不需要学习和熟悉新的语言。易于与系统其他框架集成，故仍用于改造。不错的选择。但除此之外，其他方面可能没有太大的吸引力。另一个重大变化是为A7及以上级别的GPU推出了一组名为Metal的新绘图API。从Keynote的ZenGarden的演示来看，Metal的表现无疑是有说服力的。Metal的渲染方式和着色器也很有趣。但实际上，这些内容更底层，更面向引擎。对于大多数使用游戏引擎制作游戏的开发者来说，他们不需要知道或理解它们。如果在A7芯片下使用苹果自家的SpriteKit或SceneKit，可以直接受益于Metal，而其他一些知名的第三方引擎，如Unity、UE等，在iOS8推出后也将支持Metal。因此，作为引擎用户，除了升级用于开发的游戏引擎外，无需做任何改动。其他重要变化Local和Remote通知的变化现在需要显示UI或播放声音通知，包括Local通知也需要实现弹窗获取用户权限。使用-registerUserNotificationSettings:获得用户的许可。作为补偿，不需要打扰用户的类型（即iOS7加入的静默通知）不再需要弹出框获取用户权限。但是因为本地推送需要权限，如果你想靠通知来提高用户留存率，现在是绕不开用户权限的。此外，通知中心加入了非常方便的Action功能，用户收到通知后无需打开应用即可完成一些操作。可以说，有了通知中心的Today扩展，用户现在很可能无需打开应用程序就可以获取自己想要的信息并完成交互。这对于开发者来说可以说是喜忧参半。一方面，我们可以为用户提供更好更快的体验，但另一方面，这会降低用户打开应用的意愿。不过，苹果目前的总体思路是应用体验是最重要的，所以正确的路径应该是优先考虑应用体验，并在应用和通知之间探索一个平衡点来满足大家。CoreLocationCoreLocation室内定位。现在CL可以给出建筑物所在楼层的位置信息，直接访问CLLocation实例的楼层，如果当前位置可用，会返回一个包含位置信息的非nilCLFloor来标识当前楼层。这大大扩展了定位应用的可能性。想象一下，当你在复杂的地铁站或建筑物中迷路时，你仍然可以依靠定位系统，你会感到幸福。TouchIDTouchIDAPI，说是开启了TouchID的验证，但实际上能做的还是比较有限。因为现在提供的API只能验证用户是否是手机的主人，而不能给出识别标志或唯一码，所以使用TouchID注册登录可能不太现实。但是对于登录后的再次确认操作比较有用，比如支付验证。现在看来，这套API是为了简化像Paypal或Alipay这样的第三方支付确认的流程。我希望它能在未来继续发布。如果可以给出一个唯一的标识符，也许可以消除整个烦人的注册和登录系统。相机和照片新增了Photos.framework框架，用于与系统内置的Photo应用进行交互。它不仅可以代替原来的AssetsLibrary作为照片和视频选择，还可以与iCloud照片流进行交互。此外，一个非常重要的功能是它还可以监听其他应用程序对照片所做的更改。可以说整个框架非常灵活。
