回覆 “進群” ，拉你進交流群
本期概要
本期話題：聊聊 iOS 部落格環境，公眾號vs掘金。
Tips：Reachability 的使用建議，SQL 中 JOIN、UNION 的含義，如何在專案中區分 AdHoc 和 AppStore 包。
面試解析：本期講解
block 型別
的相關知識點。
優秀部落格：如何做電量方面的最佳化，關於 MetricKit 的使用。
學習資料：布朗大學的學生製作的「看見統計」課程；一個 Github 倉庫 Hacker Laws，總結各種定律和法則。
一個幫助學習正則表示式的線上工具：regex101。
本期話題
@zhangferry：看一張最近掘金的作者排行榜圖片
整個反應出的就是 iOS 社群不活躍，但真是這樣嗎？單就前段時間老司機週報組織的 WWDC21 內參來說，參與者就有 200+，社群肯定還是活躍的啊。所以我得出的結論是，
就 iOS 部落格環境來說，公眾號要優於掘金
。緊接著就有了這次的想法，介紹一些優質的由個人維護的 iOS 開發公眾號、部落格、獨立應用等，同時還會邀請對應的作者講一下做這些內容的初衷，目前的運營現狀和一些未來規劃。
這次是第一期，邀請的是摸魚週報聯合編輯：展菲。
博主訪談
個人介紹：展菲，目前就職於外企，從事人工智慧、智慧家居研發工作。
做最好的 Swift 社群，我們的使命是做一個最專業最權威的 Swift 中文社群，我們的願景是希望更多的人學習和使用 Swift。我們會不斷維護最佳化，持續輸出優質的原創內容。不忘初心，牢記使命。
開發Tips
整理編輯：夏天 、zhangferry
類的實踐準則
在網路請求實踐中，常見的操作是監聽 的狀態或變換來有選擇的對網路的可達性進行判斷，做出阻止或暫停請求的對應操作。
一直以來，受到監聽網路狀態這種手段的影響，當用戶在執行某些操作時，會根據獲取到的使用者當前的網路狀態，在網路不可達（
NotReachable
）的情況下會
阻止使用者發起網路請求
。
直到我看到了 AFNetworking Issues 中的 Docs on Reachability contradict Apple‘s docs 。
我們不應該使用 作為網路是否可用的判斷，因為在某些情況下，其返回的狀態可能不那麼準確。
在 AFNetworking 的定義了關於 的最佳實踐：
Reachability can be used to determine background information about why a network operation failed， or to trigger a network operation retrying when a connection is established。 It should not be used to prevent a user from initiating a network request， as it’s possible that an initial request may be required to establish reachability。
我們應該將其用於
網路請求後失敗
的背景資訊，或者在失敗後用於
判斷是否應該重試
。不應該用於阻止使用者發起網路請求，因為可能需要初始化請求來建立
可達性
。
我們在網路請求中整合的 應該用在
請求失敗後
，無論是作為請求失敗的提示，還是利用可達性狀態的更改，作為請求重試的條件。
當我們使用 或者功能相似的 類時，我們可基於此來獲取當前的網路型別，如 4G 還是 WiFi。但是當我們監聽到其狀態變為不可達時，不應該立即彈出 來告訴使用者當前網路不可用，而應該是當請求失敗以後判斷該狀態是否是不可達，如果是，再提示沒有網路。並且，如果該介面需要一定的連貫性的話，可以保留當前的請求引數，提示使用者等待網路可達時再主動去請求。
SQL 中的 JOIN 和 UNION
JOIN 作用是把多個表的行結合起來，各個表中對應的列有可能資料為空，就出現了多種結合關係：LEFT JOIN、RIGHT JOIN、INNER JOIN、OUTER JOIN。對應到集合的表示，它們會出現如下 7 種表示方法：
UNION 表示合併多個 SELECT 結果。UNION 預設會合並相同的值，如果想讓結果逐條顯示的話可以使用 UNION ALL。
在專案中區分 AppStore/Adhoc 包
在解決這個問題前，我們先要了解開發環境這個概念，iOS 的開發環境通常涉及三個維度：專案，開發端伺服器，AppStore 伺服器。
專案
即我們的 Xcode 專案，它由 Project 裡的 Configuration 管理，預設有兩個開發環境：Debug、Release。而我們常用的控制開發環境的宏命令如 是 Xcode 幫我們預置的值，它的設定形式為 ，這裡的內容都是可以修改的。
我們新增一個名為 AppStore 的 Configuration，然後給其設定一個宏 ，然後將之前的 Release 設定為 ，即是為這兩個專案環境指定了特定的宏。
開發端伺服器
伺服器環境由服務端管理，反應到專案裡，我們通常將其跟專案環境保持一致。
AppStore 伺服器
AppStore 的開發環境根據證書形式來定，其決定了 IAP 和推送的使用場景，在最後的封包環節決定，Xcode 將其分為以下四種場景：
可以看到 Configuration 設定和封包環節是相互獨立的，如果本地有三個 Configuration 的話，我們可匯出的包型別數量最多為：3 x 4 = 12 種。所以如果僅僅用開發包和生成環境包描述一個包的型別肯定是不夠用的，但全描述又不現實，又因封包環節在編譯之後，所以我們沒法提前決定包型別，所以就有了約定成俗的一些習慣。
開發包通常指：Debug + Development，
生產環境包通常指：Release + Ad Hoc 或 Release + App Store Conenct
如題目所說，如果我們要區分 Ad Hoc 和 AppStore，就需要新增 Configuration：AppStore，這樣的話：
Ad Hoc 包：Release + Ad Hoc
AppStore 包：AppStore + App Store Connect
這樣程式碼裡我們就可以使用我們上面定義的宏對 Ad Hoc 和 AppStore 進行單獨配置了。
既然是約定所以他們之間是不存在強關聯的，所以推薦使用指令碼進行打包，以避免人為導致的錯誤。
備註：經@iHTCboy 建議，還可以透過非 Configuration 的形式區分包型別，部分內容還未實踐，測試完畢之後會將方案放到下一期內容。
面試解析
整理編輯：師大小海騰
本期講解
block 型別
的相關知識點。你是否遇到過這樣的面試題：
block 都有什麼型別？
棧 block 存在什麼問題？
block 每種型別呼叫 copy 的結果分別是怎樣的？
希望以下的總結能幫助到你。如果你對內容有任何疑問，或者有更好的解答，都可以聯絡我們。
block 型別
block 有 3 種類型：棧塊、堆塊、全域性塊，最終都是繼承自 NSBlock 型別。
1. 棧塊
定義塊的時候，其所佔的記憶體區域是分配在棧中的。塊只在定義它的那個範圍內有效。
上面的程式碼有危險，定義在 if 及 else 中的兩個塊都分配在棧記憶體中，當出了 if 及 else 的範圍，棧塊可能就會被銷燬。如果編譯器覆寫了該塊的記憶體，那麼呼叫該塊就會導致程式崩潰。或者資料可能會變成垃圾資料，儘管將來該塊還能正常呼叫，但是它捕獲的變數的值已經錯亂了。
若是在 ARC 下，上面 block 會被自動 copy 到堆，所以不會有問題。但在 MRC 下我們要避免這樣寫。
2. 堆塊
為了解決以上問題，可以給塊物件傳送 copy 訊息將其從棧複製到堆區，堆塊可以在定義它的那個範圍之外使用。堆塊是帶引用計數的物件，所以在 MRC 下如果不再使用堆塊需要呼叫 release 進行釋放。
3. 全域性塊
如果執行塊所需的全部資訊都能在編譯期確定，包括沒有訪問自動區域性變數等，那麼該塊就是全域性塊。全域性塊可以宣告在全域性記憶體中，而不需要在每次用到的時候於棧中建立。全域性塊的 copy 操作是空操作，因為全域性塊決不可能被系統所回收，其實際上相當於單例。
每一種型別的 block 呼叫 copy 後的結果如下所示：
參考：iOS 面試解析｜block 的型別［1］
優秀部落格
整理編輯：皮拉夫大王在此、我是熊大
本期主題：
1、iOS效能最佳化之耗電檢測［2］—— 來自：雜貨鋪
文章介紹了耗電量檢測的三種方式：Energy impact、Energy Log、sysdiagnose。每種方案詳細介紹了檢測步驟。在 Energy Log 中提到了“當前臺三分鐘或後臺一分鐘 CPU 執行緒連續佔用 80% 以上就判定為耗電，同時記錄耗電執行緒堆疊供分析”，這對我們日常分析有一定的幫助。
2、Analyzing Your App’s Battery Use［3］—— 來自：Apple
蘋果官方提供了一些效能監控的手段，透過 Xcode Organizer 可以檢視 24 小時的效能資料，包括電量資料。
3、iOS 效能最佳化：使用 MetricKit 2。0 收集資料［4］—— 來自老司機週報：Jerry4me
既然提到了官方的方案就不得不提到 MetricKit。本文介紹了什麼是 MetricKit，如何使用以及 iOS 14 之後的新的資料指標。另外需要注意的是 MetricKit 是 iOS13 之後才支援的，並且並不能蒐集全部使用者的資料，只有共享 iPhone 分析的使用者資料才能被收集。
4、iOS進階——App功耗最佳化［5］—— 來自cocoachina：yyuuzhu
直觀上耗電大戶主要包括：CPU、裝置喚醒、網路、影象、動畫、影片、動作感測器、定位、藍芽。測試工具：Energy Impact、Energy Log，更加具體的資訊檢視本文。
5、iOS耗電量和效能最佳化的全新框架［6］—— 來自部落格：Punmy
在 Session 417 中，蘋果推出了三項新的電量和效能監測工具，分別用於開發階段、內測階段、以及線上階段。相信透過本文，你會對你的 App 接下去的耗電量和效能最佳化的方向，有更好的計劃。
6、耗電最佳化的幾點建議［7］—— 來自部落格：Catalog
關於耗電最佳化的幾點實操性的建議。
學習資料
整理編輯：Mimosa
Seeing Theory
地址；https：//seeing-theory。brown。edu/cn。html
由布朗大學的學生製作的「看見統計」課程，致力於用資料視覺化的手段讓數理統計概念更容易理解。其中的內容與國內本科的機率論與數理統計內容也大致相仿，且對於中文的本地化支援的非常好。
Hacker Laws
地址：https：//github。com/dwmkerr/hacker-laws
我們常常會說「xx法則」、「xx定律」，如「摩爾定律」等。在 Hacker Laws 這個倉庫中，我們可以找到在開發者群體比較有名或者是比較常見的法則和定律。但要注意：這個資源庫包含了對一些法則、原則和模式的解釋，
但並不提倡任何一種
。它們是否應該被應用在很大程度上取決於你正在做的事情，要根據情況來判斷使用與否。
工具推薦
整理編輯：zhangferry
regex101
地址
：https：//regex101。com
一個正則表示式測試和分析網站，不僅可以將匹配結果進行輸出，還會逐個分析表示式的含義。我們以摸魚週報的文案進行測試，我們想匹配出 “iOS 摸魚週報”（中間有空格），“iOS成長之路”，這兩個字串。文案特徵為：”iOS“開頭，不能緊跟其他字母，以逗號結尾但不包括逗號。測試結果如下：
觀察右側結果分析，示例中使用的 非貪婪模式和 零寬度正預測先行斷言，都有很詳細的講解。這對於我們理解他人寫的正則表示式能起到很好的幫助作用。
關於我們
iOS 摸魚週報，主要分享開發過程中遇到的經驗教訓、優質的部落格、高質量的學習資料、實用的開發工具等。週報倉庫在這裡：https：//github。com/zhangferry/iOSWeeklyLearning ，如果你有好的的內容推薦可以透過 issue 的方式進行提交。另外也可以申請成為我們的常駐編輯，一起維護這份週報。另可關注公眾號：iOS成長之路，後臺點選進群交流，聯絡我們，獲取更多內容。
參考資料
［2］
iOS效能最佳化之耗電檢測：https：//www。diffit。cn/2020/09/03/EnergyDetection/
［3］
Analyzing Your App‘s Battery Use：https：//developer。apple。com/documentation/xcode/analyzing-your-app-s-battery-use
［5］
iOS進階——App功耗最佳化：http：//www。cocoachina。com/articles/21428
［6］
iOS耗電量和效能最佳化的全新框架：https：//punmy。cn/2019/06/16/wwdc_417_metrics。html
［7］
耗電最佳化的幾點建議：https：//lizhaobomb。github。io/2020/03/02/iOS%E6%80%A7%E8%83%BD%E4%BC%98%E5%8C%9606%20-%20%E8%80%97%E7%94%B5%E4%BC%98%E5%8C%96/
-End-
