iOS | 面試知識(shí)整理 - OC基礎(chǔ) (二)

1.C和 OC 如何混編

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

.m文件,可以編寫 OC語(yǔ)言 和 C 語(yǔ)言代碼

.cpp: 只能識(shí)別C++ 或者C語(yǔ)言(C++兼容C)

.mm: 主要用于混編 C++和OC代碼,可以同時(shí)識(shí)別OC,C,C++代碼

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

Swift 調(diào)用 OC代碼

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

OC 調(diào)用 Swift代碼

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

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

Foundation對(duì)象是OC的,在MRC下需要手動(dòng)管理內(nèi)存,ARC下不需要手動(dòng)管理

Core Foundation對(duì)象是C對(duì)象, MRC和ARC都需要手動(dòng)管理內(nèi)存

數(shù)據(jù)類型之間的轉(zhuǎn)換

ARC:__bridge_retained, __bridge_transfer(自動(dòng)內(nèi)存管理)

非ARC: __bridge

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

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

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

Swift更加安全，它是類型安全的語(yǔ)言楷扬。

Swift容易閱讀，語(yǔ)法和文件結(jié)構(gòu)簡(jiǎn)易化。

Swift更易于維護(hù)，文件分離后結(jié)構(gòu)更清晰骚秦。

Swift代碼更少甲馋，簡(jiǎn)潔的語(yǔ)法，可以省去大量冗余代碼

Swift速度更快若贮，運(yùn)算性能更高省有。

5. delegate(代理,委托)

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

delegate:

非常嚴(yán)格的語(yǔ)法蠢沿。所有將聽到的事件必須是在delegate協(xié)議中有清晰的定義,語(yǔ)法清晰,易讀;

如果delegate中的一個(gè)方法沒(méi)有實(shí)現(xiàn)那么就會(huì)出現(xiàn)編譯警告/錯(cuò)誤

在釋放代理對(duì)象時(shí)，需要小心的將delegate改為nil匾效。一旦設(shè)定失敗舷蟀，那么調(diào)用釋放對(duì)象的方法將會(huì)出現(xiàn)內(nèi)存crash

6.Notification(通知)

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

notification:

對(duì)于一個(gè)發(fā)出的通知，多個(gè)對(duì)象能夠做出反應(yīng)魔策，即1對(duì)多的方式實(shí)現(xiàn)簡(jiǎn)單

controller能夠傳遞context對(duì)象（dictionary）匈子，context對(duì)象攜帶了關(guān)于發(fā)送通知的自定義的信息

在調(diào)試的時(shí)候應(yīng)用的工作以及控制過(guò)程難跟蹤；

7.KVO

KVO是一個(gè)對(duì)象能夠觀察另外一個(gè)對(duì)象的屬性的值闯袒，并且能夠發(fā)現(xiàn)值的變化虎敦。

KVO：

能夠提供一種簡(jiǎn)單的方法實(shí)現(xiàn)兩個(gè)對(duì)象間的同步。例如：model和view之間同步政敢；

能夠?qū)Ψ俏覀儎?chuàng)建的對(duì)象其徙，即內(nèi)部對(duì)象的狀態(tài)改變作出響應(yīng)，而且不需要改變內(nèi)部對(duì)象（SKD對(duì)象）的實(shí)現(xiàn)喷户；

8. 如何選擇delegate唾那、notification、KVO褪尝？

三種模式都是一個(gè)對(duì)象傳遞事件給另外一個(gè)對(duì)象闹获，并且不要他們有耦合。

delegate. 一對(duì)一

notification 一對(duì)多,多對(duì)多

KVO 一對(duì)一

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

delegate 語(yǔ)法簡(jiǎn)潔,方便閱讀,易于調(diào)試

notification 靈活多變,可以跨越多個(gè)類之間進(jìn)行使用

KVO 實(shí)現(xiàn)屬性監(jiān)聽,實(shí)現(xiàn)model和view同步

可以根據(jù)實(shí)際開發(fā)遇到的場(chǎng)景來(lái)使用不同的方式

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

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

創(chuàng)建通知中心單例類,并在里面有個(gè)一個(gè)保存通知的全局NSDiction

對(duì)于注冊(cè)通知的類,將其注冊(cè)通知名作為key, 執(zhí)行的方法和類,以及一些參數(shù)做為一個(gè)數(shù)組為值

發(fā)送通知可以調(diào)用通知中心,通過(guò)字典key(通知名),找到對(duì)應(yīng)的 類和方法進(jìn)行執(zhí)行調(diào)用傳值.

10. Notification 和KVO區(qū)別

KVO提供一種機(jī)制,當(dāng)指定的被觀察的對(duì)像的屬性被修改后,KVO會(huì)自動(dòng)通知響應(yīng)的觀察者,KVC(鍵值編碼)是KVO的基礎(chǔ)

通知:是一種廣播機(jī)制,在實(shí)踐發(fā)生的時(shí)候,通過(guò)通知中心對(duì)象,一個(gè)對(duì)象能夠?yàn)樗嘘P(guān)心這個(gè)時(shí)間發(fā)生的對(duì)象發(fā)送消息,兩者都是觀察者模式,不同在于KVO是被觀察者直接發(fā)送消息給觀察者,是對(duì)象間的直接交互,通知?jiǎng)t是兩者都和通知中心對(duì)象交互,對(duì)象之間不知道彼此

本質(zhì)區(qū)別,底層原理不一樣.kvo 基于 runtime, 通知?jiǎng)t是有個(gè)通知中心來(lái)進(jìn)行通知

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

結(jié)構(gòu)體可以存不同類型的元素,而數(shù)組只能存同一類型

結(jié)構(gòu)體類型需要我們自已定義.數(shù)組是用別的類型加[元素個(gè)數(shù)]

結(jié)構(gòu)體內(nèi)存分配方式很特別,使用對(duì)齊原則,不一定是所有元素的字節(jié)數(shù)和,而數(shù)組一定是所有元素的字節(jié)數(shù)和.

結(jié)構(gòu)體指針可以指針名->結(jié)構(gòu)體元素名(取元素);數(shù)組不行.

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

哈希表(NSDictionary 是通過(guò)hash表來(lái)實(shí)現(xiàn)key和value之間的映射和存儲(chǔ)的)

13.說(shuō)一下靜態(tài)庫(kù)和動(dòng)態(tài)庫(kù)之間的區(qū)別

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

動(dòng)態(tài)庫(kù)：以.tbd(之前叫.dylib) 和 .framework 為文件后綴名茎用。

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

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

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

.framework 可以包含頭文件+資源信息

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

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

OC是C語(yǔ)言的超集, 在C語(yǔ)言基礎(chǔ)上增加了面向?qū)ο筇匦? 開發(fā)使用起來(lái)會(huì)方便高效.

分類可以快速擴(kuò)展類的方法.擴(kuò)展模塊之間相互不影響

運(yùn)行時(shí)特性,動(dòng)態(tài)特性(動(dòng)態(tài)類型,動(dòng)態(tài)綁定,動(dòng)態(tài)加載),提高了編程的靈活性

OC可以與C / C++進(jìn)行混編

缺點(diǎn):

不支持多繼承,多繼承可以使用分類,協(xié)議,消息轉(zhuǎn)發(fā)來(lái)彌補(bǔ)

不支持運(yùn)算符重載

使用動(dòng)態(tài)運(yùn)行時(shí)類型花盐，所有的方法都是函數(shù)調(diào)用羡滑，所以很多編譯時(shí)優(yōu)化方法都用不到菇爪，如內(nèi)聯(lián)函數(shù)等，性能低劣柒昏。

執(zhí)行效率比C低,語(yǔ)法怪異

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

通過(guò)攔截URL

使用MessageHandler(WKWebView)

JavaScriptCore (UIWebView)

使用三方庫(kù)WebViewJavascriptBridge,可提供 js 調(diào)OC,以及OC掉JS

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

通過(guò)攔截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)原生界面returnNO;? ? }returnYES;}

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

當(dāng)JS端想傳一些數(shù)據(jù)給iOS.那它們會(huì)調(diào)用下方方法來(lái)發(fā)送.

window.webkit.messageHandlers.<方法名>.postMessage(<數(shù)據(jù)>)上方代碼在JS端寫會(huì)報(bào)錯(cuò),導(dǎo)致網(wǎng)頁(yè)后面業(yè)務(wù)不執(zhí)行.可使用try-catch執(zhí)行.

那么在OC中的處理方法如下.它是WKScriptMessageHandler的代理方法.name和上方JS中的方法名相對(duì)應(yīng).

- (void)addScriptMessageHandler:(id)scriptMessageHandler name:(NSString*)name;

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

1.設(shè)置 webViewBridge_bridge = [WKWebViewJavascriptBridgebridgeForWebView:self.webView];? ? [_bridge setWebViewDelegate:self];2.注冊(cè)handler方法,需要和 前段協(xié)商好 方法名字,是供 JS調(diào)用Native 使用的凳宙。? ? [_bridge registerHandler:@"scanClick"handler:^(iddata, WVJBResponseCallback responseCallback) {// OC調(diào)用NSString*scanResult =@"http://www.baidu.com";// js 回調(diào)傳參responseCallback(scanResult);? ? }];3.OC掉用JS? [_bridge callHandler:@"testJSFunction"data:@"一個(gè)字符串"responseCallback:^(idresponseData) {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. 遇到過(guò)BAD_ACCESS的錯(cuò)誤嗎？你是怎樣調(diào)試的职祷？

BAD_ACCESS 報(bào)錯(cuò)屬于內(nèi)存訪問(wèn)錯(cuò)誤氏涩，會(huì)導(dǎo)致程序崩潰，錯(cuò)誤的原因是訪問(wèn)了野指針(懸掛指針)有梆。

設(shè)置全局?jǐn)帱c(diǎn)快速定位問(wèn)題代碼所在行是尖。

開啟僵尸對(duì)象診斷

Analyze分析

重寫object的respondsToSelector方法，現(xiàn)實(shí)出現(xiàn)EXEC_BAD_ACCESS前訪問(wèn)的最后一個(gè)object泥耀。

Xcode 7 已經(jīng)集成了BAD_ACCESS捕獲功能：Address Sanitizer饺汹。 用法如下：在配置中勾選?Enable Address Sanitizer。

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

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

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

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

鏈?zhǔn)骄幊?

top.bottom.left.right.equalTo(self.view)通過(guò)"."語(yǔ)法胎食，將需要執(zhí)行的代碼連續(xù)的書寫，就叫做鏈?zhǔn)骄幊淘识沟么a簡(jiǎn)單易懂厕怜。

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

響應(yīng)式編程是一種面向數(shù)據(jù)流和變化傳播的編程范式。

例如蕾总，在命令式編程環(huán)境中粥航，a:=b+c表示將表達(dá)式的結(jié)果賦給a，而之后改變b或c的值不會(huì)影響a生百。但在響應(yīng)式編程中递雀，a的值會(huì)隨著b或c的更新而更新。

Reactive Cocoa就是一個(gè)響應(yīng)式編程的經(jīng)典作品蚀浆！

23.Block和Protocol的區(qū)別缀程，Block是為了解決什么問(wèn)題而使用的搜吧。

“代理和block的共同特性是回調(diào)機(jī)制，不同的是杨凑，代理的方法比較多赎败，比較分散,公共接口，方法較多也選擇用delegate進(jìn)行解耦

使用block的代碼比較集中統(tǒng)一,異步和簡(jiǎn)單的回調(diào)用block更好”

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

block為了多線程之間調(diào)度產(chǎn)生的;

block 也是一個(gè)OC對(duì)象,可以當(dāng)參數(shù)傳遞,使用方便簡(jiǎn)單,靈活,很少的代碼就可以實(shí)現(xiàn)代碼回調(diào).比協(xié)議省很多代碼

24.說(shuō)一下ios代碼簽名

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

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

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

slicing 可以打包對(duì)應(yīng)的 app 資源文件

Bitcode 蘋果會(huì)對(duì)包含Bitcode的二進(jìn)制app進(jìn)行二次優(yōu)化曼追，而不需要提交一個(gè)新的app版本到app store中窍仰。

On-Demand Resources 按需加載

26. 如果沒(méi)有instruments，該如何檢測(cè)memory leak, zombie object 之類的問(wèn)題礼殊。

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

27.字典的工作原理 驹吮？怎100w個(gè)中是怎么快速去取value？

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

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

Objective-C 中的字典 NSDictionary 底層其實(shí)是一個(gè)哈希表，實(shí)際上絕大多數(shù)語(yǔ)言中字典都通過(guò)哈希表實(shí)現(xiàn)婚陪，

哈希表的本質(zhì)是一個(gè)數(shù)組族沃，數(shù)組中每一個(gè)元素稱為一個(gè)箱子(bin)，箱子中存放的是鍵值對(duì)泌参。數(shù)組長(zhǎng)度即箱子數(shù)脆淹。哈希表還有一個(gè)重要的屬性: 負(fù)載因子(load factor)，它用來(lái)衡量哈希表的 空/滿 程度沽一，一定程度上也可以體現(xiàn)查詢的效率盖溺，計(jì)算公式為:負(fù)載因子 = 總鍵值對(duì)數(shù) / 箱子個(gè)數(shù)負(fù)載因子越大，意味著哈希表越滿铣缠，越容易導(dǎo)致沖突烘嘱，性能也就越低。因此攘残，一般來(lái)說(shuō)拙友，當(dāng)負(fù)載因子大于某個(gè)常數(shù)(可能是1，或者0.75等)時(shí)歼郭，哈希表將自動(dòng)擴(kuò)容遗契。參考: http://www.reibang.com/p/88dfc8f405ab

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

isEquel 用于比較2個(gè)對(duì)象是否相等, 與==(地址比較)不一樣, 可以重寫isEquel方法,來(lái)進(jìn)行2個(gè)對(duì)象的比較

hash 是一個(gè)類方法，任何類都可以調(diào)用這個(gè)方法病曾，返回的結(jié)果是一個(gè)NSInteger值(如果兩個(gè)對(duì)象相等牍蜂，那么他們的hash值一定相等漾根，但是，如果兩個(gè)對(duì)象的哈希值相等是不能一定推出來(lái)這兩個(gè)對(duì)象是相等的)

29.isEquel 和 isEquelToString

isEquel 比較的是2個(gè)NSObject的方法,

isEquelToString是比較2個(gè)字符串值是否相等

isEquel 首先比較2個(gè)對(duì)象地址,如果相同就返回YES,如果不同,就比較對(duì)象類型,以及屬性的值,一般重寫 isEquel 來(lái)比較2個(gè)對(duì)象

30. iOS 9 以后通知不再需要手動(dòng)移除

通知 NSNotification 在注冊(cè)者被回收時(shí)需要手動(dòng)移除鲫竞，是一直以來(lái)的使用準(zhǔn)則辐怕。 原因是在 MRC 時(shí)代，通知中心持有的是注冊(cè)者的 unsafe_unretained 指針从绘，在注冊(cè)者被回收時(shí)若不對(duì)通知進(jìn)行手動(dòng)移除寄疏，則指針指向被回收的內(nèi)存區(qū)域，變?yōu)橐爸羔樈┚４藭r(shí)發(fā)送通知會(huì)造成 crash 陕截。 而在 iOS 9 以后，通知中心持有的是注冊(cè)者的 weak 指針批什，這時(shí)即使不對(duì)通知進(jìn)行手動(dòng)移除农曲，指針也會(huì)在注冊(cè)者被回收后自動(dòng)置空。因?yàn)橄蚩罩羔槹l(fā)送消息是不會(huì)有問(wèn)題的驻债。

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

一般情況下只有通過(guò)調(diào)用 set 方法對(duì)值進(jìn)行改變才會(huì)觸發(fā) KVO乳规。但是在調(diào)用NSMutableArray的 addObject或removeObject 系列方法時(shí)，并不會(huì)觸發(fā)它的 set 方法合呐。所以為了實(shí)現(xiàn)NSMutableArray的 KVO暮的，官方為我們提供了如下方法:

@property(nonatomic,strong)NSMutableArray*arr;//添加元素操作[[selfmutableArrayValueForKey:@"arr"] addObject:item];//移除元素操作[[selfmutableArrayValueForKey:@"arr"] removeObjectAtIndex:0];

32. 編譯過(guò)程做了哪些事情；

* Objective,Swift都是編譯語(yǔ)言合砂。編譯語(yǔ)言在執(zhí)行的時(shí)候青扔，必須先通過(guò)編譯器生成機(jī)器碼，機(jī)器碼可以直接在CPU上執(zhí)行翩伪，所以執(zhí)行效率較高。Objective,Swift二者的編譯都是依賴于Clang + LLVM. OC和Swift因?yàn)樵砩洗笸‘愄赶ⅲ酪粋€(gè)即可缘屹！

* iOS編譯 不管是OC還是Swift，都是采用Clang作為編譯器前端,LLVM(Low level vritual machine)作為編譯器后端侠仇。

* 編譯器前端 :編譯器前端的任務(wù)是進(jìn)行：語(yǔ)法分析轻姿，語(yǔ)義分析，生成中間代碼(intermediate representation )逻炊。在這個(gè)過(guò)程中互亮，會(huì)進(jìn)行類型檢查，如果發(fā)現(xiàn)錯(cuò)誤或者警告會(huì)標(biāo)注出來(lái)在哪一行

* 編譯器后端 :編譯器后端會(huì)進(jìn)行機(jī)器無(wú)關(guān)的代碼優(yōu)化余素，生成機(jī)器語(yǔ)言豹休，并且進(jìn)行機(jī)器相關(guān)的代碼優(yōu)化。LVVM優(yōu)化器會(huì)進(jìn)行BitCode的生成桨吊，鏈接期優(yōu)化等等,LLVM機(jī)器碼生成器會(huì)針對(duì)不同的架構(gòu)威根，比如arm64等生成不同的機(jī)器碼凤巨。

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

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

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

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

例：

1症歇、category給類添加方法用來(lái)替換掉原本存在潛在崩潰的方法郎笆。

2、利用runtime方法交換技術(shù)忘晤，將系統(tǒng)方法替換成類添加的新方法宛蚓。

3、利用異常的捕獲來(lái)防止程序的崩潰设塔，并且進(jìn)行相應(yīng)的處理凄吏。

4、使用 @try__Catch__方法進(jìn)行攔截

總結(jié)：

1闰蛔、不要過(guò)分相信服務(wù)器返回的數(shù)據(jù)會(huì)永遠(yuǎn)的正確痕钢。

2、在對(duì)數(shù)據(jù)處理上序六，要進(jìn)行容錯(cuò)處理任连，進(jìn)行相應(yīng)判斷之后再處理數(shù)據(jù)，這是一個(gè)良好的編程習(xí)慣例诀。

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

Objective-C 異常機(jī)制 :

-- 作用 : 開發(fā)者將引發(fā)異常的代碼放在 @try 代碼塊中, 程序出現(xiàn)異常 使用 @catch 代碼塊進(jìn)行捕捉;

-- 每個(gè)代碼塊作用 : @try 代碼塊存放可能出現(xiàn)異常的代碼, @catch 代碼塊 異常處理邏輯, @finally 代碼塊回收資源;

-- 語(yǔ)法示例 :

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

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

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

1.單元測(cè)試可以進(jìn)行 邏輯測(cè)試/異步測(cè)試/性能測(cè)試2.單元測(cè)試是以代碼測(cè)試代碼氧猬。不是靠NSLog來(lái)測(cè)試,而是使用斷言來(lái)測(cè)試的背犯，提前預(yù)判條件必須滿足。XCTAssert(條件, 不滿足條件的描述)3.可以在單元測(cè)試類中編寫單獨(dú)的測(cè)試用例方法盅抚。這些方法與普通的方法類似漠魏，但是方法名稱必須以 test 開頭，且不能有參數(shù)妄均，不然不會(huì)識(shí)別為測(cè)試方法柱锹。4.不是所有的方法都需要測(cè)試。例如私有方法不需要測(cè)試丰包，只有暴露在 .h 中的方法需要測(cè)試禁熏。一般而言，代碼的覆蓋度大概在50% ~70%邑彪。從 github 上得知：YYModel 測(cè)試覆蓋度為83%瞧毙，AFNetworking 測(cè)試覆蓋度為77%，兩者都是比較高的寄症。 總結(jié): 單元測(cè)試可以根據(jù)項(xiàng)目需要,針對(duì)一些關(guān)鍵業(yè)務(wù),編寫一些測(cè)試用例,可以方便的排查業(yè)務(wù)邏輯可能出現(xiàn)的問(wèn)題.在后續(xù)改動(dòng)時(shí)候也可以方便的測(cè)試等等.

37. 一個(gè)上線的項(xiàng)目宙彪，知道這個(gè)方法可能會(huì)出問(wèn)題，在不破壞改方法前提下有巧，怎么搞释漆？

做一些容錯(cuò)處理,防止崩潰

加一些日志收集,收集問(wèn)題再具體分析

try_catch

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

Xcode3以前：GCC；Xcode3：? ? ? ? ? ? 增加LLVM篮迎，GCC(前端) +LLVM(后端)男图；Xcode4.2：? ? ? ? ? 出現(xiàn)Clang-LLVM3.0成為默認(rèn)編譯器；Xcode4.6：LLVM升級(jí)到4.2版本甜橱；Xcode5：GCC被廢棄逊笆，新的編譯器是LLVM5.0，從GCC過(guò)渡到Clang-LLVM的時(shí)代正式完成

39.代碼從 Git 上拉下來(lái)到生成 .ipa 都有哪些過(guò)程岂傲，期間都生成了什么文件览露。

git clone 遠(yuǎn)程地址到本地

pod 三方集成

配置證書信息,簽名

打包 ipa

40.Pods的原理

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

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

相同點(diǎn):

二者都可以看成是一個(gè)代碼片段命锄。

函數(shù)指針類型和 Block 類型都可以作為變量和函數(shù)參數(shù)的類型

不同點(diǎn):

函數(shù)指針只能指向預(yù)先定義好的函數(shù)代碼塊堰乔，函數(shù)地址是在編譯鏈接時(shí)就已經(jīng)確定好的。從內(nèi)存的角度看脐恩，函數(shù)指針只不過(guò)是指向代碼區(qū)的一段可執(zhí)行代碼

block 本質(zhì)是 OC對(duì)象镐侯，是 NSObject的子類，是程序運(yùn)行過(guò)程中在棧內(nèi)存動(dòng)態(tài)創(chuàng)建的對(duì)象，可以向其發(fā)送copy消息將block對(duì)象拷貝到堆內(nèi)存苟翻，以延長(zhǎng)其生命周期韵卤。

42. 符號(hào)表

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

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

Crash 時(shí)的堆棧信息诅炉，全是二進(jìn)制的地址信息蜡歹。如果利用這些二進(jìn)制的地址信息來(lái)定位問(wèn)題是不可能的，因此我們需要將這些二進(jìn)制的地址信息還原成源代碼種的函數(shù)以及行號(hào)涕烧，這時(shí)候符號(hào)表就起作用了月而。利用符號(hào)表將原始的 Crash 的二進(jìn)制堆棧信息還原成包含行號(hào)的源代碼文件信息，可以快速定位問(wèn)題议纯。iOS 中的符號(hào)表文件(DSYM) 是在編譯源代碼后父款，處理完 Asset Catalog 資源和 info.plist 文件后開始生成，生成符號(hào)表文件(DSYM)之后瞻凤，再進(jìn)行后續(xù)的鏈接憨攒、打包、簽名鲫构、校驗(yàn)等步驟浓恶。

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

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

slicing, bitcode, on-demand resources炕吸，

* slicing

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

* bitcode

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

* On Demand Resources

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

44.埋點(diǎn)處理

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

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

頁(yè)面統(tǒng)計(jì)，即在進(jìn)入頁(yè)面和離開頁(yè)面的時(shí)候埋點(diǎn)摧玫，統(tǒng)計(jì)停留頁(yè)面時(shí)長(zhǎng)

交互事件統(tǒng)計(jì)

無(wú)痕埋點(diǎn)(自動(dòng)埋點(diǎn))解決方案:

技術(shù)原理：Method-Swizzling

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

參考鏈接:

http://www.reibang.com/p/b8a67c4acfb3

http://www.reibang.com/p/ae8d45e10ac5

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

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

iOS 系統(tǒng)向APNS服務(wù)器請(qǐng)求手機(jī)端的deviceToken

App 接收到手機(jī)端的 deviceToken,然后傳給 App 對(duì)應(yīng)的服務(wù)器.

App 服務(wù)端需要發(fā)送推送消息時(shí), 需要先通過(guò) APNS 服務(wù)器

然后根據(jù)對(duì)應(yīng)的 deviceToken 發(fā)送給對(duì)應(yīng)的手機(jī)