騰訊雲Mac圖牀插件

背景

隨着博客越寫越多，不免會遇到須要插入圖片來講明的狀況。

圖牀選擇

首先調研了市面上的圖牀服務，本着穩定長期的目標，過濾掉了打一槍換一個地方的野雞小網站，剩餘比較靠譜的優缺點以下。

圖牀	優勢	缺點
騰訊雲	免費 無需域名	將來可能會收費
七牛	免費	須要域名和備案
又拍雲	免費 無需域名	將來可能會收費
阿里雲	目前最完備	收費 須要域名
微博	免費 無需域名	不穩定 匿名上傳

做爲一個剛起步的小博客，應該把精力更多關注於內容，之後再考慮域名備案或者大流量套餐，所以儘可能選擇免費的圖牀。 實際上是窮

微博做爲國內數一數二的流量大戶，其圖牀的CDN和質量確定沒有問題，可是上傳圖片會自帶水印，且匿名上傳總以爲不靠譜。

剩下的選擇還有兩個，又拍雲進軍對象存儲領域比騰訊雲早並且更成熟，可是就規模和技術來講，我仍是更願意相信騰訊。

工具

註冊完騰訊雲帳號後，下一個問題就是怎麼更方便的將圖牀與 MarkDown 結合起來使用，提升效率和體驗。

iPic 完美符合個人需求，這是一款 Mac 上的狀態欄軟件，支持上傳本地圖片到設定的圖牀，獲取圖片地址後按照 ![](url) 格式複製到剪貼板。

那麼好的應用爲啥不用呢？

由於不想按年交錢。應用默認是微博圖牀，若是要使用其餘圖牀就須要購買專業版，每一年60元。若是是一次買斷的話，也就買了，年費內心總有疙瘩 矯情。

忽然，我就想到！ 本身開發一個！ 閒的蛋疼

開發iPhone應用已經好多年了，還從未開發過Mac上的狀態欄軟件，正好還能鍛鍊下Swift，因而說幹就幹。沒想到開發了一個月

---

需求設計

產品使用邏輯基本與 iPic 一致，基於狀態欄交互，選擇png jpg文件上傳。

能夠設置是否壓縮圖片，壓縮會壓到500K如下。

還須要有一個登陸界面記錄騰訊雲的帳號和存儲庫信息。

文件上傳成功後，彈出通知提醒，並複製到剪貼板。

若是不慎複製了其餘文本致使丟失了連接，再點擊一次通知就能夠從新獲取。

---

遇到的難題

Swift

第一關就是編程語言。

雖然也曾系統的學過Swift，但因爲常年使用Objective-C 開發，思惟方式還轉不過來。

嚴格的空變量

比較明顯的區別就是處理空變量的方式。

在ObjC中，指針變量能夠是nil（也就是0），對nil執行方法不會發生任何事情，所以能夠算是部分安全。

Swift對待空變量更嚴格，!修飾的變量必須有具體值，?修飾的變量才具備空值的可能性。

nil再也不表示爲空對象，而是一個空值，向空值調用方法會致使閃退。對待?修飾的變量必需要當心，最好先判斷是否有值再使用，好在有語法糖能夠解決這類問題。

//默認爲nil
var money : String?
//變量有值
money = "million"

//判斷確定有值後再使用
if money != nil {
    print("I have \(money!) dollars.")
}

//保證變量有值並賦值給安全變量後執行
if let account = money {
    print("I have \(account) dollars.") 
}

//變量若是沒有值就執行else事件並return
guard let account = money else {
    print("I have no money.")
}

print("I have \(account) dollars.") 
複製代碼

合理使用! ? 會使咱們的代碼更安全與簡潔。

Swift 的 nil 和 Objective-C 中的 nil 並不同。在 Objective-C 中，nil 是一個指向不存在對象的指針。在 Swift 中，nil 不是指針——它是一個肯定的值，用來表示值缺失。任何類型的可選狀態均可以被設置爲 nil，不僅是對象類型。

拋出警告

ObjC 有 @throw 的用法，可是根據蘋果官方的描述，執行的成本很大。究其緣由在於 ObjC 基於 C 語言而不是 C++，因此只能使用 setjmp()和longjmp() 方法實現，所以可能會形成內存泄漏。

Important: Exceptions are resource-intensive in Objective-C. You should not use exceptions for general flow-control, or simply to signify errors (such as a file not being accessible)

Swift 從根本解決了這個問題，並結合枚舉優化了整個流程。

enum CompressError : Error {
    case NoImage
    case OverSize(size : Int)
}

func compressImage(_ imageData: Data?) throws -> Data? {
        guard var compressData = imageData else {
            throw CompressError.NoImage
        }

        if compressData.count > maxSize {
            throw CompressError.OverSize(size: compressData.count)
        }
}

func uploadImage(_ imageData: Data?) {
    var compressData : Data? = nil
    do {
        compressData = try self.compressImage(imageData)
    } catch CompressError.NoImage {
        print("Image Not Exist")
    } catch CompressError.OverSize(let size) {
        print("Image over size of \(size)")
    }  catch _ {}

    //簡潔的方式，忽略處理警告
    let compressData = try? self.compressImage(imageData)
}

複製代碼

利用Swift強大的枚舉類型，能夠定製化警告從而傳遞出咱們須要的信息，使得整個流程更爲順暢。

語法還支持 try?忽略警告獲取一個可能爲空值的變量，若是自信絕對不會拋出異常的話，還能使用try!獲取一個確定值。

Mac OS 開發

實際編寫Cocoa代碼過程當中，發現與UIKit相差仍是比較多的。

控件邏輯

UIKit 的層級通常是 UINavigationController -> UIViewController

Cocoa 的層級則不太同樣，NSWindowController -> NSViewController

緣由也很簡單，手機上通常只有一個窗口，依靠導航欄進行頁面跳轉。可是桌面端邏輯就不太同樣，新頁面通常都是以新窗口的形式彈出。

其次桌面端擁有特定的狀態欄控件NSMenu，在其中操做菜單項也是一個新的挑戰。

騰訊雲相關

因爲騰訊雲只提供了iOS的庫，因此我還須要先把庫文件從新調整爲Cocoa代碼。 這一部分也是吃了很多苦頭，須要把設備相關的代碼與應用、進出後臺的通知等都去除，還要處理相似功能的轉換（好比UIImage -> NSImage）。

同時還有第二個坑，騰訊雲的庫都是ObjC代碼，因此須要混編。

建立一個工做空間後拖入兩個工程，在主工程的 Targets / Build Phases / Embed Frameworks 中加入SDK庫。

接着在Swift工程中建立Project-Bridging-Header.h 頭文件，在其中引用SDK庫。

最後在 Targets / Build Settings / Objective-C Bridging Header 設置頭文件，就能夠解決代碼混編的問題。

其原理在於自動建立了基於頭文件的pch，把頭文件中引用到的ObjC代碼，都橋接到工程中。

圖片壓縮算法

之因此不使用現成的軟件還有一個緣由，就是我想本身控制壓縮圖片的參數和效果。

經過調研和實驗圖片壓縮效果，最終我選擇壓制成jpg格式，500k大小限制，壓縮率限制爲最小0.75，等比寬度限制爲1280px。

文首那張美女圖，初始是1.9M 5087x3661，因爲尺寸過大，第一次壓縮圖片質量後，容量反而增長到了2.4M。

將寬高等比縮小到1280x922，圖片又變大了，此次增長到了4.7M。（改變寬高須要新建一張畫布，建立時必需要有alpha通道等其餘設置，因此會變大）

咱們接着壓縮，最終在壓縮率爲0.9的狀況下把圖片壓到了260K，成功達到了目標。

---

總結

距離上一次博客已經有兩個月的間隔，其中一部分緣由在於生活上的一些變故，另外一個緣由就在於不熟悉 Cocoa + Swift 開發。

好在最終仍是啃出來了，Github項目已開源，歡迎你們指點與吐槽。

此次項目最大的收穫在於脫離本身的溫馨區。人的本性包含惰性，老是趨向於在熟悉的領域幹熟悉的活。可是就和企業同樣，不創新就死，技術不斷在發展，若是沒有跟上潮流，最終就會被淘汰。以此共勉！

---

參考資料

Swift 4.0 教程

App圖片壓縮裁剪原理和上傳方案