0704 - Klib 到底赚了多少钱？

说说 Klib 这一辈子，以及可否养活他爹。

---

Klib 这款产品，从最初的想法，到目前第四版发布，已整整半年。而这个产品也走到了分叉路口，也是回顾的好时机。Klib 到底赚了多少钱？往下看。

先前，已经写了 2 篇关于 Klib 的长文：

• 0221 - 我是如何把 Klib 带到这个世界的
• 0620 - 关于 Klib 分享，各类纠结以后，我选了以下方案

感兴趣能够先看这两篇文章，相关的部分这里再也不重复。

Klib 简要时间表

2017 这半年，即是 Klib 的所有。

版本	日期	主要功能
1.1.3	2 月 26 日	首发上架 MAS
1.5.5	4 月 4 日	从 Amazon、Kindle 客户端、多看导入
-	-	在 Kindle for macOS 中回顾
1.6.1	5 月 16 日	从 iBooks 导入
-	-	可标记章节
-	-	引入实验室
1.7.2	6 月 23 日	新增阅读器
-	-	一键分享读书笔记

在产品层面聊聊 Klib

Klib 解决了什么问题？

这应该是我启动一个项目时，最早、最常常问本身的问题，也应该是 产品存在的惟一理由。

起初，这个问题很好回答：管理用户在 Kindle 上所作的标注和笔记。

后来，随着产品的演进，引入了不少其余功能，甚至能够从 iBooks 这个跟 Kindle 没有任何关系的 App 中导入笔记，产品的定位和方向就变得不清晰了。关于这一点，在文末统一介绍。

Klib 作得怎样？

值得骄傲的，Klib 作到了不少第一：

• 首款上架 Mac App Store 的 Kindle 标注管理工具
• 首款能在 Kindle for macOS 中回顾笔记的 App
• 能从 Kindle、导出的 html、Amazon 官网中导入笔记，地表最强、没有之一
• 首款能够导入 Kindle + 多看系统中笔记的 App
• 目前自动排除 Kindle 重复标注最好的 App
• 首款能够将 Kindle 的标注一键复制为 Markdown 格式的 App
• 首款能够优雅管理 iBooks 标注的 App
• …

简单的说，若是你须要管理 Kindle 标注、恰巧有一台 Mac，Klib 是你最好的选择。

Klib 的一些功能

牛皮不是吹的，来讲说 Klib 中一些不错的点：

「在 Kindle for macOS 中回顾笔记」

这是一个既酷炫、又实用的功能。

咱们在回顾笔记时，有时会以为标注的内容太简洁了、须要回看书的上下文。怎么办呢？很巧妙地，Klib 能够打开 Kindle for macOS、并跳转到标注所在位置，够贴心吧？

「自动合并不一样来源的笔记」

如上所述，Klib 支持从 Kindle、Kindle 客户端、Amazon 等来源导入笔记，这也引入了书籍和笔记的合并问题。而且，用户有可能在 Klib 中修改笔记，这会让合并所需处理的逻辑更复杂。

好在，Klib 结合书名、做者、笔记原文、笔记位置等信息，很好地解决了不一样来源的合并问题，尽量地避免重复。

不过，毕竟不一样来源的笔记没有标准格式，导入时依然会有重复的可能。因而，Klib 还支持手动合并书籍。看似简单，这却会又一层地增长复杂度：若是在被合并书中增长新标注，如何正确导入到合并的书中？单单是这一整套的合并逻辑，我处理了将近一个星期，梳理了大量测试用例，并用单元测试，保证各逻辑的正确。

固然，这是用户没法感知、却又以为理所固然的功能。

「自动排除重复的笔记」

以前 Kindle 系统的标注逻辑是：选择文本，而后手动标注。新版系统作了调整：选择文本后自动标注。这带来的问题是：若是第一次没有选择正确、或者干脆就是误解，即便删除后从新标注，以前删除的标注依然会位于 Kindle 系统中，进而会被导入。

Klib 结合笔记的位置、内容的类似度，几乎能够排除全部重复的内容，仅保留最有价值的一条。

一样，这是用户没法感知、却又以为理所固然的功能。

「标注为章节」

章节对于笔记的管理是颇有帮助的，否则就会是一堆标注罗列在一块儿，没有规律，也会给回顾带来压力。

如何读取到书的章节信息呢？以前展转联系上一位前 Kindle 在线阅读的工程师，他的原话是：咱们内部有接口，用起来很容易。而很惋惜，Kindle 并无开放接口。若是要完全支持，就须要解析带数字签名的亚马逊私有电子书格式。这工做量与难度，是至关巨大的。

不能放弃呀。因而，我想出了一个方式：

• 阅读时在章节文字上添加标注
• 导入 Klib 后，选择所有章节对应的标注，将其「标记为章节」
• 在 Klib 中复制为 Markdown 时，自动为章节添加二级标题
• 在 Klib 的阅读器中回顾时，章节会让排版更优雅

虽然须要手工多作一些事情，但与其能达到的效果，是至关划算的。

「阅读器及分享」

以前的 Klib 使用列表来展现全部笔记，虽然能够按下空格显示笔记的预览，但总归没有总体的感受。

为了提高阅读体验，我在最近的 Klib 中引入了「阅读器」，名字和交互灵感来自 Safari 的「阅读器」，后者能够去除网页中的冗余元素，仅保留文本、图片等核心内容。想法很明确，而设计优雅的排版以方便中英文阅读，并不容易。而且还要考虑网页在电脑、手机等不一样设备上的阅读效果，难度加倍。

通过好几版设计后，最终的样式是这样的：

能够隐藏全部干扰因素，仅剩下文字自己。纯净排版，让你沉醉于阅读；全屏体验，效果更佳。

有了优雅的排版，怎能不分享给好友呢？以书会友，共读精彩。当我偶然在一个读书群中看到用户分享使用 Klib 生成的读书笔记时，真的很开心 :)

「实验室」

功能的开发，老是众口难调。而我也可能作出错误的判断，怎么办呢？

目前，Klib 引入的「实验室」功能。对于变更较大的新功能，都会在「实验室」中观察一段时间。若是你们不喜欢，新功能将会调整、甚至移除。另外，考虑暂时不用考虑收费的问题，看试验的结果，延迟决定。

Klib 之于技术

麻雀虽小，五脏俱全。Klib 看似一个很小的产品，涉及到的技术仍是不少的。

功能	技术
从 Kindle 导入	多语言文本识别、日期识别
从 Kindle 客户端导入	html 内容解析
从 Amazon 导入	html 内容解析
从 iBooks 导入	iBooks 数据结构逆向解析
导出至 Evernote	Evernote 6 年前的 SDK
阅读器	使用 Markdown 生成 html，CSS 布局，SNS 分享
笔记分享	Python + Flask + Nginx + 阿里云 OSS + 服务器

界面开发

这部分没有太多可说的，由于我想尽可能保持原生的感受，大部分都是使用 标准控件。不过，仍是遇到了坑，好比：

• NSOutlineView会出现诸如 UI 刷新不及时、图标丢失等现象。
• MKWebView 在 macOS 10.11 时有闪退，10.12 则正常

另外，要把标准控件用好，并不件容易。一个缘由是，Apple 的技术文档，和 MSDN 不在一个世纪。

软件质量

质量是软件的生命。对于我来说，最大的问题是：时间有限。若是 在尽可能少的时间内，覆盖尽可能多的场景，减小 Bug，是一个挑战。

单元测试

在开发功能时，当即完善单元测试。既能够保证开发时避免遗漏，又能够一劳永逸地使用单元测试保证后续开发不会影响以前的功能，很是推荐。

截止目前，Klib 共有 133 条单元测试：

不过，在项目复杂后，Xcode 的单元测试变得很慢。尤为是 App 签名时，程序修改后，单元测试首次运行会失败，必须第 2 次运行才能够，非常闹心。

测试用例

人老是会遗忘的。在刚开发功能时，测试时能很好地覆盖功能的各个细节，时间长就忘了。最好的办法是，开发功能时，即写充分的测试用例。出现用户报的 Bug，一般意味着这个环节是薄弱的。修复后，我都会 新添加一条测试用例，以保证后续的版本不会出相似的问题。

截止目前，Klib 共有 682 条测试用例：

也就是说，每发一个版本，我都要测试 682 个场景，若是考虑到操做系统版本（macOS 10.11, 10.12），理论上测试工做量还要翻倍。各位自行脑补一下，每发一个版本，我在电脑前久坐测试的场景…尤为是提需求但愿支持 10.10 甚至更多版本的朋友。

收集日志

错误是不免的，重要的是及时改进。要改进，首先就要能知道错误。

• Klib 自己会在错误时输出日志、记录在本地
• 集成 DevMate 后，能够很方便地收集闪退日志

固然，前提是用户愿意并手动发送日志。

慎用第三方库

或者说，尽可能使用稳定可靠的第三方库。在 DevMate 中追踪到的仅有的几个 Crash 中，大部分是 6 年前的 Evernote SDK 引发的，我也是无奈…

软件性能

Klib 最开始遇到的性能瓶颈是：当用户有上万条标注时，导入须要将近 2 分钟。其中，大部分时间用于日期识别、数据合并。通过改进后，导入仅需 10 秒左右，满意。

不过，目前还有待改进的是：当有大量数据时，界面操做会有卡顿。数据越多，卡顿越明显。确实仍是有可改进的空间。一方面是减小计算量，另外一方面是进一步分离界面操做与后台数据计算。

Klib 运营 & 推广

酒香也怕巷子深。这时代，你们天天要接触的信息太多了，要将本身的产品展示在用户面前，很难。也就意味着，很须要花时间、花心思去研究。我作的并很差，也并无找到门道，这里只是大体列出我所作的事，供你们参考。

在 MAS 提交版本

这能够说是运营的起点。由于毕竟 MAS 是 Klib 惟一的下载渠道，是脸面。而且，MAS 仍是有些天然流量的。即便这个环节不加分，至少不能减分。

每次提交版本，都要处理至少如下内容：

• 应用名称
• 描述
• What's New
• 关键字
• 截图

考虑到目前 Klib 支持 简体中文、英文、德文，工做量实际是上述的 3 倍。

其中，截图部分最为麻烦。由于，不只要处理图片，关键的，要 事先准备素材（如书、标注内容等），才能生成适当的截图。中文还好，可我并无标注那么英文原著。即便有，也都是技术类书籍，并不适合用于 MAS 的截图。没办法，我只能找英文中流行的书，从 Amazon 官网中找其分享的标注，合成同样书的阅读笔记。这种工做是很是费时的，德语版我干脆放弃了，直接使用英文的素材。

域名与官网

以前，Klib 是挂在 Toolinbox 官网的：toolinbox.net/Klib/

后来，为了方便推广，我又挑选了 Klib.me 这个域名，并创建官网：

这个页面看似简单、却花费大量时间：

• 编写内容，制做图片
  • 中文、英文
• 页面排版
  • 适配不一样设备
  • 微信分享时显示图标
• 全球访问加速
  • 期间，为了使用国内的 CDN 等资源，还不得不关站图案，哎…
• SEO 优化

有个短的域名很重要，这样后来在分享笔记时，就能够有相似 s.klib.me/share.html 这种简洁的网址。

使用教程

随着 Klib 功能变得复杂，详尽的使用教程变得必须。目前，中文版的教程在 13 寸 MBP 上，已经有 28 页之多。

其中，最花时间的操做 gif 图的制做。和截图同样，首先要准备好素材。另外，就是要在最小的屏幕范围内，将意图表达清楚。由于，这意味着才能控制最终生成的 gif 文件大小。

以前，我使用 QuickTime 录屏，使用 iMovie 编辑后导出来 .mov 格式，而后再转成 gif. 其中，最麻烦的是 iMovie 仅能处理 16:9 的视频，这就要在录屏时很是当心地控制比如例。

后来，我发现 能够直接在 QuickTime 进行简单的编辑，也就是去除操做中多余的环节，仅保留操做部分，并生成最终的 gif 文件。这大大加快了 gif 的制做，惟一的缺点是：不能在视频中加文字。

媒体运营

媒体的助力，对产品的推广，帮助很大。

国内

效果最好的就是「少数派」了，以及 V2EX、爱范儿、掘金、Mac 玩儿法等媒体，以及本身我的的媒体，如朋友圈、微博、博客、等等。

除了媒体是否愿意报道，对我而言，最困难就是如何写媒体文章。毕竟本身是程序员思惟，很难用讲故事的方式，写出吸引人的文章。这方面还得再提升。

海外

其实，国外推广是个很是头痛的事。毕竟文化不一样，语言也有障碍。

效果最好的主要是两处：

• Product Hunt
  • 多人讨论，300+ 个赞

• Twitter 上用户自发推广
  • 30+ 次转发，160+ 个喜欢

我曾经要求本身天天在 Twitter、Facebook 发新消息，以创建品牌和影响力；不过惋惜没有坚持。找个契机，从新开始运营。

用户运营

都说要口碑传播，最重要的，就是核心用户了。

起初，我是抗拒创建用户群的，由于我担忧重复回答基础性的问题这种技术支持，会花太多时间。不事后来想一想，仍是利大于弊的，毕竟能够直接和用户接触、倾听用户的声音，是很是宝贵的。目前，用户和我直接沟通的渠道有：

• 微信群
• Telegram 群
• 邮件反馈
  • 基本 3 小时内回复

另一个没作的事：邮件订阅。尤为是国外，这个更常见。用户一旦喜欢一个团队、开发者，极可能是愿意知道其发布的新产品、新版本。很惋惜，我尚未在网站创建这个。其中一个缘由是，目前个人网站是基于博客的，加这一点不太方便。不过，找机会仍是要加上。

软件订价与收入

软件订价是门玄学，里面的门道很是多。最近 Day One 调整收费模式，引来一片骂声。Klib 也没什么经验可介绍，只是罗列一下历史。

刚发布时 Klib Pro 是 ￥50，随着功能的改进，目前是 ￥98. 另外还有 Klib 扩展包，不过因为 Amazon 功能限制，国内用户能够无视；并且，其带来的收入，与 Klib Pro 相比，能够忽略。

若是你以为书、软件贵，去商场逛一圈，看买 Klib Pro 的钱，都能买些什么。

到底 Klib 赚了多少钱？我想这是不少朋友都感兴趣的。不出意料，答案可能会让绝大多数朋友惊讶：Klib 这 6 个月给我带来的收入，差很少等于我过去一个月的薪水。做为独立开发者，要养活本身和家人，我还得坚持好久。

另一点能够分享的，因为个人影响力主要在国内，85% 左右的收入来自国内用户。在国内盗版的环境下，你们能如此支持 Klib，真心感谢。我也相信，随意你们消费能力、和软件素质的提升，会有愈来愈多用户愿意花钱购买软件，期待。

Klib 将来会怎样？

面对近 300 件要作的事，Klib 该何去何从？

引伸：功能性产品的思考

截止目前，我已经前后作了 6 款 mac App (Klib、iPic、iPic Mover、iPaste、iHosts、iTimer)，也都前后到了瓶颈。怎么回事呢？

整体来看，主要是 产品太过依赖功能：当功能基本完成时，就没有更多想象空间了。

若是要增长用户，极可能就要强行加功能。而这些附属的、无关紧要的功能，极可能让产品自己变得难用。纠结于此。

再来看看 Klib

Klib 是款好产品，但不必定是个好的商业项目。

• 使用频次过低
  • 好比，若是读一本书须要一个月，读完后才须要使用 Klib 导入标注和笔记，那 Klib 的打开次数基本就是 1 次/月，这实在是过低了。
• 用户体量过小
  • 恰巧使用 Kindle 阅读
  • 恰巧想要管理标注
  • 恰巧有 Mac 电脑
  • 恰巧愿意付费
  • …
  • 这样的几率，至关于 0.1 0.1 0.1 0.1 = 0.0001，可真是 *万里挑一

怎么办呢？

方向一：深挖 Kindle 辅助工具这个定位

好处是：

• 可让 Kindle 用户得到更好的体验

坏处是：

• Kindle 的用户群体仍是过小
• 更关键的，Kindle/Amazon 并非一个合适的合做伙伴，不开放数据接口，不少体验很难作好

方向二：作笔记中枢

笔记的来源能够不止是 Kindle，也能够是 iBooks、多看等等；除了在 Klib 中阅读，还可方便地导出至 Evernote、OneNote 等目标应用。

好处是：

• 能够得到更多潜在的用户
• 能够增长产品的使用频次

坏处是：

• 技术上很是依赖于第三方应用的开放程度、稳定性
  • 目测像微信阅读这样的应用，不见得深度开放数据，进而很难在其基础上有所发挥
  • 并且，一旦将来比如今更封闭，届时已经实现的功能就会失效（参见微博接口的愈来愈封装），这对于产品而言是很大的风险

目前还很难决择，暂定先观察一段时间；等考虑成熟了，再进一步改进。

---

考虑的同时，我准备挖个新坑：iTips, 碎片信息管理工具。这是个人 iPaste 的一位荷兰用户跟我提的需求，接下来的一段时间，我会跟他进行国际合做，共同打造这样一款国内、国外用户都喜欢，横跨 macOS、iOS 的新工具，敬请期待。

---

博客原文：0704 - Klib 到底赚了多少钱？