4.7 KiB
navbar
| navbar |
|---|
| false |
Q&A
为什么偶尔CPU占用特别高? 为什么预览图片时插件卡顿?
这是由超级剪贴板监听剪贴板内容更新的机制决定的，为了不漏数据，超级剪贴板的监听策略为每300ms读取一次剪贴板内容并与上一次读取到的内容作比较。如果剪贴板当前位置是一张大图片，那么插件会反复读取这张图片，导致大量计算被用在了无意义的读取与对比上。
插件市场中相同原理的同类插件的处理方法是：
- 轮询比较两次剪贴板内容，如果检查到当前剪贴板内容数据量较大，则降低轮询时间间隔。
- 这避免了读取大图片/长文本时的高占用，然而这很容易导致漏数据
- 轮询比较两次剪贴板内容，由用户自定义轮询时间
- 用户设置的轮询间隔时间长，读取大图片/长文本时不会导致高占用，但很容易漏数据。
- 用户设置的轮询间隔时间较短，则又会造成高占用
在v1.4.0版本更新中，超级剪贴板换用了clipboard-event库监听剪贴板更新事件，这种方式性能更优，不需要反复读取剪贴板内容来做比较，而只需要在检查到剪贴板更新事件时通知插件读取一次剪贴板即可，完全解决了CPU占用高、浏览图片卡顿的问题。
然而该库包含了二进制文件，这触发了uTools插件市场的安全限制而无法上架。所以自v1.4.2起，插件不再内置监听剪贴板更新事件的二进制文件，用户要使用低占用、高性能的剪贴板监听方案，可以自行下载并将其移动到剪贴板数据库文件所在目录，详见如何手动安装clipboard-event-handler，插件会自动判断使用新的抑或是旧的方案监听剪贴板更新。同时，自v1.4.3起，你可以在设置页查看当前剪贴板监听程序的运行状态。
为什么官方的剪贴板插件没有CPU占用高这个问题?
官方的剪贴板内容更新事件监听函数也是从一个二进制文件引出的，这个二进制文件跟随主程序启动，不受剪贴板插件的打开或关闭的影响。
启动报错, 读取剪切板出错
请尝试以下方法：
- 清空本地数据库文件
- 格式化uTools内的插件数据
- 完全退出插件后重启插件
如果上述方法都无法解决你的问题，欢迎论坛回帖或加入QQ群交流具体情况
为什么剪贴板记录会丢失?
一般是由于插件退出后台运行导致的, 插件需要保持后台运行才能记录剪贴板, 请检查:
- 是否正确设置了插件
跟随主程序启动 - 是否手动清理或关闭了后台插件 (在分离模式下关闭插件 使用clear命令 在插件列表退出插件)
- 是否存在高频复制的操作 (高频复制可能会漏掉记录)
我对这个插件的安全性有担忧, 插件偷窃我的隐私怎么办?
首先, 我写这个插件不是为了获取你的隐私的, 我对你的隐私没有兴趣, 这一点你完全可以放心;
其次uTools官方在插件上架前会对代码进行审查, 如果插件有高危行为, 那也不会过审;
再其次, uTools大部分用户是程序员, 如果我真的在代码里藏了"毒", 那他们也有办法发现, 如果你真的对你的隐私十分关心, 可以选择从开源仓库下载代码自行构建
我不懂代码, 我也不会构建, 但是我担心你的插件会窃取我的隐私
我在贡献教程中详细说明了如何构建, JavaScript也并不是一门很高深的语言, 祝你能早日入门, 构建出安全的版本供自己使用, 学习的过程中遇到任何问题, 也欢迎随时与我交流 :D
开源版本和插件市场版本的区别?
开源版本后续将只提供必要的BUG修复, 不再添加新功能
- 开源版本: 包含完整的基本功能, 可以自行构建开源版本, 通过安装离线插件方式使用
- 市场版本: 包含后续更新的新功能、插件会员功能, 可以直接从插件应用市场安装
为什么不开源了, 为什么要开始收费?
目前由我个人维护的开源版本已经趋于稳定, 可以满足绝大部分场景的需求
- 代码开源的出发点不是为了让不愿付费的人白嫖开发者的劳动, 而是为开发提供更多的经验和思路, 开源的代码已经启发了一些开发者上架了自己的剪贴板插件应用
- 开发和维护插件需要时间和精力, 插件付费可以鼓励我更积极的更新
- 目前插件内已有的基本功能都不会转为收费, 可以放心使用