- 相關推薦
ios面試常見問題
面試題中有一些一般性的問題，通常是會問到的。面試iOS應聘者時，切入點很重要，不同的切入點會導致不同的結(jié)果，沒有找到合適的切入點也無法對應聘者有一個全面的了解。以下是ios面試常見問題，歡迎閱讀。
注意：以下問題的參考答案均為參考，不代表正確，問題答案因人而異，請根據(jù)自己的實際情況回答，若認為不合理，請在評論中指出。下面所有的參考答案，都是筆者站在面試官的角度來分析的，不同的面試官也會不一樣。筆者面試過一些人，一問就可以知道對方的底子如何了，雖然如此，不代表參考答案是每個面試官想要的。
自我介紹
自我介紹時，一定要簡潔明了，不要長篇大論。以我個人而言，最不喜歡自我介紹說了一大堆，最后連她/他叫什么名字都沒記住。
參考答案：
自我介紹時，突出重點，說話慢一些，在關鍵點聲音大一點。本人回答時，就簡單地說： 我叫某某某，做iosX年了，曾在XX公司擔任過XX職務，在YY公司擔任過XX職務，主要負責ZZ工作。業(yè)余喜歡做NN（要說積極點的），擅長LL（把自己的特長說明白）等。
最近這兩天你有學到什么知識/技能么？
對于這個問題，面試官肯定知道作為求職者，這兩天肯定是在忙于找工作、面試。那么，面試官問出這樣的問題的目的是什么？如果我是面試官，我最想了解的是這兩天你為此次面試準備了什么而不僅僅是告訴面試官這兩天學習了某一方面的知識。
參考答案：
這兩天為了準備面試，整理了以前所做過的一些項目的筆記，回頭看了看以前的工作日志。一來是整理一些在工作中經(jīng)常遇到的坑，比如cell重用問題、ios6適配問題等；二來是回頭告別過去的自己，在思想上、技術上迎來全新的自我；三來定位自己下一個目標：往架構師方向深入研究。
最近有做過比較酷或者比較有挑戰(zhàn)的項目么？
這個問題的關鍵是酷和挑戰(zhàn)。其實這里所說的酷對應于開發(fā)中的動畫，而挑戰(zhàn)則對應于開發(fā)中的沖刺。對于筆者而言，其實并沒有做過特別酷的項目，但是做過有挑戰(zhàn)性的項目。但是沒有做過并不是就不用回答，面試官想看到的是你的學習能力、應用能力以及解決問題的能力，而不是一句沒做過或者沒什么挑戰(zhàn)性這樣的話語。
參考答案：
我之前所負責的項目大多是電商項目，因此并不會特別酷，但是業(yè)務比較多，很有技術挑戰(zhàn)性。不過，平時我也深入研究過ios核心動畫相關知識，對于常用的動畫是很熟悉的。在我看來，用戶體驗并不是所謂的酷，而是簡單、方便且明了。我很在意用戶體驗問題，在開發(fā)中會不斷地站在用戶的角度地問自己用戶討厭什么、喜歡什么和怎樣才能讓用戶感覺容易上手且使用簡單等問題。比如，我會很在意網(wǎng)絡狀態(tài)的變化給用戶的提示、請求網(wǎng)絡時右上角的轉(zhuǎn)圈圈是否開啟、滾動cell時是否有卡頓的問題等。
我待過幾家公司，從一個人開發(fā)到帶領團隊，從小公司到大公司，因此對于不同的公司對項目的要求完全不一樣。對于大公司，一般項目管理機制相對比較完善，而且會有比較多經(jīng)驗豐富的技術VP，因此對于工作的要求比較高，對于用戶的體驗及反饋會非常地關注；而對于一些小公司，可能就一個人在開發(fā)，而這個人往往是菜鳥的多，因此都是東拼西湊而形成的項目，技術不成熟、水平不夠，而且還被壓著不斷加班，因此幾乎不會過多關注用戶體驗問題，當然這樣項目也不會有什么好的構架（初創(chuàng)技術合伙人除外）。
現(xiàn)在我所在的公司不算大，也就1000+號人，而做ios也才40號人左右。本公司是按業(yè)務方向劃分成多個團隊，不同團隊開發(fā)不同的業(yè)務需求，因此這樣就面臨技術架構問題、安全問題、團隊開發(fā)如何做到互不干擾等問題了。而我在團隊中的主要職責是處理團隊之間沖突的問題、如何代碼模塊化以減少團隊之外的依賴問題、移動端安全通信問題、項目存儲安全問題、公共框架等問題，這一系列都是非常有技術挑戰(zhàn)的，需要花費很多非工作時間去調(diào)研、寫demo、寫文檔等。
最近看過的書/文章有哪些？
詢問最近看過的書或者文章，其實通過所回答的書的性質(zhì)差不多就可以猜出當前狀態(tài)下應聘者的技術水平大致處于什么樣的水準了。下面的參考答案是筆者的常態(tài)。
參考答案：
最近在看《iOS應用逆向工程》、《The Swift Programming Language》。不過本人更喜歡的是閱讀博客文章和官方文檔，雖然官方文檔是英文的，閱讀起來相對要費勁一些，但是一方面可以提高英文閱讀能力，另一方面英文原版表達的語義才是最準確的，其他翻譯過來的文章會有一些變味之處。
為什么要學習編程，編程對你而言的樂趣在哪兒？
這樣的話題在很多社區(qū)都出現(xiàn)過，其實問這樣的問題只是想知道應聘者的態(tài)度而已。通過應聘者的回答，一方面可初步了解應聘者對編程的認知程度，另一方面可從應聘者口出得出編程對于應聘者而言是什么樣的態(tài)度。下面是結(jié)合筆者的事跡寫下的參考答案，僅供參考。
參考答案：
說到這個問題，我曾經(jīng)也問過自己為什么要學習編程�；叵氘斈旮呖冀Y(jié)果出來的時候，需要選擇學校和專業(yè)的時候是很迷茫的，不知上大學應該學點什么。后來，我選擇了計算機科學與技術專業(yè)，并為了這個專業(yè)而選擇學校。由于高考考得不好，雖然超過一本線，但是高不成低不就，很多高校的計算機專業(yè)要求總分達到560（當時一本線是502分）左右才能穩(wěn)拿到這個專業(yè)，而我才考了526分，想想計算機專業(yè)很強的高校是很難進的。于是選擇了從廣西到沈陽這么遙遠的地方上學，竟然是為了計算機專業(yè)，現(xiàn)在回想起來還自己偷笑。
在大學的時候，大一天天在圖書館提前學習編程，因為動手能力突出，到大二的時候有好多教計算機的老師提前知道了這樣的我，感謝他們的認可，在大學這幾年，是他們引導我如何編程實戰(zhàn)。大學的時候做過很多PC端的軟件（.net開發(fā)的）、給老師做過教程網(wǎng)站（ASP.net開發(fā)的）、參加學習的ACM訓練等等，一切的一切，都要感謝那些教導我的恩師們。
后來通過學長了解到未來就業(yè)的一些動向，了解到畢業(yè)后如何找工作，學習了iOS開發(fā)，于是越來越愛她了。如果非要說編程的樂趣在哪里，我想說在討論技術的時候就像和同學、朋友一起玩LOL的時候；在解決掉一個別人解決不了的bug的時候，那是一種想要向全世界大聲說：YES,I Can；當我們與技術總監(jiān)并肩作戰(zhàn)，一起為了項目上線熬夜，總監(jiān)為我們買夜宵一起吃的時候，那就是兄弟情誼，那會有種相見恨晚的感覺。
如果一個函數(shù)10次中有7次正確，3次錯誤，問題可能出現(xiàn)在哪里？
這樣的問題通過應聘者的分析，可以知道應聘者的功底如何。很多人的回答會是很簡單的，沒有從多方面去分析。這樣的問題也是很有意義的，在項目開發(fā)中所產(chǎn)生的bug，有的時候會出現(xiàn)這樣的情況，而代碼量比較大且業(yè)務比較復雜時，通過其他工具并不能分析出來是什么bug，但是我們卻可以根據(jù)出現(xiàn)的頻率推測。筆者把這個問題當作測試部反饋過來的bug描述問題來分析一下。
參考答案：
從問題描述可知，bug不會必現(xiàn)的，因此無法直接定位出錯之處。從以下角度出現(xiàn)來分析可能出錯之處：
因出錯并不是崩潰，因此沒有錯誤日志可看。第一步就是分析函數(shù)中的所有分支，是否在語法上存在可能缺少條件的問題。所以，檢查所有的分支，確保每個分支執(zhí)行的結(jié)果的正確的
檢測函數(shù)的參數(shù)，保證必傳參數(shù)不能為空，若為空應該拋出異常。因此，用斷言檢測參數(shù)的正確性是很重要的。
檢測函數(shù)中每個分支所調(diào)用的函數(shù)返回結(jié)果是正確的，其實就是一個遞歸的過程（步驟1、2）
自身最大優(yōu)點是什么，怎么證明？
人最大的敵人不是別人，而是自己。戰(zhàn)勝自己，才是最大的勝利。很多人不清楚自己的優(yōu)點是什么，甚至很多朋友喜歡說我最大的優(yōu)點是沒有缺點。如果是對面試官說這一句話，那么你可能被pass掉了。
參考答案：
我也不清楚我最大的優(yōu)點是什么，但是我知道我有很多優(yōu)點。
我學習能力特別強，接受新事物的能力也特別強。比如，我在工作之余還會去學習swift、PHP、js等。
我喜歡寫博客、寫總結(jié)、分享技術、幫助他人等。我覺得寫博客的過程，既讓自己對相關知識有更深刻的認識，更是幫助到他人。每做一期需求，我都會寫一份總結(jié)，記錄那些坑。在公司每個季度都會做幾次技術分享，帶動團隊的技術氛圍。我也喜歡幫助他人，我創(chuàng)建了自己的技術群，短短1個月群就滿500人了，在群里通過回答大家問題，也讓我了解到很多知識。筆者有好幾個博客，不過現(xiàn)在自己搭建了個博客，以后會專門維護標哥的技術博客。
我支持開源、喜歡開源。我寫了幾個開源庫，大家若是覺得有價值，請隨手給個star：標哥的GITHUB
我開發(fā)過多款App，解決問題的能力很強。在團隊中充當技術主心骨，任何隊員解決不好的問題，我都會幫助一起解決掉。
我對技術構架、團隊如何解藕方面都有所研究。在團隊開發(fā)中，因為經(jīng)常面臨團隊開發(fā)存在交差的問題，導致需求變動引起很多問題，因此研究過如何讓團隊之間減少依賴的問題。
我活躍于GITHUB、CocoaChina、CSDN等，對于iOS相關技術知識比較熟悉。
就說這么多吧！(因為面試高級人員通常會交談3個小時左右，所以盡可能地說吧，不要害怕時間過長)
有沒有在 GitHub 上發(fā)布過開源代碼，參與過開源項目？
github上的開源項目可以體現(xiàn)應聘者的水平以及對編程的熱愛程度。一個不足夠熱愛編程的人，業(yè)余時間是不會花在編程上的，因此更不會有什么開源項目了。
參考答案：
這里我的開源庫的地址標哥的GitHub，里面除了一些開源庫之外，還有很多的demo，每個demo都有對應的博客文章講解，那都是我感覺學習的成果。
我在GITHUB上發(fā)布過很多開源代碼，也提供了支持cocoapods的開源項目，現(xiàn)在也有不少人在使用，當然我也會一直維護著，不過我并沒有參與過其他人發(fā)起的開源項目。
你最近遇到過的一個技術挑戰(zhàn)是什么？怎么解決的？
通過應聘者回答所遇到過的技術挑戰(zhàn)，其實從側(cè)面就可以看出這個人的水平如何了。如果回答的技術挑戰(zhàn)是個簡單的問題，而在應聘者這里卻是技術挑戰(zhàn)，那么就可以知道這水平是初級的。然后應聘者針對這個技術挑戰(zhàn)所給出的解決方案也可以看出面對技術挑戰(zhàn)，可以看出應聘者處理問題的能力。
參考答案：
最近公司項目中的用戶賬號出現(xiàn)被盜現(xiàn)象，原因是通信安全問題處理不好。因為公司的項目已經(jīng)是好幾年的老項目了，包括服務端的接口好多是老接口，原來是沒有處理任何加密的，因此很容易被盜取賬號�，F(xiàn)在我們的技術VP要求針對這個問題，做一個版本。因為主動接受挑戰(zhàn)，所以這個重任落在了我的身上，由我來牽頭做好這個需求。
這真的是一個很有挑戰(zhàn)性的技術項目。步驟如下：
需要調(diào)研市場上比較有名的App，他們是如何做好安全通信問題的；
寫好技術文檔，將調(diào)研結(jié)果反饋出來并寫出自己的技術方案；
開初步技術方案評審會，會有VP及各組Leader參與，會上會提出各種問題，并給予一一解答，然后做會議記錄，會后繼續(xù)完善文檔；
開跨部分評審會，只有所有都通過了，才能立項。
技術立項，然后寫好各方向所需要做的工作文檔。
為什么要這么麻煩？因為我們既要兼容以前的所有版本，又要保證技術安全，那就不會自己就能說了算的，而且也不僅僅是客戶端的問題。
開發(fā)常用的工具有哪些？
通過回答這個問題，一方面可以看出這個應聘者在iOS開發(fā)領域的深入程度。如果只知道Xcode和Cocoapods，說明是初級或者根本不愿意在業(yè)余時間花費精力去擴展。
參考答案：
常用的iOS開發(fā)工具有：
Xcode開發(fā)工具及配套的Instruments工具
Xcode常用的插件
Cocoapods第三方庫管理依賴工具
SourceTree是git版本管理工具
CornerStone是SVN版本管理工具
友盟統(tǒng)計BUG日志分析工具
熟悉CocoaPods么？能大概講一下工作原理么？
這個問題不會回答也沒有關系，因為很多老項目是不使用CocoaPods的，因此不一定會了解。 回答說使用過Cocoapods寫過demo，但是不太懂工作原理是沒有關系的。因為在我看到這個問題之前，我也沒有深入了解過其工作原理，只是熟悉如何使用而已。
參考答案：
閱讀關于Cocoapods第三方庫管理依賴工具如何使用
關于其原理，大家百度一下或者谷歌一下吧！因為筆者對其工作原理也不會很清楚，只知道它會為我們創(chuàng)建一個工作區(qū)間，然后將所有在cocoapods中的引入的第三方庫以libPods.a這樣的方式引入到我們的工程中，這樣就可以直接訪問第三方庫了。但是，更具體的細節(jié)就不了解了，大家想要深入了解的話， 還得找谷歌或者百度。
最常用的版本控制工具是什么，能大概講講原理么？
關于這個版本控制工具的工作原理，其實也就是對這此命令的操作而已。
參考答案：
最常用的版本控制工具有SourceTree（GIT）和CornerStone（SVN）：
SourceTree是git版本管理工具
CornerStone是SVN版本管理工具
今年你最想掌握的一門技術是什么？為什么？目前已經(jīng)做到了哪個程度？
既然是技術，那么就要說明是什么技術，至于為什么想要掌握，當然是想要在技術上更上一層樓。
參考答案：
我現(xiàn)在一直在研究runtime相關知識。掌握runtime相關技術，可以做很多正常狀態(tài)下做不到的事、可以讓做一些自動化處理工作、解決代碼依賴問題等。目前已經(jīng)對runtime中的成員變量、屬性、消息轉(zhuǎn)發(fā)、Swizzling等可以熟練使用。關于runtime專題，大家可以閱讀我的博客專題：iOS Runtime相關知識點
你一般是怎么用Instruments的？
這個就是工作經(jīng)驗的問題了。Instruments工具里面有很多個選項，沒有必要每個都答，其實筆者也只用過里面的幾個而已。
參考答案：
使用Allocations來檢測內(nèi)存和堆棧信息
使用Leaks檢測內(nèi)存的使用情況，包括內(nèi)存泄露問題
使用Zombies來檢測過早釋放的僵尸對象，通過它可以檢測出在哪里崩潰的。
使用Time Profiler來檢測CPU內(nèi)存使用情況
你一般是如何調(diào)試Bug的？
這個問題看起來很籠統(tǒng)，但又一針見血。通過應聘者的回答，可很直觀地看出這個應聘者的處理bug的能力，以及其解決問題的思維。
參考答案：
Bug分為測試中的Bug和線上的Bug：
線上Bug：項目使用了友盟統(tǒng)計，因此會有崩潰日志，通過解析dYSM可以直接定位到大部分bug崩潰之處。解決線上bug需要從主干拉一個新的分支，解決bug并測試通過后，再合并到主干，然后上線。若是多團隊開發(fā)，可以將fix bug分支與其他團隊最近要上線的分支集成，然后集成測試再上線。
測試Bug：根據(jù)測試所反饋的bug描述，若語義不清晰，則直接找到提bug人，操作給開發(fā)人員看，最好是可以bug復現(xiàn)。解決bug時，若能根據(jù)描述直接定位bug出錯之處，則好處理；若無法直觀定位，則根據(jù)bug類型分幾種處理方式，比如崩潰的bug可以通過instruments來檢測、數(shù)據(jù)顯示錯誤的bug，則需要閱讀代碼一步步查看邏輯哪里寫錯。
對于開發(fā)中出現(xiàn)的崩潰或者數(shù)據(jù)顯示不正常，那就需要根據(jù)經(jīng)驗或者相關工具來檢測可能出錯之處。當然，團隊內(nèi)溝通解決是最好的。
你在你的項目中用到了哪些設計模式？
項目中使用了很多的設計模式，我相信面試官最好聽到的不僅僅是設計模式的名字，更想聽到的是這些設計模式在項目中如何應用。因此，筆者認為這個問題隱式地說明了應該回答設計模式及其在項目中的應用。
參考答案：
單例設計模式：在項目中，單例是必不可少的。比如UIApplication、NSUserDefaults就是蘋果提供的單例。在項目中經(jīng)常會將用戶數(shù)據(jù)管理封裝成一個單例類，因此用戶的信息需要全局使用。
MVC設計模式：現(xiàn)在絕大部分項目都是基于MVC設計模式的，現(xiàn)在有一部分開發(fā)者采用MVVM、MVP等模式。
通知(NSNotification)模式：通知在開發(fā)中是必不可少的，對于跨模塊的類交互，需要使用通知；對于多對多的關系，使用通知更好實現(xiàn)。
工廠設計模式：在我的項目中使用了大量的工廠設計模式，特別是生成控件的API，都已經(jīng)封裝成一套，全部是擴展的類方法，可簡化很多的代碼。
KVC/KVO設計模式：有的時候需要監(jiān)聽某個類的屬性值的變化而做出相應的改變，這時候會使用KVC/KVO設計模式。在項目中，我需要監(jiān)聽model中的某個屬性值的變化，當變化時，需要更新UI顯示，這時候使用KVC/KVO設計模式就很方便了。
就說這么多吧，還有很多的設計模式，不過其它并不是那么常用。
如何實現(xiàn)單例，單例會有什么弊端？
單例在項目中的是必不可少的，它可以使我們?nèi)侄伎晒蚕砦覀兊臄?shù)據(jù)。這只是簡單的問題，大家根據(jù)自己的情況回答。
參考答案：
首先，單例寫法有好幾種，通常的寫法是基于線程安全的寫法，結(jié)合dispatch_once來使用，保證單例對象只會被創(chuàng)建一次。如果不小心銷毀了單例，再調(diào)用單例生成方法是不會再創(chuàng)建的。
其次，由于單例是約定俗成的，因此在實際開發(fā)中通常不會去重寫內(nèi)存管理方法。
單例確實給我們帶來的便利，但是它也會有代價的。單例一旦創(chuàng)建，整個App使用過程都不會釋放，這會占用內(nèi)存，因此不可濫用單例。
iOS是如何管理內(nèi)存的？
我相信很多人的回答是內(nèi)存管理的黃金法則，其實如果我是面試官，我想要的答案不是這樣的。我希望的回答是工作中如何處理內(nèi)存管理的。
參考答案：
Block內(nèi)存管理：由于使用block很容易造成循環(huán)引用，因此一定要小心內(nèi)存管理問題。最好在基類controller下重寫dealloc，加一句打印日志，表示類可以得到釋放。如果出現(xiàn)無打印信息，說明這個類一直得不到釋放，表明很有可能是使用block的地方出現(xiàn)循環(huán)引用了。對于block中需要引用外部controller的屬性或者成員變量時，一定要使用弱引用，特別是成員變量像_testId這樣的，很多人都沒有使用弱引用，導致內(nèi)存得不到釋放。
對于普通所創(chuàng)建的對象，因為現(xiàn)在都是ARC項目，所以記住內(nèi)存管理的黃金法則就可以解決。
使用過哪些第三方庫？
開發(fā)過App，如果回答說沒有使用過第三方庫，那么這個人一定是剛?cè)腴T。如果回答者能夠說出很多有名的第三方庫，并且能說明使用場景，那么可以突出這個面試者的知識面還是很廣的，這是可以加分的。