由于iOS設備的限制，想處理好應用程序中的性能是一件難事。我們在開發(fā)過程中會有很多地方是需要注意的，當然也很容易在做出選擇時忘記考慮性能影響。
對tableView的優(yōu)化：
UITableView作為iOS開發(fā)中最重要的控件之一,為了獲得更好的滑動性能,我們可以采取以下的措施:
·正確使用`reuseIdentifier`來重用cells
·盡量使所有的view opaque，包括cell自身
·如果cell內現(xiàn)實的內容來自web，使用異步加載，緩存請求結果
·避免漸變，圖片縮放
·使用`shadowPath`來畫陰影
·緩存行高
·減少subviews的數(shù)量
·盡量不適用`cellForRowAtIndexPath:`，如果你需要用到它，只用一次然后緩存結果
·使用正確的數(shù)據(jù)結構來存儲數(shù)據(jù)
·盡量少于或者不用透明圖層
以下是詳細的介紹:
1、在應用程序中正確的地方使用：ReuseIdentifier
我們在開發(fā)中常見的錯誤就是沒有給UITableViewCells，UICollectionViewCells，甚至是UITableViewHeaderFooterViews設置正確的reuseIdentifier。
在優(yōu)化性能時，table view用`tableView:cellForRowAtIndexPath:`為rows分配cells的時候，它的數(shù)據(jù)應該重用自UITableViewCell。一個table view維持一個隊列的數(shù)據(jù)可重用的UITableViewCell對象。當然如果不使用reuseIdentifier的話，每顯示一行table view就需要設置全新的cell。這樣一來對應用程序性能的影響非常的大，特別會使app的滾動體驗大大的降低。
從iOS6起，除了對UICollectionView的cells和補充views，也應該在header和footer views中使用reuseIdentifiers，使用reuseIdentifiers的話，在一個table view中添加一個新的cell時在data source 方法中添加這個方法：
staticNSString*ID =@"MyCell";
UITableViewCell*cell = [tableViewdequeueReusableCellWithIdentifier:ID];
這個方法可以把那些已經(jīng)存在的cell從隊列中排除，或者在必要時使用先前注冊的nib或者class創(chuàng)造新的cell。如果沒有可重用的cell，也沒有注冊一個class或者nib的話，這個方法就會返回nil。
2、在開發(fā)的過程中要盡量把Views設置為透明色：
如果應用中有透明的Views我們應該設置它們的opaque屬性為YES。
其原因是這樣會使系統(tǒng)用一個最優(yōu)的方式渲染這些views。這個屬性在IB或者代碼里都可以設定。
Apple的文檔對于為圖片設置透明屬性的描述是：
(opaque)這個屬性給渲染系統(tǒng)提供了一個如何處理這個view的提示。如果設為YES，渲染系統(tǒng)就認為這個view是完全不透明的，這使得渲染系統(tǒng)優(yōu)化一些渲染過程和提高性能。如果設置為NO，渲染系統(tǒng)正常地和其它內容組成這個View。默認值是YES。
在相對比較靜止的畫面中，設置這個屬性不會有太大影響。然而當這個view嵌在scroll view里邊，或者是一個復雜動畫的一部分，不設置這個屬性的話會在很大程度上影響app的性能。所以我們可以在模擬器中用Debug\Color Blended Layers選項來發(fā)現(xiàn)哪些view沒有被設置為opaque。目標就是，能設為opaque的就全設為opaque!
3、在ImageView中調整圖片的大?。?/b>
如果要在`UIImageView`中顯示一個來自bundle的圖片，你應保證圖片的大小和UIImageView的大小相同。在運行中縮放圖片是很耗費資源的，特別是`UIImageView`嵌套在`UIScrollView`中的情況下。
如果圖片是從遠端服務加載的你不能控制圖片大小，比如在下載前調整到合適大小的話，你可以在下載完成后，最好是用background thread，縮放一次，然后在UIImageView中使用縮放后的圖片。
4、選擇正確的數(shù)據(jù)格式：
從app和網(wǎng)絡服務間傳輸數(shù)據(jù)有很多方案，最常見的就是JSON和XML。如果讓我們選擇對app來說最合適的一個，那么解析JSON會比XML更快一些，JSON也通常更小更便于傳輸。從iOS5起就有了官方內建的JSON deserialization就更加方便使用了。
但是使用XML也有XML的好處，比如使用SAX來解析XML就像解析本地文件一樣，我們不需像解析json一樣等到整個文檔下載完成才開始解析，那么當我們處理很大的數(shù)據(jù)的時候就會極大地減低內存消耗和增加性能。
XML的解析方式：
①DOM解析：是將文檔一次性全部下載到本地在按節(jié)點進行解析，這樣對我們的應用程序的內存消耗極大，手機本身的內存就不是很大，不像電腦那樣有很大的內存，可見這種解析方式不太適用于手機，即手機無法直接使用 DOM 的方式來解析 XML；
②SAX解析：是一種只讀的方式，在文檔中按照節(jié)點從上之下的方式來進行解析，是蘋果提供的解析方式，雖然節(jié)點是一次性讀取的，但是節(jié)點中的內容是多次讀取的，這種解析方式的速度相當?shù)目?，可以用NSXMLParser通過代理方法來實現(xiàn)解析；
SAX解析方式的步驟：
①開始文檔—準備工作
②開始"節(jié)點"
③發(fā)現(xiàn)節(jié)點內部的內容，每一個節(jié)點，可能都需要多次解析才能完成
④結束"節(jié)點"
⑤結束文檔—解析結束
以上步驟，②、③、④會不斷循環(huán)，一直到所有的解析完成。
5、避免反復處理數(shù)據(jù)：
我們的應用需要從服務器加載所需的常用的JSON或者XML格式的數(shù)據(jù)。在服務器端和客戶端使用相同的數(shù)據(jù)結構很重要。在內存中操作數(shù)據(jù)使它們滿足我們的數(shù)據(jù)結構開銷很大的。
譬如我們需要數(shù)據(jù)來展示一個table view,最好直接從服務器取array結構的數(shù)據(jù)以避免額外的中間數(shù)據(jù)結構改變。相似的，如果需要從特定key中取數(shù)據(jù)，那么就使用鍵值對的dictionary。
如果以上總結有欠缺的地方,請大神多多指教.
github: iOS_愚非愚余 歡迎star..? ? ??
參考iOS開發(fā)進階,感謝xiao66guo;
