今天給大家?guī)��?lái)文章講述IOS程序員招聘面試時(shí)候可能出現(xiàn)的部分問(wèn)題以及答案，對(duì)于希望擔(dān)任IOS程序員的各位來(lái)說(shuō)是必讀的干貨。

　　IOS程序員面試中被面試官問(wèn)到的問(wèn)題以及答案

　　1. 請(qǐng)你談?wù)剆tatic和宏定義的區(qū)別。什么時(shí)候用static什么時(shí)候用宏定義。

　　讓你聲明的常量只在你聲明的文件里有作用要不編譯器會(huì)保存 

　　宏定義：

　　1). 一般來(lái)說(shuō)我們使用宏定義最常見(jiàn)的是定義一些常量 簡(jiǎn)單的”函數(shù)”(比如求兩個(gè)數(shù)的最大小值)

　　例如：定義常量PI

　　#define PI 3.1415926

　　定義函數(shù)

　　#define MIN(A,B) ((A) < (B) ? (A):(B))

　　我們不對(duì)宏定義進(jìn)行修改

　　2) . 使用宏定義可以在很大程度上可以簡(jiǎn)化我們的代碼

　　例如：我們?cè)趯?xiě)單例的時(shí)候 之前我們寫(xiě)的是

　　#import "ShareSingleton.h"@implementation ShareSingleton+(instancetype)shareSingleton { static ShareSingleton *leader = nil; static dispatch_once_t onceToken; dispatch_once(&onceToken, ^{

　　leader = [[ShareSingleton alloc]init];

　　}); return leader;

　　}@end//如果我們使用宏定義的話(huà)我們可以這樣寫(xiě)：#define DISPATCH_ONCE_BLOCK(onceBlock) static dispatch_once_t onceToken; dispatch_once(&onceToken, onceBlock);#import "ShareSingleton.h"@implementation ShareSingleton+(instancetype)shareSingleton { static ShareSingleton *leader = nil;

　　DISPATCH_ONCE_BLOCK(^{

　　leader = [[ShareSingleton alloc]init];

　　}) return leader;

　　}@end

　　其實(shí)#define的原理就是不管三七二十一，直接做替換，所以我們完全可以利用這個(gè)特點(diǎn)，發(fā)揮自己的想象，簡(jiǎn)化代碼~ 宏定義實(shí)質(zhì)是一個(gè)預(yù)編譯指令，在程序未運(yùn)行之前將某些指令付給相應(yīng)的變量。

　　小結(jié)一下： static標(biāo)記的變量會(huì)存儲(chǔ)到全局變量區(qū)，生命周期和程序相同。而宏定義所定義的生命周期與所在的載體的生命周期有關(guān).

　　static只在聲明的類(lèi)中可見(jiàn)。

　　在聲明的類(lèi)中結(jié)束后，再次使用還是之前的值。

　　2.你是怎么看待代理 通知的 他們有什么區(qū)別?

　　首先，我們把代理通知 放到一起來(lái)討論第一反映是傳值。 ok，下面慢慢來(lái)說(shuō)各個(gè)的用法和區(qū)別。

　　通知中心

　　通過(guò)NSNotification可以給多個(gè)對(duì)象傳遞數(shù)據(jù)和消息(多個(gè)傳遞) 代理 通過(guò)protocol(代理模式)只能給一個(gè)對(duì)象傳遞數(shù)據(jù)和消息(單一傳遞)“一對(duì)一”，對(duì)同一個(gè)協(xié)議，一個(gè)對(duì)象只能設(shè)置一個(gè)代理delegate，所以單例對(duì)象就不能用代理(可以用多點(diǎn)回調(diào)，下面見(jiàn)解)。

　　代理更注重過(guò)程信息的傳輸：比如發(fā)起一個(gè)網(wǎng)絡(luò)請(qǐng)求，可能想要知道此時(shí)請(qǐng)求是否已經(jīng)開(kāi)始、是否收到了數(shù)據(jù)、數(shù)據(jù)是否已經(jīng)接受完成、數(shù)據(jù)接收失敗。

　　區(qū)別： 代理和通知的區(qū)別應(yīng)該主要是一對(duì)一和一對(duì)多的關(guān)系。delegate的多點(diǎn)回調(diào)相對(duì)notification更加便捷，更多方便，讓項(xiàng)目更好維護(hù)。

　　3.說(shuō)說(shuō)你對(duì)內(nèi)存管理的理解。

　　內(nèi)存管理原則

　　引用計(jì)數(shù)的增加和減少相等，當(dāng)引用計(jì)數(shù)降為0之后，不應(yīng)該再使用這塊內(nèi)存空間。 凡是用alloc retain 或者copy讓內(nèi)存的引用計(jì)數(shù)增加了。就需要使用release或者autorelease讓內(nèi)存的引用 計(jì)數(shù)減少。在一段代碼內(nèi)。增加和減少的次數(shù)要相等。

　　autoreleasepool的使用

　　通過(guò)autoreleasepool控制autorelease對(duì)象的釋放 向一個(gè)對(duì)象發(fā)送autorelease消息。這個(gè)對(duì)象何時(shí)釋放取決于autoreleasepool

　　copy方法

　　跟retain不同，一個(gè)對(duì)象想要copy，生成自己的副本，需要實(shí)現(xiàn)NSCopying協(xié)議，定義copy的細(xì)節(jié)(如何copy)如果類(lèi)沒(méi)有接受NSCoping協(xié)議而給類(lèi)發(fā)送copy消息，會(huì)引起crash 總結(jié)： OC借助引用計(jì)數(shù)機(jī)制去管理內(nèi)存，凡是使用了alloc copy retain 等 方法，增加了引用計(jì)數(shù)，就要使用release 和autorelease 減少引用計(jì)數(shù)，引用計(jì)數(shù)為0的時(shí)候，對(duì)象所占的內(nèi)存，被系統(tǒng)回收。

　　autorelease是未來(lái)某個(gè)時(shí)間(出autorelease)引用減一，不是即時(shí)的。

　　不是任何對(duì)象都可以接受copy消息。只有接受了NSCoping協(xié)議的對(duì)象才接受copy消息。

　　4.談?wù)勀銓?duì)iOS性能優(yōu)化的理解.

　　談起iOS的性能優(yōu)化我們首先想到的是應(yīng)該是tableview表視圖的優(yōu)化。關(guān)于表視圖的優(yōu)化我們可以從以下幾個(gè)方面來(lái)看:

　　1).tableviewcell渲染

　　繪制時(shí)要盡可能的避免分配資源，比如UIFont，NSDateFormatter或者任何在繪制時(shí) 需要的對(duì)象，推薦使用類(lèi)層級(jí)的初始化方法中執(zhí)行分配，并將其存儲(chǔ)為靜態(tài)變量。

　　2).圖層渲染的問(wèn)題

　　透明圖層對(duì)渲染性能會(huì)有一定的影響，系統(tǒng)必須將透明圖層與下面的視圖混合起來(lái)計(jì)算顏色，并繪制出來(lái)。減少透明圖層并使用不透明的圖層來(lái)替代它們，可以極大地提高渲染速度。

　　3).為代理方法瘦身

　　我們要盡量避免在tableview的cellforrowatindexpath的代理方法里寫(xiě)那么多代碼，這樣做不僅可以簡(jiǎn)化代碼方便維護(hù)和管理，這對(duì)程序的運(yùn)行也有幫助。

　　4).復(fù)雜視圖盡量采用純代碼的方式

　　當(dāng) UITableViewCell擁有多個(gè)子視圖時(shí)，IOS的渲染機(jī)制會(huì)拖慢速度。重寫(xiě)drawRect直接繪制內(nèi)容的方式可 以提高性能，而不是在類(lèi)初始化的時(shí)候初始化一些label或者imageview等。

　　下面就是些CPU 資源消耗原因和解決方案 還有GPU資源消耗原因和解決方案

　　對(duì)象的創(chuàng)建會(huì)分配內(nèi)存、調(diào)整屬性、甚至還有讀取文件等操作，比較消耗 CPU 資源。盡量用輕量的對(duì)象代替重量的對(duì)象，可以對(duì)性能有所優(yōu)化。比如 CALayer 比 UIView 要輕量許多，那么不需要響應(yīng)觸摸事件的控件，用 CALayer 顯示會(huì)更加合適。如果對(duì)象不涉及 UI 操作，則盡量放到后臺(tái)線程去創(chuàng)建，但可惜的是包含有 CALayer 的控件，都只能在主線程創(chuàng)建和操作。通過(guò) Storyboard 創(chuàng)建視圖對(duì)象時(shí)，其資源消耗會(huì)比直接通過(guò)代碼創(chuàng)建對(duì)象要大非常多，在性能敏感的界面里，Storyboard 并不是一個(gè)好的技術(shù)選擇。

　　1).對(duì)象的創(chuàng)建

　　盡量推遲對(duì)象創(chuàng)建的時(shí)間，并把對(duì)象的創(chuàng)建分散到多個(gè)任務(wù)中去。盡管這實(shí)現(xiàn)起來(lái)比較麻煩，并且?guī)��?lái)的優(yōu)勢(shì)并不多，但如果有能力做，還是要盡量嘗試一下。如果對(duì)象可以復(fù)用，并且復(fù)用的代價(jià)比釋放、創(chuàng)建新對(duì)象要小，那么這類(lèi)對(duì)象應(yīng)當(dāng)盡量放到一個(gè)緩存池里復(fù)用。

　　2).對(duì)象調(diào)整

　　對(duì)象的調(diào)整也經(jīng)常是消耗 CPU 資源的地方。這里特別說(shuō)一下 CALayer：CALayer 內(nèi)部并沒(méi)有屬性，當(dāng)調(diào)用屬性方法時(shí)，它內(nèi)部是通過(guò)運(yùn)行時(shí) resolveInstanceMethod 為對(duì)象臨時(shí)添加一個(gè)方法，并把對(duì)應(yīng)屬性值保存到內(nèi)部的一個(gè) Dictionary 里，同時(shí)還會(huì)通知 delegate、創(chuàng)建動(dòng)畫(huà)等等，非常消耗資源。UIView 的關(guān)于顯示相關(guān)的屬性(比如 frame/bounds/transform)等實(shí)際上都是 CALayer 屬性映射來(lái)的，所以對(duì) UIView 的這些屬性進(jìn)行調(diào)整時(shí)，消耗的資源要遠(yuǎn)大于一般的屬性。對(duì)此你在應(yīng)用中，應(yīng)該盡量減少不必要的屬性修改。 當(dāng)視圖層次調(diào)整時(shí)，UIView、CALayer 之間會(huì)出現(xiàn)很多方法調(diào)用與通知，所以在優(yōu)化性能時(shí)，應(yīng)該盡量避免調(diào)整視圖層次、添加和移除視圖。

　　3). 對(duì)象銷(xiāo)毀

　　對(duì)象的銷(xiāo)毀雖然消耗資源不多，但累積起來(lái)也是不容忽視的。通常當(dāng)容器類(lèi)持有大量對(duì)象時(shí)，其銷(xiāo)毀時(shí)的資源消耗就非常明顯。同樣的，如果對(duì)象可以放到后臺(tái)線程去釋放，那就挪到后臺(tái)線程去。這里有個(gè)小 Tip：把對(duì)象捕獲到 block 中，然后扔到后臺(tái)隊(duì)列去隨便發(fā)送個(gè)消息以避免編譯器警告，就可以讓對(duì)象在后臺(tái)線程銷(xiāo)毀了。 例如：

　　NSArray *tmp = self.array; self.array = nil; dispatch_async(queue, ^{

　　[tmp class];

　　});

　　4). 一些計(jì)算

　　視圖布局的計(jì)算是 App 中最為常見(jiàn)的消耗 CPU 資源的地方。如果能在后臺(tái)線程提前計(jì)算好視圖布局、并且對(duì)視圖布局進(jìn)行緩存，那么這個(gè)地方基本就不會(huì)產(chǎn)生性能問(wèn)題了。 不論通過(guò)何種技術(shù)對(duì)視圖進(jìn)行布局，其最終都會(huì)落到對(duì) UIView.frame/bounds/center 等屬性的調(diào)整上。上面也說(shuō)過(guò)，對(duì)這些屬性的調(diào)整非常消耗資源，所以盡量提前計(jì)算好布局，在需要時(shí)一次性調(diào)整好對(duì)應(yīng)屬性，而不要多次、頻繁的計(jì)算和調(diào)整這些屬性。 Autolayout 是蘋(píng)果本身提倡的技術(shù)，在大部分情況下也能很好的提升開(kāi)發(fā)效率，但是 Autolayout 對(duì)于復(fù)雜視圖來(lái)說(shuō)常常會(huì)產(chǎn)生嚴(yán)重的性能問(wèn)題。隨著視圖數(shù)量的增長(zhǎng)，Autolayout 帶來(lái)的 CPU 消耗會(huì)呈指數(shù)級(jí)上升。具體數(shù)據(jù)可以看這個(gè)文章：https://pilky.me/36/。 如果你不想手動(dòng)調(diào)整 frame 等屬性，你可以用一些工具方法替代(比如常見(jiàn)的 left/right/top/bottom/width/height 快捷屬性)，或者使用 ComponentKit、AsyncDisplayKit 等框架.

　　如果一個(gè)界面中包含大量文本(比如微博微信朋友圈等)，文本的寬高計(jì)算會(huì)占用很大一部分資源，并且不可避免。如果你對(duì)文本顯示沒(méi)有特殊要求，可以參考下 UILabel 內(nèi)部的實(shí)現(xiàn)方式：用 [NSAttributedString boundingRectWithSize:options:context:] 來(lái)計(jì)算文本寬高，用 -[NSAttributedString drawWithRect:options:context:] 來(lái)繪制文本。盡管這兩個(gè)方法性能不錯(cuò)，但仍舊需要放到后臺(tái)線程進(jìn)行以避免阻塞主線程。

　　5).文本的繪制

　　如果你用 CoreText 繪制文本，那就可以先生成 CoreText 排版對(duì)象，然后自己計(jì)算了，并且 CoreText 對(duì)象還能保留以供稍后繪制使用。 屏幕上能看到的所有文本內(nèi)容控件，包括 UIWebView，在底層都是通過(guò) CoreText 排版、繪制為 Bitmap 顯示的。常見(jiàn)的文本控件 (UILabel、UITextView 等)，其排版和繪制都是在主線程進(jìn)行的，當(dāng)顯示大量文本時(shí)，CPU 的壓力會(huì)非常大。對(duì)此解決方案只有一個(gè)，那就是自定義文本控件，用 TextKit 或最底層的 CoreText 對(duì)文本異步繪制。盡管這實(shí)現(xiàn)起來(lái)非常麻煩，但其帶來(lái)的優(yōu)勢(shì)也非常大，CoreText 對(duì)象創(chuàng)建好后，能直接獲取文本的寬高等信息，避免了多次計(jì)算(調(diào)整 UILabel 大小時(shí)算一遍、UILabel 繪制時(shí)內(nèi)部再算一遍);CoreText 對(duì)象占用內(nèi)存較少，可以緩存下來(lái)以備稍后多次渲染.

　　6).圖片的解碼

　　當(dāng)你用 UIImage 或 CGImageSource 的那幾個(gè)方法創(chuàng)建圖片時(shí)，圖片數(shù)據(jù)并不會(huì)立刻解碼。圖片設(shè)置到 UIImageView 或者 CALayer.contents 中去，并且 CALayer 被提交到 GPU 前，CGImage 中的數(shù)據(jù)才會(huì)得到解碼。這一步是發(fā)生在主線程的，并且不可避免。如果想要繞開(kāi)這個(gè)機(jī)制，常見(jiàn)的做法是在后臺(tái)線程先把圖片繪制到 CGBitmapContext 中，然后從 Bitmap 直接創(chuàng)建圖片。目前常見(jiàn)的網(wǎng)絡(luò)圖片庫(kù)都自帶這個(gè)功能。

　　7).圖像的繪制

　　圖像的繪制通常是指用那些以 CG 開(kāi)頭的方法把圖像繪制到畫(huà)布中，然后從畫(huà)布創(chuàng)建圖片并顯示這樣一個(gè)過(guò)程。這個(gè)最常見(jiàn)的地方就是 [UIView drawRect:] 里面了。由于 CoreGraphic 方法通常都是線程安全的，所以圖像的繪制可以很容易的放到后臺(tái)線程進(jìn)行。一個(gè)簡(jiǎn)單異步繪制的過(guò)程大致如下(實(shí)際情況會(huì)比這個(gè)復(fù)雜得多，但原理基本一致)

　　dispatch_async(backgroundQueue, ^{

　　CGContextRef ctx = CGBitmapContextCreate(...); // draw in context...

　　CGImageRef img = CGBitmapContextCreateImage(ctx);

　　CFRelease(ctx); dispatch_async(mainQueue, ^{

　　layer.contents = img;

　　});

　　});

　　GPU 資源消耗原因和解決方案

　　1. 紋理的渲染

　　所有的 Bitmap，包括圖片、文本、柵格化的內(nèi)容，最終都要由內(nèi)存提交到顯存，綁定為 GPU Texture。不論是提交到顯存的過(guò)程，還是 GPU 調(diào)整和渲染 Texture 的過(guò)程，都要消耗不少 GPU 資源。當(dāng)在較短時(shí)間顯示大量圖片時(shí)(比如 TableView 存在非常多的圖片并且快速滑動(dòng)時(shí))，CPU 占用率很低，GPU 占用非常高，界面仍然會(huì)掉幀。避免這種情況的方法只能是盡量減少在短時(shí)間內(nèi)大量圖片的顯示，盡可能將多張圖片合成為一張進(jìn)行顯示。 當(dāng)圖片過(guò)大，超過(guò) GPU 的最大紋理尺寸時(shí)，圖片需要先由 CPU 進(jìn)行預(yù)處理，這對(duì) CPU 和 GPU 都會(huì)帶來(lái)額外的資源消耗。目前來(lái)說(shuō)，iPhone 4S 以上機(jī)型，紋理尺寸上限都是 4096x4096，更詳細(xì)的資料可以看這里：iosres.com。所以，盡量不要讓圖片和視圖的大小超過(guò)這個(gè)值。

　　2.視圖的混合

　　當(dāng)多個(gè)視圖(或者說(shuō) CALayer)重疊在一起顯示時(shí)，GPU 會(huì)首先把他們混合到一起。如果視圖結(jié)構(gòu)過(guò)于復(fù)雜，混合的過(guò)程也會(huì)消耗很多 GPU 資源。為了減輕這種情況的 GPU 消耗，應(yīng)用應(yīng)當(dāng)盡量減少視圖數(shù)量和層次，并在不透明的視圖里標(biāo)明 opaque 屬性以避免無(wú)用的 Alpha 通道合成。當(dāng)然，這也可以用上面的方法，把多個(gè)視圖預(yù)先渲染為一張圖片來(lái)顯示

　　3.圖像的生成

　　CALayer 的 border、圓角、陰影、遮罩(mask)，CASharpLayer 的矢量圖形顯示，通常會(huì)觸發(fā)離屏渲染(offscreen rendering)，而離屏渲染通常發(fā)生在 GPU 中。當(dāng)一個(gè)列表視圖中出現(xiàn)大量圓角的 CALayer，并且快速滑動(dòng)時(shí)，可以觀察到 GPU 資源已經(jīng)占滿(mǎn)，而 CPU 資源消耗很少。這時(shí)界面仍然能正�；瑒�(dòng)，但平均幀數(shù)會(huì)降到很低。為了避免這種情況，可以嘗試開(kāi)啟 CALayer.shouldRasterize 屬性，但這會(huì)把原本離屏渲染的操作轉(zhuǎn)嫁到 CPU 上去。對(duì)于只需要圓角的某些場(chǎng)合，也可以用一張已經(jīng)繪制好的圓角圖片覆蓋到原本視圖上面來(lái)模擬相同的視覺(jué)效果。最徹底的解決辦法，就是把需要顯示的圖形在后臺(tái)線程繪制為圖片，避免使用圓角、陰影、遮罩等屬性。

　　如何檢測(cè)應(yīng)用的流暢度?

　　“過(guò)早的優(yōu)化是萬(wàn)惡之源”，在需求未定，性能問(wèn)題不明顯時(shí)，沒(méi)必要嘗試做優(yōu)化，而要盡量正確的實(shí)現(xiàn)功能。做性能優(yōu)化時(shí)，也最好是走修改代碼 -> Profile -> 修改代碼這樣一個(gè)流程，優(yōu)先解決最值得優(yōu)化的地方。 如果你需要一個(gè)明確的 FPS 指示器，可以嘗試一下 KMCGeigerCounter。對(duì)于 CPU 的卡頓，它可以通過(guò)內(nèi)置的 CADisplayLink 檢測(cè)出來(lái);對(duì)于 GPU 帶來(lái)的卡頓，它用了一個(gè) 1x1 的 SKView 來(lái)進(jìn)行監(jiān)視。這個(gè)項(xiàng)目有兩個(gè)小問(wèn)題：SKView 雖然能監(jiān)視到 GPU 的卡頓，但引入 SKView 本身就會(huì)對(duì) CPU/GPU 帶來(lái)額外的一點(diǎn)的資源消耗;這個(gè)項(xiàng)目在 iOS 9 下有一些兼容問(wèn)題，需要稍作調(diào)整。

　　5.你用過(guò)單元測(cè)試嗎?怎么才能做好單元測(cè)試?

　　什么是單元測(cè)試?

　　單元測(cè)試：以下內(nèi)容來(lái)自維基百科單元測(cè)試

　　在計(jì)算機(jī)編程中，單元測(cè)試(英語(yǔ)：Unit Testing)又稱(chēng)為模塊測(cè)試, 是針對(duì)程序模塊(軟件設(shè)計(jì)的最小單位)來(lái)進(jìn)行正確性檢驗(yàn)的測(cè)試工作。程序單元是應(yīng)用的最小可測(cè)試部件。在過(guò)程化編程中，一個(gè)單元就是單個(gè)程序、函數(shù)、過(guò)程等;對(duì)于面向?qū)ο缶幊�，最小單元就是方法，包括基�?lèi)(超類(lèi))、抽象類(lèi)、或者派生類(lèi)(子類(lèi))中的方法。

　　通常來(lái)說(shuō)，程序員每修改一次程序就會(huì)進(jìn)行最少一次單元測(cè)試，在編寫(xiě)程序的過(guò)程中前后很可能要進(jìn)行多次單元測(cè)試，以證實(shí)程序達(dá)到軟件規(guī)格書(shū)要求的工作目標(biāo)，沒(méi)有程序錯(cuò)誤;雖然單元測(cè)試不是什么必須的，但也不壞，這牽涉到項(xiàng)目管理的政策決定。

　　每個(gè)理想的測(cè)試案例獨(dú)立于其它案例;為測(cè)試時(shí)隔離模塊，經(jīng)常使用stubs、mock[1]或fake等測(cè)試馬甲程序。單元測(cè)試通常由軟件開(kāi)發(fā)人員編寫(xiě)，用于確保他們所寫(xiě)的代碼符合軟件需求和遵循開(kāi)發(fā)目標(biāo)。它的實(shí)施方式可以是非常手動(dòng)的(通過(guò)紙筆)，或者是做成構(gòu)建自動(dòng)化的一部分。

　　單元測(cè)試有什么好處?

　　單元測(cè)試的一個(gè)好處就是我們可以只測(cè)試單個(gè)模塊，我們可以測(cè)試 單一模塊有沒(méi)有問(wèn)題。比如說(shuō)我們?cè)陂_(kāi)發(fā)中經(jīng)常會(huì)寫(xiě)一些測(cè)試性的demo。我們寫(xiě)的測(cè)試性demo運(yùn)行正常達(dá)到了我們需要的效果，那么我們就可以把demo的效果運(yùn)用到我們的工程中進(jìn)行調(diào)試。

　　適應(yīng)變更

　　單元測(cè)試允許程序員在未來(lái)重構(gòu)代碼，并且確保模塊依然工作正確(復(fù)合測(cè)試)。這個(gè)過(guò)程就是為所有函數(shù)和方法編寫(xiě)單元測(cè)試，一旦變更導(dǎo)致錯(cuò)誤發(fā)生，借助于單元測(cè)試可以快速定位并修復(fù)錯(cuò)誤。

　　可讀性強(qiáng)的單元測(cè)試可以使程序員方便地檢查代碼片斷是否依然正常工作。良好設(shè)計(jì)的單元測(cè)試案例覆蓋程序單元分支和循環(huán)條件的所有路徑。

　　在連續(xù)的單元測(cè)試環(huán)境，通過(guò)其固有的持續(xù)維護(hù)工作，單元測(cè)試可以延續(xù)用于準(zhǔn)確反映當(dāng)任何變更發(fā)生時(shí)可執(zhí)行程序和代碼的表現(xiàn)。借助于上述開(kāi)發(fā)實(shí)踐和單元測(cè)試的覆蓋，可以分分秒秒維持準(zhǔn)確性。

　　簡(jiǎn)化集成

　　單元測(cè)試消除程序單元的不可靠，采用自底向上的測(cè)試路徑。通過(guò)先測(cè)試程序部件再測(cè)試部件組裝，使集成測(cè)試變得更加簡(jiǎn)單。

　　業(yè)界對(duì)于人工集成測(cè)試的必要性存在較大爭(zhēng)議。盡管精心設(shè)計(jì)的單元測(cè)試體系看上去實(shí)現(xiàn)了集成測(cè)試，因?yàn)榧�成測(cè)試需要人為評(píng)估一些人為因素才能證實(shí)的方面，單元測(cè)試替代集成測(cè)試不可信。一些人認(rèn)為在足夠的自動(dòng)化測(cè)試系統(tǒng)的條件下，人力集成測(cè)試組不再是必需的。事實(shí)上，真實(shí)的需求最終取決于開(kāi)發(fā)產(chǎn)品的特點(diǎn)和使用目標(biāo)。另外，人工或手動(dòng)測(cè)試很大程度上依賴(lài)于組織的可用資源。

　　文檔記錄

　　單元測(cè)試提供了系統(tǒng)的一種文檔記錄。借助于查看單元測(cè)試提供的功能和單元測(cè)試中如何使用程序單元，開(kāi)發(fā)人員可以直觀的理解程序單元的基礎(chǔ)API。

　　單元測(cè)試具體表現(xiàn)了程序單元成功的關(guān)鍵特點(diǎn)。這些特點(diǎn)可以指出正確使用和非正確使用程序單元，也能指出需要捕獲的程序單元的負(fù)面表現(xiàn)(譯注：異常和錯(cuò)誤)。盡管很多軟件開(kāi)發(fā)環(huán)境不僅依賴(lài)于代碼做為產(chǎn)品文檔，在單元測(cè)試中和單元測(cè)試本身確實(shí)文檔化了程序單元的上述關(guān)鍵特點(diǎn)。

　　另一方面，傳統(tǒng)文檔易受程序本身實(shí)現(xiàn)的影響，并且時(shí)效性難以保證(如設(shè)計(jì)變更、功能擴(kuò)展等在不太嚴(yán)格時(shí)經(jīng)常不能保持文檔同步更新)。

　　表達(dá)設(shè)計(jì)

　　在測(cè)試驅(qū)動(dòng)開(kāi)發(fā)的軟件實(shí)踐中，單元測(cè)試可以取代正式的設(shè)計(jì)。每一個(gè)單元測(cè)試案例均可以視為一項(xiàng)類(lèi)、方法和待觀察行為等設(shè)計(jì)元素。下面的Java例可以幫助說(shuō)明這一點(diǎn)。 當(dāng)然，單元測(cè)試缺乏圖的可讀性，但UML圖可以在自由工具(通�？蓮腎DE擴(kuò)展獲取)中為大多數(shù)現(xiàn)代程序語(yǔ)言生成UML圖，很難要求采購(gòu)昂貴的UML設(shè)計(jì)套裝軟件。自由工具，類(lèi)似于基于xUnit框架的工具，測(cè)試結(jié)果輸出到一些可生成供人工識(shí)讀的圖形化工具系統(tǒng)中去。

　　分離接口和實(shí)現(xiàn)

　　因?yàn)楹芏囝?lèi)會(huì)引用其它類(lèi)，對(duì)這個(gè)類(lèi)的測(cè)試經(jīng)常會(huì)要求測(cè)試其它的類(lèi)。一個(gè)最普遍的例子是依賴(lài)于數(shù)據(jù)庫(kù)的類(lèi)：為了測(cè)試它，測(cè)試人員通常編寫(xiě)代碼去操作數(shù)據(jù)庫(kù)。這是不對(duì)的，因?yàn)閱卧獪y(cè)試不應(yīng)超出待測(cè)試的類(lèi)邊界。

　　作為替代，軟件開(kāi)發(fā)人員應(yīng)創(chuàng)建一個(gè)數(shù)據(jù)庫(kù)連接的抽象接口，然后實(shí)現(xiàn)這個(gè)接口的模擬對(duì)象。通過(guò)對(duì)代碼所需附件的抽象(臨時(shí)降低了網(wǎng)狀的耦合效應(yīng))，這些獨(dú)立程序單元較前者更能被完整測(cè)試。高質(zhì)量的代碼單元也可提供更好的可維護(hù)性。

　　局限

　　測(cè)試不可能發(fā)現(xiàn)所有的程序錯(cuò)誤，單元測(cè)試也不例外。按定義，單元測(cè)試只測(cè)試程序單元自身的功能。因此，它不能發(fā)現(xiàn)集成錯(cuò)誤、性能問(wèn)題、或者其他系統(tǒng)級(jí)別的問(wèn)題。單元測(cè)試結(jié)合其他軟件測(cè)試活動(dòng)更為有效。與其它形式的軟件測(cè)試類(lèi)似，單元測(cè)試只能表明測(cè)到的問(wèn)題，不能表明不存在未測(cè)試到的錯(cuò)誤。

　　軟件測(cè)試是一個(gè)組合問(wèn)題。例如，每一個(gè)布爾型的決斷語(yǔ)句需要至少兩種測(cè)試：一個(gè)返回真，一個(gè)返回假。因此，針對(duì)每行書(shū)寫(xiě)的代碼，程序員通常需要寫(xiě)3至5行的測(cè)試代碼。[3]這很明顯地很花時(shí)間而且對(duì)此的投入可能并不值得。也有些問(wèn)題是根本不能簡(jiǎn)單地檢測(cè)出來(lái)的——例如具不確定性的或牽扯到多線程的問(wèn)題。此外，替單元測(cè)試寫(xiě)的代碼可能就像要測(cè)試的代碼一樣有程序錯(cuò)誤。佛瑞德·布魯克斯在人月神話(huà)一書(shū)中舉例說(shuō)明：“絕對(duì)不要帶兩個(gè)計(jì)時(shí)器去海邊。最好總是帶一或三個(gè)”。意味著，如果兩個(gè)計(jì)時(shí)器互相沖突的話(huà)，你該怎么知道哪個(gè)是對(duì)的?為了獲得單元測(cè)試的好處，在軟件開(kāi)發(fā)過(guò)程中應(yīng)形成一套嚴(yán)格紀(jì)律意識(shí)。仔細(xì)保留記錄是必要的，不僅僅只保留執(zhí)行的測(cè)試，也包括保留對(duì)應(yīng)的源碼和其它軟件單元的變更歷史。即，使用版本控制系統(tǒng)是必要的。如果后續(xù)版本不能通過(guò)一個(gè)以前測(cè)試通過(guò)的單元測(cè)試，版本控制系統(tǒng)可以提供對(duì)應(yīng)時(shí)間段對(duì)源代碼所做的變更清單。

　　每天養(yǎng)成查看單元測(cè)試案例失敗測(cè)試并及時(shí)確定錯(cuò)誤原因的習(xí)慣是必要的。如果沒(méi)有這樣的流程，沒(méi)有在團(tuán)隊(duì)工作流程中體現(xiàn)，單元測(cè)試系列將走向不同步，造成越來(lái)越多的錯(cuò)誤和越來(lái)越低效的單元測(cè)試案例系列。

　　iOS中的單元測(cè)試

　　在開(kāi)發(fā)中，經(jīng)常用到的單元測(cè)試一是測(cè)試某個(gè)模塊的功能，也就是說(shuō)把這個(gè)模塊獨(dú)立起來(lái)，單獨(dú)進(jìn)行測(cè)試。用到最多的應(yīng)該是測(cè)試模塊功能和接口調(diào)試功能。當(dāng)然單元測(cè)試還有一些高級(jí)的用法自動(dòng)測(cè)試和自動(dòng)發(fā)布等。

　　OCUnit(即用XCTest進(jìn)行測(cè)試)其實(shí)就是蘋(píng)果自帶的測(cè)試框架，我們主要講的就是這個(gè)。GHUnit是一個(gè)可視化的測(cè)試框架。(有了它，你可以點(diǎn)擊APP來(lái)決定測(cè)試哪個(gè)方法，并且可以點(diǎn)擊查看測(cè)試結(jié)果等。)OCMock就是模擬某個(gè)方法或者屬性的返回值，你可能會(huì)疑惑為什么要這樣做?使用用模型生成的模型對(duì)象，再傳進(jìn)去不就可以了?答案是可以的，但是有特殊的情況。比如你測(cè)試的是方法A，方法A里面調(diào)用到了方法B，而且方法B是有參數(shù)傳入，但又不是方法A所提供。這時(shí)候，你可以使用OCMock來(lái)模擬方法B返回的值。(在不影響測(cè)試的情況下，就可以這樣去模擬。)除了這些，在沒(méi)有網(wǎng)絡(luò)的情況下，也可以通過(guò)OCMock模擬返回的數(shù)據(jù)。UITests就是通過(guò)代碼化來(lái)實(shí)現(xiàn)自動(dòng)點(diǎn)擊界面，輸入文字等功能。靠人工操作的方式來(lái)覆蓋所有測(cè)試用例是非常困難的，尤其是加入新功能以后，舊的功能也要重新測(cè)試一遍，這導(dǎo)致了測(cè)試需要花非常多的時(shí)間來(lái)進(jìn)行回歸測(cè)試，這里產(chǎn)生了大量重復(fù)的工作，而這些重復(fù)的工作有些是可以自動(dòng)完成的，這時(shí)候UITests就可以幫助解決這個(gè)問(wèn)題了。

　　關(guān)于單元測(cè)試可以參考文章

　　6.你知道的的本地?cái)?shù)據(jù)持久化都有哪些。你比較喜歡用哪些 為什么?

　　采用的數(shù)據(jù)存儲(chǔ)的方式有以下幾種：

　　1、 FMDB(常用)

　　2、 Sqlite(次之)

　　3、 Coredata(次之)

　　4、 NSUserdefaults(最多使用)

　　5、 序列化反序列化(歸檔和解檔)

　　6、 MongoDB(小眾型的)

　　大家討論用的最多的是FMDB，原因很簡(jiǎn)單，關(guān)系型數(shù)據(jù)庫(kù)，使用方便(相對(duì)于沒(méi)經(jīng)過(guò)封裝和加工的Sqlite來(lái)說(shuō))。其次就是sqlite和coredata 當(dāng)然使用者三種主要是為了緩存。因?yàn)槲覀冊(cè)陂_(kāi)發(fā)中為了給用戶(hù)更好的體驗(yàn)，就采用緩存的形式。一般情況下要做的操作就是在本地建立一個(gè)數(shù)據(jù)庫(kù)(本地后臺(tái))。