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

1.C和 OC 如何混編

xcode可以識別一下幾種擴展名文件:

.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的橋文件,在喬文件導入需要調(diào)用的OC代碼頭文件即可

OC 調(diào)用 Swift代碼

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

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)點?

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

優(yōu)點:

Swift更加安全，它是類型安全的語言。

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

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

Swift代碼更少，簡潔的語法，可以省去大量冗余代碼

Swift速度更快，運算性能更高。

5. delegate(代理,委托)

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

delegate:

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

如果delegate中的一個方法沒有實現(xiàn)那么就會出現(xiàn)編譯警告/錯誤

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

6.Notification(通知)

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

notification:

對于一個發(fā)出的通知，多個對象能夠做出反應(yīng)，即1對多的方式實現(xiàn)簡單

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

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

7.KVO

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

KVO：

能夠提供一種簡單的方法實現(xiàn)兩個對象間的同步。例如：model和view之間同步；

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

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

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

delegate. 一對一

notification 一對多,多對多

KVO 一對一

三者各有自己的特點:

delegate 語法簡潔,方便閱讀,易于調(diào)試

notification 靈活多變,可以跨越多個類之間進行使用

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

可以根據(jù)實際開發(fā)遇到的場景來使用不同的方式

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

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

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

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

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

10. Notification 和KVO區(qū)別

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

通知:是一種廣播機制,在實踐發(fā)生的時候,通過通知中心對象,一個對象能夠為所有關(guān)心這個時間發(fā)生的對象發(fā)送消息,兩者都是觀察者模式,不同在于KVO是被觀察者直接發(fā)送消息給觀察者,是對象間的直接交互,通知則是兩者都和通知中心對象交互,對象之間不知道彼此

本質(zhì)區(qū)別,底層原理不一樣.kvo 基于 runtime, 通知則是有個通知中心來進行通知

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

優(yōu)點:

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

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

運行時特性,動態(tài)特性(動態(tài)類型,動態(tài)綁定,動態(tài)加載),提高了編程的靈活性

OC可以與C / C++進行混編

缺點:

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

不支持運算符重載

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

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

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

通過攔截URL

使用MessageHandler(WKWebView)

JavaScriptCore (UIWebView)

使用三方庫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)原生界面returnNO;? ? }returnYES;}

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

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

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

那么在OC中的處理方法如下.它是WKScriptMessageHandler的代理方法.name和上方JS中的方法名相對應(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.注冊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:@"一個字符串"responseCallback:^(idresponseData) {NSLog(@"調(diào)用完JS后的回調(diào)：%@",responseData);? ? }];

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

// 直接運行 使用 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í)行的JS代碼[context evaluateScript:runJS];}

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

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

設(shè)置全局斷點快速定位問題代碼所在行。

開啟僵尸對象診斷

Analyze分析

重寫object的respondsToSelector方法，現(xiàn)實出現(xiàn)EXEC_BAD_ACCESS前訪問的最后一個object。

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

21.什么是函數(shù)式編程？鏈式

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

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

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

鏈式編程?

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

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

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

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

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

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

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

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

Block是為了解決什么問題而使用的? 個人認為:

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

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

24.說一下ios代碼簽名

確保從app store下載的app是沒被惡意篡改，如果修改則無法安裝, 以及驗證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。

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

Bitcode 蘋果會對包含Bitcode的二進制app進行二次優(yōu)化，而不需要提交一個新的app版本到app store中。

On-Demand Resources 按需加載

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

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

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

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

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

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

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

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

isEquel 用于比較2個對象是否相等, 與==(地址比較)不一樣, 可以重寫isEquel方法,來進行2個對象的比較

hash 是一個類方法，任何類都可以調(diào)用這個方法，返回的結(jié)果是一個NSInteger值(如果兩個對象相等，那么他們的hash值一定相等，但是，如果兩個對象的哈希值相等是不能一定推出來這兩個對象是相等的)

29.isEquel 和 isEquelToString

isEquel 比較的是2個NSObject的方法,

isEquelToString是比較2個字符串值是否相等

isEquel 首先比較2個對象地址,如果相同就返回YES,如果不同,就比較對象類型,以及屬性的值,一般重寫 isEquel 來比較2個對象

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

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

31. 如何對 NSMutableArray 進行 KVO

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

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

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

* Objective,Swift都是編譯語言。編譯語言在執(zhí)行的時候，必須先通過編譯器生成機器碼，機器碼可以直接在CPU上執(zhí)行，所以執(zhí)行效率較高。Objective,Swift二者的編譯都是依賴于Clang + LLVM. OC和Swift因為原理上大同小異，知道一個即可！

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

* 編譯器前端 :編譯器前端的任務(wù)是進行：語法分析，語義分析，生成中間代碼(intermediate representation )。在這個過程中，會進行類型檢查，如果發(fā)現(xiàn)錯誤或者警告會標注出來在哪一行

* 編譯器后端 :編譯器后端會進行機器無關(guān)的代碼優(yōu)化，生成機器語言，并且進行機器相關(guān)的代碼優(yōu)化。LVVM優(yōu)化器會進行BitCode的生成，鏈接期優(yōu)化等等,LLVM機器碼生成器會針對不同的架構(gòu)，比如arm64等生成不同的機器碼。

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

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

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

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

例：

1、category給類添加方法用來替換掉原本存在潛在崩潰的方法。

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

3、利用異常的捕獲來防止程序的崩潰，并且進行相應(yīng)的處理。

4、使用 @try__Catch__方法進行攔截

總結(jié)：

1、不要過分相信服務(wù)器返回的數(shù)據(jù)會永遠的正確。

2、在對數(shù)據(jù)處理上，要進行容錯處理，進行相應(yīng)判斷之后再處理數(shù)據(jù)，這是一個良好的編程習慣。

35.@try @catch異常機制

Objective-C 異常機制 :

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

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

-- 語法示例 :

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

36.單元測試是什么?

單元測試（unit testing），是指對軟件中的最小可測試單元進行檢查和驗證。

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

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

做一些容錯處理,防止崩潰

加一些日志收集,收集問題再具體分析

try_catch

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

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

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

git clone 遠程地址到本地

pod 三方集成

配置證書信息,簽名

打包 ipa

40.Pods的原理

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

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

相同點:

二者都可以看成是一個代碼片段。

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

不同點:

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

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

42. 符號表

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

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

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

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)會對編譯后的二進制文件進行二次優(yōu)化, 使用最新的編譯器自動編譯app并且針對特定架構(gòu)進行優(yōu)化。不會下載應(yīng)用針對不同架構(gòu)的優(yōu)化，而僅下載與特定設(shè)備相關(guān)的優(yōu)化，使得下載量更小，

* On Demand Resources

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

44.埋點處理

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

埋點分為兩種：

頁面統(tǒng)計，即在進入頁面和離開頁面的時候埋點，統(tǒng)計停留頁面時長

交互事件統(tǒng)計

無痕埋點(自動埋點)解決方案:

技術(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é)合本地配置的埋點json或者plist文件(若埋點需要額外的參數(shù)，需要給UIControl的類別通過Runtime添加屬性)，便可以實現(xiàn)自動埋點的功能。

參考鏈接:

http://www.itdecent.cn/p/b8a67c4acfb3

http://www.itdecent.cn/p/ae8d45e10ac5

45.說一下iOS 中的APNS,遠程推送原理?

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

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

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

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

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