「 iOS知識小集 」2018 · 第 42 期

原文連接

上週公衆號發佈的如下文章：

• 一些 RxSwift 思考題
• CocoaPods 都作了什麼？
• 初步探索LaunchScreen
• 使用 Metal 和 Core ML 評價照片質量

本期知識小集的主要內容包括：

• 使用 Named UIColor
• Diff:/Podfile.lock NO such file or directory
• iOS 中的 GZIP 壓縮
• 使用 CaseIterable 獲取枚舉的全部 case
• 不可或缺的背景色

使用 Named UIColor

從 XCode 9 開始，咱們能夠在工程中建立 named color，並在代碼或 Storyboard 中使用。要建立 named color，只須要進入 Assets.xcassets 中，點擊右鍵，出現圖 1 的菜單，選擇 New Color Set，

而後編輯 named color 的名稱和色值等信息，如圖 2 所示。

在代碼中，咱們能夠直接使用 UIColor(name: "Test")來使用，如圖 3 所示。

Diff:/Podfile.lock NO such file or directory

做者: Lefe_x

當 Pod install 後，運行項目後發現報錯，錯誤提示如圖所示。按提示看了下 Podfile.lock 是存在的。試了各類辦法，都沒有解決（刪除 pods 文件夾，從新安裝，都很差使）。無奈之下，看了下文件的路徑。發現文件路徑錯了，XXX/Pods/Pods/Target Support Files/xxx，發現文件路徑多了個 Pods。這個路徑我並無設置，是 Pod 本身管理的。最後發如今下圖的位置中能夠配置路徑，把這個路徑修改爲正確的地址就能夠了：

iOS 中的 GZIP 壓縮

做者：這個湯圓沒有餡

當項目中與後端接口交互涉及到大量數據信息的時候，爲了提高響應速度須要對傳輸的數據進行壓縮，壓縮成功後將 data 轉化爲 string 傳給服務器。

關於 iOS 端的 GZIP 壓縮，這是我目前在 github 上找到的 star 數最多的一個：t.cn/RUBP1Le

GZIP 支持 cocoapods，若是手動導入的話，記得在 Targets--Build Phases--Link Binary With Libraries 中添加 libz.1.2.5.tbd。

模擬一萬條簡單的數據，看看壓縮先後數據大小變化。以下圖。

通過 GZIP 壓縮後，字節量縮小幅度很大。可是壓縮後的 data 是沒法經過 - (nullable instancetype)initWithData:(NSData *)data encoding:(NSStringEncoding)encoding; 這個方法獲得string的。

這個時候咱們再來看 java 中對於壓縮的數據是如何解壓縮的，java 代碼以下圖。

其中有一行代碼爲

byte[] compressed = new sun.misc.BASE64Decoder().decodeBuffer(compressedStr);
複製代碼

說明 java 是對 base64 的string 進行解壓縮的，也就是說咱們在進行 data 壓縮後，須要傳 base64 的string 給服務器。那麼只須要加一行代碼

[zipData base64EncodedStringWithOptions:0];
複製代碼

使用 CaseIterable 獲取枚舉的全部 case

在寫 Swift 代碼時，可能須要獲取枚舉的全部 case，在以前的版本中，咱們可能須要本身來實現一個靜態方法 allCases，以下代碼所示：

enum CompassDirection {
    case north, south, east, west

    static let allCases = [north, south, east, west]
}
複製代碼

而在 Swift 4.2 中，標準庫爲咱們提供了 CaseIterable 協議，能夠實現這個需求，以下代碼所示：

enum CompassDirection: CaseIterable {
    case north, south, east, west
}

print("There are \(CompassDirection.allCases.count) directions.")
// Prints "There are 4 directions."
let caseList = CompassDirection.allCases
                               .map({ "\($0)" })
                               .joined(separator: ", ")
// caseList == "north, south, east, west"
複製代碼

實現 CaseIterable 的枚舉在編譯器會自動合成 allCases 方法，且 allCases 數組中的元素按 case 聲明的順序。不過若是枚舉中的關聯值或者 @available 屬性，則須要本身重寫 allCases，以下代碼所示：

enum CompassDirection: CaseIterable {

    case north, south, east
    case west(Int)

    static var allCases: [CompassDirection] {
        return [north, south, east, west(0)]
    }
}

print("There are \(CompassDirection.allCases.count) directions.")
// Prints "There are 4 directions."
let caseList = CompassDirection.allCases
    .map({ "\($0)" })
    .joined(separator: ", ")
// caseList == "north, south, east, west(0)"
複製代碼

不可或缺的背景色

做者：Vong_HUST

最近遇到兩個和背景色有關的坑，和你們一塊兒分享下。第一個頁面 A push到頁面 B 時，會莫名卡頓。一開始還覺得是代碼裏有耗時操做，而後就一行行屏蔽，屏蔽到什麼代碼都沒有了，仍是會卡頓，如今大概就以下圖所示。

以爲難以想象，由於 push 到其它頁面都不會發生這種狀況，最後比對代碼發現，其它頁面比 B 頁面惟一多的一個操做就是設置了 vc.view.background，只要設置了背景色不爲 nil 且不爲 [UIColor clearColor]，就不會出現圖中的卡頓感。

另一種狀況就是，若是 collectionView 和 vc.view 背景色都是 nil 或者 clearColor，會出現一種現象就是 collectionView 只能響應有內容區域的點擊事件，好比一個 (0, 0, 100, 100) 的 cell 上有一個 (0, 0, 20, 100)的 button，則只有按鈕區域是能點擊響應事件，其它空白區域(20, 0, 80, 100)的區域點擊是不會觸發 didSelect 回調的，一旦設置了 vc.view 的背景色，就會恢復正常。

以上兩種現象都是因爲背景色沒有處理穩當，致使頁面卡頓或沒法響應事件，只要設置了背景色，便可恢復。具體緣由還不清楚，有知道的老哥們能夠在評論中指點一波~

注：提拉拉拉就是技術宅 大大對此的解釋是：不是卡頓，動畫原本就是這樣子的，後面的vc只推過去一點點。我曾經作過一個app，背景是spritekit的特效，而後整個app 全部vc 都是模態窗口蓋在特效上面，背景顏色所有都是clear ，push的動畫自己就是這個樣子的。

關注咱們

歡迎關注咱們的公衆號：iOS-Tips，也歡迎加入咱們的羣組討論問題。能夠公衆號留言 ios、flutter 等關鍵詞獲取入羣方式。