Klib 到底賺了多少錢？

說說 Klib 這一生，以及能否養活他爹。

Klib 這款產品，從最初的想法，到目前第四版發布，已整整半年。而這個產品也走到了分叉路口，也是回顧的好時機。Klib 到底賺了多少錢？往下看。

先前，已經寫了 2 篇關於 Klib 的長文：

感興趣可以先看這兩篇文章，相關的部分這裡不再重複。

Klib 簡要時間表

2017 這半年，便是 Klib 的一生。

在產品層面聊聊 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 中一些不錯的點：

1.「在 Kindle for macOS 中回顧筆記」

這是一個既酷炫、又實用的功能。

我們在回顧筆記時，有時會覺得標註的內容太簡潔了、需要回看書的上下文。怎麼辦呢？很巧妙地，Klib 可以打開 Kindle for macOS、並跳轉到標註所在位置，夠貼心吧？

2. 「自動合併不同來源的筆記」

如上所述，Klib 支持從 Kindle、Kindle 客戶端、Amazon 等來源導入筆記，這也引入了書籍和筆記的合併問題。並且，用戶有可能在 Klib 中修改筆記，這會讓合併所需處理的邏輯更複雜。

好在，Klib 結合書名、作者、筆記原文、筆記位置等信息，很好地解決了不同來源的合併問題，儘可能地避免重複。

不過，畢竟不同來源的筆記沒有標準格式，導入時依然會有重複的可能。於是，Klib 還支持手動合併書籍。看似簡單，這卻會又一層地增加複雜度：如果在被合併書中增加新標註，如何正確導入到合併的書中？單單是這一整套的合併邏輯，我處理了將近一個星期，梳理了大量測試用例，並用單元測試，保證各邏輯的正確。

當然，這是用戶無法感知、卻又覺得理所當然的功能。

3. 「自動排除重複的筆記」

之前 Kindle 系統的標註邏輯是：選擇文本，然後手動標註。新版系統做了調整：選擇文本后自動標註。這帶來的問題是：如果第一次沒有選擇正確、或者乾脆就是誤解，即使刪除后重新標註，之前刪除的標註依然會位於 Kindle 系統中，進而會被導入。

Klib 結合筆記的位置、內容的相似度，幾乎可以排除所有重複的內容，僅保留最有價值的一條。

同樣，這是用戶無法感知、卻又覺得理所當然的功能。

4. 「標註為章節」

章節對於筆記的管理是很有幫助的，不然就會是一堆標註羅列在一起，沒有規律，也會給回顧帶來壓力。

如何讀取到書的章節信息呢？之前輾轉聯繫上一位前 Kindle 在線閱讀的工程師，他的原話是：我們內部有介面，用起來很容易。而很可惜，Kindle 並沒有開放介面。如果要徹底支持，就需要解析帶數字簽名的亞馬遜私有電子書格式。這工作量與難度，是相當巨大的。

不能放棄呀。於是，我想出了一個方式：

• 閱讀時在章節文字上添加標註
• 導入 Klib 后，選擇全部章節對應的標註，將其「標記為章節」
• 在 Klib 中複製為 Markdown 時，自動為章節添加二級標題
• 在 Klib 的閱讀器中回顧時，章節會讓排版更優雅

雖然需要手工多做一些事情，但與其能達到的效果，是相當划算的。

5. 「閱讀器及分享」

之前的 Klib 使用列表來展示所有筆記，雖然可以按下空格顯示筆記的預覽，但總歸沒有整體的感覺。

為了提升閱讀體驗，我在最近的 Klib 中引入了「閱讀器」，名字和交互靈感來自 Safari 的「閱讀器」，後者可以去除網頁中的冗餘元素，僅保留文本、圖片等核心內容。想法很明確，而設計優雅的排版以方便中英文閱讀，並不容易。並且還要考慮網頁在電腦、手機等不同設備上的閱讀效果，難度加倍。

經過好幾版設計后，最終的樣式是這樣的：

可以隱藏所有干擾因素，僅剩下文字本身。純凈排版，讓你沉醉於閱讀；全屏體驗，效果更佳。

有了優雅的排版，怎能不分享給好友呢？以書會友，共讀精彩。當我偶然在一個讀書群中看到用戶分享使用 Klib 生成的讀書筆記時，真的很開心 :)

6. 「實驗室」

功能的開發，總是眾口難調。而我也可能做出錯誤的判斷，怎麼辦呢？

目前，Klib 引入的「實驗室」功能。對於變動較大的新功能，都會在「實驗室」中觀察一段時間。如果大家不喜歡，新功能將會調整、甚至移除。另外，考慮暫時不用考慮收費的問題，看試驗的結果，延遲決定。

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 甚至更多版本的朋友。

收集日誌

錯誤是難免的，重要的是及時改進。要改進，首先就要能知道錯誤。

• Klib 本身會在錯誤時輸出日誌、記錄在本地
• 集成 DevMate 后，可以很方便地收集閃退日誌

當然，前提是用戶願意並手動發送日誌。

慎用第三方庫

或者說，盡量使用穩定可靠的第三方庫。在 DevMate 中追蹤到的僅有的幾個 Crash 中，大部分是 6 年前的 Evernote SDK 引起的，我也是無奈…

軟體性能

Klib 最開始遇到的性能瓶頸是：當用戶有上萬條標註時，導入需要將近 2 分鐘。其中，大部分時間用於日期識別、數據合併。經過改進后，導入僅需 10 秒左右，滿意。

不過，目前還有待改進的是：當有大量數據時，界面操作會有卡頓。數據越多，卡頓越明顯。確實還是有可改進的空間。一方面是減少計算量，另一方面是進一步分離界面操作與後台數據計算。

Klib 運營 & 推廣

酒香也怕巷子深。這時代，大家每天要接觸的信息太多了，要將自己的產品展現在用戶面前，很難。也就意味著，很需要花時間、花心思去研究。我做的並不好，也並沒有找到門道，這裡只是大致列出我所做的事，供大家參考。

在 MAS 提交版本

這可以說是運營的起點。因為畢竟 MAS 是 Klib 唯一的下載渠道，是臉面。並且，MAS 還是有些自然流量的。即使這個環節不加分，至少不能減分。

每次提交版本，都要處理至少以下內容：

• 應用名稱
• 描述
• What's New
• 關鍵字
• 截圖

考慮到目前 Klib 支持 簡體中文、英文、德文，工作量實際是上述的 3 倍。

其中，截圖部分最為麻煩。因為，不僅要處理圖片，關鍵的，要 事先準備素材（如書、標註內容等），才能生成適當的截圖。中文還好，可我並沒有標註那麼英文原著。即使有，也都是技術類書籍，並不適合用於 MAS 的截圖。沒辦法，我只能找英文中流行的書，從 Amazon 官網中找其分享的標註，合成一樣書的閱讀筆記。這種工作是非常費時的，德語版我乾脆放棄了，直接使用英文的素材。

域名與官網

之前，Klib 是掛在 Toolinbox 官網的：

後來，為了方便推廣，我又挑選了 Klib.me 這個域名，並建立官網：

這個頁面看似簡單、卻花費大量時間：

• 編寫內容，製作圖片
  • 中文、英文
• 頁面排版
  • 適配不同設備
  • 微信分享時顯示圖標
• 全球訪問加速
  • 期間，為了使用國內的 CDN 等資源，還不得不關站圖案，哎…
• SEO 優化

有個短的域名很重要，這樣後來在分享筆記時，就可以有類似 這種簡潔的網址。

使用教程

隨著 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 x 0.1 x 0.1 x 0.1 = 0.0001，可真是萬里挑一

怎麼辦呢？

方向一：深挖 Kindle 輔助工具這個定位

好處是：

• 可以讓 Kindle 用戶獲得更好的體驗

• Kindle 的用戶群體還是太小
• 更關鍵的，Kindle/Amazon 並不是一個合適的合作夥伴，不開放數據介面，很多體驗很難做好

筆記的來源可以不止是 Kindle，也可以是 iBooks、多看等等；除了在 Klib 中閱讀，還可方便地導出至 Evernote、OneNote 等目標應用。

• 可以獲得更多潛在的用戶
• 可以增加產品的使用頻次

壞處是：

• 技術上非常依賴於第三方應用的開放程度、穩定性
  • 目測像微信閱讀這樣的應用，不見得深度開放數據，進而很難在其基礎上有所發揮
  • 而且，一旦未來比現在更封閉，屆時已經實現的功能就會失效（參見微博介面的越來越封裝），這對於產品而言是很大的風險

目前還很難決擇，暫定先觀察一段時間；等考慮成熟了，再進一步改進。

考慮的同時，我準備挖個新坑：iTips, 碎片信息管理工具。這是我的 iPaste 的一位荷蘭用戶跟我提的需求，接下來的一段時間，我會跟他進行國際合作，共同打造這樣一款國內、國外用戶都喜歡，橫跨 macOS、iOS 的新工具，敬請期待。

博客原文：0704 - Klib 到底賺了多少錢？