国腾量子安卓一面：多线程同步与视频下载链路

《面试题目》

1. 之前做的视频下载项目是怎么做的？核心链路是什么？哪些部分是你做的？
2. 如果用户在 Twitter 或 Instagram 的 App 里想下载资源，你是怎么解决的？
3. 站点请求资源可能会受到网站策略影响，要求带 cookie 或者登录，怎么解决？
4. 为什么要做成 App 而不是做成浏览器插件？
5. 在广州做监控摄像机 App 时做了什么工作？
6. 讲讲你对多线程的理解，多线程同步是怎么做的？
7. 有没有遇到什么技术难点？怎么解决的？
8. 平时 Java、Kotlin、C++ 的使用情况怎么样？
9. C++ 技术怎么样？岗位后续会涉及 C++ 的东西，你的意愿怎么样？
10. 自我介绍。
11. 离职原因是什么？

《参考解析》

分享链接的接收与解析链路

Android 端做「从别的 App 分享过来就能下载」，入口是 Intent：在 AndroidManifest.xml 里给目标 Activity 注册 ACTION_SEND + text/plain 的 intent-filter，用户在其他 App 点分享选中你的应用后，从 Intent.EXTRA_TEXT 里取出文本，用正则抽出 URL。链路的完整形态是：接收文本 → 提取 URL → 短链展开（跟随 301/302 拿到最终地址）→ 按站点规则抽取资源 ID → 调站点接口拿无水印/最高清直链 → 多线程分片下载 → 合并与校验。工程上要处理的细节：文本里可能混着分享文案（「快来看看这个视频」+ 链接），要能容错提取；一条文本里可能有多个链接，要判断哪个是视频页；正则和站点规则最好做成可配置的规则表并按版本热更新，否则站点一改版 App 就得发版。

需要 cookie / 登录才能取资源时怎么办

站点为了防盗链，通常会对资源请求校验 cookie、Referer、User-Agent，甚至签名参数。可行的做法有几种，基本都要配合：内嵌 WebView 让用户登录一次，再用 CookieManager 把 cookie 同步到网络层（OkHttp 实现自定义 CookieJar，从 CookieManager.getCookie(url) 取、往 cookieJar 里回写）；请求头补齐 Referer 与真实 UA；对需要签名的站点，在 WebView 里注入脚本抓取签名参数或直接拦截 shouldInterceptRequest 拿到已经带签名的真实资源 URL（这是最稳的一路）。要注意：这类方案有账号风控与被封风险，必须限速、退避重试、不要在服务端集中代理用户凭证；产品上也该明确告知用户，别把「绕过限制」做成默认行为。面试时把「先判断资源是否公开，公开的直接下；要登录的走 WebView 会话并把 cookie 交给下载器；失败就明确报错而不是无限重试」这条决策链讲清楚即可。

为什么做 App 而不做浏览器插件

浏览器插件这条路技术上完全可行，但工程与商业上都更难：各浏览器商店审核规则不同（Manifest V3 之后后台与网络能力被大幅收紧，MV3 对拦截与后台请求的限制很硬）、安装门槛高导致留存与转化差、移动端浏览器基本不支持扩展，而下载类需求恰恰大量发生在手机端；跨域与站点策略也让插件很难拿全资源。App 的优势是能拿系统分享入口、有后台下载与通知栏进度、能统一管理下载队列与本地文件、也更容易做付费。代价是各平台要分别适配、上架审核、以及无法复用浏览器已有的登录态——所以 App 的核心难点反而变成了「怎么把站点会话搬进来」，也就是上一题。

多线程与同步

Android 的多线程要分三层说：线程模型（主线程只做 UI，网络与磁盘走 Dispatchers.IO，计算走 Dispatchers.Default；Kotlin 协程用结构化并发把作用域绑到生命周期，配 withContext 切线程，比裸 Thread/AsyncTask 更不容易泄漏）；线程池配置（ThreadPoolExecutor 的核心线程数、最大线程数、有界队列与拒绝策略，下载场景一般用固定并发数 + 有界队列，避免同时开几十个连接把带宽和电量吃光）；同步手段（synchronized 与 ReentrantLock 保护临界区、volatile 保证可见性但不保证原子性、AtomicInteger/CAS 做无锁计数、CountDownLatch/Semaphore 做协作、ConcurrentHashMap 与 CopyOnWriteArrayList 这类线程安全容器、以及 Handler/Looper 回主线程更新 UI）。

落到下载这个具体场景，最有说服力的答法是讲分片下载的并发处理：把文件按字节区间切成 N 片，每个线程用 RandomAccessFile.seek(offset) 写自己的区间（互不重叠，天然不需要锁），进度用原子类累加，全部写完再顺序合并或用 FileChannel.transferTo；下载中断要落盘每片的完成区间做断点续传，重试要按片而不是整体重来。再补一句踩过的坑（比如并发过高被限流、进度回调用 Handler 高频刷 UI 导致卡顿，需要节流合并），回答就很扎实。

监控摄像机 App 与岗位方向

监控类 App 的技术点集中在：RTSP/RTMP 拉流与 P2P 打洞、H.264/H.265 硬解码与 YUV 渲染、多路并发与弱网重连、后台保活与低功耗、以及设备配网（AP 热点/声波/蓝牙）。这块经历可以自然过渡到「底层 + 协议 + C++」的意愿问题。

按原帖的岗位信息，国腾量子做的是量子加密通信：从量子 SIM 卡读取加密算法和密钥，App 侧对密钥做处理，再用密钥对数据做量子算法加密，先用在通话音频传输、后续扩到视频；其中部分算法、转换与调用会涉及 C++ 和 Linux，公司也希望员工愿意补一些量子计算基础（数学部分主要是高数、线代、概率、泛函）。回答意愿类问题时，与其空喊「愿意学」，不如给一个具体路径：先把手上的 Android 网络与音频链路做扎实，同步补 C++ 工程能力（内存管理、跨语言 JNI 调用、NDK 构建），再按项目需要学密钥协商与加解密的基础——既表了态，也显得可信。