由于iOS設(shè)備的限制突硝，想處理好應(yīng)用程序中的性能是一件難事特铝。我們在開發(fā)過程中會有很多地方是需要注意的祭衩，當(dāng)然也很容易在做出選擇時忘記考慮性能影響嚼摩。
對tableView的優(yōu)化：
UITableView作為iOS開發(fā)中最重要的控件之一,為了獲得更好的滑動性能,我們可以采取以下的措施:
·正確使用`reuseIdentifier`來重用cells
·盡量使所有的view opaque钦讳，包括cell自身
·如果cell內(nèi)現(xiàn)實(shí)的內(nèi)容來自web，使用異步加載枕面，緩存請求結(jié)果
·避免漸變愿卒，圖片縮放
·使用`shadowPath`來畫陰影
·緩存行高
·減少subviews的數(shù)量
·盡量不適用`cellForRowAtIndexPath:`，如果你需要用到它潮秘，只用一次然后緩存結(jié)果
·使用正確的數(shù)據(jù)結(jié)構(gòu)來存儲數(shù)據(jù)
·盡量少于或者不用透明圖層
以下是詳細(xì)的介紹:
1琼开、在應(yīng)用程序中正確的地方使用：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對象。當(dāng)然如果不使用reuseIdentifier的話玉控，每顯示一行table view就需要設(shè)置全新的cell飞主。這樣一來對應(yīng)用程序性能的影響非常的大，特別會使app的滾動體驗(yàn)大大的降低高诺。
從iOS6起碌识，除了對UICollectionView的cells和補(bǔ)充views，也應(yīng)該在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設(shè)置為透明色：
如果應(yīng)用中有透明的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選項(xiàng)來發(fā)現(xiàn)哪些view沒有被設(shè)置為opaque。目標(biāo)就是葵陵，能設(shè)為opaque的就全設(shè)為opaque!
3液荸、在ImageView中調(diào)整圖片的大小：
如果要在`UIImageView`中顯示一個來自bundle的圖片脱篙，你應(yīng)保證圖片的大小和UIImageView的大小相同娇钱。在運(yùn)行中縮放圖片是很耗費(fèi)資源的，特別是`UIImageView`嵌套在`UIScrollView`中的情況下绊困。
如果圖片是從遠(yuǎn)端服務(wù)加載的你不能控制圖片大小文搂，比如在下載前調(diào)整到合適大小的話，你可以在下載完成后秤朗，最好是用background thread煤蹭，縮放一次，然后在UIImageView中使用縮放后的圖片。
4硝皂、選擇正確的數(shù)據(jù)格式：
從app和網(wǎng)絡(luò)服務(wù)間傳輸數(shù)據(jù)有很多方案常挚，最常見的就是JSON和XML。如果讓我們選擇對app來說最合適的一個稽物，那么解析JSON會比XML更快一些奄毡，JSON也通常更小更便于傳輸。從iOS5起就有了官方內(nèi)建的JSON deserialization就更加方便使用了贝或。
但是使用XML也有XML的好處吼过，比如使用SAX來解析XML就像解析本地文件一樣，我們不需像解析json一樣等到整個文檔下載完成才開始解析咪奖，那么當(dāng)我們處理很大的數(shù)據(jù)的時候就會極大地減低內(nèi)存消耗和增加性能盗忱。
XML的解析方式：
①DOM解析：是將文檔一次性全部下載到本地在按節(jié)點(diǎn)進(jìn)行解析，這樣對我們的應(yīng)用程序的內(nèi)存消耗極大羊赵，手機(jī)本身的內(nèi)存就不是很大趟佃，不像電腦那樣有很大的內(nèi)存，可見這種解析方式不太適用于手機(jī)慷垮，即手機(jī)無法直接使用 DOM 的方式來解析 XML揖闸；
②SAX解析：是一種只讀的方式，在文檔中按照節(jié)點(diǎn)從上之下的方式來進(jìn)行解析料身，是蘋果提供的解析方式汤纸，雖然節(jié)點(diǎn)是一次性讀取的，但是節(jié)點(diǎn)中的內(nèi)容是多次讀取的芹血，這種解析方式的速度相當(dāng)?shù)目熘ⅲ梢杂肗SXMLParser通過代理方法來實(shí)現(xiàn)解析；
SAX解析方式的步驟：
①開始文檔—準(zhǔn)備工作
②開始"節(jié)點(diǎn)"
③發(fā)現(xiàn)節(jié)點(diǎn)內(nèi)部的內(nèi)容幔烛，每一個節(jié)點(diǎn)啃擦，可能都需要多次解析才能完成
④結(jié)束"節(jié)點(diǎn)"
⑤結(jié)束文檔—解析結(jié)束
以上步驟，②饿悬、③令蛉、④會不斷循環(huán)，一直到所有的解析完成狡恬。
5珠叔、避免反復(fù)處理數(shù)據(jù)：
我們的應(yīng)用需要從服務(wù)器加載所需的常用的JSON或者XML格式的數(shù)據(jù)。在服務(wù)器端和客戶端使用相同的數(shù)據(jù)結(jié)構(gòu)很重要弟劲。在內(nèi)存中操作數(shù)據(jù)使它們滿足我們的數(shù)據(jù)結(jié)構(gòu)開銷很大的祷安。
譬如我們需要數(shù)據(jù)來展示一個table view,最好直接從服務(wù)器取array結(jié)構(gòu)的數(shù)據(jù)以避免額外的中間數(shù)據(jù)結(jié)構(gòu)改變。相似的兔乞，如果需要從特定key中取數(shù)據(jù)汇鞭，那么就使用鍵值對的dictionary凉唐。
如果以上總結(jié)有欠缺的地方,請大神多多指教.
github: iOS_愚非愚余 歡迎star..? ? ??
參考iOS開發(fā)進(jìn)階,感謝xiao66guo;
