Chrome 扩展 Pomodoro 开发小结

最近做了个Chrome 扩展 Pomodoro，也就是传说中的番茄计数。这东西市面上不少，chrome store里面一堆，不过试用了一圈都不是很爽，应该说我这个人比较膈应，总是有些怪异的想法，例如：

• 怎么也得提供两种计数模式吧，我喜欢工作时间使用25分钟来分隔，晚上喜欢长一点，例如45分钟的
• 如果能像 gtalk 那个扩展那样，在右下角出现多好，而且还可以在所有非chrome窗口之上出现，在浏览器图标上点击出现个popup实在是不利索啊
• 当然，既可以在右下角出现，又可以切换到弹出窗口状态就更好了
• 在计时状态下，窗口关闭了也不影响计时
• ……

嗯哼，这么一限定，剩下的就只能是自己搞了。想自己搞还有一个原因就是：屁大个小东西，能有多麻烦，一两天还不搞定……

这瞧不起人家 chrome 的下场很明显，其它的不说，从主体功能完成——就是下面的小窗口加上配置页面，那个计时器也能跑起来了——到方方面面小bug都找全了，已经是22号到26号了，虽然不是全时间投入，但起码每天也会花上个1-4小时不等的。

下面说说 chrome 扩展开发可能会遇到的一些问题吧。

看上去很美的事件页面

这个事件页面看上去很美，是对之前的background页面的优化。后者是会一直运行着的，无论那个扩展你当时用没用，它会紧密陪伴着chrome，chrome不关它的内存不释放。

使用也很简单，只需要在 manifest.json 的background 部分加个 “persistent”: false 就ok了（当然，设置成 true 的话就是传统的后台模式了）。

但是！！！

这个杀进程的机制往往让你不知所措，明明扩展还在后台运行，丫就给你干掉了，这个在开发的时候往往还观察不到，因为你会打开那个 dev panel。导致我把扩展提交到 store之后有用户报bug，说窗口关闭之后计时就失效了。

这个进程卸载机制开发者完全无法控制——反正我没发现控制的办法，有两个监听：onSuspend和 onSuspendCanceled，但是没有提供个机制让你手工控制一下，例如提供个方法来cancel这个 suspend。

为了解决这个问题，一开始的思路是把所有相关数据存到 storage 中去，然后用 alarm 每分钟触发一次，通过读取这些数据来重新初始化对象。结果碰壁，因为这个 alarm 太残废（这个后面专门吐槽）。

最后还是只能依靠传统解决办法：把 “persistent” 设置为 true，然后用 setTimeout 来定时。

于是本来挺好的玩意——可以帮助用户节省内存——却无法适应所有场景。

残废的 Alarm

chrome 官方文档推荐用来做周期性事件触发的是 chrome.alarms，一开始也是用的这东西来做的后台计时，在开发环境下一切正常，触发的时间也很准确，打包扔到 store 再下载下来用发现不对了，丫的这个触发时间极度不可捉摸，每次都得延迟2、30s，再仔细看文档，感情人家已经明确提到了：由于性能原因，定时器可能会延迟至该时间后的任意时间。

如果一个计时器不能按时触发那么还有什么意义？当然也有，如果是时间不敏感的话也还是可以用用的，但是我这个扩展显然不行了。

缺乏完善的扩展页面间的消息传递机制

chrome 虽然也提供了 postMessage 的api，但是这个只能跟 content script 之间互相传递消息，而无法给扩展内的一般页面传递，例如我这个扩展的主窗口是个独立的页面，于是就无能为力了。

这时候最好的方式还是用 storage 来作为消息中转站吧。

结论

我几年前曾经做了个用来发推的小扩展，当时就是恨的咬牙切齿，所以只草草搞了下就算了，没想到几年下来，这个局面依然没有太大改变，虽然 api 增加不少，可惜很多细节仍然很糙。也可以说是 chrome 的扩展机制就不够完善，尤其是与 Firefox 相比。

我一直认为扩展不应该在页面中插入太多内容，但是chrome的 content 处理模式显然是要在客户浏览的页面中插入Javascript和dom节点来解决。导致有时候甚至会破坏用户浏览的页面，但是这时候用户骂的显然不是哪个扩展，而是网站啊。

写到这想到一句话：带着镣铐跳舞！