专栏 | 作为组件的捷径 & 捷径整理心得

我的捷径库里有超过 200 个捷径，为了解决它们的整理问题，我摸索出了一套比较有效的办法，可以让捷径在它最该出现的地方出现，让我在想调用任何一个捷径的时候都能最快地调取它。

但是在介绍这一套方法之前，我还要先给大家的捷径库再加点料——再在你们的捷径库里加入一类特殊的捷径——组件类捷径¹ 。

组件类捷径

组件类捷径，指的是那些经常会被其它捷径调用的通用功能。比如：

• 链接输入判断：链接输入判断会被下载类的捷径调用，比如下载微博视频、微博图片、下载 Twitter 视频、下载 Youtube 视频等等，在一开始都免不了要判断一下是不是有链接传入，如果没有的话调取剪切板等等。

• 上传图片到图床：以图搜图的捷径、OCR 的捷径都会用到上传图片到图床后返回的链接。

• 合集类捷径要调用的小捷径：比如 5 个和 App Store 相关的捷径组成一个「App Store 五合一」的捷径。

那么肯定有人要问了，为什么我们要把这些捷径单独做出来，而不是直接把它们的完整操作放到另一个捷径里呢？

这主要是因为维护成本的问题。这个维护成本主要分为两个情况：

1. 一处修改处处适用

2. 仅修改复杂捷径中有错的部分

我们先来看「一处修改处处适用」是怎么回事。

「输入判断」、「上传图片到图床」这种需求，我们的捷径库里一般有多个捷径都会用到。如果我们在每个用到这些需求的捷径里，都分别做了一套一模一样的操作，费时费力不说，修改起来也会非常麻烦。

有人可能会问，为什么我们要修改？这是因为我们对一个事的理解未必一开始就是对的，像「输入判断」这类捷径的逻辑，对于初学者来说并不算特别简单，它要绕几个弯。如果最开始用了一个错的逻辑，随后在很多捷径里都重复了这个逻辑，摆起来还越来越熟练，那等他晃过神之后再改，就要每个用到这套逻辑的捷径都要重改。

所以，不如把「输入判断」这类捷径专门做出来，哪个捷径需要判断输入，不管是文字、链接还是图片，都有直接对应的捷径可以直接调用。这样做的时候方便，不用把同样的操作重新拖一遍；改的时候也方便，只要把这个组件捷径改了，其它所有用到它的捷径就都没问题。

讲明白了「一处修改处处适用」，我们再来看「仅修改复杂捷径中有错部分」。

Workflow 流行之后，就有一些人喜欢做「超级 Workflow」，企图一个 Workflow 解决所有问题，比如说一个捷径下载所有网站的视频等等。这种势头在捷径时代是有增无减。

但是这种「X合一大捷径」的最大问题是维护困难。捷径这个东西和 App Store 里的 App 不一样，没办法由作者随时修 bug 再推给使用者更新，而且作者也不会得到分文的收益，所以更不会有动力去长期维护非自用捷径。那么这时候，这种又长又复杂的「X合一大捷径」一出问题，维护的重担就掉在了使用者身上。

看这种「X合一大捷径」的感觉不比看祖传代码² 舒服多少。就算能看的下去，还看得明白，也得想想捷径这种拖动操作，有可能一分神一手滑就不知道刚才拖的那个操作掉到哪个位置了。老问题没修好，还容易把整个捷径都整崩了。

因此，最好的办法，还是下载、制作单一功能的捷径，让它们成为「X合一捷径」的组件，在「X合一捷径」里使用「运行捷径」这个操作来调用它们。这样的话，哪个部分出现问题，就可以单独去修哪个部分。不仅减少了维护的工作量，也不会影响到其它捷径的正常工作。

解决闪退问题

不管你是否接受我关于「组件」类捷径的建议，在整理捷径的整个过程中，我们都很容易碰到「闪退」这个问题。

捷径闪退这个问题主要有这两种情况：第一种是运行时内存不足（或遇上 Bug，比如使用测试版本的 iOS 系统或捷径），这种情况很好处理，退出应用再打开，或者是重启设备都能够解决。而第二种情况，是由于多设备同步时出现的冲突。

同步冲突问题的终极解决手段，是删除捷径后重新安装。但是这个方法有个严重的弊端，是它高概率会恢复捷径闪退那个设备的捷径排布。

比如说我们有两个设备，iPhone 和 iPad。当我们在 iPad 上按照后面的思路，辛辛苦苦把自己上百个捷径调整颜色、调整位置之后，打开 iPhone 上的捷径却发现闪退。这时候我们如果删除 iPhone 上的捷径再安装回来，iPhone 上的捷径排布会是过去的排布，而且这个排布会同步到 iPad 上，也就是说前面的整理将功亏一篑。

其实当两个设备发生同步冲突时，并不是非得通过重装捷径来解决。一般来说，删除发生变动的那些捷径，特别是最近几个变动的捷径，一般就能解决闪退的问题。

如果不想让捷径出现同步冲突，比较保险的办法是在整理一个设备的捷径时，把其它设备的捷径打开，实时观察排布的变化是否同步到了不同的设备中。这样起码能保证在发生冲突时，只修改最后一个变动的捷径，把损失降到最低。

总结下来就是，如果遇到捷径闪退：

1. 尝试重启捷径、设备。

2. 在捷径不闪退的设备上删除最近变动了的捷径。

3. 在捷径闪退的设备上重装捷径（万不得已时）。

如果想在第一次大型整理捷径时避免同步冲突造成的损失过大，可以在一个设备上调整捷径排布时，打开另一个设备，实时观察同步情况。

整理捷径时的摆放顺序

还有一个方法可以尽量避免调整捷径后导致的同步冲突，那就是调整捷径的时候应该从上到下依次排序。就像写文章要从左起第一个字开始一样，捷径也需要从左上角第一个开始放置。在我的设备上，如果不这样做的话，捷径的同步状态会有很高的概率被还原到之前的状态。所以在第一次对捷径进行大扫除时，我们需要从左到右、从上到下地去安放捷径。

我曾经为了求快，用了「两头堵」的方法，把相对靠前的捷径放在了前面，把相对靠后的捷径放到最尾。其结果是被整理好的捷径一次次地被还原甚至被打为乱序。最终我终于发现，在整理大量捷径时，只有从左上角开始放置捷径才是最稳妥的。

当然这个问题不是不能被修复，不过在它被修复之前，我们只有先遵守这个潜规则，才能让整理时的风险降到最低。

整理捷径

在了解了如何避免/处理闪退，以及捷径从上到下的排布「潜规则」之后，我们就可以来实施我们的排布计划。整个计划从分类开始，首先我们要根据捷径色块的颜色，来区分不同的捷径类别，并把同一种类别的捷径，也就是颜色相同的捷径放在一起。

我的捷径分类与颜色的对应关系如下（按在捷径应用中的位置由上到下排列）：

1. 「今天」视图类捷径：橙色

2. 独立运行类捷径：黄色

3. 共享表单类捷径：蓝色

4. 组件类捷径：灰色

5. Apple Music 相关捷径：红色

6. Evernote 相关捷径：绿色

7. 未完成待研究的捷径：粉色

8. 从别人那里下载的捷径：紫色

这么区分捷径主要是根据两个原则：

首先按照使用场景决定颜色，例如第 1/2/3/4/7/8 种类别都属于此列。5 和 6 是关于某个应用的捷径过多，足以单独拉出来单独赋予一种颜色的特殊情况。这个原则的好处是整体视觉效果统一，不光捷径应用内部，「今天」视图和共享表单里的颜色将都是统一的：

其次是在场景冲突时，按主要场景决定颜色，比如有些捷径符合 1/2/3 三类场景，本来独立运行的捷径就包括了「今天」视图类的捷径，而且「今天」视图类的捷径还总是跟分享插件的捷径重合，比如下载视频类的捷径都有这个问题。对此的解决思路是，把下载视频类的捷径设为蓝色，放到第三部分——共享表单类捷径之中，但与此同时，允许它在小组件中显示。所以在上图中，我们会看到「今天」视图里有一个蓝色的捷径，这反而会让它更容易被找到。

明白了这两个原则之后，我再来具体讲解一下我所使用的分类、排序的原因。如果配色有特殊原因的话，也会谈及配色的特殊原因。

「今天」视图类捷径，一般是可以单独运行，而且相对常用的那些捷径。有一些捷径可以独立运行，也可以通过各种共享表单调用，我们就按照它最常用的使用场景来决定它该分为哪一类。如果它非常常用，而且主要是独立运行，那么就分到第 1 类，「今天」视图类。而且我们可以考虑牺牲它在共享表单里使用这种情况，也就是关掉「在小组件中显示」的开关，因为不这样的话，你会在共享表单调用捷径时，发现一些颜色不统一的捷径，看着比较难受。而如果是它更经常通过共享表单被使用，就应该把它分到第 3 类，共享表单类捷径，不让它在「今天」视图里显示。

独立运行类捷径的准确定义其实是，可以独立运行但不常用的捷径。如果这类捷径常用，它们就应该升格成为第 1 类捷径，「今天」视图类捷径。在所有列表的最上面。

共享表单类捷径比较容易理解，就是主要通过共享表单使用的那些捷径。把它设为蓝色是因为最初用 Safari 的时候经常调用捷径，所以就把这类捷径设为了和 Safari 相近的蓝色。

从共享表单类捷径往下，不同的类别就没什么必然的位置顺序了，完全可以按照各位自己的使用情境和顺手程度来做。把「今天」视图类捷径放到最顶，是因为捷径在「今天」视图里的排序是应用内的排序，如果不想让「今天」视图里意外出现其它颜色的捷径，改变原有的位置，最好的方法就是把它们都堆在顶部。这样就算「今天」视图里新出现了其它捷径，也是在最末尾，不会影响原有的位置。而把独立运行类捷径紧贴着「今天」视图类捷径放到第二位，主要是因为这两者其实本质上是一种捷径，都是可以独立运行的捷径。而且独立运行类捷径不需要通过共享表单调用，所以不会在共享表单里出现，因此也就不影响共享表单里最顶部那些捷径的位置顺序。共享表单类捷径在捷径应用内紧接着出现在第三位也是这个原因。像是后面的 Apple Music 捷径和 Evernote 捷径其实都需要通过共享表单调用，但是它们属于专属用途而不是通用用途，所以要往下靠一靠。最常用的，在哪个应用里都可以调用的那些捷径自然要放在更靠上的位置。

组件类捷径的好处前面已经介绍过了。因为它们这种特殊的存在方式，导致它们实际上都不是为了用，而是为了调用的，所以我把它们设为灰色，最不起眼。

Apple Music 相关捷径 和 Evernote 相关捷径 是两个应用类捷径，为它们做的捷径太多，不管是把它们放到「今天」视图还是调用共享表单都会占用过多位置，所以首先我会把它们换个专属颜色，不管是在共享表单还是捷径应用内部都很醒目。另外，这些类别的捷径里，属于「今天」视图类捷径的，我会专门制作一个多合一捷径，比如「Apple Music 多合一」，把它放到「今天」视图里，来统一调用 Apple Music 捷径。

未完成待研究的捷径看名字就知道是那些我们还没完成，卡到某一步进行不下去的捷径。那些实用价值不大，但是思路很奇特的捷径也在此列，我这里就有一些像是什么「制作倒序列表」的捷径。这些捷径本身的思路很有价值，未完成的那些如果已经做了不少，攻克了一些难题，也可以留下来等日后换个思路再去解决。

从别人那里下载捷径的主要目的一般还是为了学习和见识思路，很多都舍不得删。专门为它们设个颜色是因为有时候捷径太多，这些不是我自己做的可能连名字都记不住，但我能记得这是从别人那下载的。所以根据这个原则，把从别人那下载的捷径全设为一个颜色，就能在想起某个思路时缩小查找范围。

结语

捷径整理起来不容易，使用频率低的话，确实有些出力不讨好的味道。也因为这样很多人的态度是大删特删，认为没有必要留下那么多捷径，而是应该只留几个最常用的。

但是很明显，确实会有一些我们也许不常用，但做起来不容易的捷径。还有一些甚至没有用，但它的思路很妙，我们留下它不占什么手机容量，在日后用得上它时还能参考。这也留一些那也留一些，平常自己再做一些，只要养成了捷径思维，喜欢拿捷径解决问题，那捷径堆成山是早晚的事。

「扔」是在「整」失效之后的事。比如有的人家里空间不大，还爱买衣服，旧衣服不怎么穿还占地方，买了新的都没地方挂。这样的话确实是得扔点儿旧衣服，或者说其实是不得不扔。但要是家里的地儿还足够呢？就说还是那么多衣服，但衣架还没放够一半儿，还要扔吗？这时候很多人的答案就会转变了。所以旧衣服扔不扔，对于很多人来说重点实际是有没有地方放，而不是自己是不是喜欢是不是会穿。东西的多少往往是相对于空间的大小来说的。

不会整，空间大东西少也会乱；会整，空间小东西多也能有序。