在我上一篇文章中，我強(qiáng)調(diào)了一些在iOS 10推出的開發(fā)者可以利用的新功能。將版本沖刺到最新和最好的是很有趣，然而你也需要確保你的應(yīng)用程序是全線更新的。這意味著需要檢查任何過時(shí)的方法或類，并驗(yàn)證仍在運(yùn)行iOS現(xiàn)有版本的用戶被繼續(xù)維護(hù)。

在你翻看所有的更新記錄之前（如果今晚你無法入睡，這是我強(qiáng)烈建議的），有幾件事情你可以做，以確保你的應(yīng)用程序準(zhǔn)備好過渡到iOS 10。

小故事：很多年前，在一個(gè)遙遠(yuǎn)的星系，我以在幾十萬的月活躍用戶附近的東西創(chuàng)建一個(gè)iOS應(yīng)用程序。我建立、測(cè)試和部署最新iOS 5支持的更新。我和一些同事慶祝其發(fā)布，但幾小時(shí)內(nèi)，我從Apteligent得到事故通知。原來，我用了一個(gè)只適用于iOS 5的方法，沒有妥善處理，于是，由于我的用戶群中30%的人使用iOS 4或更早版本，應(yīng)用程序崩潰了。哎！不用說，我的測(cè)試變得更加嚴(yán)格，（注意：無恥的插在前面）我很高興我安裝的Apteligent快速提醒了我，但這是一個(gè)慘痛的教訓(xùn)。不要讓這種事發(fā)生在你的身上！

API的可用性檢查

當(dāng)在iOS 10中構(gòu)建新的API時(shí)，你能夠確保你的應(yīng)用程序仍然可以在舊版本上運(yùn)行的最好的辦法就是做運(yùn)行時(shí)API檢查。這將確保你將要在當(dāng)前運(yùn)行的設(shè)備上調(diào)用的類或方法。如果你想在iOS 9中調(diào)用iOS 10的方法，你會(huì)遇到麻煩（見以上我的傷心故事）。

對(duì)于類，這是一個(gè)簡(jiǎn)單的檢查，看起來就像這樣：

if(NSClassFromString(@"MSMessage")) {
    // This class is available, go ahead and do something with it
} else {
    // This class is not available, handle it appropriately
}

或者，如果你更喜歡Swift：

if #available(iOS 10.0, *) {
  let message = MSMessage()
} else {
    // This class is not available, handle it appropriately
}

如果類（MSMessage）是弱聯(lián)系，block 外部的MSMessage引用在前iOS 10設(shè)備上不會(huì)導(dǎo)致你的應(yīng)用程序立即崩潰。這使得錯(cuò)誤更難找到，并會(huì)讓測(cè)試忽略更多的問題。即使你避免了崩潰，你的用戶體驗(yàn)也會(huì)迅速降低，因?yàn)槟愕拇a不能識(shí)別MSMessage功能的缺失。這使得實(shí)施新的功能時(shí)，處理前、后iOS 10的情況變得非常重要。

對(duì)于現(xiàn)有的類的新方法，有另一個(gè)簡(jiǎn)單的檢查：

// Check if new API is available
if ([existingClassObject respondsToSelector:@selector(newMethod:)]){
    // Yes, we can safely call this method
    [existingClassObject newMethod:@”something”];
} else {
    // The new method is not available, handle accordingly
}

在Swift中，你可以使用上述相同的#available方法，如果你知道你的方法需要的SDK，這會(huì)特別有用。否則，你可以使用以下所顯示的等效方法調(diào)用：

// Check if new API is available
if existingClassObject.respondsToSelector(Selector(“newMethod”)){
    // Yes, we can safely call this method
    existingClassObject.newMethod()
} else {
    // The new method is not available, handle accordingly
}

我們首先檢查看看如果我們調(diào)用它，該方法是否會(huì)響應(yīng)，如果響應(yīng)，我們就繼續(xù)并且安全地調(diào)用它。這個(gè)簡(jiǎn)單的條件也在iOS 9中處理的事件，其中該方法將不響應(yīng)，在iOS 10中，該方法可以被調(diào)用。

如果你試圖在iOS一個(gè)不受支持的版本中調(diào)用newMethod ，你的應(yīng)用程序會(huì)由于NSInvalidArgumentException而崩潰。這是一個(gè)關(guān)于iOS最常見的事故，它可以用這種簡(jiǎn)單的檢查來避免。

關(guān)于宏的一個(gè)注記

宏是由編譯器執(zhí)行的代碼位。通過iOS系統(tǒng)，你可以使用這樣的東西：

#if __IPHONE_OS_VERSION_MIN_REQUIRED >= __IPHONE_10_0 
    // iOS 10+ code 
#endif

許多開發(fā)者看到了這一點(diǎn)，把它添加到他們的代碼卻沒有完全理解發(fā)生了什么，但這不應(yīng)該被用來確保用戶在iOS 10。這就是為什么：

么，但這不應(yīng)該被用來確保用戶在iOS 10。這就是為什么： 如果應(yīng)用程序的部署目標(biāo)（deployment target）是大于或等于iOS 10，block內(nèi)的代碼只會(huì)被編譯。更有可能的是，你的應(yīng)用程序的部署目標(biāo)是低于目前的SDK。例如，你的部署目標(biāo)可低至iOS 8，因?yàn)槟闳匀灰С脂F(xiàn)有的用戶。

如果你使用iOS 8以上支持的宏，由于宏在編譯時(shí)執(zhí)行的所有用戶，block內(nèi)的代碼將被省略。你不會(huì)看到任何警告或得到任何錯(cuò)誤提示，你的代碼將不會(huì)被包含在你的應(yīng)用程序中！

為了管理的棄用和新的API，最好在運(yùn)行時(shí)做代碼檢查以容納你的應(yīng)用程序支持的所有的操作系統(tǒng)版本和設(shè)備。

注意Deprecation警告

在一點(diǎn)或另一個(gè)上，每個(gè)開發(fā)者都沿著“別擔(dān)心，我后面會(huì)處理”的套路在走。你可能已經(jīng)在Xcode看到deprecation警告，讓開發(fā)商知道方法或類找到了出路。在某個(gè)點(diǎn)上的代碼將被刪除；如果它試圖在一個(gè)新的操作系統(tǒng)上引用被刪除的方法，你的應(yīng)用程序?qū)⒈罎ⅰ?/p>

一般來說，這不是一個(gè)短期的過程。蘋果通常會(huì)用“過時(shí)的”類或方法發(fā)布很多大的操作系統(tǒng)，在它實(shí)際上被刪除之前，這給了開發(fā)者時(shí)間來適當(dāng)?shù)馗滤麄兊拇a。無論如何，時(shí)間終于來了，所以它是你的雷達(dá)上應(yīng)保留的東西。

在iOS 10有極少數(shù)的類/方法移除，這意味著對(duì)大多數(shù)開發(fā)者而言這些都不是問題，但是要檢查更新記錄，以及關(guān)注你的編譯器警告以防萬一。

測(cè)試所有支持的iOS版本

在一天結(jié)束時(shí)，它將是適當(dāng)?shù)臏y(cè)試，以驗(yàn)證你的應(yīng)用程序可以在你支持的所有的設(shè)備和操作系統(tǒng)上運(yùn)行。不要落入“它能在我的設(shè)備上運(yùn)行，所以它是沒問題的”的陷阱中。不幸的是，即使是最好的測(cè)試也不能抓住一切，于是Apteligent來了。我們的SDK允許你在你的應(yīng)用程序上監(jiān)控崩潰和性能問題，快速追蹤測(cè)試忽略的錯(cuò)誤。

完成

我強(qiáng)烈建議搶先安裝iOS的最新版本，這樣你的應(yīng)用程序就可以利用蘋果所提供的最新的功能。只要確保你沒有忽視其余部分用戶群使用的應(yīng)用程序的穩(wěn)定性和性能。只需要一個(gè)失敗的發(fā)布就可能減少你辛辛苦苦賺來的五星評(píng)級(jí)，所以請(qǐng)徹底的測(cè)試、測(cè)試、測(cè)試。

遵循這些準(zhǔn)則，你的應(yīng)用程序都將在今年秋季iOS 10正式啟動(dòng)時(shí)被設(shè)置完成。

本文翻譯自：

PS: 關(guān)于移動(dòng)開發(fā)，這些產(chǎn)品你可以關(guān)注>>

關(guān)于移動(dòng)開發(fā)的最新資訊和產(chǎn)品推薦，請(qǐng)<>!