目錄
####入門級（這是些你一定會經(jīng)常用在你app開發(fā)中的建議）
1.用ARC管理內(nèi)存?
2. 在正確的地方使用reuseIdentifier?
3. 盡可能使Views透明?
4. 避免龐大的XIB?
5. 不要block主線程?
6. 在Image Views中調(diào)整圖片大小?
7. 選擇正確的Collection?
8. 打開gzip壓縮
####中級（這些是你可能在一些相對復(fù)雜情況下可能用到的）
9. 重用和延遲加載Views?
10. Cache, Cache, 還是Cache！?
11. 權(quán)衡渲染方法?
12. 處理內(nèi)存警告? ?
13. 重用大開銷的對象? ?
14. 優(yōu)化你的Table View? ?
15. 選擇正確的數(shù)據(jù)存儲選項
####進階級（這些建議只應(yīng)該在你確信他們可以解決問題和得心應(yīng)手的情況下采用）
16. 加速啟動時間? ?
17. 使用Autorelease Pool? ?
18. 選擇是否緩存圖片? ?
19. 盡量避免日期格式轉(zhuǎn)換
初學(xué)者性能提升
1. 用ARC管理內(nèi)存
ARC(Automatic Reference Counting, 自動引用計數(shù))和iOS5一起發(fā)布，它避免了最常見的也就是經(jīng)常是由于我們忘記釋放內(nèi)存所造成的內(nèi)存泄露颠蕴。它自動為你管理retain和release的過程扁凛，所以你就不必去手動干預(yù)了。
2. 在正確的地方使用 reuseIdentifier
一個開發(fā)中常見的錯誤就是沒有給UITableViewCells诅岩， UICollectionViewCells，甚至是UITableViewHeaderFooterViews設(shè)置正確的reuseIdentifier楣铁。為了性能最優(yōu)化道偷，table view用tableView:cellForRowAtIndexPath:為rows分配cells的時候缀旁，它的數(shù)據(jù)應(yīng)該重用自UITableViewCell。 一個table view維持一個隊列的數(shù)據(jù)可重用的UITableViewCell對象勺鸦。不使用reuseIdentifier的話并巍，每顯示一行table view就不得不設(shè)置全新的cell。這對性能的影響可是相當(dāng)大的换途，尤其會使app的滾動體驗大打折扣懊渡。自iOS6起，除了UICollectionView的cells和補充views军拟，你也應(yīng)該在header和footer views中使用reuseIdentifiers剃执。想要使用reuseIdentifiers的話，在一個table view中添加一個新的cell時在data source object中添加這個方法：
NSString*CellIdentifier = @“Cell”;
UITableViewCell*cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier forIndexPath:indexPath];
這個方法把那些已經(jīng)存在的cell從隊列中排除懈息，或者在必要時使用先前注冊的nib或者class創(chuàng)造新的cell肾档。如果沒有可重用的cell，你也沒有注冊一個class或者nib的話辫继，這個方法返回nil怒见。
3.盡量把views設(shè)置為透明
如果你有透明的Views你應(yīng)該設(shè)置它們的opaque屬性為YES。
原因是這會使系統(tǒng)用一個最優(yōu)的方式渲染這些views姑宽。這個簡單的屬性在IB或者代碼里都可以設(shè)定遣耍。
Apple的文檔對于為圖片設(shè)置透明屬性的描述是：
(opaque)這個屬性給渲染系統(tǒng)提供了一個如何處理這個view的提示。如果設(shè)為YES炮车， 渲染系統(tǒng)就認(rèn)為這個view是完全不透明的舵变，這使得渲染系統(tǒng)優(yōu)化一些渲染過程和提高性能。如果設(shè)置為NO示血，渲染系統(tǒng)正常地和其它內(nèi)容組成這個View棋傍。默認(rèn)值是YES。
在相對比較靜止的畫面中难审，設(shè)置這個屬性不會有太大影響瘫拣。然而當(dāng)這個view嵌在scroll view里邊，或者是一個復(fù)雜動畫的一部分告喊，不設(shè)置這個屬性的話會在很大程度上影響app的性能麸拄。
你可以在模擬器中用Debug\Color Blended Layers選項來發(fā)現(xiàn)哪些view沒有被設(shè)置為opaque。目標(biāo)就是黔姜，能設(shè)為opaque的就全設(shè)為opaque!
4. 避免過于龐大的XIB
iOS5中加入的Storyboards(分鏡)正在快速取代XIB拢切。然而XIB在一些場景中仍然很有用。比如你的app需要適應(yīng)iOS5之前的設(shè)備秆吵，或者你有一個自定義的可重用的view,你就不可避免地要用到他們淮椰。
如果你不得不XIB的話，使他們盡量簡單。嘗試為每個Controller配置一個單獨的XIB主穗，盡可能把一個View Controller的view層次結(jié)構(gòu)分散到單獨的XIB中去泻拦。
需要注意的是，當(dāng)你加載一個XIB的時候所有內(nèi)容都被放在了內(nèi)存里忽媒，包括任何圖片争拐。如果有一個不會即刻用到的view，你這就是在浪費寶貴的內(nèi)存資源了晦雨。Storyboards就是另一碼事兒了架曹，storyboard僅在需要時實例化一個view controller.
當(dāng)家在XIB是，所有圖片都被chache闹瞧，如果你在做OS X開發(fā)的話绑雄，聲音文件也是。Apple在相關(guān)文檔中的記述是：
當(dāng)你加載一個引用了圖片或者聲音資源的nib時夹抗，nib加載代碼會把圖片和聲音文件寫進內(nèi)存绳慎。在OS X中，圖片和聲音資源被緩存在named cache中以便將來用到時獲取漠烧。在iOS中杏愤，僅圖片資源會被存進named caches。取決于你所在的平臺已脓，使用NSImage 或UIImage 的imageNamed:方法來獲取圖片資源珊楼。
5. 不要阻塞主線程
永遠(yuǎn)不要使主線程承擔(dān)過多。因為UIKit在主線程上做所有工作度液，渲染厕宗，管理觸摸反應(yīng)，回應(yīng)輸入等都需要在它上面完成堕担。
一直使用主線程的風(fēng)險就是如果你的代碼真的block了主線程已慢，你的app會失去反應(yīng)。這霹购。佑惠。。正是在App Store中拿到一顆星的捷徑 :]
大部分阻礙主進程的情形是你的app在做一些牽涉到讀寫外部資源的I/O操作齐疙，比如存儲或者網(wǎng)絡(luò)膜楷。
你可以使用NSURLConnection異步地做網(wǎng)絡(luò)操作:
(void)sendAsynchronousRequest:(NSURLRequest)request queue:(NSOperationQueue )queue completionHandler:(void (^)(NSURLResponse, NSData, NSError*))handler
或者使用像AFNetworking這樣的框架來異步地做這些操作。
如果你需要做其它類型的需要耗費巨大資源的操作(比如時間敏感的計算或者存儲讀寫)那就用 Grand Central Dispatch贞奋，或者 NSOperation 和 NSOperationQueues.
下面代碼是使用GCD的模板
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT,0), ^{
// switch to a background thread and perform your expensive operationdispatch_async(dispatch_get_main_queue(), ^{
// switch back to the main thread to update your UI
});
});
發(fā)現(xiàn)代碼中有一個嵌套的dispatch_async嗎赌厅？這是因為任何UIKit相關(guān)的代碼需要在主線程上進行。
如果你對 NSOperation 或者GCD 的細(xì)節(jié)感興趣的話轿塔，看看Ray Wenderlich的Multithreading and Grand Central Dispatch on iOS for Beginners特愿， 還有 Soheil Azarpour 的How To Use NSOperations and NSOperationQueues教程仲墨。
6. 在Image Views中調(diào)整圖片大小
如果要在UIImageView中顯示一個來自bundle的圖片，你應(yīng)保證圖片的大小和UIImageView的大小相同洽议。在運行中縮放圖片是很耗費資源的宗收，特別是UIImageView嵌套在UIScrollView中的情況下。
如果圖片是從遠(yuǎn)端服務(wù)加載的你不能控制圖片大小亚兄，比如在下載前調(diào)整到合適大小的話，你可以在下載完成后采驻，最好是用background thread审胚，縮放一次，然后在UIImageView中使用縮放后的圖片礼旅。
7. 選擇正確的Collection
學(xué)會選擇對業(yè)務(wù)場景最合適的類或者對象是寫出能效高的代碼的基礎(chǔ)膳叨。當(dāng)處理collections時這句話尤其正確。
Apple有一個Collections Programming Topics的文檔詳盡介紹了可用的classes間的差別和你該在哪些場景中使用它們痘系。這對于任何使用collections的人來說是一個必讀的文檔菲嘴。
…這是一些常見collection的總結(jié)：
Arrays: 有序的一組值。使用index來lookup很快汰翠，使用value lookup很慢龄坪， 插入/刪除很慢。
Dictionaries: 存儲鍵值對复唤。 用鍵來查找比較快健田。
Sets: 無序的一組值。用值來查找很快佛纫，插入/刪除很快妓局。
8. 打開gzip壓縮
大量app依賴于遠(yuǎn)端資源和第三方API，你可能會開發(fā)一個需要從遠(yuǎn)端下載XML, JSON, HTML或者其它格式的app呈宇。
問題是我們的目標(biāo)是移動設(shè)備好爬，因此你就不能指望網(wǎng)絡(luò)狀況有多好。一個用戶現(xiàn)在還在edge網(wǎng)絡(luò)甥啄，下一分鐘可能就切換到了3G存炮。不論什么場景，你肯定不想讓你的用戶等太長時間型豁。
減小文檔的一個方式就是在服務(wù)端和你的app中打開gzip僵蛛。這對于文字這種能有更高壓縮率的數(shù)據(jù)來說會有更顯著的效用。
好消息是迎变，iOS已經(jīng)在NSURLConnection中默認(rèn)支持了gzip壓縮充尉，當(dāng)然AFNetworking這些基于它的框架亦然。像Google App Engine這些云服務(wù)提供者也已經(jīng)支持了壓縮輸出衣形。
如果你不知道如何利用Apache或者IIS(服務(wù)器)來打開gzip驼侠，可以讀下這篇文章姿鸿。
中級性能提升
9. 重用和延遲加載(lazy load) Views
更多的view意味著更多的渲染，也就是更多的CPU和內(nèi)存消耗倒源，對于那種嵌套了很多view在UIScrollView里邊的app更是如此苛预。
這里我們用到的技巧就是模仿UITableView和UICollectionView的操作: 不要一次創(chuàng)建所有的subview，而是當(dāng)需要時才創(chuàng)建笋熬，當(dāng)它們完成了使命热某，把他們放進一個可重用的隊列中。
這樣的話你就只需要在滾動發(fā)生時創(chuàng)建你的views胳螟，避免了不劃算的內(nèi)存分配昔馋。
創(chuàng)建views的能效問題也適用于你app的其它方面。想象一下一個用戶點擊一個按鈕的時候需要呈現(xiàn)一個view的場景糖耸。有兩種實現(xiàn)方法：
1. 創(chuàng)建并隱藏這個view當(dāng)這個screen加載的時候秘遏，當(dāng)需要時顯示它；
2. 當(dāng)需要時才創(chuàng)建并展示嘉竟。
每個方案都有其優(yōu)缺點邦危。
用第一種方案的話因為你需要一開始就創(chuàng)建一個view并保持它直到不再使用，這就會更加消耗內(nèi)存舍扰。然而這也會使你的app操作更敏感因為當(dāng)用戶點擊按鈕的時候它只需要改變一下這個view的可見性倦蚪。
第二種方案則相反-消耗更少內(nèi)存，但是會在點擊按鈕的時候比第一種稍顯卡頓妥粟。
10. Cache, Cache, 還是Cache!
一個極好的原則就是审丘，緩存所需要的，也就是那些不大可能改變但是需要經(jīng)常讀取的東西勾给。
我們能緩存些什么呢滩报？一些選項是，遠(yuǎn)端服務(wù)器的響應(yīng)播急，圖片脓钾，甚至計算結(jié)果，比如UITableView的行高桩警。
NSURLConnection默認(rèn)會緩存資源在內(nèi)存或者存儲中根據(jù)它所加載的HTTP Headers可训。你甚至可以手動創(chuàng)建一個NSURLRequest然后使它只加載緩存的值。
下面是一個可用的代碼段捶枢，你可以可以用它去為一個基本不會改變的圖片創(chuàng)建一個NSURLRequest并緩存它：
+ (NSMutableURLRequest *)imageRequestWithURL:(NSURL *)url {
NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:url];
request.cachePolicy = NSURLRequestReturnCacheDataElseLoad;// this will make sure the request always returns the cached image
request.HTTPShouldHandleCookies = NO;
request.HTTPShouldUsePipelining = YES;
[request addValue:@"image/*"``forHTTPHeaderField:@``"Accept”];
return request;
}
注意你可以通過 NSURLConnection 獲取一個URL request握截， AFNetworking也一樣的。這樣你就不必為采用這條tip而改變所有的networking代碼了烂叔。
如果想了解更多關(guān)于HTTP caching, NSURLCache, NSURLConnection的相關(guān)知識谨胞，可以讀下這篇文章()
如果你需要緩存其它不是HTTP Request的東西，你可以用NSCache蒜鸡。
NSCache和NSDictionary類似胯努，不同的是系統(tǒng)回收內(nèi)存的時候它會自動刪掉它的內(nèi)容牢裳。 Mattt Thompson有一篇很棒的關(guān)于它的文章：:http://nshipster.com/nscache/
如果你對HTTP感興趣可以讀下Google的這篇best-practices document on HTTP caching。
11. 權(quán)衡渲染方法
在iOS中可以有很多方法做出漂亮的按鈕叶沛。你可以用整幅的圖片蒲讯，可調(diào)大小的圖片，uozhe可以用CALayer灰署， CoreGraphics甚至OpenGL來畫它們判帮。
當(dāng)然每個不同的解決方法都有不同的復(fù)雜程度和相應(yīng)的性能。有一篇Apple UIKit team中的一員Andy Matuschak推薦過的很棒的關(guān)于graphic性能的帖子很值得一讀溉箕。
簡單來說脊另，就是用事先渲染好的圖片更快一些，因為如此一來iOS就免去了創(chuàng)建一個圖片再畫東西上去然后顯示在屏幕上的程序约巷。問題是你需要把所有你需要用到的圖片放到app的bundle里面，這樣就增加了體積 – 這就是使用可變大小的圖片更好的地方了: 你可以省去一些不必要的空間旱捧，也不需要再為不同的元素(比如按鈕)來做不同的圖独郎。
然而，使用圖片也意味著你失去了使用代碼調(diào)整圖片的機動性枚赡，你需要一遍又一遍不斷地重做他們氓癌，這樣就很浪費時間了，而且你如果要做一個動畫效果贫橙，雖然每幅圖只是一些細(xì)節(jié)的變化你就需要很多的圖片造成bundle大小的不斷增大贪婉。
總得來說，你需要權(quán)衡一下利弊卢肃，到底是要性能能還是要bundle保持合適的大小疲迂。
12. 處理內(nèi)存警告
一旦系統(tǒng)內(nèi)存過低，iOS會通知所有運行中app莫湘。在官方文檔中是這樣記述:
如果你的app收到了內(nèi)存警告尤蒿，它就需要盡可能釋放更多的內(nèi)存。最佳方式是移除對緩存幅垮，圖片object和其他一些可以重創(chuàng)建的objects的strong references.
幸運的是腰池，UIKit提供了幾種收集低內(nèi)存警告的方法:
在app delegate中使用applicationDidReceiveMemoryWarning:的方法
在你的自定義UIViewController的子類(subclass)中覆蓋didReceiveMemoryWarning
注冊并接收 UIApplicationDidReceiveMemoryWarningNotification 的通知
一旦收到這類通知，你就需要釋放任何不必要的內(nèi)存使用忙芒。
例如示弓，UIViewController的默認(rèn)行為是移除一些不可見的view， 它的一些子類則可以補充這個方法呵萨，刪掉一些額外的數(shù)據(jù)結(jié)構(gòu)奏属。一個有圖片緩存的app可以移除不在屏幕上顯示的圖片。
這樣對內(nèi)存警報的處理是很必要的甘桑，若不重視拍皮，你的app就可能被系統(tǒng)殺掉歹叮。
然而，當(dāng)你一定要確認(rèn)你所選擇的object是可以被重現(xiàn)創(chuàng)建的來釋放內(nèi)存铆帽。一定要在開發(fā)中用模擬器中的內(nèi)存提醒模擬去測試一下咆耿。
13. 重用大開銷對象
一些objects的初始化很慢，比如NSDateFormatter和NSCalendar爹橱。然而萨螺，你又不可避免地需要使用它們，比如從JSON或者XML中解析數(shù)據(jù)愧驱。
想要避免使用這個對象的瓶頸你就需要重用他們慰技，可以通過添加屬性到你的class里或者創(chuàng)建靜態(tài)變量來實現(xiàn)。
注意如果你要選擇第二種方法组砚，對象會在你的app運行時一直存在于內(nèi)存中吻商，和單例(singleton)很相似。
下面的代碼說明了使用一個屬性來延遲加載一個date formatter. 第一次調(diào)用時它會創(chuàng)建一個新的實例糟红，以后的調(diào)用則將返回已經(jīng)創(chuàng)建的實例：
// in your .h or inside a class extension
@property (nonatomic, strong) NSDateFormatter *formatter;
// inside the implementation (.m)
// When you need, just use self.formatter
- (NSDateFormatter *)formatter {
if(! _formatter) {
_formatter = [[NSDateFormatter alloc] init];
_formatter.dateFormat = @"EEE MMM dd HH:mm:ss Z yyyy”;
// twitter date format
}
return _formatter;
}
還需要注意的是艾帐，其實設(shè)置一個NSDateFormatter的速度差不多是和創(chuàng)建新的一樣慢的！所以如果你的app需要經(jīng)常進行日期格式處理的話盆偿，你會從這個方法中得到不小的性能提升柒爸。
14. 優(yōu)化Table View
Table view需要有很好的滾動性能，不然用戶會在滾動過程中發(fā)現(xiàn)動畫的瑕疵事扭。
為了保證table view平滑滾動捎稚，確保你采取了以下的措施:
正確使用`reuseIdentifier`來重用cells盡量使所有的view opaque，包括cell自身避免漸變求橄，圖片縮放今野，后臺選人緩存行高
如果cell內(nèi)現(xiàn)實的內(nèi)容來自web，使用異步加載谈撒，緩存請求結(jié)果使用`shadowPath`來畫陰影減少subviews的數(shù)量盡量不適用`cellForRowAtIndexPath:`腥泥，如果你需要用到它，只用一次然后緩存結(jié)果使用正確的數(shù)據(jù)結(jié)構(gòu)來存儲數(shù)據(jù)使用`rowHeight`,`sectionFooterHeight`和`sectionHeaderHeight`來設(shè)定固定的高啃匿，不要請求delegate
15. 選擇正確的數(shù)據(jù)存儲選項
當(dāng)存儲大塊數(shù)據(jù)時你會怎么做蛔外？
你有很多選擇，比如：
使用NSUerDefaults
使用XML, JSON, 或者 plist
使用NSCoding存檔
使用類似SQLite的本地SQL數(shù)據(jù)庫
使用 Core Data
NSUserDefaults的問題是什么溯乒？雖然它很nice也很便捷夹厌，但是它只適用于小數(shù)據(jù)，比如一些簡單的布爾型的設(shè)置選項裆悄，再大點你就要考慮其它方式了
XML這種結(jié)構(gòu)化檔案呢矛纹？總體來說，你需要讀取整個文件到內(nèi)存里去解析光稼，這樣是很不經(jīng)濟的或南。使用SAX又是一個很麻煩的事情孩等。
NSCoding？不幸的是采够，它也需要讀寫文件肄方，所以也有以上問題。
在這種應(yīng)用場景下蹬癌，使用SQLite 或者 Core Data比較好权她。使用這些技術(shù)你用特定的查詢語句就能只加載你需要的對象。
在性能層面來講逝薪，SQLite和Core Data是很相似的隅要。他們的不同在于具體使用方法。Core Data代表一個對象的graph model董济，但SQLite就是一個DBMS步清。Apple在一般情況下建議使用Core Data，但是如果你有理由不使用它虏肾，那么就去使用更加底層的SQLite吧尼啡。
如果你使用SQLite，你可以用FMDB(FMDB)這個庫來簡化SQLite的操作询微，這樣你就不用花很多經(jīng)歷了解SQLite的C API了。
進階性能提示
22. 加速啟動時間
快速打開app是很重要的狂巢，特別是用戶第一次打開它時撑毛，對app來講，第一印象太太太重要了唧领。
你能做的就是使它盡可能做更多的異步任務(wù)藻雌，比如加載遠(yuǎn)端或者數(shù)據(jù)庫數(shù)據(jù)，解析數(shù)據(jù)斩个。
還是那句話胯杭，避免過于龐大的XIB，因為他們是在主線程上加載的受啥。所以盡量使用沒有這個問題的Storyboards吧做个！
注意，用Xcode debug時watchdog并不運行滚局，一定要把設(shè)備從Xcode斷開來測試啟動速度
23. 使用Autorelease Pool
NSAutoreleasePool負(fù)責(zé)釋放block中的autoreleased objects居暖。一般情況下它會自動被UIKit調(diào)用。但是有些狀況下你也需要手動去創(chuàng)建它藤肢。
假如你創(chuàng)建很多臨時對象太闺，你會發(fā)現(xiàn)內(nèi)存一直在減少直到這些對象被release的時候。這是因為只有當(dāng)UIKit用光了autorelease pool的時候memory才會被釋放嘁圈。
好消息是你可以在你自己的@autoreleasepool里創(chuàng)建臨時的對象來避免這個行為：
NSArray*urls = <# An array of file URLs #>;
for(NSURL*urlinurls) {
@autoreleasepool{
NSError*error;
NSString*fileContents = [NSStringstringWithContentsOfURL:urlencoding:NSUTF8StringEncodingerror:&error];/* Process the string, creating and autoreleasing more objects. */}}
這段代碼在每次遍歷后釋放所有autorelease對象
更多關(guān)于NSAutoreleasePool請參考官方文檔省骂。
24. 選擇是否緩存圖片
常見的從bundle中加載圖片的方式有兩種蟀淮，一個是用imageNamed，二是用imageWithContentsOfFile钞澳，第一種比較常見一點怠惶。
既然有兩種類似的方法來實現(xiàn)相同的目的，那么他們之間的差別是什么呢略贮？
imageNamed的優(yōu)點是當(dāng)加載時會緩存圖片甚疟。[imageNamed的文檔](http://developer.apple.com/library/ios/#documentation/uikit/reference/UIImage_Class/Reference/Reference.html)中這么說:
這個方法用一個指定的名字在系統(tǒng)緩存中查找并返回一個圖片對象如果它存在的話。如果緩存中沒有找到相應(yīng)的圖片逃延，這個方法從指定的文檔中加載然后緩存并返回這個對象览妖。
相反的，imageWithContentsOfFile僅加載圖片揽祥。
下面的代碼說明了這兩種方法的用法:
UIImage*img = [UIImageimageNamed:@``"myImage"``];``// caching// orUIImage*img = [UIImageimageWithContentsOfFile:@"myImage"];// no caching
那么我們應(yīng)該如何選擇呢讽膏？
如果你要加載一個大圖片而且是一次性使用，那么就沒必要緩存這個圖片拄丰，用imageWithContentsOfFile足矣府树，這樣不會浪費內(nèi)存來緩存它。
然而料按，在圖片反復(fù)重用的情況下imageNamed是一個好得多的選擇奄侠。
25. 避免日期格式轉(zhuǎn)換
如果你要用NSDateFormatter來處理很多日期格式，應(yīng)該小心以待载矿。就像先前提到的垄潮，任何時候重用NSDateFormatters都是一個好的實踐。
然而闷盔，如果你需要更多速度弯洗，那么直接用C是一個好的方案。Sam Soffes有一個不錯的帖子(http://soff.es/how-to-drastically-improve-your-app-with-an-afternoon-and-instruments)里面有一些可以用來解析ISO-8601日期字符串的代碼逢勾，簡單重寫一下就可以拿來用了牡整。
嗯，直接用C來搞溺拱，看起來不錯了逃贝，但是你相信嗎，我們還有更好的方案迫摔！
如果你可以控制你所處理的日期格式秋泳，盡量選擇Unix時間戳。你可以方便地從時間戳轉(zhuǎn)換到NSDate:
- (NSDate*)dateFromUnixTimestamp:(NSTimeInterval)timestamp {return[NSDatedateWithTimeIntervalSince1970:timestamp];}
這樣會比用C來解析日期字符串還快攒菠！
Conference
