老司機 iOS 週報 #32 | 2018-08-20

老司機iOS週報發表於2019-02-27
iOS

老司機 iOS 週報，只為你呈現有價值的資訊。

你也可以為這個專案出一份力，如果發現有價值的資訊、文章、工具等可以到 Issues 裡提給我們，我們會盡快處理。記得寫上推薦的理由哦。有建議和意見也歡迎到 Issues 提出。

新聞

最親民的 HomeKit：用 Siri 控制米家智慧硬體

一直以來，HomeKit 配件因為過於昂貴的原因，阻礙著它進入尋常百姓家。另一方面，國內小米的生態佈局已經初見規模：開關、插座、燈等品種繁多。但是，Apple 的生態中，使用 Siri 來控制家中的硬體無疑是最方便的。而通過米家應用來控制硬體總有點隔靴搔癢的感覺。為此，先行者們曾考慮使用樹莓派來曲線救國，不過操作複雜，對一般使用者還門檻頗高。這一次，米家原生的 HomeKit 控制器來了，使用原汁原味的家庭和 Siri。如果你正準備做智慧化改造，不妨試一試。

文章

? ? 為什麼大公司還在採用過時的技術？

本文描述了一個很現實的問題，就是部分人費勁心力加入的大公司，實際上卻跟自己想的不一樣。其實很多大公司都是從小公司發展來的，不可避免會遺留一些古董，甚至不良風氣。從公司盈利的角度看，成本是首先需要考慮的，如果重構後帶來的收益大於繼續修補維護，那麼大部分老闆會願意進行改良。但假如沒有過硬的技術能力，大公司是不太可能會讓你拿新技術試水的。並不是大公司技術不行，而是他們懂得風險控制，想尋找最合適的人來做而已。正如作者在文中所說，“工作中，不斷的提升自己，少一些抱怨吧”。所以我們更應該努力成為公司老闆們努力尋找的 —— 我們需要的就是你這樣的 —— 人。

? Let it Rip

作者記錄了一次用 LLDB 的 regular expression breakpoints（正規表示式斷點） 和 breakpoint commands 結合起來有效地追蹤一個看起來毫無頭緒的問題根源的過程。下一次當你面對貌似束手無策的 warning / error 時，考慮設定一個廣泛的、基於正規表示式的斷點和一系列命令來幫助你吧。

? 談談 RxSwift 和狀態管理

現在大前端的概念非常深入人心，在大前端中一個體系是幾乎無法被忽略的：React 體系。React 體系深入地影響了前端、客戶端近幾年的技術發展。從基於 JS 的 React，Vue，Rax 到基於客戶端語言的 RxSwift，RxJava，雖然實現細節各有各的不同，但背後反映的思想都出奇的一致：通過利用函式式和響應式程式設計的思想，總結出了一套新的模式來更好的實現業務需求。

這篇文章探討了在前端中已經取得廣泛應用的兩個模式，基於 React 的 Redux 和基於 Vue 的 VUEX，在 Swift 中的落地實現，分析了其中的優劣，並且在最後提出了一種相對簡化的模式。文章寫得循序漸進而且介紹相對全面，即便是之前並不熟悉這些概念的同學也能很容易看懂，推薦。

? 把 Objective-C 類遷移到 Swift

30 期週報中 Migrating an Objective-C class to Swift 的續篇，在重構的同時保持原有功能並且繼續添磚加瓦，除了 extension 之外最顯而易見的方法就是繼承，逐漸把 Objective-C 類的抽象挪到 Swift 類裡就可以平滑地完成遷移，其中的優劣勢可以看 Ole 給你細細分析。

? Scalable bulleted lists with UILabel or UITextView

一個使用 UILabel 實現段落樣式的範例，主要是通過一個 NSParagraphStyle 的 headIndent 屬性來完成整體段落縮排（首行除外）。

? iOS App 後臺 Crash 調查

Peak 最近在調查一個詭異的 crash，該問題無法通過 App 內部的 crash 捕獲框架獲取日誌，但可以通過 Xcode 檢視系統自帶的崩潰日誌看到。經過排查，最終將問題鎖定在了系統為了保證本地共享目錄下資料庫的同步，從而強殺 App 生成 code 為 0xdead10cc 的閃退日誌。

在這次問題排查後，Peak 還總結了現在 iOS 後臺任務執行的一些場景以及一些無法通過 App 內部 crash 收集工具的 crash 型別，對於我們平常排查閃退問題，有一定參考意義。

? Creating a Bottom Sheet

這篇文章比較詳細的描述瞭如何實現一個類似於系統地圖首頁的底部帶有一個列表的介面。雖然說這並不是一個很難的問題，但是作者提供的思路包括他的程式碼實現，都給人以一種十分精簡的感覺。特別是通過組合的控制器，而不是在一個控制器上面操作不同的檢視方式也給我帶來不少新的思考。

? 端內外融合拉新，使用者增長 — 相關技術方案選型分析

H5 網頁端有著便於傳播，方便在各類 APP 與瀏覽器容器中進行推廣，而 APP 客戶端用來承接，有著更好的體驗與長久使用者存留的收益與價值。如果能將使用者從 H5 -> APP 的流程進行打磨，將體驗進行優化，就能極大程度的提高拉新的轉化率，而這其中的關鍵就是打破 H5 -> APP 之間傳遞資料，進行無縫銜接的方式。

眾所周知，從H5 -> APP 傳遞資料廣泛使用 deeplink ，也就是通過 Scheme/UniversalLink 直接喚起 APP 進行無縫銜接。那麼假如你在瀏覽 H5 網頁的時候未安裝APP，那麼如何無縫的實現 APP 剛一安裝就能自動拿到H5資料，從而進行體驗上的無縫銜接呢？本文會帶給你答案。

? The 5 Whys for Product Managers

“5 個為什麼”是借鑑自豐田產品系統的分析技術，用於尋找問題的根本原因。這個模型鼓勵連續回答幾個簡單的“為什麼”，然後會發現每個看似是技術上的問題，最後歸根結底都是人的問題。但是“5 個為什麼”並不是為了歸責，而是為了找出異常出現的根本原因，以便讓團隊不斷進步，讓類似的問題不再發生。

? How to Build Swift Compiler-Based Tool? The Step-by-Step Guide

Polidea 開源了一個名為 Sirius 的程式碼混淆工具，他們同時也根據在實現 Sirius 過程中遇到的問題和相關經驗，寫了一篇關於如何使用 Swift Compiler-Based Tool 的文章。

文章分兩部分介紹他們在實現 Swift 程式碼混淆工具過程中的經驗：

  1. 如何擴充 Swift 編譯器，讓其可在編譯和整合階段呼叫自己寫的工具。
  2. 如何使用編譯器內部方法，從 LLVM，Clang 和 Swift 本身提供的功能來增強寫的工具。

文章比較長，最好大家能親自動手實踐一次，才能更好的理解文章。

? Sourcery – Swift超程式設計實踐，告別樣板程式碼

Swift Codable 優化了解析 JSON 的體驗。但是如果有一個屬性的解析名稱需要自定義，或者跳過某個屬性的 JSON 對映，都需要自己手寫全部的 Codingkey。本文介紹了利用 Sourcery 的超程式設計能力來優化一些需要手寫 Codingkey 的場景。

? Trimming long argument lists in Swift

當我們想為一個已有的方法增加新功能，但又不想重新寫一個類似方法的時候，通常會往引數列表裡增加新的引數。雖然每一次修改看起來都沒什麼問題，但是久而久之引數列表會變得冗長，對其他維護者來說也越來越難以理解。作者列舉了幾個小技巧，包括通過封裝相關聯的幾個引數為新型別、通過拆分/組合的方法解耦複合邏輯等，展示瞭如何在擴充套件功能的同時，最大可能保持程式碼的整潔性。

程式碼

視覺化除錯時將指標地址轉為 emoji

我們除錯時經常需要判斷兩個變數是否是同一個例項，然而大部分時候 po obj 只能得到得到一串記憶體地址，需要人眼去比對。這個 gist 擴充套件了 NSObject，使得 print obj.asPointer.asEmoji 可以列印出 emoji 字元(比如 ?)，而不是指標地址。

內推

北京-螞蟻金服 招iOS/安卓/前端開發

螞蟻金服招聘，負責支付寶會員及帳號業務線，地點北京國貿，金臺夕照地鐵站出口 100 米。雖然招聘連結只給了 iOS 的 JD，但前端/安卓/iOS 都要，要求相近。有興趣的同學歡迎將簡歷傳送到：weijing.wdf@alibaba-inc.com / weijing.wdf@antfin.com （同一個郵箱） 或這微博私信 @折騰範兒_味精 瞭解情況。

編輯內推

關注我們

我們開通了公眾號，每期釋出時公眾號會推送訊息，歡迎關注。

老司機 iOS 週報 #32 | 2018-08-20

同時也支援了 RSS 訂閱：github.com/SwiftOldDri… 。

本期編輯

@沒故事的卓同學，@四娘，@享耳先森，@Damonwong，@折騰範兒_味精，@張嘉夫，@AidenRao，@Parsifal，@aaaron7，@方秋枋，kyo，tom510230，anotheren，水水，looping，@JasonYuh，@老老老老老老老驢

說明

? 表示需翻牆，? 表示編輯推薦

預計閱讀時間：? 很快就能讀完（1 – 10 mins）；? 中等 （10 – 20 mins）；? 慢（20+ mins）

相關文章