一些常見的iOS面試問題， 一眼就能看出iOS初級和進階工程師的區別

標籤：工作經驗   為什麼   成員變數   面試問題   機制   實現   不能   引入   一個人   

前言

面試題中有一些一般性的問題，通常是會問到的。面試iOS應聘者時，切入點很重要，不同的切入點會導致不同的結果，沒有找到合適的切入點也無法對應聘者有一個全面的瞭解。所以下面的面試問題更多的是提供方向，沒有固定的答案，而且可以根據應聘者的回應引出更多有意思深層次的討論。

 

注意：以下問題的參考答案均為筆者所答，不代表正確，問題答案因人而異，請根據自己的實際情況回答，若認為不合理，請在評論中指出。下面所有的參考答案，都是筆者站在面試官的角度來分析的，不同的面試官也會不一樣。筆者面試過一些人，一問就可以知道對方的底子如何了，雖然如此，不代表參考答案是每個面試官想要的。

 

作為一個開發人員，有一個學習的氛圍跟一個交流圈子特別重要這是一個我的iOS交流群：638302184，不管你是小白還是大牛歡迎入駐 ，分享BAT,阿里面試題、面試經驗，討論技術， 大家一起交流學習成長！

 

1，自我介紹

自我介紹時，一定要簡潔明了，不要長篇大論。以我個人而言，最不喜歡自我介紹說了一大堆，最後連她/他叫什麼名字都沒記住。

參考答案：

自我介紹時，突出重點，說話慢一些，在關鍵點聲音大一點。本人回答時，就簡單地說： 我叫某某某，做iosX年了，曾在XX公司擔任過XX職務，在YY公司擔任過XX職務，主要負責ZZ工作。業餘喜歡做NN（要說積極點的），擅長LL（把自己的特長說明白）等。

 

2，最近這兩天你有學到什麼知識/技能嗎？

對於這個問題，面試官肯定知道作為求職者，這兩天肯定是在忙於找工作、面試。那麼，面試官問出這樣的問題的目的是什嗎？如果我是面試官，我最想瞭解的是這兩天你為此次面試準備了什麼而不僅僅是告訴面試官這兩天學習了某一方面的知識。

參考答案：

這兩天為了準備面試，整理了以前所做過的一些項目的筆記，回頭看了看以前的工作日誌。一來是整理一些在工作中經常遇到的坑，比如cell重用問題、ios6適配問題等；二來是回頭告別過去的自己，在思想上、技術上迎來全新的自我；三來定位自己下一個目標：往架構師方向深入研究。

 

3，最近有做過比較酷或者比較有挑戰的項目嗎？

這個問題的關鍵是酷和挑戰。其實這裡所說的酷對應於開發中的動畫，而挑戰則對應於開發中的衝刺。對於筆者而言，其實並沒有做過特別酷的項目，但是做過有挑戰性的項目。但是沒有做過並不是就不用回答，面試官想看到的是你的學習能力、應用能力以及解決問題的能力，而不是一句沒做過或者沒什麼挑戰性這樣的話語。

參考答案：

我之前所負責的項目大多是電商項目，因此並不會特別酷，但是業務比較多，很有技術挑戰性。不過，平時我也深入研究過ios核心動畫相關知識，對於常用的動畫是很熟悉的。在我看來，使用者體驗並不是所謂的酷，而是簡單、方便且明了。我很在意使用者體驗問題，在開發中會不斷地站在使用者的角度地問自己使用者討厭什麼、喜歡什麼和怎樣才能讓使用者感覺容易上手且使用簡單等問題。比如，我會很在意網路狀態的變化給使用者的提示、請求網路時右上方的轉圈圈是否開啟、滾動cell時是否有卡頓的問題等。

 

我待過幾家公司，從一個人開發到帶領團隊，從小公司到大公司，因此對於不同的公司對項目的要求完全不一樣。對於大公司，一般專案管理機制相對比較完善，而且會有比較多經驗豐富的技術VP，因此對於工作的要求比較高，對於使用者的體驗及反饋會非常地關注；而對於一些小公司，可能就一個人在開發，而這個人往往是菜鳥的多，因此都是東拼西湊而形成的項目，技術不成熟、水平不夠，而且還被壓著不斷加班，因此幾乎不會過多關注使用者體驗問題，當然這樣項目也不會有什麼好的構架（初創技術合伙人除外）。

現在我所在的公司不算大，也就1000+號人，而做ios也才40號人左右。本公司是按業務方向劃分成多個團隊，不同團隊開發不同的業務需求，因此這樣就面臨技術架構問題、安全問題、團隊開發如何做到互不干擾等問題了。而我在團隊中的主要職責是處理團隊之間衝突的問題、如何代碼模組化以減少團隊之外的依賴問題、移動端安全通訊問題、項目儲存安全問題、公用架構等問題，這一系列都是非常有技術挑戰的，需要花費很多非工作時間去調研、寫demo、寫文檔等。

 

4，最近看過的書/文章有哪些？

詢問最近看過的書或者文章，其實通過所回答的書的性質差不多就可以猜出目前狀態下應聘者的技術水平大致處於什麼樣的水準了。

參考答案：

最近在看《iOS應用逆向工程》、《The Swift Programming Language》。不過本人更喜歡的是閱讀部落格文章和官方文檔，雖然官方文檔是英文的，閱讀起來相對要費勁一些，但是一方面可以提高英文閱讀能力，另一方面英文原版表達的語義才是最準確的，其他翻譯過來的文章會有一些變味之處。

 

5，為什麼要學習編程，編程對你而言的樂趣在哪兒？

這樣的話題在很多社區都出現過，其實問這樣的問題只是想知道應聘者的態度而已。通過應聘者的回答，一方面可初步瞭解應聘者對編程的認知程度，另一方面可從應聘者口出得出編程對於應聘者而言是什麼樣的態度。

參考答案：

說到這個問題，我曾經也問過自己為什麼要學習編程。回想當年高考結果出來的時候，需要選擇學校和專業的時候是很迷茫的，不知上大學應該學點什麼。後來，我選擇了電腦科學與技術專業，並為了這個專業而選擇學校。由於高考考得不好，雖然超過一本線，但是高不成低不就，很多高校的電腦專業要求總分達到560（當時一本線是502分）左右才能穩拿到這個專業，而我才考了526分，想想電腦專業很強的高校是很難進的。於是選擇了從廣西到瀋陽這麼遙遠的地方上學，竟然是為了電腦專業，現在回想起來還自己偷笑。

 

在大學的時候，大一天天在圖書館提前學習編程，因為動手能力突出，到大二的時候有好多教電腦的老師提前知道了這樣的我，感謝他們的認可，在大學這幾年，是他們引導我如何編程實戰。大學的時候做過很多PC端的軟體（.net開發的）、給老師做過教程網站（ASP.net開發的）、參加學習的ACM訓練等等，一切的一切，都要感謝那些教導我的恩師們。

後來通過學長瞭解到未來就業的一些動向，瞭解到畢業後如何找工作，學習了iOS開發，於是越來越愛她了。如果非要說編程的樂趣在哪裡，我想說在討論技術的時候就像和同學、朋友一起玩LOL的時候；在解決掉一個別人解決不了的bug的時候，那是一種想要向全世界大聲說：YES,I Can；當我們與技術總監並肩作戰，一起為了項目上線熬夜，總監為我們買夜宵一起吃的時候，那就是兄弟情誼，那會有種相見恨晚的感覺。

 

6，如果一個函數10次中有7次正確，3次錯誤，問題可能出現在哪裡？

這樣的問題通過應聘者的分析，可以知道應聘者的功底如何。很多人的回答會是很簡單的，沒有從多方面去分析。這樣的問題也是很有意義的，在項目開發中所產生的bug，有的時候會出現這樣的情況，而代碼量比較大且業務比較複雜時，通過其他工具並不能分析出來是什麼bug，但是我們卻可以根據出現的頻率推測。筆者把這個問題當作測試部反饋過來的bug描述問題來分析一下。

參考答案：

從問題描述可知，bug不會必現的，因此無法直接定位出錯之處。從以下角度出現來分析可能出錯之處：

因出錯並不是崩潰，因此沒有錯誤記錄檔可看。第一步就是分析函數中的所有分支，是否在文法上存在可能缺少條件的問題。所以，檢查所有的分支，確保每個分支執行的結果的正確的

檢測函數的參數，保證必傳參數不可為空，若為空白應該拋出異常。因此，用斷言檢測參數的正確性是很重要的。

檢測函數中每個分支所調用的函數返回結果是正確的，其實就是一個遞迴的過程（步驟1、2）

 

7，自身最大優點是什麼，怎麼證明？

人最大的敵人不是別人，而是自己。戰勝自己，才是最大的勝利。很多人不清楚自己的優點是什麼，甚至很多朋友喜歡說我最大的優點是沒有缺點。如果是對面試官說這一句話，那麼你可能被pass掉了。

參考答案：

我也不清楚我最大的優點是什麼，但是我知道我有很多優點。

我學習能力特彆強，接受新事物的能力也特彆強。比如，我在工作之餘還會去學習swift、PHP、js等。

我喜歡寫部落格、寫總結、分享技術、協助他人等。我覺得寫部落格的過程，既讓自己對相關知識有更深刻的認識，更是協助到他人。每做一期需求，我都會寫一份總結，記錄那些坑。在公司每個季度都會做幾次技術分享，帶動團隊的技術氛圍。我也喜歡協助他人，我建立了自己的技術群，短短兩個月群就滿1000人了，在群裡通過回答大家問題，也讓我瞭解到很多知識。

我支援開源、喜歡開源。

 

我開發過多款App，解決問題的能力很強。在團隊中充當技術主心骨，任何隊員解決不好的問題，我都會協助一起解決掉。

我對技術構架、團隊如何解藕方面都有所研究。在團隊開發中，因為經常面臨團隊開發存在交差的問題，導致需求變動引起很多問題，因此研究過如何讓團隊之間減少依賴的問題。

就說這麼多吧！(因為面試進階人員通常會交談3個小時左右，所以儘可能地說吧，不要害怕時間過長)

 

8，你最近遇到過的一個技術挑戰是什嗎？怎麼解決的？

通過應聘者回答所遇到過的技術挑戰，其實從側面就可以看出這個人的水平如何了。如果回答的技術挑戰是個簡單的問題，而在應聘者這裡卻是技術挑戰，那麼就可以知道這水平是初級的。然後應聘者針對這個技術挑戰所給出的解決方案也可以看出面對技術挑戰，可以看出應聘者處理問題的能力。

參考答案：

最近公司項目中的使用者帳號出現被盜現象，原因是通訊安全問題處理不好。因為公司的項目已經是好幾年的老項目了，包括服務端的介面好多是老介面，原來是沒有處理任何加密的，因此很容易被盜取帳號。現在我們的技術VP要求針對這個問題，做一個版本。因為主動接受挑戰，所以這個重任落在了我的身上，由我來牽頭做好這個需求。

這真的是一個很有挑戰性的技術項目。步驟如下：

需要調研市場上比較有名的App，他們是如何做好安全通訊問題的；

寫好技術文檔，將調研結果反饋出來並寫出自己的技術方案；

開初步技術方案評審會，會有VP及各組Leader參與，會上會提出各種問題，並給予一一解答，然後做會議記錄，會後繼續完善文檔；

開跨部分評審會，只有所有都通過了，才能立項。

技術立項，然後寫好各方向所需要做的工作文檔。

為什麼要這麼麻煩？因為我們既要相容以前的所有版本，又要保證技術安全，那就不會自己就能說了算的，而且也不僅僅是用戶端的問題。

 

9，開發常用的工具有哪些？

通過回答這個問題，一方面可以看出這個應聘者在iOS開發領域的深入程度。如果只知道Xcode和Cocoapods，說明是初級或者根本不願意在業餘時間花費精力去擴充。

參考答案：

常用的iOS開發工具有：

Xcode開發工具及配套的Instruments工具

Xcode常用的外掛程式

Cocoapods第三方庫管理依賴工具

SourceTree是git版本管理工具

CornerStone是SVN版本管理工具

友盟統計BUG日誌分析工具

 

10，熟悉CocoaPods嗎？能大概講一下工作原理嗎？

這個問題不會回答也沒有關係，因為很多老項目是不使用CocoaPods的，因此不一定會瞭解。 回答說使用過Cocoapods寫過demo，但是不太懂工作原理是沒有關係的。因為在我看到這個問題之前，我也沒有深入瞭解過其工作原理，只是熟悉如何使用而已。

參考答案：

閱讀關於Cocoapods第三方庫管理依賴工具如何使用

關於其原理，大家百度一下或者Google一下吧！因為筆者對其工作原理也不會很清楚，只知道它會為我們建立一個工作區間，然後將所有在cocoapods中的引入的第三方庫以libPods.a這樣的方式引入到我們的工程中，這樣就可以直接存取第三方庫了。但是，更具體的細節就不瞭解了，大家想要深入瞭解的話， 還得找Google或者百度。

 

11，最常用的版本控制工具是什麼，能大概講講原理嗎？

關於這個版本控制工具的工作原理，其實也就是對這此命令的操作而已。

參考答案：

最常用的版本控制工具有SourceTree（GIT）和CornerStone（SVN）：

SourceTree是git版本管理工具

CornerStone是SVN版本管理工具

 

12，今年你最想掌握的一門技術是什嗎？為什嗎？目前已經做到了哪個程度？

既然是技術，那麼就要說明是什麼技術，至於為什麼想要掌握，當然是想要在技術上更上一層樓。

參考答案：

我現在一直在研究runtime相關知識。掌握runtime相關技術，可以做很多正常狀態下做不到的事、可以讓做一些自動化處理工作、解決代碼依賴問題等。目前已經對runtime中的成員變數、屬性、訊息轉寄、Swizzling等可以熟練使用。關於runtime專題，大家可以閱讀我的部落格專題：iOS Runtime相關知識點

 

13，你一般是怎麼用Instruments的？

這個就是工作經驗的問題了。Instruments工具裡面有很多個選項，沒有必要每個都答，

參考答案：

使用Allocations來檢測記憶體和堆棧資訊

使用Leaks檢測記憶體的使用方式，包括記憶體泄露問題

使用Zombies來檢測過早釋放的殭屍對象，通過它可以檢測出在哪裡崩潰的。

使用Time Profiler來檢測CPU記憶體使用量情況

 

14，你一般是如何調試Bug的？

這個問題看起來很籠統，但又一針見血。通過應聘者的回答，可很直觀地看出這個應聘者的處理bug的能力，以及其解決問題的思維。

參考答案：

Bug分為測試中的Bug和線上的Bug：

線上Bug：項目使用了友盟統計，因此會有崩潰日誌，通過解析dYSM可以直接定位到大部分bug崩潰之處。解決線上bug需要從主幹拉一個新的分支，解決bug並測試通過後，再合并到主幹，然後上線。若是多團隊開發，可以將fix bug分支與其他團隊最近要上線的分支整合，然後整合測試再上線。

測試Bug：根據測試所反饋的bug描述，若語義不清晰，則直接找到提bug人，操作給開發人員看，最好是可以bug複現。解決bug時，若能根據描述直接定位bug出錯之處，則好處理；若無法直觀定位，則根據bug類型分幾種處理方式，比如崩潰的bug可以通過instruments來檢測、資料顯示錯誤的bug，則需要閱讀代碼一步步查看邏輯哪裡寫錯。

對於開發中出現的崩潰或者資料顯示不正常，那就需要根據經驗或者相關工具來檢測可能出錯之處。當然，團隊內溝通解決是最好的。

 

15，你在你的項目中用到了哪些設計模式？

項目中使用了很多的設計模式，我相信面試官最好聽到的不僅僅是設計模式的名字，更想聽到的是這些設計模式在項目中如何應用。因此，筆者認為這個問題隱式地說明了應該回答設計模式及其在項目中的應用。

參考答案：

單例設計模式：在項目中，單例是必不可少的。比如UIApplication、NSUserDefaults就是蘋果提供的單例。在項目中經常會將使用者資料管理封裝成一個單例類，因此使用者的資訊需要全域使用。

MVC設計模式：現在絕大部分項目都是基於MVC設計模式的，現在有一部分開發人員採用MVVM、MVP等模式。

通知(NSNotification)模式：通知在開發中是必不可少的，對於跨模組的類互動，需要使用通知；對於多對多的關係，使用通知更好實現。

工廠設計模式：在我的項目中使用了大量的工廠設計模式，特別是產生控制項的API，都已經封裝成一套，全部是擴充的類方法，可簡化很多的代碼。

KVC/KVO設計模式：有的時候需要監聽某個類的屬性值的變化而做出相應的改變，這時候會使用KVC/KVO設計模式。在項目中，我需要監聽model中的某個屬性值的變化，當變化時，需要更新UI顯示，這時候使用KVC/KVO設計模式就很方便了。

就說這麼多吧，還有很多的設計模式，不過其它並不是那麼常用。

 

16，如何?單例，單例會有什麼弊端？

單例在項目中的是必不可少的，它可以使我們全域都可共用我們的資料。這隻是簡單的問題，大家根據自己的情況回答。

參考答案：

首先，單例寫法有好幾種，通常的寫法是基於安全執行緒的寫法，結合dispatch_once來使用，保證單例對象只會被建立一次。如果不小心銷毀了單例，再調用單例產生方法是不會再建立的。

其次，由於單例是約定俗成的，因此在實際開發中通常不會去重寫記憶體管理方法。

單例確實給我們帶來的便利，但是它也會有代價的。單例一旦建立，整個App使用過程都不會釋放，這會佔用記憶體，因此不可濫用單例。

 

17，iOS是如何管理記憶體的？

我相信很多人的回答是記憶體管理的黃金法則，其實如果我是面試官，我想要的答案不是這樣的。我希望的回答是工作中如何處理記憶體管理的。

參考答案：

Block記憶體管理：由於使用block很容易造成循環參考，因此一定要小心記憶體管理問題。最好在基類controller下重寫dealloc，加一句列印日誌，表示類可以得到釋放。如果出現無列印資訊，說明這個類一直得不到釋放，表明很有可能是使用block的地方出現循環參考了。對於block中需要引用外部controller的屬性或者成員變數時，一定要使用弱引用，特別是成員變數像_testId這樣的，很多人都沒有使用弱引用，導致記憶體得不到釋放。

對於普通所建立的對象，因為現在都是ARC項目，所以記住記憶體管理的黃金法則就可以解決。

 

18，使用過哪些第三方庫？

開發過App，如果回答說沒有使用過第三方庫，那麼這個人一定是剛入門。如果回答者能夠說出很多有名的第三方庫，並且能說明使用情境，那麼可以突出這個面試者的知識面還是很廣的，這是可以加分的。

學如逆水行舟，不進則退，希望你閱讀本文後對你有一定的收貨。

作為一個開發人員，有一個學習的氛圍跟一個交流圈子特別重要這是一個我的iOS交流群：638302184，不管你是小白還是大牛歡迎入駐 ，分享BAT,阿里面試題、面試經驗，討論技術， 大家一起交流學習成長！

 

 

文章來源於網路，如有侵權，請聯絡小編刪除。

一些常見的iOS面試問題， 一眼就能看出iOS初級和進階工程師的區別