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