面試中被面試官問到的問題答案(一)

時間 2019-11-21

原文原文鏈接

如下問題的答案是以前寫的一篇文章面試中被面試官問到的問題如今把問題的答案整理了一份出來給你們。但願對你們有所幫助。若是整理的答案有問題，請聯繫我。shavekevin@gmail.comhtml

1.請你談談static和宏定義的區別。何時用static何時用宏定義。讓你聲明的常量只在你聲明的文件裏有做用要不編譯器會保存ios

宏定義：c++

1）. 通常來講咱們使用宏定義最多見的是定義一些常量簡單的」函數」（好比求兩個數的最大小值）例如：定義常量PI程序員

#define PI 3.1415926
複製代碼

定義函數web

#define MIN(A,B) ((A) < (B) ? (A):(B))
複製代碼

咱們不對宏定義進行修改面試

. 使用宏定義能夠在很大程度上能夠簡化咱們的代碼例如：咱們在寫單例的時候以前咱們寫的是

#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
複製代碼

其實#define的原理就是無論三七二十一，直接作替換，因此咱們徹底能夠利用這個特色，發揮本身的想象，簡化代碼~ 宏定義實質是一個預編譯指令，在程序未運行以前將某些指令付給相應的變量。sql

小結一下： static標記的變量會存儲到全局變量區，生命週期和程序相同。而宏定義所定義的生命週期與所在的載體的生命週期有關.數據庫

static只在聲明的類中可見。在聲明的類中結束後，再次使用仍是以前的值。編程

2.你是怎麼看待代理通知的他們有什麼區別？首先，咱們把代理通知放到一塊兒來討論第一反映是傳值。 ok，下面慢慢來講各個的用法和區別。

通知中心

經過NSNotification能夠給多個對象傳遞數據和消息(多個傳遞) 代理經過protocol（代理模式）只能給一個對象傳遞數據和消息(單一傳遞)「一對一」，對同一個協議，一個對象只能設置一個代理delegate，因此單例對象就不能用代理（能夠用多點回調，下面看法）。

代理更注重過程信息的傳輸：好比發起一個網絡請求，可能想要知道此時請求是否已經開始、是否收到了數據、數據是否已經接受完成、數據接收失敗。

區別：代理和通知的區別應該主要是一對一和一對多的關係。delegate的多點回調相對notification更加便捷，更多方便，讓項目更好維護。

3.說說你對內存管理的理解。

內存管理原則

引用計數的增長和減小相等，當引用計數降爲0以後，不該該再使用這塊內存空間。凡是用alloc retain 或者copy讓內存的引用計數增長了。就須要使用release或者autorelease讓內存的引用計數減小。在一段代碼內。增長和減小的次數要相等。

autoreleasepool的使用

經過autoreleasepool控制autorelease對象的釋放向一個對象發送autorelease消息。這個對象什麼時候釋放取決於autoreleasepool

copy方法跟retain不一樣，一個對象想要copy，生成本身的副本，須要實現NSCopying協議，定義copy的細節（如何copy）若是類沒有接受NSCoping協議而給類發送copy消息，會引發crash 總結： OC藉助引用計數機制去管理內存，凡是使用了alloc copy retain 等方法，增長了引用計數，就要使用release 和autorelease 減小引用計數，引用計數爲0的時候，對象所佔的內存，被系統回收。

autorelease是將來某個時間（出autorelease）引用減一，不是即時的。

不是任何對象均可以接受copy消息。只有接受了NSCoping協議的對象才接受copy消息。

4.談談你對iOS性能優化的理解.

談起iOS的性能優化咱們首先想到的是應該是tableview表視圖的優化。關於表視圖的優化咱們能夠從如下幾個方面來看:

1).tableviewcell渲染繪製時要儘量的避免分配資源，好比UIFont，NSDateFormatter或者任何在繪製時須要的對象，推薦使用類層級的初始化方法中執行分配，並將其存儲爲靜態變量。

2）.圖層渲染的問題透明圖層對渲染性能會有必定的影響，系統必須將透明圖層與下面的視圖混合起來計算顏色，並繪製出來。減小透明圖層並使用不透明的圖層來替代它們，能夠極大地提升渲染速度。

3）.爲代理方法瘦身咱們要儘可能避免在tableview的cellforrowatindexpath的代理方法裏寫那麼多代碼，這樣作不只能夠簡化代碼方便維護和管理，這對程序的運行也有幫助。

4).複雜視圖儘可能採用純代碼的方式

當 UITableViewCell擁有多個子視圖時，IOS的渲染機制會拖慢速度。重寫drawRect直接繪製內容的方式可以提升性能，而不是在類初始化的時候初始化一些label或者imageview等。

（如下來源於yykit做者ibireme這是源連接）

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

對象的建立會分配內存、調整屬性、甚至還有讀取文件等操做，比較消耗 CPU 資源。儘可能用輕量的對象代替重量的對象，能夠對性能有所優化。好比 CALayer 比 UIView 要輕量許多，那麼不須要響應觸摸事件的控件，用 CALayer 顯示會更加合適。若是對象不涉及 UI 操做，則儘可能放到後臺線程去建立，但惋惜的是包含有 CALayer 的控件，都只能在主線程建立和操做。經過 Storyboard 建立視圖對象時，其資源消耗會比直接經過代碼建立對象要大很是多，在性能敏感的界面裏，Storyboard 並非一個好的技術選擇。

1).對象的建立儘可能推遲對象建立的時間，並把對象的建立分散到多個任務中去。儘管這實現起來比較麻煩，而且帶來的優點並很少，但若是有能力作，仍是要儘可能嘗試一下。若是對象能夠複用，而且複用的代價比釋放、建立新對象要小，那麼這類對象應當儘可能放到一個緩存池裏複用。

2).對象調整對象的調整也常常是消耗 CPU 資源的地方。這裏特別說一下 CALayer：CALayer 內部並無屬性，當調用屬性方法時，它內部是經過運行時 resolveInstanceMethod 爲對象臨時添加一個方法，並把對應屬性值保存到內部的一個 Dictionary 裏，同時還會通知 delegate、建立動畫等等，很是消耗資源。UIView 的關於顯示相關的屬性（好比 frame/bounds/transform）等實際上都是 CALayer 屬性映射來的，因此對 UIView 的這些屬性進行調整時，消耗的資源要遠大於通常的屬性。對此你在應用中，應該儘可能減小沒必要要的屬性修改。當視圖層次調整時，UIView、CALayer 之間會出現不少方法調用與通知，因此在優化性能時，應該儘可能避免調整視圖層次、添加和移除視圖。 3). 對象銷燬對象的銷燬雖然消耗資源很少，但累積起來也是不容忽視的。一般當容器類持有大量對象時，其銷燬時的資源消耗就很是明顯。一樣的，若是對象能夠放到後臺線程去釋放，那就挪到後臺線程去。這裏有個小 Tip：把對象捕獲到 block 中，而後扔到後臺隊列去隨便發送個消息以免編譯器警告，就可讓對象在後臺線程銷燬了。例如：

NSArray *tmp = self.array;
self.array = nil;
dispatch_async(queue, ^{
    [tmp class];
});
複製代碼

4).一些計算

視圖佈局的計算是 App 中最爲常見的消耗 CPU 資源的地方。若是能在後臺線程提早計算好視圖佈局、而且對視圖佈局進行緩存，那麼這個地方基本就不會產生性能問題了。不論經過何種技術對視圖進行佈局，其最終都會落到對 UIView.frame/bounds/center 等屬性的調整上。上面也說過，對這些屬性的調整很是消耗資源，因此儘可能提早計算好佈局，在須要時一次性調整好對應屬性，而不要屢次、頻繁的計算和調整這些屬性。 Autolayout 是蘋果自己提倡的技術，在大部分狀況下也能很好的提高開發效率，可是 Autolayout 對於複雜視圖來講經常會產生嚴重的性能問題。隨着視圖數量的增加，Autolayout 帶來的 CPU 消耗會呈指數級上升。具體數據能夠看這個文章：http://pilky.me/36/。若是你不想手動調整 frame 等屬性，你能夠用一些工具方法替代（好比常見的 left/right/top/bottom/width/height 快捷屬性），或者使用 ComponentKit、AsyncDisplayKit 等框架.

若是一個界面中包含大量文本（好比微博微信朋友圈等），文本的寬高計算會佔用很大一部分資源，而且不可避免。若是你對文本顯示沒有特殊要求，能夠參考下 UILabel 內部的實現方式：用 [NSAttributedString boundingRectWithSize:options:context:] 來計算文本寬高，用 -[NSAttributedString drawWithRect:options:context:] 來繪製文本。儘管這兩個方法性能不錯，但仍舊須要放到後臺線程進行以免阻塞主線程。

5).文本的繪製

若是你用 CoreText 繪製文本，那就能夠先生成 CoreText 排版對象，而後本身計算了，而且 CoreText 對象還能保留以供稍後繪製使用。屏幕上能看到的全部文本內容控件，包括 UIWebView，在底層都是經過 CoreText 排版、繪製爲 Bitmap 顯示的。常見的文本控件（UILabel、UITextView 等），其排版和繪製都是在主線程進行的，當顯示大量文本時，CPU 的壓力會很是大。對此解決方案只有一個，那就是自定義文本控件，用 TextKit 或最底層的 CoreText 對文本異步繪製。儘管這實現起來很是麻煩，但其帶來的優點也很是大，CoreText 對象建立好後，能直接獲取文本的寬高等信息，避免了屢次計算（調整 UILabel 大小時算一遍、UILabel 繪製時內部再算一遍）；CoreText 對象佔用內存較少，能夠緩存下來以備稍後屢次渲染.

6).圖片的解碼

當你用 UIImage 或 CGImageSource 的那幾個方法建立圖片時，圖片數據並不會馬上解碼。圖片設置到 UIImageView 或者 CALayer.contents 中去，而且 CALayer 被提交到 GPU 前，CGImage 中的數據纔會獲得解碼。這一步是發生在主線程的，而且不可避免。若是想要繞開這個機制，常見的作法是在後臺線程先把圖片繪製到 CGBitmapContext 中，而後從 Bitmap 直接建立圖片。目前常見的網絡圖片庫都自帶這個功能。

7).圖像的繪製

圖像的繪製一般是指用那些以 CG 開頭的方法把圖像繪製到畫布中，而後從畫布建立圖片並顯示這樣一個過程。這個最多見的地方就是 [UIView drawRect:] 裏面了。因爲 CoreGraphic 方法一般都是線程安全的，因此圖像的繪製能夠很容易的放到後臺線程進行。一個簡單異步繪製的過程大體以下（實際狀況會比這個複雜得多，但原理基本一致）

dispatch_async(backgroundQueue, ^{
        CGContextRef ctx = CGBitmapContextCreate(...);
        // draw in context...
        CGImageRef img = CGBitmapContextCreateImage(ctx);
        CFRelease(ctx);
        dispatch_async(mainQueue, ^{
            layer.contents = img;
        });
    });
    
複製代碼

GPU 資源消耗緣由和解決方案

1.紋理的渲染

全部的 Bitmap，包括圖片、文本、柵格化的內容，最終都要由內存提交到顯存，綁定爲 GPU Texture。不管是提交到顯存的過程，仍是 GPU 調整和渲染 Texture 的過程，都要消耗很多 GPU 資源。當在較短期顯示大量圖片時（好比 TableView 存在很是多的圖片而且快速滑動時），CPU 佔用率很低，GPU 佔用很是高，界面仍然會掉幀。避免這種狀況的方法只能是儘可能減小在短期內大量圖片的顯示，儘量將多張圖片合成爲一張進行顯示。當圖片過大，超過 GPU 的最大紋理尺寸時，圖片須要先由 CPU 進行預處理，這對 CPU 和 GPU 都會帶來額外的資源消耗。目前來講，iPhone 4S 以上機型，紋理尺寸上限都是 4096x4096，更詳細的資料能夠看這裏：iosres.com。因此，儘可能不要讓圖片和視圖的大小超過這個值。

2.視圖的混合當多個視圖（或者說 CALayer）重疊在一塊兒顯示時，GPU 會首先把他們混合到一塊兒。若是視圖結構過於複雜，混合的過程也會消耗不少 GPU 資源。爲了減輕這種狀況的 GPU 消耗，應用應當儘可能減小視圖數量和層次，並在不透明的視圖裏標明 opaque 屬性以免無用的 Alpha 通道合成。固然，這也能夠用上面的方法，把多個視圖預先渲染爲一張圖片來顯示

3.圖像的生成

CALayer 的 border、圓角、陰影、遮罩（mask），CASharpLayer 的矢量圖形顯示，一般會觸發離屏渲染（offscreen rendering），而離屏渲染一般發生在 GPU 中。當一個列表視圖中出現大量圓角的 CALayer，而且快速滑動時，能夠觀察到 GPU 資源已經佔滿，而 CPU 資源消耗不多。這時界面仍然能正常滑動，但平均幀數會降到很低。爲了不這種狀況，能夠嘗試開啓 CALayer.shouldRasterize 屬性，但這會把本來離屏渲染的操做轉嫁到 CPU 上去。對於只須要圓角的某些場合，也能夠用一張已經繪製好的圓角圖片覆蓋到本來視圖上面來模擬相同的視覺效果。最完全的解決辦法，就是把須要顯示的圖形在後臺線程繪製爲圖片，避免使用圓角、陰影、遮罩等屬性。

如何檢測應用的流暢度？
複製代碼

「過早的優化是萬惡之源」，在需求未定，性能問題不明顯時，不必嘗試作優化，而要儘可能正確的實現功能。作性能優化時，也最好是走修改代碼 -> Profile -> 修改代碼這樣一個流程，優先解決最值得優化的地方。若是你須要一個明確的 FPS 指示器，能夠嘗試一下 KMCGeigerCounter。對於 CPU 的卡頓，它能夠經過內置的 CADisplayLink 檢測出來；對於 GPU 帶來的卡頓，它用了一個 1x1 的 SKView 來進行監視。這個項目有兩個小問題：SKView 雖然能監視到 GPU 的卡頓，但引入 SKView 自己就會對 CPU/GPU 帶來額外的一點的資源消耗；這個項目在 iOS 9 下有一些兼容問題，須要稍做調整。

5.你用過單元測試嗎?怎麼才能作好單元測試？

什麼是單元測試？

單元測試：如下內容來自維基百科單元測試

在計算機編程中，單元測試（英語：Unit Testing）又稱爲模塊測試, 是針對程序模塊（軟件設計的最小單位）來進行正確性檢驗的測試工做。程序單元是應用的最小可測試部件。在過程化編程中，一個單元就是單個程序、函數、過程等；對於面向對象編程，最小單元就是方法，包括基類（超類）、抽象類、或者派生類（子類）中的方法。

一般來講，程序員每修改一次程序就會進行最少一次單元測試，在編寫程序的過程當中先後極可能要進行屢次單元測試，以證明程序達到軟件規格書要求的工做目標，沒有程序錯誤；雖然單元測試不是什麼必須的，但也不壞，這牽涉到項目管理的政策決定。

每一個理想的測試案例獨立於其它案例；爲測試時隔離模塊，常用stubs、mock[1]或fake等測試馬甲程序。單元測試一般由軟件開發人員編寫，用於確保他們所寫的代碼符合軟件需求和遵循開發目標。它的實施方式能夠是很是手動的（經過紙筆），或者是作成構建自動化的一部分。
複製代碼

單元測試有什麼好處？

單元測試的一個好處就是咱們能夠只測試單個模塊，咱們能夠測試單一模塊有沒有問題。好比說咱們在開發中常常會寫一些測試性的demo。咱們寫的測試性demo運行正常達到了咱們須要的效果，那麼咱們就能夠把demo的效果運用到咱們的工程中進行調試。

適應變動

單元測試容許程序員在將來重構代碼，而且確保模塊依然工做正確（複合測試）。這個過程就是爲全部函數和方法編寫單元測試，一旦變動致使錯誤發生，藉助於單元測試能夠快速定位並修復錯誤。

可讀性強的單元測試可使程序員方便地檢查代碼片段是否依然正常工做。良好設計的單元測試案例覆蓋程序單元分支和循環條件的全部路徑。

在連續的單元測試環境，經過其固有的持續維護工做，單元測試能夠延續用於準確反映當任何變動發生時可執行程序和代碼的表現。藉助於上述開發實踐和單元測試的覆蓋，能夠分分秒秒維持準確性。

簡化集成

單元測試消除程序單元的不可靠，採用自底向上的測試路徑。經過先測試程序部件再測試部件組裝，使集成測試變得更加簡單。

業界對於人工集成測試的必要性存在較大爭議。儘管精心設計的單元測試體系看上去實現了集成測試，由於集成測試須要人爲評估一些人爲因素才能證明的方面，單元測試替代集成測試不可信。一些人認爲在足夠的自動化測試系統的條件下，人力集成測試組再也不是必需的。事實上，真實的需求最終取決於開發產品的特色和使用目標。另外，人工或手動測試很大程度上依賴於組織的可用資源。[來源請求]

文檔記錄

單元測試提供了系統的一種文檔記錄。藉助於查看單元測試提供的功能和單元測試中如何使用程序單元，開發人員能夠直觀的理解程序單元的基礎API。

單元測試具體表現了程序單元成功的關鍵特色。這些特色能夠指出正確使用和非正確使用程序單元，也能指出須要捕獲的程序單元的負面表現（譯註：異常和錯誤）。儘管不少軟件開發環境不只依賴於代碼作爲產品文檔，在單元測試中和單元測試自己確實文檔化了程序單元的上述關鍵特色。

另外一方面，傳統文檔易受程序自己實現的影響，而且時效性難以保證（如設計變動、功能擴展等在不太嚴格時常常不能保持文檔同步更新）。

表達設計

在測試驅動開發的軟件實踐中，單元測試能夠取代正式的設計。每個單元測試案例都可以視爲一項類、方法和待觀察行爲等設計元素。下面的Java例能夠幫助說明這一點。固然，單元測試缺少圖的可讀性，但UML圖能夠在自由工具（一般可從IDE擴展獲取）中爲大多數現代程序語言生成UML圖，很難要求採購昂貴的UML設計套裝軟件。自由工具，相似於基於xUnit框架的工具，測試結果輸出到一些可生成供人工識讀的圖形化工具系統中去。
分離接口和實現

由於不少類會引用其它類，對這個類的測試常常會要求測試其它的類。一個最廣泛的例子是依賴於數據庫的類：爲了測試它，測試人員一般編寫代碼去操做數據庫。這是不對的，由於單元測試不該超出待測試的類邊界。

做爲替代，軟件開發人員應建立一個數據庫鏈接的抽象接口，而後實現這個接口的模擬對象。經過對代碼所需附件的抽象（臨時下降了網狀的耦合效應），這些獨立程序單元較前者更能被完整測試。高質量的代碼單元也可提供更好的可維護性。
複製代碼

侷限

測試不可能發現全部的程序錯誤，單元測試也不例外。按定義，單元測試只測試程序單元自身的功能。所以，它不能發現集成錯誤、性能問題、或者其餘系統級別的問題。單元測試結合其餘軟件測試活動更爲有效。與其它形式的軟件測試相似，單元測試只能代表測到的問題，不能代表不存在未測試到的錯誤。

軟件測試是一個組合問題。例如，每個布爾型的決斷語句須要至少兩種測試：一個返回真，一個返回假。所以，針對每行書寫的代碼，程序員一般須要寫3至5行的測試代碼。[3]這很明顯地很花時間並且對此的投入可能並不值得。也有些問題是根本不能簡單地檢測出來的——例如具不肯定性的或牽扯到多線程的問題。此外，替單元測試寫的代碼可能就像要測試的代碼同樣有程序錯誤。佛瑞德·布魯克斯在人月神話一書中舉例說明：「絕對不要帶兩個計時器去海邊。最好老是帶一或三個」。意味着，若是兩個計時器互相沖突的話，你該怎麼知道哪一個是對的？爲了得到單元測試的好處，在軟件開發過程當中應造成一套嚴格紀律意識。仔細保留記錄是必要的，不只僅只保留執行的測試，也包括保留對應的源碼和其它軟件單元的變動歷史。即，使用版本控制系統是必要的。若是後續版本不能經過一個之前測試經過的單元測試，版本控制系統能夠提供對應時間段對源代碼所作的變動清單。

天天養成查看單元測試案例失敗測試並及時肯定錯誤緣由的習慣是必要的。若是沒有這樣的流程，沒有在團隊工做流程中體現，單元測試系列將走向不一樣步，形成愈來愈多的錯誤和愈來愈低效的單元測試案例系列。
複製代碼

iOS中的單元測試

在開發中，常常用到的單元測試一是測試某個模塊的功能，也就是說把這個模塊獨立起來，單獨進行測試。用到最多的應該是測試模塊功能和接口調試功能。固然單元測試還有一些高級的用法自動測試和自動發佈等。

OCUnit（即用XCTest進行測試）其實就是蘋果自帶的測試框架，咱們主要講的就是這個。GHUnit是一個可視化的測試框架。（有了它，你能夠點擊APP來決定測試哪一個方法，而且能夠點擊查看測試結果等。）OCMock就是模擬某個方法或者屬性的返回值，你可能會疑惑爲何要這樣作?使用用模型生成的模型對象，再傳進去不就能夠了？答案是能夠的，可是有特殊的狀況。好比你測試的是方法A，方法A裏面調用到了方法B，並且方法B是有參數傳入，但又不是方法A所提供。這時候，你可使用OCMock來模擬方法B返回的值。（在不影響測試的狀況下，就能夠這樣去模擬。）除了這些，在沒有網絡的狀況下，也能夠經過OCMock模擬返回的數據。UITests就是經過代碼化來實現自動點擊界面，輸入文字等功能。靠人工操做的方式來覆蓋全部測試用例是很是困難的，尤爲是加入新功能之後，舊的功能也要從新測試一遍，這致使了測試須要花很是多的時間來進行迴歸測試，這裏產生了大量重複的工做，而這些重複的工做有些是能夠自動完成的，這時候UITests就能夠幫助解決這個問題了。

6. 你知道的的本地數據持久化都有哪些。你比較喜歡用哪些爲何？

採用的數據存儲的方式有如下幾種：

一、 FMDB（經常使用）二、 Sqlite(次之) 三、 Coredata(次之) 四、 NSUserdefaults(最多使用) 五、序列化反序列化（歸檔和解檔）六、 MongoDB(小衆型的)

你們討論用的最多的是FMDB，緣由很簡單，關係型數據庫，使用方便(相對於沒通過封裝和加工的Sqlite來講)。其次就是sqlite和coredata 固然使用者三種主要是爲了緩存。由於咱們在開發中爲了給用戶更好的體驗，就採用緩存的形式。通常狀況下要作的操做就是在本地創建一個數據庫(本地後臺)。

7.談談MVC設計模式的優缺點

編程以來就一直被灌輸MVC設計模式，具體MVC使用到底好在哪裏又有那些不足之處，能夠經過下面的介紹得以瞭解。

1、mvc原理

mvc是一種程序開發設計模式,它實現了顯示模塊與功能模塊的分離。提升了程序的可維護性、可移植性、可擴展性與可重用性，下降了程序的開發難度。它主要分模型、視圖、控制器三層。

模型(model)它是應用程序的主體部分，主要包括業務邏輯模塊（web項目中的Action,dao類）和數據模塊（pojo類）。模型與數據格式無關，這樣一個模型能爲多個視圖提供數據。因爲應用於模型的代碼只需寫一次就能夠被多個視圖重用，因此減小了代碼的重複性
視圖(view) 用戶與之交互的界面、在web中視圖通常由jsp,html組成
控制器(controller)接收來自界面的請求並交給模型進行處理在這個過程當中控制器不作任何處理只是起到了一個鏈接的作用.

2、MVC的優勢

能夠爲一個模型在運行時同時創建和使用多個視圖。變化-傳播機制能夠確保全部相關的視圖及時獲得模型數據變化，從而使全部關聯的視圖和控制器作到行爲同步。
視圖與控制器的可接插性，容許更換視圖和控制器對象，並且能夠根據需求動態的打開或關閉、甚至在運行期間進行對象替換。
模型的可移植性。由於模型是獨立於視圖的，因此能夠把一個模型獨立地移植到新的平臺工做。須要作的只是在新平臺上對視圖和控制器進行新的修改。
潛在的框架結構。能夠基於此模型創建應用程序框架，不只僅是用在設計界面的設計中。

3、MVC的不足之處

增長了系統結構和實現的複雜性。對於簡單的界面，嚴格遵循MVC，使模型、視圖與控制器分離，會增長結構的複雜性，並可能產生過多的更新操做，下降運行效率。
視圖與控制器間的過於緊密的鏈接。視圖與控制器是相互分離，但確實聯繫緊密的部件，視圖沒有控制器的存在，其應用是頗有限的，反之亦然，這樣就妨礙了他們的獨立重用。
視圖對模型數據的低效率訪問。依據模型操做接口的不一樣，視圖可能須要屢次調用才能得到足夠的顯示數據。對未變化數據的沒必要要的頻繁訪問，也將損害操做性能。
目前，通常高級的界面工具或構造器不支持模式。改造這些工具以適應MVC須要和創建分離的部件的代價是很高的，從而形成MVC使用的困難。

8.談談你對多線程的理解，你常常用的多線程有哪些實現方式，談談他們優缺點。

使用NSOperationQueue用來管理子類化的NSOperation對象，控制其線程併發數目。GCD和NSOperation均可以實現對線程的管理，區別是 NSOperation和NSOperationQueue是多線程的面向對象抽象。項目中使用NSOperation的優勢是NSOperation是對線程的高度抽象，在項目中使用它，會使項目的程序結構更好，子類化NSOperation的設計思路，是具備面向對象的優勢（複用、封裝），使得實現是多線程支持，而接口簡單，建議在複雜項目中使用。

項目中使用GCD的優勢是GCD自己很是簡單、易用，對於不復雜的多線程操做，會節省代碼量，而Block參數的使用，會是代碼更爲易讀，建議在簡單項目中使用。

何時用多線程？

大多狀況下,要用到多線程的主要是須要處理大量的IO操做時或處理的狀況須要花大量的時間等等,好比:讀寫文件、視頻圖像的採集、處理、顯示、保存等。

多線程的做用?

能夠解決負載均衡問題,充分利用cpu資源。爲了提升CPU的使用率,採用多線程的方式去同時完成幾件事情而互不干擾.

iOS實現多線程有哪幾種方式？

主要有三種主要方法。

一、NSThread。

二、NSOperation。

三、GCD。

多線程安全問題的幾種解決方案?

使用鎖。鎖是線程編程同步工具的基礎。鎖可讓你很容易保護代碼中一大塊區域以便你能夠確保代碼的正確性。使用POSIX互斥鎖;使用NSLock類;使用@synchronized指令等。

分線程回調主線程方法是什麼？有什麼做用呢？

回到主線程的方法:

(1). performSelectorOnMainThrea

[self performSelectorOnMainThread:<#(SEL)#>withObject:<#(id)#>waitUntilDone:<#(BOOL)#>];
複製代碼

(2). GCD

dispatch_async(dispatch_get_main_queue(), ^{ 
});
複製代碼

(3). NSOperationQueue

[[NSOperationQueue mainQueue]addOperationWithBlock:^{
}]
複製代碼

做用:主線程是顯示UI界面,子線程多數是進行數據處理.

PS:最高境界是異步單線程，江湖上稱協程。能夠參考 boost 中的 asio 用戶級的任務調度

9.談談你對面向對象和麪向過程的認識。

簡單對比

面向過程就像是一個細心的管家，事無具細的都要考慮到。而面向對象就像是個家用電器，你只須要知道他的功能，不須要知道它的工做原理。「面向過程」是一種是事件爲中心的編程思想。就是分析出解決問題所需的步驟，而後用函數把這寫步驟實現，並按順序調用。面向對象是以「對象」爲中心的編程思想。

簡單的舉個例子：汽車發動、汽車到站

這對於「面向過程」來講，是兩個事件，汽車啓動是一個事件，汽車到站是另外一個事件，面向過程編程的過程當中咱們關心的是事件，而不是汽車自己。針對上述兩個事件，造成兩個函數，以後依次調用。然而這對於面向對象來講，咱們關心的是汽車這類對象，兩個事件只是這類對象所具備的行爲。並且對於這兩個行爲的順序沒有強制要求。

兩種思想的對比

面向過程其實最爲實際的一種思考方式，由於咱們老是一向一步一步的解決問題。(舉個簡單的事情，在初學面向對象的語言例如c++時，咱們也老是不經意的面向過程了!)。其實就算是面向對象思想也是包含有面向過程思想的，面向過程需造成事件、也就是函數，面向對象需抽象出類，而且也會定義出這類對象的「行爲」及方法。可是不管是面向過程的函數，仍是面向對象的方法，二者所完成目的都是一致的。能夠說面向過程是一種基礎的方法，它考慮的是實際的實現，通常狀況下，面向過程是自頂向下逐步求精，其最重要的是模塊化的思想方法。面向對象的方法主要是把事物給對象化，包括其屬性和行爲。這裏在程序較小的時候，面向過程就會體現出一種優點，其程序流程十分清楚。如同上述汽車發動、到站這一過程，面向過程能夠很清晰的將這一過程體現出來。而面向對像僅僅是抽象出一個Bus類，包括髮動、到站之兩個行爲，具體的執行順序不能體現出來。

面向過程和麪向對象的本質理解

面向過程就是分析出解決問題所需的步驟，面向對象則是把構成問題的事物分解成對象，抽象出對象的目的並不在於完成某個步驟，而是描述其再整個解決問題的步驟中的行爲。面向過程的思惟方式是分析綜合，面向對象的思惟方式是構造。例如c語言解決問題時，通常是先定義數據結構，而後在構造算法。而是面向對象求解時則是先抽象出對象，構造一個「封閉」的環境，這個環境中有定義的數據和解決問題的算法。面向過程的設計更具挑戰性，技巧性，面向對象主要在於對象抽象的技術性，一旦完成抽象，任何人均可以作後面的工做了。從代碼層結構上來講的話，面向對象和麪向過程的主要區別就是數據是單獨存數仍是與操做存儲在一塊兒。面向對象提供了數據的封裝後，是的對某一操做而言，數據的訪問變得可靠了。

面向過程就是將coding當作一件事，一步一步完成，面向對象就是將coding當作一件事物，須要作什麼的時候由事物(對象)自己的行爲去完成。

總的來講：