好的代碼有一些特性：簡明窍仰，自我解釋短条，優(yōu)秀的組織导匣，良好的文檔，良好的命名茸时，優(yōu)秀的設(shè)計(jì)以及可以被久經(jīng)考驗(yàn)贡定。
本文參考若干優(yōu)秀的Object-C編程規(guī)范文檔。寫作目的亦在多人開發(fā)時(shí)可都，統(tǒng)一代碼風(fēng)格與命名方式的規(guī)范缓待。并以減少錯(cuò)誤的產(chǎn)生，提高性能渠牲，降低維護(hù)成本旋炒。
蘋果命名約定應(yīng)堅(jiān)持盡可能遵守,特別是那些涉及到內(nèi)存管理規(guī)則的地方.盡量使用描述方法和變量名的方式
應(yīng)該是:
UIButton *settingsButton;
而非:
UIButton *setBut;
駝峰法命令,且為了代碼清晰.應(yīng)以相關(guān)類名作為前綴
推薦:
static const NSTimeInterval ZOCSignInViewControllerFadeOutAnimationDuration= 0.4;
而非:
static const NSTimeInterval fadeOutTime = 0.4
推薦使用常量來代替字符串字面值和數(shù)字，這樣能夠方便復(fù)用嘱兼，而且可以快速修改而不需要查找和替換国葬。常量應(yīng)該用static聲明為靜態(tài)常量，而不要用#define芹壕，除非它明確的作為一個(gè)宏來使用汇四。
推薦:
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ī)則。
方法名與方法類型(-/+符號(hào))之間應(yīng)該以空格間隔睁壁。方法段之間也應(yīng)該以空格間隔（以符合Apple風(fēng)格）背苦。參數(shù)前應(yīng)該總是有一個(gè)描述性的關(guān)鍵詞。
盡可能少用"and"這個(gè)詞潘明。它不應(yīng)該用來闡明有多個(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）字面值
使用字面值來創(chuàng)建不可變的NSString,NSDictionary,NSArray,和NSNumber對象。注意不要將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];
如果要用到這些類的可變副本，我們推薦使用NSMutableArray,NSMutableString這樣的類。
應(yīng)該避免下面這樣:
NSMutableArray*aMutableArray = [@[]mutableCopy];
上面這種書寫方式的效率和可讀性的都存在問題铲觉。
效率方面澈蝙，一個(gè)不必要的不可變對象被創(chuàng)建后立馬被廢棄了；雖然這并不會(huì)讓你的App變慢（除非這個(gè)方法被頻繁調(diào)用）撵幽，但是確實(shí)沒必要為了少打幾個(gè)字而這樣做灯荧。
可讀性方面，存在兩個(gè)問題：第一個(gè)問題是當(dāng)你瀏覽代碼并看見@[]的時(shí)候盐杂，你首先聯(lián)想到的是NSArray實(shí)例逗载，但是在這種情形下你需要停下來深思熟慮的檢查；另一個(gè)問題是况褪，一些新手以他的水平看到你的代碼后可能會(huì)對這是一個(gè)可變對象還是一個(gè)不可變對象產(chǎn)生分歧撕贞。他/她可能不熟悉可變拷貝構(gòu)造的含義（這并不是說這個(gè)知識(shí)不重要）。當(dāng)然测垛，不存在絕對的錯(cuò)誤捏膨，我們只是討論代碼的可用性（包括可讀性）。
類名應(yīng)該以三個(gè)大寫字母作為前綴（雙字母前綴為Apple的類預(yù)留）食侮。盡管這個(gè)規(guī)范看起來有些古怪号涯，但是這樣做可以減少Objective-C沒有命名空間所帶來的問題。
屬性應(yīng)該盡可能描述性地命名锯七，避免縮寫链快，并且是小寫字母開頭的駝峰命名。我們的工具可以很方便地幫我們自動(dòng)補(bǔ)全所有東西（嗯眉尸。域蜗。幾乎所有的，Xcode的Derived
Data會(huì)索引這些命名）噪猾。所以沒理由少打幾個(gè)字符了霉祸，并且最好盡可能在你源碼里表達(dá)更多東西。
例子:
NSString*text;
不要這樣:
NSString* text;
（注意：這個(gè)習(xí)慣和常量不同袱蜡，這是主要從常用和可讀性考慮丝蹭。C++的開發(fā)者偏好從變量名中分離類型陌僵，作為類型它應(yīng)該是NSString*（對于從堆中分配的對象淑际，對于C++是能從棧上分配的）格式。）
你應(yīng)該總是使用setter和getter方法訪問屬性炊昆，除了init和dealloc方法敏晤。通常贱田，使用屬性讓你增加了在當(dāng)前作用域之外的代碼塊的可能所以可能帶來更多副作用。
你總應(yīng)該用getter和setter嘴脾，因?yàn)椋?/p>
使用setter會(huì)遵守定義的內(nèi)存管理語義(strong,weak,copyetc...)男摧，這個(gè)在ARC之前就是相關(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：
它是對未來的變化有擴(kuò)展能力的（比如哥谷，屬性是自動(dòng)生成的）。
它允許子類化麻献。
更簡單的debug（比如们妥，允許拿出一個(gè)斷點(diǎn)在getter方法里面，并且看誰訪問了特別的getter
它讓意圖更加清晰和明確：通過訪問ivar_anIvar你可以明確的訪問self->_anIvar.這可能導(dǎo)致問題勉吻。在block里面訪問ivar（你捕捉并且retain了self监婶，即使你沒有明確的看到self關(guān)鍵詞）。
它自動(dòng)產(chǎn)生KVO通知齿桃。
Designated和Secondary初始化方法
一個(gè)類應(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)來訪問以及設(shè)置屬性短纵。
例子:
view.backgroundColor = [UIColororangeColor];
[UIApplicationsharedApplication].delegate;
不要這樣:
[viewsetBackgroundColor:[UIColororangeColor]];
UIApplication.sharedApplication.delegate;
使用點(diǎn)符號(hào)會(huì)讓表達(dá)更加清晰并且?guī)椭鷧^(qū)分屬性訪問和方法調(diào)用
4.懶加載（Lazy?Loading）
當(dāng)實(shí)例化一個(gè)對象需要耗費(fèi)很多資源带污，或者配置一次就要調(diào)用很多配置相關(guān)的方法而你又不想弄亂這些方法時(shí)，我們需要重寫getter方法以延遲實(shí)例化香到，而不是在init方法里給對象分配內(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è)字符串常量悠就，就像你暴露給其他類的其他字符串常量一樣千绪。你應(yīng)該在公開的接口文件中將其聲明為extern的，并且在對應(yīng)的實(shí)現(xiàn)文件里面定義理卑。
因?yàn)槟阍陬^文件中暴露了符號(hào)翘紊，所以你應(yīng)該按照統(tǒng)一的命名空間前綴法則，用類名前綴作為這個(gè)通知名字的前綴藐唠。
同時(shí)帆疟，用一個(gè)Did/Will這樣的動(dòng)詞以及用"Notifications"后綴來命名這個(gè)通知也是一個(gè)好的實(shí)踐。
// Foo.h
externNSString*constZOCFooDidBecomeBarNotification
// Foo.m
NSString*constZOCFooDidBecomeBarNotification =@"ZOCFooDidBecomeBarNotification";
隨著項(xiàng)目的不斷迭代更新宇立，工程中引入的三方庫日益增多踪宠。如何管理已有三方庫，合理的引入新的第三方庫成為了一個(gè)新的問題妈嘹。如下將總結(jié)我們引入第三方庫的規(guī)范柳琢，并將持續(xù)更新。
1.所引入的第三方庫盡量選擇有人維護(hù)更新的。無人維護(hù)的庫并被證明存在已知缺陷或明顯落后于當(dāng)前版本環(huán)境的柬脸，請避免使用他去。
2.兼容性滿足當(dāng)前APP要求的。引用前請確認(rèn)該庫在所需要兼容的版本范圍內(nèi)良好的運(yùn)行倒堕。不會(huì)出現(xiàn)崩潰灾测，或較大的外觀差異。
3.易于維護(hù)的垦巴，應(yīng)用廣泛的媳搪。最好是業(yè)內(nèi)特定功能的行業(yè)標(biāo)準(zhǔn)庫。冷門且復(fù)雜的三方庫會(huì)給項(xiàng)目帶來不可預(yù)估的風(fēng)險(xiǎn)骤宣。如需求變更秦爆，或出現(xiàn)崩潰問題時(shí)將很難修改，也無法找到有價(jià)值的參考資料憔披。
4.一致性等限。同一功能的第三方庫在一個(gè)項(xiàng)目內(nèi)只允許用使用一種。以減小維護(hù)成本活逆，降低復(fù)雜度精刷，統(tǒng)一標(biāo)準(zhǔn)。
5.關(guān)于拓展蔗候，當(dāng)三方庫不能滿足所需功能時(shí)怒允，不要直接修改庫的代碼（雖然它是開源的）。請建立新的子類去繼承它或使用category锈遥。修改源碼會(huì)降低庫的復(fù)用性纫事。
CPU資源消耗原因和解決方案
對象的創(chuàng)建會(huì)分配內(nèi)存、調(diào)整屬性所灸、甚至還有讀取文件等操作丽惶，比較消耗CPU資源。盡量用輕量的對象代替重量的對象爬立，可以對性能有所優(yōu)化钾唬。比如CALayer比UIView要輕量許多，那么不需要響應(yīng)觸摸事件的控件侠驯，用CALayer顯示會(huì)更加合適抡秆。如果對象不涉及UI操作，則盡量放到后臺(tái)線程去創(chuàng)建吟策，但可惜的是包含有CALayer的控件儒士，都只能在主線程創(chuàng)建和操作。通過Storyboard創(chuàng)建視圖對象時(shí)檩坚，其資源消耗會(huì)比直接通過代碼創(chuàng)建對象要大非常多着撩，在性能敏感的界面里诅福，Storyboard并不是一個(gè)好的技術(shù)選擇。
盡量推遲對象創(chuàng)建的時(shí)間拖叙，并把對象的創(chuàng)建分散到多個(gè)任務(wù)中去氓润。盡管這實(shí)現(xiàn)起來比較麻煩，并且?guī)淼膬?yōu)勢并不多薯鳍，但如果有能力做旺芽，還是要盡量嘗試一下（懶加載）。如果對象可以復(fù)用辐啄，并且復(fù)用的代價(jià)比釋放、創(chuàng)建新對象要小运嗜，那么這類對象應(yīng)當(dāng)盡量放到一個(gè)緩存池里復(fù)用壶辜。
對象的調(diào)整也經(jīng)常是消耗CPU資源的地方。這里特別說一下CALayer：CALayer內(nèi)部并沒有屬性担租，當(dāng)調(diào)用屬性方法時(shí)砸民，它內(nèi)部是通過運(yùn)行時(shí)resolveInstanceMethod為對象臨時(shí)添加一個(gè)方法，并把對應(yīng)屬性值保存到內(nèi)部的一個(gè)Dictionary里奋救，同時(shí)還會(huì)通知delegate岭参、創(chuàng)建動(dòng)畫等等，非常消耗資源尝艘。UIView的關(guān)于顯示相關(guān)的屬性（比如frame/bounds/transform）等實(shí)際上都是CALayer屬性映射來的演侯，所以對UIView的這些屬性進(jìn)行調(diào)整時(shí)，消耗的資源要遠(yuǎn)大于一般的屬性背亥。對此你在應(yīng)用中秒际，應(yīng)該盡量減少不必要的屬性修改。
當(dāng)視圖層次調(diào)整時(shí)狡汉，UIView娄徊、CALayer之間會(huì)出現(xiàn)很多方法調(diào)用與通知，所以在優(yōu)化性能時(shí)盾戴，應(yīng)該盡量避免調(diào)整視圖層次寄锐、添加和移除視圖。
對象的銷毀雖然消耗資源不多尖啡，但累積起來也是不容忽視的橄仆。通常當(dāng)容器類持有大量對象時(shí)，其銷毀時(shí)的資源消耗就非常明顯可婶。同樣的沿癞，如果對象可以放到后臺(tái)線程去釋放，那就挪到后臺(tái)線程去矛渴。這里有個(gè)小Tip：把對象捕獲到block中椎扬，然后扔到后臺(tái)隊(duì)列去隨便發(fā)送個(gè)消息以避免編譯器警告惫搏，就可以讓對象在后臺(tái)線程銷毀了。
NSArray *tmp=self.array;
self.array=nil;
dispatch_async(queue,^{
[tmpclass];
});
視圖布局的計(jì)算是App中最為常見的消耗CPU資源的地方蚕涤。如果能在后臺(tái)線程提前計(jì)算好視圖布局筐赔、并且對視圖布局進(jìn)行緩存，那么這個(gè)地方基本就不會(huì)產(chǎn)生性能問題了揖铜。
不論通過何種技術(shù)對視圖進(jìn)行布局茴丰，其最終都會(huì)落到對UIView.frame/bounds/center等屬性的調(diào)整上。上面也說過天吓，對這些屬性的調(diào)整非常消耗資源贿肩，所以盡量提前計(jì)算好布局，在需要時(shí)一次性調(diào)整好對應(yīng)屬性龄寞，而不要多次汰规、頻繁的計(jì)算和調(diào)整這些屬性。
Autolayout是蘋果本身提倡的技術(shù)物邑，在大部分情況下也能很好的提升開發(fā)效率溜哮，但是Autolayout對于復(fù)雜視圖來說常常會(huì)產(chǎn)生嚴(yán)重的性能問題。隨著視圖數(shù)量的增長色解，Autolayout帶來的CPU消耗會(huì)呈指數(shù)級(jí)上升茂嗓。具體數(shù)據(jù)可以看這個(gè)文章：http://pilky.me/36/。如果你不想手動(dòng)調(diào)整frame等屬性科阎，你可以用一些工具方法替代（比如常見的left/right/top/bottom/width/height快捷屬性）述吸，或者使用ComponentKit、AsyncDisplayKit等框架锣笨。
如果一個(gè)界面中包含大量文本（比如微博微信朋友圈等）刚梭，文本的寬高計(jì)算會(huì)占用很大一部分資源，并且不可避免票唆。如果你對文本顯示沒有特殊要求朴读，可以參考下UILabel內(nèi)部的實(shí)現(xiàn)方式：用[NSAttributedString boundingRectWithSize:options:context:]來計(jì)算文本寬高，用-[NSAttributedString
drawWithRect:options:context:]來繪制文本走趋。盡管這兩個(gè)方法性能不錯(cuò)衅金，但仍舊需要放到后臺(tái)線程進(jìn)行以避免阻塞主線程。
如果你用CoreText繪制文本簿煌，那就可以先生成CoreText排版對象氮唯，然后自己計(jì)算了，并且CoreText對象還能保留以供稍后繪制使用姨伟。
屏幕上能看到的所有文本內(nèi)容控件惩琉，包括UIWebView，在底層都是通過CoreText排版夺荒、繪制為Bitmap顯示的瞒渠。常見的文本控件（UILabel良蒸、UITextView等），其排版和繪制都是在主線程進(jìn)行的伍玖，當(dāng)顯示大量文本時(shí)嫩痰，CPU的壓力會(huì)非常大。對此解決方案只有一個(gè)窍箍，那就是自定義文本控件串纺，用TextKit或最底層的CoreText對文本異步繪制。盡管這實(shí)現(xiàn)起來非常麻煩椰棘，但其帶來的優(yōu)勢也非常大纺棺，CoreText對象創(chuàng)建好后，能直接獲取文本的寬高等信息邪狞，避免了多次計(jì)算（調(diào)整UILabel大小時(shí)算一遍五辽、UILabel繪制時(shí)內(nèi)部再算一遍）；CoreText對象占用內(nèi)存較少外恕，可以緩存下來以備稍后多次渲染。
當(dāng)你用UIImage或CGImageSource的那幾個(gè)方法創(chuàng)建圖片時(shí)乡翅，圖片數(shù)據(jù)并不會(huì)立刻解碼鳞疲。圖片設(shè)置到UIImageView或者CALayer.contents中去，并且CALayer被提交到GPU前蠕蚜，CGImage中的數(shù)據(jù)才會(huì)得到解碼尚洽。這一步是發(fā)生在主線程的，并且不可避免靶累。如果想要繞開這個(gè)機(jī)制腺毫，常見的做法是在后臺(tái)線程先把圖片繪制到CGBitmapContext中，然后從Bitmap直接創(chuàng)建圖片挣柬。目前常見的網(wǎng)絡(luò)圖片庫都自帶這個(gè)功能潮酒。
（8）圖像的繪制
圖像的繪制通常是指用那些以CG開頭的方法把圖像繪制到畫布中，然后從畫布創(chuàng)建圖片并顯示這樣一個(gè)過程邪蛔。這個(gè)最常見的地方就是[UIView drawRect:]里面了急黎。由于CoreGraphic方法通常都是線程安全的，所以圖像的繪制可以很容易的放到后臺(tái)線程進(jìn)行侧到。一個(gè)簡單異步繪制的過程大致如下（實(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;
});
});
}
相對于CPU來說，GPU能干的事情比較單一：接收提交的紋理（Texture）和頂點(diǎn)描述（三角形）匠抗，應(yīng)用變換（transform）故源、混合并渲染，然后輸出到屏幕上汞贸。通常你所能看到的內(nèi)容绳军，主要也就是紋理（圖片）和形狀（三角模擬的矢量圖形）兩類印机。
所有的Bitmap，包括圖片删铃、文本耳贬、柵格化的內(nèi)容，最終都要由內(nèi)存提交到顯存猎唁，綁定為GPU Texture咒劲。不論是提交到顯存的過程，還是GPU調(diào)整和渲染Texture的過程诫隅，都要消耗不少GPU資源腐魂。當(dāng)在較短時(shí)間顯示大量圖片時(shí)（比如TableView存在非常多的圖片并且快速滑動(dòng)時(shí)），CPU占用率很低逐纬，GPU占用非常高蛔屹，界面仍然會(huì)掉幀。避免這種情況的方法只能是盡量減少在短時(shí)間內(nèi)大量圖片的顯示豁生，盡可能將多張圖片合成為一張進(jìn)行顯示兔毒。
當(dāng)圖片過大，超過GPU的最大紋理尺寸時(shí)甸箱，圖片需要先由CPU進(jìn)行預(yù)處理育叁，這對CPU和GPU都會(huì)帶來額外的資源消耗。目前來說芍殖，iPhone 4S以上機(jī)型豪嗽，紋理尺寸上限都是4096x4096，
當(dāng)多個(gè)視圖（或者說CALayer）重疊在一起顯示時(shí)豌骏，GPU會(huì)首先把他們混合到一起龟梦。如果視圖結(jié)構(gòu)過于復(fù)雜，混合的過程也會(huì)消耗很多GPU資源窃躲。為了減輕這種情況的GPU消耗计贰，應(yīng)用應(yīng)當(dāng)盡量減少視圖數(shù)量和層次，并在不透明的視圖里標(biāo)明opaque屬性以避免無用的Alpha通道合成蒂窒。當(dāng)然蹦玫，這也可以用上面的方法，把多個(gè)視圖預(yù)先渲染為一張圖片來顯示刘绣。
CALayer的border、圓角纬凤、陰影福贞、遮罩（mask），CASharpLayer的矢量圖形顯示停士，通常會(huì)觸發(fā)離屏渲染（offscreen rendering）挖帘，而離屏渲染通常發(fā)生在GPU中完丽。當(dāng)一個(gè)列表視圖中出現(xiàn)大量圓角的CALayer，并且快速滑動(dòng)時(shí)拇舀，可以觀察到GPU資源已經(jīng)占滿逻族，而CPU資源消耗很少。這時(shí)界面仍然能正辰颈溃滑動(dòng)聘鳞，但平均幀數(shù)會(huì)降到很低。為了避免這種情況要拂，可以嘗試開啟CALayer.shouldRasterize屬性抠璃，但這會(huì)把原本離屏渲染的操作轉(zhuǎn)嫁到CPU上去。對于只需要圓角的某些場合脱惰，也可以用一張已經(jīng)繪制好的圓角圖片覆蓋到原本視圖上面來模擬相同的視覺效果搏嗡。最徹底的解決辦法，就是把需要顯示的圖形在后臺(tái)線程繪制為圖片拉一，避免使用圓角采盒、陰影、遮罩等屬性蔚润。
