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)出了所有字符串符號(hào)，因此可以很簡(jiǎn)單的比較和檢測(cè)當(dāng)前的網(wǎng)絡(luò)信息。

Core Foundation 和 Autorelease

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

CFTypeRef CFAutorelease(CFTypeRef CF_RELEASES_ARGUMENT arg)

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

圖片解壓縮

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

iOS7 開(kāi)始，你可以使用kCGImageSourceShouldCacheImmediately:來(lái)強(qiáng)制圖片在創(chuàng)建時(shí)立即解壓縮：

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

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

盜版檢查

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

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

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

Refresh the Receipt

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

[request setDelegate:self];

[request start];

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

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

Comic Sans MS

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

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