當您準備 iOS 技術面試時，重要的是要了解您可能會被問到哪些主題以及對經驗豐富的 iOS 開發人員的期望。許多公司使用這些問題和主題（以一種或另一種形式）來衡量 iOS 候選人的經驗水平。它們涵蓋了 iOS 開發的各個方面，旨在廣泛瞭解該平臺。畢竟，高階開發人員應該能夠從頭到尾釋出完整的 iOS 產品。但在擁有大型 iOS 開發團隊（想想 25 人以上）的大公司中，專業化和專注於特定問題（如網路）的深入知識也會發生。這絕不是一份詳盡的清單，但它可以幫助您為即將到來的 iOS 技術面試做好準備。

> 如果你正在跳槽或者正準備跳槽不妨動動小手，新增一下我們們的交流群[**1012951431**](https://links.jianshu.com/go?to=https%3A%2F%2Fjq.qq.com%2F%3F_wv%3D1027%26k%3D5JFjujE)來獲取一份詳細的大廠面試資料為你的跳槽多添一份保障。

#提問：
1.  Swift 的主要特點和優點或缺點是什麼？
2.  什麼是 iOS 應用程式，您的程式碼在哪裡適合它？
3.  iOS 上的記憶體管理是如何處理的？
4.  什麼是MVC？
5.  你對單身人士瞭解多少？你會在哪裡使用，你不會在哪裡？
6.  解釋一下委託和 KVO 之間的區別？
7.  iOS 應用中常用的設計模式有哪些？
8.  除了常見的 Cocoa 模式，你還知道哪些設計模式？
9.  解釋和展示 SOLID 原則的例子？
10.  在 iOS 上實現儲存和持久化有哪些選擇？
11.  在 iOS 上實現網路和 HTTP 有哪些選擇？
12.  如何以及何時在 iOS 上序列化和對映資料？
13.  在 iOS 上佈局 UI 的選項有哪些？
14.  如何最佳化動態調整大小的表格或集合檢視的滾動效能？
15.  你如何在iOS上執行非同步任務？
16.  你如何管理依賴關係？
17.  你如何在 iOS 上除錯和分析程式碼？
18.  你有TDD經驗嗎？你如何在 iOS 上進行單元和 UI 測試？
19.  模擬、存根和假貨之間有什麼區別？
20.  您是否進行程式碼審查和/或結對程式設計？
21.  什麼是 FRP（Functional Reactive Programming）及其在 iOS 平臺中的地位？
22.  你知道哪些 iOS 架構有這麼大的規模？

在下面的部分中，我將詳細介紹每個問題、其背後的推理、預期答案以及可能會給面試官帶來危險的答案。在適用的情況下，問題有**進一步閱讀**部分，您可以在其中找到與它們相關的更多材料的連結和參考。

## 1.Swift 的主要特點和優點或缺點是什麼？

這聽起來像是一個初學者的問題，但事實並非如此。有時可能會要求評估您使用其他語言的經驗以及您對所使用語言的更廣泛理解及其優點、缺點和侷限性。

**預期答案：**

TLDR：主要的 Swift 特性 - 靜態型別、協議、引用型別、值型別、選項、泛型。

Swift 是一種強型別語言，這可能是它最大的特點，同時也是優點和缺點。靜態型別允許存在協議、泛型和選項，並幫助您進行開發。靜態型別給你很多編譯時警告和編譯錯誤，但提供了更好的執行時安全性和確定性（可選、var/let、泛型或具體型別等）。這是該語言提供的最大優勢之一。在以下場景中擁有嚴格的型別安全是最有幫助的：

*   當您構建客戶端應用程式並且需要更嚴格的明確性而不是動態性和靈活性時
*   當您在這樣的環境中工作時，您希望限制經驗不足的開發人員（初學者和初級人員）擁有過多的權力並讓自己陷入困境
*   當您需要重構程式碼並且編譯器可以幫助您正確正確地編寫程式碼時

所有這些恰好是 iOS 開發人員構建的大多數面向客戶的應用程式。

同時，當您構建需要更多靈活性的東西（例如構建庫或框架）時，靜態型別可能過於嚴格。在這方面，Objective-C 可能是更好的選擇，因為它比 Swift 具有更好的超程式設計功能。（雖然可以說此時 Objective-C 已經過時了，Apple 平臺的所有開發都應該在 Swift 中完成）

**注意點：**

只要您能闡明每個功能提供的內容，即協議和泛型實際上允許您在程式碼中做什麼，您就可以了？但同樣，與嚴格的型別系統相比，這些可以說是次要的語言功能。

*這個問題的進一步閱讀：*
*   [關於 Swift (swift.org)](https://swift.org/about)

## 2.什麼是 iOS 應用程式，您的程式碼在哪裡適合它？

這是一個以一種或另一種形式提出的宏觀問題，以衡量您對 iOS 應用程式是什麼的理解，以及您編寫的程式碼在其中的位置以及在整個 iOS 系統中的位置。

**預期答案：**

我們可能認為我們構建的應用程式很特別，因為它們涵蓋了一個獨特的用例。但是您典型的 iOS 應用程式只是一個巨大的、美化的執行迴圈。它等待使用者輸入並被外部訊號中斷，例如電話、推送通知、家庭手勢/按鈕按下和其他應用程式生命週期事件。唯一的區別在於，它不僅僅是一個簡單的主迴圈函式，每次使用者點選您的應用程式圖示時都會啟動它，它具有更高階別的抽象，開發人員可以使用[UIApplication](https://developer.apple.com/documentation/uikit/uiapplication)、[AppDelegate](https://developer.apple.com/documentation/uikit/uiapplicationdelegate)和[SceneDelegate](https://developer.apple.com/documentation/uikit/uiscenedelegate)。

您為實現應用程式的業務邏輯而編寫的其餘程式碼放置在該主迴圈透過`AppDelegate`或委託給我們的應用程式的“觸發點”中的某個位置`SceneDelegate`。在 iOS 13`AppDelegate`負責接收應用程式的所有外部事件並啟動 UI 之前；但是從 iOS 13 開始，所有與 UI 相關的邏輯都移到了 SceneDelegate。

而已。簡單的。您為應用編寫的程式碼可以像方法/函式呼叫一樣簡單，也可以像 VIPER 架構一樣複雜。這是你的選擇。

**注意點：**

通常，開發人員將 iOS 應用程式視為他們編寫的 MVC 程式碼以及實現的複雜細節，這是事實。但是如果你退後一步看大局，你會看到 iOS 應用程式真正是什麼——一個執行迴圈。

*這個問題的進一步閱讀：*

*   [UIApplicationDelegate (developer.apple.com)](https://developer.apple.com/documentation/uikit/uiapplicationdelegate)
*   [響應您的應用程式的釋出 (developer.apple.com)](https://developer.apple.com/documentation/uikit/app_and_environment/responding_to_the_launch_of_your_app)
*   [UISceneDelegate (developer.apple.com)](https://developer.apple.com/documentation/uikit/uiscenedelegate)
*   [準備您的 UI 以在前臺執行 (developer.apple.com)](https://developer.apple.com/documentation/uikit/app_and_environment/scenes/preparing_your_ui_to_run_in_the_foreground)
*   [準備您的 UI 以在後臺執行 (developer.apple.com)](https://developer.apple.com/documentation/uikit/app_and_environment/scenes/preparing_your_ui_to_run_in_the_background)

## 3.iOS 中的記憶體管理是如何處理的？

記憶體管理在任何應用程式中都非常重要，尤其是在具有記憶體和其他硬體和系統限制的 iOS 應用程式中。本題涉及ARC、MRC、引用型別和值型別。

**預期答案：**

Swift 使用自動引用計數 ( [ARC](https://docs.swift.org/swift-book/LanguageGuide/AutomaticReferenceCounting.html) )。這在 Swift 和 Objective-C 中在概念上是一樣的。ARC 跟蹤對類例項的強引用，並在您將類（引用型別）的例項分配或取消分配給常量、屬性和變數時相應地增加或減少它們的引用計數。它釋放引用計數降至零的物件使用的記憶體。ARC 不會增加或減少值型別的引用計數，因為在賦值時，這些被複制。預設情況下，如果您不另行指定，則所有引用都將是強引用。

**注意點：**

這是每個 iOS 開發者都必須知道的！由於 iOS 應用程式中的記憶體管理不善，記憶體洩漏和應用程式崩潰非常普遍。

*這個問題的進一步閱讀：*

*   [自動引用計數 (docs.swift.org)](https://docs.swift.org/swift-book/LanguageGuide/AutomaticReferenceCounting.html)

## 4.什麼是MVC？

哦，好老的MVC。這是 Apple 不斷推給 iOS 開發人員的基本設計模式。很可能每個面試官都會問這個，不管你是申請高階職位還是初級職位。不過，您作為大四學生的回答會有所不同。

**預期答案：**

`MVC`代表模型檢視控制器。這是 Apple 選擇的一種軟體設計模式，作為 iOS 應用程式開發的主要方法。模型代表應用資料；檢視在螢幕上繪製東西；控制器管理模型和檢視之間的資料流。模型和檢視從不直接相互通訊，而是依靠控制器來協調通訊。這種設計模式被 Apple 從其[最初的 SmallTalk 實現](https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller#History)演變成其他的東西 。

iOS 應用程式中每個 Apple MVC 層的典型表示是：

*   [UIView](https://developer.apple.com/documentation/uikit/uiview)子類（Cocoa Touch 或自定義）是檢視
*   [UIViewControllers](https://developer.apple.com/documentation/uikit/uiviewcontroller)及其子類是控制器
*   任何資料物件、[NSManagedObject](https://developer.apple.com/documentation/coredata/nsmanagedobject)子類和類似的都是模型

MVC 是一種很棒的通用設計模式，但作為高階開發人員，您應該知道它只是檢視層的一種設計模式，單獨使用它會限制您的架構，並經常導致臭名昭著的“大規模檢視控制器”問題。

大規模檢視控制器是程式碼庫的狀態，其中許多邏輯和責任被推入不屬於那裡的檢視控制器。這種做法會使您的程式碼僵化、臃腫且難以更改。還有其他設計模式可以幫助您解決這個問題，例如 [MVVM](https://www.objc.io/issues/13-architecture/mvvm/)、 [MVP](https://martinfowler.com/eaaDev/uiArchs.html#Model-view-presentermvp)和 [Coordinator](https://www.raywenderlich.com/158-coordinator-tutorial-for-ios-getting-started)。還有一些架構，例如[VIPER](https://www.objc.io/issues/13-architecture/viper/)和 [RIB](https://github.com/uber/RIBs)，專門用於擴充套件 iOS 程式碼和避免 Massive View Controller 問題。

儘管 Apple 一直告訴我們 MVC 是一切，但要更好地瞭解並堅持[SOLID](https://en.wikipedia.org/wiki/SOLID)原則。

**注意點：**

您絕對必須知道什麼是 MVC，因為它是任何 iOS 開發的基礎。不過，探索替代方案和附加功能，例如 MVVM、MVP、VIPER 和 RIB。

*這個問題的進一步閱讀：*

*   [Model-View-Controller (developer.apple.com)](https://developer.apple.com/library/archive/documentation/General/Conceptual/DevPedia-CocoaCore/MVC.html)
*   [Lighter View Controllers (objc.io)](https://www.objc.io/issues/1-view-controllers/)
*   [Massive View Controller (khanlou.com)](http://khanlou.com/2015/12/massive-view-controller/)
*   [The Problems with View Controllers (insideiosdev.com)](http://insideiosdev.com/the-problems-with-view-controllers)
*   [Introduction to MVVM (objc.io)](https://www.objc.io/issues/13-architecture/mvvm/)
*   [View Models To The Rescue (insideiosdev.com)](http://insideiosdev.com/ea25af39)
*   [Model-View-Presenter (MVP) (martinfowler.com)](https://martinfowler.com/eaaDev/uiArchs.html#Model-view-presentermvp)

## 5.你對Singleton瞭解多少？你會在哪裡使用，你不會在哪裡？

Singleton 是許多 OOP 語言中常用的設計模式，Cocoa 將其視為“Cocoa 核心能力”之一。這個問題出現在面試中，以衡量您對Singleton的體驗，或者瞭解您是否擁有 iOS 以外的其他方面的背景。

**預期答案：**

[Singleton](https://en.wikipedia.org/wiki/Singleton_pattern)是一個類，無論您請求多少次，它都只返回一個相同的例項。

單例有時被認為是一種反模式。使用單例有多個缺點。主要是全域性狀態、物件生命週期和依賴注入。當您只有一個例項時，很容易直接在任何地方引用和使用它，而不是將它注入到您的物件中。這會導致程式碼中不必要的具體實現耦合，而不是使用介面抽象。

“Singleton”的另一個副作用是全域性狀態。單例通常可以實現全域性狀態共享，並扮演每個物件用來儲存狀態的“公共包”的角色。當這種不受控制的狀態被某人覆蓋或刪除時，這會導致不可預測的結果和錯誤或崩潰。

**注意點：**

儘管在某些語言和平臺中單例被認為是好的，但它們實際上是一種反模式，應該不惜一切代價避免。

*這個問題的進一步閱讀：*

*    [Why Singletons Are Evil (insideiosdev.com)](http://insideiosdev.com/dde8a34e)
*   [Singletons Are Evil (wiki.c2.com)](http://wiki.c2.com/?SingletonsAreEvil)

## 6.Delegate和 KVO 之間有什麼區別？

透過這個問題，您的面試官正在評估您對 iOS 中使用的不同訊息傳遞模式的瞭解。

**預期答案：**

兩者都是在物件之間建立關係的方法。[Delegate](https://developer.apple.com/library/archive/documentation/General/Conceptual/DevPedia-CocoaCore/Delegation.html)是一種一對一的關係，其中一個物件實現委託協議；另一個使用協議定義的方法向它傳送訊息。[KVO](https://developer.apple.com/library/archive/documentation/General/Conceptual/DevPedia-CocoaCore/KVO.html)是一種多對多關係，其中一個物件廣播一條訊息，一個或多個其他物件偵聽它並做出反應。KVO 不依賴於協議。KVO 是反應式程式設計（[RxSwift](https://github.com/ReactiveX/RxSwift)、[ReactiveCocoa](https://github.com/ReactiveCocoa/ReactiveCocoa)等）的 第一步和基本塊

**注意點：**

經驗豐富的開發人員應該知道兩者之間的區別，以及在哪裡使用它們。

*這個問題的進一步閱讀：*

*   [Delegation (developer.apple.com)](https://developer.apple.com/library/archive/documentation/General/Conceptual/DevPedia-CocoaCore/Delegation.html)
*   [Key-Value Observing (nshipster.com)](https://nshipster.com/key-value-observing/)
*   [ReactiveX (reactivex.io)](http://reactivex.io/)

## 7.iOS 應用中常用的設計模式有哪些？

這個問題在所有級別職位的面試中都很常見，除了初級職位。使用 iOS 平臺的開發人員應該熟悉 iOS 上常用的技術、架構和設計模式。

**預期答案：**

構建 iOS 應用程式時典型的常用模式是 Apple 在其 Cocoa、Cocoa Touch、Objective-C 和 Swift 文件中提倡的模式。這些是每個 iOS 開發人員都學習的模式。Apple 將它們稱為“核心競爭力”設計模式。它們包括[MVC](https://developer.apple.com/library/archive/documentation/General/Conceptual/DevPedia-CocoaCore/MVC.html)、[Singleton](https://developer.apple.com/documentation/swift/cocoa_design_patterns/managing_a_shared_resource_using_a_singleton)、[Delegate](https://developer.apple.com/documentation/swift/cocoa_design_patterns/using_delegates_to_customize_object_behavior)和[Observer](https://developer.apple.com/documentation/swift/cocoa_design_patterns/using_key-value_observing_in_swift)。

**注意點：**

當面試官問這個問題（以一種或另一種形式）時，他正在尋找 MVC 之外的東西。因為 MVC 是首選設計模式，所以期望每個 iOS 開發人員都知道它。但是，他們想從您那裡聽到的是我們通常開箱即用的其他內容。

*這個問題的進一步閱讀：*

*   [Model-View-Controller (developer.apple.com)](https://developer.apple.com/library/archive/documentation/General/Conceptual/DevPedia-CocoaCore/MVC.html)
*   [Cocoa Design Patterns (developer.apple.com)](https://developer.apple.com/documentation/swift/cocoa_design_patterns)

## 8.除了常見的 Cocoa 模式，你還知道哪些設計模式？

這是一個高階問題，面試官在你面試高階或建築師職位時會問這個問題。期望您瞭解 iOS 應用程式中使用的更多實用設計模式，而不是前面問題中涵蓋的基本設計模式。準備好回憶一堆[四人組](http://wiki.c2.com/?GangOfFour)模式和其他類似模式。

設計模式本身就是一個很大的話題（它們在[我的書中](https://iosinterviewguide.com/?ref=ios-interview-questions-for-senior-devs-2020)有更好的介紹），所以在這裡我將只總結那些我在 iOS 程式碼庫中常見的內容。

**預期答案：**

除了常用的 MVC、Singleton、Delegate 和 Observer 模式之外，還有許多其他模式非常適用於 iOS 應用程式：[Factory Method](https://www.oodesign.com/factory-method-pattern.html)、[Adapter](https://www.oodesign.com/adapter-pattern.html)、[Decorator](https://www.oodesign.com/decorator-pattern.html)、[Command](https://www.oodesign.com/command-pattern.html)和[Template](https://www.sm-cloud.com/template-method/)。

**工廠方法**用於替換類建構函式，抽象和隱藏物件初始化以便在執行時確定型別，以及隱藏和包含`switch/if`確定要例項化的物件型別的語句。

**介面卡**是一種設計模式，顧名思義，它可以幫助您使一個物件的介面適應另一個物件的介面。當您嘗試調整無法更改為您的程式碼的第三方程式碼時，或者當您需要使用具有不方便或不相容的 API 的東西時，通常會使用此模式。

**裝飾器**是另一個類的包裝器，可增強其功能。它環繞著你想要裝飾的東西，實現它的介面，並將傳送給它的訊息委託給底層物件，或者增強它們或提供它自己的實現。

**命令**是一種設計模式，您可以在其中實現一個物件，該物件表示您想要執行的操作。該操作可以有自己的狀態和邏輯來執行它所做的任務。這種設計模式的主要優點是您可以對使用者隱藏操作的內部實現，您可以為其新增撤消/重做功能，並且您可以在稍後的時間點（或根本不）執行操作而不是立即建立操作。

**模板**是一種設計模式，其主要概念是擁有一個基類，該基類概述了需要完成的工作的演算法。基類有幾個抽象方法，需要由它的具體子類來實現。這些方法稱為鉤子方法。模板方法類的使用者僅使用實現演算法步驟的基類進行互動；這些步驟的具體實現由子類提供。

**注意點：**

當您剛開始使用 iOS 平臺時，僅堅持使用 MVC、單例、委託和觀察者模式是沒問題的，但是對於高階的東西，您需要更深入地研究更抽象和更高階的東西，例如四人組 OOP 設計模式。它們非常有用，可以使您的程式碼庫更加靈活和可維護。

*這個問題的進一步閱讀：*

*   [設計模式書 (wiki.c2.com)](http://wiki.c2.com/?DesignPatternsBook)
*   [OODesign.com](https://www.oodesign.com/)
*   [理解設計模式和架構 (insideiosdev.com)](http://insideiosdev.com/39d89682)
*   [Swift Optionals 和 Null 物件設計模式 (m.smartcloud.io)](https://m.smartcloud.io/swift-optionals-and-the-null-object-design-pattern-7578b7448edf)
*   [空物件模式和得墨忒耳定律 (insideiosdev.com)](http://insideiosdev.com/3362c124)

## 9.解釋和展示 SOLID 原則的例子？

SOLID 原則是相對古老但非常有用的概念，可以應用於任何語言的任何 OOP 程式碼庫。觀看鮑勃叔叔關於該主題的一些演講，以充分了解他們背後的歷史。

在 YouTube 上：[Bob Martin 物件導向和敏捷設計的 SOLID 原則](https://www.youtube.com/watch?v=TMuno5RZNeE)。

不幸的是，[SOLID](https://en.wikipedia.org/wiki/SOLID)原則本身就是一個很大的話題（它們在[我的書中](https://iosinterviewguide.com/)也有更好的介紹），所以在這裡我將只給出它們的概述。

**預期答案：**

**SOLID**代表[單一職責原則](https://www.oodesign.com/single-responsibility-principle.html)、[開放/封閉原則](https://www.oodesign.com/open-close-principle.html)、[Liskov 替換原則](https://www.oodesign.com/liskov-s-substitution-principle.html)、[介面隔離原則](https://www.oodesign.com/interface-segregation-principle.html)和[依賴倒置原則](https://www.oodesign.com/dependency-inversion-principle.html)。這些原則相互補充和支援，是您可以為程式碼採用的最佳通用設計方法之一。讓我們來看看它們中的每一個。

**單一職責原則（SRP）**是團隊中最重要的原則。它指出每個模組應該只有一個更改的責任和理由。SRP 從小的具體和特定案例開始，例如一個類和/或一個只有一個目的並且僅用於一件事的物件。

**開放/封閉原則 (OCP)**規定您的模組應該對擴充套件開放，但對修改關閉。這是聽起來很容易的事情之一，但當您開始思考它的含義時，有點難以理解。實際上，這意味著在編寫程式碼時，您應該能夠透過使用介面、抽象和依賴注入實現物件的繼承、多型和組合來擴充套件物件的行為。

**Liskov 替換原則 (LSP)**指出，程式中的物件應該可以替換為其子型別的例項，而不會改變該程式的正確性。這意味著當您從類或抽象類繼承或實現介面（協議）時，您的物件應該是可替換和可注入的，無論您使用哪個介面或類的子類。這個原則通常被稱為契約設計，或者在 Swift 社群的後期，被稱為面向協議的程式設計。這個原則的主要資訊是你不應該違反你的介面從承諾到實現的子類的約定，並且透過子類化，這些子類可以在以前使用超類的任何地方使用。

**介面隔離原則 (ISP)**說，許多特定於客戶端的介面比一個通用介面要好。它還指出，不應強迫任何客戶端依賴和實現它不使用的方法。這意味著當你建立你的類實現的介面（協議）時，你應該爭取並依賴抽象而不是特異性，但直到它成為一種浪費，你必須實現一堆你的新類沒有的方法甚至使用。

**依賴倒置原則 (DIP)**指出，“依賴於抽象，而不是具體化。” 展示此原則的最佳示例是依賴注入 (DI) 技術。使用依賴注入技術，當你建立一個物件時，你在它的初始化或配置時提供和注入它的所有依賴項，而不是讓物件為自己建立或獲取/找到它的依賴項。

**注意點：**

SOLID 原則是良好的 OOP 設計的基石。應用這些原則將幫助您構建更好、更易於維護的軟體。如果您正在申請 iOS 高階職位，強烈建議您精通它們。

*這個問題的進一步閱讀：*

*   [設計原則 (oodesign.com)](https://www.oodesign.com/design-principles.html)

## 10.在 iOS 上實現儲存和持久化有哪些選擇？

面試官問這個問題是為了讓你瞭解你有哪些工具和方式可以在 iOS 上儲存和持久化資料。

**預期答案：**

通常有以下幾種方式來儲存資料，從簡單到複雜的順序：

*   記憶體中的陣列、字典、集合和其他資料結構
*   NSUserDefaults/鑰匙串
*   檔案/磁碟儲存
*   核心資料，領域
*   SQLite

**記憶體中的陣列、字典、集合和其他資料結構**非常適合中間儲存資料，或者如果不需要持久化資料。

**NSUserDefaults/Keychain**是簡單的鍵值儲存。一個是不安全的，另一個是安全的。

**檔案/磁碟儲存**是一種使用[NSFileManager](https://developer.apple.com/documentation/foundation/nsfilemanager)向/從磁碟寫入資料（序列化或非序列化）的[方式](https://developer.apple.com/documentation/foundation/nsfilemanager)。

**Core Data**和**Realm**是簡化資料庫工作的框架。

**SQLite**是一個關係型資料庫，當你需要實現複雜的查詢機制而 Core Data 或 Realm 不會削減它時，它是很好的。

**注意點：**

您應該瞭解在 iOS 上儲存資料的不同方式及其優缺點。不要將自己侷限於一種您習慣的解決方案（例如 Core Data）。知道什麼時候一個比另一個更可取。

*這個問題的進一步閱讀：*

*   [Collection Types (docs.swift.org)](https://docs.swift.org/swift-book/LanguageGuide/CollectionTypes.html)
*   [Core Data (developer.apple.com)](https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/CoreData/index.html)
*   [Realm (realm.io)](https://realm.io/products/realm-database)
*   [SQLite With Swift Tutorial: Getting Started (raywenderlich.com)](https://iosinterviewguide.com/[https://www.raywenderlich.com/385-sqlite-with-swift-tutorial-getting-started])

## 11.哪些選項可用於 iOS 上的網路和 HTTP？

如今，每個應用程式都使用網路從 API 和其他外部資源獲取資料。許多應用程式在未連線到網際網路時是無用的。每個 iOS 開發人員都應該知道他們可以使用什麼來構建應用程式的服務/網路層。

**預期答案：**

在 iOS 中有幾種實現[HTTP](https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol)網路的選項。您可以使用舊的[NSURLSession](https://developer.apple.com/documentation/foundation/urlsession)，但除非您將其抽象得足夠好，否則使用它可能會令人生畏。另一種選擇是在它周圍使用包裝器庫。iOS 上最流行的解決方案是[Alamofire](https://github.com/Alamofire/Alamofire)。

一般來說，如果您有一個小團隊，您可能希望依賴開源解決方案，例如 Alamofire，它為您抽象出大量樣板程式碼；但是如果你在一個大團隊中並且可以節省資源，你會希望對資料如何傳入/傳出伺服器有更多的控制權，並使用 NSURLSession 自己實現它。

高階開發人員應該記住，在 iOS 應用程式中構建網路層不僅意味著處理 HTTP 請求，還意味著實現您的程式碼所做的與此相關的整套任務：HTTP 網路、資料序列化和資料對映。

**注意點：**

現在，NSURLSession 和 Codable 是 iOS 上用於網路的兩種主要技術，但瞭解開源解決方案（例如 Alamofire）也是有益的。

*這個問題的進一步閱讀：*

*   [NSURLSession (developer.apple.com)](https://developer.apple.com/documentation/foundation/nsurlsession)
*   [Codable (developer.apple.com)](https://developer.apple.com/documentation/swift/codable)
*   [Alamofire (github.com)](https://github.com/Alamofire/Alamofire)
*   [Representational state transfer (REST)](https://en.wikipedia.org/wiki/Representational_state_transfer)

## 12.如何以及何時在 iOS 上序列化和對映資料？

資料序列化是構建 iOS 應用程式時的一項常見任務。面試官問這個問題是想看看你是否知道它適合哪裡，是否知道處理資料時所需的任務，無論是網路還是儲存資料。

**預期答案：**

有兩種最常見的場景需要在 iOS 應用程式中序列化和對映資料：在網路層接收或傳送資料（例如 JSON 或 XML 或其他東西），以及在儲存層（NSData）中持久化或檢索模型，NSManagedObject）。

每次您從後端 API 接收 JSON 或 XML 或任何其他響應型別的響應時，您很可能會以 JSON 或二進位制或其他“不方便”的格式獲得它。要處理收到的資料，您需要做的第一件事是將其序列化為您的應用程式可以理解的內容。在最簡單和基本的層面上，這將是一個字典或一個包含來自該響應的其他字典、陣列和基元的物件陣列。NSJSONSerialization 負責解決這個問題。下一步是將該資料對映到應用程式的域模型中。這些將是應用程式其餘部分要使用的模型物件或結構。您可以手動完成，也可以使用`Codable`Apple 提供的協議或使用 Mantle 或 SwiftyJSON 等庫。資料和序列化/對映的流程是：`binary data`->`json`-> `NSDictionary/NSArray`-> `your domain model objects`。

同樣，在儲存層中，您需要將資料序列化並對映到您的自定義域模型物件和從您的自定義域模型物件對映到您的儲存理解的格式。讀取資料的“對映”鏈：`db`-> `raw data format`-> `custom domain models`; 和寫作：`custom domain models`-> `raw data format`-> `db`。您將在這裡使用 NSManagedObject 或 NSCoding 或 Codable 協議來實現這一點。

**注意點：**

這裡的主要危險訊號是沒有意識到在使用 iOS 應用程式的網路和儲存層時需要進行這些資料操作。事情不會“自動”發生，使用原始 NSDictionaries 也不合適且可維護。

*這個問題的進一步閱讀：*

*   [Codable (developer.apple.com)](https://developer.apple.com/documentation/swift/codable)
*   [NSJSONSerialization (developer.apple.com)](https://developer.apple.com/documentation/foundation/nsjsonserialization)

## 13在 iOS 上佈局 UI 的選項有哪些？

當您需要在 iOS 上解決不同的 UI 挑戰時，瞭解在螢幕上佈置內容的選項至關重要。這個問題有助於衡量您如何在螢幕上放置和對齊檢視的知識。在回答這個問題時，你至少應該提到 CGRect、Fframes 和 AutoLayout 和 SwiftUI，但最好提到其他選項，例如 Texture (ASDK)、ComponentKit 和其他 Flexbox 和 React 在 iOS 上的實現。

**預期答案：**

在螢幕上佈置檢視的首選選項是舊的 CGRect Frames 和 AutoLayout。框架以及自動調整大小的遮罩，過去在 iOS 6 之前使用過，現在不是首選選項。框架太容易出錯且難以使用，因為很難計算各種裝置的精確座標和檢視大小。

從 iOS 6 開始，我們有了 AutoLayout，這是當今的首選解決方案，也是 Apple 更喜歡的。AutoLayout 是一種技術，可幫助您以宣告方式定義檢視之間的關係（稱為約束），讓框架計算 UI 元素的精確框架和位置。

在 iOS 13 中，Apple 引入了一種佈局檢視的新方法 - SwiftUI，這是一種宣告式方法，支援使用 Combine 進行 FRP（功能反應式程式設計）資料繫結。FRP 和宣告式 UI 並不是新概念，但 SwiftUI 和 Combine 是 Apple 支援它的新框架。SwiftUI 的宣告性質允許您非常簡潔地宣告您的 UI 元素，然後透過資料繫結宣告 UI 的哪些部分，例如文字標籤，以更新哪些資料模型更改。實際上，它允許你做以前用 RxSwift 已經可以做到的事情，但現在用 Apple 框架。

佈局檢視還有其他選項，例如 ASDK（Texture）、ComponentKit 和 LayoutKit，其中一些或多或少受到 React 的啟發，而另一些則以不同的方式解決佈局非同步性。這些替代方案在某些情況下非常有用，例如，您需要構建高度動態且快速的表檢視和集合檢視。AutoLayout 並不總是完美的，知道有其他選擇總是好的。

注意：我們將在未來看到 SwiftUI 如何證明自己解決複雜的 UI 問題和複雜的非同步 UI 佈局問題，在撰寫本文時，它是一項非常新的技術。

**注意點：**

至少不要提到 AutoLayout 以及框架很難正確的事實，這對你的面試官來說是一個危險訊號。如今，除非有必要（例如，當您進行瘋狂繪圖時），否則沒有理智的人會進行 CGRect 框架計算。

這還不是危險訊號，但請提及 SwiftUI，這可能是 Apple 在未來幾年推動我們的目標。

*這個問題的進一步閱讀：*

*   [Understanding Auto Layout (developer.apple.com)](https://developer.apple.com/library/archive/documentation/UserExperience/Conceptual/AutolayoutPG/)
*   [SwiftUI (developer.apple.com)](https://developer.apple.com/documentation/swiftui)
*   [Texture (http://texturegroup.org/)](http://texturegroup.org/)

## 14.如何最佳化動態大小的表或集合檢視的滾動效能？

面試中與 UITableView 問題一起的重要問題之一是關於滾動效能。

**預期答案：**

滾動效能是 UITableViews 的一個大問題，而且通常很難做到正確。主要難點是單元高度計算。當使用者滾動時，每個下一個單元格都需要計算其內容和高度才能顯示。如果您進行手動框架檢視佈局，那麼它的效能會更高，但挑戰在於正確計算高度和大小。如果您使用 AutoLayout，那麼挑戰是正確設定所有約束。但即使是 AutoLayout 本身也可能需要一些時間來計算單元格高度，並且您的滾動效能會受到影響。

滾動效能問題的潛在解決方案可能是：

*   自己計算單元格高度
*   保留一個用內容填充的原型單元格並使用它來計算單元格高度

或者，您可以採取完全激進的方法，即使用不同的技術，例如 ASDK（紋理）。ASDK (Texture) 專為具有動態內容大小的列表檢視而設計，並針對在後臺執行緒中計算單元格高度進行了最佳化，使其具有超強的效能。

*這個問題的進一步閱讀：*

*   [Texture (http://texturegroup.org/)](http://texturegroup.org/)

## 15.你將如何在 iOS 上執行非同步任務？

如今，多執行緒是任何客戶端、面向使用者的應用程式的重要組成部分。這個問題可以在網路環境中提出，也可以作為關於 GCD 或非同步開發的獨立問題提出。

**預期答案：**

現在在 iOS 上，非同步任務的首選解決方案是 NSOperations 和 GCD 塊。Grand Central Dispatch 是一種與多個後臺佇列一起工作的技術，這些佇列反過來確定哪個後臺執行緒處理工作。主要的是，這是從你那裡抽象出來的，這樣你就不必擔心了。NSOperation 是 GCD 之上的 OOP 抽象，它允許您執行更復雜的非同步操作，但是您可以使用 NSOperations 實現的所有操作都可以使用 GCD 完成。許多 Cocoa 框架在底層使用 GCD 和/或 NSOperations（例如 NSURLSession）。

有使用第三方庫的幫助處理非同步工作的替代方法。最著名的是 Promises (PromiseKit)、RxSwift 和 ReactiveCocoa。RxSwift 和 ReactiveCocoa 尤其擅長建模需要在後臺完成並線上程之間協調的時間和工作的非同步性質。

**注意點：**

每個 iOS 開發人員都應該瞭解的有關非同步工作的基礎知識是 GCD 和 NSOperations。RxSwift 和 Promises 是高階概念，但高階開發人員應該知道它們。

*這個問題的進一步閱讀：*

*   [Asynchronous Frameworks on iOS (insideiosdev.com)](https://insideiosdev.com/episodes/async-frameworks-ios)
*   [GCD (developer.apple.com)](https://developer.apple.com/documentation/dispatch)
*   [NSOperations (developer.apple.com) ](https://developer.apple.com/documentation/foundation/operation)
*   [NSOperation (nshipster.com)](https://nshipster.com/nsoperation/)
*   [PromiseKit](https://github.com/mxcl/PromiseKit)
*   [RxSwift](https://github.com/ReactiveX/RxSwift%20http://reactivex.io/)

## 16.你如何管理依賴關係？

依賴管理是每個 iOS 專案中的一項重要任務。這個問題衡量您對問題及其解決方案的理解。

**預期答案：**

幾年前，我們在 iOS 上沒有任何依賴管理器，不得不將第三方程式碼複製貼上和拖放到我們的專案中或使用 Git 子模組。隨著我們的程式碼庫和依賴項的增長，這些方法被證明是難以管理的。

現在我們有其他依賴管理器可供選擇：CocoaPods、Carthage 和 Swift Package Manager。

到目前為止，最具統治力和最強大的是[CocoaPods](https://cocoapods.org/)。我是本著 Ruby [Bundler gem](https://bundler.io/)的精神構建的，它本身就是一個 Ruby gem。它的工作方式是安裝 gem，`Podfile`在專案的根目錄中建立，宣告要使用的 pod（庫），然後執行`pod install`. 而已。

使用[Carthage](https://github.com/Carthage/Carthage)，您可以建立一個名為的依賴宣告檔案，`Cartfile`但與 Cocoapods 不同的是，您需要進行 Xcode 專案設定才能使其工作。

[Swift Package Manager](https://swift.org/package-manager/)是任何 Swift 專案依賴管理的未來，但它只支援庫和框架，不能用於生成 iOS 目標，儘管 iOS 目標可以依賴於 SPM 構建的模組。

**注意點：**

每個 iOS 開發人員都應該瞭解為什麼將第三方庫複製貼上到您的程式碼庫中會導致維護噩夢，因為多個庫可能依賴於另一個庫的兩個不同版本，從而導致不匹配以及編譯和執行時問題。

*這個問題的進一步閱讀：*

*   [Cocoapods (cocoapods.org)](https://cocoapods.org/)
*   [迦太基 (github.com/Carthage)](https://github.com/Carthage/Carthage)
*   [Swift 包管理器 (swift.org)](https://swift.org/package-manager/)

## 17.你如何在 iOS 上除錯和分析程式碼？

沒有人會寫出完美的程式碼，開發人員需要除錯他們的程式碼並分析應用程式的效能和記憶體洩漏。

**預期答案：**

在 iOS 應用程式中 總是有`NSLog`ging 和`print`ing。您可以使用 Xcode 設定斷點。對於單個程式碼段的效能，您可以使用 XCTest 的 measureBlock。

您可以使用`Instruments`. Instruments 是一種分析工具，可幫助您分析應用程式並在執行時查詢記憶體洩漏和效能問題。

*這個問題的進一步閱讀：*

*   [Instruments Overview (help.apple.com)](https://help.apple.com/instruments/mac/current/#/dev7b09c84f5)

## 18.你有TDD經驗嗎？你如何在 iOS 上進行單元和 UI 測試？

儘管從歷史上看，iOS 社群在 TDD 上並不大，但由於工具的改進和其他社群（例如很久以前接受 TDD 的 Ruby）的影響，它現在變得越來越流行。

**預期答案：**

TDD 是一種技術和學科，您首先編寫失敗的測試，然後再編寫使它們透過的生產程式碼。測試驅動生產程式碼的實現和設計，幫助您只編寫透過測試實現所需的程式碼，不多也不少。該學科起初可能令人生畏，您不會立即看到這種方法的回報，但如果您堅持下去，從長遠來看，它會幫助您更快地前進。它在幫助您進行重構和程式碼更改方面特別有效，因為在任何給定時間，您都有測試的安全網來告訴您是否有問題發生，或者在您更改時一切是否仍然正常。

最近，Apple 對 XCTest 框架進行了改進，使我們的測試更容易。他們還對 Xcode (XCUITest) 中的 UI 測試進行了大量改進，因此現在我們有一個很好的程式設計介面來與我們的應用程式互動並查詢我們在螢幕上看到的內容。或者，您可以使用 KIF、iOSSnapshotTestCase、EarlGrey 等框架。

關於單元測試，也有多種選擇，但最流行的兩個是 XCTest 和 Quick 和 Nimble。

**XCTest**是由 Apple 構建的類似 xUnit 的測試框架。這是他們推薦使用的，它與 Xcode 的整合度最高。

**Quick**是一個類似於 RSpec 的 BDD 框架，可幫助您根據行為而非“測試”來描述規範/測試。RSpec 的粉絲非常喜歡它。

**Nimble**是一個匹配器庫，可與 XCTest 或 Quick 一起使用以斷言您的測試/規範中的期望。

**注意點：**

越來越多的團隊和公司採用 TDD，它已成為 iOS 開發過程中的重要組成部分。如果您不想被拋在後面，請加入它並學習如何測試驅動您的程式碼。

*這個問題的進一步閱讀：*

*   [XCTest (developer.apple.com)](https://developer.apple.com/documentation/xctest)
*   [Quick (github.com)](https://github.com/Quick/Quick)
*   [Nimble (github.com)](https://github.com/Quick/Nimble)
*   [iOSSnapshotTestCase (github.com)](https://github.com/uber/ios-snapshot-test-case)

## 19.mocks、stubs和fakes之間有什麼區別？

隨著測試在 iOS 世界中成為一種更加突出和重要的實踐，在編寫測試時瞭解自己在做什麼很重要。您的測試程式碼與您的應用程式程式碼一樣重要。此問題衡量您對用於輔助單元測試的物件的測試術語的理解。

**預期答案：**

不同的人有多種呼叫和分類測試物件的方式，但最常見的測試物件可以按以下方式分類：mocks、stubs和fakes。

**Fakes**是任何型別的 mock、fake、stub、double 等的通用總稱。就其本身而言，它們通常沒有實現，僅滿足它們所替代的型別的介面 API 要求。

**stubs**是假的，它做了一些有意義的工作，這些工作是測試中涉及的物件執行所必需的，但除此之外沒有其他用途。它們不能代替真實的生產物件，但可以返回存根值。他們不能斷言。

**mocks**是可以判定真假。Mocks 被用來代替其他物件，就像假的一樣，但它們本身記錄了一些資料，例如方法呼叫的數量或傳遞給測試的變數數量，以便稍後進行斷言。

**注意點：**

許多開發人員錯誤地將任何測試物件稱為mocks，但是測試物件有一個特定的不同命名法，指示每個測試物件的目的。作為一名高階開發人員，您不僅要編寫測試，還應該知道如何維護它們以及您的應用程式程式碼庫。

*這個問題的進一步閱讀：*

*   [Overview of Mocks, Stubs, and Fakes (insideiosdev.com)](https://insideiosdev.com/episodes/overview-of-mocks-stubs-fakes)
*   [Test Doubles — Fakes, Mocks and Stubs (blog.pragmatists.com)](https://blog.pragmatists.com/test-doubles-fakes-mocks-and-stubs-1a7491dfa3da)

## 20.您是否進行Code review或者Pair programming？

儘管有很多應用程式是由單獨的開發人員構建的，但應用程式的複雜性不斷增加，需要一個開發人員團隊來開發。在團隊中工作在程式碼維護、協作和知識共享方面帶來了不同的挑戰。

**預期答案：**

**Pair programming**是一種實踐，其中兩個開發人員在同一臺機器上一起處理相同的任務（希望不要共享相同的螢幕和鍵盤並擁有兩套自己的）。目標是在生成程式碼的地方促進協作、討論、程式碼審查和 QA。這個過程使知識轉移和架構討論成為日常事務，防止人們孤立併成為程式碼特定部分的“專家”（當那個人離開或生病時會發生什麼？）。它還提高了程式碼質量，因為在編寫程式碼時，有兩組眼睛在檢視程式碼。這個過程同時發生在兩個開發者身上，有時被稱為同步。

結對程式設計並不適合所有人，如果人們的個性不匹配，則可能是一個令人筋疲力盡的過程。儘管如此，它仍然是軟體開發中最有效的協作技術之一。

**Code review**是一個類似的協作和知識轉移過程，但與結對程式設計不同，它不會同時發生，因此是非同步的。透過程式碼審查，在開發人員編寫一段程式碼或功能後，團隊中的其他人會檢視它。審閱者檢查程式碼是否有意義並建議進行更改和重構以改進它。這開啟了關於程式碼的線上或離線討論，這很棒。這會將有關該程式碼段的知識傳遞給其他團隊成員，並有助於儘早發現錯誤和設計異味。

程式碼審查是一種參與較少的協作型別，它實現的結果與結對程式設計的結果大致相同。這也是一種同理心的練習，您可以向他人提供有關他們工作的反饋。

*這個問題的進一步閱讀：*

*   [Tuple’s Pair Programming Guide (tuple.app)](https://tuple.app/pair-programming-guide/)

## 21.什麼是 FRP（Functional Reactive Programming）及其在 iOS 平臺中的地位？

函式式反應式程式設計 (FRP) 是 iOS/Swift、JavaScript 和其他開發社群的新熱點。除了它實際上不是那麼新。期待這個關於 Swift 特性的問題，或者作為一個更大的架構和概念討論問題。

**預期答案：**

函式式反應式程式設計 (FRP) 是一種宣告式程式設計正規化，它結合了函數語言程式設計和反應式（非同步資料流程式設計）正規化。它是一種宣告式程式設計風格，您可以在其中宣告您的程式碼做什麼，而不是說明它是如何做的。FRP 的反應式元件允許我們引入和描述時間的概念，這在純函數語言程式設計中很難使用。FRP 幫助我們處理使用者輸入和 iOS 應用程式的一般非同步特性；使用者輸入發生在某個時間點，網路將在未來某個時間完成，等等。

FP 和 FRP 依賴於 map、reduce 和 filter 等高階函式，它們以函式為引數並返回其他函式，這使得它們具有高度的可組合性。

Swift 沒有對 FRP 的原生支援，但是有兩個優秀的庫實現了函式式響應式程式設計概念並使我們可以輕鬆使用它們：ReactiveCocoa 和 RxSwift。

在 iOS 13 中，Apple 還宣佈了一個內建於 iOS 中的新 FRP 框架，名為 Combine。Combine 實際上是一個類似於 RxSwift 的 FRP 框架實現。它有兩個優點：它與 SwiftUI 整合，允許將 UI 元素繫結到資料更改，並且它是 Apple 內建和支援的。缺點是：它不如 RxSwift 成熟，而且 Apple 對其進行更改和新增的速度會很慢。

**注意點：**

FRP 在 iOS 應用程式中變得越來越普遍，並且隨著 Apple 對這種程式設計正規化的官方支援和 Combine 的支援，FRP 將被更多地使用。iOS 開發人員應該開始接受它。

*這個問題的進一步閱讀：*

*   [ReactiveX (reactivex.io)](http://reactivex.io/)
*   [結合（developer.apple.com）](https://developer.apple.com/documentation/combine/)
*   [ReactiveCocoa (github.com)](https://github.com/ReactiveCocoa/ReactiveCocoa)

## 22.你知道哪些 iOS 架構有這麼大的規模？

這個問題可能會在面試一家擁有龐大 iOS 開發團隊的大公司時被問到。iOS 應用程式變得越來越複雜，MVC 設計模式不能很好地支援大規模應用程式架構。對於老年人、主管、架構師等來說，這是一個非常高階的問題。

**預期答案：**

MVC、MVVM、MVP 和類似的設計模式都很棒，而且每一種都是彼此的改進，但對於超過 10 或 20 人的團隊，它們仍然不能很好地擴充套件。如果您超出了該團隊規模，則需要使用更通用和可擴充套件的架構方法。有這樣一種概念方法，稱為清潔架構。

Clean Architecture 是一個概念性的規模應用架構，可以簡單地描述為“洋蔥分層架構”。主要思想是使依賴項向內指向域邏輯和域模型，並保持其他所有內容可插入和可選（儲存資料、呈現 ui、接收或傳送網路請求的方式等）。對於 100 多名開發人員的大型團隊，這種架構的擴充套件性特別好。

在 iOS 上有兩個具體的 Clean Architecture 實現：VIPER 和 RIBs。

**毒蛇**代表檢視、互動器、演示者、實體和路由器。這些是該架構的構建塊。在這種架構中，一切都以路由器開始，以檢視結束。每個 VIPER 堆疊（意味著一組檢視、互動器、展示器、實體和路由器）是應用程式的一個螢幕或一個邏輯 UI 部分。要導航和使用 VIPER 堆疊，您需要例項化它的路由器，然後要求它建立它的檢視控制器。路由器建立一個檢視控制器、一個相應的表示器，用於為檢視格式化資料並接收檢視的使用者輸入，一個包含業務邏輯並與演示器通訊的互動器，以及互動器工作所需的實體。然後VC擁有Presenter，Presenter擁有interactor，interactor擁有實體和路由器。生成的檢視控制器在您的檢視層次結構中使用，並根據需要插入、推送或呈現。由於您的應用程式的每個部分現在都是一個 VIPER 堆疊，因此該架構允許針對團隊規模進行強大的邏輯封裝和可擴充套件性。

**RIBs**代表路由器、互動器、構建器。RIBs 是 Clean Architecture 的另一種實現，它是對 VIPER 的改進。在 RIB 體系結構中，主要構建塊是一個 RIB，一組一個路由器、一個互動器和一個帶有可選檢視和展示器的構建器。沒有檢視的 RIB 稱為無頭 RIB。就像在 VIPER 架構中一樣，您使用路由器從一個 RIB 路由到另一個 RIB，並將您的應用程式的整個執行時構建為具有父級和子級 RIB 的樹結構。由於檢視是可選的，與 VIPER 不同，您的應用程式樹結構可能會也可能不會模仿您的檢視層次結構。

Builder 負責為互動器、路由器以及組裝和初始化它們的檢視/展示器獲取或建立依賴項。

路由器負責導航到特定的子 RIB。

Interactor 負責所有業務邏輯並使用路由器啟動路由。

Presenter 和檢視通常組合在一個檢視控制器中，其中 Presenter 負責對資料進行查詢和格式化以在檢視中顯示。

View負責在螢幕上顯示資料並收集使用者輸入。

*這個問題的進一步閱讀：*

*   [Architecting iOS Apps with VIPER (objc.io)](https://www.objc.io/issues/13-architecture/viper/)
*   [RIBs (github.com)](https://github.com/uber/RIBs)

## 結論

這篇文章中涵蓋的問題涉及 iOS 開發人員應該瞭解的廣泛主題。這絕不是一個全面的清單。這些問題基於[《iOS 面試指南](https://iosinterviewguide.com/?ref=ios-interview-questions-for-senior-devs-2020)》一書所做的研究。

> 如果你正在跳槽或者正準備跳槽不妨動動小手，新增一下我們們的交流群[**1012951431**](https://links.jianshu.com/go?to=https%3A%2F%2Fjq.qq.com%2F%3F_wv%3D1027%26k%3D5JFjujE)來獲取一份詳細的大廠面試資料為你的跳槽多添一份保障。

## **文末推薦：iOS熱門文集**

*   **①　[BAT等各個大廠iOS面試真題+答案大全](https://github.com/iOS-Mayday/heji)**

*   **②　[iOS中高階開發必看的熱門書籍（經典必看）](https://github.com/iOS-Mayday/iOSAdvanced-Roadmap)**

*   **③　[iOS開發高階面試"簡歷製作"指導](https://github.com/iOS-Mayday/Interview-questions-iOS)**
*   **④　[iOS面試流程到基礎知識大全](https://github.com/iOS-Mayday/iOS-Interview-Strategy)**

2021- iOS開發者一份你一定會被問到的面試題（附參考答案）

相關文章