最新版本SDK優化了開發體驗，編譯過程會提供更多提示警告，建議你修改。這些功能也可以自主選擇用或者不用，當然，蘋果喜歡你用他推薦的東西。。。
1 . @avalibale 語法，同步判斷當前iOS系統是否滿足需求。例如：
if (@available(iOS 11, *)) { // >= 11 DLog(@"XXX1"); } else if (@available(iOS 10, *)) { //>= 10 DLog(@"XXX2"); } else { // < 10 DLog(@"XXX3"); }
（2）聲明或者引用一些api需要在指定iOS版本才起作用會有warning,這個時候 可以用1 去做判斷。參考代碼：
1.2 如果是對方法的聲明 添加API_AVAILABLE(ios(11)) ，就不用再方法里面做系統版本判斷了，錯用會有警告提示。
例如：
（2）如果在類之前聲明 API_AVAILABLE(ios(11)) 就是對該類添加了系統版本約束。
（3) 針對runtime 或者 c/c++ 方法中里面,也有對應判斷系統版本方法，相似 @avalibale 語法
__builtin_available 去判斷
對類的約束：
（4）蘋果鼓勵你升級Xcode 使用最新sdk 和操作以上方法，但是也不妨礙回歸老版本sdk，這時候@available方法在
編譯時候 ,會被忽略不做警告提示。
但個人認為，已經做版本判斷了的話，還是要注意業務邏輯的。這個功能也是可選的使用下圖。當然蘋果鼓勵你
操作最新語法 去運用到項目中來。
2 . analyze
2.1 使用該分析功能 會幫你提示 類型錯誤提示。舉例參考2.2.1 NSNumber類型和數字類型比大小，這個會出問題 。 當 photoCount沒賦值就是nil 會返回 NO, 如果有值 都會返回YES。這可不是一個正常的比大小的邏輯 亂套了，要知道的是 類型使用錯誤通常的直接反應就是崩潰，這類問題還是很嚴重的。
（1）錯誤類型比大小
（2) analyze 提示出錯
（3）修正錯誤
（4) 這個這個也是選擇使用的方法參考下面圖片
2.2 聲明單利，會遇到的問題
(1)只能有一個實例
(2)dispatch_once 使用謂詞 一定是靜態 或者全局來進行必要修飾 。
解決使用錯誤 給的例 是使用 NSLock 同步鎖 。
(3)資源競爭造成的死方式鎖，數據讀取或者存儲都不正常
2.3 不要使用copy 修飾可變類型 比如可變數組可變字典等
(1) 如下圖會出現什么問題？？
(2) 用copy修飾可變類型，會導致可變類型 變成普通類型，這樣可變數組變成不可變數組了，再動態添加元素,就會崩潰
因為動態添加元素根本不是 NSArray 里面的方法。。。
（3）analyze 幫助我們提示這種 應該修改的錯誤
（4）還可以選擇 在編譯過程順便 analyze這個我真是 之前都是想起來analyze ,現在build 就可以，這樣更方便我們查找
潛在問題。
3 .
（1）引用已經釋放的對象（野指針 崩潰）會 做提示。 下面代碼有什么問題？
分析：enumerateKeysAndObjectsUsingBlock: 循環體相當於一個自動釋放內存池，用過即廢掉，
所以外部再引用NSError要展示信息的話 一定會崩潰的發生野指針錯誤。
（2）兩種解決方案
a.
b.
詳細解釋： 取地址符號的error寫法是要滲透到方法里面可以被修改的變量對象。 這就說明，方法對error來說
就是強引用，如果在方法里被銷毀，外邊不引用了還好，如果繼續引用error就會報野指針錯誤而崩潰。
模擬銷毀不是在方法內置error為nil而是放到自動釋放內存池里面，自己也可以模擬出這種情況。這就進一步驗證了
關於字典的快速遍歷的循環體是即時銷毀的。因此，如果需要繼續使用error一定要處理成強引用寫法。
測試模擬：
銷毀模擬 ：
(3) 舉例說類似C語言，如果聲明方法不指定類型雖然可以編譯通過，但是現在可以報警告，防止未來不明確調用
會出問題:“not type safe” 類型不安全。
改了警告說的 類型不安全問題，濫用錯誤引用就會報錯：
（4）同理：閉包函數也是一樣的：
改后，如果濫用就報錯
（5）這個也是在build時候檢查， 也可以選擇使用該項檢查，參考配置
4 . C++ 的開發體驗 優化與支持 略 （目前還沒這個經驗。。。）
參考：
（1）https://developer.apple.com/videos/play/wwdc2017/411/