作者：XiaolongTu
本文結構
今年的Android開發的招聘市場如何
今年Android開發的整體招聘趨勢可以概括爲幾句話：賽道中的公司在矇眼狂奔，成熟業務藉機補強，更多公司在觀望。
這裏面賽道的公司指的是在疫情中受益或者在疫情之前就已經在狂奔的業務，比如在線辦公、在線教育、在線生活服務、直播帶貨等，市場上很多HC來自這些賽道里面的公司，技術好，能幹活最受青睞。
成熟的業務藉機補強：很多成熟的業務在招聘高級開發解決性能和提效的問題，雖然手上握有HC，但是在發offer時比較謹慎，優中擇優不斷地比較。
更多公司在觀望：很多公司凍結HC，甚至出現“軟裁員”的情況（筆者公司屬於其中之一）。
Android開發面試的幾部分
基礎知識
基礎知識包括幾個部分：Java（JDK、JVM）、Android、數據結構和算法、計算機基礎、設計模式。
Java部分：
不太推薦這部分只看博客，因爲很多博客並不系統也不完整，推薦完整看一遍《深入理解Java虛擬機》這本書，基本上這裏面涵蓋了JVM相關的所有面試問題，包括內存分區、GC機制、內存模型、鎖、字節碼、類加載等。
JDK的部分會雜一些，基本上可以歸類爲幾種：容器（必問HashMap、CurrentHashMap、ArrayList等）、線程池（必問）、註解、同步工具、動態代理、notify/wait/sleep。這部分可以從一些JDK相關的文章中去整理一遍。
Android部分：
建議看《Android開發藝術探索》，最重要的一點是要跟着源碼讀這本書，書中篇幅所限，很多源碼只有部分，只看書的話並不能理解很多機制是怎麼樣，只有讀源碼才能完全理解喫透，但是讀源碼的時候最好是找到線索即可，切忌陷入到具體的邏輯裏面不能自拔。
這部分必問的是Handler機制、觸摸事件傳遞、四大組件啓動流程、View繪製流程、Binder機制、生命週期。需要徹底讀懂源碼，這樣才能解答很多靈活變通的問題。
經典的問題比如：
- 觸摸事件一定是先傳遞到Activity然後才傳遞給View的麼？
- 如果要在Application的onCreate生命週期之前執行一些邏輯，可以放在哪裏？
- draw、onDraw、dispatchDraw執行的順序如何？
- View真正顯示是在onResume之前還是之後？
- Activity中嵌套有一個Fragment，startActivity之後，Activity和Fragment的生命週期順序是如何的？
這些問題可能在不同的面試官會有不同的變形，只有親自讀懂了源碼纔可以應付這些問題，切忌從一些博客上看到隻言片語就以爲準備萬全了，博客只能作爲參考。最重要是源碼，源碼，源碼！
數據結構與算法：
這部分在客戶端開發中考察的比例會小一些，不過也有很多公司非常重視手寫代碼。經常碰到的問題有二叉樹遍歷、有序二維數組查找，排序等，基本上以《劍指offer》或者《編程之美》爲準就可以了。
一些常見的算法面試題我也已經整理進了《Android開發核心知識點筆記》裏面，有需要的朋友可以 點這領取
計算機基礎：
這部分涵蓋的比較雜，比如計算機網絡（7層網絡模型、Http和Https）、git工作流和命令、計算機緩存策略、UML、信息安全等等。
設計模式：
在自己的項目中一定要多總結和使用設計模式，面試官問你使用過什麼設計模式的時候，如果能回答出比如狀態模式、責任鏈、裝飾等等，肯定會加分不少。如果只是回答單例和建造者模式，那就會遜色多了。這部分推薦看《研磨設計模式》。
開源項目：
這個也是必問的環節之一，建議從自己項目使用的開源項目入手，跟着代碼，畫一遍流程圖和架構圖，仔細體會這裏面設計的優點和缺點。比如OkHttp、LeakCanery等等，這些都可以。開源項目根據面試官的個人經驗不同，問的深入程度也不一樣，這時候就需要你個人的一些引導技巧，比如面試官可能不是很熟悉這個框架，這時候你能主動表達出這裏面設計的一些細節，也能給面試官留下不錯的印象。切忌在簡歷上寫只是用過但是沒看過源碼的框架。
重點項目經歷
小廠的項目往往追求業務快速迭代上線，相對比較能容忍一些技術難點，但是這些技術難點往往是能體現一個人技術能力的。
所以你如果在小廠，就不能過分陷入到業務中，必須跳出來找一些有亮點的技術點，做好做精。這些技術點纔是一個程序員安身立命的本錢，否則公司業務陷入困境了，你的價值也就不復存在了。在如何準備面試中項目這部分，筆者有幾點心得：
- 分成三部分：爲什麼要做這個點，考慮了什麼因素並且是如何做的，取得了什麼效果（比如啓動速度從1000ms降到200ms，這種具體的數據）
- 可以把幾個小點串起來，這樣可以顯得更系統和全面一些，比如代碼優化和性能優化結合在一起講。
- 小廠的一些優化點往往只能做性價比最高的一部分，這時候還可以講一下業界還有哪些更優的方案
- 最好再準備一下“如果你沒有離職項目中還有有什麼不足和可以優化的地方？”（筆者面試中碰到過幾次這樣的問題）
小廠跳大廠，技術基礎可以準備得很充分，但是項目絕對是一個弱項。大廠一個App可能就有幾十上百人在做，小廠很多所謂的優化在大廠的面試官眼中可能都是他們很早就做過了，這時候項目本身做了哪些東西並不是太重要，需要着重體現你解決問題的思路以及你是一個有追求的程序員，至少你要能做到業界的平均水平，這樣纔能有機會通過面試。
對於不知道如何準備項目的同學可以自行百度參考一下。
開放式設計思路
開放式的設計問題需要融會貫通數據結構、設計模式和架構設計等方面的知識，這部分沒有固定的答案，筆者總結了一下這些問題可以套用的幾個解決問題的思路：
分治法
分治法是現代程序設計中非常重要的一個原則，主要是把大問題化解成小問題，再在小問題中去解決各自的問題。
分層法
把一個大的系統進行分層，比如View層-Controller層-Model層。把一個大的問題，劃分成幾個層次，每個層次的職責和層次之間之間數據流定義清楚，然後再在各個層次中去實現。
套用常見的模型
比如生產者消費者模型，“池”的模型（例如線程池、對象池）、緩存模型（LRU）等。
比較常見的開放式設計思路問題有如何設計一個網絡圖片加載框架、如何設計一個文件下載系統、如何設計一個IM組件等等。
這些問題都是非常大的問題，比如圖片加載框架就可以套用分層法去化解，參考fresco的設計，劃分成View-Controler-DataSource這樣的層次。大量文件的下載系統可以套用線程池的模型去設計，這裏就不再展開講了。
技術以外的東西
大廠面試中技術以外的部分也是非常重要的一部分，這部分大多是一些軟技能:
自我驅動和追求
這部分主要是在平時工作中的一些自我驅動學習和自主追求一些技術能力，而不僅僅是完成需求就可以了，這樣才能體現出你個人的成長性和潛力。
溝通和協作
這部分會評估你未來在團隊的融入程度以及跟團隊跨團隊協作和溝通的能力。比如你在工作中是否能正確看待和解決一些跨部門溝通的問題。
下面是我個人整理的整個面試的一些知識圖譜，這上面的知識點基本上都是面試過程中問到的，屬於必知必會的知識點。
與面試官聊天的收穫
雖然很多面試都是在問問題和答問題中度過的，但是還是有一些面試官在面試完成後會對我的面試結果做一些總結和評價，這裏面也收穫頗多，跟大家分享一下。
1、大廠和小廠的選擇
很多剛進入職場以及學生會有這方面的困惑，不過我還是簡單粗暴地回答一下這個問題吧，建議去大廠。因爲這幾個方面的原因：
- 大廠周圍的小夥伴大概率更優秀。
- 幾年後小廠和大廠的程序員市場溢價不同。同樣工作年限的程序員，大廠天然要比小廠的溢價高很多。
- 小廠更強調業務的快跑，忽視人的成長。很多小廠會在不同的業務方向上投幾個人做出一個App出來試試市場反應，很多人就不得不重複做之前已經會的一些功能，而且很多小廠用戶量很小，並不關心所謂的性能架構，因爲優化了一個性能，能受益的用戶也非常少，還要佔用開發業務的時間，你的老闆和業務部門也是非常不樂意的，這對於一個程序員的成長是非常不利的。如果一個小廠宣稱自己的團隊主要成員主要來自百度、新浪、網易等大廠的時候，你需要格外注意一下，這並不代表你進入這個團隊後能成長成百度的標準。
2、5年左右的開發的標準
這裏說一個標準，5年左右開發經驗的工程師，應該在某個或者某幾個方向上是整個公司的專家和標杆。
比如設計能力、網絡優化、性能優化、音視頻等等，5年左右的開發不應該僅僅滿足於實現一些業務需求，應該更深入瞭解底層的原理和技術，這樣在未來的跳槽中才能有更高的溢價，比如從抖音出來的音視頻工程師就能在市場上享受非常高的溢價。
3、關於成長和職級
主動去承擔高一個職級的事情，自然而然你的職級也會跟着提升。
很多同學包括我之前也是認爲把我自己的事情做好了，找一些項目的亮點再去PK晉升職級。
然而阿里的面試官跟我聊這個問題的時候給了一個新的思路：很多P6的同學升級到P7是因爲他們已經在做並且能做好P7的事情了,所以他們升了P7大家都覺得順理成章。從這個角度看職級和晉升，是不是角度不一樣了呢？
寫在最後
在不斷的糾結比較後，筆者最終選擇字節跳動的某書團隊作爲職業生涯的下一站。
最後，在這裏我還分享一份由幾位大佬一起收錄整理的Android學習PDF+架構視頻+面試文檔+源碼筆記，高級架構技術進階腦圖、Android開發面試專題資料，高級進階架構資料
這些都是我閒暇還會反覆翻閱的精品資料。可以有效的幫助大家掌握知識、理解原理。當然你也可以拿去查漏補缺，提升自身的競爭力。
如果你有需要的話，可以 點這領取
喜歡本文的話，不妨順手給我點個小贊、評論區留言或者轉發支持一下唄~
