前言

俗話說“生于憂患，死于安樂”，其實大部分中年危機，就是在安樂中產(chǎn)生的。

有的人或許會反駁，“照你這么說，我還必須奮斗了，不奮斗就要死，難道選擇安逸的生活就不對嗎？我就沒有選擇自己生活方式的權(quán)利嗎？”

說這句話的人其實有一些誤解，誤解就在于，安逸的生活并不等于不需要奮斗，這要看你的家底。

某聰如果說要選擇安逸的生活，他可以很安逸，因為他有了安逸的資本，而大部分的你，并沒有這個資本，你如果過早的選擇了安逸的生活，那么結(jié)局往往會很悲慘，而你能做的，最多也就是讓你的后代有選擇安逸的資本。

而你，并沒有這個選擇的權(quán)利，所以，想要安逸的生活，就必須先奮斗！

而大部分中年危機，就是因為安逸之前的奮斗不足導(dǎo)致的。

【1面 - 基礎(chǔ)面】

你們 Android 開發(fā)的時候，對于 UI 稿的 px 是如何適配的？

• dpi：屏幕像素密度，指的是在系統(tǒng)軟件上指定的單位尺寸的像素數(shù)量，它往往是寫在系統(tǒng)出廠配置文件的一個固定值；
• ppi：也是屏幕像素密度，但這個是物理上的概念，它是客觀存在的不會改變。dpi是軟件參考了物理像素密度后，人為指定的一個值，這樣保證了某一個區(qū)間內(nèi)的物理像素密度在軟件上都使用同一個值；
• dp加上自適應(yīng)布局和weight比例布局能解決90%的適配問題。因為并不是所有的1080P的手機dpi都是480，比如Google 的Pixel2（1920*1080）的dpi是420；
• 寬高限定符適配：窮舉市面上所有的Android手機的寬高像素值，設(shè)定一個基準的分辨率，其他分辨率都根據(jù)這個基準分辨率來計算，在不同的尺寸文件夾內(nèi)部，根據(jù)該尺寸編寫對應(yīng)的dimens文件。但其有一個致命的缺陷，那就是需要精準命中才能適配，App包體積也會變大

兩個值相等的 Integer 對象，== 比較，判斷是否相等？

Activity A 跳轉(zhuǎn)Activity B，Activity B再按back鍵回退，兩個過程各自的生命周期

• ActivityA跳轉(zhuǎn)ActivityB的過程中,各自生命周期的執(zhí)行順序。例如：A.onCreate A.onStart A.onPause A.onStop B.onCreate B.onStart B.onPause B.onStop B.onDestroy?
  ActivityA和ActivityB生命周期執(zhí)行順序如下： A.onPause －> B.onCreate －> B.onStart－> B.onResume－> A.onStop
• ActivityB 按back鍵呢？
  按下back鍵后： B.onPause－>A.onRestart－>A.onStart－>A.onResume－>B.onStop－>B.onDestory
• ActivityB是個窗口Activity的情況下，1、2的結(jié)論呢？
  若ActivityB是個窗口，ActivityA跳轉(zhuǎn)到ActivityB時，ActivityA失去焦點部分可見，故不會調(diào)用onStop，此時生命周期順序： A.onPause －> B.onCreate －> B.onStart－> B.onResume
  按下Back鍵后：B.onPause－>A.onResume－>B.onStop－>B.onDestory
• 切換橫豎屏時，onCreate會調(diào)用嗎？幾次？
  程序在運行時，一些設(shè)備的配置可能會改變，如：橫豎屏的切換、鍵盤的可用性或語言的切換等，此時Activity會重新啟動。其中的過程是：在銷毀之前會先調(diào)用onSaveInstancestate()去保存應(yīng)用中的一些數(shù)據(jù)，然后調(diào)用 onDestory()，最后才會去調(diào)用onCreate()或者onRestoreInstanceState方法重新啟動Activiy。在切換屏幕時候會重新調(diào)用各個生命周期，切橫屏時會執(zhí)行一次onCreate，切豎屏時會執(zhí)行兩次onCreate。

子線程是否可以 context.startActivity() (如ApplicationContext), 會不會有什么問題？

寫 demo 試了下是可以的。但會有什么問題還沒弄清楚…

Handler機制整體流程；Looper.loop()為什么不會阻塞主線程；IdHandler(閑時機制）；postDelay()的具體實現(xiàn)；post()與sendMessage()區(qū)別；使用Handler需要注意什么問題，怎么解決的?

問題很細，能準備多詳細就準備多詳細。人家自己封裝了一套 Handler 來避免內(nèi)存泄漏問題

Native、H5、RN頁面混合跳轉(zhuǎn)時，頁面清棧的橋如何實現(xiàn)的？

自己做的一個項目，原理講清楚就行，講不清就畫圖

怎么計算一個View在屏幕可見部分的百分比？

ClassLoader 的雙親委派機制

簡單介紹下 Https 的原理

什么情況會導(dǎo)致內(nèi)存泄漏，如何修復(fù)？

下載一張很大的圖，如何保證不 oom？

有沒有做過UI方面的優(yōu)化，做過哪些?

• 調(diào)試GPU過度繪制，將Overdraw降低到合理范圍內(nèi)；
• 減少嵌套層次及控件個數(shù)，保持view的樹形結(jié)構(gòu)盡量扁平（使用Hierarchy Viewer可以方便的查看），同時移除所有不需要渲染的view；
• 使用GPU配置渲染工具，定位出問題發(fā)生在具體哪個步驟，使用TraceView精準定位代碼；
• 使用標簽，merge減少嵌套層次、viewStub延遲初始化、include布局重用 (與merge配合使用)

WebView 與 JS 交互方式，shouldOverrideUrlLoading、onJsPrompt使用有啥區(qū)別

Flutter、Kotlin接觸使用過沒有

其他項目相關(guān)問題

算法 - 二叉樹輸出第 k 層節(jié)點元素

【2面 - 項目專項】

Native、H5、RN頁面混合跳轉(zhuǎn)時，頁面清棧的橋?qū)崿F(xiàn)

頁面混編框架的設(shè)計與難點

RN 通用容器的設(shè)計

用戶行為監(jiān)控方案設(shè)計

JS 錯誤治理方案

RN 頁面對用戶行為的監(jiān)控與JS錯誤治理，在問題發(fā)現(xiàn)有什么收獲、優(yōu)化點

美團 RN 相對于原生 RN 的有什么優(yōu)勢

【3面 - 基礎(chǔ)加深】

你們公司 Picasso 有使用過沒，介紹下

Picasso 單引擎，在多 Bundle 的情況下怎么保證數(shù)據(jù)隔離的？

美團 RN 與 Picasso 的區(qū)別

4.省略若干項目相關(guān)問題…

RN 的頁面追蹤埋點如何實現(xiàn)的

美團首頁是否是 RN 頁面，MTFlexBox 原理

synchronized 修飾 static 方法、普通方法、類、方法塊區(qū)別

synchronized 底層實現(xiàn)原理

volatile 的作用和原理

一個 int 變量用 volatile 修飾，多線程去操作 i++，是否線程安全？如何保證 i++ 線程安全？AtomicInteger 的底層實現(xiàn)原理？

使用 AtomicInteger 可以使 i++ 線程安全

說下對線程池的理解，以及創(chuàng)建線程池的幾個關(guān)鍵參數(shù)

Handler 機制又問了一遍…

介紹下 Binder 機制，與內(nèi)存共享機制有什么區(qū)別？

Java 集合，介紹下ArrayList 和 HashMap 的使用場景，底層實現(xiàn)原理

ArrayList 與 LinkedList 的區(qū)別

算法 - 兩個有序的鏈表的合并

算法 - 輸入一個字符串(不含*和.)、正則(字母、*和.任意組合)，判斷字符串是否合法

簡單介紹下，項目中遇到的一些技術(shù)難點

【4面 - 交叉面】

下面的代碼， str 值最終為多少？換成 Integer 值又為多少，是否會被改變？

• 考點：Java 值傳遞 (第 2 題相同)。編寫代碼測試，在 changeValue() 方法中修改入?yún)?#xff0c;并不會改變之前的值；
• 原理 ：方法得到的是所有參數(shù)值的一個拷貝，即方法不能修改傳遞給它的任何參數(shù)變量的內(nèi)容。基本類型參數(shù)傳遞的是參數(shù)副本，對象類型參數(shù)傳遞的是對象地址的副本；
• 題解：在 changeValue() 中，對于對象類型參數(shù)，直接修改的是對象地址副本的值，所以之前變量的地址并未被修改！若修改的是對象實例里面的某個值，之前變量則會被修改

最后

其實Android開發(fā)的知識點就那么多，面試問來問去還是那么點東西。所以面試沒有其他的訣竅，只看你對這些知識點準備的充分程度。so，出去面試時先看看自己復(fù)習到了哪個階段就好。

雖然 Android 沒有前幾年火熱了，已經(jīng)過去了會四大組件就能找到高薪職位的時代了。這只能說明 Android 中級以下的崗位飽和了，現(xiàn)在高級工程師還是比較缺少的，很多高級職位給的薪資真的特別高（錢多也不一定能找到合適的），所以努力讓自己成為高級工程師才是最重要的。

這里附上上述的面試題相關(guān)的幾十套字節(jié)跳動，京東，小米，騰訊、頭條、阿里、美團等公司21年的面試題。把技術(shù)點整理成了視頻和PDF（實際上比預(yù)期多花了不少精力），包含知識脈絡(luò) + 諸多細節(jié)。

由于篇幅有限，這里以圖片的形式給大家展示一小部分。

詳細整理在GitHub可以見；

Android架構(gòu)視頻+BAT面試專題PDF+學習筆記?

網(wǎng)上學習 Android的資料一大堆，但如果學到的知識不成體系，遇到問題時只是淺嘗輒止，不再深入研究，那么很難做到真正的技術(shù)提升。希望這份系統(tǒng)化的技術(shù)體系對大家有一個方向參考。

%95%E9%9D%A2%E8%AF%95%E6%8B%BF%E9%AB%98%E8%96%AA%EF%BC%81.md)**

網(wǎng)上學習 Android的資料一大堆，但如果學到的知識不成體系，遇到問題時只是淺嘗輒止，不再深入研究，那么很難做到真正的技術(shù)提升。希望這份系統(tǒng)化的技術(shù)體系對大家有一個方向參考。

總結(jié)

以上是生活随笔為你收集整理的意外收获字节跳动内部资料，一篇文章帮你解答的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。