1，復(fù)用問題:UITableViewCells，UICollectionViewCells,tableView和collectionView的組頭和組尾設(shè)置正確的復(fù)用標(biāo)識，充分復(fù)用。
2，盡量把Views設(shè)置為不透明:opaque這個屬性給渲染系統(tǒng)提供了一個如何處理這個view的提示，如果設(shè)為YES，渲染系統(tǒng)就認(rèn)為這個view是完全不透明的，這使得渲染系統(tǒng)優(yōu)化一些渲染過程和提高性能。
3，不要使用太復(fù)雜的XIB/StoryBoard：載入時就會將XIB/StoryBoard需要的所有資源，包括圖片全部載入內(nèi)存，即使之后很久才會用到。與那些相比純代碼寫的延遲加載，性能及內(nèi)存就差了很多。
4，選中正確的數(shù)據(jù)結(jié)構(gòu):學(xué)會選擇對業(yè)務(wù)場景最合適的數(shù)組結(jié)構(gòu)是寫出高效代碼的基礎(chǔ)。比如：數(shù)組:有序的一組值。使用索引來查詢很快，使用值查詢很慢，插入/刪除很慢。字典:存儲鍵值對，用鍵來查找比較快，集合:無序的一組值，用值來查找很快，插入/刪除很快。
5，gizp/zip壓縮:當(dāng)從服務(wù)端下載相關(guān)附件時， 可以通過gzip/zip壓縮再下載，使得內(nèi)存更小，下載速度也更快。
6，延遲加載:對于不應(yīng)該使用是數(shù)據(jù)，使用延遲加載方式，對于不需要馬上顯示的視圖，使用延遲加載方式，比如：網(wǎng)絡(luò)請求失敗時顯示的提示界面，可能一直都不會使用到，因此應(yīng)該使用延遲加載。
場景舉例:用戶點(diǎn)擊一個按鈕的時候需要呈現(xiàn)一個view的場景。有兩種實(shí)現(xiàn)方法:
(1):創(chuàng)建并隱藏這個view當(dāng)這個screen加載的時候，當(dāng)需要的時候顯示他
（2）:當(dāng)需要時才創(chuàng)建并顯示。
方案一:需要一開始就創(chuàng)建一個View并保持它知道不再使用，會更加消耗內(nèi)存，然而會使你的app操作更敏感，因?yàn)辄c(diǎn)擊時只需要改變一下這個view的可見性
方案二:消耗更少內(nèi)存，但是會在點(diǎn)擊按鈕的時候比第一種稍顯卡頓。
7，數(shù)據(jù)緩存:對于cell的行高要緩存起來，使得reload數(shù)據(jù)時 ，效率極高。對于那些網(wǎng)絡(luò)數(shù)據(jù)，不需要 每次都請求的，應(yīng)該緩存起來，可以寫入數(shù)據(jù)庫，也可以通過plist文件存儲。
8，處理內(nèi)存警告:一般在基類統(tǒng)一處理內(nèi)存警告，將相關(guān)不用的資源立即釋放掉。
UIKi提供了幾種收集低內(nèi)存警告的方法
· 在app delegate中使用applicationDidReceiveMemoryWarning:的方法
· 在你的自定義UIViewController的子類(subclass)中覆蓋didReceiveMemoryWarning
· 注冊并接收 UIApplicationDidReceiveMemoryWarningNotification的通知
9，重用大開銷對象:一些對象的初始化很慢，比如:NSDateFormatter和NSCalendar，但又不可避免的需要使用它們，通常是作為屬性存儲起來，防止反復(fù)創(chuàng)建。
10，避免反復(fù)處理數(shù)據(jù):許多應(yīng)用需要從服務(wù)器加載功能所需的常為JSON或者XML格式的數(shù)據(jù)，在服務(wù)器端和客戶端使用相同的數(shù)據(jù)結(jié)構(gòu)很重要。
11，使用Autorelease Pool：在某些循環(huán)創(chuàng)建臨時變量處理數(shù)據(jù)時，自動釋放池以保證能及時釋放內(nèi)存。
12，正確選擇圖片加載方式。
在View里放背景圖片就像很多其它iOS編程一樣有很多方法:
使用UIColor的 colorWithPatternImage來設(shè)置背景色；
在view中添加一個UIImageView作為一個子View。
如果你使用全畫幅的背景圖，你就必須使用UIImageView因?yàn)閁IColor的colorWithPatternImage是用來創(chuàng)建小的重復(fù)的圖片作為背景的。這種情形下使用UIImageView可以節(jié)約不少的內(nèi)存：
UIImageView *backgroundView = [[UIImageView alloc] initWithImage:[UIImage imageNamed:@"background"]];
[self.view addSubview:backgroundView];
如果你用小圖平鋪來創(chuàng)建背景，你就需要用UIColor的colorWithPatternImage來做了，它會更快地渲染也不會花費(fèi)很多內(nèi)存：
self.view.backgroundColor = [UIColor colorWithPatternImage:[UIImage imageNamed:@"background"]];
13，如果要在UIImagView中顯示一個來自bundle的圖片，應(yīng)該保證圖片的大小和UIImageView的大小相同，在運(yùn)行中縮放圖片是很耗資源的，特別是UIImageView嵌套在UIScrollView中的情況下。如過圖片是從遠(yuǎn)端服務(wù)加載的圖片你不能控制圖片大小，可以在下載完成后，最好用background thread，縮放一次，然后在UIImageView中使用縮放后的圖片。
14，caches
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;
request.HTTPShouldHandleCookies = NO;
request.HTTPShouldUsePipelining = YES;
[request addValue:@"image/*"forHTTPHeaderField:@"Accept"];
return request;
}

注意你可以通過 NSURLConnection 獲取一個URL request， AFNetworking也一樣的。這樣你就不必為采用這條tip而改變所有的networking代碼了。
如果你需要緩存其它不是HTTP Request的東西，你可以用NSCache。
NSCache和NSDictionary類似，不同的是系統(tǒng)回收內(nèi)存的時候它會自動刪掉它的內(nèi)容。
15：減少使用web特性
UIWebView很有用，用它來展示網(wǎng)頁內(nèi)容或者創(chuàng)建UIKit很難做到的動畫效果是很簡單的一件事。但是你可能有注意到UIWebView并不像驅(qū)動Safari的那么快。這是由于以JIT compilation為特色的Webkit的Nitro Engine的限制。
所以想要更高的性能你就要調(diào)整下你的HTML了。第一件要做的事就是盡可能移除不必要的javascript，避免使用過大的框架。能只用原生js就更好了。
另外，盡可能異步加載例如用戶行為統(tǒng)計(jì)script這種不影響頁面表達(dá)的javascript。
最后，永遠(yuǎn)要注意你使用的圖片，保證圖片的符合你使用的大小。使用Sprite sheet提高加載速度和節(jié)約內(nèi)存。
16:設(shè)定Shadow Path
如何在一個View或者一個layer上加一個shadow呢，QuartzCore框架是很多開發(fā)者的選擇：
UIView *view = [[UIView alloc] init];
view.layer.shadowOffset = CGSizeMake(-1.0f, 1.0f);
view.layer.shadowRadius = 5.0f;
view.layer.shadowOpacity = 0.6;
看起來很簡單，對吧?？墒?，壞消息是使用這個方法也有它的問題… Core Animation不得不先在后臺得出你的圖形并加好陰影然后才渲染，這開銷是很大的。
使用shadowPath的話就避免了這個問題：
view.layer.shadowPath = [[UIBezierPath bezierPathWithRect:view.bounds] CGPath];
使用shadow path的話iOS就不必每次都計(jì)算如何渲染，它使用一個預(yù)先計(jì)算好的路徑。但問題是自己計(jì)算path的話可能在某些View中比較困難，且每當(dāng)view的frame變化的時候你都需要去update shadow path.
17：優(yōu)化tableView
為了保證table view平滑滾動，確保你采取了以下的措施:
1)正確使用reuseIdentifier來重用cells

2. 盡量使所有的view opaque，包括cell自身
   3)避免漸變，圖片縮放，后臺選人
3. 緩存行高
   5)如果cell內(nèi)現(xiàn)實(shí)的內(nèi)容來自web，使用異步加載，緩存請求結(jié)果
4. 使用shadowPath來畫陰影
   7)減少subviews的數(shù)量
   8)盡量不適用cellForRowAtIndexPath:，如果你需要用到它，只用一次然后緩存結(jié)果
   9)使用正確的數(shù)據(jù)結(jié)構(gòu)來存儲數(shù)據(jù)
   10)使用rowHeight, sectionFooterHeight和 sectionHeaderHeight來設(shè)定固定的高，不要請求delegate
   18：選擇是否緩存圖片
   常見的從bundle中加載圖片的方式有兩種，一個是用imageNamed，二是用imageWithContentsOfFile，第一種比較常見一點(diǎn)。
   既然有兩種類似的方法來實(shí)現(xiàn)相同的目的，那么他們之間的差別是什么呢？
   imageNamed的優(yōu)點(diǎn)是當(dāng)加載時會緩存圖片。imageNamed的文檔中這么說:這個方法用一個指定的名字在系統(tǒng)緩存中查找并返回一個圖片對象如果它存在的話。如果緩存中沒有找到相應(yīng)的圖片，這個方法從指定的文檔中加載然后緩存并返回這個對象。
   相反的，imageWithContentsOfFile僅加載圖片。
   下面的代碼說明了這兩種方法的用法:
   UIImage *img = [UIImage imageNamed:@"myImage"];// caching
   // or
   UIImage *img = [UIImage imageWithContentsOfFile:@"myImage"];// no caching
   那么我們應(yīng)該如何選擇呢？
   如果你要加載一個大圖片而且是一次性使用，那么就沒必要緩存這個圖片，用imageWithContentsOfFile足矣，這樣不會浪費(fèi)內(nèi)存來緩存它。
   然而，在圖片反復(fù)重用的情況下imageNamed是一個好得多的選擇。
   19:避免日期格式轉(zhuǎn)換
   如果你要用NSDateFormatter來處理很多日期格式，應(yīng)該小心以待。就像先前提到的，任何時候重用NSDateFormatters都是一個好的實(shí)踐。
   如果你可以控制你所處理的日期格式，盡量選擇Unix時間戳。你可以方便地從時間戳轉(zhuǎn)換到NSDate:

• (NSDate*)dateFromUnixTimestamp:(NSTimeInterval)timestamp {
  return[NSDate dateWithTimeIntervalSince1970:timestamp];
  }
  需要注意的是，許多web API會以微秒的形式返回時間戳，因?yàn)檫@種格式在javascript中更方便使用。記住用dateFromUnixTimestamp之前除以1000就好了。