iOS 7: 隱藏的特性和解決之道

}];

當手機從edge環(huán)境到3G，log輸出應該像這樣：

iOS7Tests[612:60b] Current Radio Access Technology: CTRadioAccessTechnologyEdge

iOS7Tests[612:1803] New Radio Access Technology: (null)

iOS7Tests[612:1803] New Radio Access Technology: CTRadioAccessTechnologyHSDPA

蘋果導出了所有字符串符號，因此可以很簡單的比較和檢測當前的網(wǎng)絡(luò)信息。

Core Foundation 和 Autorelease

Core Foundation中出現(xiàn)了一個新的方法，它被用于私有調(diào)用已有數(shù)年時間：

CFTypeRef CFAutorelease(CFTypeRef CF_RELEASES_ARGUMENT arg)

它確實做了你所期望的事，讓人費解的是蘋果花了這么長時間才把它公開。ARC 下，大多數(shù)人在處理返回 Core Foundation 對象時是通過轉(zhuǎn)換成對等的 NS 對象來完成的，如 NSDictionary,即便它只是一個 CFDictionaryRef 然后簡單地 CFBridgingRelease() 。這樣通常沒問題，除非你返回的對等 NS 對象不可用時，如 CFBagRef。你要么使用 id，這樣會失去類型安全性，要么你將你的方法重命名為 createMethod 并考慮所有的內(nèi)存語義，最后使用 CFRelease。還有一些手段，比如這個，用 non-ARC-file 標簽然后編譯，但終歸得使用CFAutorelease()。另外：不要編寫使用蘋果公司命名空間的代碼，所有這些自定義的 CF-宏將來都會被打破的。

圖片解壓縮

當通過 UIImage 展示一張圖時，在顯示之前需要解壓縮(除非源已經(jīng)像素緩存了)。對于 JPG/PNG 文件這會占用相當可觀的時間并會造成卡頓。iOS6 以前，通常是創(chuàng)建一個位圖上下文，然后在其中畫圖來解決。(參見 AFNetworking 如何處理)。

iOS7 開始，你可以使用kCGImageSourceShouldCacheImmediately:來強制圖片在創(chuàng)建時立即解壓縮：

(UIImage *)decompressedImageWithData:(NSData *)data

{

CGImageSourceRef source = CGImageSourceCreateWithData((__bridge CFDataRef)data, NULL);

CGImageRef cgImage = CGImageSourceCreateImageAtIndex(source, 0, (__bridge CFDictionaryRef)@{(id)kCGImageSourceShouldCacheImmediately: @YES});

UIImage *image = [UIImage imageWithCGImage:cgImage];

CGImageRelease(cgImage);

CFRelease(source);

return image;

}

當我剛發(fā)現(xiàn)這一點時確實很興奮，但事實并非如此。在我的測試中，發(fā)現(xiàn)當開啟了即時緩存后性能有明顯的降低。要么這個方法是在主線程中調(diào)用的(不太可能)，感覺上性能更糟，因為它在方法copyImageBlockSetJPEG中鎖住了，而同時在主線程中在顯示非加密的圖片所致。在我的程序中，我在主線程中加載小的預覽圖，在后臺線程中加載大型圖，使用了kCGImageSourceShouldCacheImmediately后小小的解壓縮阻塞了主線程，同時在后臺處理大量開銷昂貴的操作。

還有更多關(guān)于圖片解壓縮相關(guān)的卻不是 iOS7 中的新東西，像kCGImageSourceShouldCache，它用來控制系統(tǒng)自動卸載解壓縮的圖片數(shù)據(jù)的能力。確保你將它設(shè)置為YES，否則所有的工作都將沒有意義。有趣的是，蘋果在64bit運行時的系統(tǒng)中將kCGImageSourceShouldCache的默認值從 NO 改為了 YES。

盜版檢查

蘋果添加了一個方式，通過 NSBunble 上的新方法appStoreReceiptURL來評估Lion系統(tǒng)上 App Store 的收據(jù)，同時也將其移植到了 iOS 上。這使得你可以檢查你的應用是在被合法購買或者已經(jīng)被破解了。檢查收據(jù)還有一個重要的原因，它包含了初始購買日期，這點對于把你的應用從付費模型遷移到免費+應用內(nèi)付費方式很有幫助意義。你可以根據(jù)這個初始購買日期來決定額外內(nèi)容對于你的用戶是免費的還是收費的。

收據(jù)還允許你檢查應用程序是否通過批量購買計劃購買以及該許可證是否仍有效，有一個名為SKReceiptPropertyIsVolumePurchase的屬性顯示了該值。

當你調(diào)用appStoreReceiptURL時，你需要特別注意，因為在 iOS6 上，它還是一個私有API，你應該在用戶代碼中先調(diào)用doesNotRecognizeSelector:，在調(diào)用前檢查運行(基礎(chǔ))版本。在開發(fā)期間，這個方法返回的 URL 不會是指向一個文件。你可能需要使用 StoreKit 的SKReceiptRefreshRequest，這也是 iOS7 中的新東西，用它來下載證書。使用一個至少購買過一次的測試用戶，否則它將沒法工作：

Refresh the Receipt

SKReceiptRefreshRequest *request = [[SKReceiptRefreshRequest alloc] init];

[request setDelegate:self];

[request start];

驗證收據(jù)需要大量的代碼。你需要使用OpenSSL和內(nèi)嵌的蘋果根證書，并且你還要了解一些基本的東西像是證書、PCKS容器以及ASN.1。這里有一些樣例代碼，但是你不應該讓它這么簡單——別只是拷貝現(xiàn)有的驗證方法，至少做點修改或者編寫你自己的，你應該不希望一個普通的補丁程序就能在數(shù)秒內(nèi)瓦解你的努力吧。

你絕對應該讀讀蘋果的指南——驗證 Mac App 商店收據(jù)，這里面的大多數(shù)都適用于 iOS。蘋果在 WWDC2013 的 Session308 “Using Receipts to Protect Your Digital Sales” 中詳述了“Grand Unified Receipt”的變動。

Comic Sans MS

iOS7 中，終于迎回了 Comic Sans MS?，F(xiàn)在，它以可下載的字體被添加到 iOS6 中，但當時的字體列表很少也不見得多么有趣。在 iOS7 中蘋果添加了不少字體，包括“famous”，它和 PT Sans 或 Comic Sans MS 有些類似。kCTFontDownloadableAttribute并沒有在 iOS6 中聲明，所以 iOS7 以前它并不真正可用，但蘋果確是在 iOS6 的時候就已經(jīng)做了私有聲明了。

字體列表是動態(tài)變化的，以后可能就會發(fā)生變動。蘋果在 Tech Note HT5484 中羅列了一些可用的字體，但這個文檔已經(jīng)過時了，同時也不能反映 iOS7 的變化。