iOS的Share Extension分享机制

在最近参与的项目过程中，我发现一个有趣的现象。国内的App开发者，在设计“分享”这个功能的时候，一般都会根据业务的实际需要，设计一套自定义的解决方案，我们姑且称之为“自定义分享插件”。而相比之下，国外的开发者更倾向于使用iOS提供的系统级的Share Extension，我们姑且称之为“原生分享插件”。那么，这两种方案，各有什么特色和优缺点呢？

国外的App一般都会采用iOS的原生分享插件，图为Amazon、Ebay、Etsy。 国内的App一般都会采用iOS的原生分享插件，图为微信、淘宝、知乎

什么是原生分享插件？

我们先来简单看一下什么是苹果的原生分享插件Share Extension。前面说过，由于中国App开发大量使用自定义的分享方式，所以可能很多设计师还不熟悉原生分享的机制。另外，苹果直到去年的iOS8.0才重新定义了iOS的Extension机制，并重新设计了Share Extension，使得她真正变得好用而受到开发者的认可。所以，原生分享插件对于我们来说，其实还挺新的：）

在早先版本里，从iOS5到iOS6，乃至iOS7，分享插件的界面设计进过了几次变更，但是功能上一直十分有限，一开始仅限于系统级和系统原生应用的内容传递，例如发送照片内容到邮件和短信，或者从Safari保存网页等。后来苹果通过与Twitter和Facebook等几家公司签订独立的协议，实现了整合的方案，使内容分享到这些应用的过程更方便。

但是苹果显然也意识到了这一点，即系统和应用，以及应用与应用之间传递内容信息的需求是用户真实存在的需求，需要一个真正系统级的解决方案，就像当年的Push Notification那样，一个方案解决所有App的问题，而不是一家一家地去签协议。

历代iOS的分享界面

所以，在去年的iOS8发布时，苹果对分享机制做了大刀阔斧的改变，这就是新的Share Extension，原生分享插件。App开发者只需要在开发过程中，为App加入原生分享插件，向系统注册，就可以通过Extension来实现与系统和其他App的内容分享了。原生分享插件就相当于一个中间媒介，可以接受Host App（发送内容的App）提交的内容，转交给想要分享到的Containing App（接受内容的App）。、

Share Extension的工作原理

举例来说，如果你开发的是一个电商类App，希望鼓励用户把App上的商品分享给他们的朋友或者社交媒体，那么通过挂载和注册原生分享插件，以后用户想要分享App上的内容时，唤出分享界面，就可以把内容分享到系统上的任一（注册了分享插件的）位置。相反，如果你开发的是一个社交App，并鼓励用户从其他内容源分享内容你的App，同样需要注册到分享插件，表明你同意接受由它发送来的内容。

当然，不同形式的内容也不是随便就到处传递的。无论你是发送内容的Host App，还是接受内容的Containing App，都需要向原生分享插件描述清楚，要发送或接受的内容是什么格式，比如图片视频、文本还是链接。这被称为Activation Rules。也就是说，假如用户要分享的是一段文字，那么当他点击分享按钮时，弹出的Share Sheet上，就不会显示Instagram和Pintrest这类App，因为他们只接受图片分享。这也就是说，尽管是同一个原生分享组件，但是在不同的App上，它出现时显示的内容会自动根据要分享出去的内容性质做出变化。

所以，iOS的Share Extension原生分享插件，就像一个巨大的内容中转站，在系统和App，以及App之间建立起关联，方便内容的传递。

那么为什么要采用这样一种集成式的设计思路，而不是鼓励各App之间点对点传输呢？

最大的优势就是安全性和便利性。

iOS上的App被设计在一个“沙盒”里，App与系统间，以及App与另一个App之间的数据传输是受到严格限制的。所以我们经常遇到App在使用相机、相册或者GPS传感器时，都要请求用户同意的场景。这样设计的好处就是苹果的设备安全系数很高，恶意软件和病毒很难入侵。在这种情况下，如果系统允许App随便传递内容信息，肯定是不行的。App们互相之间如果要传递信息，也要先建立信任，也就是授权。所以在没有原生分享插件的时候，每一次分享动作，伴随的都是可能要一次新的授权（如果你自定义分享插件，情况便是如此）。而原生分享插件，就是将这些授权全都集中起来，由系统平台一次完成（App向系统注册时）。这样，iOS通过这种集成的方式，既能保证沙盒机制不被破坏，又实现了系统层面的信息分享。

当App注册了原生分享插件，一方面，它就可以通过插件向系统和其他所有（也注册了分享插件）的App发送内容，只要对方接受内容的形式（图片、文本等）。另一方面，它也同意接受来自插件的相应内容。这意味着，用户在iOS设备上，从任意一个App分享内容到其他任意一个App时，都不用再额外进行一个App之间的授权动作了。分享真正变成系统级别的，无处不在的。

并且，这个方案的系统整合程度很高，意味着，在实际的交互场景中，用户甚至可以不用跳转到他要分享的那个App里去操作，而是直接在当前界面完成分享，然后继续该干嘛干嘛。

用户在Pintrest里将内容分享到Evernot

讲完了这些，那么问题来了：

既然苹果的这套Share Extension机制这么好，为什么国内的App们还偏要自定义分享插件呢？

最大的问题在于，App的开发者想要分享内容到甲乙丙，而原生分享插件显示的是ABC。

苹果在设计原生分享插件时，是从所有用户的习惯角度出发的，如果用户经常分享内容到Facebook和Pintrest，而不常用Twitter，那么他可以通过Share的Action Sheet上的“更多”按钮，进入一个设置页面，在那里调整分享到App的顺序，甚至把不常用的分享渠道关掉。

分享的目标只有用户自己能控制

这显然不符合国内一些开发者的口味，尤其是BAT这样的大公司。微信就关闭了对原生分享的支持，而选择了大量的自定义，所以我们可以看到微信的Share Sheet上出现了“收藏”、“调整字体”等跟分享毫无关系的功能。淘宝的分享也是自定义的。这类大公司的逻辑更多是让分享内容在自家的生态体系里流动，而不是整个平台。

国内的开发者更喜欢自定义

一个非常有意思的特例是Pintrest。这家公司在自己的App上也使用了自定义的分享插件，为了方便用户把内容分享给App内的好友关系圈。但是如果在自定义的sheet上点击表示“更多”的那个“…”红色按钮，这是App又会调出原生分享插件。真是既满足了自己的小算盘，又照顾到了全平台的用户。而这样做的副作用就是，如果用户在第一个自定义Sheet上点击分享到Facebook，则调用系统分享编辑界面，而如果用户是在第二个原生分享sheet上点击，则会跳转到Facebook App里去做分享内容编辑。

Pinterest兼顾了两种分享机制，先启用自定义分享，用户点击“更多”时，启用系统的原生分享 在两个不同的分享插件里，点击分享到Facebook时，界面体验是不一样的