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

随着技术的迭代演进，直播的互动形态由直播间内用户聊天互动的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站整个信息组织方式做一个拆解。

H5技术已经非常广泛的应用在app开发中，尤其针对电商等需要快速迭代的业务，突破版本、系统限制，可以很有效的促进业务发展。但是也会导致性能问题，存在一些加载慢、卡顿的情况。在这个用户体验至上的年代，H5页面加载优化已经成为了必需品。

• 研发首先要保证系统稳定性，不能只关注业务功能开发快跑。大促前，充分完成稳定性。
• 保障工作，保障高并发下电商核心流程用户体验。
• 和大厂非常强大的基础架构/中间件不同，公司的基础架构在持续搭建和完善中，我们需要考虑有时中间件不稳定的情况下，对系统增加容错降级，最大程度保证用户体验。
• 从0到1搭建系统，从未知风险到预知消除风险的转变，被现实无数次毒打后，不得不这样做，现在的大促系统稳定性都是血和泪换来的。

跟大多数互联网团队一样，B站也经历过“小步快跑，迭代试错”的阶段，但随着业务规模不断扩大，系统的功能也逐渐复杂，如何能够做到业务快速交付变成了摆在我们面前的又一个难题。最近我在负责我们会员购供应链业务的DDD改造，准备在这里把我们实践的方法以及遇到的问题“抖一抖，晒一晒”。

或许你也在经历着一个复杂度很高的，需求多变的系统，你也尝试寻找一个能够像“解药”一般的框架来让自己摆脱“泥潭”一般的现状，但是我想说软件行业是没有“银弹”的，任何不区分上下文地生搬硬套框架都很有可能遇到滑铁卢一般的惨败。因此做好业务知识储备，拥有独立的思辨力是对我们软件工程师的必备的要求。

文章主要分为三个部分，第一部分简单介绍一下DDD的一些概念，第二部分为结合业务的实操环节，第三部分为作者的心得分享。如果对DDD概念有过了解的同学，可以直接从第二部分看起。鉴于经验有限，本文的观点很多可能也只是一家之言，所以我也比较希望读者们能够带着批判的眼光来看这篇文章，在此也非常希望大家能够一起学习探讨。

换肤功能 并非奇技淫巧，而是已非常普及，尤其当Android Q推出了 深色模式 之后，国内绝大多数主流应用都至少提供了 日间 和 夜间 两种模式。

对于无感的用户而言，这个功能实属鸡肋，但从另外一个角度上来说，这也是产品在雕琢 用户极致体验 过程中的一次尝试，为不同情景下，不同偏好的用户提供更多的选择性。

以 哔哩哔哩 为例，除了提供以上两种主题之外，还免费提供了充满 少女心 的粉色主题。

一份B站社区氛围案例研究。通过案例，我们发现了B站打造优质社区氛围的独家经验，但同时，也意识到它作为内容社区不可违背的某些亘古定律。

关于站内消息系统设计的思考。

随着Z世代的到来，程序员们越来越多的从原本单一的开发职责中走了出来，越来越多的参与到业务里。同时开始思考如何利用手中多样化的技术武器库为业务赋能，与业务互相成就。 想到一个业务Idea并不困难，但衡量一个业务Idea值不值得去P

有人说，战争的胜利将属于犯下错误较少的那一方——这么说来，要判断这场“奇怪的战争”的胜利者还真不容易。