1，復用問題:UITableViewCells，UICollectionViewCells,tableView和collectionView的組頭和組尾設置正確的復用標識，充分復用。
2，盡量把Views設置為不透明:opaque這個屬性給渲染系統提供了一個如何處理這個view的提示，如果設為YES，渲染系統就認為這個view是完全不透明的，這使得渲染系統優化一些渲染過程和提高性能。
3，不要使用太復雜的XIB/StoryBoard：載入時就會將XIB/StoryBoard需要的所有資源，包括圖片全部載入內存，即使之后很久才會用到。與那些相比純代碼寫的延遲加載，性能及內存就差了很多。
4，選中正確的數據結構:學會選擇對業務場景最合適的數組結構是寫出高效代碼的基礎。比如：數組:有序的一組值。使用索引來查詢很快，使用值查詢很慢，插入/刪除很慢。字典:存儲鍵值對，用鍵來查找比較快，集合:無序的一組值，用值來查找很快，插入/刪除很快。
5，gizp/zip壓縮:當從服務端下載相關附件時， 可以通過gzip/zip壓縮再下載，使得內存更小，下載速度也更快。
6，延遲加載:對于不應該使用是數據，使用延遲加載方式，對于不需要馬上顯示的視圖，使用延遲加載方式，比如：網絡請求失敗時顯示的提示界面，可能一直都不會使用到，因此應該使用延遲加載。
場景舉例:用戶點擊一個按鈕的時候需要呈現一個view的場景。有兩種實現方法:
(1):創建并隱藏這個view當這個screen加載的時候，當需要的時候顯示他
（2）:當需要時才創建并顯示。
方案一:需要一開始就創建一個View并保持它知道不再使用，會更加消耗內存，然而會使你的app操作更敏感，因為點擊時只需要改變一下這個view的可見性
方案二:消耗更少內存，但是會在點擊按鈕的時候比第一種稍顯卡頓。
7，數據緩存:對于cell的行高要緩存起來，使得reload數據時 ，效率極高。對于那些網絡數據，不需要 每次都請求的，應該緩存起來，可以寫入數據庫，也可以通過plist文件存儲。
8，處理內存警告:一般在基類統一處理內存警告，將相關不用的資源立即釋放掉。
UIKi提供了幾種收集低內存警告的方法
· 在app delegate中使用applicationDidReceiveMemoryWarning:的方法
· 在你的自定義UIViewController的子類(subclass)中覆蓋didReceiveMemoryWarning
· 注冊并接收 UIApplicationDidReceiveMemoryWarningNotification的通知
9，重用大開銷對象:一些對象的初始化很慢，比如:NSDateFormatter和NSCalendar，但又不可避免的需要使用它們，通常是作為屬性存儲起來，防止反復創建。
10，避免反復處理數據:許多應用需要從服務器加載功能所需的常為JSON或者XML格式的數據，在服務器端和客戶端使用相同的數據結構很重要。
11，使用Autorelease Pool：在某些循環創建臨時變量處理數據時，自動釋放池以保證能及時釋放內存。
12，正確選擇圖片加載方式。
在View里放背景圖片就像很多其它iOS編程一樣有很多方法:
使用UIColor的 colorWithPatternImage來設置背景色；
在view中添加一個UIImageView作為一個子View。
如果你使用全畫幅的背景圖，你就必須使用UIImageView因為UIColor的colorWithPatternImage是用來創建小的重復的圖片作為背景的。這種情形下使用UIImageView可以節約不少的內存：
UIImageView *backgroundView = [[UIImageView alloc] initWithImage:[UIImage imageNamed:@"background"]];
[self.view addSubview:backgroundView];
如果你用小圖平鋪來創建背景，你就需要用UIColor的colorWithPatternImage來做了，它會更快地渲染也不會花費很多內存：
self.view.backgroundColor = [UIColor colorWithPatternImage:[UIImage imageNamed:@"background"]];
13，如果要在UIImagView中顯示一個來自bundle的圖片，應該保證圖片的大小和UIImageView的大小相同，在運行中縮放圖片是很耗資源的，特別是UIImageView嵌套在UIScrollView中的情況下。如過圖片是從遠端服務加載的圖片你不能控制圖片大小，可以在下載完成后，最好用background thread，縮放一次，然后在UIImageView中使用縮放后的圖片。
14，caches
NSURLConnection默認會緩存資源在內存或者存儲中根據它所加載的HTTP Headers。你甚至可以手動創建一個NSURLRequest然后使它只加載緩存的值。
下面是一個可用的代碼段，你可以可以用它去為一個基本不會改變的圖片創建一個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類似，不同的是系統回收內存的時候它會自動刪掉它的內容。
15：減少使用web特性
UIWebView很有用，用它來展示網頁內容或者創建UIKit很難做到的動畫效果是很簡單的一件事。但是你可能有注意到UIWebView并不像驅動Safari的那么快。這是由于以JIT compilation為特色的Webkit的Nitro Engine的限制。
所以想要更高的性能你就要調整下你的HTML了。第一件要做的事就是盡可能移除不必要的javascript，避免使用過大的框架。能只用原生js就更好了。
另外，盡可能異步加載例如用戶行為統計script這種不影響頁面表達的javascript。
最后，永遠要注意你使用的圖片，保證圖片的符合你使用的大小。使用Sprite sheet提高加載速度和節約內存。
16:設定Shadow Path
如何在一個View或者一個layer上加一個shadow呢，QuartzCore框架是很多開發者的選擇：
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就不必每次都計算如何渲染，它使用一個預先計算好的路徑。但問題是自己計算path的話可能在某些View中比較困難，且每當view的frame變化的時候你都需要去update shadow path.
17：優化tableView
為了保證table view平滑滾動，確保你采取了以下的措施:
1)正確使用reuseIdentifier來重用cells
- 盡量使所有的view opaque，包括cell自身
3)避免漸變，圖片縮放，后臺選人 - 緩存行高
5)如果cell內現實的內容來自web，使用異步加載，緩存請求結果 - 使用
shadowPath來畫陰影
7)減少subviews的數量
8)盡量不適用cellForRowAtIndexPath:，如果你需要用到它，只用一次然后緩存結果
9)使用正確的數據結構來存儲數據
10)使用rowHeight,sectionFooterHeight和sectionHeaderHeight來設定固定的高，不要請求delegate
18：選擇是否緩存圖片
常見的從bundle中加載圖片的方式有兩種，一個是用imageNamed，二是用imageWithContentsOfFile，第一種比較常見一點。
既然有兩種類似的方法來實現相同的目的，那么他們之間的差別是什么呢？
imageNamed的優點是當加載時會緩存圖片。imageNamed的文檔中這么說:這個方法用一個指定的名字在系統緩存中查找并返回一個圖片對象如果它存在的話。如果緩存中沒有找到相應的圖片，這個方法從指定的文檔中加載然后緩存并返回這個對象。
相反的，imageWithContentsOfFile僅加載圖片。
下面的代碼說明了這兩種方法的用法:
UIImage *img = [UIImage imageNamed:@"myImage"];// caching
// or
UIImage *img = [UIImage imageWithContentsOfFile:@"myImage"];// no caching
那么我們應該如何選擇呢？
如果你要加載一個大圖片而且是一次性使用，那么就沒必要緩存這個圖片，用imageWithContentsOfFile足矣，這樣不會浪費內存來緩存它。
然而，在圖片反復重用的情況下imageNamed是一個好得多的選擇。
19:避免日期格式轉換
如果你要用NSDateFormatter來處理很多日期格式，應該小心以待。就像先前提到的，任何時候重用NSDateFormatters都是一個好的實踐。
如果你可以控制你所處理的日期格式，盡量選擇Unix時間戳。你可以方便地從時間戳轉換到NSDate:
- (NSDate*)dateFromUnixTimestamp:(NSTimeInterval)timestamp {
return[NSDate dateWithTimeIntervalSince1970:timestamp];
}
需要注意的是，許多web API會以微秒的形式返回時間戳，因為這種格式在javascript中更方便使用。記住用dateFromUnixTimestamp之前除以1000就好了。
