iOS應用程序中的性能優化

文章出出:http://www.code4app.com/blog-826368-158.html

 

應用程序中的性能對 iOS 應用的開發來講尤爲重要，若是一個應用失去反應或者很慢，失望的用戶會把他們的失望寫滿App Store的評論。然而因爲iOS設備的限制，想處理好應用程序中的性能是一件難事。咱們在開發過程當中會有不少地方是須要注意的，固然也很容易在作出選擇時忘記考慮性能影響。

一、在應用程序中正確的地方使用：ReuseIdentifier

 

 

 

咱們在開發中常見的錯誤就是沒有給UITableViewCells， UICollectionViewCells，甚至是UITableViewHeaderFooterViews設置正確的reuseIdentifier。

 

在優化性能時，table view用 `tableView:cellForRowAtIndexPath:` 爲rows分配cells的時候，它的數據應該重用自UITableViewCell。 一個table view維持一個隊列的數據可重用的UITableViewCell對象。固然若是不使用reuseIdentifier的話，每顯示一行table view就須要設置全新的cell。這樣一來對應用程序性能的影響很是的大，特別會使app的滾動體驗大大的下降。

 

從iOS6起，除了對UICollectionView的cells和補充views，也應該在header和footer views中使用reuseIdentifiers，使用reuseIdentifiers的話，在一個table view中添加一個新的cell時在data source 方法中添加這個方法：

 

static NSString *ID = @"MyCell";

 

    UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:ID];

 

這個方法能夠把那些已經存在的cell從隊列中排除，或者在必要時使用先前註冊的nib或者class創造新的cell。若是沒有可重用的cell，也沒有註冊一個class或者nib的話，這個方法就會返回nil。

二、在開發的過程當中要儘可能把Views設置爲透明色：

 

 

 

若是應用中有透明的Views咱們應該設置它們的opaque屬性爲YES。

其緣由是這樣會使系統用一個最優的方式渲染這些views。這個屬性在IB或者代碼裏均可以設定。

Apple的文檔對於爲圖片設置透明屬性的描述是：

(opaque)這個屬性給渲染系統提供了一個如何處理這個view的提示。若是設爲YES， 渲染系統就認爲這個view是徹底不透明的，這使得渲染系統優化一些渲染過程和提升性能。若是設置爲NO，渲染系統正常地和其它內容組成這個View。默認值是YES。

在相對比較靜止的畫面中，設置這個屬性不會有太大影響。然而當這個view嵌在scroll view裏邊，或者是一個複雜動畫的一部分，不設置這個屬性的話會在很大程度上影響app的性能。因此咱們能夠在模擬器中用Debug\Color Blended Layers選項來發現哪些view沒有被設置爲opaque。目標就是，能設爲opaque的就全設爲opaque!

三、在ImageView中調整圖片的大小：

 

若是要在`UIImageView`中顯示一個來自bundle的圖片，你應保證圖片的大小和UIImageView的大小相同。在運行中縮放圖片是很耗費資源的，特別是`UIImageView`嵌套在`UIScrollView`中的狀況下。

若是圖片是從遠端服務加載的你不能控制圖片大小，好比在下載前調整到合適大小的話，你能夠在下載完成後，最好是用background thread，縮放一次，而後在UIImageView中使用縮放後的圖片。

四、選擇正確的數據格式：

從app和網絡服務間傳輸數據有不少方案，最多見的就是JSON和XML。若是讓咱們選擇對app來講最合適的一個，那麼解析JSON會比XML更快一些，JSON也一般更小更便於傳輸。從iOS5起就有了官方內建的JSON deserialization 就更加方便使用了。

可是使用XML也有XML的好處，好比使用SAX 來解析XML就像解析本地文件同樣，咱們不需像解析json同樣等到整個文檔下載完成纔開始解析，那麼當咱們處理很大的數據的時候就會極大地減低內存消耗和增長性能。

XML的解析方式：

①DOM解析：是將文檔一次性所有下載到本地在按節點進行解析，這樣對咱們的應用程序的內存消耗極大，手機自己的內存就不是很大，不像電腦那樣有很大的內存，可見這種解析方式不太適用於手機，即手機沒法直接使用 DOM 的方式來解析 XML；

②SAX解析：是一種只讀的方式，在文檔中按照節點從上之下的方式來進行解析，是蘋果提供的解析方式，雖然節點是一次性讀取的，可是節點中的內容是屢次讀取的，這種解析方式的速度至關的快，能夠用 NSXMLParser 經過 代理 方法來實現解析；

SAX解析方式的步驟：

①開始文檔—準備工做

②開始"節點"

③發現節點內部的內容，每個節點，可能都須要屢次解析才能完成

④結束"節點"

⑤結束文檔—解析結束

以上步驟，②、③、④會不斷循環，一直到全部的解析完成。

五、避免反覆處理數據：

咱們的應用須要從服務器加載所需的經常使用的JSON或者XML格式的數據。在服務器端和客戶端使用相同的數據結構很重要。在內存中操做數據使它們知足咱們的數據結構開銷很大的。

譬如咱們須要數據來展現一個table view,最好直接從服務器取array結構的數據以免額外的中間數據結構改變。類似的，若是須要從特定key中取數據，那麼就使用鍵值對的dictionary。

六、對tableView的優化：

Table view須要有很好的滾動性能，要不用戶會在滾動過程當中發現動畫的弊端，爲了保證table view可以平滑滾動，咱們能夠採起如下的措施:

• ·       正確使用`reuseIdentifier`來重用cells
• ·       儘可能使全部的view opaque，包括cell自身
• ·       避免漸變，圖片縮放，後臺選人
• ·       緩存行高
• ·       若是cell內現實的內容來自web，使用異步加載，緩存請求結果
• ·       使用`shadowPath`來畫陰影
• ·       減小subviews的數量
• ·       儘可能不適用`cellForRowAtIndexPath:`，若是你須要用到它，只用一次而後緩存結果
• ·       使用正確的數據結構來存儲數據

使用`rowHeight`, `sectionFooterHeight` 和 `sectionHeaderHeight`來設定固定的高，不要請求delegate

七、用戶響應：

①用戶響應，即APP用戶所觸發的操做都能獲得馬上響應，即用戶事件可以被主線程的Run Loop獲得及時的處理；

②要讓主線程的Run Loop更好的響應用戶的事件，咱們應該儘可能減小在主線程作複雜的操做的時間，尤爲是I/O操做，網絡操做，大量複雜的運算等，這類操做務必不要在主線程中執行。

八、內存管理的優化：

①合理的利用緩存機制，能夠有效的減少設備內存的佔用率，從而來下降內存溢出的機率和崩潰率；    ②及時的處理內存警告；    ③對大數據的內存管理：從網絡中獲取的大文件不要直接保存到內存中，能夠合理的利用沙盒的緩存機制，來減少對內存的壓力； ④大量的循環建立臨時變量時的內存管理：若是須要大量的且循環的建立臨時的變量，咱們就須要在循環開始的時候就建立自動釋放池； ⑤對圖片/大文件的壓縮處理：咱們在作圖片上傳的時候，能夠先把圖片壓縮後在保存或者上傳； ⑥減小UIWebView的應用：由於其對內存的佔用率是至關高的。

九、對數據壓縮：大的數據能夠採用壓縮返回，減小用戶流量的消耗，加快APP的反映速度

十、對數據庫的優化：①在數據庫的設計上面能夠作一些重構；   ②對查詢語句的一些優化；     ③若是數據過多，咱們能夠把其分紅不一樣的表或者庫

十一、從代碼的規範上： ①這個能夠用隱形的方式來提升APP的性能，譬如：用if   else   仍是用 Switch；    ②CodeReview（要堅持用CodeReview來對代碼進行持續的重構，從而減小代碼的邏輯複雜度）。

十二、要避免過於使用龐大的XIB:XIB和StoryBoard的本質就是XML文件，解析這樣的文件是至關的耗費性能的。

1三、對重用的View進行封裝：若是過多的建立View的話，就意味着會消耗更多的性能，因此要對重用的View進行封裝

1四、避免進行大量的日期格式的轉換：頻繁的轉換日期的格式對APP來講消耗的性能也是很大的

1五、對控件的渲染：若是要作一個特殊樣式的按鈕的話，咱們能夠事先將渲染好的圖片設置到按鈕上，這個圖片放在Bundle裏面，而後跟着咱們的APP進行一塊兒打包，這樣就避免了畫個圖形讓後再顯示到APP的屏幕上去。