本文章轉(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ì)比較靜止的畫面中嗓蘑，設(shè)置這個(gè)屬性不會(huì)有太大影響峻汉。然而當(dāng)這個(gè)view嵌在scroll view里邊，或者是一個(gè)復(fù)雜動(dòng)畫的一部分脐往，不設(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)整圖片的大小：

如果要在`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)行解析漓摩，是蘋果提供的解析方式，雖然節(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)銷很大的。

譬如我們需要數(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)畫的弊端兴泥，為了保證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)畫陰影

· ? ? ? 減少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)算等，這類操作務(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)行一起打包震放，這樣就避免了畫個(gè)圖形讓后再顯示到APP的屏幕上去宾毒。