最近几年B站业务高速发展，除了原有的主站业务又催生了很多新的业务，如国际版、必剪、猫耳、HD等，因此各个业务团队对测试手机的需求也显著增长，这对公司来说是一笔不小的开支，但现有测试手机资源分配不均，利用率也非常有限，导致各个团队开发、测试过程中都很难做到多机型覆盖，如何合理、高效利用这些测试手机资源，是摆在我们面前的一道难题。另外在B站内部业务高频率敏捷迭代的节奏下，客户端版本的迭代周期也变的越来越短，为了最大限度的保障产品质量，自动化测试成为整个质量保障过程中不可或缺的存在，而自动化测试需要高质量基础设施来支撑，不然就是空中楼阁，而对于移动APP来说，这个基础设施就是云测机房，也就是下图中的IaaS层。

其中最上面的SaaS层提供诸如：兼容性测试、稳定性测试、性能测试、UI测试等各种各样的自动化测试能力，中间的PaaS层则提供：测试用例管理、测试数据管理、测试框架支持、测试任务调度以及测试报告展示等平台层服务，而laaS层作为底层服务，主要是为了把手机这类硬件资源抽象化为一种通用的测试资源来为上层提供通用的测试设备服务。

B站直播营收送礼业务有着高写、在跨晚和S赛等大型活动下流量陡增、数据实时性要求高等特性，传统压测无法逼近线上真实情况的问题，因此业务对全链路压测有着较大的诉求，需要通过全链路压测来系统性地评估服务容量，发现瓶颈和隐患。

随着云计算、大数据技术的日趋成熟，复杂多元、规模庞大的数据所蕴含的经济价值和社会价值逐步凸显，数据安全也是企业面临的巨大挑战，B站一直致力于对用户隐私数据的保护。本文将介绍B站基于Apache Ranger的大数据权限服务的技术演进之路。

为填补现有3D格式能力上的一些缺陷，增强已有格式能力，并掌握自治权，我们认为有必要创造一种适合中国本土化的标准格式，以满足日益繁多的业务和本土化特色需求，并掌握虚拟生态的话语权。基于此需求，哔哩哔哩BVA应运而生。

全链路压测是在线上生产环境中通过模拟正常用户操作路径进行压力测试的一种方式，对比于我们通常的接口压测具有仿真度高、场景覆盖全等特点。本文将基于前人成熟的实践经验并结合 B 站的基础设施来介绍我们在全链路压测的建设和落地经验。

别骂了，我们来还债了！B站“713事故”系列之第一篇：首次公开复盘。

本文旨在探索与介绍如何通过“流量录制”、“流量回放”代码套件降低白盒测试成本，持续提升移动端代码可测性。

本文描述了B站离线多机房方案，该方案已平稳上线运行半年以上，迁移数据量近300PB，作业数占集群所有作业数的1/3。从实践的结果来看该方案在很大程度上解决了跨机房网络带宽不足、稳定性差与离线任务高效产出之间的矛盾。

本文具体讨论代码分支相关的安全隐患和规避代码分支的一些技术。代码分支的重点并不在于针对每种攻击去消除或掩盖相应的效应，而是要从源头入手，避免根据敏感数据作出代码分支。

随着技术的迭代演进，直播的互动形态由直播间内用户聊天互动的IM消息流衍生出许多互动行为的实时提醒，这些丰富的实时交互能力都是通过长链消息流下发的。本文将介绍APP客户端直播间场景下长链消息业务性能测试实践。

压测的重要性毋庸置疑，相比于监控，压测可以说是主动手段。通过高负载的预演，及时发现线上服务的瓶颈和缺陷，对线上服务质量保障起到了至关重要的作用。本文将介绍B站压测的演进之路：手工阶段 → 平台1.0阶段 → 平台2.0阶段。

目前B站客户端的 Monorepo 模式还在进化中，未来会有越来越多的编译优化的自研规则实装到我们的iOS项目中来，分布式编译能力也已经提上日程。

B 站是一家把用户体验放在第一位的公司，在 AVC 编码下我们已经做到了不错的视频播放卡顿率控制，为了进一步的降低卡顿率我们开始了对 HEVC 编码的探索。HEVC 是比 AVC 更加高效的视频压缩标准，可以在同等画质下减少 50% 的文件体积，意味着只要原先一半的带宽下就能流畅播放 HEVC 视频，在更差的网络环境下依旧能得到不错的用户体验。

目前业内 HEVC 编码主要用于各类移动端设备上，Web 端常见浏览器仅在 Safari 、旧版 Edge 和部分魔改的 Chromium 内核浏览器上才支持播放。得益于 Chrome 在 v57 版本支持了 WebAssembly 并在 v68 版本重新开放了 SharedArrayBuffer（WebAssembly 多线程基础） 接口使得在 Web 上实现高性能应用成为了可能，于是我们自研了基于 WebAssembly 实现软解 HEVC 的播放器。我们在 Web 上进行 HEVC 优化就分为了两部分：在支持 HEVC 的浏览器上使用浏览器解码播放 HEVC 和在不支持 HEVC 的 Chromium 内核浏览器上使用基于 WebAssembly 开发的 WasmPlayer 解码播放 HEVC。

WasmPlayer 提供的是软件解码（软解）能力，通俗层面上软件解码是指使用 CPU 进行解码，相对应的硬件解码（硬解）则是使用 GPU 进行解码。软解的兼容性较高，在不支持硬解的设备上也能使用，劣势是相对而言占用更多的 CPU；硬解的兼容性则相对较低，需要硬件厂商提前适配，优势是功耗、CPU 占用低。硬解和软件相辅相成缺一不可，不是所有的设备都支持各类编码的硬解，新编码借助软解方案则可以实现更快的普及，让更多的用户提前使用上优秀的新编码。

B站最新推出的一款应援弹幕交互产品，将用户发送的弹幕与当下视频场景强相关的文字或图片组合，由此打造视频定制化的弹幕体验，以独特性和新鲜感刺激用户发弹幕，贴合视频内容表达情感，增强互动趣味性。

哔哩哔哩的安卓项目的工程结构是Monorepo(单仓)变种，也就是所有的代码都在一个工程结构下编译。我们认为Monorepo(单仓)是一个非常适合我们的开发模式，主要是因为其提供的原子提交，可见性，参与度，切片的稳定性等等优点，这些都是我们选择Monorepo的原因。但是因为权限管控，ijkplayer等双端通用工程的原因，还是拆开了多个git仓库。通过git权限的方式来拆分了工程结构，然后通过Gradle Plugin的形式进行了多工程的组合，在CI打包环境上让工程具备Monorepo的能力。

随着代码长时间迭代，业务模块数量增多，当前工程有500+的模块以及19个复合构建。如果所有的模块都用源代码编译，打一个包本地可能需要大概30分钟的时间才能完成编译。而且哔哩哔哩的安卓工程是一个上百人同时开发的项目，如果一小个改动都需要30分钟的时间投入编译中，对于开发同学来说可能心态都要崩了。

让编译速度变得更快也就迫在眉睫，而且这个模式是针对开发同学，让他们可以快速对模块变更的代码负责。同时也希望这个模式是在不影响当前的工程结构，让他们的打包速度能变得更快。

没做过内容消费类的产品，对于产品经理来说，是蛮遗憾的一件事。

最近刚好有机会在做内容分发相关的产品设计，免不了想看看这个领域哪个产品做得比较好。

拆解到B站的时候，顿觉头皮发麻，诸多设计精巧之处让我赞叹。

所以，谨尝试从我能看到的部分，对B站整个信息组织方式做一个拆解。