本文为稀土技术社区首发签约文章，14天内制止转载，14天后未获授权制止转载，侵权必究！

导言

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

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

怎么进步功率呢？这是一个好问题，其实我们学习作业中许多机械、重复的流程、能够经过代码来替代人工操作的内容，都能够抽象成东西，这些东西我们称之为应用软件。

可是为每一个小东西开发一个完整功用的软件又有些小题大做，不光占用体系资源，并且因为不同东西软件的入口不同，反而增加了运用成本，降低了功率。

针对上面的问题，许多东西软件都规划了优异的插件体系，方便广大开发者运用规定的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 的插件，都能够快速适配开发。
一个东西做得再好，有人运用才有价值，尽可能掩盖更多渠道，能让东西与用户的距离更近，不论是从提高本身影响力仍是变现角度来说，流量、运用量才是王道。

后续会具体解说中心模块的思路以及各渠道适配的细节，带我们了解更多东西软件插件开发，假如这篇文章对您有一些启示，麻烦给个赞鼓励一下~