2016 年 7 月 4 日,图床神器 iPic 上架 Mac App Store,虽说这是个好记的日子:美国独立日,但其实我还是忘记了。是前几天一条银行扣款短信提醒了我,刚开始我还觉得奇怪:我最近没在 MAS 上买软件呀?后来一查才知道:这里 iPic 高级版第二年的扣款短信。

Git 历史显示,iPic 项目始建于 2016 年 5 月 19 日。事实上,因为已经过了这么长时间,我也记不起 iPic 一路走来的点点滴滴,很难像 Klib 那样有系统性的总结。这里主要回忆一些关键的点,或者我觉得有意思的,拿出来与大伙一说。

文章很长,我也并不知道你大概需要几分钟读完;不喜欢读长文的,现在就可以关闭了,去找些你更感兴趣的吧。

------------- 长文开始警戒线 ----------------

iPic 带给我的骄傲

我最骄傲的,是 iPic 开创了 macOS 图床工具这一品类。在 iPic 之前,你在 macOS 中是找不到类似工具的,而在 iPic 之后,接连有多款 App 出现,甚至包括 Windows 版。曾经,你在 Mac App Store 搜索「iPic」,会有多款类似产品。使用「iPic」作为搜索关键字,也算是他们向我致敬的一种方式吧。不过,现在没有了,因为我向苹果举报、苹果向他们发律师邮件,他们已经去掉这一关键字了。

如果你在 macOS 平台找到比 iPic 更好的图床工具,告诉我。

Swift 带来的尴尬

Swift 是 2014 年中发布的,iPic 是 2016 年初启动的。虽说已过 1 年多,但对于一门编程语言而言,还是太短了。主要的问题是:不成熟,导致厂商对 Swift 的支持非常有限。比如,iPic 需要集成各家图床所提供的接口。对于一些较成熟的语言,比如 JavaScript、Python 等等,厂商可以直接提供了 SDK,只需要调用简单的接口,就可以实现图片上传这样的操作。

null

而对于 Swift 这么年轻的语言,肯定是没有 SDK 的,这就需要我 一个个去集成各个服务商的 REST API,这一过程相当繁琐。其中,大量的时间花在 OAuth 的实现上。不过,好在 OAuth 是相对标准的东西,各家的实现也大体相当,多支持几个图床,能重用的代码也多了。

另外,做这种相对 SDK 来说偏底层的东西,也是有好处的。比如,可以多一些对 OAuth 的理解;在设计 Klib 后端接口时,也能多参考这种工业级的 REST API 设计规范;等等。

其实,在这个过程中也会有很多有意思的发现,比如,阿里云的 OSS 接口基本是复刻 Amazon S3,连参数名都一样。Amazon S3 果然是企业级的,权限系统什么的很复杂,一般人很难搞定,而后来的阿里云则对中小用户更友好些。当然,只是模仿接口也未可厚非,但总会让人看轻一些:不要把 S3 中一些不好的设计也抄了去才好 😂

期间,也经历了 Swift 2.2 > 3.0 的升级,感觉比较多的变更都是语法层面,甚至可以说是变量名方面。个人感觉,我愿意给 Swift 版本升级多一些体谅:虽说确实会带来一些麻烦,但总比裹足不前要好

顺便说一句,我所有的产品都是纯 Swift 的:KlibiPiciPic MoveriPasteiTimeriHosts

我不愿增加一个额外的选项

首先吐槽一下七牛的接口。

七牛起初只有几个区域(好像是华北、华东,具体忘了),每个区域的不同的图片上传地址。后来,七牛增加了新的区域,每个区域又有新的上传地址。关键问题在于,Bucket 的名字在各个区域中不能重复的,但七牛却没有提供根据 Bucket 名字查询其所在地区的接口。这就意味着,在 iPic 的图床配置中,用户需要额外指定 Bucket 所在地区。这在我看来,是相当傻的。我相信,很多用户在创建结果后,并不记得 Bucket 所在地区,这就使得在配置图床时,遇到了额外的困难。

我实在不想增加这一设置项,所以实际上我是这么做的:用户不需要指定地区,iPic 自动尝试所有地区。如果图床的其他信息如 Key 是正确的,则可以找到正确的地区。这一方案,唯一问题是:一旦七牛又新开了区域,iPic 就得多尝试一个地区。至少,iPic 需要从服务器端获取七牛所有的区域列表,多了一点点维持工作量。不过,为了减少界面上一个设置项,这些都是值得的。

其实,不止七牛,别的图床也有类似的问题。不过,要好一些。比如,Amazon S3 如果选择错误的地区上传,返回结果中会包含正确的地区,选用即可。

这样以后,七牛、又拍、阿里云 OSS、Amazon S3 的图床配置界面一模一样,这降低了用户的使用成本,也让我很满意。

null

开放图片上传能力的 iPicUploader

iPic 一个比较重要的场景:在使用 Markdown 写文章时,插入图片。那与其单独使用 iPic 这样一个额外的 App,直接使用 Markdown 编辑器来插图,岂不更好?不过事实上,仅有少量的 Markdown 编辑器支持图床功能(如我在用的 MWeb),大部分并不支持。

正巧,Typora 作者联系上我,希望与 iPic 集成,可谓一拍即合。

于是,我好好研究了在 macOS 沙盒限制下,各个 App 间通信的方式。最后,我选择了「私有剪贴板」这种方式(这个名字是我自己取的),既可以安全地上架 Mac App Store,也不会对用户的通用剪贴板造成干扰。事实上,在我向 Bear(对,就是前段时间大红大紫的 Markdown 编辑器 Bear)介绍时,他们也夸赞这种方式。只可惜,他们没接入 iPic…

null

具体的步骤:

  • Typora 集成 iPicUploader 这个开源的 iPic 上传助手
  • Typora 等 Markdown 编辑器,当用户通过拖拽等方式上传图片时,读取图片信息,写入「私有剪贴板」,然后等待返回结果
    • 注:之所以要由 Typora 读取图片信息,是因为 iPic 处于沙盒模式中,如果客户端仅仅发送一个文件路径,iPic 是没有权限读取的
    • 另外,iPicUploader 也能检测 iPic 是否安装、当前是否在运行等情况
  • 当 iPic 运行时,会监控「私有剪贴板」中的内容。一旦发现有待上传的图片,则上传、并将图片地址写回「私有剪贴板」
  • Typora 得到上传结果,即图片的 http 地址,更新 Markdown 中的图片链接

事实上,从客户端的角度,使用过程比上述文字描述要简单的多:只要在项目中集成 iPicUploader,通过一个接口调用就可以了:

let imageFilePath = "/Path/to/the/pic.jpg"
iPic.uploadImage(imageFilePath, handler: { (imageLink, error) in    
    if let imageLink = imageLink {
        // Image uploaded        

    } else if let error = error {
        // Some error happened
    }
})

当然,做这事也不是纯粹因为对开源世界的热爱,我自然是有私心的:傍大款。比如,像 Bear 这样级别的产品如果集成 iPic,那对 iPic 自然是极好的。只可惜,大部分邀约都没有反馈,最终成产品的只有 Typora…

null

自立山头的 iPic Mover

除了配合 Markdown 编辑器,我还单独开发了 iPic Mover,核心功能是:通过 iPic 上传 Markdown 中的图片(包括本地或网络图片)至新的图床,并替换 Markdown 中的图片地址。

主要的使用场景:

  • 将博客中的图片整体搬家至新图床
  • 使用 Markdown 编辑器编辑文章后,一键上传本地图片

null

其实,这个功能确实可以作为 iPic 的一部分。这样,至少可以省去单独为 iPic Mover 这款 App 设计 Logo,运营推广等多方面的资源。不过,我还是不想因为这个小众的功能,让 iPic 主体变得复杂。毕竟,大部分 iPic 用户并不需要这个功能。如果不需要却要天天看见这个功能,我是觉得不爽的。

免登录上传图片至微博

iPic 默认上传图片至微博图床,且无需登录。为什么一定要做到无需登录呢?主要是为了实现「开箱即用」的效果。想想一个国际友人,在下载 iPic 后,还需要注册一个微博账户才能用、注册界面丑陋且多年未更新,那是怎样的画面?

其实,iPic 要实现开箱即用:即安装后就可以上传图片至微博,技术上还是有些复杂的。不过,严格来讲,把微博当图床来用,本身确实是在道德上无法站住脚的,怎么说都有滥用微博资源的嫌疑。出于这一点,我就不在文章中详细介绍了,大家也不要私信问我,我不会回答。不过,想想我经常看的,包括 App 启动广告、女性生理期用品在内的微博广告,我心里就觉得舒服一些了。

关于 iPic 付费模式

iPic 的付费模式是:

  • 默认的(微博)图床免费,所有 iPic 的功能免费
  • 自定义图床收费,图床包括:七牛云 、又拍云、阿里云 OSS 、Imgur 、Flickr 、Amazon S3 共 6 款,包含了目前主流的图床,收费模式为 ¥58 每年

null

其实,默认的微博图床还是挺好的:免费、不限流量、CDN 加速、稳定可靠、支持 https 等等,主要的局限是:

  • 不支持 png 格式
  • 会对图片进行肉眼可见的有损压缩
  • 无法删除已上传的图片
  • 无法查看或管理所有自己上传的图片
  • 毕竟是依赖第三方服务,多少有风险,比如新浪倒闭

相反,如果不能接受微博图床的上述局限,可使用灵活度更高的自定义图床。比如,我自己使用的是七牛图床。起初是因为七牛提供一定额度的免费流量,后来才发现是个坑:免费流量不支持 https,而我的 博客产品首页 已经全面支持 https,虽说我每月也就给七牛交很少的流量费,不过多少有些受骗的感觉。早知如此,我就选择阿里云 OSS 了。

这里顺便再说个七牛的一个坑:不支持 bucket 的自定义域名。也许你会说:支持的呀?但其实,只有「融合云」是支持的。但 CDN 毕竟有缓存问题,比如在做 Klib 分享时,我并不想因为速度的提升带来很大的缓存的问题(这会带来业务的问题,详见我当时的介绍),最后还是使用了支持自定义域名的阿里云 OSS. 比如,你在访问 http://s.klib.me/share.html 时,其实是访问的阿里云 OSS 里的文件。

关于订阅模式

现在,订阅依然不为人所接受。而想想 1 年前,订阅更加被抗拒;但我还是依然坚持做吃螃蟹的人。一方面,我想有所尝试;另一方面,我觉得订阅制是对开发者友好的,进而对整个生态友好的。试想,如果开发者都坚持不下去了,也就不会再有好软件诞生。Windows 的生态就是很好的例子,我时不时听到有开发者放弃、或不愿开发 Windows 下的应用,很大的一个原因是:盗版太猖獗。很多人用盗版用得理所应当,觉得 Windows 操作系统收费是变态,OK,惹不起我还躲得起,最终吃亏的还是用户自己:没有好软件可用

Apple 的订阅制有个细节可以跟大家分享下。对于订阅的首年,Apple 会抽成 30%,即你付的 58 中,我只能得到 58 * 0.7 = 40.6,17.4 被 Apple 拔毛了。而在第 2 年及以后,Apple 抽成降低至 15%,即我可以多得 8.7 元。虽不多,但蚊子腿也是肉。更多的,是 Apple 对开发者的支持,用户对我的肯定。

¥58 一年的软件贵吗?贵,尤其是在国内的软件环境里,绝对是高价。但,还是有人愿意购买。我相信,购买的人不是傻子,而是经过充分对比才做的聪明选择。¥58 一年对于使用 iPic 所节约的时间而言,可以忽略。用钱买效率,并不是所有人的习惯,只是高效人士的习惯。

很开心的,就是通过 iPic 认识了一群 高效人士。他们认可我的努力,认可我对产品的理解,认可 iPic 对他们带来的帮助,愿意用付费的方式来支持我继续,还通过微信群、邮件等方式,提出改进意见。在此,谢谢各位的支持。

关于 iPic 的未来

其实,就像我在小结 Klib 中已经提到了,对于 iPic 这种典型的工具型应用,其天花板是很明显的:一旦功能实现了,进一步的想象空间很小。这也是我很长时间都没有对 iPic 更新的主要原因,因为不知道怎么做才是对的。

比如,有用户提除了 Markdown 格式外,也支持 reST 等其它标记语言的格式。这样的需求肯定是有道理的。但问题是,相对而言更小众。如果列表里同时列出 Markdown、reST,对于只用 Markdown 的大多数用户而言,是种干扰,因为他们可能根本就不知道什么是 reST。当然,可以在配置在自定义链接格式。这也是有道理的,只是又增加了产品的理解难度。

对于这类的需求,我很难判断是否要加。不加,肯定会流失部分用户;加,又会对已有用户造成一定的困扰。想不好之前,我宁愿暂时什么都不做。

当然,这并不意味着 iPic 不会更新。就像同样许久未更新的 iPaste,本月会迎来重大更新:支持 Pin 分组及管理。同样的,随着大家对图床需求的演变,一旦我想通了某一点,自然会适时跟进的。

尾巴

这篇文章很长,希望你能有与付出时间相称的回报。不然,我不会觉得不好意思…


博客原文:0711 - 在 iPic 周岁时,说说这款让我骄傲的产品