同步助手优化建议

[binsee]

对于同步助手提出一些优化建议：

1. 确保同步助手以单例运行
2. 增加支持 URL Scheme 协议
3. 支持静默启动
4. 监听127.0.0.1而不是0.0.0.0

---

1. 单例运行

目前少量用户可能碰到同步助手启动时报错，无法获得端口号问题，部分原因是因为重复启动同步助手。见 #2129

而同步助手使用的 electron 内是有解决方案的，即通过实例锁确保程序是单例运行的。

参考文档：

• app.requestSingleInstanceLock()
• 事件: 'second-instance'

2. 支持 URL Scheme 协议

增加对 URL Scheme 协议的支持，如 simpreader://start 之类。

主要实现目的，当浏览器中扩展需要与同步助手通讯时，无法通过端口访问到同步助手时，可以通过 URL Scheme 协议来启动同步助手，用户最多只需要点击一个同意即可，然后同步助手自动启动，然后扩展与同步助手建立通讯再继续正常执行。如此便不用用户主动去找到同步助手再执行，会更加方便。

参考文档：

• app.setAsDefaultProtocolClient(protocol[, path, args])
• Electron系列文章 - deeplink打开应用 - FlyKnows

3. 支持静默启动

同步助手作为一个辅助型组件，其定位应当为一次设置，永久静默启动，而不应该是每次启动都要把主窗口显示出来。
因此，应当有静默启动的选项或功能。

如：

• 启动时默认静默启动，再次执行时（通过 second-instance 、 open-url 事件和执行参数判断）显示主窗口

4. 监听127.0.0.1而不是0.0.0.0

在win10、MacOS系统上，默认情况下，一个程序监听端口绑定到 0.0.0.0 这个ip时，系统可能会要求管理员权限，以将此端口添加到防火墙策略中。某些情况下，可能会导致监听端口失败。
当在 0.0.0.0 上监听端口，当防火墙（如果存在的话）中允许外部访问此端口时，外部设备可以直接通过本机有效ip访问到此端口。而在 127.0.0.1 上监听端口，只有当前主机可以访问。

因此，出于以下原因，建议更改监听端口绑定的ip为 127.0.0.1 而非 0.0.0.0。

• 由于权限原因，可能导致的监听端口失败。
• 安全问题，应只允许当前主机访问此端口。

需修改代码如下：

server = app.listen( config.storage.db.port, '127.0.0.1' , function() {
// ....
});

[Kenshin]

嗨，沉寂了一段时间后，终于出手了！ 哈哈，都是很棒的建议，照单全收。（部分功能的建议已经在 To-do 里面了~

---

近期会升级扩展端，所以时间有限，暂时无法实施这些功能了。

大致的 Roamap 是这样的：新版发布 → 补丁版本 → 上述更新 → 补丁版

其中，1 和 3 跟扩展端无关，可以先发布，然后是 2

[binsee]

补充一条建议：

同步助手 - 导出 中的 「导出服务详细设定」 一项，建议改下颜色。因为这是个折叠项，和上边的标签用途不同，应该用其他颜色，否则太容易忽视掉了。

[Kenshin]

同步助手 - 导出 中的 「导出服务详细设定」 一项，建议改下颜色。因为这是个折叠项，和上边的标签用途不同，应该用其他颜色，否则太容易忽视掉了。

收到，到时候让 UE 大佬帮忙看看。

[Kenshin]

嗨，你提到的建议，除了 URL Scheme 外都已经 Fixed 掉了。

更新说明

1. Telegram Channel

2. Notion