2016 年 7 月 4 日，圖床神器 iPic 上架 Mac App Store问欠，雖說這是個好記的日子：美國獨立日肝匆，但其實我還是忘記了。是前幾天一條銀行扣款短信提醒了我顺献，剛開始我還覺得奇怪：我最近沒在 MAS 上買軟件呀旗国？后來一查才知道：這里 iPic 高級版第二年的扣款短信。
Git 歷史顯示注整，iPic 項目始建于 2016 年 5 月 19 日能曾。事實上，因為已經(jīng)過了這么長時間肿轨，我也記不起 iPic 一路走來的點點滴滴寿冕，很難像 Klib 那樣有系統(tǒng)性的總結。這里主要回憶一些關鍵的點椒袍，或者我覺得有意思的驼唱，拿出來與大伙一說。
文章很長驹暑，我也并不知道你大概需要幾分鐘讀完玫恳；不喜歡讀長文的辨赐，現(xiàn)在就可以關閉了，去找些你更感興趣的吧京办。
------------- 長文開始警戒線 ----------------
iPic 帶給我的驕傲
我最驕傲的掀序，是 iPic 開創(chuàng)了 macOS 圖床工具這一品類。在 iPic 之前臂港，你在 macOS 中是找不到類似工具的森枪，而在 iPic 之后，接連有多款 App 出現(xiàn)审孽，甚至包括 Windows 版县袱。曾經(jīng)，你在 Mac App Store 搜索「iPic」佑力，會有多款類似產(chǎn)品式散。使用「iPic」作為搜索關鍵字，也算是他們向我致敬的一種方式吧打颤。不過暴拄，現(xiàn)在沒有了，因為我向蘋果舉報编饺、蘋果向他們發(fā)律師郵件乖篷，他們已經(jīng)去掉這一關鍵字了。
如果你在 macOS 平臺找到比 iPic 更好的圖床工具透且，告訴我撕蔼。
Swift 帶來的尷尬
Swift 是 2014 年中發(fā)布的，iPic 是 2016 年初啟動的秽誊。雖說已過 1 年多鲸沮，但對于一門編程語言而言，還是太短了锅论。主要的問題是：不成熟讼溺，導致廠商對 Swift 的支持非常有限。比如最易，iPic 需要集成各家圖床所提供的接口怒坯。對于一些較成熟的語言，比如 JavaScript藻懒、Python 等等敬肚，廠商可以直接提供了 SDK，只需要調(diào)用簡單的接口束析，就可以實現(xiàn)圖片上傳這樣的操作艳馒。
而對于 Swift 這么年輕的語言，肯定是沒有 SDK 的，這就需要我 一個個去集成各個服務商的 REST API弄慰，這一過程相當繁瑣第美。其中，大量的時間花在 OAuth 的實現(xiàn)上陆爽。不過什往，好在 OAuth 是相對標準的東西，各家的實現(xiàn)也大體相當慌闭，多支持幾個圖床别威，能重用的代碼也多了。
另外驴剔，做這種相對 SDK 來說偏底層的東西省古，也是有好處的。比如丧失，可以多一些對 OAuth 的理解豺妓；在設計 Klib 后端接口時，也能多參考這種工業(yè)級的 REST API 設計規(guī)范布讹；等等琳拭。
其實，在這個過程中也會有很多有意思的發(fā)現(xiàn)描验，比如白嘁，阿里云的 OSS 接口基本是復刻 Amazon S3，連參數(shù)名都一樣膘流。Amazon S3 果然是企業(yè)級的权薯，權限系統(tǒng)什么的很復雜，一般人很難搞定睡扬，而后來的阿里云則對中小用戶更友好些。當然黍析，只是模仿接口也未可厚非卖怜，但總會讓人看輕一些：不要把 S3 中一些不好的設計也抄了去才好 ??
期間，也經(jīng)歷了 Swift 2.2 > 3.0 的升級阐枣，感覺比較多的變更都是語法層面马靠，甚至可以說是變量名方面。個人感覺蔼两，我愿意給 Swift 版本升級多一些體諒：雖說確實會帶來一些麻煩甩鳄，但總比裹足不前要好。
順便說一句额划，我所有的產(chǎn)品都是純 Swift 的：Klib妙啃、iPic、iPic Mover、iPaste揖赴、iTimer馆匿、iHosts
我不愿增加一個額外的選項
首先吐槽一下七牛的接口。
七牛起初只有幾個區(qū)域（好像是華北燥滑、華東渐北，具體忘了），每個區(qū)域的不同的圖片上傳地址铭拧。后來赃蛛，七牛增加了新的區(qū)域，每個區(qū)域又有新的上傳地址搀菩。關鍵問題在于呕臂，Bucket 的名字在各個區(qū)域中不能重復的，但七牛卻沒有提供根據(jù) Bucket 名字查詢其所在地區(qū)的接口秕磷。這就意味著诵闭，在 iPic 的圖床配置中，用戶需要額外指定 Bucket 所在地區(qū)澎嚣。這在我看來疏尿，是相當傻的。我相信易桃，很多用戶在創(chuàng)建結果后褥琐，并不記得 Bucket 所在地區(qū)，這就使得在配置圖床時晤郑，遇到了額外的困難敌呈。
我實在不想增加這一設置項，所以實際上我是這么做的：用戶不需要指定地區(qū)造寝，iPic 自動嘗試所有地區(qū)磕洪。如果圖床的其他信息如 Key 是正確的，則可以找到正確的地區(qū)诫龙。這一方案析显，唯一問題是：一旦七牛又新開了區(qū)域，iPic 就得多嘗試一個地區(qū)签赃。至少谷异，iPic 需要從服務器端獲取七牛所有的區(qū)域列表，多了一點點維持工作量锦聊。不過歹嘹，為了減少界面上一個設置項，這些都是值得的孔庭。
其實尺上，不止七牛，別的圖床也有類似的問題。不過尖昏，要好一些仰税。比如，Amazon S3 如果選擇錯誤的地區(qū)上傳抽诉，返回結果中會包含正確的地區(qū)陨簇，選用即可。
這樣以后迹淌，七牛河绽、又拍、阿里云 OSS唉窃、Amazon S3 的圖床配置界面一模一樣耙饰，這降低了用戶的使用成本，也讓我很滿意纹份。
開放圖片上傳能力的 iPicUploader
iPic 一個比較重要的場景：在使用 Markdown 寫文章時苟跪，插入圖片。那與其單獨使用 iPic 這樣一個額外的 App蔓涧，直接使用 Markdown 編輯器來插圖件已，豈不更好？不過事實上元暴，僅有少量的 Markdown 編輯器支持圖床功能（如我在用的 MWeb）篷扩，大部分并不支持。
正巧茉盏，Typora 作者聯(lián)系上我鉴未，希望與 iPic 集成，可謂一拍即合鸠姨。
于是铜秆，我好好研究了在 macOS 沙盒限制下，各個 App 間通信的方式讶迁。最后连茧，我選擇了「私有剪貼板」這種方式（這個名字是我自己取的），既可以安全地上架 Mac App Store添瓷，也不會對用戶的通用剪貼板造成干擾。事實上值纱，在我向 Bear（對鳞贷，就是前段時間大紅大紫的 Markdown 編輯器 Bear）介紹時，他們也夸贊這種方式虐唠。只可惜搀愧，他們沒接入 iPic…
具體的步驟：
- Typora 集成 iPicUploader 這個開源的 iPic 上傳助手
- Typora 等 Markdown 編輯器，當用戶通過拖拽等方式上傳圖片時，讀取圖片信息咱筛，寫入「私有剪貼板」搓幌，然后等待返回結果
- 注：之所以要由 Typora 讀取圖片信息，是因為 iPic 處于沙盒模式中迅箩，如果客戶端僅僅發(fā)送一個文件路徑溉愁，iPic 是沒有權限讀取的
- 另外，iPicUploader 也能檢測 iPic 是否安裝饲趋、當前是否在運行等情況
- 當 iPic 運行時拐揭，會監(jiān)控「私有剪貼板」中的內(nèi)容。一旦發(fā)現(xiàn)有待上傳的圖片奕塑，則上傳堂污、并將圖片地址寫回「私有剪貼板」
- Typora 得到上傳結果，即圖片的 http 地址龄砰，更新 Markdown 中的圖片鏈接
事實上盟猖，從客戶端的角度，使用過程比上述文字描述要簡單的多：只要在項目中集成 iPicUploader换棚，通過一個接口調(diào)用就可以了：
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 這樣級別的產(chǎn)品如果集成 iPic，那對 iPic 自然是極好的颇蜡。只可惜价说，大部分邀約都沒有反饋，最終成產(chǎn)品的只有 Typora…
自立山頭的 iPic Mover
除了配合 Markdown 編輯器风秤，我還單獨開發(fā)了 iPic Mover鳖目，核心功能是：通過 iPic 上傳 Markdown 中的圖片（包括本地或網(wǎng)絡圖片）至新的圖床，并替換 Markdown 中的圖片地址缤弦。
主要的使用場景：
- 將博客中的圖片整體搬家至新圖床
- 使用 Markdown 編輯器編輯文章后领迈，一鍵上傳本地圖片
其實，這個功能確實可以作為 iPic 的一部分碍沐。這樣狸捅，至少可以省去單獨為 iPic Mover 這款 App 設計 Logo，運營推廣等多方面的資源累提。不過尘喝，我還是不想因為這個小眾的功能，讓 iPic 主體變得復雜斋陪。畢竟朽褪，大部分 iPic 用戶并不需要這個功能置吓。如果不需要卻要天天看見這個功能，我是覺得不爽的缔赠。
免登錄上傳圖片至微博
iPic 默認上傳圖片至微博圖床衍锚，且無需登錄。為什么一定要做到無需登錄呢嗤堰？主要是為了實現(xiàn)「開箱即用」的效果戴质。想想一個國際友人，在下載 iPic 后梁棠，還需要注冊一個微博賬戶才能用置森、注冊界面丑陋且多年未更新，那是怎樣的畫面符糊？
其實凫海，iPic 要實現(xiàn)開箱即用：即安裝后就可以上傳圖片至微博，技術上還是有些復雜的男娄。不過行贪，嚴格來講，把微博當圖床來用模闲，本身確實是在道德上無法站住腳的建瘫，怎么說都有濫用微博資源的嫌疑。出于這一點尸折，我就不在文章中詳細介紹了啰脚，大家也不要私信問我，我不會回答实夹。不過橄浓，想想我經(jīng)常看的亮航，包括 App 啟動廣告荸实、女性生理期用品在內(nèi)的微博廣告，我心里就覺得舒服一些了缴淋。
關于 iPic 付費模式
iPic 的付費模式是：
- 默認的（微博）圖床免費准给，所有 iPic 的功能免費
- 自定義圖床收費，圖床包括：七牛云 重抖、又拍云露氮、阿里云 OSS 、Imgur 钟沛、Flickr 畔规、Amazon S3 共 6 款，包含了目前主流的圖床讹剔，收費模式為 ￥58 每年
其實油讯，默認的微博圖床還是挺好的：免費、不限流量延欠、CDN 加速陌兑、穩(wěn)定可靠、支持 https 等等由捎，主要的局限是：
- 不支持 png 格式
- 會對圖片進行肉眼可見的有損壓縮
- 無法刪除已上傳的圖片
- 無法查看或管理所有自己上傳的圖片
- 畢竟是依賴第三方服務兔综，多少有風險，比如新浪倒閉
相反狞玛，如果不能接受微博圖床的上述局限软驰，可使用靈活度更高的自定義圖床。比如心肪，我自己使用的是七牛圖床锭亏。起初是因為七牛提供一定額度的免費流量，后來才發(fā)現(xiàn)是個坑：免費流量不支持 https硬鞍，而我的 博客 和 產(chǎn)品首頁 已經(jīng)全面支持 https慧瘤，雖說我每月也就給七牛交很少的流量費，不過多少有些受騙的感覺固该。早知如此锅减，我就選擇阿里云 OSS 了。
這里順便再說個七牛的一個坑：不支持 bucket 的自定義域名伐坏。也許你會說：支持的呀怔匣？但其實，只有「融合云」是支持的桦沉。但 CDN 畢竟有緩存問題每瞒，比如在做 Klib 分享時，我并不想因為速度的提升帶來很大的緩存的問題（這會帶來業(yè)務的問題永部，詳見我當時的介紹）独泞，最后還是使用了支持自定義域名的阿里云 OSS. 比如，你在訪問 http://s.klib.me/share.html 時苔埋，其實是訪問的阿里云 OSS 里的文件懦砂。
關于訂閱模式
現(xiàn)在，訂閱依然不為人所接受组橄。而想想 1 年前荞膘，訂閱更加被抗拒；但我還是依然堅持做吃螃蟹的人玉工。一方面羽资，我想有所嘗試；另一方面遵班，我覺得訂閱制是對開發(fā)者友好的屠升，進而對整個生態(tài)友好的潮改。試想，如果開發(fā)者都堅持不下去了腹暖，也就不會再有好軟件誕生汇在。Windows 的生態(tài)就是很好的例子，我時不時聽到有開發(fā)者放棄脏答、或不愿開發(fā) Windows 下的應用糕殉，很大的一個原因是：盜版太猖獗。很多人用盜版用得理所應當殖告，覺得 Windows 操作系統(tǒng)收費是變態(tài)阿蝶，OK，惹不起我還躲得起黄绩，最終吃虧的還是用戶自己：沒有好軟件可用羡洁。
Apple 的訂閱制有個細節(jié)可以跟大家分享下。對于訂閱的首年爽丹，Apple 會抽成 30%焚廊，即你付的 58 中，我只能得到 58 * 0.7 = 40.6习劫，17.4 被 Apple 拔毛了咆瘟。而在第 2 年及以后，Apple 抽成降低至 15%诽里，即我可以多得 8.7 元袒餐。雖不多，但蚊子腿也是肉谤狡。更多的灸眼，是 Apple 對開發(fā)者的支持，用戶對我的肯定墓懂。
￥58 一年的軟件貴嗎焰宣？貴，尤其是在國內(nèi)的軟件環(huán)境里捕仔，絕對是高價匕积。但，還是有人愿意購買榜跌。我相信闪唆，購買的人不是傻子，而是經(jīng)過充分對比才做的聰明選擇钓葫。￥58 一年對于使用 iPic 所節(jié)約的時間而言悄蕾，可以忽略。用錢買效率础浮，并不是所有人的習慣帆调，只是高效人士的習慣奠骄。
很開心的，就是通過 iPic 認識了一群 高效人士番刊。他們認可我的努力戚揭，認可我對產(chǎn)品的理解，認可 iPic 對他們帶來的幫助撵枢，愿意用付費的方式來支持我繼續(xù)，還通過微信群精居、郵件等方式锄禽，提出改進意見。在此靴姿，謝謝各位的支持沃但。
關于 iPic 的未來
其實，就像我在小結 Klib 中已經(jīng)提到了佛吓，對于 iPic 這種典型的工具型應用宵晚，其天花板是很明顯的：一旦功能實現(xiàn)了，進一步的想象空間很小维雇。這也是我很長時間都沒有對 iPic 更新的主要原因淤刃，因為不知道怎么做才是對的。
比如吱型，有用戶提除了 Markdown 格式外逸贾，也支持 reST 等其它標記語言的格式。這樣的需求肯定是有道理的津滞。但問題是铝侵，相對而言更小眾。如果列表里同時列出 Markdown触徐、reST咪鲜，對于只用 Markdown 的大多數(shù)用戶而言，是種干擾撞鹉，因為他們可能根本就不知道什么是 reST疟丙。當然，可以在配置在自定義鏈接格式鸟雏。這也是有道理的隆敢，只是又增加了產(chǎn)品的理解難度。
對于這類的需求崔慧，我很難判斷是否要加拂蝎。不加，肯定會流失部分用戶惶室；加温自，又會對已有用戶造成一定的困擾玄货。想不好之前，我寧愿暫時什么都不做悼泌。
當然松捉，這并不意味著 iPic 不會更新。就像同樣許久未更新的 iPaste馆里，本月會迎來重大更新：支持 Pin 分組及管理隘世。同樣的材彪，隨著大家對圖床需求的演變惠猿，一旦我想通了某一點刘陶，自然會適時跟進的阔馋。
尾巴
這篇文章很長缓升，希望你能有與付出時間相稱的回報划址。不然蛀骇，我不會覺得不好意思…
