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