在“应用间通信——iOS 的孤岛困境”一文中，我们曾经讨论过 iOS 上跨应用通信与内容分享的难题。而直到现在，在 iOS 上想实现跨应用的通信和内容分享依然是一件头疼的事，虽然我们已经可以使用 iOS 系统内部整合的分享功能，实现通过 Twitter、电子邮件、短消息的内容分享，但此功能尚未向第三方开发者开放，用户的选择相当有限，而虽然利用 URL Scheme 机制，开发者可以实现简单的跨应用分享，但一方面这一机制能够实现的功能有限（打开应用的某个界面、发送文本信息、提示用户输入内容等），同时通过这一机制将信息发送到第三方应用后，原应用会被随之关闭，无法保证用户连贯性的操作；另一方面，这毕竟不是一款应用的标准功能，许多应用对其并没有很好的支持，所以即使有像 Launch Center Pro、Draft 这样巧妙利用和扩展 URL Scheme，实现跨应用分享的第三方应用，但其在通用性上依然受到很大的限制。

那么，对于 iOS 的竞争对手们来说，这一问题是如何处理的呢？

Android 的 Intent 机制

一个典型的 Android 应用一般包含了多个组件，其最大的特点在于：组件并不像 iOS 那样，与应用本身严格耦合，一款应用不仅可以打开自己内部的组件，也可以直接调用其他应用提供的相关组件。通过定义文件，一款应用可以向系统注册自己的组件及其可以处理的数据，这为 Android 的跨应用信息、乃至功能的分享机制 - App Intent 提供了基础。

App Intent 是一套灵活的数据传递和调用方法，一款应用 A 既可以直接调用某个特定的应用组件，也可以向系统发送分享请求。在后一种情况下，系统将根据发送的数据类型，从所有安装应用所注册的组件信息中，筛选出可以处理该请求的组件，以列表的形式呈现给用户，用户根据自己的需要选择最合适的应用 B，随后数据从应用 A 发送到应用 B，在后台进行处理、或实际进入应用 B 的对应功能组件界面进行操作。得益于 Android 多任务的特性，在调用外界应用的功能模块时，原程序 A 不会退出，用户可以通过返回键轻松的回到分享前的应用状态。

Windows 8 （与 Windows Phone 8？）的 Contract 机制

而对于另一移动平台 - 微软的 Windows Phone 而言，在 Windows Phone 7 的时代，其与 iOS 非常类似，仅仅支持系统内置的、有限的几个分享渠道。但随着 Windows Phone 8 即将采用与 Windows 8 RT 版相同的系统架构，我们也许可以从目前已经完成的 Windows 8 的系统分享机制上看到未来整个 Windows 大平台的趋势。

在 Windows 8 的“Metro”界面下，当用户从屏幕右侧向中心滑动时（或鼠标移到屏幕的右侧角时），会发现其崭新的功能 - Charm 侧栏。这个侧栏包含了用户经常使用到的几个功能：返回主页、设置、搜索、设备、分享，其中的分享、搜索、设备、设置等功能实际上都是一种广义上的跨应用分享。对于像 iOS 一样，对采用应用沙盒机制的 Windows 8 来说，这一功能是通过一个名为Contract 的机制来实现的（所谓的 Contract，指的是 Windows 中不同 “Metro”风格应用间的一种标准通信格式，发送请求的应用和接收请求的应用可以分别向系统声明自己发送和接收数据的类型，由系统根据不同的情景和用户的选择对数据进行传递。）

具体到本文涉及的跨应用分享功能上，当一个应用 A 的 Charm 分享功能被激活，想要与其他应用进行通信时，其将根据分享 Contract 的标准创建出一个标准的数据包（可包含文本、链接、图片、文件等各种数据类型），并将其发送给系统，系统根据来源数据的类型列出可以处理该种数据的应用，当用户选定一个特定应用 B 后，系统将数据包传递给应用 B，进行对应的数据操作。在这一过程中，发送请求的应用 A 与处理请求的应用 B 之间没有直接的交互，在满足了沙盒安全性需求的前提下实现了跨应用通信的功能。

混乱的 iOS

与此相比， iOS 在这方面有着明显的缺陷，以至于许多开发者为了解决用户的需求，在自己的应用中独立嵌入了常用应用的分享功能（如 Evernote、Instapaper、Pocket 等）、独立的浏览器功能等。而从 iOS 5 中开始 Twitter 的整合已经很清楚的表明，这些任务理应是系统该做的工作。虽然目前已经确认，在下月即将发布的 iOS 6 中将正式增加 Facebook 服务的整合，但在庞大的 App Store 应用面前，仅凭苹果一己之力并无法真正解决用户分享的选择有限、操作体验不佳的问题。一个通用的分享 API 的存在将解决目前用户在 iOS 上面临的许多使用上的不便（不再需要在每个单独的阅读应用中分别登录 Evernote 帐号以进行分享、不再需要费劲的在 Mobile Safari 中添加书签脚本以发送文章稍后阅读…）；而开发者也可以从这些琐碎的杂务中解放出来，将精力放在更有创造力的想法上去。

正如 Windows 8 所展示的，在一个封闭的系统中同样可以优雅的实现跨应用通信的难题。但苹果是否会提供一个通用的 API 呢？从目前的 iOS 6 的测试版看来，系统通信和分享功能的整合依然是苹果主导的第一方行为。而考虑到在苹果已发布的 Mountain Lion 中，所谓 Back to Mac 的特性之一的“分享”菜单功能也并未向第三方应用开放，对于苹果在更加封闭的 iOS 上可能放宽控制的前景并不乐观。

当然，这也仅仅是预测，苹果是否会在最后给开发者和用户带来惊喜，敬请期待 9 月的苹果新品发布会。