引言

子曰：“工欲善其事，必先利其器”

在日益追求降本增效的大环境下，个人效率越高，咱们就能卷死其他工友（手动狗头）。

怎么提高效率呢？这是一个好问题，其实咱们学习工作中很多机械、重复的流程、可以通过代码来代替人工操作的内容，都可以抽象成工具，这些工具咱们称之为应用软件。

但是为每一个小工具开发一个完整功能的软件又有些小题大做，不但占用系统资源，而且因为不同工具软件的入口不同，反而增加了使用成本，降低了效率。

针对上面的问题，很多工具软件都设计了优秀的插件系统，方便广大开发者使用规定的API开发插件，从而实现在一个软件内使用不同的提效插件。

平台

笔者习惯把带有插件系统的工具软件称为平台，可以让咱们开发的插件在其上大展拳脚。

Alfred

Alfred 是一款屡获殊荣的 macOS 应用程序，它通过热键、关键字、文本扩展等来提高您的效率。 搜索您的 Mac 和网络，并通过自定义操作来控制您的 Mac，从而提高工作效率。

以上介绍摘自 Alfred 官网，可以看出，作者对自己产品有强烈自豪和信心，而笔者在实际使用后发现，作者没有吹牛，的确提效很多。

使用方式和 macOS 自带的“聚焦”类似，唤出输入框以后输入关键字即可匹配内容，可以完成快速打开对应软件，查找文件等功能。

Alfred 还内置了很多提效工具，如浏览器书签检索、剪贴板、计算器等等。

比较遗憾的是 Alfred 仅支持 macOS，Windows 用户无缘体验如此高效的工具。

Workflows

除了内置工具外，Alfred还有 Workflows 工作流功能，可以让用户方便快捷地开发插件，并且导出分享。

Alfred Workflows 提供了多种多样的功能模块，包括输入输出、触发器、流程控制，以及调用系统能力的模块，可以运行各种脚本语言的程序来扩展功能（需要用户系统中有对应的语言的runtime）。

Raycast

Raycast 和 Alfred 一样，只支持 macOS，作为 Alfred 头号竞品，Alfred 出彩的功能它都有，而且在 UI 设计上更胜一筹。

在插件开发方面，Raycast 与 Alfred 差别较大，Raycast 的插件开发流程类似 VSCode，通过命令创建脚手架工程，开发完毕后构建并发布到官方插件市场供用户选择，现在插件市场已有 500+ 款不同类型的插件。

Raycast 的插件由React、Node.js、TypeScript构建而成，对前端同学十分友好。

uTools

uTools 是一款优秀的国产工具软件，使用方式与上面两个工具类似，唤出输入框可以匹配关键字打开软件或搜索文件，输入或者粘贴文字、图片、文件触发支持处理该内容的插件，效率提升明显。

除了输入框外，uTools 还有个亮点是它的“超级面板”功能，长按右键即可唤醒，与当前选中的文本、文件联动，快速联动插件，效率贼高。

uTools 有详细的中文文档以及活跃的开发者社区，最重要的是，它基于 Electron开发，做到了跨三大操作系统，插件只要注意平台区别，即可在三大操作系统下运行。

虽然 uTools 有很多优点，但是实际体验下来，还是有一些可以优化的地方（后续 uTools 篇会细说），不过瑕不掩瑜，uTools 未来可期。

猎豹 Cheetah

上面介绍了几个比较优秀的工具软件，接下来再说说咱们的主角“猎豹 Cheetah”。 这是一款检索本地 Git 项目并快速通过制定软件打开的插件，目前已经实现了 Alfred、uTools版本，Raycast版本还在规划中。

插件的运行原理如下：

1. 在用户配置的工作区目录下递归查找并记录包含 .git 目录的文件夹，生成或者合并缓存文件。
2. 工具软件启动插件并搜索项目关键字，读取缓存缓存，匹配项目，若无匹配项目则重新执行步骤 1 并匹配项目。
3. 将匹配到的项目列表排序并通过工具软件提供的 GUI 返回给用户选择。
4. 用户选择后根据触发命令不同，调用不同软件打开项目文件夹的真实路径。
5. 每次打开项目后该项目在缓存中的点击量自增 1，点击量会影响排序。

从上面这个流程可以看出，开发适配不同工具软件的插件，很大一部分逻辑其实是共用的，如果为每个平台插件全部写一遍，这件事对一个提效插件来说是一件非常不提效的事情。当核心逻辑优化的时候，三个平台的插件都得做相应的修改。

核心模块

上面有提到，猎豹已经支持了 Alfred 和 uTools 两个平台，已经迭代优化了多个版本，经历了这几次折磨以后，笔者痛定思痛，决定将不涉及平台特性，输入输出API的内容都抽离出来，开发一个核心模块，开发各平台插件时引用核心模块即可。

这里有个注意的点，uTools 和 Raycast 是支持 Node.js API 的，Alfred 自身不带脚本运行环境，需要用户系统安装了 Node.js 才行，如果插件是面向前端开发者还行，面向普通用户的话，如此繁复的操作会劝退很多人。

txiki.js

如何解决上面这个问题呢，在另一个 Alfred 插件中我发现了一个叫 txiki.js 的 JavaScript 运行时，基于 Quick.js，外加 libuv 提供系统 API 支持，可以看做一个简化版的 Node.js 可以实现系统文件操作，网络请求等功能，可执行文件大小仅3M左右，Alfred Workflows 导出时可以一起打包，这样用户在使用时就不用下载运行时了。

抹平差异

解决了运行时问题，还要解决的问题就是 txiki.js 和 Node.js 在系统文件操作上的差异了，需要针对读取文件、读取文件夹内容、写入文件等API封装方法，判断当前运行环境运行不同的 API。

运行环境可以根据 global 对象上是否包含 tjs 属性来判断是否为 txiki.js。

const isTxiki = !!global.tjs

只要抹平了差异，在适配各平台的时候，只要针对平台特性做好输入输出部分，再调用核心模块提供的方法即可完成是适配，简单快捷，后续更新迭代也不用头秃。

结语

通过上面的介绍，相信大家也了解了跨平台插件开发需要注意的地方，其实还有很多类似的工具软件，比如与 uTools 非常相似的 rubick，windows 平台下的 quicker、wox等等，只要目标平台能够支持 Node.js 运行环境或者可以导入打包有 txiki.js 的插件，都可以快速适配开发。 一个工具做得再好，有人使用才有价值，尽可能覆盖更多平台，能让工具与用户的距离更近，不论是从提升自身影响力还是变现角度来说，流量、使用量才是王道。

后续会详细讲解核心模块的思路以及各平台适配的细节，带大家了解更多工具软件插件开发，如果这篇文章对您有一些启发，麻烦给个赞鼓励一下~