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