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

}];

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

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

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

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

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

Core Foundation 和 Autorelease

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

CFTypeRef CFAutorelease(CFTypeRef CF_RELEASES_ARGUMENT arg)

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

圖片解壓縮

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

iOS7 開始，你可以使用kCGImageSourceShouldCacheImmediately:來強(qiáng)制圖片在創(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;

}

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

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

盜版檢查

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

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

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

Refresh the Receipt

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

[request setDelegate:self];

[request start];

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

你絕對應(yīng)該讀讀蘋果的指南——驗(yàn)證 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 中，但當(dāng)時的字體列表很少也不見得多么有趣。在 iOS7 中蘋果添加了不少字體，包括“famous”，它和 PT Sans 或 Comic Sans MS 有些類似。kCTFontDownloadableAttribute并沒有在 iOS6 中聲明，所以 iOS7 以前它并不真正可用，但蘋果確是在 iOS6 的時候就已經(jīng)做了私有聲明了。

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