性能優(yōu)化

1.如何讓你的應(yīng)用程序更加省電死嗦？

答：(1)如果程序用到定位，需要在定位完畢之后關(guān)閉定位牡辽，或者降低定位的頻率喳篇，不停的定位會消耗電量。(2)如果用到了藍(lán)牙态辛，需要使用藍(lán)牙時候開啟藍(lán)牙麸澜，藍(lán)牙用完之后關(guān)閉藍(lán)牙，藍(lán)牙也很耗電奏黑。(3)優(yōu)化算法炊邦，減少循環(huán)次數(shù)编矾，大量循環(huán)會讓CPU一直處于忙碌狀態(tài)，特別費(fèi)電馁害。(4)不要使用網(wǎng)絡(luò)輪詢窄俏，使用推送。(5)timer的時間間隔不宜太短碘菜，滿足需求即可凹蜈。(5)不要頻繁刷新頁面，能刷新1行cell忍啸，不要reloadData仰坦。(6)切勿讓屏幕長亮。(7)線程適量计雌，不宜過多缎岗。

57.簡單描述你一下在開發(fā)的過程中，如何實現(xiàn)程序的性能優(yōu)化白粉？

答：我在開發(fā)的過程中會注意一下幾點(diǎn)來優(yōu)化程序性能：

1.避免龐大的XIB

2.使用懶加載的方式延遲加載界面

3.避免反復(fù)處理數(shù)據(jù)

4.避免使用NSDateFormatter和NSCalendar传泊。

5.圖片緩存的取舍

UIImage加載圖片方式一般有兩種:

A：imagedNamed初始化

B：imageWithContentsOfFile初始化

二者不同之處在于,imageNamed默認(rèn)加載圖片成功后會內(nèi)存中緩存圖片,這個方法用一個指定的名字在系統(tǒng)緩存中查找并返回一個圖片對象.如果緩存中沒有找到相應(yīng)的圖片對象,則從指定地方加載圖片然后緩存對象，并返回這個圖片對象.

而imageWithContentsOfFile則僅只加載圖片,不緩存.

大量使用imageNamed方式會在不需要緩存的地方額外增加開銷CPU的時間來做這件事.當(dāng)應(yīng)用程序需要加載一張比較大的圖片并且使用一次性鸭巴，那么其實是沒有必要去緩存這個圖片的眷细，用imageWithContentsOfFile是最為經(jīng)濟(jì)的方式,這樣不會因為UIImage元素較多情況下，CPU會被逐個分散在不必要緩存上浪費(fèi)過多時間.使用場景需要編程時鹃祖，應(yīng)該根據(jù)實際應(yīng)用場景加以區(qū)分溪椎，UIImage雖小，但使用元素較多問題會有所凸顯.

8恬口、tableView的重用機(jī)制校读？

查看UITableView頭文件，會找到NSMutableArray* visiableCells祖能，和NSMutableDictnery*reusableTableCells兩個結(jié)構(gòu)歉秫。visiableCells內(nèi)保存當(dāng)前顯示的cells，reusableTableCells保存可重用的cells养铸。

TableView顯示之初雁芙，reusableTableCells為空，那么tableViewdequeueReusableCellWithIdentifier:CellIdentifier返回nil钞螟。開始的cell都是通過[[UITableViewCell alloc]initWithStyle:UITableViewCellStyleDefault reuseIdentifier:CellIdentifier]來創(chuàng)建兔甘，而且cellForRowAtIndexPath只是調(diào)用最大顯示cell數(shù)的次數(shù)。

比如：有100條數(shù)據(jù)鳞滨，iPhone一屏最多顯示10個cell洞焙。程序最開始顯示TableView的情況是：

1.用[[UITableViewCellalloc] initWithStyle:UITableViewCellStyleDefaultreuseIdentifier:CellIdentifier]創(chuàng)建10次cell，并給cell指定同樣的重用標(biāo)識(當(dāng)然，可以為不同顯示類型的cell指定不同的標(biāo)識)澡匪。并且10個cell全部都加入到visiableCells數(shù)組熔任，reusableTableCells為空。

2.向下拖動tableView仙蛉，當(dāng)cell1完全移出屏幕笋敞，并且cell11(它也是alloc出來的碱蒙，原因同上)完全顯示出來的時候荠瘪。cell11加入到visiableCells，cell1移出visiableCells赛惩，cell1加入到reusableTableCells哀墓。

3.接著向下拖動tableView，因為reusableTableCells中已經(jīng)有值喷兼，所以篮绰，當(dāng)需要顯示新的cell，cellForRowAtIndexPath再次被調(diào)用的時候季惯，tableViewdequeueReusableCellWithIdentifier:CellIdentifier吠各，返回cell1。cell1加入到visiableCells勉抓，cell1移出reusableTableCells贾漏；cell2移出visiableCells，cell2加入到reusableTableCells藕筋。之后再需要顯示的Cell就可以正常重用了纵散。

如何減小一個應(yīng)用程序占用存儲空間？

檢查程序 去掉多余的xib隐圾。iOS App Store相關(guān)因素作為提交到App Store中app里的可執(zhí)行文件是被加過密的伍掀。加密的副作用是可執(zhí)行文件的壓縮效果沒有之前的好了。Build Settings編譯選項暇藏，將build setting中的Optimization Level設(shè)置為Fastest, Smallest [-Os];將build setting中的Strip Debug Symbols During Copy設(shè)置為YES(COPY_PHASE_STRIP = YES)蜜笤，這樣可以減小編譯出二進(jìn)制文件的尺寸。Target針對較少的CPUs對程序指定的特定CPU類型做優(yōu)化處理盐碱，以生成相對于的可執(zhí)行文件瘩例。不同的硬件，將運(yùn)行不同的可執(zhí)行代碼甸各。雖然這樣優(yōu)化后的程序垛贤，只能針對某些設(shè)備運(yùn)行，但是這大大減小可執(zhí)行程序的大小趣倾。要想只設(shè)定特定類型的CPUs聘惦，可以修改build setting中的Architectures，將其從Standard $(ARCHS_STANDARD)修改為你希望支持的列表中對應(yīng)的特定類型CPU。有效的CPU名稱列在Valid Architectures (VALID_ARCHS) build setting中善绎。請不要修改Valid Architectures設(shè)置項黔漂，最好由Xcode管理。盡量使用8-bit圖片禀酱。使用8-bit的PNG圖片炬守，比32-bit的圖片能減少4倍的壓縮率。由于8-bit的圖片支持最多256種不同的顏色剂跟，所以8-bit的圖片一般只應(yīng)該用于一小部分

的顏色圖片减途。例如灰度圖片最好使用8-bit

如何提高一個應(yīng)用程序的性能？

1曹洽、使用ARC減少內(nèi)存失誤鳍置，dealloc需要重寫并對屬性置nil。2送淆、重用税产。3、盡量少使用透明或半透明偷崩。會產(chǎn)生額外的運(yùn)算辟拷。4、少用運(yùn)算獲得圓角阐斜，不論view.maskToBounds還是layer.clipToBounds都會有很大資源開銷衫冻，必須要用圓角的話不如圖片本身就做成圓角。5智听、不要阻塞主線程羽杰。6、使用正確的容器類型到推。7考赛、圖片與imageView相同大小避免多余運(yùn)算。8莉测、使用懶加載颜骤。9、使用繪制捣卤。

如何優(yōu)化內(nèi)存忍抽？

（1）.用ARC管理內(nèi)存

ARC(Automatic ReferenceCounting,自動引用計數(shù))和iOS5一起發(fā)布，它避免了最常見的也就是經(jīng)常是由于我們忘記釋放內(nèi)存所造成的內(nèi)存泄露董朝。它自動為你管理retain和release的過程鸠项，除了幫你避免內(nèi)存泄露，ARC還可以幫你提高性能子姜，它能保證釋放掉不再需要的對象的內(nèi)存祟绊。

（2）.在正確的地方使用reuseIdentifier

一個開發(fā)中常見的錯誤就是沒有給UITableViewCells，UICollectionViewCells，甚至是UITableViewHeaderFooterViews設(shè)置正確的reuseIdentifier牧抽。

（3）.盡量把views設(shè)置為透明

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

原因是這會使系統(tǒng)用一個最優(yōu)的方式渲染這些views。如果設(shè)為YES扬舒，渲染系統(tǒng)就認(rèn)為這個view是完全不透明的阐肤，這使得渲染系統(tǒng)優(yōu)化一些渲染過程和提高性能。如果設(shè)置為NO讲坎，渲染系統(tǒng)正常地和其它內(nèi)容組成這個View孕惜。默認(rèn)值是YES。

（4）.避免過于龐大的XIB

當(dāng)你加載一個XIB的時候所有內(nèi)容都被放在了內(nèi)存里衣赶，包括任何圖片诊赊。如果有一個不會即刻用到的view厚满，你這就是在浪費(fèi)寶貴的內(nèi)存資源了府瞄。

（5）.不要阻塞主線程

永遠(yuǎn)不要使主線程承擔(dān)過多。因為UIKit在主線程上做所有工作碘箍，渲染遵馆，管理觸摸反應(yīng)，回應(yīng)輸入等都需要在它上面完成丰榴。

一直使用主線程的風(fēng)險就是如果你的代碼真的block了主線程货邓，你的app會失去反應(yīng)。

大部分阻礙主進(jìn)程的情形是你的app在做一些牽涉到讀寫外部資源的I/O操作四濒，比如存儲或者網(wǎng)絡(luò)换况。

（6）.在Image Views中調(diào)整圖片大小

如果要在`UIImageView`中顯示一個來自bundle的圖片，你應(yīng)保證圖片的大小和UIImageView的大小相同盗蟆。在運(yùn)行中縮放圖片是很耗費(fèi)資源的戈二，特別是`UIImageView`嵌套在`UIScrollView`中的情況下。

如果圖片是從遠(yuǎn)端服務(wù)加載的你不能控制圖片大小喳资，比如在下載前調(diào)整到合適大小的話觉吭，你可以在下載完成后，最好是用background thread仆邓，縮放一次鲜滩，然后在UIImageView中使用縮放后的圖片。

（7）.選擇正確的Collection

學(xué)會選擇對業(yè)務(wù)場景最合適的類或者對象是寫出能效高的代碼的基礎(chǔ)节值。當(dāng)處理collections時這句話尤其正確徙硅。

一些常見collection的總結(jié)：

·Arrays:有序的一組值。使用index來lookup很快搞疗，使用value lookup很慢嗓蘑，插入/刪除很慢。

·Dictionaries:存儲鍵值對。用鍵來查找比較快脐往。

·Sets:無序的一組值休吠。用值來查找很快，插入/刪除很快业簿。

（8）.打開gzip壓縮

大量app依賴于遠(yuǎn)端資源和第三方API瘤礁，你可能會開發(fā)一個需要從遠(yuǎn)端下載XML, JSON, HTML或者其它格式的app。

問題是我們的目標(biāo)是移動設(shè)備梅尤，因此你就不能指望網(wǎng)絡(luò)狀況有多好柜思。一個用戶現(xiàn)在還在edge網(wǎng)絡(luò)，下一分鐘可能就切換到了3G巷燥。不論什么場景赡盘，你肯定不想讓你的用戶等太長時間。

減小文檔的一個方式就是在服務(wù)端和你的app中打開gzip缰揪。這對于文字這種能有更高壓縮率的數(shù)據(jù)來說會有更顯著的效用陨享。

好消息是，iOS已經(jīng)在NSURLConnection中默認(rèn)支持了gzip壓縮钝腺，當(dāng)然AFNetworking這些基于它的框架亦然抛姑。像Google App Engine這些云服務(wù)提供者也已經(jīng)支持了壓縮輸出。

（9）.重用和延遲加載(lazy load) Views

更多的view意味著更多的渲染艳狐，也就是更多的CPU和內(nèi)存消耗定硝，對于那種嵌套了很多view在UIScrollView里邊的app更是如此。

這里我們用到的技巧就是模仿`UITableView`和`UICollectionView`的操作:不要一次創(chuàng)建所有的subview毫目，而是當(dāng)需要時才創(chuàng)建蔬啡，當(dāng)它們完成了使命，把他們放進(jìn)一個可重用的隊列中镀虐。

這樣的話你就只需要在滾動發(fā)生時創(chuàng)建你的views箱蟆，避免了不劃算的內(nèi)存分配。

創(chuàng)建views的能效問題也適用于你app的其它方面粉私。想象一下一個用戶點(diǎn)擊一個按鈕的時候需要呈現(xiàn)一個view的場景顽腾。有兩種實現(xiàn)方法：

1.創(chuàng)建并隱藏這個view當(dāng)這個screen加載的時候，當(dāng)需要時顯示它诺核；

2.當(dāng)需要時才創(chuàng)建并展示抄肖。

每個方案都有其優(yōu)缺點(diǎn)。用第一種方案的話因為你需要一開始就創(chuàng)建一個view并保持它直到不再使用窖杀，這就會更加消耗內(nèi)存漓摩。然而這也會使你的app操作更敏感因為當(dāng)用戶點(diǎn)擊按鈕的時候它只需要改變一下這個view的可見性。

第二種方案則相反-消耗更少內(nèi)存入客，但是會在點(diǎn)擊按鈕的時候比第一種稍顯卡頓管毙。

（10）. Cache, Cache,還是Cache!

一個極好的原則就是腿椎，緩存所需要的，也就是那些不大可能改變但是需要經(jīng)常讀取的東西夭咬。

我們能緩存些什么呢啃炸？一些選項是，遠(yuǎn)端服務(wù)器的響應(yīng)卓舵，圖片南用，甚至計算結(jié)果，比如UITableView的行高掏湾。

NSURLConnection默認(rèn)會緩存資源在內(nèi)存或者存儲中根據(jù)它所加載的HTTP Headers裹虫。你甚至可以手動創(chuàng)建一個NSURLRequest然后使它只加載緩存的值。

（11）.權(quán)衡渲染方法

在iOS中可以有很多方法做出漂亮的按鈕融击。你可以用整幅的圖片筑公，可調(diào)大小的圖片，uozhe可以用CALayer尊浪，CoreGraphics甚至OpenGL來畫它們票摇。

當(dāng)然每個不同的解決方法都有不同的復(fù)雜程度和相應(yīng)的性能户敬。

簡單來說飘蚯，就是用事先渲染好的圖片更快一些析命，因為如此一來iOS就免去了創(chuàng)建一個圖片再畫東西上去然后顯示在屏幕上的程序兴泥。問題是你需要把所有你需要用到的圖片放到app的bundle里面工育，這樣就增加了體積–這就是使用可變大小的圖片更好的地方了:你可以省去一些不必要的空間，也不需要再為不同的元素(比如按鈕)來做不同的圖搓彻。

然而如绸，使用圖片也意味著你失去了使用代碼調(diào)整圖片的機(jī)動性，你需要一遍又一遍不斷地重做他們旭贬，這樣就很浪費(fèi)時間了怔接，而且你如果要做一個動畫效果，雖然每幅圖只是一些細(xì)節(jié)的變化你就需要很多的圖片造成bundle大小的不斷增大稀轨。

總得來說扼脐，你需要權(quán)衡一下利弊，到底是要性能能還是要bundle保持合適的大小奋刽。

（12）.處理內(nèi)存警告

一旦系統(tǒng)內(nèi)存過低瓦侮，iOS會通知所有運(yùn)行中app。如果你的app收到了內(nèi)存警告佣谐，它就需要盡可能釋放更多的內(nèi)存肚吏。最佳方式是移除對緩存，圖片object和其他一些可以重創(chuàng)建的objects的strong references.

幸運(yùn)的是狭魂，UIKit提供了幾種收集低內(nèi)存警告的方法:

· 在app delegate中使用`applicationDidReceiveMemoryWarning:`的方法

· 在你的自定義UIViewController的子類(subclass)中覆蓋`didReceiveMemoryWarning`

· 注冊并接收UIApplicationDidReceiveMemoryWarningNotification的通知

一旦收到這類通知罚攀，你就需要釋放任何不必要的內(nèi)存使用党觅。

例如，UIViewController的默認(rèn)行為是移除一些不可見的view斋泄，它的一些子類則可以補(bǔ)充這個方法杯瞻，刪掉一些額外的數(shù)據(jù)結(jié)構(gòu)。一個有圖片緩存的app可以移除不在屏幕上顯示的圖片炫掐。

（13）.重用大開銷對象

一些objects的初始化很慢又兵，比如NSDateFormatter和NSCalendar。然而卒废，你又不可避免地需要使用它們沛厨，比如從JSON或者XML中解析數(shù)據(jù)。

想要避免使用這個對象的瓶頸你就需要重用他們摔认，可以通過添加屬性到你的class里或者創(chuàng)建靜態(tài)變量來實現(xiàn)逆皮。

注意如果你要選擇第二種方法，對象會在你的app運(yùn)行時一直存在于內(nèi)存中参袱，和單例(singleton)很相似电谣。

還需要注意的是，其實設(shè)置一個NSDateFormatter的速度差不多是和創(chuàng)建新的一樣慢的抹蚀！所以如果你的app需要經(jīng)常進(jìn)行日期格式處理的話剿牺，你會從這個方法中得到不小的性能提升。

（14）.減少使用Web特性

UIWebView很有用环壤，用它來展示網(wǎng)頁內(nèi)容或者創(chuàng)建UIKit很難做到的動畫效果是很簡單的一件事晒来。

但是你可能有注意到UIWebView并不像不像驅(qū)動Safari的那么快。這是由于以JIT compilation為特色的Webkit的Nitro Engine的限制郑现。

所以想要更高的性能你就要調(diào)整下你的HTML了湃崩。第一件要做的事就是盡可能移除不必要的javascript，避免使用過大的框架接箫。能只用原生js就更好了攒读。

另外，盡可能異步加載例如用戶行為統(tǒng)計script這種不影響頁面表達(dá)的javascript辛友。

最后薄扁，永遠(yuǎn)要注意你使用的圖片，保證圖片的符合你使用的大小废累。使用Sprite sheet提高加載速度和節(jié)約內(nèi)存邓梅。

（15）.優(yōu)化Table ViewTable view需要有很好的滾動性能，不然用戶會在滾動過程中發(fā)現(xiàn)動畫的瑕疵九默。為了保證table view平滑滾動震放，確保你采取了以下的措施:

· 正確使用`reuseIdentifier`來重用cells

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

· 避免漸變驼修，圖片縮放殿遂，后臺選人

· 緩存行高

· 如果cell內(nèi)現(xiàn)實的內(nèi)容來自web诈铛，使用異步加載，緩存請求結(jié)果

· 使用`shadowPath`來畫陰影

· 減少subviews的數(shù)量

·盡量不適用`cellForRowAtIndexPath:`墨礁，如果你需要用到它幢竹，只用一次然后緩

存結(jié)果

· 使用正確的數(shù)據(jù)結(jié)構(gòu)來存儲數(shù)據(jù)

· 使用`rowHeight`, `sectionFooterHeight`和`sectionHeaderHeight`來設(shè)定固定

的高，不要請求delegate

（16）.使用Autorelease Pool ?`NSAutoreleasePool`負(fù)責(zé)釋放block中的autoreleased objects恩静。一般情況下它會自動被UIKit調(diào)用焕毫。但是有些狀況下你也需要手動去創(chuàng)建它。假如你創(chuàng)建很多臨時對象驶乾，你會發(fā)現(xiàn)內(nèi)存一直在減少直到這些對象被release的時候邑飒。這是因為只有當(dāng)UIKit用光了autorelease pool的時候memory才會被釋放。好消息是你可以在你自己的@autoreleasepool里創(chuàng)建臨時的對象來避免這個行為：

NSArray *urls = <# An array of file URLs #>;

for(NSURL *url in urls) {

@autoreleasepool {

NSError *error;

NSString *fileContents = [NSString stringWithContentsOfURL:url encoding:NSUTF8StringEncoding error:&error];

/* Process the string, creating and autoreleasing more objects. */

}

}

這段代碼在每次遍歷后釋放所有autorelease對象

（17）.選擇是否緩存圖片

常見的從bundle中加載圖片的方式有兩種级乐，一個是用`imageNamed`疙咸，二是用`imageWithContentsOfFile`，第一種比較常見一點(diǎn)风科。既然有兩種類似的方法來實現(xiàn)相同的目的撒轮，那么他們之間的差別是什么呢？`imageNamed`的優(yōu)點(diǎn)是當(dāng)加載時會緩存圖片贼穆。`imageNamed`的文檔中這么說:這個方法用一個指定的名字在系統(tǒng)緩存中查找并返回一個圖片對象如果它存在的話题山。如果緩存中沒有找到相應(yīng)的圖片，這個方法從指定的文檔中加載然后緩存并返回這個對象故痊。

相反的顶瞳，`imageWithContentsOfFile`僅加載圖片。如果你要加載一個大圖片而且是一次性使用崖蜜，那么就沒必要緩存這個圖片浊仆，用`imageWithContentsOfFile`足矣，這樣不會浪費(fèi)內(nèi)存來緩存它豫领。

然而，在圖片反復(fù)重用的情況下`imageNamed`是一個好得多的選擇舔琅。

如何加強(qiáng)iOS里的列表滾動時的順暢感等恐？

1、UITableViewCell里不要添加太多subview备蚓，最好只添加一個cellview课蔬。

2、UITableViewCell上的子View的opaque屬性設(shè)為YES郊尝。其實默認(rèn)也是不透明二跋。UITableViewCell盡量不要包含透明的子View。

3流昏、在cellview里扎即，重寫drawRect函數(shù)繪制UITableViewCell的內(nèi)容吞获。

4、在繪制字符串時谚鄙，盡可能使用drawAtPoint: withFont:各拷，而不要使用更復(fù)雜的drawAtPoint:(CGPoint)point forWidth:(CGFloat)width withFont:(UIFont *)font lineBreakMode:(UILineBreakMode)lineBreakMode;如果要繪制過長的字符串，建議自己先截斷闷营，然后使用drawAtPoint: withFont:方法繪制烤黍。

5、在繪制圖片時傻盟，盡量使用drawAtPoint速蕊，而不要使用drawInRect。drawInRect如果在繪制過程中對圖片進(jìn)行放縮娘赴，會特別消耗CPU互例。

6、如果繪制cell過程中筝闹，需要下載cell中的圖片媳叨，建議在繪制cell一段時間后再開啟圖片下載任務(wù)。譬如先畫一個默認(rèn)圖片关顷，然后在0.5S后開始下載本cell的圖片糊秆。

7、即使下載cell圖片是在子線程中進(jìn)行议双，在繪制cell過程中痘番，也不能開啟過多的子線程。最好只有一個下載圖片的子線程在活動平痰。否則也會影響UITableViewCell的繪制汞舱，因而影響了UITableViewCell的滑動速度。(建議結(jié)合使用NSOpeartion和NSOperationQueue來下載圖片宗雇，如果想盡可能找的下載圖片昂芜，可以把[self.queuesetMaxConcurrentOperationCount:4];)

8、最好自己寫一個cache赔蒲，用來緩存UITableView中的UITableViewCell泌神，這樣在整個UITableView的生命周期里，一個cell只需繪制一次舞虱，并且如果發(fā)生內(nèi)存不足欢际，也可以有效的釋放掉緩存的cell。

9矾兜、不要將tableview的背景顏色設(shè)置成一個圖片损趋。這回嚴(yán)重影響UITableView的滑動速度。在限時免費(fèi)搜索里椅寺，我曾經(jīng)翻過一個錯誤：self.tableView_.backgroundColor = [UIColorcolorWithPatternImage:[UIImageimageNamed:@"background.png"]];通過這種方式設(shè)置UITableView的背景顏色會嚴(yán)重影響UTIableView的滑動流暢性浑槽。修改成self.tableView_.backgroundColor = [UIColor clearColor];之后蒋失，fps從43上升到60左右±ǖ矗滑動比較流暢高镐。

10、cell的行高不是固定值畸冲，需要計算嫉髓，則要盡可能緩存行高值，避免重復(fù)計算行高邑闲。這里指的是UITableViewDelegate里的行高函數(shù)算行。

1、舉出兩個實際開發(fā)應(yīng)用程序中可以省電的例子苫耸。

(1)如果程序用到定位州邢，需要在定位完畢之后關(guān)閉定位，或者降低定位的頻率褪子，

不停的定位會消耗電量量淌。

(2)如果用到了藍(lán)牙，需要使用藍(lán)牙時候開啟藍(lán)牙嫌褪，藍(lán)牙用完之后關(guān)閉藍(lán)牙呀枢，藍(lán)

牙也很耗電。

(3)優(yōu)化算法笼痛，減少循環(huán)次數(shù)裙秋，大量循環(huán)會讓CPU一直處于忙碌狀態(tài)，特別費(fèi)電缨伊。

(4)不要使用網(wǎng)絡(luò)輪詢摘刑，使用推送。

(5)timer的時間間隔不宜太短刻坊，滿足需求即可枷恕。

(6)不要頻繁刷新頁面，能刷新1行cell紧唱，不要reloadData活尊。

(7)切勿讓屏幕長亮。

(8)線程適量漏益，不宜過多

3、怎么解決緩存池滿的問題（cell）

ios中不存在緩存池滿的情況深胳，因為通常我們ios中開發(fā)绰疤，對象都是在需要的時候才會創(chuàng)建，有種常用的說話叫做懶加載舞终，還有在UITableView中一般只會創(chuàng)建剛開始出現(xiàn)在屏幕中的cell轻庆，之后都是從緩存池里取癣猾，不會在創(chuàng)建新對象。緩存池里最多也就一兩個對象余爆，緩存池滿的這種情況一般在開發(fā)java中比較常見纷宇，java中一般把最近最少使用的對象先釋放。

//清楚cell的緩存

NSArray *subviews = [[NSArray alloc] initWithArray:cell.contentView.subviews];

for (UIView *subview in subviews) {

[subview removeFromSuperview];

2.TableView是怎么優(yōu)化的蛾方？tableView下拉加載數(shù)據(jù)的時候為什么會出現(xiàn)卡頓像捶，如何解決？

(1)使用不透明視圖

（2）不要重復(fù)創(chuàng)建不必要的table cell桩砰。

（3）減少視圖的數(shù)目拓春。

（4）不要做多余的繪制工作。

（5）預(yù)渲染圖像亚隅。

（6）不要阻塞主線程硼莽。

http://blog.sina.com.cn/s/blog_b638dc890101ep3x.html

4、正常使用應(yīng)用時煮纵，按HOME鍵退出懂鸵。稍后再次打開，界面出現(xiàn)卡頓現(xiàn)象行疏，嘗試分析一下可能原因匆光。

這是由iOS系統(tǒng)管理決定的，但APP退出在后臺后隘擎，只有10秒的持續(xù)運(yùn)行時間殴穴，然后暫停。但該APP還在內(nèi)存中货葬，當(dāng)出現(xiàn)內(nèi)存警告采幌，也就是別的APP要運(yùn)行，而此時內(nèi)存又不足的情況下震桶，系統(tǒng)會回收停在后臺APP所占用的內(nèi)存休傍。如果出現(xiàn)這種情況，那么你再次打開你的APP蹲姐，就會重新啟動磨取。

不知道你是為什么要讓APP在后臺還要繼續(xù)運(yùn)行，如果非得這樣柴墩，那可以使用多線程技術(shù)中的gcd忙厌，可以讓APP退出后繼續(xù)運(yùn)行很長一段時間（大概10分鐘）

iOS APP類型：

1.保存現(xiàn)場。按下Home鍵10秒內(nèi)直接殺死進(jìn)程江咳，并釋放內(nèi)存逢净。

2. iOS支持的“多任務(wù)”。按下Home鍵轉(zhuǎn)入多任務(wù)狀態(tài)，保留在內(nèi)存中爹土，但只能系統(tǒng)允許的動作：比如GPS甥雕，比如VoIP，比如音樂等等胀茵。

3.真正的桌面級別的多任務(wù)社露。只有Safari/Mail是，蘋果嫡系大都都不是琼娘。這個級別的app在后臺沒有任何限制動作峭弟。

無限制動作的程序，一會在用戶無察覺的情況下耗光電力轨奄，二會有安全上面的問題(那些在后臺依舊默默發(fā)送你的個人消息程序)

順便提一句孟害，后兩種占用內(nèi)存的app，也會在任意時間從內(nèi)存中被砍掉挪拟，取決于你是否動用了其它app而導(dǎo)致內(nèi)存不足挨务。

真正不會被砍掉的后臺，只有蘋果那個通知系統(tǒng)玉组。

3.什么時候會用到懶加載谎柄？如果需要展示大量圖片的時候還要一個個去加載么？

懶加載惯雳，又稱為延遲加載朝巫。說的通俗一點(diǎn)，就是在開發(fā)中石景，當(dāng)程序中需要利用的資源時劈猿。在程序啟動的時候不加載資源，只有在運(yùn)行當(dāng)需要一些資源時潮孽，再去加載這些資源揪荣。

我們知道iOS設(shè)備的內(nèi)存有限，如果在程序在啟動后就一次性加載將來會用到的所有資源往史，那么就有可能會耗盡iOS設(shè)備的內(nèi)存仗颈。這些資源例如大量數(shù)據(jù)，圖片椎例，音頻等等

16.工程中的圖片存在哪里挨决，如何保證刷新后內(nèi)存不斷增加問題，以及節(jié)約用戶流量

工程中使用的圖片可以自己創(chuàng)建個文件夾進(jìn)行存放你需要用的圖片,也可以在你工程中的Images.xcassets文件中存放你的圖片.

解決刷新內(nèi)存不斷增加的問題,需要把你創(chuàng)建的控件布局寫成對應(yīng)類的屬性,在ViewDidLoad中初始化一次.不要在其他的類方法里創(chuàng)建控件.

刷新節(jié)約用戶流量的方法就是在一定時間段中判斷當(dāng)前的請求時間和上次刷新的時間并限定一個時間范圍在某個范圍內(nèi)刷新不重新請求數(shù)據(jù).

1.UIWebView如何管理內(nèi)存泄露的問題.

在你點(diǎn)擊按鈕跳轉(zhuǎn)界面是不要再你的button點(diǎn)擊時間中創(chuàng)建你的UIWebView,把UIWebView創(chuàng)建成一條屬性在你的ViewDidLoad中去初始化,在你點(diǎn)擊button時再去給你的WebView指定需要現(xiàn)實的網(wǎng)址.這樣的操作可以讓你的WebView不會在你點(diǎn)擊button的時候無限制的被創(chuàng)建.這樣就不會讓你的內(nèi)存無限制的增長.

g?????