好的代碼有一些特性：簡(jiǎn)明，自我解釋?zhuān)瑑?yōu)秀的組織，良好的文檔，良好的命名，優(yōu)秀的設(shè)計(jì)以及可以被久經(jīng)考驗(yàn)。
本文參考若干優(yōu)秀的Object-C編程規(guī)范文檔。寫(xiě)作目的亦在多人開(kāi)發(fā)時(shí)，統(tǒng)一代碼風(fēng)格與命名方式的規(guī)范。并以減少錯(cuò)誤的產(chǎn)生，提高性能，降低維護(hù)成本。
蘋(píng)果命名約定應(yīng)堅(jiān)持盡可能遵守,特別是那些涉及到內(nèi)存管理規(guī)則的地方.盡量使用描述方法和變量名的方式
應(yīng)該是:
UIButton *settingsButton;
而非:
UIButton *setBut;
駝峰法命令,且為了代碼清晰.應(yīng)以相關(guān)類(lèi)名作為前綴
推薦:
static const NSTimeInterval ZOCSignInViewControllerFadeOutAnimationDuration= 0.4;
而非:
static const NSTimeInterval fadeOutTime = 0.4
推薦使用常量來(lái)代替字符串字面值和數(shù)字，這樣能夠方便復(fù)用，而且可以快速修改而不需要查找和替換。常量應(yīng)該用static聲明為靜態(tài)常量，而不要用#define，除非它明確的作為一個(gè)宏來(lái)使用。
推薦:
static NSString * const ZOCCacheControllerDidClearCacheNotification= @"ZOCCacheControllerDidClearCacheNotification";
static const CGFloat ZOCImageThumbnailHeight =50.0f;
不推薦:
#define CompanyName @"Apple Inc."
#define magicNumber 42
常量應(yīng)該在頭文件中以這樣的形式暴露給外部：
extern NSString *const ZOCCacheControllerDidClearCacheNotification;
并在實(shí)現(xiàn)文件中為它賦值。
只有公有的常量才需要添加命名空間作為前綴。盡管實(shí)現(xiàn)文件中私有常量的命名可以遵循另外一種模式，你仍舊可以遵循這個(gè)規(guī)則。
方法名與方法類(lèi)型(-/+符號(hào))之間應(yīng)該以空格間隔。方法段之間也應(yīng)該以空格間隔（以符合Apple風(fēng)格）。參數(shù)前應(yīng)該總是有一個(gè)描述性的關(guān)鍵詞。
盡可能少用"and"這個(gè)詞。它不應(yīng)該用來(lái)闡明有多個(gè)參數(shù)，比如下面的initWithWidth:height:這個(gè)例子：
推薦:
- (void)setExampleText:(NSString*)textimage:(UIImage *)image;
- (void)sendAction:(SEL)aSelector?to:(id)anObject forAllCells:(BOOL)flag;
- (id)viewWithTag:(NSInteger)tag;
- (instancetype)initWithWidth:(CGFloat)width?height:(CGFloat)height;
不推薦:
- (void)setT:(NSString*)texti:(UIImage *)image;
- (void)sendAction:(SEL)aSelector?:(id)anObject :(BOOL)flag;
- (id)taggedView:(NSInteger)tag;
- (instancetype)initWithWidth:(CGFloat)width?andHeight:(CGFloat)height;
- (instancetype)initWith:(int)width?and:(int)height; // Never?do this.
（4）字面值
使用字面值來(lái)創(chuàng)建不可變的NSString,NSDictionary,NSArray,和NSNumber對(duì)象。注意不要將nil傳進(jìn)NSArray和NSDictionary里，因?yàn)檫@樣會(huì)導(dǎo)致崩潰。
例子：
NSArray*names = @[@"Brian",@"Matt",@"Chris",@"Alex",@"Steve",@"Paul"];
NSDictionary*productManagers = @{@"iPhone":@"Kate",@"iPad":@"Kamal",@"Mobile Web":@"Bill"};
NSNumber*shouldUseLiterals = @YES;
NSNumber*buildingZIPCode = @10018;
不要這樣:
NSArray*names = [NSArrayarrayWithObjects:@"Brian",@"Matt",@"Chris",@"Alex",@"Steve",@"Paul",nil];
NSDictionary*productManagers = [NSDictionarydictionaryWithObjectsAndKeys:@"Kate",@"iPhone",@"Kamal",@"iPad",@"Bill",@"Mobile Web",nil];
NSNumber*shouldUseLiterals = [NSNumbernumberWithBool:YES];
NSNumber*buildingZIPCode = [NSNumbernumberWithInteger:10018];
如果要用到這些類(lèi)的可變副本，我們推薦使用NSMutableArray,NSMutableString這樣的類(lèi)。
應(yīng)該避免下面這樣:
NSMutableArray*aMutableArray = [@[]mutableCopy];
上面這種書(shū)寫(xiě)方式的效率和可讀性的都存在問(wèn)題。
效率方面，一個(gè)不必要的不可變對(duì)象被創(chuàng)建后立馬被廢棄了；雖然這并不會(huì)讓你的App變慢（除非這個(gè)方法被頻繁調(diào)用），但是確實(shí)沒(méi)必要為了少打幾個(gè)字而這樣做。
可讀性方面，存在兩個(gè)問(wèn)題：第一個(gè)問(wèn)題是當(dāng)你瀏覽代碼并看見(jiàn)@[]的時(shí)候，你首先聯(lián)想到的是NSArray實(shí)例，但是在這種情形下你需要停下來(lái)深思熟慮的檢查；另一個(gè)問(wèn)題是，一些新手以他的水平看到你的代碼后可能會(huì)對(duì)這是一個(gè)可變對(duì)象還是一個(gè)不可變對(duì)象產(chǎn)生分歧。他/她可能不熟悉可變拷貝構(gòu)造的含義（這并不是說(shuō)這個(gè)知識(shí)不重要）。當(dāng)然，不存在絕對(duì)的錯(cuò)誤，我們只是討論代碼的可用性（包括可讀性）。
類(lèi)名應(yīng)該以三個(gè)大寫(xiě)字母作為前綴（雙字母前綴為Apple的類(lèi)預(yù)留）。盡管這個(gè)規(guī)范看起來(lái)有些古怪，但是這樣做可以減少Objective-C沒(méi)有命名空間所帶來(lái)的問(wèn)題。
屬性應(yīng)該盡可能描述性地命名，避免縮寫(xiě)，并且是小寫(xiě)字母開(kāi)頭的駝峰命名。我們的工具可以很方便地幫我們自動(dòng)補(bǔ)全所有東西（嗯。。幾乎所有的，Xcode的Derived
Data會(huì)索引這些命名）。所以沒(méi)理由少打幾個(gè)字符了，并且最好盡可能在你源碼里表達(dá)更多東西。
例子:
NSString*text;
不要這樣:
NSString* text;
（注意：這個(gè)習(xí)慣和常量不同，這是主要從常用和可讀性考慮。C++的開(kāi)發(fā)者偏好從變量名中分離類(lèi)型，作為類(lèi)型它應(yīng)該是NSString*（對(duì)于從堆中分配的對(duì)象，對(duì)于C++是能從棧上分配的）格式。）
你應(yīng)該總是使用setter和getter方法訪(fǎng)問(wèn)屬性，除了init和dealloc方法。通常，使用屬性讓你增加了在當(dāng)前作用域之外的代碼塊的可能所以可能帶來(lái)更多副作用。
你總應(yīng)該用getter和setter，因?yàn)椋?/p>
使用setter會(huì)遵守定義的內(nèi)存管理語(yǔ)義(strong,weak,copyetc...)，這個(gè)在A(yíng)RC之前就是相關(guān)的內(nèi)容。舉個(gè)例子，copy屬性定義了每個(gè)時(shí)候你用setter并且傳送數(shù)據(jù)的時(shí)候，它會(huì)復(fù)制數(shù)據(jù)而不用額外的操作。
KVO通知(willChangeValueForKey,didChangeValueForKey)會(huì)被自動(dòng)執(zhí)行。
更容易debug：你可以設(shè)置一個(gè)斷點(diǎn)在屬性聲明上并且斷點(diǎn)會(huì)在每次getter / setter方法調(diào)用的時(shí)候執(zhí)行，或者你可以在自己的自定義setter/getter設(shè)置斷點(diǎn)。
允許在一個(gè)單獨(dú)的地方為設(shè)置值添加額外的邏輯。
你應(yīng)該傾向于用getter：
它是對(duì)未來(lái)的變化有擴(kuò)展能力的（比如，屬性是自動(dòng)生成的）。
它允許子類(lèi)化。
更簡(jiǎn)單的debug（比如，允許拿出一個(gè)斷點(diǎn)在getter方法里面，并且看誰(shuí)訪(fǎng)問(wèn)了特別的getter
它讓意圖更加清晰和明確：通過(guò)訪(fǎng)問(wèn)ivar_anIvar你可以明確的訪(fǎng)問(wèn)self->_anIvar.這可能導(dǎo)致問(wèn)題。在block里面訪(fǎng)問(wèn)ivar（你捕捉并且retain了self，即使你沒(méi)有明確的看到self關(guān)鍵詞）。
它自動(dòng)產(chǎn)生KVO通知。
Designated和Secondary初始化方法
一個(gè)類(lèi)應(yīng)該有且只有一個(gè)designated初始化方法，其他的初始化方法（Secondary）應(yīng)該調(diào)用這個(gè)designated的初始化方法
當(dāng)使用setter getter方法的時(shí)候盡量使用點(diǎn)符號(hào)。應(yīng)該總是用點(diǎn)符號(hào)來(lái)訪(fǎng)問(wèn)以及設(shè)置屬性。
例子:
view.backgroundColor = [UIColororangeColor];
[UIApplicationsharedApplication].delegate;
不要這樣:
[viewsetBackgroundColor:[UIColororangeColor]];
UIApplication.sharedApplication.delegate;
使用點(diǎn)符號(hào)會(huì)讓表達(dá)更加清晰并且?guī)椭鷧^(qū)分屬性訪(fǎng)問(wèn)和方法調(diào)用
4.懶加載（Lazy?Loading）
當(dāng)實(shí)例化一個(gè)對(duì)象需要耗費(fèi)很多資源，或者配置一次就要調(diào)用很多配置相關(guān)的方法而你又不想弄亂這些方法時(shí)，我們需要重寫(xiě)getter方法以延遲實(shí)例化，而不是在init方法里給對(duì)象分配內(nèi)存。通常這種操作使用下面這樣的模板：
- (NSDateFormatter*)dateFormatter {
if(!_dateFormatter) {
_dateFormatter = [[NSDateFormatteralloc]init];
NSLocale*enUSPOSIXLocale = [[NSLocalealloc]initWithLocaleIdentifier:@"en_US_POSIX"];
[_dateFormattersetLocale:enUSPOSIXLocale];
[_dateFormattersetDateFormat:@"yyyy-MM-dd'T'HH:mm:ss.SSS"];//毫秒是SSS，而非SSSSS
}
return_dateFormatter;
}
5.NSNotification（廣播）
當(dāng)你定義你自己的NSNotification的時(shí)候你應(yīng)該把你的通知的名字定義為一個(gè)字符串常量，就像你暴露給其他類(lèi)的其他字符串常量一樣。你應(yīng)該在公開(kāi)的接口文件中將其聲明為extern的，并且在對(duì)應(yīng)的實(shí)現(xiàn)文件里面定義。
因?yàn)槟阍陬^文件中暴露了符號(hào)，所以你應(yīng)該按照統(tǒng)一的命名空間前綴法則，用類(lèi)名前綴作為這個(gè)通知名字的前綴。
同時(shí)，用一個(gè)Did/Will這樣的動(dòng)詞以及用"Notifications"后綴來(lái)命名這個(gè)通知也是一個(gè)好的實(shí)踐。
// Foo.h
externNSString*constZOCFooDidBecomeBarNotification
// Foo.m
NSString*constZOCFooDidBecomeBarNotification =@"ZOCFooDidBecomeBarNotification";
隨著項(xiàng)目的不斷迭代更新，工程中引入的三方庫(kù)日益增多。如何管理已有三方庫(kù)，合理的引入新的第三方庫(kù)成為了一個(gè)新的問(wèn)題。如下將總結(jié)我們引入第三方庫(kù)的規(guī)范，并將持續(xù)更新。
1.所引入的第三方庫(kù)盡量選擇有人維護(hù)更新的。無(wú)人維護(hù)的庫(kù)并被證明存在已知缺陷或明顯落后于當(dāng)前版本環(huán)境的，請(qǐng)避免使用。
2.兼容性滿(mǎn)足當(dāng)前APP要求的。引用前請(qǐng)確認(rèn)該庫(kù)在所需要兼容的版本范圍內(nèi)良好的運(yùn)行。不會(huì)出現(xiàn)崩潰，或較大的外觀(guān)差異。
3.易于維護(hù)的，應(yīng)用廣泛的。最好是業(yè)內(nèi)特定功能的行業(yè)標(biāo)準(zhǔn)庫(kù)。冷門(mén)且復(fù)雜的三方庫(kù)會(huì)給項(xiàng)目帶來(lái)不可預(yù)估的風(fēng)險(xiǎn)。如需求變更，或出現(xiàn)崩潰問(wèn)題時(shí)將很難修改，也無(wú)法找到有價(jià)值的參考資料。
4.一致性。同一功能的第三方庫(kù)在一個(gè)項(xiàng)目?jī)?nèi)只允許用使用一種。以減小維護(hù)成本，降低復(fù)雜度，統(tǒng)一標(biāo)準(zhǔn)。
5.關(guān)于拓展，當(dāng)三方庫(kù)不能滿(mǎn)足所需功能時(shí)，不要直接修改庫(kù)的代碼（雖然它是開(kāi)源的）。請(qǐng)建立新的子類(lèi)去繼承它或使用category。修改源碼會(huì)降低庫(kù)的復(fù)用性。
CPU資源消耗原因和解決方案
對(duì)象的創(chuàng)建會(huì)分配內(nèi)存、調(diào)整屬性、甚至還有讀取文件等操作，比較消耗CPU資源。盡量用輕量的對(duì)象代替重量的對(duì)象，可以對(duì)性能有所優(yōu)化。比如CALayer比UIView要輕量許多，那么不需要響應(yīng)觸摸事件的控件，用CALayer顯示會(huì)更加合適。如果對(duì)象不涉及UI操作，則盡量放到后臺(tái)線(xiàn)程去創(chuàng)建，但可惜的是包含有CALayer的控件，都只能在主線(xiàn)程創(chuàng)建和操作。通過(guò)Storyboard創(chuàng)建視圖對(duì)象時(shí)，其資源消耗會(huì)比直接通過(guò)代碼創(chuàng)建對(duì)象要大非常多，在性能敏感的界面里，Storyboard并不是一個(gè)好的技術(shù)選擇。
盡量推遲對(duì)象創(chuàng)建的時(shí)間，并把對(duì)象的創(chuàng)建分散到多個(gè)任務(wù)中去。盡管這實(shí)現(xiàn)起來(lái)比較麻煩，并且?guī)?lái)的優(yōu)勢(shì)并不多，但如果有能力做，還是要盡量嘗試一下（懶加載）。如果對(duì)象可以復(fù)用，并且復(fù)用的代價(jià)比釋放、創(chuàng)建新對(duì)象要小，那么這類(lèi)對(duì)象應(yīng)當(dāng)盡量放到一個(gè)緩存池里復(fù)用。
對(duì)象的調(diào)整也經(jīng)常是消耗CPU資源的地方。這里特別說(shuō)一下CALayer：CALayer內(nèi)部并沒(méi)有屬性，當(dāng)調(diào)用屬性方法時(shí)，它內(nèi)部是通過(guò)運(yùn)行時(shí)resolveInstanceMethod為對(duì)象臨時(shí)添加一個(gè)方法，并把對(duì)應(yīng)屬性值保存到內(nèi)部的一個(gè)Dictionary里，同時(shí)還會(huì)通知delegate、創(chuàng)建動(dòng)畫(huà)等等，非常消耗資源。UIView的關(guān)于顯示相關(guān)的屬性（比如frame/bounds/transform）等實(shí)際上都是CALayer屬性映射來(lái)的，所以對(duì)UIView的這些屬性進(jìn)行調(diào)整時(shí)，消耗的資源要遠(yuǎn)大于一般的屬性。對(duì)此你在應(yīng)用中，應(yīng)該盡量減少不必要的屬性修改。
當(dāng)視圖層次調(diào)整時(shí)，UIView、CALayer之間會(huì)出現(xiàn)很多方法調(diào)用與通知，所以在優(yōu)化性能時(shí)，應(yīng)該盡量避免調(diào)整視圖層次、添加和移除視圖。
對(duì)象的銷(xiāo)毀雖然消耗資源不多，但累積起來(lái)也是不容忽視的。通常當(dāng)容器類(lèi)持有大量對(duì)象時(shí)，其銷(xiāo)毀時(shí)的資源消耗就非常明顯。同樣的，如果對(duì)象可以放到后臺(tái)線(xiàn)程去釋放，那就挪到后臺(tái)線(xiàn)程去。這里有個(gè)小Tip：把對(duì)象捕獲到block中，然后扔到后臺(tái)隊(duì)列去隨便發(fā)送個(gè)消息以避免編譯器警告，就可以讓對(duì)象在后臺(tái)線(xiàn)程銷(xiāo)毀了。
NSArray *tmp=self.array;
self.array=nil;
dispatch_async(queue,^{
[tmpclass];
});
視圖布局的計(jì)算是App中最為常見(jiàn)的消耗CPU資源的地方。如果能在后臺(tái)線(xiàn)程提前計(jì)算好視圖布局、并且對(duì)視圖布局進(jìn)行緩存，那么這個(gè)地方基本就不會(huì)產(chǎn)生性能問(wèn)題了。
不論通過(guò)何種技術(shù)對(duì)視圖進(jìn)行布局，其最終都會(huì)落到對(duì)UIView.frame/bounds/center等屬性的調(diào)整上。上面也說(shuō)過(guò)，對(duì)這些屬性的調(diào)整非常消耗資源，所以盡量提前計(jì)算好布局，在需要時(shí)一次性調(diào)整好對(duì)應(yīng)屬性，而不要多次、頻繁的計(jì)算和調(diào)整這些屬性。
Autolayout是蘋(píng)果本身提倡的技術(shù)，在大部分情況下也能很好的提升開(kāi)發(fā)效率，但是Autolayout對(duì)于復(fù)雜視圖來(lái)說(shuō)常常會(huì)產(chǎn)生嚴(yán)重的性能問(wèn)題。隨著視圖數(shù)量的增長(zhǎng)，Autolayout帶來(lái)的CPU消耗會(huì)呈指數(shù)級(jí)上升。具體數(shù)據(jù)可以看這個(gè)文章：http://pilky.me/36/。如果你不想手動(dòng)調(diào)整frame等屬性，你可以用一些工具方法替代（比如常見(jiàn)的left/right/top/bottom/width/height快捷屬性），或者使用ComponentKit、AsyncDisplayKit等框架。
如果一個(gè)界面中包含大量文本（比如微博微信朋友圈等），文本的寬高計(jì)算會(huì)占用很大一部分資源，并且不可避免。如果你對(duì)文本顯示沒(méi)有特殊要求，可以參考下UILabel內(nèi)部的實(shí)現(xiàn)方式：用[NSAttributedString boundingRectWithSize:options:context:]來(lái)計(jì)算文本寬高，用-[NSAttributedString
drawWithRect:options:context:]來(lái)繪制文本。盡管這兩個(gè)方法性能不錯(cuò)，但仍舊需要放到后臺(tái)線(xiàn)程進(jìn)行以避免阻塞主線(xiàn)程。
如果你用CoreText繪制文本，那就可以先生成CoreText排版對(duì)象，然后自己計(jì)算了，并且CoreText對(duì)象還能保留以供稍后繪制使用。
屏幕上能看到的所有文本內(nèi)容控件，包括UIWebView，在底層都是通過(guò)CoreText排版、繪制為Bitmap顯示的。常見(jiàn)的文本控件（UILabel、UITextView等），其排版和繪制都是在主線(xiàn)程進(jìn)行的，當(dāng)顯示大量文本時(shí)，CPU的壓力會(huì)非常大。對(duì)此解決方案只有一個(gè)，那就是自定義文本控件，用TextKit或最底層的CoreText對(duì)文本異步繪制。盡管這實(shí)現(xiàn)起來(lái)非常麻煩，但其帶來(lái)的優(yōu)勢(shì)也非常大，CoreText對(duì)象創(chuàng)建好后，能直接獲取文本的寬高等信息，避免了多次計(jì)算（調(diào)整UILabel大小時(shí)算一遍、UILabel繪制時(shí)內(nèi)部再算一遍）；CoreText對(duì)象占用內(nèi)存較少，可以緩存下來(lái)以備稍后多次渲染。
當(dāng)你用UIImage或CGImageSource的那幾個(gè)方法創(chuàng)建圖片時(shí)，圖片數(shù)據(jù)并不會(huì)立刻解碼。圖片設(shè)置到UIImageView或者CALayer.contents中去，并且CALayer被提交到GPU前，CGImage中的數(shù)據(jù)才會(huì)得到解碼。這一步是發(fā)生在主線(xiàn)程的，并且不可避免。如果想要繞開(kāi)這個(gè)機(jī)制，常見(jiàn)的做法是在后臺(tái)線(xiàn)程先把圖片繪制到CGBitmapContext中，然后從Bitmap直接創(chuàng)建圖片。目前常見(jiàn)的網(wǎng)絡(luò)圖片庫(kù)都自帶這個(gè)功能。
（8）圖像的繪制
圖像的繪制通常是指用那些以CG開(kāi)頭的方法把圖像繪制到畫(huà)布中，然后從畫(huà)布創(chuàng)建圖片并顯示這樣一個(gè)過(guò)程。這個(gè)最常見(jiàn)的地方就是[UIView drawRect:]里面了。由于CoreGraphic方法通常都是線(xiàn)程安全的，所以圖像的繪制可以很容易的放到后臺(tái)線(xiàn)程進(jìn)行。一個(gè)簡(jiǎn)單異步繪制的過(guò)程大致如下（實(shí)際情況會(huì)比這個(gè)復(fù)雜得多，但原理基本一致）：
-(void)display{
dispatch_async(backgroundQueue,^{
CGContextRefctx=CGBitmapContextCreate(...);
// draw in context...
CGImageRefimg=CGBitmapContextCreateImage(ctx);
CFRelease(ctx);
dispatch_async(mainQueue,^{
layer.contents=img;
});
});
}
相對(duì)于CPU來(lái)說(shuō)，GPU能干的事情比較單一：接收提交的紋理（Texture）和頂點(diǎn)描述（三角形），應(yīng)用變換（transform）、混合并渲染，然后輸出到屏幕上。通常你所能看到的內(nèi)容，主要也就是紋理（圖片）和形狀（三角模擬的矢量圖形）兩類(lèi)。
所有的Bitmap，包括圖片、文本、柵格化的內(nèi)容，最終都要由內(nèi)存提交到顯存，綁定為GPU Texture。不論是提交到顯存的過(guò)程，還是GPU調(diào)整和渲染Texture的過(guò)程，都要消耗不少GPU資源。當(dāng)在較短時(shí)間顯示大量圖片時(shí)（比如TableView存在非常多的圖片并且快速滑動(dòng)時(shí)），CPU占用率很低，GPU占用非常高，界面仍然會(huì)掉幀。避免這種情況的方法只能是盡量減少在短時(shí)間內(nèi)大量圖片的顯示，盡可能將多張圖片合成為一張進(jìn)行顯示。
當(dāng)圖片過(guò)大，超過(guò)GPU的最大紋理尺寸時(shí)，圖片需要先由CPU進(jìn)行預(yù)處理，這對(duì)CPU和GPU都會(huì)帶來(lái)額外的資源消耗。目前來(lái)說(shuō)，iPhone 4S以上機(jī)型，紋理尺寸上限都是4096x4096，
當(dāng)多個(gè)視圖（或者說(shuō)CALayer）重疊在一起顯示時(shí)，GPU會(huì)首先把他們混合到一起。如果視圖結(jié)構(gòu)過(guò)于復(fù)雜，混合的過(guò)程也會(huì)消耗很多GPU資源。為了減輕這種情況的GPU消耗，應(yīng)用應(yīng)當(dāng)盡量減少視圖數(shù)量和層次，并在不透明的視圖里標(biāo)明opaque屬性以避免無(wú)用的Alpha通道合成。當(dāng)然，這也可以用上面的方法，把多個(gè)視圖預(yù)先渲染為一張圖片來(lái)顯示。
CALayer的border、圓角、陰影、遮罩（mask），CASharpLayer的矢量圖形顯示，通常會(huì)觸發(fā)離屏渲染（offscreen rendering），而離屏渲染通常發(fā)生在GPU中。當(dāng)一個(gè)列表視圖中出現(xiàn)大量圓角的CALayer，并且快速滑動(dòng)時(shí)，可以觀(guān)察到GPU資源已經(jīng)占滿(mǎn)，而CPU資源消耗很少。這時(shí)界面仍然能正?；瑒?dòng)，但平均幀數(shù)會(huì)降到很低。為了避免這種情況，可以嘗試開(kāi)啟CALayer.shouldRasterize屬性，但這會(huì)把原本離屏渲染的操作轉(zhuǎn)嫁到CPU上去。對(duì)于只需要圓角的某些場(chǎng)合，也可以用一張已經(jīng)繪制好的圓角圖片覆蓋到原本視圖上面來(lái)模擬相同的視覺(jué)效果。最徹底的解決辦法，就是把需要顯示的圖形在后臺(tái)線(xiàn)程繪制為圖片，避免使用圓角、陰影、遮罩等屬性。
