Bilibili Android一二面凉经(2024)

BiliBili Android一二面凉经(2024)

笔者作为一名双非二本毕业7年老Android, 最近面试了不少公司, 目前已告一段落, 整理一下各家的面试问题, 打算陆续发布出来, 供有缘人参考。今天给大家带来的是《BiliBili Android一二面凉经(2024)》。

面试职位: 高级Android开发工程师（播放业务）

技术一面

面试时长: 50min(提问40min + 反问10min)
代码考核: 无

面试问题(40min)

自我介绍
Flow用过吗
Jetpack ComposeView
起播优化
业务组件化
内存泄漏排查的经验
- 在哪里会有常见的内存泄漏
有哪几类锁？这些锁有哪些区别？
kotlin独有的类有哪些, 分别是什么功能? (sealed class、value class、data class)
视频播放器有研究过吗
RN页面打开速度优化
- 为什么选用RN, 没用kotlin的跨平台, 或者flutter？

面试反问(10min)

招聘岗位未来负责的内容

1 ijk内核负责解码和渲染。给ijk封装了一层。还接了其他的播放器。为这些播放器接了统一的API, 提供给别的业务方使用, 或者自己业务用。
2 详情页和短视频页(B站内部称之为story页); 长视频的播放流已经经过一年的改造, 现在再用协程、flow、hilt。短视频还未完成改造。
3 不想做播放可以做业务；想做播放的话, 可以去跟ijk对接。两者跨度比较大。

播放真正的底层都是C/C++层, 这个岗位更多的还是上层的吧？

是的, c++层是在ijk内核做的。ijk负责解码。但是播放有什么问题, 或者介入新的播放能力都要经过我们。

播放组有多少人？为什么现在比较少?

现在单端5个。去年优化了一波。

整个Android团队人数。

20+

分组是业务划分还是技术栈分？

不同的端分组。

有代码考核或算法题吗

我不面

面试有几轮

三轮(两轮技术+一轮hr)。

问了团队氛围

二次元氛围浓郁。有个别小朋友(应该是指年轻的同事)二次元属性比较厉害。

每层楼都有猫咪常驻。每次过节都有cosplay, 比如圣诞节什么的。之前有好多女装大佬。

社团: 汉服社、萝莉社。

个人独特爱好包容性比较强。

技术二面

面试时长: 60min(提问40min + 反问20min)
代码考核: 无

面试问题(40min)

自我介绍
业务组件化
播放优化的优化措施、优化的效果(具体的数值)
- 是否有线上统计数据？
- 拉流地址过期时间, 过期了怎么做？用户播放暂停了, 退到后台, 超过过期时间, 缓存会全部失效。针对这块问题有什么优化手段？
- 播放底层有做什么优化吗? 比如解码
- 用户网络不好, 带宽紧张, 预加载会导致他当前的音视频不能流畅播放？这种问题怎么解决？
- 有些音频码率也很高(无损音乐), 动不动一首歌就一两百兆。然后用户的网络状况并不是很优秀, 比如他在地铁上听, 怎么保障流畅度？
- 怎么计算起播耗时？起始点和结束点分别是？
- 播放器跨进程通信的时间对你统计有影响嘛？它回调给你的时候, 已经送响给Audio Window了。因此你的打点时机, 相对来说是滞后的。这块gap后来有解决吗？如果没有, 现在想想该怎么解决？
- 你在做视频和音频上有没有做什么差异化的优化？
kotlin相关
- compose、MVI、coroutines在项目中有用吗？
- 根据你对kotlin coroutines的理解是, 你觉得它是个什么？
- 我们在kotlin协程写的时候, 会涉及到一个概念叫CoroutineContext, 如果他只是一个线程池的话, 他设计出来一个context干嘛？
- 一个协程scope下有多个子协程。当一个某一个子协程异常的时候, 会影响到其他协程吗？
对于你负责的这几个项目, 都是你独自负责项目吗？还是跟其他人合作开发？
这些项目在Android端的代码编写上就是你自己独立负责的？
RN相关
- RN的渲染机制。它的页面绘制是通过什么样的方式完成的？这个页面最终是怎么画出来的？你写的东西在Android上面其实都是没有的, 写的所谓的DSL。
- RN自己提供的UI组件是不能满足需求的, 然后面对这种问题, 一般怎么解决？
有其他性能优化的经验吗？还是做业务开发为主？
你的业务里面有什么东西是可以去优化？
- 布局xml转code是手写吗？有自动化吗？
- 布局可以异步创建吗？
- Android异步操作UI会抛一个异常？为什么litho不会？

面试反问(20min)

距离一面过了很久了(2周+), 为什么招聘流程会这么慢？

我们在横向比较候选人, 匹配度最高的那个候选人也在横向对比他的offer。整体时间久拖得比较久。

HC多吗？

不多。所以才会横向对比, 优中选优。HC多的话就直接发了嘛。我们也担心白折腾。

现在B站技术选型, 跨端方案, Native占比？

Native占绝对的主导地位。
跨端: 一部分是c/c++(播放器、弹幕), JSRuntime来做。业务层跨端用KMP。

KMP不是不支持UI的跨端吗？

对。我们考量下来, UI在各端上面去做跨端的话, 可能后续还是去用compose做UI的跨端。
目前来讲, 复杂逻辑的跨端和基础组件的跨端可能对我们来说更有意义。因为UI变化太频繁了, 很多跨端方案的UI实现方式不能一比一复刻平台的效果。

为什么没有选择其他跨端方案？

1 复杂逻辑的跨端和基础组件的跨端可能对我们来说更有意义。
2 UI变化太频繁了, 很多跨端方案的UI实现方式不能一比一复刻平台的效果。

Flutter: 平台差异诟病多。
RN: 转成原生性能差。
KMP+compose: 转换成平台可执行的代码, 性能好。缺点是: 逻辑和UI的跨端不是一并兼容, 需要分开做。

听上去B站之前也是尝试过这些跨端方案, 但综合考虑下来最终没有选择？

Flutter和RN都做过。
漫画业务在用Flutter, 团队人少, 交付更重要(Ps: 我理解面试官这里表达的是省人力, 快速交付的意思)。
主站对性能要求高, 大部分场景还是原生。

B站的跨端方案主推KMP和compose的话, 做跨端的都是Android开发吗？还是iOS同学也会参与？

它确实天然对Android友好, 因为使用kotlin嘛。不过iOS也在学。

对岗位的候选人的要求？

要求: 主要看技术基础 + 对播放器有一定的了解(不是完全小白的, 比如说播放器怎么播起来都不知道的那种)
招聘岗位主要是面向于业务开发 + 技术优化为主。
播放业务复杂度特别高。比如播放页的框架是用依赖注入(Dagger)+协程scope抽象出来的一套框架。它需要对依赖注入和各种协程理解比较到位才可以。
没有使用依赖注入的经验也不用太担心, 因为我们同组的同学刚开始也不会写, 会了以后就轻松了。