基於 Electron 的 Rubick 2.4k star 啦,同步更新新功能!

  • 2021 年 12 月 30 日
  • 筆記

為什麼要做 Rubick

其實做 Rubick 1.x 的初衷就是解決自己的問題的:特別需要一款支持自定義插件的桌面端應用來簡化使用者安裝龐大桌面端應用的臃腫。而且涉及到數據安全的問題,插件只能在公司內網貢獻,無法對外公開。

Rubick 2.0 的階段,重新設計了一套基於 npm 的插件管理體系,讓開發者更加便利的加入插件的開發。拓展了插件的邊界和種類,開發者可以開發 Rubick 系統插件,此時的 Rubick 就成了一個 electron 高級封裝,開發者可以高自由的實現系統能力而不局限余 openAPI 也不局限於必須搜索呼起使用,只要 Rubick 在運行,插件就在運行。

Rubick 的自我介紹

Rubick 是基於 electron 的開源工具箱,基於 npm 插件管理的方式自由集成豐富插件。Rubick(拉比克) 出處是 dota 裏面的英雄之一,其核心技能是插件化使用其他英雄的技能,用完即走。非常符合本工具的設計理念,所以取名 Rubick

核心技能展示

1. 基於 npm 的方式管理插件

剛開始設計插件管理的方式是將插件打包成 .zip 的壓縮包,然後再將壓縮包上傳到 CDN 上,點擊安裝再 download 下來進行解壓。但是這樣有幾個弊端

  1. 需要一個數據存儲服務器,來存儲這些壓縮包文件,那麼這需要一筆費用,這對於一個開源開發者來說很難維持下去。
  2. 打包機制和解壓機制繁瑣,對開發者不友好

直到我看到 PicGo 作者關於 PicGo 插件設計思路的文章,我突然覺得基於 npm 的包管理方式不正是我想要的嗎,既輕量有省了一筆服務器存儲開銷: PicGo 插件設計 但這其實也有另一個問題,因為是基於 npm 的管理模式,所以需要開發者提前安裝 node 環境,才可以使用 npm。但這在目前是可以接受的,因為 Rubick 的目前定位也是為開發者服務的開源工具箱。

當你點安裝插件的時候,其實執行的就是 npm install xxx.

QQ20211222-153720.gif

2. 系統插件能力

Rubick 另一個最大的能力就是支持系統插件,有了系統插件,我們就可以不用受限於必須搜索使用插件了,只要 rubick 在運行,插件就在運行。這對於一些特殊的場景來說是非常有價值的事情,比如我要實現一個定時提醒喝水的插件,如果我退出了插件界面,可能就無法實現。但是要做成了系統插件,即使退出了插件,但rubick依舊會在後台運行插件提供的hooks。這個靈感也是來自於 PicGo 的插件生命周期設計。下面來演示系統插件:

QQ20211224-164014.gif

有了系統插件,我們就可以實現 屏幕取色插件定時提醒插件超級面板插件… 另外,由於 rubick 的系統插件是運行在 main 進程的,所以,我們可以通過系統插件做到更多的能力,比如把 rubick 就看出是 electron 的二次封裝,不需要任何 electron 的構建打包,基於系統插件,我們可以實現另一個桌面端應用!

最後

做開源最大的動力是因為熱愛,完全是非盈利的,希望做的東西能給需要的小夥伴提供一些幫助和方向,程序員都是最單純可愛的,希望不要惡意攻擊打破程開源動力最後一份熱衷。

另附:

rubick github 倉庫

rubick 使用文檔