PicGo的star数破1000的心路历程

原文首发在个人博客，欢迎关注~

大概半年前（2017年11月28日）我在GitHub上开源了一个基于electron-vue的开源桌面应用PicGo。其出发点是为了改善我在写博客的时候贴图困难的问题。在通过了半年的持续维护和一些宣传（《PicGo：基于 Electron 的图片上传工具》、《图床上传工具PicGo v1.5更新：支持腾讯云COSv5版本、支持GitHub图床、支持上传前重命名文件等等》等等）后，6月12日，它的star数也终于突破了1000的关卡。在这过程当中我也学习了很多东西。在和你们交流的过程当中，我才发现原来你们都有着这些需求，才发现我一开始的实现思路并不是到位等等。谨以此文记录与PicGo有关的个人心路历程。

赶巧前不久也有一个开发者chyingp的开源项目破了1000star，也有着相似的文章，祝贺！

项目诞生

我之前写博客的时候，因为一开始用的是七牛的图床，因此遇到要在markdown里贴图的时候就必须登陆七牛，而后手动上传图片，再找到按钮来复制连接，而后复制到markdown里。要在markdown里显示一张图片我得通过上述4个步骤。

我本身的笔记本用的是mac，因此我就接触到了一款叫作iPic的图床神器。在用它的时候我也知道了微博图床。iPic的功能和体验真的特别好。不过若是须要使用七牛等其余图床的时候，我就须要付费了。其实若是iPic支持windows的话，我可能就真的去付费了。（由于实验室的电脑是windows，因此我平时在实验室里得用windows来写东西）。仅为mac一个平台付费我有点不能接受。

因而我就在想可否我本身写一个工具来简化个人上传图片的流程呢，这个应用能够实现拖拽图片就上传，而后上传完自动复制连接到剪贴板里，我就只要粘贴到markdown里就行了。一开始想用swift写mac的应用，用C#写windows的应用。后来发现工做量不只大，并且学习成本也很高。因而最后仍是选择投入electron的怀抱。

一开始不选择electron主要是由于个人印象中electron的应用体积都挺大的（100MB以上），因此感受体积可能有点不友好。不事后来我在用了electron-vue打包出来后发现体积是能够接受的范围（mac端大概50M，windows端大概38M），因而就决定用它来写了。用electron-vue的主要缘由是我写vue比较多，想要学习成本低一些，这样开发只要学electron的部分就行了。

说干就干，在去年年末（11月下旬）我开始写这个应用。

项目发布

文末会给出electron-vue开发的系列经验教程

通过20多天的间断性地开发，我在12月12号发布了1.0.0版本。因为一开始是在mac上开发的，因此1.0.0版本也只支持了macOS。一开始支持的图床也很少，只支持了微博和七牛两个图床。

1.0.0版本的截图以下：

基本实现了我预期的功能，相似iPic可以经过拖拽到顶部栏图标上传。而且为了从此支持windows平台（windows平台的任务栏图标不支持拖拽事件），我就作了一个主窗口，在主窗口里也有拖拽上传的区域。由于有了主窗口，我就顺便把图床的配置也放到了主窗口里。

应用作出来了，我也想让更多的人用到。因而我在北邮人论坛、cnode、v2ex还有掘金都发了文章。不过一开始看到的人寥寥无几，发了文章也没多少人看到和使用。后来我在少数派上发了一样的文章，意外地被推荐到了首页。

此次的契机让PicGo意外地有了些用户和star数。在跟使用者交流的过程当中我也开始逐步往PicGo里加功能和修复bug。在1月10日的时候，PicGo更新v1.3.1版本支持了windows系统。

由于开始有用户了，PicGo早期确实存在着很多功能的缺失，好比快捷键上传，其余经常使用图床的缺失等等。因此那时候是PicGo迭代最快的一段时间。经过你们在issue里的反馈，我也在不断打磨PicGo。能够看到截止6月14日，已经有61个被关闭的issue了。

项目改进

用户体验这个东西真的并非开发者在开发的时候可以立马就想到的。这点在开发PicGo上我体会很深。

好比增长快捷键上传这个功能，我一开始以为自定义快捷键写起来比较麻烦，干脆我定一个你们基本用不到的快捷键吧。因而我默认给了一个【command/ctrl+shift+p】的快捷键。我本身用的时候没有什么问题。结果有人给我反馈说，快捷键跟某某某软件冲突了，可否给一个快捷键自定义的功能。这是我没法回避的一个问题。因而我就开始去学习如何加入自定义快捷键。并在不久以后实现了个这个功能。

好比自定义连接格式的问题。我一开始给了你们4种复制连接的格式，分别是markdown、HTML、URL、UBB。原本觉得这4种格式就足够你们平时使用了。后来有人提了一个issue，问PicGo可否自定义连接格式，由于他想基于HTML增长一些属性，好比大小居中等。我以为这个使用场景确实是有的，因而我便在后来的某个提交里实现了这个功能。

固然并非你们有这个需求我就必定要作。还有一些需求我以为并不符合我对于PicGo的定位的，那么我就会给予回绝。好比后期可否支持上传视频文件？，因为PicGo的开发初衷只针对图片，因此在流程上（图片->base64）就不容许上传视频文件。因而我拒绝了这个需求。

还有一个对我以及PicGo这个项目影响深远的issue，ZetaoYang提出了一个想法：

这个建议改变了我对PicGo开发的后续想法。我思考了很久，发现确实一步步增长默认的图床支持是不长远的。一个是重复性劳动太多（图床上传除了协议和加密方式不一样以外，接收文件，转成base64和最后上传成功后存到本地的流程是同样的），一个是无止尽的图床支持其实也不该该。相比之下，把PicGo作成一个Core+Plugin模式的应用会更好。其中Core的部分能够单独只作图片接收和转码，并预留一些生命周期，供上传过程当中不一样的需求来调用。Core的部分能够单独发布成一个npm包。Plugin能够实现接入Core的生命周期，能够实现本身的上传逻辑，能够实现图片压缩、加水印等等其余功能。而PicGo只是在Core+Plugin的基础上套了一层electron的皮方便普通用户使用，而Core和Plugin能够独立拆出方便开发者使用和开发。这个也是PicGo的2.0版本将要作的事。

总结

在开发PicGo的过程当中我也深入了解到，写一个DEMO不难，给这个DEMO注入你本身的思想和灵魂是难的。PicGo从一个一开始只是我想简化上传图片流程的玩具应用，发展到如今，总下载量突破7000次，已是很多用户的效率工具而言，其实一路走来也并不容易。如今你们对用户体验的要求愈来愈高，若是只沉醉在本身的DEMO里没法自拔，只会被更好的产品所淘汰。

开发PicGo也是一件很开心的事。你们给予个人赞扬和感谢，都是给我继续开发的动力。而我也发现愈来愈多的文章里，都提到了PicGo。以下：

• 《老司机的神兵利器-效率工具》
• 《PicGo 强大的免费图床工具》
• 《PicGo：开源的图片管理工具》
• 《图床神器PicGo》
• 《提高生活品质——我的效率工具与资讯网站推荐》
• 《7 款 Windows 国产软件推荐》

我想，获得大家的承认，把它写进大家的文章，这是对我最大的确定，这个比star数更令我感到开心。

我在开发PicGo的过程当中，也写了一个系列文章Electron-vue开发实战。若是你也想学习electron或者electron-vue的开发的话，但愿个人文章可以给你带来帮助。若是你以前没有据说过PicGo，那么不妨试试；若是你以为它挺好用的，不妨点个star~