本文章轉(zhuǎn)載于搜狗測(cè)試

1、在應(yīng)用程序中正確的地方使用：ReuseIdentifier

我們?cè)陂_(kāi)發(fā)中常見(jiàn)的錯(cuò)誤就是沒(méi)有給UITableViewCells， UICollectionViewCells，甚至是UITableViewHeaderFooterViews設(shè)置正確的reuseIdentifier。

在優(yōu)化性能時(shí)，table view用 `tableView:cellForRowAtIndexPath:` 為rows分配cells的時(shí)候，它的數(shù)據(jù)應(yīng)該重用自UITableViewCell。 一個(gè)table view維持一個(gè)隊(duì)列的數(shù)據(jù)可重用的UITableViewCell對(duì)象。當(dāng)然如果不使用reuseIdentifier的話，每顯示一行table view就需要設(shè)置全新的cell。這樣一來(lái)對(duì)應(yīng)用程序性能的影響非常的大，特別會(huì)使app的滾動(dòng)體驗(yàn)大大的降低。

從iOS6起，除了對(duì)UICollectionView的cells和補(bǔ)充views，也應(yīng)該在header和footer views中使用reuseIdentifiers，使用reuseIdentifiers的話，在一個(gè)table view中添加一個(gè)新的cell時(shí)在data source 方法中添加這個(gè)方法：

static NSString *ID = @"MyCell";

UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:ID];

這個(gè)方法可以把那些已經(jīng)存在的cell從隊(duì)列中排除，或者在必要時(shí)使用先前注冊(cè)的nib或者class創(chuàng)造新的cell。如果沒(méi)有可重用的cell，也沒(méi)有注冊(cè)一個(gè)class或者nib的話，這個(gè)方法就會(huì)返回nil。

2、在開(kāi)發(fā)的過(guò)程中要盡量把Views設(shè)置為透明色：

如果應(yīng)用中有透明的Views我們應(yīng)該設(shè)置它們的opaque屬性為YES。

其原因是這樣會(huì)使系統(tǒng)用一個(gè)最優(yōu)的方式渲染這些views。這個(gè)屬性在IB或者代碼里都可以設(shè)定。

Apple的文檔對(duì)于為圖片設(shè)置透明屬性的描述是：

(opaque)這個(gè)屬性給渲染系統(tǒng)提供了一個(gè)如何處理這個(gè)view的提示。如果設(shè)為YES， 渲染系統(tǒng)就認(rèn)為這個(gè)view是完全不透明的，這使得渲染系統(tǒng)優(yōu)化一些渲染過(guò)程和提高性能。如果設(shè)置為NO，渲染系統(tǒng)正常地和其它內(nèi)容組成這個(gè)View。默認(rèn)值是YES。

在相對(duì)比較靜止的畫(huà)面中，設(shè)置這個(gè)屬性不會(huì)有太大影響。然而當(dāng)這個(gè)view嵌在scroll view里邊，或者是一個(gè)復(fù)雜動(dòng)畫(huà)的一部分，不設(shè)置這個(gè)屬性的話會(huì)在很大程度上影響app的性能。所以我們可以在模擬器中用Debug\Color Blended Layers選項(xiàng)來(lái)發(fā)現(xiàn)哪些view沒(méi)有被設(shè)置為opaque。目標(biāo)就是，能設(shè)為opaque的就全設(shè)為opaque!

3、在ImageView中調(diào)整圖片的大?。?/b>

如果要在`UIImageView`中顯示一個(gè)來(lái)自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ù)有很多方案，最常見(jiàn)的就是JSON和XML。如果讓我們選擇對(duì)app來(lái)說(shuō)最合適的一個(gè)，那么解析JSON會(huì)比XML更快一些，JSON也通常更小更便于傳輸。從iOS5起就有了官方內(nèi)建的JSON deserialization 就更加方便使用了。

但是使用XML也有XML的好處，比如使用SAX 來(lái)解析XML就像解析本地文件一樣，我們不需像解析json一樣等到整個(gè)文檔下載完成才開(kāi)始解析，那么當(dāng)我們處理很大的數(shù)據(jù)的時(shí)候就會(huì)極大地減低內(nèi)存消耗和增加性能。

XML的解析方式：

①DOM解析：是將文檔一次性全部下載到本地在按節(jié)點(diǎn)進(jìn)行解析，這樣對(duì)我們的應(yīng)用程序的內(nèi)存消耗極大，手機(jī)本身的內(nèi)存就不是很大，不像電腦那樣有很大的內(nèi)存，可見(jiàn)這種解析方式不太適用于手機(jī)，即手機(jī)無(wú)法直接使用 DOM 的方式來(lái)解析 XML；

②SAX解析：是一種只讀的方式，在文檔中按照節(jié)點(diǎn)從上之下的方式來(lái)進(jìn)行解析，是蘋(píng)果提供的解析方式，雖然節(jié)點(diǎn)是一次性讀取的，但是節(jié)點(diǎn)中的內(nèi)容是多次讀取的，這種解析方式的速度相當(dāng)?shù)目?，可以?NSXMLParser 通過(guò) 代理 方法來(lái)實(shí)現(xiàn)解析；

SAX解析方式的步驟：

①開(kāi)始文檔—準(zhǔn)備工作

②開(kāi)始"節(jié)點(diǎn)"

③發(fā)現(xiàn)節(jié)點(diǎn)內(nèi)部的內(nèi)容，每一個(gè)節(jié)點(diǎn)，可能都需要多次解析才能完成

④結(jié)束"節(jié)點(diǎn)"

⑤結(jié)束文檔—解析結(jié)束

以上步驟，②、③、④會(huì)不斷循環(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)開(kāi)銷(xiāo)很大的。

譬如我們需要數(shù)據(jù)來(lái)展示一個(gè)table view,最好直接從服務(wù)器取array結(jié)構(gòu)的數(shù)據(jù)以避免額外的中間數(shù)據(jù)結(jié)構(gòu)改變。相似的，如果需要從特定key中取數(shù)據(jù)，那么就使用鍵值對(duì)的dictionary。

6、對(duì)tableView的優(yōu)化：

Table view需要有很好的滾動(dòng)性能，要不用戶會(huì)在滾動(dòng)過(guò)程中發(fā)現(xiàn)動(dòng)畫(huà)的弊端，為了保證table view能夠平滑滾動(dòng)，我們可以采取以下的措施:

· ? ? ? 正確使用`reuseIdentifier`來(lái)重用cells

· ? ? ? 盡量使所有的view opaque，包括cell自身

· ? ? ? 避免漸變，圖片縮放，后臺(tái)選人

· ? ? ? 緩存行高

· ? ? ? 如果cell內(nèi)現(xiàn)實(shí)的內(nèi)容來(lái)自web，使用異步加載，緩存請(qǐng)求結(jié)果

· ? ? ? 使用`shadowPath`來(lái)畫(huà)陰影

· ? ? ? 減少subviews的數(shù)量

· ? ? ? 盡量不適用`cellForRowAtIndexPath:`，如果你需要用到它，只用一次然后緩存結(jié)果

· ? ? ? 使用正確的數(shù)據(jù)結(jié)構(gòu)來(lái)存儲(chǔ)數(shù)據(jù)

使用`rowHeight`, `sectionFooterHeight` 和 `sectionHeaderHeight`來(lái)設(shè)定固定的高，不要請(qǐng)求delegate

7、用戶響應(yīng)：

①用戶響應(yīng)，即APP用戶所觸發(fā)的操作都能得到立刻響應(yīng)，即用戶事件能夠被主線程的Run Loop得到及時(shí)的處理；

②要讓主線程的Run Loop更好的響應(yīng)用戶的事件，我們應(yīng)該盡量減少在主線程做復(fù)雜的操作的時(shí)間，尤其是I/O操作，網(wǎng)絡(luò)操作，大量復(fù)雜的運(yùn)算等，這類(lèi)操作務(wù)必不要在主線程中執(zhí)行。

8、內(nèi)存管理的優(yōu)化：

①合理的利用緩存機(jī)制，可以有效的減小設(shè)備內(nèi)存的占用率，從而來(lái)降低內(nèi)存溢出的概率和崩潰率； ? ?②及時(shí)的處理內(nèi)存警告； ? ?③對(duì)大數(shù)據(jù)的內(nèi)存管理：從網(wǎng)絡(luò)中獲取的大文件不要直接保存到內(nèi)存中，可以合理的利用沙盒的緩存機(jī)制，來(lái)減小對(duì)內(nèi)存的壓力；④大量的循環(huán)創(chuàng)建臨時(shí)變量時(shí)的內(nèi)存管理：如果需要大量的且循環(huán)的創(chuàng)建臨時(shí)的變量，我們就需要在循環(huán)開(kāi)始的時(shí)候就創(chuàng)建自動(dòng)釋放池；⑤對(duì)圖片/大文件的壓縮處理：我們?cè)谧鰣D片上傳的時(shí)候，可以先把圖片壓縮后在保存或者上傳；⑥減少UIWebView的應(yīng)用：因?yàn)槠鋵?duì)內(nèi)存的占用率是相當(dāng)高的。

9、對(duì)數(shù)據(jù)壓縮：

大的數(shù)據(jù)可以采用壓縮返回，減少用戶流量的消耗，加快APP的反映速度

10、對(duì)數(shù)據(jù)庫(kù)的優(yōu)化：

①在數(shù)據(jù)庫(kù)的設(shè)計(jì)上面可以做一些重構(gòu)；

②對(duì)查詢語(yǔ)句的一些優(yōu)化；

③如果數(shù)據(jù)過(guò)多，我們可以把其分成不同的表或者庫(kù)

11、從代碼的規(guī)范上：

①這個(gè)可以用隱形的方式來(lái)提高APP的性能，譬如：用if ? else ? 還是用 Switch；

②CodeReview（要堅(jiān)持用CodeReview來(lái)對(duì)代碼進(jìn)行持續(xù)的重構(gòu)，從而減少代碼的邏輯復(fù)雜度）。

12、要避免過(guò)于使用龐大的XIB:

XIB和StoryBoard的本質(zhì)就是XML文件，解析這樣的文件是相當(dāng)?shù)暮馁M(fèi)性能的。

13、對(duì)重用的View進(jìn)行封裝：

如果過(guò)多的創(chuàng)建View的話，就意味著會(huì)消耗更多的性能，所以要對(duì)重用的View進(jìn)行封裝

14、避免進(jìn)行大量的日期格式的轉(zhuǎn)換：

頻繁的轉(zhuǎn)換日期的格式對(duì)APP來(lái)說(shuō)消耗的性能也是很大的

15、對(duì)控件的渲染：

如果要做一個(gè)特殊樣式的按鈕的話，我們可以事先將渲染好的圖片設(shè)置到按鈕上，這個(gè)圖片放在Bundle里面，然后跟著我們的APP進(jìn)行一起打包，這樣就避免了畫(huà)個(gè)圖形讓后再顯示到APP的屏幕上去。