今天給大家?guī)砦恼轮v述IOS程序員招聘面試時(shí)候可能出現(xiàn)的部分問題以及答案，對于希望擔(dān)任IOS程序員的各位來說是必讀的干貨。
IOS程序員面試中被面試官問到的問題以及答案
1. 請你談?wù)剆tatic和宏定義的區(qū)別。什么時(shí)候用static什么時(shí)候用宏定義。
讓你聲明的常量只在你聲明的文件里有作用要不編譯器會保存
宏定義：
1). 一般來說我們使用宏定義最常見的是定義一些常量 簡單的”函數(shù)”(比如求兩個(gè)數(shù)的最大小值)
例如：定義常量PI
#define PI 3.1415926
定義函數(shù)
#define MIN(A,B) ((A) < (B) ? (A):(B))
我們不對宏定義進(jìn)行修改
2) . 使用宏定義可以在很大程度上可以簡化我們的代碼
例如：我們在寫單例的時(shí)候 之前我們寫的是
#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//如果我們使用宏定義的話我們可以這樣寫：#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ā)揮自己的想象，簡化代碼~ 宏定義實(shí)質(zhì)是一個(gè)預(yù)編譯指令，在程序未運(yùn)行之前將某些指令付給相應(yīng)的變量。
小結(jié)一下： static標(biāo)記的變量會存儲到全局變量區(qū)，生命周期和程序相同。而宏定義所定義的生命周期與所在的載體的生命周期有關(guān).
static只在聲明的類中可見。
在聲明的類中結(jié)束后，再次使用還是之前的值。
2.你是怎么看待代理 通知的 他們有什么區(qū)別?
首先，我們把代理通知 放到一起來討論第一反映是傳值。 ok，下面慢慢來說各個(gè)的用法和區(qū)別。
通知中心
通過NSNotification可以給多個(gè)對象傳遞數(shù)據(jù)和消息(多個(gè)傳遞) 代理 通過protocol(代理模式)只能給一個(gè)對象傳遞數(shù)據(jù)和消息(單一傳遞)“一對一”，對同一個(gè)協(xié)議，一個(gè)對象只能設(shè)置一個(gè)代理delegate，所以單例對象就不能用代理(可以用多點(diǎn)回調(diào)，下面見解)。
代理更注重過程信息的傳輸：比如發(fā)起一個(gè)網(wǎng)絡(luò)請求，可能想要知道此時(shí)請求是否已經(jīng)開始、是否收到了數(shù)據(jù)、數(shù)據(jù)是否已經(jīng)接受完成、數(shù)據(jù)接收失敗。
區(qū)別： 代理和通知的區(qū)別應(yīng)該主要是一對一和一對多的關(guān)系。delegate的多點(diǎn)回調(diào)相對notification更加便捷，更多方便，讓項(xiàng)目更好維護(hù)。
3.說說你對內(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的使用
通過autoreleasepool控制autorelease對象的釋放 向一個(gè)對象發(fā)送autorelease消息。這個(gè)對象何時(shí)釋放取決于autoreleasepool
copy方法
跟retain不同，一個(gè)對象想要copy，生成自己的副本，需要實(shí)現(xiàn)NSCopying協(xié)議，定義copy的細(xì)節(jié)(如何copy)如果類沒有接受NSCoping協(xié)議而給類發(fā)送copy消息，會引起crash 總結(jié)： OC借助引用計(jì)數(shù)機(jī)制去管理內(nèi)存，凡是使用了alloc copy retain 等 方法，增加了引用計(jì)數(shù)，就要使用release 和autorelease 減少引用計(jì)數(shù)，引用計(jì)數(shù)為0的時(shí)候，對象所占的內(nèi)存，被系統(tǒng)回收。
autorelease是未來某個(gè)時(shí)間(出autorelease)引用減一，不是即時(shí)的。
不是任何對象都可以接受copy消息。只有接受了NSCoping協(xié)議的對象才接受copy消息。
4.談?wù)勀銓OS性能優(yōu)化的理解.
談起iOS的性能優(yōu)化我們首先想到的是應(yīng)該是tableview表視圖的優(yōu)化。關(guān)于表視圖的優(yōu)化我們可以從以下幾個(gè)方面來看:
1).tableviewcell渲染
繪制時(shí)要盡可能的避免分配資源，比如UIFont，NSDateFormatter或者任何在繪制時(shí) 需要的對象，推薦使用類層級的初始化方法中執(zhí)行分配，并將其存儲為靜態(tài)變量。
2).圖層渲染的問題
透明圖層對渲染性能會有一定的影響，系統(tǒng)必須將透明圖層與下面的視圖混合起來計(jì)算顏色，并繪制出來。減少透明圖層并使用不透明的圖層來替代它們，可以極大地提高渲染速度。
3).為代理方法瘦身
我們要盡量避免在tableview的cellforrowatindexpath的代理方法里寫那么多代碼，這樣做不僅可以簡化代碼方便維護(hù)和管理，這對程序的運(yùn)行也有幫助。
4).復(fù)雜視圖盡量采用純代碼的方式
當(dāng) UITableViewCell擁有多個(gè)子視圖時(shí)，IOS的渲染機(jī)制會拖慢速度。重寫drawRect直接繪制內(nèi)容的方式可 以提高性能，而不是在類初始化的時(shí)候初始化一些label或者imageview等。
下面就是些CPU 資源消耗原因和解決方案 還有GPU資源消耗原因和解決方案
對象的創(chuàng)建會分配內(nèi)存、調(diào)整屬性、甚至還有讀取文件等操作，比較消耗 CPU 資源。盡量用輕量的對象代替重量的對象，可以對性能有所優(yōu)化。比如 CALayer 比 UIView 要輕量許多，那么不需要響應(yīng)觸摸事件的控件，用 CALayer 顯示會更加合適。如果對象不涉及 UI 操作，則盡量放到后臺線程去創(chuàng)建，但可惜的是包含有 CALayer 的控件，都只能在主線程創(chuàng)建和操作。通過 Storyboard 創(chuàng)建視圖對象時(shí)，其資源消耗會比直接通過代碼創(chuàng)建對象要大非常多，在性能敏感的界面里，Storyboard 并不是一個(gè)好的技術(shù)選擇。
1).對象的創(chuàng)建
盡量推遲對象創(chuàng)建的時(shí)間，并把對象的創(chuàng)建分散到多個(gè)任務(wù)中去。盡管這實(shí)現(xiàn)起來比較麻煩，并且?guī)淼膬?yōu)勢并不多，但如果有能力做，還是要盡量嘗試一下。如果對象可以復(fù)用，并且復(fù)用的代價(jià)比釋放、創(chuàng)建新對象要小，那么這類對象應(yīng)當(dāng)盡量放到一個(gè)緩存池里復(fù)用。
2).對象調(diào)整
對象的調(diào)整也經(jīng)常是消耗 CPU 資源的地方。這里特別說一下 CALayer：CALayer 內(nèi)部并沒有屬性，當(dāng)調(diào)用屬性方法時(shí)，它內(nèi)部是通過運(yùn)行時(shí) resolveInstanceMethod 為對象臨時(shí)添加一個(gè)方法，并把對應(yīng)屬性值保存到內(nèi)部的一個(gè) Dictionary 里，同時(shí)還會通知 delegate、創(chuàng)建動畫等等，非常消耗資源。UIView 的關(guān)于顯示相關(guān)的屬性(比如 frame/bounds/transform)等實(shí)際上都是 CALayer 屬性映射來的，所以對 UIView 的這些屬性進(jìn)行調(diào)整時(shí)，消耗的資源要遠(yuǎn)大于一般的屬性。對此你在應(yīng)用中，應(yīng)該盡量減少不必要的屬性修改。 當(dāng)視圖層次調(diào)整時(shí)，UIView、CALayer 之間會出現(xiàn)很多方法調(diào)用與通知，所以在優(yōu)化性能時(shí)，應(yīng)該盡量避免調(diào)整視圖層次、添加和移除視圖。
3). 對象銷毀
對象的銷毀雖然消耗資源不多，但累積起來也是不容忽視的。通常當(dāng)容器類持有大量對象時(shí)，其銷毀時(shí)的資源消耗就非常明顯。同樣的，如果對象可以放到后臺線程去釋放，那就挪到后臺線程去。這里有個(gè)小 Tip：把對象捕獲到 block 中，然后扔到后臺隊(duì)列去隨便發(fā)送個(gè)消息以避免編譯器警告，就可以讓對象在后臺線程銷毀了。 例如：
NSArray *tmp = self.array; self.array = nil; dispatch_async(queue, ^{
[tmp class];
});
4). 一些計(jì)算
視圖布局的計(jì)算是 App 中最為常見的消耗 CPU 資源的地方。如果能在后臺線程提前計(jì)算好視圖布局、并且對視圖布局進(jìn)行緩存，那么這個(gè)地方基本就不會產(chǎn)生性能問題了。 不論通過何種技術(shù)對視圖進(jìn)行布局，其最終都會落到對 UIView.frame/bounds/center 等屬性的調(diào)整上。上面也說過，對這些屬性的調(diào)整非常消耗資源，所以盡量提前計(jì)算好布局，在需要時(shí)一次性調(diào)整好對應(yīng)屬性，而不要多次、頻繁的計(jì)算和調(diào)整這些屬性。 Autolayout 是蘋果本身提倡的技術(shù)，在大部分情況下也能很好的提升開發(fā)效率，但是 Autolayout 對于復(fù)雜視圖來說常常會產(chǎn)生嚴(yán)重的性能問題。隨著視圖數(shù)量的增長，Autolayout 帶來的 CPU 消耗會呈指數(shù)級上升。具體數(shù)據(jù)可以看這個(gè)文章：https://pilky.me/36/。 如果你不想手動調(diào)整 frame 等屬性，你可以用一些工具方法替代(比如常見的 left/right/top/bottom/width/height 快捷屬性)，或者使用 ComponentKit、AsyncDisplayKit 等框架.
如果一個(gè)界面中包含大量文本(比如微博微信朋友圈等)，文本的寬高計(jì)算會占用很大一部分資源，并且不可避免。如果你對文本顯示沒有特殊要求，可以參考下 UILabel 內(nèi)部的實(shí)現(xiàn)方式：用 [NSAttributedString boundingRectWithSize:options:context:] 來計(jì)算文本寬高，用 -[NSAttributedString drawWithRect:options:context:] 來繪制文本。盡管這兩個(gè)方法性能不錯(cuò)，但仍舊需要放到后臺線程進(jìn)行以避免阻塞主線程。
5).文本的繪制
如果你用 CoreText 繪制文本，那就可以先生成 CoreText 排版對象，然后自己計(jì)算了，并且 CoreText 對象還能保留以供稍后繪制使用。 屏幕上能看到的所有文本內(nèi)容控件，包括 UIWebView，在底層都是通過 CoreText 排版、繪制為 Bitmap 顯示的。常見的文本控件 (UILabel、UITextView 等)，其排版和繪制都是在主線程進(jìn)行的，當(dāng)顯示大量文本時(shí)，CPU 的壓力會非常大。對此解決方案只有一個(gè)，那就是自定義文本控件，用 TextKit 或最底層的 CoreText 對文本異步繪制。盡管這實(shí)現(xiàn)起來非常麻煩，但其帶來的優(yōu)勢也非常大，CoreText 對象創(chuàng)建好后，能直接獲取文本的寬高等信息，避免了多次計(jì)算(調(diào)整 UILabel 大小時(shí)算一遍、UILabel 繪制時(shí)內(nèi)部再算一遍);CoreText 對象占用內(nèi)存較少，可以緩存下來以備稍后多次渲染.
6).圖片的解碼
當(dāng)你用 UIImage 或 CGImageSource 的那幾個(gè)方法創(chuàng)建圖片時(shí)，圖片數(shù)據(jù)并不會立刻解碼。圖片設(shè)置到 UIImageView 或者 CALayer.contents 中去，并且 CALayer 被提交到 GPU 前，CGImage 中的數(shù)據(jù)才會得到解碼。這一步是發(fā)生在主線程的，并且不可避免。如果想要繞開這個(gè)機(jī)制，常見的做法是在后臺線程先把圖片繪制到 CGBitmapContext 中，然后從 Bitmap 直接創(chuàng)建圖片。目前常見的網(wǎng)絡(luò)圖片庫都自帶這個(gè)功能。
7).圖像的繪制
圖像的繪制通常是指用那些以 CG 開頭的方法把圖像繪制到畫布中，然后從畫布創(chuàng)建圖片并顯示這樣一個(gè)過程。這個(gè)最常見的地方就是 [UIView drawRect:] 里面了。由于 CoreGraphic 方法通常都是線程安全的，所以圖像的繪制可以很容易的放到后臺線程進(jìn)行。一個(gè)簡單異步繪制的過程大致如下(實(shí)際情況會比這個(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。不論是提交到顯存的過程，還是 GPU 調(diào)整和渲染 Texture 的過程，都要消耗不少 GPU 資源。當(dāng)在較短時(shí)間顯示大量圖片時(shí)(比如 TableView 存在非常多的圖片并且快速滑動時(shí))，CPU 占用率很低，GPU 占用非常高，界面仍然會掉幀。避免這種情況的方法只能是盡量減少在短時(shí)間內(nèi)大量圖片的顯示，盡可能將多張圖片合成為一張進(jìn)行顯示。 當(dāng)圖片過大，超過 GPU 的最大紋理尺寸時(shí)，圖片需要先由 CPU 進(jìn)行預(yù)處理，這對 CPU 和 GPU 都會帶來額外的資源消耗。目前來說，iPhone 4S 以上機(jī)型，紋理尺寸上限都是 4096x4096，更詳細(xì)的資料可以看這里：iosres.com。所以，盡量不要讓圖片和視圖的大小超過這個(gè)值。
2.視圖的混合
當(dāng)多個(gè)視圖(或者說 CALayer)重疊在一起顯示時(shí)，GPU 會首先把他們混合到一起。如果視圖結(jié)構(gòu)過于復(fù)雜，混合的過程也會消耗很多 GPU 資源。為了減輕這種情況的 GPU 消耗，應(yīng)用應(yīng)當(dāng)盡量減少視圖數(shù)量和層次，并在不透明的視圖里標(biāo)明 opaque 屬性以避免無用的 Alpha 通道合成。當(dāng)然，這也可以用上面的方法，把多個(gè)視圖預(yù)先渲染為一張圖片來顯示
3.圖像的生成
CALayer 的 border、圓角、陰影、遮罩(mask)，CASharpLayer 的矢量圖形顯示，通常會觸發(fā)離屏渲染(offscreen rendering)，而離屏渲染通常發(fā)生在 GPU 中。當(dāng)一個(gè)列表視圖中出現(xiàn)大量圓角的 CALayer，并且快速滑動時(shí)，可以觀察到 GPU 資源已經(jīng)占滿，而 CPU 資源消耗很少。這時(shí)界面仍然能正�；瑒�，但平均幀數(shù)會降到很低。為了避免這種情況，可以嘗試開啟 CALayer.shouldRasterize 屬性，但這會把原本離屏渲染的操作轉(zhuǎn)嫁到 CPU 上去。對于只需要圓角的某些場合，也可以用一張已經(jīng)繪制好的圓角圖片覆蓋到原本視圖上面來模擬相同的視覺效果。最徹底的解決辦法，就是把需要顯示的圖形在后臺線程繪制為圖片，避免使用圓角、陰影、遮罩等屬性。
如何檢測應(yīng)用的流暢度?
“過早的優(yōu)化是萬惡之源”，在需求未定，性能問題不明顯時(shí)，沒必要嘗試做優(yōu)化，而要盡量正確的實(shí)現(xiàn)功能。做性能優(yōu)化時(shí)，也最好是走修改代碼 -> Profile -> 修改代碼這樣一個(gè)流程，優(yōu)先解決最值得優(yōu)化的地方。 如果你需要一個(gè)明確的 FPS 指示器，可以嘗試一下 KMCGeigerCounter。對于 CPU 的卡頓，它可以通過內(nèi)置的 CADisplayLink 檢測出來;對于 GPU 帶來的卡頓，它用了一個(gè) 1x1 的 SKView 來進(jìn)行監(jiān)視。這個(gè)項(xiàng)目有兩個(gè)小問題：SKView 雖然能監(jiān)視到 GPU 的卡頓，但引入 SKView 本身就會對 CPU/GPU 帶來額外的一點(diǎn)的資源消耗;這個(gè)項(xiàng)目在 iOS 9 下有一些兼容問題，需要稍作調(diào)整。
5.你用過單元測試嗎?怎么才能做好單元測試?
什么是單元測試?
單元測試：以下內(nèi)容來自維基百科單元測試
在計(jì)算機(jī)編程中，單元測試(英語：Unit Testing)又稱為模塊測試, 是針對程序模塊(軟件設(shè)計(jì)的最小單位)來進(jìn)行正確性檢驗(yàn)的測試工作。程序單元是應(yīng)用的最小可測試部件。在過程化編程中，一個(gè)單元就是單個(gè)程序、函數(shù)、過程等;對于面向?qū)ο缶幊�，最小單元就是方法，包括基�?超類)、抽象類、或者派生類(子類)中的方法。
通常來說，程序員每修改一次程序就會進(jìn)行最少一次單元測試，在編寫程序的過程中前后很可能要進(jìn)行多次單元測試，以證實(shí)程序達(dá)到軟件規(guī)格書要求的工作目標(biāo)，沒有程序錯(cuò)誤;雖然單元測試不是什么必須的，但也不壞，這牽涉到項(xiàng)目管理的政策決定。
每個(gè)理想的測試案例獨(dú)立于其它案例;為測試時(shí)隔離模塊，經(jīng)常使用stubs、mock[1]或fake等測試馬甲程序。單元測試通常由軟件開發(fā)人員編寫，用于確保他們所寫的代碼符合軟件需求和遵循開發(fā)目標(biāo)。它的實(shí)施方式可以是非常手動的(通過紙筆)，或者是做成構(gòu)建自動化的一部分。
單元測試有什么好處?
單元測試的一個(gè)好處就是我們可以只測試單個(gè)模塊，我們可以測試 單一模塊有沒有問題。比如說我們在開發(fā)中經(jīng)常會寫一些測試性的demo。我們寫的測試性demo運(yùn)行正常達(dá)到了我們需要的效果，那么我們就可以把demo的效果運(yùn)用到我們的工程中進(jìn)行調(diào)試。
適應(yīng)變更
單元測試允許程序員在未來重構(gòu)代碼，并且確保模塊依然工作正確(復(fù)合測試)。這個(gè)過程就是為所有函數(shù)和方法編寫單元測試，一旦變更導(dǎo)致錯(cuò)誤發(fā)生，借助于單元測試可以快速定位并修復(fù)錯(cuò)誤。
可讀性強(qiáng)的單元測試可以使程序員方便地檢查代碼片斷是否依然正常工作。良好設(shè)計(jì)的單元測試案例覆蓋程序單元分支和循環(huán)條件的所有路徑。
在連續(xù)的單元測試環(huán)境，通過其固有的持續(xù)維護(hù)工作，單元測試可以延續(xù)用于準(zhǔn)確反映當(dāng)任何變更發(fā)生時(shí)可執(zhí)行程序和代碼的表現(xiàn)。借助于上述開發(fā)實(shí)踐和單元測試的覆蓋，可以分分秒秒維持準(zhǔn)確性。
簡化集成
單元測試消除程序單元的不可靠，采用自底向上的測試路徑。通過先測試程序部件再測試部件組裝，使集成測試變得更加簡單。
業(yè)界對于人工集成測試的必要性存在較大爭議。盡管精心設(shè)計(jì)的單元測試體系看上去實(shí)現(xiàn)了集成測試，因?yàn)榧蓽y試需要人為評估一些人為因素才能證實(shí)的方面，單元測試替代集成測試不可信。一些人認(rèn)為在足夠的自動化測試系統(tǒng)的條件下，人力集成測試組不再是必需的。事實(shí)上，真實(shí)的需求最終取決于開發(fā)產(chǎn)品的特點(diǎn)和使用目標(biāo)。另外，人工或手動測試很大程度上依賴于組織的可用資源。
文檔記錄
單元測試提供了系統(tǒng)的一種文檔記錄。借助于查看單元測試提供的功能和單元測試中如何使用程序單元，開發(fā)人員可以直觀的理解程序單元的基礎(chǔ)API。
單元測試具體表現(xiàn)了程序單元成功的關(guān)鍵特點(diǎn)。這些特點(diǎn)可以指出正確使用和非正確使用程序單元，也能指出需要捕獲的程序單元的負(fù)面表現(xiàn)(譯注：異常和錯(cuò)誤)。盡管很多軟件開發(fā)環(huán)境不僅依賴于代碼做為產(chǎn)品文檔，在單元測試中和單元測試本身確實(shí)文檔化了程序單元的上述關(guān)鍵特點(diǎn)。
另一方面，傳統(tǒng)文檔易受程序本身實(shí)現(xiàn)的影響，并且時(shí)效性難以保證(如設(shè)計(jì)變更、功能擴(kuò)展等在不太嚴(yán)格時(shí)經(jīng)常不能保持文檔同步更新)。
表達(dá)設(shè)計(jì)
在測試驅(qū)動開發(fā)的軟件實(shí)踐中，單元測試可以取代正式的設(shè)計(jì)。每一個(gè)單元測試案例均可以視為一項(xiàng)類、方法和待觀察行為等設(shè)計(jì)元素。下面的Java例可以幫助說明這一點(diǎn)。 當(dāng)然，單元測試缺乏圖的可讀性，但UML圖可以在自由工具(通常可從IDE擴(kuò)展獲取)中為大多數(shù)現(xiàn)代程序語言生成UML圖，很難要求采購昂貴的UML設(shè)計(jì)套裝軟件。自由工具，類似于基于xUnit框架的工具，測試結(jié)果輸出到一些可生成供人工識讀的圖形化工具系統(tǒng)中去。
分離接口和實(shí)現(xiàn)
因?yàn)楹芏囝悤闷渌�，對這個(gè)類的測試經(jīng)常會要求測試其它的類。一個(gè)最普遍的例子是依賴于數(shù)據(jù)庫的類：為了測試它，測試人員通常編寫代碼去操作數(shù)據(jù)庫。這是不對的，因?yàn)閱卧獪y試不應(yīng)超出待測試的類邊界。
作為替代，軟件開發(fā)人員應(yīng)創(chuàng)建一個(gè)數(shù)據(jù)庫連接的抽象接口，然后實(shí)現(xiàn)這個(gè)接口的模擬對象。通過對代碼所需附件的抽象(臨時(shí)降低了網(wǎng)狀的耦合效應(yīng))，這些獨(dú)立程序單元較前者更能被完整測試。高質(zhì)量的代碼單元也可提供更好的可維護(hù)性。
局限
測試不可能發(fā)現(xiàn)所有的程序錯(cuò)誤，單元測試也不例外。按定義，單元測試只測試程序單元自身的功能。因此，它不能發(fā)現(xiàn)集成錯(cuò)誤、性能問題、或者其他系統(tǒng)級別的問題。單元測試結(jié)合其他軟件測試活動更為有效。與其它形式的軟件測試類似，單元測試只能表明測到的問題，不能表明不存在未測試到的錯(cuò)誤。
軟件測試是一個(gè)組合問題。例如，每一個(gè)布爾型的決斷語句需要至少兩種測試：一個(gè)返回真，一個(gè)返回假。因此，針對每行書寫的代碼，程序員通常需要寫3至5行的測試代碼。[3]這很明顯地很花時(shí)間而且對此的投入可能并不值得。也有些問題是根本不能簡單地檢測出來的——例如具不確定性的或牽扯到多線程的問題。此外，替單元測試寫的代碼可能就像要測試的代碼一樣有程序錯(cuò)誤。佛瑞德·布魯克斯在人月神話一書中舉例說明：“絕對不要帶兩個(gè)計(jì)時(shí)器去海邊。最好總是帶一或三個(gè)”。意味著，如果兩個(gè)計(jì)時(shí)器互相沖突的話，你該怎么知道哪個(gè)是對的?為了獲得單元測試的好處，在軟件開發(fā)過程中應(yīng)形成一套嚴(yán)格紀(jì)律意識。仔細(xì)保留記錄是必要的，不僅僅只保留執(zhí)行的測試，也包括保留對應(yīng)的源碼和其它軟件單元的變更歷史。即，使用版本控制系統(tǒng)是必要的。如果后續(xù)版本不能通過一個(gè)以前測試通過的單元測試，版本控制系統(tǒng)可以提供對應(yīng)時(shí)間段對源代碼所做的變更清單。
每天養(yǎng)成查看單元測試案例失敗測試并及時(shí)確定錯(cuò)誤原因的習(xí)慣是必要的。如果沒有這樣的流程，沒有在團(tuán)隊(duì)工作流程中體現(xiàn)，單元測試系列將走向不同步，造成越來越多的錯(cuò)誤和越來越低效的單元測試案例系列。
iOS中的單元測試
在開發(fā)中，經(jīng)常用到的單元測試一是測試某個(gè)模塊的功能，也就是說把這個(gè)模塊獨(dú)立起來，單獨(dú)進(jìn)行測試。用到最多的應(yīng)該是測試模塊功能和接口調(diào)試功能。當(dāng)然單元測試還有一些高級的用法自動測試和自動發(fā)布等。
OCUnit(即用XCTest進(jìn)行測試)其實(shí)就是蘋果自帶的測試框架，我們主要講的就是這個(gè)。GHUnit是一個(gè)可視化的測試框架。(有了它，你可以點(diǎn)擊APP來決定測試哪個(gè)方法，并且可以點(diǎn)擊查看測試結(jié)果等。)OCMock就是模擬某個(gè)方法或者屬性的返回值，你可能會疑惑為什么要這樣做?使用用模型生成的模型對象，再傳進(jìn)去不就可以了?答案是可以的，但是有特殊的情況。比如你測試的是方法A，方法A里面調(diào)用到了方法B，而且方法B是有參數(shù)傳入，但又不是方法A所提供。這時(shí)候，你可以使用OCMock來模擬方法B返回的值。(在不影響測試的情況下，就可以這樣去模擬。)除了這些，在沒有網(wǎng)絡(luò)的情況下，也可以通過OCMock模擬返回的數(shù)據(jù)。UITests就是通過代碼化來實(shí)現(xiàn)自動點(diǎn)擊界面，輸入文字等功能。靠人工操作的方式來覆蓋所有測試用例是非常困難的，尤其是加入新功能以后，舊的功能也要重新測試一遍，這導(dǎo)致了測試需要花非常多的時(shí)間來進(jìn)行回歸測試，這里產(chǎn)生了大量重復(fù)的工作，而這些重復(fù)的工作有些是可以自動完成的，這時(shí)候UITests就可以幫助解決這個(gè)問題了。
關(guān)于單元測試可以參考文章
6.你知道的的本地?cái)?shù)據(jù)持久化都有哪些。你比較喜歡用哪些 為什么?
采用的數(shù)據(jù)存儲的方式有以下幾種：
1、 FMDB(常用)
2、 Sqlite(次之)
3、 Coredata(次之)
4、 NSUserdefaults(最多使用)
5、 序列化反序列化(歸檔和解檔)
6、 MongoDB(小眾型的)
大家討論用的最多的是FMDB，原因很簡單，關(guān)系型數(shù)據(jù)庫，使用方便(相對于沒經(jīng)過封裝和加工的Sqlite來說)。其次就是sqlite和coredata 當(dāng)然使用者三種主要是為了緩存。因?yàn)槲覀冊陂_發(fā)中為了給用戶更好的體驗(yàn)，就采用緩存的形式。一般情況下要做的操作就是在本地建立一個(gè)數(shù)據(jù)庫(本地后臺)。