最新整理：iOS面試題-面試常問問題（二）

前言:

最近把 iOS 面試中可能會遇到的問題整理了一番, 題目大部分是網(wǎng)上收錄的, 方便自己鞏固復(fù)習(xí), 也分享給大家； 希望對大家有所幫助！

  • 對于答案，不一定都合適，歡迎大家積極討論；整理不易，如果您覺得還不錯，麻煩在文末 “點(diǎn)個贊” ，或者留下您的評論“Mark” 一下，謝謝您的支持

目錄合集

iOS面試題-面試常問問題（二）

1.C和 OC 如何混編

xcode可以識別一下幾種擴(kuò)展名文件:

  • .m文件,可以編寫 OC語言 和 C 語言代碼
  • .cpp: 只能識別C++ 或者C語言(C++兼容C)
  • .mm: 主要用于混編 C++和OC代碼,可以同時識別OC,C,C++代碼

2. Swift 和OC 如何調(diào)用?

  • Swift 調(diào)用 OC代碼
    需要創(chuàng)建一個 Target-BriBridging-Header.h 的橋文件,在喬文件導(dǎo)入需要調(diào)用的OC代碼頭文件即可

  • OC 調(diào)用 Swift代碼
    直接導(dǎo)入 Target-Swift.h文件即可, Swift如果需要被OC調(diào)用,需要使用@objc 對方法或者屬性進(jìn)行修飾

3. Foundation 對象與 CoreFoundation 對象 有什么區(qū)別?

  • Foundation對象是OC的,在MRC下需要手動管理內(nèi)存,ARC下不需要手動管理
  • Core Foundation對象是C對象, MRC和ARC都需要手動管理內(nèi)存
  • 數(shù)據(jù)類型之間的轉(zhuǎn)換
    • ARC:__bridge_retained, __bridge_transfer(自動內(nèi)存管理)
    • 非ARC: __bridge

4.與OC比較.Swift有什么優(yōu)點(diǎn)?

Swift 是一門新型語言,借鑒了JS,Python,C#,Ruby等語言特性,看上去偏腳本化,Swift 仍支持 cocoa touch 框架

優(yōu)點(diǎn):

  1. Swift更加安全，它是類型安全的語言。
  2. Swift容易閱讀，語法和文件結(jié)構(gòu)簡易化。
  3. Swift更易于維護(hù)，文件分離后結(jié)構(gòu)更清晰。
  4. Swift代碼更少，簡潔的語法，可以省去大量冗余代碼
  5. Swift速度更快，運(yùn)算性能更高。

精選全網(wǎng) · iOS面試題答案PDF文集

  • 獲取加小編的iOS技術(shù)交流圈：937 194 184，直接獲取

5. delegate(代理,委托)

委托是協(xié)議的一種,顧名思義，就是委托他人幫自己去做什么事。

delegate:

  1. 非常嚴(yán)格的語法。所有將聽到的事件必須是在delegate協(xié)議中有清晰的定義,語法清晰,易讀;
  2. 如果delegate中的一個方法沒有實(shí)現(xiàn)那么就會出現(xiàn)編譯警告/錯誤
  3. 在釋放代理對象時，需要小心的將delegate改為nil。一旦設(shè)定失敗，那么調(diào)用釋放對象的方法將會出現(xiàn)內(nèi)存crash

6.Notification(通知)

在IOS應(yīng)用開發(fā)中有一個”Notification Center“的概念。它是一個單例對象，允許當(dāng)事件發(fā)生時通知一些對象。

notification:

  1. 對于一個發(fā)出的通知，多個對象能夠做出反應(yīng)，即1對多的方式實(shí)現(xiàn)簡單
  2. controller能夠傳遞context對象（dictionary），context對象攜帶了關(guān)于發(fā)送通知的自定義的信息
  3. 在調(diào)試的時候應(yīng)用的工作以及控制過程難跟蹤；

7.KVO

KVO是一個對象能夠觀察另外一個對象的屬性的值，并且能夠發(fā)現(xiàn)值的變化。

KVO：

  1. 能夠提供一種簡單的方法實(shí)現(xiàn)兩個對象間的同步。例如：model和view之間同步；
  2. 能夠?qū)Ψ俏覀儎?chuàng)建的對象，即內(nèi)部對象的狀態(tài)改變作出響應(yīng)，而且不需要改變內(nèi)部對象（SKD對象）的實(shí)現(xiàn)；

8. 如何選擇delegate、notification、KVO？

三種模式都是一個對象傳遞事件給另外一個對象，并且不要他們有耦合。

  1. delegate. 一對一
  2. notification 一對多,多對多
  3. KVO 一對一

三者各有自己的特點(diǎn):

  • delegate 語法簡潔,方便閱讀,易于調(diào)試
  • notification 靈活多變,可以跨越多個類之間進(jìn)行使用
  • KVO 實(shí)現(xiàn)屬性監(jiān)聽,實(shí)現(xiàn)model和view同步
  • 可以根據(jù)實(shí)際開發(fā)遇到的場景來使用不同的方式

9. 若你去設(shè)計(jì)一個通知中心，你會怎樣設(shè)計(jì)？

個人理解: 參考現(xiàn)有的通知中心

  1. 創(chuàng)建通知中心單例類,并在里面有個一個保存通知的全局NSDiction
  2. 對于注冊通知的類,將其注冊通知名作為key, 執(zhí)行的方法和類,以及一些參數(shù)做為一個數(shù)組為值
  3. 發(fā)送通知可以調(diào)用通知中心,通過字典key(通知名),找到對應(yīng)的 類和方法進(jìn)行執(zhí)行調(diào)用傳值.

10. Notification 和KVO區(qū)別

  • KVO提供一種機(jī)制,當(dāng)指定的被觀察的對像的屬性被修改后,KVO會自動通知響應(yīng)的觀察者,KVC(鍵值編碼)是KVO的基礎(chǔ)
  • 通知:是一種廣播機(jī)制,在實(shí)踐發(fā)生的時候,通過通知中心對象,一個對象能夠?yàn)樗嘘P(guān)心這個時間發(fā)生的對象發(fā)送消息,兩者都是觀察者模式,不同在于KVO是被觀察者直接發(fā)送消息給觀察者,是對象間的直接交互,通知則是兩者都和通知中心對象交互,對象之間不知道彼此
  • 本質(zhì)區(qū)別,底層原理不一樣.kvo 基于 runtime, 通知則是有個通知中心來進(jìn)行通知

11.結(jié)構(gòu)體與數(shù)組有什么區(qū)別?

  1. 結(jié)構(gòu)體可以存不同類型的元素,而數(shù)組只能存同一類型
  2. 結(jié)構(gòu)體類型需要我們自已定義.數(shù)組是用別的類型加[元素個數(shù)]
  3. 結(jié)構(gòu)體內(nèi)存分配方式很特別,使用對齊原則,不一定是所有元素的字節(jié)數(shù)和,而數(shù)組一定是所有元素的字節(jié)數(shù)和.
  4. 結(jié)構(gòu)體指針可以指針名->結(jié)構(gòu)體元素名(取元素);數(shù)組不行.

12. NSDictionary的實(shí)現(xiàn)原理是什么？

  • 哈希表(NSDictionary 是通過hash表來實(shí)現(xiàn)key和value之間的映射和存儲的)

13.說一下靜態(tài)庫和動態(tài)庫之間的區(qū)別

  • 靜態(tài)庫：以.a 和 .framework為文件后綴名。

  • 動態(tài)庫：以.tbd(之前叫.dylib) 和 .framework 為文件后綴名。

  • 靜態(tài)庫：鏈接時會被完整的復(fù)制到可執(zhí)行文件中，被多次使用就有多份拷貝。

  • 動態(tài)庫：鏈接時不復(fù)制，程序運(yùn)行時由系統(tǒng)動態(tài)加載到內(nèi)存，系統(tǒng)只加載一次，多個程序共用（如系統(tǒng)的UIKit.framework等），節(jié)省內(nèi)存。

  • // 靜態(tài)庫.a 和 framework區(qū)別.a 主要是二進(jìn)制文件,不包含資源,需要自己添加頭文件
    .framework 可以包含頭文件+資源信息

14.對于 oc 來講,他的最大優(yōu)缺點(diǎn)是什么? 如何缺點(diǎn)如何繞過這些不足

優(yōu)點(diǎn):

  1. OC是C語言的超集, 在C語言基礎(chǔ)上增加了面向?qū)ο筇匦? 開發(fā)使用起來會方便高效.
  2. 分類可以快速擴(kuò)展類的方法.擴(kuò)展模塊之間相互不影響
  3. 運(yùn)行時特性,動態(tài)特性(動態(tài)類型,動態(tài)綁定,動態(tài)加載),提高了編程的靈活性
  4. OC可以與C / C++進(jìn)行混編

缺點(diǎn):

  1. 不支持多繼承,多繼承可以使用分類,協(xié)議,消息轉(zhuǎn)發(fā)來彌補(bǔ)
  2. 不支持運(yùn)算符重載
  3. 使用動態(tài)運(yùn)行時類型，所有的方法都是函數(shù)調(diào)用，所以很多編譯時優(yōu)化方法都用不到，如內(nèi)聯(lián)函數(shù)等，性能低劣。
  4. 執(zhí)行效率比C低,語法怪異

精選全網(wǎng) · iOS面試題答案PDF文集

  • 獲取加小編的iOS技術(shù)交流圈：937 194 184，直接獲取

15. OC與 JS交互方式有哪些?

  1. 通過攔截URL
  2. 使用MessageHandler(WKWebView)
  3. JavaScriptCore (UIWebView)
  4. 使用三方庫WebViewJavascriptBridge,可提供 js 調(diào)OC,以及OC掉JS

16. 通過JS調(diào)用OC代碼(url攔截)一

  • 通過攔截url（適用于UIWebView和WKWebView）
- (BOOL)webView:(UIWebView *)webView shouldStartLoadWithRequest:(NSURLRequest *)request navigationType:(UIWebViewNavigationType)navigationType {
    NSString *url = request.URL.absoluteString;
    if ([url rangeOfString:@"需要跳轉(zhuǎn)源生界面的URL判斷"].location != NSNotFound) {
        //跳轉(zhuǎn)原生界面
        return NO;
    }
    return YES;
}

17. JS調(diào)用OC代碼(messageHander)二

  • 當(dāng)JS端想傳一些數(shù)據(jù)給iOS.那它們會調(diào)用下方方法來發(fā)送.
  • window.webkit.messageHandlers.<方法名>.postMessage(<數(shù)據(jù)>)上方代碼在JS端寫會報錯,導(dǎo)致網(wǎng)頁后面業(yè)務(wù)不執(zhí)行.可使用try-catch執(zhí)行.
  • 那么在OC中的處理方法如下.它是WKScriptMessageHandler的代理方法.name和上方JS中的方法名相對應(yīng).
- (void)addScriptMessageHandler:(id <WKScriptMessageHandler>)scriptMessageHandler name:(NSString *)name;

18 JS調(diào)用OC代碼(WebViewJavascriptBridge)三

1. 設(shè)置 webViewBridge
_bridge = [WKWebViewJavascriptBridge bridgeForWebView:self.webView];
    [_bridge setWebViewDelegate:self];
2. 注冊handler方法,需要和 前段協(xié)商好 方法名字,是供 JS調(diào)用Native 使用的。
    [_bridge registerHandler:@"scanClick" handler:^(id data, WVJBResponseCallback responseCallback) {
        // OC調(diào)用
        NSString *scanResult = @"http://www.baidu.com";
        // js 回調(diào)傳參
        responseCallback(scanResult);
    }];
3. OC掉用JS
  [_bridge callHandler:@"testJSFunction" data:@"一個字符串" responseCallback:^(id responseData) {
        NSLog(@"調(diào)用完JS后的回調(diào)：%@",responseData);
    }];

19.OC調(diào)用JS代碼

// 直接運(yùn)行 使用 
NSString *jsStr = @"執(zhí)行的JS代碼";
[webView stringByEvaluatingJavaScriptFromString:jsStr];

// 使用JavaScriptCore框架
#import <JavaScriptCore/JavaScriptCore.h>  
- (void)webViewDidFinishLoad:(UIWebView *)webView {
    //獲取webview中的JS內(nèi)容
    JSContext *context = [webView valueForKeyPath:@"documentView.webView.mainFrame.javaScriptContext"];
    NSString *runJS = @"執(zhí)行的JS代碼";
    //準(zhǔn)備執(zhí)行的JS代碼
    [context evaluateScript:runJS];
}

20. 遇到過BAD_ACCESS的錯誤嗎？你是怎樣調(diào)試的？

BAD_ACCESS 報錯屬于內(nèi)存訪問錯誤，會導(dǎo)致程序崩潰，錯誤的原因是訪問了野指針(懸掛指針)。

  1. 設(shè)置全局?jǐn)帱c(diǎn)快速定位問題代碼所在行。
  2. 開啟僵尸對象診斷
  3. Analyze分析
  4. 重寫object的respondsToSelector方法，現(xiàn)實(shí)出現(xiàn)EXEC_BAD_ACCESS前訪問的最后一個object。
  5. Xcode 7 已經(jīng)集成了BAD_ACCESS捕獲功能：Address Sanitizer。 用法如下：在配置中勾選?Enable Address Sanitizer。

21.什么是函數(shù)式編程？鏈?zhǔn)?/h4>

  • 函數(shù)式編程是一種編程模型，他將計(jì)算機(jī)運(yùn)算看做是數(shù)學(xué)中函數(shù)的計(jì)算，并且避免了狀態(tài)以及變量的概念。函數(shù)式編程就像流水線一樣，一順順的把問題解決完，從一個起點(diǎn)開始，一個個的調(diào)用函數(shù)，因?yàn)樯弦粋€函數(shù)有返回值是工具類本身，所以一個函數(shù)執(zhí)行完之后，可以用上一個函數(shù)繼續(xù)調(diào)用，有點(diǎn)鏈?zhǔn)剿季S在里面。

  • Masonry 就是我們最常見的函數(shù)式編程,通過對象.方法1().方法2.....

[view mas_makeConstraints:^(MASConstraintMaker *make){     
make.top.bottom.left.right.equalTo(self.view);
}];

鏈?zhǔn)骄幊?

  • top.bottom.left.right.equalTo(self.view)通過"."語法，將需要執(zhí)行的代碼連續(xù)的書寫，就叫做鏈?zhǔn)骄幊?，它使得代碼簡單易懂。

22. 響應(yīng)式編程?

  • 響應(yīng)式編程是一種面向數(shù)據(jù)流和變化傳播的編程范式。
  • 例如，在命令式編程環(huán)境中，a:=b+c表示將表達(dá)式的結(jié)果賦給a，而之后改變b或c的值不會影響a。但在響應(yīng)式編程中，a的值會隨著b或c的更新而更新。
  • Reactive Cocoa就是一個響應(yīng)式編程的經(jīng)典作品！

23.Block和Protocol的區(qū)別，Block是為了解決什么問題而使用的。

  • “代理和block的共同特性是回調(diào)機(jī)制，不同的是，代理的方法比較多，比較分散,公共接口，方法較多也選擇用delegate進(jìn)行解耦
  • 使用block的代碼比較集中統(tǒng)一,異步和簡單的回調(diào)用block更好”

Block是為了解決什么問題而使用的? 個人認(rèn)為:

  • block為了多線程之間調(diào)度產(chǎn)生的;
  • block 也是一個OC對象,可以當(dāng)參數(shù)傳遞,使用方便簡單,靈活,很少的代碼就可以實(shí)現(xiàn)代碼回調(diào).比協(xié)議省很多代碼

24.說一下ios代碼簽名

  • 確保從app store下載的app是沒被惡意篡改，如果修改則無法安裝, 以及驗(yàn)證app開發(fā)者身份;

25.什么是app thinning(app 瘦身)

App Thinning可以譯成“應(yīng)用瘦身”。指的是App store 和操作系統(tǒng)在安裝iOS或者watchOS的 app 的時候通過一些列的優(yōu)化，盡可能減少安裝包的大小，使得 app 以最小的合適的大小被安裝到你的設(shè)備上。而這個過程包括了三個過程：slicing, bitcode, and on-demand resources。

  1. slicing 可以打包對應(yīng)的 app 資源文件
  2. Bitcode 蘋果會對包含Bitcode的二進(jìn)制app進(jìn)行二次優(yōu)化，而不需要提交一個新的app版本到app store中。
  3. On-Demand Resources 按需加載

26. 如果沒有instruments，該如何檢測memory leak, zombie object 之類的問題。

  • 查看MLeaksFinder源碼分析,國內(nèi)三方

27.字典的工作原理 ？怎100w個中是怎么快速去取value？

  1. NSDictionary（字典）是使用 hash表來實(shí)現(xiàn)key和value之間的映射和存儲的，hash函數(shù)設(shè)計(jì)的好壞影響著數(shù)據(jù)的查找訪問效率。

    • (void)setObject:(id)anObject forKey:(id <NSCopying>)aKey;

  2. Objective-C 中的字典 NSDictionary 底層其實(shí)是一個哈希表，實(shí)際上絕大多數(shù)語言中字典都通過哈希表實(shí)現(xiàn)，

哈希表的本質(zhì)是一個數(shù)組，數(shù)組中每一個元素稱為一個箱子(bin)，箱子中存放的是鍵值對。數(shù)組長度即箱子數(shù)。
哈希表還有一個重要的屬性: 負(fù)載因子(load factor)，它用來衡量哈希表的 空/滿 程度，一定程度上也可以體現(xiàn)查詢的效率，計(jì)算公式為:
負(fù)載因子 = 總鍵值對數(shù) / 箱子個數(shù)
負(fù)載因子越大，意味著哈希表越滿，越容易導(dǎo)致沖突，性能也就越低。因此，一般來說，當(dāng)負(fù)載因子大于某個常數(shù)(可能是 1，或者 0.75 等)時，哈希表將自動擴(kuò)容。
參考: http://www.itdecent.cn/p/88dfc8f405ab

28. isEquel和hash的關(guān)系

  1. isEquel 用于比較2個對象是否相等, 與==(地址比較)不一樣, 可以重寫isEquel方法,來進(jìn)行2個對象的比較
  2. hash 是一個類方法，任何類都可以調(diào)用這個方法，返回的結(jié)果是一個NSInteger值(如果兩個對象相等，那么他們的hash值一定相等，但是，如果兩個對象的哈希值相等是不能一定推出來這兩個對象是相等的)

29.isEquel 和 isEquelToString

  • isEquel 比較的是2個NSObject的方法,
  • isEquelToString是比較2個字符串值是否相等
  • isEquel 首先比較2個對象地址,如果相同就返回YES,如果不同,就比較對象類型,以及屬性的值,一般重寫 isEquel 來比較2個對象

30. iOS 9 以后通知不再需要手動移除

  • 通知 NSNotification 在注冊者被回收時需要手動移除，是一直以來的使用準(zhǔn)則。 原因是在 MRC 時代，通知中心持有的是注冊者的 unsafe_unretained 指針，在注冊者被回收時若不對通知進(jìn)行手動移除，則指針指向被回收的內(nèi)存區(qū)域，變?yōu)橐爸羔槨４藭r發(fā)送通知會造成 crash 。 而在 iOS 9 以后，通知中心持有的是注冊者的 weak 指針，這時即使不對通知進(jìn)行手動移除，指針也會在注冊者被回收后自動置空。因?yàn)橄蚩罩羔槹l(fā)送消息是不會有問題的。

31. 如何對 NSMutableArray 進(jìn)行 KVO

  • 一般情況下只有通過調(diào)用 set 方法對值進(jìn)行改變才會觸發(fā) KVO。但是在調(diào)用NSMutableArray的 addObject或removeObject 系列方法時，并不會觸發(fā)它的 set 方法。所以為了實(shí)現(xiàn)NSMutableArray的 KVO，官方為我們提供了如下方法:
@property (nonatomic, strong) NSMutableArray *arr;

//添加元素操作
[[self mutableArrayValueForKey:@"arr"] addObject:item];
//移除元素操作
[[self mutableArrayValueForKey:@"arr"] removeObjectAtIndex:0];

32. 編譯過程做了哪些事情；

* Objective,Swift都是編譯語言。編譯語言在執(zhí)行的時候，必須先通過編譯器生成機(jī)器碼，機(jī)器碼可以直接在CPU上執(zhí)行，所以執(zhí)行效率較高。Objective,Swift二者的編譯都是依賴于Clang + LLVM. OC和Swift因?yàn)樵砩洗笸‘悾酪粋€即可！
* iOS編譯 不管是OC還是Swift，都是采用Clang作為編譯器前端,LLVM(Low level vritual machine)作為編譯器后端。
* 編譯器前端 :編譯器前端的任務(wù)是進(jìn)行：語法分析，語義分析，生成中間代碼(intermediate representation )。在這個過程中，會進(jìn)行類型檢查，如果發(fā)現(xiàn)錯誤或者警告會標(biāo)注出來在哪一行
* 編譯器后端 :編譯器后端會進(jìn)行機(jī)器無關(guān)的代碼優(yōu)化，生成機(jī)器語言，并且進(jìn)行機(jī)器相關(guān)的代碼優(yōu)化。LVVM優(yōu)化器會進(jìn)行BitCode的生成，鏈接期優(yōu)化等等,LLVM機(jī)器碼生成器會針對不同的架構(gòu)，比如arm64等生成不同的機(jī)器碼。

33. 容錯處理你們一般是注意哪些？

在團(tuán)隊(duì)協(xié)作開發(fā)當(dāng)中，由于每個團(tuán)隊(duì)成員的水平不一，很難控制代碼的質(zhì)量，保證代碼的健壯性，經(jīng)常會發(fā)生由于后臺返回異常數(shù)據(jù)造成app崩潰閃退的情況，為了避免這樣的情況項(xiàng)目中做一些容錯處理，顯得格外重要，極大程度上降低了因?yàn)閿?shù)據(jù)容錯不到位產(chǎn)生崩潰閃退的概率。

例如：
1.字典
2.數(shù)組；
3.野指針；
4.NSNull
等~
// AvoidCrash github 三方不錯

34. 項(xiàng)目開始容錯處理沒做？如何防止攔截潛在的崩潰？

例：
1、category給類添加方法用來替換掉原本存在潛在崩潰的方法。
2、利用runtime方法交換技術(shù)，將系統(tǒng)方法替換成類添加的新方法。
3、利用異常的捕獲來防止程序的崩潰，并且進(jìn)行相應(yīng)的處理。
4、使用 @try__Catch__方法進(jìn)行攔截

總結(jié)：
1、不要過分相信服務(wù)器返回的數(shù)據(jù)會永遠(yuǎn)的正確。
2、在對數(shù)據(jù)處理上，要進(jìn)行容錯處理，進(jìn)行相應(yīng)判斷之后再處理數(shù)據(jù)，這是一個良好的編程習(xí)慣。

35.@try @catch異常機(jī)制

Objective-C 異常機(jī)制 :
-- 作用 : 開發(fā)者將引發(fā)異常的代碼放在 @try 代碼塊中, 程序出現(xiàn)異常 使用 @catch 代碼塊進(jìn)行捕捉;
-- 每個代碼塊作用 : @try 代碼塊存放可能出現(xiàn)異常的代碼, @catch 代碼塊 異常處理邏輯, @finally 代碼塊回收資源;
-- 語法示例 :

try{
   //..執(zhí)行的代碼，其中可能有異常。一旦發(fā)現(xiàn)異常，則立即跳到catch執(zhí)行。否則不會執(zhí)行catch里面的內(nèi)容
}catch(){
  //...除非try里面執(zhí)行代碼發(fā)生了異常，否則這里的代碼不會執(zhí)行
}finally{
  //..不管什么情況都會執(zhí)行，包括try catch 里面用了return ,可以理解為只要執(zhí)行了try或者catch，就一定會執(zhí)行 finally
}
可以用于查找 bug,或者調(diào)試,防止崩潰使用

36.單元測試是什么?

單元測試（unit testing），是指對軟件中的最小可測試單元進(jìn)行檢查和驗(yàn)證。

1. 單元測試可以進(jìn)行 邏輯測試/異步測試/性能測試
2. 單元測試是以代碼測試代碼。不是靠 NSLog 來測試,而是使用斷言來測試的，提前預(yù)判條件必須滿足。XCTAssert(條件, 不滿足條件的描述)
3. 可以在單元測試類中編寫單獨(dú)的測試用例方法。這些方法與普通的方法類似，但是方法名稱必須以 test 開頭，且不能有參數(shù)，不然不會識別為測試方法。
4. 不是所有的方法都需要測試。例如私有方法不需要測試，只有暴露在 .h 中的方法需要測試。
一般而言，代碼的覆蓋度大概在 50% ~ 70%。從 github 上得知：YYModel 測試覆蓋度為 83%，AFNetworking 測試覆蓋度為 77%，兩者都是比較高的。

總結(jié): 單元測試可以根據(jù)項(xiàng)目需要,針對一些關(guān)鍵業(yè)務(wù),編寫一些測試用例,可以方便的排查業(yè)務(wù)邏輯可能出現(xiàn)的問題.在后續(xù)改動時候也可以方便的測試等等.

37. 一個上線的項(xiàng)目，知道這個方法可能會出問題，在不破壞改方法前提下，怎么搞？

  1. 做一些容錯處理,防止崩潰
  2. 加一些日志收集,收集問題再具體分析
  3. try_catch

38.Xcode編譯器發(fā)展簡史

Xcode3 以前：  GCC；
Xcode3：             增加LLVM，GCC(前端) + LLVM(后端)；
Xcode4.2：           出現(xiàn)Clang - LLVM 3.0成為默認(rèn)編譯器；
Xcode4.6：         LLVM 升級到4.2版本；
Xcode5：         GCC被廢棄，新的編譯器是LLVM 5.0，從GCC過渡到Clang-LLVM的時代正式完成

39.代碼從 Git 上拉下來到生成 .ipa 都有哪些過程，期間都生成了什么文件。

  1. git clone 遠(yuǎn)程地址到本地
  2. pod 三方集成
  3. 配置證書信息,簽名
  4. 打包 ipa

精選全網(wǎng) · iOS面試題答案PDF文集

  • 獲取加小編的iOS技術(shù)交流圈：937 194 184，直接獲取

40.Pods的原理

  • 簡單理解：快速的搜索多第三方框架，然后自動集成多工程里面。并編譯成一個libPod.a的靜態(tài)庫給我們的項(xiàng)目用。

41. 函數(shù)指針和 Block區(qū)別

相同點(diǎn):

  • 二者都可以看成是一個代碼片段。
  • 函數(shù)指針類型和 Block 類型都可以作為變量和函數(shù)參數(shù)的類型

不同點(diǎn):

  • 函數(shù)指針只能指向預(yù)先定義好的函數(shù)代碼塊，函數(shù)地址是在編譯鏈接時就已經(jīng)確定好的。從內(nèi)存的角度看，函數(shù)指針只不過是指向代碼區(qū)的一段可執(zhí)行代碼
  • block 本質(zhì)是 OC對象，是 NSObject的子類，是程序運(yùn)行過程中在棧內(nèi)存動態(tài)創(chuàng)建的對象，可以向其發(fā)送copy消息將block對象拷貝到堆內(nèi)存，以延長其生命周期。

42. 符號表

iOS 構(gòu)建時產(chǎn)生的符號表，是內(nèi)存地址、函數(shù)名、文件名和行號的映射表。格式大概是：

<起始地址> <結(jié)束地址> <函數(shù)> [<文件名:行號>]

Crash 時的堆棧信息，全是二進(jìn)制的地址信息。如果利用這些二進(jìn)制的地址信息來定位問題是不可能的，因此我們需要將這些二進(jìn)制的地址信息還原成源代碼種的函數(shù)以及行號，這時候符號表就起作用了。利用符號表將原始的 Crash 的二進(jìn)制堆棧信息還原成包含行號的源代碼文件信息，可以快速定位問題。iOS 中的符號表文件(DSYM) 是在編譯源代碼后，處理完 Asset Catalog 資源和 info.plist 文件后開始生成，生成符號表文件(DSYM)之后，再進(jìn)行后續(xù)的鏈接、打包、簽名、校驗(yàn)等步驟。

43. 應(yīng)用瘦身(Thinning)

App Thinning“應(yīng)用瘦身”,iOS9之后發(fā)布的新特性。它能對App store 和操作系統(tǒng)在安裝iOS app 的時候通過一些列的優(yōu)化，盡可能減少安裝包的大小，使得 app 以最小的合適的大小被安裝到你的設(shè)備上。而這個過程包括了三個過程：
slicing, bitcode, on-demand resources，

* slicing
appStore 會根據(jù)用戶的設(shè)備型號創(chuàng)建相應(yīng)的應(yīng)用變體,這些變體只包含可執(zhí)行的結(jié)構(gòu)和資源必要部分,不需要用戶下載完整的安裝包

* bitcode
bitcode系統(tǒng)會對編譯后的二進(jìn)制文件進(jìn)行二次優(yōu)化, 使用最新的編譯器自動編譯app并且針對特定架構(gòu)進(jìn)行優(yōu)化。不會下載應(yīng)用針對不同架構(gòu)的優(yōu)化，而僅下載與特定設(shè)備相關(guān)的優(yōu)化，使得下載量更小，

* On Demand Resources
按需加載資源是在 app 第一次安裝后可下載的文件。舉例說明，當(dāng)玩家解鎖游戲的特定關(guān)卡后可以下載新關(guān)卡（和這個關(guān)卡相關(guān)的特定內(nèi)容）。此外，玩家已經(jīng)通過的關(guān)卡可以被移除以便節(jié)約設(shè)備上的存儲空間。

44.埋點(diǎn)處理

埋點(diǎn)是什么? 用戶行為統(tǒng)計(jì)，俗稱埋點(diǎn)

埋點(diǎn)分為兩種：

  • 頁面統(tǒng)計(jì)，即在進(jìn)入頁面和離開頁面的時候埋點(diǎn)，統(tǒng)計(jì)停留頁面時長
  • 交互事件統(tǒng)計(jì)

無痕埋點(diǎn)(自動埋點(diǎn))解決方案:
技術(shù)原理：Method-Swizzling

對于一個給定的事件，UIControl會調(diào)用sendAction:to:forEvent:來將行為消息轉(zhuǎn)發(fā)到UIApplication對象，再由UIApplication對象調(diào)用其sendAction:to:fromSender:forEvent:方法來將消息分發(fā)到指定的target上，那么，我們寫一個UIControl的類別，通過替換它的sendAction:to:forEvent:方法，結(jié)合本地配置的埋點(diǎn)json或者plist文件(若埋點(diǎn)需要額外的參數(shù)，需要給UIControl的類別通過Runtime添加屬性)，便可以實(shí)現(xiàn)自動埋點(diǎn)的功能。

參考鏈接:
http://www.itdecent.cn/p/b8a67c4acfb3
http://www.itdecent.cn/p/ae8d45e10ac5

45.說一下iOS 中的APNS,遠(yuǎn)程推送原理?

Apple push Notification Service,簡稱 APNS,是蘋果的遠(yuǎn)程消息推送,原理如下:

  1. iOS 系統(tǒng)向APNS服務(wù)器請求手機(jī)端的deviceToken
  2. App 接收到手機(jī)端的 deviceToken,然后傳給 App 對應(yīng)的服務(wù)器.
  3. App 服務(wù)端需要發(fā)送推送消息時, 需要先通過 APNS 服務(wù)器
  4. 然后根據(jù)對應(yīng)的 deviceToken 發(fā)送給對應(yīng)的手機(jī)

收錄 | 原文地址

結(jié)語

再次說一聲，對于答案，不一定都合適，歡迎大家積極討論；整理不易，如果您覺得還不錯，麻煩在文末 “點(diǎn)個贊” ，或者留下您的評論“Mark” 一下，謝謝您的支持

推薦文集

最后編輯于 ：
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成，瀏覽時請結(jié)合常識與多方信息審慎甄別。
平臺聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點(diǎn)，簡書系信息發(fā)布平臺，僅提供信息存儲服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容