最近無意間在脈脈上看到了某度某位員工的言論，他說 Android 沒什麼技術，沒什麼難度，插件化、熱修復都是業界自己加戲？
點贊最高的這位網友的說法我很贊同，當我們的項目業務越來越多，性能產生問題時，我們就需要研究底層原理，保證性能，保證崩潰率不飆升。
今天我整理了一些粉絲最近提供的大廠面試題目，來看看你能答上來多少？
2面美團：
@dingtianren：
面試官問了四大組件的生命週期、Activity啓動模式等等；
問了項目總用戶量具體多少，日活和周活具體多少，上線crash率降到的千分概率，說幾個解決的上線後 crash的修復;
LeakCanary底層原理，其中弱引用如何檢測對象沒有被引用的；GC的底層原理；
線程池的使用，比如需要開上萬個線程，線程池的處理規則；
熱修復、插件化與組件化；
性能優化；
怎麼處理在線app出現的閃退問題，比如是偶現的那種，怎樣查找原因？
如果是報oom，怎麼去定位哪裏內存泄漏了？
有沒有用過kotlin開發…
3面阿里釘釘：
@歸園田居：
阿里的面試基本上都是邊聊邊問，根據你的工作經歷以及面試過程中的內容進行展開。
面試官先問，你最擅長Android中的哪個方向呢？
我答了插件化、組件化、熱修復、React Native，最近也在鑽研Flutter，對flutter有一些自己的理解。（我故意這麼講，希望面試官可以多問一下flutter。）
面試官：插件化和熱修復有什麼區別嗎？
我：插件化是把需要實現的模塊或功能獨立提取出來，減少宿主的規模，需要相應功能時再去加載相應模塊；而熱修復則是從修復bug的角度出發，不需要二次安裝應用、用戶無感知的情況下就可以修復已知bug。（這麼基礎的問題，回答的時候自信滿滿…）
面試官：熱修復的核心原理是什麼？
我：主要是利用Android類加載機制，把需要修復的類打包成dex文件，把這個修復過的dex文件排在dexElements最前面，ClassLoader在修復過的dex文件加載到類之後就不會再去加載錯誤的類了。（還好面試前有看過）
面試官：類加載爲什麼要使用雙親委託機制？
我：…（我記得我看過的來着，一下子想不起來了。）
面試官：jvm和dalvik、art的區別是什麼？
我：jvm是基於棧的，dalvik和art是基於寄存器的。（這時候我慌得一比，快頂不住了…）
面試官又追問：那什麼是基於棧的虛擬機，什麼又是基於寄存器的虛擬機？
我說不知道。（那時完全不懂面試官爲什麼要問這個）
面試官：art加載類的流程和Dalvik有區別嗎？
我：有區別嗎？不就是ClassLoader嗎？（面試官稍微提了一下機器碼。）
後續查學習文檔筆記才知道，原來art水這麼深，7.0以前直接編譯爲機器碼。之後又變成混合aot、jit和解釋執行了，加載類底層使用classlinker，先從classtable緩存查找，如果沒有再從oat文件查找，否則就解釋執行
面試官：那art下，熱修復的實現上有什麼需要注意的地方？
最後一個問題聽完之後直接懵逼了…查學習文檔筆記才感覺到面試官其實還是在問：art下類加載的流程。原來aot會生成一個base.art文件，在ClassLoader創建之後就會把base.art中的類注入到緩存中去，所以會導致這些類無法修復。
面試官又問了我遇到的最難的內存優化問題和解決方案；未來三年計劃，技術發展縱深的選擇。
感覺涼了…
3面小米：
@縱有疾風起：
對okhttp的源碼解析；用rxjava遇到過哪些坑；
用過最複雜的自定義view和優化處理；
用EventBus遇到的坑；
glide如何檢測生命週期；
底層替換熱修復和冷啓動熱修復有什麼區別，怎麼實現？
常用算法，遞歸；各種算法空間和時間複雜度；
事件衝突解決；
繪製中MeasureSpec的結構和數據的計算規則；
最近幾個系統版本的系統適配做過哪些工作( 不是ui適配)。
大廠招Android高級工程師要求很高，問的東西很深，一般都會問到原理和底層，你必須專精於Android中某一塊的知識點，不然面試中對什麼知識都是點到即止，肯定是不行。
熱修復技術已經非常成熟，很多大廠的熱修復方案都是開源的，但是市場上深入系統講解熱修復技術細節的博客和書籍非常少，在學習過程中我們經常會遇到各種各樣的問題，無從下手，很多人用過熱修復技術也並不真正理解熱修復的原理。熱修復技術涉及到了類加載、雙親委託機制、反射等原理，面試官基於任何一個點，都可以進行深挖，摸清你的真實Android水平。
爲了讓大家全面快速地理解熱修復技術難點和關鍵點，我特別分享《Android開發核心知識點學習筆記》，給大家詳解Android內核原理，各種項目實戰示例，將會全方位帶你梳理Android知識體系。
如果你需要的話，可以去我 GitHub項目地址中：https://github.com/733gh/Android-T3查閱
