通過遵循這些最佳實踐，你將很大程度上避免許多麻煩

避免內存泄漏的最佳實踐

• 避免大量的單例。具體來說，不要出現上帝對象(如職責特別多或狀態信息特別多的對 象)。這是一個反模式，指代一種常見解決方案的設計模式，但很快產生了不良效果。 日志器、埋點服務和任務隊列這樣的輔助單例都是很不錯的，但全局狀態對象不可取。
• 對子對象使用 __strong。
• 對父對象使用 __weak。
• 對使引用圖閉合的對象(如委托)使用 __weak。
• 對數值屬性(NSInteger、SEL、CGFloat 等)而言，使用 assign 限定符。
• 對于塊屬性，使用 copy 限定符。
• 當聲明使用NSError **參數的方法時，需要使用__autoreleasing，并要注意用正確的 語法:NSError * __autoreleasing *。
• 避免在塊內直接引用外部的變量。在塊外面將它們 weakify，并在塊內再將它們 strongify。
• 進行必要清理時遵循以下準則:
• 銷毀計時器
• 移除觀察者(具體來說，移除對通知的注冊)
• 解除回調(具體來說，將強引用的委托設置為 nil)

創建控制器時要遵循的最佳實踐

• 保持視圖控制器輕量。在 MVC 結構的應用中，控制器只是紐帶，而不是存放所有業務 邏輯的地方。它甚至不屬于模型。業務邏輯應該屬于服務層或業務邏輯組件。將它放在那里。通過被稱為行為委托或服務提供者的對象，視圖控制器應該將服務組件綁定至視圖，這 些行為委托或服務提供者的對象最好能被注入控制器
• 不要在視圖控制器中編寫動畫邏輯。動畫可以在獨立的動畫類中實現，該類接受視圖作 為參數傳入，這些視圖就是用來運行動畫的視圖。然后，視圖控制器會將動畫添加至視 圖或轉場效果上。 有特殊用途的視圖可以擁有自己的動畫。例如，一個自定義的微調控制器會有它自己的 動畫。
• 使用數據源和委托協議，將代碼按照數據檢索、數據更新和其他的業務邏輯進行分離。 視圖控制器只能用來選擇正確的視圖，并將它們連接到供應源。
• 視圖控制器響應來自視圖的事件，如按鈕點擊事件或列表單元格的選擇事件，然后將它 們連接至數據接收器。
• 視圖控制器響應來自操作系統的 UI 相關事件，如方向變化或低內存警告。這可能會觸 發視圖的重新布局。
• 不要編寫自定義的 init 代碼。 為什么呢?因為如果視圖控制器被重新切換至 XIB 或故 事板，那 init 方法永遠都不會被調用。
• 不要在視圖控制器中使用代碼手工布局 UI，也不要在視圖控制器中實現全部的 UI、視 圖創建和視圖布局邏輯等操作。使用 nibs 或者故事板。 手工布局代碼不會持續很久，因為應用在不斷增長，并且設計也在改變。在重新設計方 面，使用 Interface Builder 比根據像素坐標來手動編寫代碼更快。 此外，應用可能會在不同大小和形狀的設備上運行。要想適應所有的形狀，處理方向變化時的旋轉操作，以及與每兩三年就會變化的設計范例保持一致，通過擴展自定義代碼來實現是比較難做到的。同樣，如果某一設計被分在獨立的 nibs 和故事板，你就可以比較靈活地運行 A/B 測試， 因為在不同的約束之間很容易選擇最終需要的。
• 比較好的方式是，創建一個實現了公共設置的基類視圖控制器，其他視圖控制器從這里 繼承就好。
  這種技術并非一直可用，因為有時可能需要在應用的不同部分繼承不同的視圖控制器。 例如，在聯系人列表中應該使用 UITableViewController，在用戶配置文件中應該選擇 UIViewController。
  但是，如果有多個地方都需要在 UIWebView 中展示內容，那基類視圖控制器會是一個不 錯的選擇。如果需要顯示含有隱私策略的 URL 或條款和條件頁面，那么你是沒必要繼 承的。但是，如果需要顯示用戶分享的圖片或者視頻(在信息應用中)，你可以創建子 類，在子類中實現自定義瀏覽器或對重寫的東西進行控制。
• 在各視圖控制器之間，使用 category 創建可復用的代碼。如果父視圖控制器不能滿足 使用(例如，在應用中需要不同種類的視圖控制器)，那就創建 category，并在 category 中加上自定義的方法或屬性。 如此一來，你就不會被限制只能使用預定義的基類，同時還能得到復用帶來的好處。

高效使用viewController的生命周期

• 無需多說，不要重寫 loadView。
• 將 viewDidLoad 作為最后的檢查點，查看來自數據源的數據是否可用。如果可用，則更
  新 UI 元素。如果每次都需要展示最新的信息，那么就使用 viewWillAppear: 更新 UI 元素。
  例如，在某一個消息應用中，如果在聊天會話中觀看完共享視頻后返回信息列表，那么用戶必然希望看到最新的信息。但在新聞應用中，你可能不希望立即刷新列表，以免用戶找不到上下文。在后一種情況 下，列表視圖控制器一般會監聽來自數據源的事件，同時，應盡量精準、盡量少地更新 文章列表。
• 在 viewDidAppear: 中開始動畫。如果有視頻等流式內容，那么就可以開始播放了。訂 閱應用事件來檢測動畫 / 視頻或其他持續更新視頻的處理是應該繼續還是停止。 不推薦在該方法中用最新的數據更新 UI。如果你這樣做了，最終的效果是，在過渡動 畫完成之后，用戶會過渡至舊的 UI，然后產生更新。這個體驗不是很友好。話雖如此，但在一些使用案例中，你不得不在 viewDidAppear: 中執行 UI 更新。如果用 戶體驗尚可接受，那就勉強這樣吧。
• 使用 viewWillDisappear: 來暫停或停止動畫。同樣，不要做其他多余的操作。
• 使用 viewDidDisappear:銷毀內存中的復雜數據結構。也可以在這里注銷與視圖控制器綁定的數據源通知，以及與動畫、數據源、UI 更新有 關的應用事件通知中心。
• 如果其他措施都不能優化載入時間，那么你可以在應用中增加一個精巧的動 畫。如此一來，你將會有數十秒的額外時間來完成任務，讓用戶在使用應用 時不會有明顯的延遲。需要注意的是，長時間的動畫會惹惱用戶，可能導致 用戶流失。這應該作為最后的方案，需要慎用。

參考文獻：“High Performance iOS Apps by Gaurav Vaish (O’Reilly). Copyright 2016 Gaurav Vaish, 978-1-491-91100-6.”