论 iOS 11 上的 Drag and Drop

2017-10-06

曾几何时，「交互简单」一直是 iOS 引以为傲的资本。WWDC 2007 上，乔布斯演示的点击（tap）、滑动（swipe）、捏合（pinch）三个手势惊艳了世界，也奠定了 iOS 交互方式的基本格局。此后，iOS 极少引入新的触摸手势。在 Android 世界中地位显赫的长按（long press），在 iOS 中的作用仅限于排列图标和唤出少量菜单而已；iOS 4.3 中为 iPad 引入的多任务手势，也因与 Home 键功能完全重合而无足轻重。可以说，在很长一段时间中，用户为掌握 iOS 所需学习的全部手势，都不超出其靠直觉即能自行探索的范围。

然而，这种单一交互方式带来的易学性「红利」，逐渐被其对操作效率造成的严重限制所磨蚀。特别是到了 iOS 9 时代，苹果大张旗鼓地为 iPad 引入分屏多任务功能，并在宣传中将 iPad 渲染为下一代生产力设备，向笔记本公然宣战。与此形成对照的是，app 间便捷交换数据和信息的手段却依然付之阙如。想要将文件从一个 app 传送到另一个 app，用户要么用繁琐的复制—粘贴两步完成，要么用发现性极低的分享菜单（Share Sheet）；虽然也有开发者积极探索了 URL Scheme、Base64 编码等曲径通幽的方式，则因抽象难学，注定只能成为少部分极客用户的玩物。

iPad Pro 及其官方配件的问世一定程度上丰富了 iPad 的使用场景，但并未彻底改变上述困境。Apple Pencil 和 Smart Keyboard 与其说是两种新的交互手段，不如说是只是用户「手指的延伸」，为部分输入操作提供便利。要真正释放 iOS 的「生产力」属性，必须走出过度简化操作的窠臼，丰富 iOS 的交互方式。

这个问题的解决之道可能有很多，但有至少有一个答案是非常明显的，那就是为 iOS 引入拖放操作。作为一个在桌面操作系统上无处不在的功能，将拖放引入 iOS 可谓百利而无一害。一方面，用户对拖放操作早已烂熟于心、形成了肌肉记忆，将其移植到 iOS 上并不会带来额外的学习成本；另一方面，尽管拖放功能是与鼠标相伴而生的，但其与触摸输入的兼容性甚至更高——用手指挪动物件本身就是自然的下意识反应。可见，拖放操作完全符合 iOS 对交互操作简单易学、符合直觉的要求。正因如此，从很久以前起，关于 iOS 支持拖放的呼吁和谣传就一直存在。

今年，在新增功能上一贯谨慎的苹果，终于将它打磨到了有自信放出的阶段，这就是 iOS 11 中横空出世的 Drag and Drop。

其实，论及拖放在 iOS 上的应用，苹果并非先行者。早先，已有一些开发者自行在 iPad 上实现了基本的拖放操作，如 WPS 和 QQ、Readdle 系的 app（Documents、PDF Expert）间就可以直接拖放交换文件。但显然，这种 hack 无论在适用面还是功能上都是极其受限的。

而系统层面的 Drag and Drop 则完全不同。作为 iOS 11 的主打功能，Drag and Drop 身肩释放 iPad 生产力、改变 iOS 之前刻板印象的重要使命，受到的待遇也非同一般。为了推广 Drag and Drop，苹果不仅在今年六月的 Keynote 上做了长篇演示、在 iPad 和 iOS 的文案中广泛宣传，还在 WWDC 期间开设四个 session 专门向开发者教授其用法，并给出了详尽的文档和实例，鼓励开发者使用。另外，与之前 iOS 中新功能需要 app 主动适配不同，对于文本、图片、部分列表等对象，Drag and Drop 是「免费」的。换句话说，开发者什么都不用做，只要用户安装了 iOS 11，也能在第三方 app 中一定程度上享受到 Drag and Drop 的便利。

综上种种，将 Drag and Drop 称为近两年来 iOS 最重要的新增功能，恐怕并不为过。

Drag and Drop 的基本用途

iOS 11 中的 Drag and Drop 在用户可感的层面是十分简单易用的。其主要的功能用途可归结为三点：

**排列图标和文件：**在主屏幕上，短促地按住图标即可开始拖动，无须再像之前版本那样需要长按进入图标整理模式（尽管该操作现在仍然可用）。在拖动某一图标的同时，用其余手指点击其他图标还可将其加入拖动队列，一并拖动。部分 app 中的文件图标也可以同样的操作逻辑用拖放方式排序。
**多任务管理：**主屏幕和 Spotlight 搜索结果中的图标均可直接拖入当前运行的 app 界面上，从而开启分屏多任务。
**数据传输：**这是 Drag and Drop 最主要的应用场景。文本、图片、链接乃至任意文件现在均可直接拖动至目标位置。一般地，同一 app 中的拖放相当于移动，而不同 app 间的拖放相当于复制。

此外，熟悉 macOS 的用户一定还知道一种便捷的拖放操作——Spring-loading。即可将一个对象拖至另一个图标上并短暂停留，以使后者激活并打开。例如，将文件拖放并停留在 app 图标上，可用该 app 打开文件；将文件拖放并停留在文件夹图标上，可打开该文件夹窗口等。iOS 11 同样对 Spring-loading 操作提供了原生支持，从而大大拓展了 Drag and Drop 的使用场景。

Drag and Drop 在 iOS 上的特点

如上所述，Drag and Drop 彻头彻尾是一个继受自桌面系统的功能。但这并不意味着 iOS 上的拖放操作与电脑上完全雷同。相反，苹果在 Drag and Drop 中充分考虑了 iOS 作为移动操作系统的特点，对「一拖一放」这一简单的操作进行了不少改进和完善，形成了一套自成体系的操作逻辑。个中差别，在上手之初可能并不容易发现，但只要发现了规律，就能体会到其设计的巧妙和便捷。

充分支持多选

在桌面系统上，用户若想同时拖动多个对象，要么用指针框选出一个范围、要么按住 Shift/Command 等按键并多次点击。总之，选择对象必须在开始拖动之前完成。而在 iPad 上，这个限制并不存在：你固然可以先选中一系列文件，然后开始拖动；但更多时候，你都可以先按住一个对象使之浮起，然后挨个触摸其他想要一并拖动的文件，让它们「飞到」第一个文件下面堆叠起来。这颇有一种提着篮子挑选商品的感觉——容错率更高、操作起来也更愉悦。
拖放可与其他操作并行

在电脑上，一旦开始拖动，用户就不便同时进行其他操作，如切换程序、卷动页面等。毕竟，我们只有一个鼠标。（熟练用户当然可以通过键盘做到这一点，但这对大多数人还是困难的。）但我们有十根手指。iPad 上，在用一根手指拖动的同时，空闲的手指仍然可以照常与界面交互，无论是基本的点击、滑动，还是 Home 键、多任务手势，都保持完全的可用状态。这就为 Drag and Drop 带来了极大的灵活性，例如：
- 一只手拖住主屏幕上的图标，另一只手从下边缘上滑唤出多任务界面，将图标拖到其他 app 的预览图上，以开启分屏；
- 一只手拖动当前 app 中的文件，另一只手用四指平行滑动切换到前一个 app，然后松手将文件扔到该 app 中。
- 一只手拖动 Safari 中的一段文本，另一只手在右侧的 Notes 中上下翻找，然后将该文本拖放到笔记中的合适位置。
还有很多可能性，限于篇幅不能一一列举。但只要把握了「拖放不影响其他操作」这一原则，iPad 上 Drag and Drop 能实现的有趣操作几乎是无限的。原本作为 iPad 看家本领的多点触控机能，却在移植自桌面系统的拖放功能上充分彰显，这不得不说是一种奇妙的化学反应。
可定制性强

在桌面端，整个拖放过程涉及的界面元素，如鼠标指针的变化、被拖动对象的外观等，一般是由系统控制的，因此是固定的。而 iOS 11 中的 Drag and Drop 却赋予了 app 开发者相当大的灵活性。根据官方文档的表述，开发者可以自行设定拖放过程中的下列元素：
- 动画：包括拖放对象浮起和放下时的动画。
- 预览图：拖放对象的预览图在拖动过程中可随着其位置不同而实时变动。例如，从 Mail 里拖出的邮件，在移动到其他收件箱上方时会显示为一个信封图标，而当被拖到 Notes 中的文本区域时，就会显示为邮件内容预览。
- 角标：拖动对象的右上角可以角标形式显示数量，或显示一个允许/禁止图标，以指示手指当前位置是否支持接收这些对象。
略显遗憾的是，因为 iOS 11 推出时间尚短，上述特性目前基本只能在系统内建 app 中见到，第三方 app 对此适配较少。但随着开发者逐渐摸清 Drag and Drop 的潜力，相信充分发挥这种可定制性的第三方作品会越来越多。

理解 Drag and Drop 的机制

在了解了 Drag and Drop 的上述特性后，我们不免产生疑问：为什么 iOS 上的拖放功能与桌面系统存在这些区别？App 是如何做到在拖放过程中实时变换预览图的？为什么图片拖放到文本区域可以自动粘贴为链接？Drag and Drop 是对 iOS 沙盒机制的突破吗？要回答这些问题，就要详细了解 Drag and Drop 的实现机制。

与用户操作时感受到的简便和符合直觉不同，Drag and Drop 在系统层面实际上是一套相当复杂的流程。根据苹果的设计，一个完整的拖放会话（session）牵涉到源 app、目标 app 和 iOS 三方，并包含四个阶段：

Lift（拾起）：指长按某一项目，使其浮起并显示预览的阶段。
Drag（拖动）：指手指持续接触屏幕并移动的阶段。在该阶段，用户可以用其余手指点击想要一并拖动的对象，还可以将对象拖动并停驻在 app 图标、文件夹等位置上、使其闪烁并自动打开（Spring-loading）。
Set Down（放置）：指在松开手指、释放拖动对象的阶段。如果放置的目的地接受该对象，则进入后续的数据传输环节；如果目的地不接受该对象、或不支持拖放，则拖放过程终止。
Data Transfer（数据传输）：指目标 app 向源 app 获取数据的阶段。

如果你觉得太抽象的话，可以比照中介卖房的流程来理解：

某甲（源 app）欲卖房（拖放对象），于是找到中介公司（iOS），该公司听取了甲对房屋基本情况（对象类型）的描述，记录了房源信息（拖放对象预览）。
中介公司张贴房源信息，并向不同客户介绍和推荐。
某乙（目标 app）了解到该房源后，认为基本满足自己的需要（能接受拖放对象），便与中介公司开始洽谈。中介公司在甲的委托下，与乙讨论了付款方式（传输数据的方式）、内部装潢（拖放对象的呈现方式）等具体问题。甲乙最终达成合意（放置对象）。
在中介公司的指导下，甲向乙交付了房屋（传输数据）。

从上述过程中，我们不难看出 Drag and Drop 的一些基本原则：

被拖动的不是数据，只是数据的替身

在拖动过程中，我们似乎是拖着对象在屏幕上四处移动，但实际上在我们指尖下的只是对象的替身（visual representation）而已。正如房子不可能被背着四处兜售，卖主只要提供房屋的照片和基本信息就够了，拖动过程中的源 app 要提供的只是数据的预览图和所属类型。其中，数据的类型是通过 UTI（Uniform Type Identifier，统一类型识别符）记录的，这也是 iOS 和 macOS 中用于标记数据类型的通用方式。
目标 app 直到放置阶段前都无法接触数据本身

正如只有在房屋交付之后，买受人才能取得对房产的合法占有；只有在用户松开手指（放置）之后，目标 app 才能接触到真正的数据。在此之前，它能做的只是讨价还价（更新预览图、角标，声明可接受的文件类型）、表示接受或拒绝而已。
同一个对象可包含不同类型数据

与精明的买卖一样，Drag and Drop 也讲究「见人说人话，见鬼说鬼话」。不同买家的偏好和预算各不相同，房子虽然还是那套房子，但是精装房还是毛坯房、带不带家具电器、车位和公摊怎么算，都是可以 argue 的重要细节。类似地，源 app 在将数据交给目标 app 的过程中，也可以在同一拖动对象中提供多种类型的数据，让目标 app 根据其需求自由选择。例如，Safari 里拖出的图片链接，如果拖进相册，就可以呈现为图片；如果拖进文本框，就可以呈现为链接文本。GoodNotes 里拖出的手写笔迹，可以变成 png 图片、也可以变成 OCR 识别出的文字。可见，与其说我们拖动的是一份数据，不如说是一组数据的集合。

现在问题来了：为什么要花心思、费力气设计这样一套拐弯抹角的拖放流程呢？在 MacStories 的 iOS 11 评测中，Federico Viticci 对此作出了一些推测。在他看来，如此设计的用意有三：

保证兼容性

既要保持数据的本来面貌、又要让它能 drop 到尽可能多的目的地，这是鱼与熊掌式的矛盾要求。而通过允许在一个对象中包含不同类型的数据，iOS 上的 Drag and Drop 得以实现两者兼顾。
提高性能

容易理解，如果用户拖着文件每滑过一个 app，都要进行一次正式的数据传输，那无论从效率还是性能上都是不可接受的。iOS 上的拖放机制只在确定放置后才传输数据，节约了很多不必要的资源开销。更重要的是，这一机制还能充分发挥 iOS 11 新引入的文件系统格式——APFS 的优势。APFS 的一个重要特性是「Copy on Write」，即在复制数据时，系统并不会真正将数据「增殖」一份，而只会在其元信息上添上一笔，注明这份数据也可以通过另一个地址被找到；直到复制后的数据需要修改时，系统才会真正将其原样复制出来并作修改。这简直是为 Drag and Drop 量身定制的——数据传输阶段因此根本无须发生实际的数据读写，大大节约了性能和空间。这或许也就解释了为什么 Drag and Drop 在旧款 iPad 上也能无迟滞地完成。
保护隐私

这可能是最重要的考量因素，也是 iOS 在各个功能设计上的首要追求之一。如果一个 app 仅仅因为用户的手指滑过界面，就获得对拖动中文件的访问权，那显然是对数据安全和隐私的极大威胁。而在 iOS 的设计下，目标 app 在用户抬起手指前能获取的无非是文件类型而已，这就预防了恶意第三方 app 对 Drag and Drop 的滥用。

Drag and Drop 的不足与展望

不过，作为苹果在 iOS 上全新交互的初次尝试，Drag and Drop 也有很多不完善之处。

**首先，Drag and Drop 的设计还有不完善之处。**尽管拖放功能早已为用户所熟悉，但当它与 iOS 上的既有操作逻辑产生冲突时，还是会让用户感到困惑乃至恼怒。

这方面，最典型的例子就是 iOS 11 的主屏幕。在引入 Drag and Drop 后，主屏上的图标操作变得十分多样而复杂：轻按——启动、短按后松手——打开最近文件列表、短按并拖动——移动图标、长按——进入图标整理模式。可以看到，上面四种操作的触发方式，唯一的区别就是手指接触屏幕的时间长短。实践中，这种微妙的差别即使对熟练用户也是难以把握的，更遑论那些并不熟悉 iOS 的用户了——而他们中的很多正属于苹果试图抓住的移动办公市场。

**其次，Drag and Drop 对于 iPhone 的支持极其有限。**目前，iPhone 上的 Drag and Drop 仅限于同一 app 中的拖放，而不支持不同 app 间、及主屏幕与 app 间的拖放。

诚然，在 iPhone 那种尺寸的屏幕上，Drag and Drop 的发挥余地有限，但这并不足以成为限制其功能的理由。实际上，就 iPhone 的普及率和使用场景论（据统计，在亚洲地区，iPhone 是很多人第一台、甚至唯一一台「计算机」/Computing Device），其对 Drag and Drop 的需求甚至还要高于 iPad。另外，从 Castro 等 app 的早期探索看，拖放功能在 iPhone 上完全可以玩出花样，Taptic Engine 等机能赋予的额外交互反馈（如拖动项目时屏幕微妙的震动），也带来了更愉悦的体验。可见，苹果在 Drag and Drop 上对 iPhone 的特殊「歧视」，确实值得商榷。

**再次，Drag and Drop 尽管备受青睐、甚至获得了很多「特权」，但并未突破沙盒机制的限制。**从前文的 Drag and Drop 机制总结可以看出，iOS 11 上的拖放操作，从头到尾是处在 iOS 这个「中介」的严格监视之下的，app 间的一切数据交换都要通过系统进行，私下的「场外交易」是不被允许的。这固然是保证安全性和隐私之举，但也限制了第三方开发者的潜力，使 Drag and Drop 或多或少成为了一个仅在于提高操作效率的「buff」、而不是一个革命性的「killer feature」。

当然，从另一个角度看，Drag and Drop 在发布伊始就已经具有如此完成度，已属惊艳；上述诸多不足，也为该功能之后的持续完善提供了预期。试想，如果在今后的 iOS 中，Drag and Drop 能进一步做好交互丰富程度和清晰性间的平衡、补全对 iPhone 的支持、增加第三方 app 的灵活性，那必将让 iOS 设备的生产力更进一步。

总之，在移动设备硬件战争日渐疲软的当今，软实力的高下已经成为用户决策的首要因素之一。iOS 11 对 Drag and Drop 的支持，既是众望所归、水到渠成，也是形势所需。苹果已经在 iOS 设备的开放性和生产力上做出了持续和卓有成效的努力，但它能在这条路上走得多远、用户又会在多大程度上接受，仍然需要观察。而对于爱好者而言，这份不断更新的未知和期待，或许本身就是科技产品的乐趣之一。