本文为稀土技术社区首发签约文章，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 有具体的中文文档以及活跃的开发者社区，最重要的是，它根据 Electron开发，做到了跨三大操作体系，插件只需注意渠道区别，即可在三大操作体系下运转。
虽然 uTools 有许多长处，可是实际体验下来，仍是有一些能够优化的当地（后续 uTools 篇会细说），不过瑕不掩瑜，uTools 未来可期。
猎豹 Cheetah
上面介绍了几个比较优异的东西软件，接下来再说说我们的主角“猎豹 Cheetah”。
这是一款检索本地 Git 项目并快速经过拟定软件翻开的插件，现在已经实现了 Alfred、uTools版别，Raycast版别还在规划中。
插件的运转原理如下：
- 在用户配置的作业区目录下递归查找并记载包含
.git目录的文件夹，生成或许兼并缓存文件。 - 东西软件启动插件并查找项目关键字，读取缓存缓存，匹配项目，若无匹配项目则从头履行过程 1 并匹配项目。
- 将匹配到的项目列表排序并经过东西软件供给的
GUI回来给用户挑选。 - 用户挑选后根据触发指令不同，调用不同软件翻开项目文件夹的真实途径。
- 每次翻开项目后该项目在缓存中的点击量自增 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 的插件，都能够快速适配开发。
一个东西做得再好，有人运用才有价值，尽可能掩盖更多渠道，能让东西与用户的距离更近，不论是从提高本身影响力仍是变现角度来说，流量、运用量才是王道。
后续会具体解说中心模块的思路以及各渠道适配的细节，带我们了解更多东西软件插件开发，假如这篇文章对您有一些启示，麻烦给个赞鼓励一下~
