筆者作為一名雙非二本畢業(yè)7年老Android, 最近面試了不少公司, 目前已告一段落, 整理一下各家的面試問題, 打算陸續(xù)發(fā)布出來, 供有緣人參考。今天給大家?guī)淼氖恰禸ilibili Android一二面涼經(jīng)(2024)》。
技術(shù)一面
- 面試時長: 50min(提問40min + 反問10min)
- 代碼考核: 無
面試問題(40min)
- 自我介紹
- Flow用過嗎
- Jetpack ComposeView
- 起播優(yōu)化
- 業(yè)務(wù)組件化
- 內(nèi)存泄漏排查的經(jīng)驗
- 在哪里會有常見的內(nèi)存泄漏
- 有哪幾類鎖？這些鎖有哪些區(qū)別？
- kotlin獨有的類有哪些, 分別是什么功能? (sealed class、value class、data class)
- 視頻播放器有研究過嗎
- RN頁面打開速度優(yōu)化
- 為什么選用RN, 沒用kotlin的跨平臺, 或者flutter？
面試反問(10min)
招聘崗位未來負責的內(nèi)容
- 1 ijk內(nèi)核負責解碼和渲染。給ijk封裝了一層。還接了其他的播放器。為這些播放器接了統(tǒng)一的API, 提供給別的業(yè)務(wù)方使用, 或者自己業(yè)務(wù)用。
- 2 詳情頁和短視頻頁(B站內(nèi)部稱之為story頁); 長視頻的播放流已經(jīng)經(jīng)過一年的改造, 現(xiàn)在再用協(xié)程、flow、hilt。短視頻還未完成改造。
- 3 不想做播放可以做業(yè)務(wù)；想做播放的話, 可以去跟ijk對接。兩者跨度比較大。
播放真正的底層都是C/C++層, 這個崗位更多的還是上層的吧？
是的, c++層是在ijk內(nèi)核做的。ijk負責解碼。但是播放有什么問題, 或者介入新的播放能力都要經(jīng)過我們。
播放組有多少人？為什么現(xiàn)在比較少?
現(xiàn)在單端5個。去年優(yōu)化了一波。
整個Android團隊人數(shù)。
20+
分組是業(yè)務(wù)劃分還是技術(shù)棧分？
不同的端分組。
有代碼考核或算法題嗎
我不面
面試有幾輪
三輪(兩輪技術(shù)+一輪hr)。
問了團隊氛圍
二次元氛圍濃郁。有個別小朋友(應(yīng)該是指年輕的同事)二次元屬性比較厲害。
每層樓都有貓咪常駐。每次過節(jié)都有cosplay, 比如圣誕節(jié)什么的。之前有好多女裝大佬。
社團: 漢服社、蘿莉社。
個人獨特愛好包容性比較強。
技術(shù)二面
- 面試時長: 60min(提問40min + 反問20min)
- 代碼考核: 無
面試問題(40min)
- 自我介紹
- 業(yè)務(wù)組件化
- 播放優(yōu)化的優(yōu)化措施、優(yōu)化的效果(具體的數(shù)值)
- 是否有線上統(tǒng)計數(shù)據(jù)？
- 拉流地址過期時間, 過期了怎么做？ 用戶播放暫停了, 退到后臺, 超過過期時間, 緩存會全部失效。針對這塊問題有什么優(yōu)化手段？
- 播放底層有做什么優(yōu)化嗎? 比如解碼
- 用戶網(wǎng)絡(luò)不好, 帶寬緊張, 預(yù)加載會導(dǎo)致他當前的音視頻不能流暢播放？這種問題怎么解決？
- 有些音頻碼率也很高(無損音樂), 動不動一首歌就一兩百兆。然后用戶的網(wǎng)絡(luò)狀況并不是很優(yōu)秀, 比如他在地鐵上聽, 怎么保障流暢度？
- 怎么計算起播耗時？起始點和結(jié)束點分別是？
- 播放器跨進程通信的時間對你統(tǒng)計有影響嘛？它回調(diào)給你的時候, 已經(jīng)送響給Audio Window了。因此你的打點時機, 相對來說是滯后的。這塊gap后來有解決嗎？如果沒有, 現(xiàn)在想想該怎么解決？
- 你在做視頻和音頻上有沒有做什么差異化的優(yōu)化？
- kotlin相關(guān)
- compose、MVI、coroutines在項目中有用嗎？
- 根據(jù)你對kotlin coroutines的理解是, 你覺得它是個什么？
- 我們在kotlin協(xié)程寫的時候, 會涉及到一個概念叫CoroutineContext, 如果他只是一個線程池的話, 他設(shè)計出來一個context干嘛？
- 一個協(xié)程scope下有多個子協(xié)程。當一個某一個子協(xié)程異常的時候, 會影響到其他協(xié)程嗎？
- 對于你負責的這幾個項目, 都是你獨自負責項目嗎？還是跟其他人合作開發(fā)？
- 這些項目在Android端的代碼編寫上就是你自己獨立負責的？
- RN相關(guān)
- RN的渲染機制。它的頁面繪制是通過什么樣的方式完成的？這個頁面最終是怎么畫出來的？你寫的東西在Android上面其實都是沒有的, 寫的所謂的DSL。
- RN自己提供的UI組件是不能滿足需求的, 然后面對這種問題, 一般怎么解決？
- 有其他性能優(yōu)化的經(jīng)驗嗎？還是做業(yè)務(wù)開發(fā)為主？
- 你的業(yè)務(wù)里面有什么東西是可以去優(yōu)化？
- 布局xml轉(zhuǎn)code是手寫嗎？有自動化嗎？
- 布局可以異步創(chuàng)建嗎？
- Android異步操作UI會拋一個異常？為什么litho不會？
面試反問(20min)
距離一面過了很久了(2周+), 為什么招聘流程會這么慢？
我們在橫向比較候選人, 匹配度最高的那個候選人也在橫向?qū)Ρ人膐ffer。整體時間久拖得比較久。
HC多嗎？
不多。所以才會橫向?qū)Ρ? 優(yōu)中選優(yōu)。HC多的話就直接發(fā)了嘛。我們也擔心白折騰。
現(xiàn)在B站技術(shù)選型, 跨端方案, Native占比？
Native占絕對的主導(dǎo)地位。
跨端: 一部分是c/c++(播放器、彈幕), JSRuntime來做。業(yè)務(wù)層跨端用KMP。
KMP不是不支持UI的跨端嗎？
對。我們考量下來, UI在各端上面去做跨端的話, 可能后續(xù)還是去用compose做UI的跨端。
目前來講, 復(fù)雜邏輯的跨端和基礎(chǔ)組件的跨端可能對我們來說更有意義。因為UI變化太頻繁了, 很多跨端方案的UI實現(xiàn)方式不能一比一復(fù)刻平臺的效果。
為什么沒有選擇其他跨端方案？
1 復(fù)雜邏輯的跨端和基礎(chǔ)組件的跨端可能對我們來說更有意義。
2 UI變化太頻繁了, 很多跨端方案的UI實現(xiàn)方式不能一比一復(fù)刻平臺的效果。
Flutter: 平臺差異詬病多。
RN: 轉(zhuǎn)成原生性能差。
KMP+compose: 轉(zhuǎn)換成平臺可執(zhí)行的代碼, 性能好。缺點是: 邏輯和UI的跨端不是一并兼容, 需要分開做。
聽上去B站之前也是嘗試過這些跨端方案, 但綜合考慮下來最終沒有選擇？
Flutter和RN都做過。
漫畫業(yè)務(wù)在用Flutter, 團隊人少, 交付更重要(Ps: 我理解面試官這里表達的是省人力, 快速交付的意思)。
主站對性能要求高, 大部分場景還是原生。
B站的跨端方案主推KMP和compose的話, 做跨端的都是Android開發(fā)嗎？還是iOS同學(xué)也會參與？
它確實天然對Android友好, 因為使用kotlin嘛。不過iOS也在學(xué)。
對崗位的候選人的要求？
要求: 主要看技術(shù)基礎(chǔ) + 對播放器有一定的了解(不是完全小白的, 比如說播放器怎么播起來都不知道的那種)
招聘崗位主要是面向于業(yè)務(wù)開發(fā) + 技術(shù)優(yōu)化為主。
播放業(yè)務(wù)復(fù)雜度特別高。比如播放頁的框架是用依賴注入(Dagger)+協(xié)程scope抽象出來的一套框架。它需要對依賴注入和各種協(xié)程理解比較到位才可以。
沒有使用依賴注入的經(jīng)驗也不用太擔心, 因為我們同組的同學(xué)剛開始也不會寫, 會了以后就輕松了。
B站有專門的組去做一些工程的基建, 流程監(jiān)控, 啟動, 內(nèi)存, 電量等？
有基礎(chǔ)架構(gòu)團隊。有負責CI/CD, 以及移動端基礎(chǔ)建設(shè)。比如說網(wǎng)絡(luò)庫, 埋點上報, APM, APM后臺。編譯、流程都有。
播放相關(guān)的指標的APM, 是播放組這邊單獨做嗎？
播放: 我們會建立自己的業(yè)務(wù)指標和技術(shù)指標。合作比較密切的播放內(nèi)核組。他們會和我們的指標雙向驗證。
播放會監(jiān)控什么指標？
首幀、頁面打開速度、卡頓率、錯誤率、帶寬(CDN)。
如果面試流程順利的話, 后面還有一輪技術(shù)面還是直接HR面？
HR面
你們還在橫向比較一些候選人嗎？
就只有二面的幾個。
你們在做鴻蒙嗎？怎么做？我聽說有些公司在用C/C++做Android/iOS/鴻蒙三者的跨端。
在做。我們一開始也想用C, 但我們沒有那么多會C的同事。沒有HC, 因此沒法招更多會C的同事。
總結(jié)
公司氛圍比較多元化, 不僅僅有二次元, 公司內(nèi)部也有許多社團, 對有獨特愛好的人群也有非常強的包容性。
B站Android(播放業(yè)務(wù))面試以音視頻播放+性能優(yōu)化為主, 也會考察候選人對目前B站工程中在使用的技術(shù)(Flow、Compose、KMP、Dagger等)的熟練度。
B站整體的HC比較少, 面試周期比較長。如果真的應(yīng)聘這個崗位, 那就要非常高的匹配度。我總結(jié)了以下幾項技術(shù)/經(jīng)驗來提升崗位匹配度(但有可能已經(jīng)招到人了):
- 視頻播放器性能優(yōu)化
- 起播
- 預(yù)加載 & 緩存
- 網(wǎng)絡(luò)
- ijkplayer
- 跨端: KMP + Jetpack Compose
- 播放器框架: Dagger + Hilt
- 工程中使用較多: Kotlin Coroutines & Flow
