原博客地址：http://blog.csdn.net/liulanghk/article/details/46404451
1. 用ARC管理內(nèi)存
ARC(Automatic Reference Counting, 自動(dòng)引用計(jì)數(shù))和iOS5一起發(fā)布，它避免了最常見(jiàn)的也就是經(jīng)常是由于我們忘記釋放內(nèi)存所造成的內(nèi)存泄露。它自動(dòng)為你管理retain和release的過(guò)程，所以你就不必去手動(dòng)干預(yù)了。忘掉代碼段結(jié)尾的release簡(jiǎn)直像記得吃飯一樣簡(jiǎn)單。而ARC會(huì)自動(dòng)在底層為你做這些工作。除了幫你避免內(nèi)存泄露，ARC還可以幫你提高性能，它能保證釋放掉不再需要的對(duì)象的內(nèi)存。這都啥年代了，你應(yīng)該在你的所有項(xiàng)目里使用ARC!
如果你有不透明的Views，你應(yīng)該設(shè)置它們的opaque屬性為YES。
原因是這會(huì)使系統(tǒng)用一個(gè)最優(yōu)的方式渲染這些views。這個(gè)簡(jiǎn)單的屬性在IB或者代碼里都可以設(shè)定。
Apple的文檔對(duì)于為圖片設(shè)置不透明屬性的描述是：
(opaque)這個(gè)屬性給渲染系統(tǒng)提供了一個(gè)如何處理這個(gè)view的提示。如果設(shè)為YES， 渲染系統(tǒng)就認(rèn)為這個(gè)view是完全不透明的，這使得渲染系統(tǒng)優(yōu)化一些渲染過(guò)程和提高性能。如果設(shè)置為NO，渲染系統(tǒng)正常地和其它內(nèi)容組成這個(gè)View。默認(rèn)值是YES。
在相對(duì)比較靜止的畫(huà)面中，設(shè)置這個(gè)屬性不會(huì)有太大影響。然而當(dāng)這個(gè)view嵌在scroll view里邊，或者是一個(gè)復(fù)雜動(dòng)畫(huà)的一部分，不設(shè)置這個(gè)屬性的話會(huì)在很大程度上影響app的性能。
你可以在模擬器中用Debug\Color Blended Layers選項(xiàng)來(lái)發(fā)現(xiàn)哪些view沒(méi)有被設(shè)置為opaque。
目標(biāo)就是，能設(shè)為opaque的就全設(shè)為opaque!
iOS5中加入的Storyboards(分鏡)正在快速取代XIB。然而XIB在一些場(chǎng)景中仍然很有用。比如你的app需要適應(yīng)iOS5之前的設(shè)備，或者你有一個(gè)自定義的可重用的view,你就不可避免地要用到他們。
如果你不得不XIB的話，使他們盡量簡(jiǎn)單。嘗試為每個(gè)Controller配置一個(gè)單獨(dú)的XIB，盡可能把一個(gè)View Controller的view層次結(jié)構(gòu)分散到單獨(dú)的XIB中去。
需要注意的是，當(dāng)你加載一個(gè)XIB的時(shí)候所有內(nèi)容都被放在了內(nèi)存里，包括任何圖片。如果有一個(gè)不會(huì)即刻用到的view，你這就是在浪費(fèi)寶貴的內(nèi)存資源了。Storyboards就是另一碼事兒了，storyboard僅在需要時(shí)實(shí)例化一個(gè)view controller.
當(dāng)加載XIB時(shí)，所有圖片都被chache，如果你在做OS X開(kāi)發(fā)的話，聲音文件也是。Apple在相關(guān)文檔中的記述是：
當(dāng)你加載一個(gè)引用了圖片或者聲音資源的nib時(shí)，nib加載代碼會(huì)把圖片和聲音文件寫(xiě)進(jìn)內(nèi)存。在OS X中，圖片和聲音資源被緩存在named cache中以便將來(lái)用到時(shí)獲取。在iOS中，僅圖片資源會(huì)被存進(jìn)named caches。取決于你所在的平臺(tái)，使用NSImage 或UIImage 的imageNamed:方法來(lái)獲取圖片資源。
很明顯，同樣的事情也發(fā)生在storyboards中，但我并沒(méi)有找到任何支持這個(gè)結(jié)論的文檔。如果你了解這個(gè)操作，寫(xiě)信給我！
想要了解更多關(guān)于storyboards的內(nèi)容的話你可以看看 Matthijs Hollemans的Beginning Storyboards in iOS 5 Part 1 和 Part 2
永遠(yuǎn)不要使主線程承擔(dān)過(guò)多。因?yàn)閁IKit在主線程上做所有工作，渲染，管理觸摸反應(yīng)，回應(yīng)輸入等都需要在它上面完成。
一直使用主線程的風(fēng)險(xiǎn)就是如果你的代碼真的block了主線程，你的app會(huì)失去反應(yīng)。這正是在App Store中拿到一顆星的捷徑 如:dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT,0), ^{//切換到子線程異步執(zhí)行一些開(kāi)銷(xiāo)比較大的操作dispatch_async(dispatch_get_main_queue(), ^{//切換到主線程，更新UI等操作});});
如果要在UIImageView中顯示一個(gè)來(lái)自bundle的圖片，你應(yīng)保證圖片的大小和UIImageView的大小相同。
在運(yùn)行中縮放圖片是很耗費(fèi)資源的，特別是UIImageView嵌套在UIScrollView中的情況下。
如果圖片是從遠(yuǎn)端服務(wù)加載的你不能控制圖片大小，比如在下載前調(diào)整到合適大小的話，你可以在下載完成后，最好是用background thread，縮放一次，然后在UIImageView中使用縮放后的圖片。
學(xué)會(huì)選擇對(duì)業(yè)務(wù)場(chǎng)景最合適的類或者對(duì)象是寫(xiě)出能效高的代碼的基礎(chǔ)。當(dāng)處理collections時(shí)這句話尤其正確。
Apple有一個(gè)Collections Programming Topics的文檔詳盡介紹了可用的classes間的差別和你該在哪些場(chǎng)景中使用它們。這對(duì)于任何使用collections的人來(lái)說(shuō)是一個(gè)必讀的文檔。
呵呵，我就知道你因?yàn)樘L(zhǎng)沒(méi)看…這是一些常見(jiàn)collection的總結(jié)：
Arrays: 有序的一組值。使用index來(lái)lookup很快，使用value lookup很慢， 插入/刪除很慢。
Dictionaries: 存儲(chǔ)鍵值對(duì)。 用鍵來(lái)查找比較快。
Sets: 無(wú)序的一組值。用值來(lái)查找很快，插入/刪除很快。
大量app依賴于遠(yuǎn)端資源和第三方API，你可能會(huì)開(kāi)發(fā)一個(gè)需要從遠(yuǎn)端下載XML, JSON, HTML或者其它格式的app。
問(wèn)題是我們的目標(biāo)是移動(dòng)設(shè)備，因此你就不能指望網(wǎng)絡(luò)狀況有多好。一個(gè)用戶現(xiàn)在還在edge網(wǎng)絡(luò)，下一分鐘可能就切換到了3G。不論什么場(chǎng)景，你肯定不想讓你的用戶等太長(zhǎng)時(shí)間。
減小文檔的一個(gè)方式就是在服務(wù)端和你的app中打開(kāi)gzip。這對(duì)于文字這種能有更高壓縮率的數(shù)據(jù)來(lái)說(shuō)會(huì)有更顯著的效用。
好消息是，iOS已經(jīng)在NSURLConnection中默認(rèn)支持了gzip壓縮，當(dāng)然AFNetworking這些基于它的框架亦然。像Google App Engine這些云服務(wù)提供者也已經(jīng)支持了壓縮輸出。
如果你不知道如何利用Apache或者IIS(服務(wù)器)來(lái)打開(kāi)gzip，可以讀下這篇文章。
更多的view意味著更多的渲染，也就是更多的CPU和內(nèi)存消耗，對(duì)于那種嵌套了很多view在UIScrollView里邊的app更是如此。
這里我們用到的技巧就是模仿UITableView和UICollectionView的操作:
不要一次創(chuàng)建所有的subview，而是當(dāng)需要時(shí)才創(chuàng)建，當(dāng)它們完成了使命，把他們放進(jìn)一個(gè)可重用的隊(duì)列中。
這樣的話你就只需要在滾動(dòng)發(fā)生時(shí)創(chuàng)建你的views，避免了不劃算的內(nèi)存分配。
創(chuàng)建views的能效問(wèn)題也適用于你app的其它方面。想象一下一個(gè)用戶點(diǎn)擊一個(gè)按鈕的時(shí)候需要呈現(xiàn)一個(gè)view的場(chǎng)景。有兩種實(shí)現(xiàn)方法：
創(chuàng)建并隱藏這個(gè)view當(dāng)這個(gè)screen加載的時(shí)候，當(dāng)需要時(shí)顯示它；
當(dāng)需要時(shí)才創(chuàng)建并展示。
每個(gè)方案都有其優(yōu)缺點(diǎn)。
用第一種方案的話因?yàn)槟阈枰婚_(kāi)始就創(chuàng)建一個(gè)view并保持它直到不再使用，這就會(huì)更加消耗內(nèi)存。然而這也會(huì)使你的app操作更敏感因?yàn)楫?dāng)用戶點(diǎn)擊按鈕的時(shí)候它只需要改變一下這個(gè)view的可見(jiàn)性。
第二種方案則相反-消耗更少內(nèi)存，但是會(huì)在點(diǎn)擊按鈕的時(shí)候比第一種稍顯卡頓。
一個(gè)極好的原則就是，緩存所需要的，也就是那些不大可能改變但是需要經(jīng)常讀取的東西。
我們能緩存些什么呢？一些選項(xiàng)是:
遠(yuǎn)端服務(wù)器的響應(yīng)，圖片，甚至計(jì)算結(jié)果，比如UITableView的行高。
NSURLConnection會(huì)根據(jù)它所加載的HTTP Headers默認(rèn)緩存資源在內(nèi)存或者存儲(chǔ)中。你甚至可以手動(dòng)創(chuàng)建一個(gè)NSURLRequest然后使它只加載緩存的值。
下面是一個(gè)可用的代碼段，你可以用它去為一個(gè)基本不會(huì)改變的圖片創(chuàng)建一個(gè)NSURLRequest并緩存它：
+ (NSMutableURLRequest *)imageRequestWithURL:(NSURL*)url{? ? NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:url];//添加請(qǐng)求的緩存策略,保證每次都是優(yōu)先加載緩存圖片request.cachePolicy= NSURLRequestReturnCacheDataElseLoad;? ? request.HTTPShouldHandleCookies=NO;? ? request.HTTPShouldUsePipelining=YES;? ? [request addValue:@"image/*"forHTTPHeaderField:@"Accept"];returnrequest;}
注意你可以通過(guò) NSURLConnection 獲取一個(gè)URL request， AFNetworking也一樣的。這樣你就不必為采用這條tip而改變所有的networking代碼了。
如果你需要緩存其它不是HTTP Request的東西，你可以用NSCache。
NSCache和NSDictionary類似，不同的是系統(tǒng)回收內(nèi)存的時(shí)候它會(huì)自動(dòng)刪掉它的內(nèi)容。 Mattt Thompson有一篇很棒的關(guān)于它的文章：:http://nshipster.com/nscache/
如果你對(duì)HTTP感興趣可以讀下Google的這篇 best-practices document on HTTP caching。
在iOS中可以有很多方法做出漂亮的按鈕。你可以用整幅的圖片，可調(diào)大小的圖片，uozhe可以用CALayer， CoreGraphics甚至OpenGL來(lái)畫(huà)它們。
當(dāng)然每個(gè)不同的解決方法都有不同的復(fù)雜程度和相應(yīng)的性能。有一篇Apple UIKit team中的一員Andy Matuschak推薦過(guò)的很棒的關(guān)于graphic性能的帖子很值得一讀。
簡(jiǎn)單來(lái)說(shuō)，就是用事先渲染好的圖片更快一些，因?yàn)槿绱艘粊?lái)iOS就免去了創(chuàng)建一個(gè)圖片再畫(huà)東西上去然后顯示在屏幕上的程序。
問(wèn)題是你需要把所有你需要用到的圖片放到app的bundle里面，這樣就增加了體積 。
這就是使用可變大小的圖片更好的地方了: 你可以省去一些不必要的空間，也不需要再為不同的元素(比如按鈕)來(lái)做不同的圖。
然而，使用圖片也意味著你失去了使用代碼調(diào)整圖片的機(jī)動(dòng)性，你需要一遍又一遍不斷地重做他們，這樣就很浪費(fèi)時(shí)間了，而且你如果要做一個(gè)動(dòng)畫(huà)效果，雖然每幅圖只是一些細(xì)節(jié)的變化你就需要很多的圖片造成bundle大小的不斷增大。
總得來(lái)說(shuō)，你需要權(quán)衡一下利弊，到底是要性能能還是要bundle保持合適的大小。
一旦系統(tǒng)內(nèi)存過(guò)低，iOS會(huì)通知所有運(yùn)行中app。在官方文檔中是這樣記述:
如果你的app收到了內(nèi)存警告，它就需要盡可能釋放更多的內(nèi)存。最佳方式是移除對(duì)緩存，圖片object和其他一些可以重創(chuàng)建的objects的strong references.
幸運(yùn)的是，UIKit提供了幾種收集低內(nèi)存警告的方法:
在app delegate中使用applicationDidReceiveMemoryWarning:
的方法在你的自定義UIViewController的子類(subclass)中覆蓋didReceiveMemoryWarning。
注冊(cè)并接收 UIApplicationDidReceiveMemoryWarningNotification 的通知
的對(duì)象一旦收到這類通知，你就需要釋放任何不必要的內(nèi)存使用。
例如，UIViewController的默認(rèn)行為是移除一些不可見(jiàn)的view， 它的一些子類則可以補(bǔ)充這個(gè)方法，刪掉一些額外的數(shù)據(jù)結(jié)構(gòu)。一個(gè)有圖片緩存的app可以移除不在屏幕上顯示的圖片。
這樣對(duì)內(nèi)存警報(bào)的處理是很必要的，若不重視，你的app就可能被系統(tǒng)殺掉。
然而，當(dāng)你一定要確認(rèn)你所選擇的object是可以被重現(xiàn)創(chuàng)建的來(lái)釋放內(nèi)存。一定要在開(kāi)發(fā)中用模擬器中的內(nèi)存提醒模擬去測(cè)試一下。
一些objects的初始化很慢，比如NSDateFormatter和NSCalendar。然而，你又不可避免地需要使用它們，比如從JSON或者XML中解析數(shù)據(jù)。
想要避免使用這個(gè)對(duì)象的瓶頸你就需要重用他們，可以通過(guò)添加屬性到你的class里或者創(chuàng)建靜態(tài)變量來(lái)實(shí)現(xiàn)。
注意如果你要選擇第二種方法，對(duì)象會(huì)在你的app運(yùn)行時(shí)一直存在于內(nèi)存中，和單例(singleton)很相似。
許多應(yīng)用需要從服務(wù)器加載功能所需的常為JSON或者XML格式的數(shù)據(jù)。
在服務(wù)器端和客戶端使用相同的數(shù)據(jù)結(jié)構(gòu)很重要。
在內(nèi)存中操作數(shù)據(jù)使它們滿足你的數(shù)據(jù)結(jié)構(gòu)是開(kāi)銷(xiāo)很大的。
比如你需要數(shù)據(jù)來(lái)展示一個(gè)table view,最好直接從服務(wù)器取array結(jié)構(gòu)的數(shù)據(jù)以避免額外的中間數(shù)據(jù)結(jié)構(gòu)改變。
類似的，如果需要從特定key中取數(shù)據(jù)，那么就使用鍵值對(duì)的dictionary。
從app和網(wǎng)絡(luò)服務(wù)間傳輸數(shù)據(jù)有很多方案，最常見(jiàn)的就是JSON和XML。你需要選擇對(duì)你的app來(lái)說(shuō)最合適的一個(gè)。
解析JSON會(huì)比XML更快一些，JSON也通常更小更便于傳輸。從iOS5起有了官方內(nèi)建的JSON deserialization 就更加方便使用了。
但是XML也有XML的好處，比如使用SAX 來(lái)解析XML就像解析本地文件一樣，你不需像解析json一樣等到整個(gè)文檔下載完成才開(kāi)始解析。當(dāng)你處理很大的數(shù)據(jù)的時(shí)候就會(huì)極大地減低內(nèi)存消耗和增加性能。
在View里放背景圖片就像很多其它iOS編程一樣有很多方法:
使用UIColor的 colorWithPatternImage來(lái)設(shè)置背景色；
在view中添加一個(gè)UIImageView作為一個(gè)子View。
UIWebView很有用，用它來(lái)展示網(wǎng)頁(yè)內(nèi)容或者創(chuàng)建UIKit很難做到的動(dòng)畫(huà)效果是很簡(jiǎn)單的一件事。
但是你可能有注意到UIWebView并不像驅(qū)動(dòng)Safari的那么快。這是由于以JIT compilation 為特色的Webkit的Nitro Engine的限制。
所以想要更高的性能你就要調(diào)整下你的HTML了。第一件要做的事就是盡可能移除不必要的JavaScript，避免使用過(guò)大的框架。能只用原生js就更好了。
另外，盡可能異步加載例如用戶行為統(tǒng)計(jì)script這種不影響頁(yè)面表達(dá)的javascript。
最后，永遠(yuǎn)要注意你使用的圖片，保證圖片的符合你使用的大小。使用Sprite sheet提高加載速度和節(jié)約內(nèi)存。
Table view需要有很好的滾動(dòng)性能，不然用戶會(huì)在滾動(dòng)過(guò)程中發(fā)現(xiàn)動(dòng)畫(huà)的瑕疵。
為了保證table view平滑滾動(dòng)，確保你采取了以下的措施:
正確使用reuseIdentifier來(lái)重用cells
盡量使所有的view opaque，包括cell自身
避免漸變，圖片縮放，后臺(tái)選人
緩存行高
如果cell內(nèi)現(xiàn)實(shí)的內(nèi)容來(lái)自web，使用異步加載，緩存請(qǐng)求結(jié)果
使用shadowPath來(lái)畫(huà)陰影
減少subviews的數(shù)量
盡量不適用cellForRowAtIndexPath:，如果你需要用到它，只用一次然后緩存結(jié)果
使用正確的數(shù)據(jù)結(jié)構(gòu)來(lái)存儲(chǔ)數(shù)據(jù)
使用rowHeight,sectionFooterHeight和sectionHeaderHeight來(lái)設(shè)定固定的高，不要請(qǐng)求delegate
18. 選擇正確的數(shù)據(jù)存儲(chǔ)選項(xiàng)
當(dāng)存儲(chǔ)大塊數(shù)據(jù)時(shí)你會(huì)怎么做？
你有很多選擇，比如：
使用NSUerDefaults
使用XML, JSON, 或者 plist
使用NSCoding存檔
使用類似SQLite的本地SQL數(shù)據(jù)庫(kù)
使用 Core Data
NSUserDefaults的問(wèn)題是什么？雖然它很nice也很便捷，但是它只適用于小數(shù)據(jù)，比如一些簡(jiǎn)單的布爾型的設(shè)置選項(xiàng)，再大點(diǎn)你就要考慮其它方式了
XML這種結(jié)構(gòu)化檔案呢？總體來(lái)說(shuō)，你需要讀取整個(gè)文件到內(nèi)存里去解析，這樣是很不經(jīng)濟(jì)的。使用SAX又是一個(gè)很麻煩的事情。
NSCoding？不幸的是，它也需要讀寫(xiě)文件，所以也有以上問(wèn)題。
在這種應(yīng)用場(chǎng)景下，使用SQLite 或者 Core Data比較好。使用這些技術(shù)你用特定的查詢語(yǔ)句就能加載你需要的對(duì)象。
在性能層面來(lái)講，SQLite和Core Data是很相似的。他們的不同在于具體使用方法。Core Data代表一個(gè)對(duì)象的graph model，但SQLite就是一個(gè)DBMS。Apple在一般情況下建議使用Core Data，但是如果你有理由不使用它，那么就去使用更加底層的SQLite吧。
如果你使用SQLite，你可以用FMDB(https://github.com/ccgus/fmdb)這個(gè)庫(kù)來(lái)簡(jiǎn)化SQLite的操作，這樣你就不用花很多經(jīng)歷了解SQLite的C API了。
快速打開(kāi)app是很重要的，特別是用戶第一次打開(kāi)它時(shí)，對(duì)app來(lái)講，第一印象太太太重要了。
你能做的就是使它盡可能做更多的異步任務(wù)，比如加載遠(yuǎn)端或者數(shù)據(jù)庫(kù)數(shù)據(jù)，解析數(shù)據(jù)。
還是那句話，避免過(guò)于龐大的XIB，因?yàn)樗麄兪窃谥骶€程上加載的。所以盡量使用沒(méi)有這個(gè)問(wèn)題的Storyboards吧！
注意，用Xcode debug時(shí)watchdog并不運(yùn)行，一定要把設(shè)備從Xcode斷開(kāi)來(lái)測(cè)試啟動(dòng)速度
