一、如何提高一個應用程序的性能？
1、使用ARC減少內存失誤，dealloc需要重寫并對屬性置nil。
2、重用。
3、盡量少使用透明或半透明。會產生額外的運算。
4、少用運算獲得圓角，不論view.maskToBounds還是layer.clipToBounds都會有很大資源開銷，必須要用圓角的話不如圖片本身就做成圓角。
5、不要阻塞主線程。
6、使用正確的容器類型。
7、圖片與imageView相同大小避免多余運算。
8、使用懶加載。
9、使用繪制。

二、如何加強iOS里的列表滾動時的順暢感？
1、UITableViewCell里不要添加太多subview，最好只添加一個cellview。
2、UITableViewCell上的子View的opaque屬性設為YES。其實默認也是不透明。UITableViewCell盡量不要包含透明的子View。
3、在cellview里，重寫drawRect函數繪制UITableViewCell的內容。
4、在繪制字符串時，盡可能使用drawAtPoint: withFont:，而不要使用更復雜的drawAtPoint:(CGPoint)point forWidth:(CGFloat)width withFont:(UIFont *)font lineBreakMode:(UILineBreakMode)lineBreakMode;如果要繪制過長的字符串，建議自己先截斷，然后使用drawAtPoint: withFont:方法繪制。
5、在繪制圖片時，盡量使用drawAtPoint，而不要使用drawInRect。drawInRect如果在繪制過程中對圖片進行放縮，會特別消耗CPU。
6、如果繪制cell過程中，需要下載cell中的圖片，建議在繪制cell一段時間后再開啟圖片下載任務。譬如先畫一個默認圖片，然后在0.5S后開始下載本cell的圖片。
7、即使下載cell圖片是在子線程中進行，在繪制cell過程中，也不能開啟過多的子線程。最好只有一個下載圖片的子線程在活動。否則也會影響UITableViewCell的繪制，因而影響了UITableViewCell的滑動速度。(建議結合使用NSOpeartion和NSOperationQueue來下載圖片，如果想盡可能找的下載圖片，可以把[self.queuesetMaxConcurrentOperationCount:4];)
8、最好自己寫一個cache，用來緩存UITableView中的UITableViewCell，這樣在整個UITableView的生命周期里，一個cell只需繪制一次，并且如果發生內存不足，也可以有效的釋放掉緩存的cell。
9、不要將tableview的背景顏色設置成一個圖片。這回嚴重影響UITableView的滑動速度。在限時免費搜索里，我曾經翻過一個錯誤：self.tableView_.backgroundColor = [UIColorcolorWithPatternImage:[UIImageimageNamed:@"background.png"]];通過這種方式設置UITableView的背景顏色會嚴重影響UTIableView的滑動流暢性。修改成self.tableView_.backgroundColor = [UIColor clearColor];之后，fps從43上升到60左右。滑動比較流暢。
10、cell的行高不是固定值，需要計算，則要盡可能緩存行高值，避免重復計算行高。這里指的是UITableViewDelegate里的行高函數。

三、TableView是怎么優化的？tableView下拉加載數據的時候為什么會出現卡頓，如何解決？
(1)使用不透明視圖
（2）不要重復創建不必要的table cell。
（3）減少視圖的數目。
（4）不要做多余的繪制工作。
（5）預渲染圖像。
（6）不要阻塞主線程。
四、什么時候會用到懶加載？如果需要展示大量圖片的時候還要一個個去加載么？
懶加載，又稱為延遲加載。說的通俗一點，就是在開發中，程序啟動的時候不加載資源，只有在運行當需要一些資源時，再去加載這些資源。
我們知道iOS設備的內存有限，如果在程序在啟動后就一次性加載將來會用到的所有資源，那么就有可能會耗盡iOS設備的內存。這些資源例如大量數據，圖片，音頻等等

五、工程中的圖片存在哪里，如何保證刷新后內存不斷增加問題，以及節約用戶流量
工程中使用的圖片可以自己創建個文件夾進行存放你需要用的圖片,也可以在你工程中的Images.xcassets文件中存放你的圖片.
解決刷新內存不斷增加的問題,需要把你創建的控件布局寫成對應類的屬性,在ViewDidLoad中初始化一次.不要在其他的類方法里創建控件.
刷新節約用戶流量的方法就是在一定時間段中判斷當前的請求時間和上次刷新的時間并限定一個時間范圍在某個范圍內刷新不重新請求數據.

六、怎么解決緩存池滿的問題（cell）
ios中不存在緩存池滿的情況，因為通常我們ios中開發，對象都是在需要的時候才會創建，有種常用的說話叫做懶加載，還有在UITableView中一般只會創建剛開始出現在屏幕中的cell，之后都是從緩存池里取，不會在創建新對象。緩存池里最多也就一兩個對象，緩存池滿的這種情況一般在開發java中比較常見，java中一般把最近最少使用的對象先釋放。

//清楚cell的緩存
NSArray *subviews = [[NSArray alloc] initWithArray:cell.contentView.subviews];
for (UIView *subview in subviews) {
[subview removeFromSuperview];

七、tableView的重用機制？（簡單了解即可）
查看UITableView頭文件，會找到NSMutableArray* visiableCells，和NSMutableDictnery*reusableTableCells兩個結構。visiableCells內保存當前顯示的cells，reusableTableCells保存可重用的cells。TableView顯示之初，reusableTableCells為空，那么tableViewdequeueReusableCellWithIdentifier:CellIdentifier返回nil。開始的cell都是通過[[UITableViewCell alloc]initWithStyle:UITableViewCellStyleDefault reuseIdentifier:CellIdentifier]來創建，而且cellForRowAtIndexPath只是調用最大顯示cell數的次數。比如：有100條數據，iPhone一屏最多顯示10個cell。程序最開始顯示TableView的情況是：1.用

[[UITableViewCellalloc] initWithStyle:UITableViewCellStyleDefaultreuseIdentifier:CellIdentifier]

創建10次cell，并給cell指定同樣的重用標識(當然，可以為不同顯示類型的cell指定不同的標識)。并且10個cell全部都加入到visiableCells數組，reusableTableCells為空。
2.向下拖動tableView，當cell1完全移出屏幕，并且cell11(它也是alloc出來的，原因同上)完全顯示出來的時候。cell11加入到visiableCells，cell1移出visiableCells，cell1加入到reusableTableCells。
3.接著向下拖動tableView，因為reusableTableCells中已經有值，所以，當需要顯示新的cell，cellForRowAtIndexPath再次被調用的時候，tableViewdequeueReusableCellWithIdentifier:CellIdentifier，返回cell1。cell1加入到visiableCells，cell1移出reusableTableCells；cell2移出visiableCells，cell2加入到reusableTableCells。之后再需要顯示的Cell就可以正常重用了。

八、簡單描述一下你在開發的過程中，如何實現程序的性能優化？
答：我在開發的過程中會注意一下幾點來優化程序性能：
1）.避免龐大的XIB、Storyboard，盡量多用純代碼開發
2）.使用懶加載的方式延遲加載界面
3）.避免反復處理數據
4）.避免使用NSDateFormatter和NSCalendar。
5）.圖片緩存的取舍
UIImage加載圖片方式一般有兩種:
A：imagedNamed初始化
B：imageWithContentsOfFile初始化
二者不同之處在于,imageNamed默認加載圖片成功后會內存中緩存圖片,這個方法用一個指定的名字在系統緩存中查找并返回一個圖片對象.如果緩存中沒有找到相應的圖片對象,則從指定地方加載圖片然后緩存對象，并返回這個圖片對象.
而imageWithContentsOfFile則僅只加載圖片,不緩存.
大量使用imageNamed方式會在不需要緩存的地方額外增加開銷CPU的時間來做這件事.當應用程序需要加載一張比較大的圖片并且使用一次性，那么其實是沒有必要去緩存這個圖片的，用imageWithContentsOfFile是最為經濟的方式,這樣不會因為UIImage元素較多情況下，CPU會被逐個分散在不必要緩存上浪費過多時間.使用場景需要編程時，應該根據實際應用場景加以區分，UIImage雖小，但使用元素較多問題會有所凸顯.

九、 如何讓你的應用程序更加省電？
答：
(1). 如果程序用到定位，需要在定位完畢之后關閉定位，或者降低定位的頻率，不停的定位會消耗電量。
(2). 如果用到了藍牙，需要使用藍牙時候開啟藍牙，藍牙用完之后關閉藍牙，藍牙也很耗電。
(3). 優化算法，減少循環次數，大量循環會讓CPU一直處于忙碌狀態，特別費電。
(4). 盡量不要使用網絡輪詢（心跳包、定時器），使用推送。
(5). timer的時間間隔不宜太短，滿足需求即可。
(6). 不要頻繁刷新頁面，能刷新1行cell的最好刷新一行，盡量不要reloadData。
(7). 線程適量，不宜過多。

十、如何減小一個應用程序占用存儲空間？
檢查程序 去掉多余的xib。iOS App Store相關因素作為提交到App Store中app里的可執行文件是被加過密的。加密的副作用是可執行文件的壓縮效果沒有之前的好了。Build Settings編譯選項，將build setting中的Optimization Level設置為Fastest, Smallest [-Os];將build setting中的Strip Debug Symbols During Copy設置為YES(COPY_PHASE_STRIP = YES)，這樣可以減小編譯出二進制文件的尺寸。Target針對較少的CPUs對程序指定的特定CPU類型做優化處理，以生成相對于的可執行文件。不同的硬件，將運行不同的可執行代碼。雖然這樣優化后的程序，只能針對某些設備運行，但是這大大減小可執行程序的大小。要想只設定特定類型的CPUs，可以修改build setting中的Architectures，將其從Standard $(ARCHS_STANDARD)修改為你希望支持的列表中對應的特定類型CPU。有效的CPU名稱列在Valid Architectures (VALID_ARCHS) build setting中。請不要修改Valid Architectures設置項，最好由Xcode管理。盡量使用8-bit圖片。使用8-bit的PNG圖片，比32-bit的圖片能減少4倍的壓縮率。由于8-bit的圖片支持最多256種不同的顏色，所以8-bit的圖片一般只應該用于一小部分的顏色圖片。例如灰度圖片最好使用8-bit

十一、如何優化內存？
（1）.用ARC管理內存ARC(Automatic ReferenceCounting,自動引用計數)和iOS5一起發布，它避免了最常見的也就是經常是由于我們忘記釋放內存所造成的內存泄露。它自動為你管理retain和release的過程，除了幫你避免內存泄露，ARC還可以幫你提高性能，它能保證釋放掉不再需要的對象的內存。（2）.在正確的地方使用reuseIdentifier一個開發中常見的錯誤就是沒有給UITableViewCells，UICollectionViewCells，甚至是UITableViewHeaderFooterViews設置正確的reuseIdentifier。（3）.盡量把views設置為透明如果你有透明的Views你應該設置它們的opaque屬性為YES。原因是這會使系統用一個最優的方式渲染這些views。如果設為YES，渲染系統就認為這個view是完全不透明的，這使得渲染系統優化一些渲染過程和提高性能。如果設置為NO，渲染系統正常地和其它內容組成這個View。默認值是YES。（4）.避免過于龐大的XIB當你加載一個XIB的時候所有內容都被放在了內存里，包括任何圖片。如果有一個不會即刻用到的view，你這就是在浪費寶貴的內存資源了。（5）.不要阻塞主線程永遠不要使主線程承擔過多。因為UIKit在主線程上做所有工作，渲染，管理觸摸反應，回應輸入等都需要在它上面完成。一直使用主線程的風險就是如果你的代碼真的block了主線程，你的app會失去反應。大部分阻礙主進程的情形是你的app在做一些牽涉到讀寫外部資源的I/O操作，比如存儲或者網絡。（6）.在Image Views中調整圖片大小如果要在UIImageView
中顯示一個來自bundle的圖片，你應保證圖片的大小和UIImageView的大小相同。在運行中縮放圖片是很耗費資源的，特別是UIImageView
嵌套在UIScrollView
中的情況下。如果圖片是從遠端服務加載的你不能控制圖片大小，比如在下載前調整到合適大小的話，你可以在下載完成后，最好是用background thread，縮放一次，然后在UIImageView中使用縮放后的圖片。（7）.選擇正確的Collection學會選擇對業務場景最合適的類或者對象是寫出能效高的代碼的基礎。當處理collections時這句話尤其正確。一些常見collection的總結：·Arrays:有序的一組值。使用index來lookup很快，使用value lookup很慢，插入/刪除很慢。·Dictionaries:存儲鍵值對。用鍵來查找比較快。·Sets:無序的一組值。用值來查找很快，插入/刪除很快。（8）.打開gzip壓縮大量app依賴于遠端資源和第三方API，你可能會開發一個需要從遠端下載XML, JSON, HTML或者其它格式的app。問題是我們的目標是移動設備，因此你就不能指望網絡狀況有多好。一個用戶現在還在edge網絡，下一分鐘可能就切換到了3G。不論什么場景，你肯定不想讓你的用戶等太長時間。減小文檔的一個方式就是在服務端和你的app中打開gzip。這對于文字這種能有更高壓縮率的數據來說會有更顯著的效用。好消息是，iOS已經在NSURLConnection中默認支持了gzip壓縮，當然AFNetworking這些基于它的框架亦然。像Google App Engine這些云服務提供者也已經支持了壓縮輸出。（9）.重用和延遲加載(lazy load) Views更多的view意味著更多的渲染，也就是更多的CPU和內存消耗，對于那種嵌套了很多view在UIScrollView里邊的app更是如此。這里我們用到的技巧就是模仿UITableView
和UICollectionView
的操作:不要一次創建所有的subview，而是當需要時才創建，當它們完成了使命，把他們放進一個可重用的隊列中。這樣的話你就只需要在滾動發生時創建你的views，避免了不劃算的內存分配。創建views的能效問題也適用于你app的其它方面。想象一下一個用戶點擊一個按鈕的時候需要呈現一個view的場景。有兩種實現方法：1.創建并隱藏這個view當這個screen加載的時候，當需要時顯示它；2.當需要時才創建并展示。每個方案都有其優缺點。用第一種方案的話因為你需要一開始就創建一個view并保持它直到不再使用，這就會更加消耗內存。然而這也會使你的app操作更敏感因為當用戶點擊按鈕的時候它只需要改變一下這個view的可見性。第二種方案則相反-消耗更少內存，但是會在點擊按鈕的時候比第一種稍顯卡頓。（10）. Cache, Cache,還是Cache!一個極好的原則就是，緩存所需要的，也就是那些不大可能改變但是需要經常讀取的東西。我們能緩存些什么呢？一些選項是，遠端服務器的響應，圖片，甚至計算結果，比如UITableView的行高。NSURLConnection默認會緩存資源在內存或者存儲中根據它所加載的HTTP Headers。你甚至可以手動創建一個NSURLRequest然后使它只加載緩存的值。（11）.權衡渲染方法在iOS中可以有很多方法做出漂亮的按鈕。你可以用整幅的圖片，可調大小的圖片，uozhe可以用CALayer，CoreGraphics甚至OpenGL來畫它們。當然每個不同的解決方法都有不同的復雜程度和相應的性能。簡單來說，就是用事先渲染好的圖片更快一些，因為如此一來iOS就免去了創建一個圖片再畫東西上去然后顯示在屏幕上的程序。問題是你需要把所有你需要用到的圖片放到app的bundle里面，這樣就增加了體積–這就是使用可變大小的圖片更好的地方了:你可以省去一些不必要的空間，也不需要再為不同的元素(比如按鈕)來做不同的圖。然而，使用圖片也意味著你失去了使用代碼調整圖片的機動性，你需要一遍又一遍不斷地重做他們，這樣就很浪費時間了，而且你如果要做一個動畫效果，雖然每幅圖只是一些細節的變化你就需要很多的圖片造成bundle大小的不斷增大。總得來說，你需要權衡一下利弊，到底是要性能能還是要bundle保持合適的大小。（12）.處理內存警告一旦系統內存過低，iOS會通知所有運行中app。如果你的app收到了內存警告，它就需要盡可能釋放更多的內存。最佳方式是移除對緩存，圖片object和其他一些可以重創建的objects的strong references.幸運的是，UIKit提供了幾種收集低內存警告的方法:· 在app delegate中使用applicationDidReceiveMemoryWarning:
的方法· 在你的自定義UIViewController的子類(subclass)中覆蓋didReceiveMemoryWarning
· 注冊并接收UIApplicationDidReceiveMemoryWarningNotification的通知一旦收到這類通知，你就需要釋放任何不必要的內存使用。例如，UIViewController的默認行為是移除一些不可見的view，它的一些子類則可以補充這個方法，刪掉一些額外的數據結構。一個有圖片緩存的app可以移除不在屏幕上顯示的圖片。（13）.重用大開銷對象一些objects的初始化很慢，比如NSDateFormatter和NSCalendar。然而，你又不可避免地需要使用它們，比如從JSON或者XML中解析數據。想要避免使用這個對象的瓶頸你就需要重用他們，可以通過添加屬性到你的class里或者創建靜態變量來實現。注意如果你要選擇第二種方法，對象會在你的app運行時一直存在于內存中，和單例(singleton)很相似。還需要注意的是，其實設置一個NSDateFormatter的速度差不多是和創建新的一樣慢的！所以如果你的app需要經常進行日期格式處理的話，你會從這個方法中得到不小的性能提升。（14）.減少使用Web特性UIWebView很有用，用它來展示網頁內容或者創建UIKit很難做到的動畫效果是很簡單的一件事。但是你可能有注意到UIWebView并不像不像驅動Safari的那么快。這是由于以JIT compilation為特色的Webkit的Nitro Engine的限制。所以想要更高的性能你就要調整下你的HTML了。第一件要做的事就是盡可能移除不必要的javascript，避免使用過大的框架。能只用原生js就更好了。另外，盡可能異步加載例如用戶行為統計script這種不影響頁面表達的javascript。最后，永遠要注意你使用的圖片，保證圖片的符合你使用的大小。使用Sprite sheet提高加載速度和節約內存。（15）.優化Table ViewTable view需要有很好的滾動性能，不然用戶會在滾動過程中發現動畫的瑕疵。為了保證table view平滑滾動，確保你采取了以下的措施:· 正確使用reuseIdentifier
來重用cells· 盡量使所有的view opaque，包括cell自身· 避免漸變，圖片縮放，后臺選人· 緩存行高· 如果cell內現實的內容來自web，使用異步加載，緩存請求結果· 使用shadowPath
來畫陰影· 減少subviews的數量·盡量不適用cellForRowAtIndexPath:
，如果你需要用到它，只用一次然后緩存結果· 使用正確的數據結構來存儲數據· 使用rowHeight
,sectionFooterHeight
和sectionHeaderHeight
來設定固定的高，不要請求delegate（16）.使用Autorelease PoolNSAutoreleasePool
負責釋放block中的autoreleased objects。一般情況下它會自動被UIKit調用。但是有些狀況下你也需要手動去創建它。假如你創建很多臨時對象，你會發現內存一直在減少直到這些對象被release的時候。這是因為只有當UIKit用光了autorelease pool的時候memory才會被釋放。好消息是你可以在你自己的@autoreleasepool里創建臨時的對象來避免這個行為：
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
，第一種比較常見一點。既然有兩種類似的方法來實現相同的目的，那么他們之間的差別是什么呢？imageNamed
的優點是當加載時會緩存圖片。imageNamed
的文檔中這么說:這個方法用一個指定的名字在系統緩存中查找并返回一個圖片對象如果它存在的話。如果緩存中沒有找到相應的圖片，這個方法從指定的文檔中加載然后緩存并返回這個對象。相反的，imageWithContentsOfFile
僅加載圖片。如果你要加載一個大圖片而且是一次性使用，那么就沒必要緩存這個圖片，用imageWithContentsOfFile
足矣，這樣不會浪費內存來緩存它。然而，在圖片反復重用的情況下imageNamed
是一個好得多的選擇
十二、正常使用應用時，按HOME鍵退出。稍后再次打開，界面出現卡頓現象，嘗試分析一下可能原因。
這是由iOS系統管理決定的，但APP退出在后臺后，只有10秒的持續運行時間，然后暫停。但該APP還在內存中，當出現內存警告，也就是別的APP要運行，而此時內存又不足的情況下，系統會回收停在后臺APP所占用的內存。如果出現這種情況，那么你再次打開你的APP，就會重新啟動。
不知道你是為什么要讓APP在后臺還要繼續運行，如果非得這樣，那可以使用多線程技術中的gcd，可以讓APP退出后繼續運行很長一段時間（大概10分鐘）
iOS APP類型：
1.保存現場。按下Home鍵10秒內直接殺死進程，并釋放內存。

iOS支持的“多任務”。按下Home鍵轉入多任務狀態，保留在內存中，但只能系統允許的動作：比如GPS，比如VoIP，比如音樂等等。
3.真正的桌面級別的多任務。只有Safari/Mail是，蘋果嫡系大都都不是。這個級別的app在后臺沒有任何限制動作。
無限制動作的程序，一會在用戶無察覺的情況下耗光電力，二會有安全上面的問題(那些在后臺依舊默默發送你的個人消息程序)
順便提一句，后兩種占用內存的app，也會在任意時間從內存中被砍掉，取決于你是否動用了其它app而導致內存不足。
真正不會被砍掉的后臺，只有蘋果那個通知系統。