本文來源：https://juejin.im/post/5b3c40f4e51d45191a0d0aae
一面電話面試：
面試官主要是針對iOS相關的基礎問題。
先簡單自我介紹一下自己
對mrc和arc的理解
談談對自動釋放池的理解
自動釋放池在mrc和arc區(qū)別
多層自動釋放池嵌套的對象在哪一層釋放
對于block，理解，mrc和arc下有什么區(qū)別，使用注意事項
對于深拷貝和淺拷貝的理解
對于strong weak，atomic等等理解
weak原理
如果屬性完全不加修飾詞入weak，atomic，系統(tǒng)會怎么處理
簡述下block的實現(xiàn)
描述下IM系統(tǒng)如何保證消息不丟
IM數(shù)據(jù)庫如何設計表
C++引用和指針有什么區(qū)別
Http協(xié)議30x的錯誤是什么
談談你懂runloop得理解：由淺入深
談談對多線程理解:由淺入深
談談category和extension區(qū)別，系統(tǒng)如何底層實現(xiàn)category
談談消息轉(zhuǎn)發(fā)機制實現(xiàn)
談談事件響應鏈，如何響應view之外的事件
界面性能優(yōu)化
整個面試大約1個半小時。整體上，回答的還算OK，自動釋放池這塊，不夠清楚底層實現(xiàn)。另外atomic是在屬性沒有寫的情況下系統(tǒng)默認的。Block的底層實現(xiàn)也表達的不夠準確。
一面之后過了幾天，給了二面通知。
二面視頻面試：
這次面試官相對于一面，更加側(cè)重于過往項目。
1.開頭都是簡短的自我介紹
2.聊一聊過往項目中你覺得收獲最大的一個模塊。
突然遇到這個問題，心理是有點懵逼的呀，我不禁反想了一下，過去這些個項目，零零散散收獲了不少知識和經(jīng)驗，可是具體到哪一個模塊，完整的思考還是沒有過的。
答: 就說了上個項目做類似朋友圈的優(yōu)化思路，談到了空間換時間，緩存，渲染相關的技術點。
不得不驚嘆騰訊的面試官的邏輯條理，很快抓住了問題的本質(zhì)。
需求痛點：界面卡頓，體驗不好
解決方案：探索的思路-》解決方案。
該模塊引申到的新話題還涉及到了增量更新，內(nèi)存緩存，本地緩存。
細節(jié)上還談到了富文本繪制，Coretext框架的使用，哎，說來慚愧，上次使用coretext已經(jīng)是兩年前，連框架的核心API都已經(jīng)不記得了。再加上項目中使用的是YYLabel的開源框架。最后只能憑借印象大概說了下繪制的流程，其實面試官都是由淺入深的，如果這邊回答的不夠深入。那么后面也就不會有更深入的探討了。
上個項目中存在視頻裁剪，錄制等功能。
面試官對這塊有些興趣，就聊到了視頻裁剪的實現(xiàn)，因為我們項目中使用了ffmpeg做的裁剪功能。包括視頻下載，數(shù)據(jù)裁剪封裝，引申聊到了邊預覽邊裁剪，因為我之前的項目并沒有做到預覽裁剪這塊。也就沒有深入聊下去了。期間簡單談到了rstp協(xié)議，和HLS，rtmp等協(xié)議的對比，信令協(xié)議。雖然之前都有看過協(xié)議的大致實現(xiàn)和預覽，但是實際使用的是SDK，沒有實踐加持。這部分知識是很容易忘記的。大致聊了下總體差別。
項目中有用到過DLNA投屏協(xié)議
說來又是慚愧，自己完整做過的項目，過去了兩年，居然連流程，協(xié)議都只是零零散散的記起來了，很勉強的說出了大概實現(xiàn)流程。知道最后才記起來是soap協(xié)議。當初為了做這個可是研究了整整兩周的。面試官應該也實現(xiàn)過這個需求，提到了視頻盒子斷線如何檢測做處理，什么原因?qū)е碌摹Ｓ捎谥拔覀兊漠a(chǎn)品需求比較簡單，沒有特別完善。這里我也只能說了大概。
項目做過視頻播放需求，使用的AVPlayer框架（重點聊）
面試官問到，AVPlayer怎么監(jiān)聽視頻緩沖狀態(tài)的，有哪幾種狀態(tài)。說來又是慚愧，我只記得是KVO監(jiān)聽的。具體的API已經(jīng)記不清了。
接著面試官問到這個需求遇到過哪些坑，怎么解決的。
這個還真的有，首先是回調(diào)播放進度在拖動時候錯亂，加載某些小視頻的適配，首幀出圖很慢。KVO的模式不靈活。緩沖進度不受我們控制。短視頻可能直接迅速緩沖到底。
還是之前的思路
需求痛點有了
解決方案：探索的思路-》解決方案。
不得不說之前做的產(chǎn)品，都是需求驅(qū)動，解決了需求，很多時候就沒有極客精神，在深入的去探討。這塊真的是差！
發(fā)散問到了：如果網(wǎng)絡不好，首幀出圖之后，如何優(yōu)化后續(xù)播放不卡頓
當時已經(jīng)一臉懵逼了：就提到了可以適當加大緩沖區(qū)，等到足夠的I幀數(shù)據(jù)再開始播放。
甚至連常規(guī)的碼率切換思路都沒想到。作為做音視頻相關產(chǎn)品的我太不應該了。
6.項目聊完了之后，又追問了iOS的一些基礎問題，屬性和成員變量區(qū)別，strong，atomic關鍵字，怎么理解runloop，runloop有幾種狀態(tài)等等。
7.最后給出了一個非常有意思的算法題
有15個瓶子，其中最多有一瓶有毒，現(xiàn)在有四只老鼠，喝了有毒的水之后，第二天就會死。如何在第二天就可以判斷出哪個瓶子有毒
答：開始我想到的是常規(guī)思路二分法，717，和面試官說了，發(fā)現(xiàn)四只老鼠根本不夠，面試官友好的提示從老鼠面去想，這時候很快想到了一個老鼠有死和不死，也就0和1兩個狀態(tài)，四只老鼠有16個組合，正好是足夠的。但是怎么分配瓶子，還沒想好，演算了一會兒，因為面試官這邊時間有限，就說思路是正確的。下面有興趣在看怎么分哈。面試就到此結(jié)束了。
二面持續(xù)了大約一個小時多一點。
二面自己感覺了很多欠缺，不夠深入。
面試總結(jié)
騰訊的面試官都非常的友好，邏輯性非常強。綜合素質(zhì)很高。面試過程中雖然針對的都是技術問題，但是考察的包含了邏輯思維和產(chǎn)品思維以及溝通能力等綜合素質(zhì)。特別是二面。
認識到了自己的不足：
1. 不夠極客精神：還是需求驅(qū)動，之前的項目很多設計優(yōu)化因為對產(chǎn)品的需求沒有那么高精度，遇到痛點的時候：僅僅做了初步的探討，沒有形成完整的閉環(huán)，
往往是做了一定的優(yōu)化滿足了需求就結(jié)束整個過程了。這對于自我的成長是很不好的。比如一個API了解到百分之70，沒有到100.
2. 已有項目知識面深度不夠：項目中使用到了某些API，第一反應是先去看Demo，完成需求，事實上例如僅僅是一個簡單視頻播放，可能調(diào)用API很簡單就可以做到，但是中間包含的卻很多，從網(wǎng)絡協(xié)議，到視頻解封裝，編解碼，渲染。音頻編解碼播放。
雖然每個環(huán)節(jié)都有去學習，也都知道流程，但是這是不夠。要深入進去。即使自己的項目沒有這塊實踐需求。也要自我驅(qū)動去做。
3.自我總結(jié)欠缺：以前都是渾渾噩噩的快樂開發(fā)，也自學了不少。每個項目，或者每個自我學習的過程走一段，都應該站在更高點去總結(jié)一下。
例如項目，要站在產(chǎn)品角度，自我學習，要站在整體框架角度。否則學習到的東西一段時間不用就忘記了。高度也不夠。沒有完全消化透。感覺什么都懂一些，但是什么都差一點火候
怎么改善提高
多寫B(tài)log分享，東西會做，和能寫出來是兩個層面。即使網(wǎng)上已經(jīng)有很多實現(xiàn)了。消化好之后，用自己的思路表達出來，也有很大提高
遇到問題，無論是項目還是自己實踐，都要多問幾個為什么，不能淺嘗輒止，站在產(chǎn)品角度。從原理層面理解問題，最重要是給出解決問題方案。demo不等于工程。
階段性總結(jié)知識點。古語: 學而時習之。
反思了很多：也清楚認識到自己的一些優(yōu)點，有技術熱情，愛好學習。很好的邏輯思維。溝通能力。相信只要堅持努力。一定能獲得好的結(jié)果。也給自己打打氣。共勉之。
作者：AceDong
鏈接：https://juejin.im/post/5b3c40f4e51d45191a0d0aae
來源：掘金
著作權歸作者所有。商業(yè)轉(zhuǎn)載請聯(lián)系作者獲得授權，非商業(yè)轉(zhuǎn)載請注明出處。
