说说 Klib 这一生，以及能否养活他爹。
Klib 这款产品，从最初的想法，到目前第四版发布，已整整半年。而这个产品也走到了分叉路口，也是回顾的好时机。Klib 到底赚了多少钱？往下看。
先前，已经写了 2 篇关于 Klib 的长文：
感兴趣可以先看这两篇文章，相关的部分这里不再重复。
2017 这半年，便是 Klib 的一生。
这应该是我启动一个项目时，最先、最经常问自己的问题，也应该是 产品存在的唯一理由。
起初，这个问题很好回答：管理用户在 Kindle 上所做的标注和笔记。
后来，随着产品的演进，引入了很多其他功能，甚至可以从 iBooks 这个跟 Kindle 没有任何关系的 App 中导入笔记，产品的定位和方向就变得不清晰了。关于这一点，在文末统一介绍。
值得骄傲的，Klib 做到了很多第一：
简单的说，如果你需要管理 Kindle 标注、恰巧有一台 Mac，Klib 是你最好的选择。
牛皮不是吹的，来说说 Klib 中一些不错的点：
1.「在 Kindle for macOS 中回顾笔记」
这是一个既酷炫、又实用的功能。
我们在回顾笔记时，有时会觉得标注的内容太简洁了、需要回看书的上下文。怎么办呢？很巧妙地，Klib 可以打开 Kindle for macOS、并跳转到标注所在位置，够贴心吧？
2. 「自动合并不同来源的笔记」
如上所述，Klib 支持从 Kindle、Kindle 客户端、Amazon 等来源导入笔记，这也引入了书籍和笔记的合并问题。并且，用户有可能在 Klib 中修改笔记，这会让合并所需处理的逻辑更复杂。
好在，Klib 结合书名、作者、笔记原文、笔记位置等信息，很好地解决了不同来源的合并问题，尽可能地避免重复。
不过，毕竟不同来源的笔记没有标准格式，导入时依然会有重复的可能。于是，Klib 还支持手动合并书籍。看似简单，这却会又一层地增加复杂度：如果在被合并书中增加新标注，如何正确导入到合并的书中？单单是这一整套的合并逻辑，我处理了将近一个星期，梳理了大量测试用例，并用单元测试，保证各逻辑的正确。
当然，这是用户无法感知、却又觉得理所当然的功能。
3. 「自动排除重复的笔记」
之前 Kindle 系统的标注逻辑是：选择文本，然后手动标注。新版系统做了调整：选择文本后自动标注。这带来的问题是：如果第一次没有选择正确、或者干脆就是误解，即使删除后重新标注，之前删除的标注依然会位于 Kindle 系统中，进而会被导入。
Klib 结合笔记的位置、内容的相似度，几乎可以排除所有重复的内容，仅保留最有价值的一条。
同样，这是用户无法感知、却又觉得理所当然的功能。
4. 「标注为章节」
章节对于笔记的管理是很有帮助的，不然就会是一堆标注罗列在一起，没有规律，也会给回顾带来压力。
如何读取到书的章节信息呢？之前辗转联系上一位前 Kindle 在线阅读的工程师，他的原话是：我们内部有接口，用起来很容易。而很可惜，Kindle 并没有开放接口。如果要彻底支持，就需要解析带数字签名的亚马逊私有电子书格式。这工作量与难度，是相当巨大的。
不能放弃呀。于是，我想出了一个方式：
虽然需要手工多做一些事情，但与其能达到的效果，是相当划算的。
5. 「阅读器及分享」
之前的 Klib 使用列表来展示所有笔记，虽然可以按下空格显示笔记的预览，但总归没有整体的感觉。
为了提升阅读体验，我在最近的 Klib 中引入了「阅读器」，名字和交互灵感来自 Safari 的「阅读器」，后者可以去除网页中的冗余元素，仅保留文本、图片等核心内容。想法很明确，而设计优雅的排版以方便中英文阅读，并不容易。并且还要考虑网页在电脑、手机等不同设备上的阅读效果，难度加倍。
经过好几版设计后，最终的样式是这样的：
可以隐藏所有干扰因素，仅剩下文字本身。纯净排版，让你沉醉于阅读；全屏体验，效果更佳。
有了优雅的排版，怎能不分享给好友呢？以书会友，共读精彩。当我偶然在一个读书群中看到用户分享使用 Klib 生成的读书笔记时，真的很开心 :)
6. 「实验室」
功能的开发，总是众口难调。而我也可能做出错误的判断，怎么办呢？
目前，Klib 引入的「实验室」功能。对于变动较大的新功能，都会在「实验室」中观察一段时间。如果大家不喜欢，新功能将会调整、甚至移除。另外，考虑暂时不用考虑收费的问题，看试验的结果，延迟决定。
麻雀虽小，五脏俱全。Klib 看似一个很小的产品，涉及到的技术还是很多的。
这部分没有太多可说的，因为我想尽量保持原生的感觉，大部分都是使用 标准控件。不过，还是遇到了坑，比如：
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 甚至更多版本的朋友。
收集日志
错误是难免的，重要的是及时改进。要改进，首先就要能知道错误。
当然，前提是用户愿意并手动发送日志。
慎用第三方库
或者说，尽量使用稳定可靠的第三方库。在 DevMate 中追踪到的仅有的几个 Crash 中，大部分是 6 年前的 Evernote SDK 引起的，我也是无奈…
Klib 最开始遇到的性能瓶颈是：当用户有上万条标注时，导入需要将近 2 分钟。其中，大部分时间用于日期识别、数据合并。经过改进后，导入仅需 10 秒左右，满意。
不过，目前还有待改进的是：当有大量数据时，界面操作会有卡顿。数据越多，卡顿越明显。确实还是有可改进的空间。一方面是减少计算量，另一方面是进一步分离界面操作与后台数据计算。
酒香也怕巷子深。这时代，大家每天要接触的信息太多了，要将自己的产品展现在用户面前，很难。也就意味着，很需要花时间、花心思去研究。我做的并不好，也并没有找到门道，这里只是大致列出我所做的事，供大家参考。
这可以说是运营的起点。因为毕竟 MAS 是 Klib 唯一的下载渠道，是脸面。并且，MAS 还是有些自然流量的。即使这个环节不加分，至少不能减分。
每次提交版本，都要处理至少以下内容：
考虑到目前 Klib 支持 简体中文、英文、德文，工作量实际是上述的 3 倍。
其中，截图部分最为麻烦。因为，不仅要处理图片，关键的，要 事先准备素材（如书、标注内容等），才能生成适当的截图。中文还好，可我并没有标注那么英文原著。即使有，也都是技术类书籍，并不适合用于 MAS 的截图。没办法，我只能找英文中流行的书，从 Amazon 官网中找其分享的标注，合成一样书的阅读笔记。这种工作是非常费时的，德语版我干脆放弃了，直接使用英文的素材。
之前，Klib 是挂在 Toolinbox 官网的：https://toolinbox.net/Klib/
后来，为了方便推广，我又挑选了 Klib.me 这个域名，并建立官网：
这个页面看似简单、却花费大量时间：
有个短的域名很重要，这样后来在分享笔记时，就可以有类似 http://s.klib.me/share.html 这种简洁的网址。
随着 Klib 功能变得复杂，详尽的使用教程变得必须。目前，中文版的教程在 13 寸 MBP 上，已经有 28 页之多。
其中，最花时间的操作 gif 图的制作。和截图一样，首先要准备好素材。另外，就是要在最小的屏幕范围内，将意图表达清楚。因为，这意味着才能控制最终生成的 gif 文件大小。
之前，我使用 QuickTime 录屏，使用 iMovie 编辑后导出来 .mov 格式，然后再转成 gif. 其中，最麻烦的是 iMovie 仅能处理 16:9 的视频，这就要在录屏时非常小心地控制好比例。
后来，我发现 可以直接在 QuickTime 进行简单的编辑，也就是去除操作中多余的环节，仅保留操作部分，并生成最终的 gif 文件。这大大加快了 gif 的制作，唯一的缺点是：不能在视频中加文字。
媒体的助力，对产品的推广，帮助很大。
国内
效果最好的就是「少数派」了，以及 V2EX、爱范儿、掘金、Mac 玩儿法等媒体，以及自己个人的媒体，如朋友圈、微博、博客、等等。
除了媒体是否愿意报道，对我而言，最困难就是如何写媒体文章。毕竟自己是程序员思维，很难用讲故事的方式，写出吸引人的文章。这方面还得再提高。
海外
其实，国外推广是个非常头痛的事。毕竟文化不同，语言也有障碍。
效果最好的主要是两处：
我曾经要求自己每天在 Twitter、Facebook 发新消息，以建立品牌和影响力；不过可惜没有坚持。找个契机，重新开始运营。
都说要口碑传播，最重要的，就是核心用户了。
起初，我是抗拒建立用户群的，因为我担心重复回答基础性的问题这种技术支持，会花太多时间。不过后来想想，还是利大于弊的，毕竟可以直接和用户接触、倾听用户的声音，是非常宝贵的。目前，用户和我直接沟通的渠道有：
另外一个没做的事：邮件订阅。尤其是国外，这个更常见。用户一旦喜欢一个团队、开发者，很可能是愿意知道其发布的新产品、新版本。很可惜，我还没有在网站建立这个。其中一个原因是，目前我的网站是基于博客的，加这一点不太方便。不过，找机会还是要加上。
软件定价是门玄学，里面的门道非常多。最近 Day One 调整收费模式，引来一片骂声。Klib 也没什么经验可介绍，只是罗列一下历史。
刚发布时 Klib Pro 是 ￥50，随着功能的改进，目前是 ￥98. 另外还有 Klib 扩展包，不过由于 Amazon 功能限制，国内用户可以无视；而且，其带来的收入，与 Klib Pro 相比，可以忽略。
如果你觉得书、软件贵，去商场逛一圈，看买 Klib Pro 的钱，都能买些什么。
到底 Klib 赚了多少钱？我想这是很多朋友都感兴趣的。不出意料，答案可能会让绝大多数朋友惊讶：Klib 这 6 个月给我带来的收入，差不多等于我过去一个月的薪水。作为独立开发者，要养活自己和家人，我还得坚持很久。
另外一点可以分享的，由于我的影响力主要在国内，85% 左右的收入来自国内用户。在国内盗版的环境下，大家能如此支持 Klib，真心感谢。我也相信，随着大家消费能力、和软件素质的提高，会有越来越多用户愿意花钱购买软件，期待。
面对近 300 件要做的事，Klib 该何去何从？
截止目前，我已经先后做了 6 款 mac App (Klib、iPic、iPic Mover、iPaste、iHosts、iTimer)，也都先后到了瓶颈。怎么回事呢？
总体来看，主要是 产品太过依赖功能：当功能基本完成时，就没有更多想象空间了。
如果要增加用户，很可能就要强行加功能。而这些附属的、可有可无的功能，很可能让产品本身变得难用。纠结于此。
Klib 是款好产品，但不一定是个好的商业项目。
怎么办呢？
方向一：深挖 Kindle 辅助工具这个定位
好处是：
坏处是：
方向二：做笔记中枢
笔记的来源可以不止是 Kindle，也可以是 iBooks、多看等等；除了在 Klib 中阅读，还可方便地导出至 Evernote、OneNote 等目标应用。
好处是：
坏处是：
目前还很难决择，暂定先观察一段时间；等考虑成熟了，再进一步改进。
考虑的同时，我准备挖个新坑：iTips, 碎片信息管理工具。这是我的 iPaste 的一位荷兰用户跟我提的需求，接下来的一段时间，我会跟他进行国际合作，共同打造这样一款国内、国外用户都喜欢，横跨 macOS、iOS 的新工具，敬请期待。
博客原文：0704 - Klib 到底赚了多少钱？
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。