应用安装包的体积会显著影响应用的下载速度和安装速度，按照 Google 的经验数据，包体积每增加 1M 会造成 0.17%的新增折损。抖音的一些实验也证明了包体积会显著影响下载激活的转化率。

Android 的安装包是 APK 格式的，在抖音的安装包中 DEX 的体积占比达到了 40%以上，所以针对 DEX 的体积优化是一种行之有效的包体积优化手段。

DEX 本质上是由 Java/Kotlin 代码编译而成的字节码，因此，针对字节码进行业务无感的通用优化成为我们的一个探索方向。

随着虚拟化技术如模拟器，容器化等技术等发展，在安卓云游戏/云手机场景中，可以在服务宿主侧虚拟出更多更小颗粒度的 Android 实例。其中比较核心的技术是图形虚拟化技术，如何最大限度利用宿主侧的 GPU 资源进行渲染和编码，不考虑软编等利用 CPU 资源进行渲染编码是因为效率带来的延迟问题。

数据库技术一直是信息技术中极其重要的一环，在步入云原生时代后，云基础设施和数据库进一步整合，弥补了传统数据库的痛点，带来了高可扩展性、全面自动化、快速部署、节约成本、管理便捷等优势。

从 2018 到 2021 年，伴随业务和数据的迅猛增长，字节跳动的分布式数据库系统取得了令人振奋的发展。如下图所示，在这 4 年间，公司应用侧容器数量从 5 万个增长到了 750 万个，截至目前已经突破 1000 万。这 1000 万个容器筑成了字节跳动坚实的云原生基础设施，支撑着整个业务体系的发展。

自 2016 年以来，为了支撑在线推荐的存储需求而诞生的——字节跳动自研高可用 KV 存储 Abase，逐步发展成支撑包括推荐、广告、搜索、抖音、西瓜、飞书、游戏等公司内几乎所有业务线的 90% 以上的 KV 存储场景，已成为公司内使用最广泛的在线存储系统之一。

作为一个以新闻、资讯为主的 App，今日头条上的主要内容都是由文章组成，文章服务自然伴随着今日头条 App 的产生就已出现，之后又逐步扩展为目前的内容云，为头条、西瓜、小说、懂车帝等多个 App 服务的业务内容中台。截止 2021 年底，内容云接入子业务已经达到数百个，高峰期主要读服务 QPS 数百万，维护超过 2200 个属性，存量数据达到百亿条级别。然而由于历史悠久，经手人众多，加上历史上一些环境或周边系统的特殊性，业务模式发生转变等，使得内容云成为一个标准的大型遗留系统，早期的一些存储、架构上的设计已经逐渐无法满足当前的业务场景，并给维护者带来了较大维护和迭代成本。

因此我们启动了内容云存储层的迁移项目，随着调研和与其他业务的讨论的不断深入，发现各业务对存储层的痛点及需求基本一致，存储模型和实现方案逐渐趋同，因此决定基于 ByteKV 开发一个宽表数据服务（本文主要聚焦在遗留系统存储层迁移的过程，暂不涉及新存储层的设计与实现细节），下沉存储层通用逻辑，供其他业务接入，并替换内容云原有的存储层。最终历时将近 1 年时间将在线流量切换至新的存储层。

迁移一个系统的存储能有多复杂？无非是双写、迁移数据、切读、停写罢了，为何内容云存储层的迁移竟花费将近一年时间？本文主要分享内容云存储层迁移的血泪史，过程中的一些坑和经验，望能给其他大型系统迁移存储或做重构带来一些流程上的参考。

作为一款面向 ToB 市场的产品——火山引擎 A/B 测试（DataTester）为了满足客户对数据安全、合规问题等需求，探索私有化部署是产品无法绕开的一条路。

在面向 ToB 客户私有化的实际落地中，火山引擎 A/B 测试（DataTester）也遇到了字节内部服务和企业 SaaS 服务都不容易遇到的问题。在解决这些问题的落地实践中，火山引擎 A/B 测试团队沉淀了一些流程管理、性能优化等方面的经验。

本文主要分享火山引擎 A/B 测试当前的私有化架构，遇到的主要问题以及从业务角度出发的解决思路。

本文分析了 Android Studio Sync 在 Gradle 层面的底层逻辑，并且从原理出发介绍了 DevOps - Build 团队 Gradle Sync 优化框架的实现细节以及在飞书项目中进行 Sync 优化的实战经验。

字节跳动 Golang RPC 框架的演进。

Turborepo 是一个用于 JavaScript 和 TypeScript 代码库的高性能构建系统。通过增量构建、智能远程缓存和优化的任务调度，Turborepo 可以将构建速度提高 85% 或更多，使各种规模的团队都能够维护一个快速有效的构建系统，该系统可以随着代码库和团队的成长而扩展。

在自研打包工具的过程中，发现有时会碰到不同的编译工具处理相同的代码，其大小差距可能很大，追查下来大部分是和不同工具对代码优化的处理方式不同所致。目前大部分js打包工具都支持的一种优化即tree shaking，但是不幸的是tree shaking没有比较标准的定义，各个打包工具的tree shaking实现又不尽相同。

为了解决老年人、残疾人等群体在使用互联网等智能技术时遇到的困难，自 2021 年春季开始，西瓜视频开展了无障碍与适老化改造专项行动。陆续完成了无障碍影院、色弱模式、护眼模式、大字号模式、外挂字幕等多个改造需求，充分满足了视力障碍、听力障碍以及老年人等特殊群体的需求。

本文从研发的视角出发，讲述了如何使用 Voice Over、如何适配 Voice Over 以及适配过程中如果遇到问题应该如何解决。

基于字节跳动分布式治理的理念，数据平台数据治理团队自研了 SLA 保障平台，目前已在字节内部得到广泛使用，并支持了绝大部分数据团队的 SLA 治理需求，每天保障的 SLA 链路数量过千，解决了数据 SLA 难对齐、难保障、难管理的问题。

《iOS15动态链接fixup chain原理详解》[1]对 iOS15+ 动态链接过程性能优化的深度解析，引发了字节跳动APM团队对MachO文件的编译链接过程探索的兴趣。在学习的过程中，初学者常常会因为对该领域的不熟悉而陷入误区。本文整理了初学者比较容易犯的三大认知误区，避免大家重蹈覆辙。

大力智能学习灯于 2019 年 10 月份上线，截止 2021 年底，台灯出货量已超过 100w 台，完成了从 0 到 1 的探索。在成立之初，很多方向的产品为了尽早拿到用户反馈，要求快速迭代，研发在代码实现上相对快糙猛，早期阶段这无可厚非，但慢慢地，自习室、系统工具、知识宇宙等应用已经变成灯上核心基建，如果还按之前的野蛮生长的方式将会为台灯的成长埋下隐患。

在这样的背景下，大力智能服务端推动 OOP 技术专项的落地，希望能够：提升团队成员自身的编码水平；统一团队内部编程风格；支撑业务快速迭代。

TCC、APIX、GORM 都是日常项目中经常会依赖到的外部包，本文从这些项目的源码出发，在学习的过程中，解读良好的代码设计在其中的应用，希望能帮忙大家更好的理解和应用 OOP 思想，写出更优秀的代码。

大型项目发展到一个阶段都绕不开性能优化，高性能是高品质产品的重要特征。如何你是研发同学，你会关心如何入手优化，优化的链路都有哪些环节；如何你是Team Leader，你一定很关心用什么易于执行，易于验证的研发流程，来指导前端团队交付高性能的产品，并确保产品的性能始终是健康的、可持续的。

本文我们将介绍前端优化链路的全景图和可持续的性能优先研发流程。

Split lock 是 CPU 为了支持跨 cache line 进行原子内存访问而支持的内存总线锁。

有些处理器比如 ARM、RISC-V 不允许未对齐的内存访问，不会产生跨 cache line 的原子访问，所以不会产生 split lock，而 X86 是支持的。

split lock 对开发者来说是很方便的，因为不需要考虑内存不对齐访问的问题，但是这同时也是有代价的：一个产生 split lock 的指令会独占内存总线大约 1000 个时钟周期，对比正常情况下的 ADD 指令约只需要小于 10 个时钟周期，锁住内存总线导致其他 CPU 无法访问内存会严重影响系统性能。

因此 split lock 的检测与处理就非常重要，现在的 CPU 支持检测能力，检测到如果在内核态会直接 panic，在用户态则会尝试主动 sleep 来降低 split lock 产生的频率，或者 kill 用户态进程，进而缓解对内存总线的争抢。

在引入了虚拟化后，会尝试在 Host 侧处理，KVM 通知 QEMU 的 vCPU 线程主动 sleep 降低 split lock 产生的频率，甚至 kill 虚拟机。以上的结论也只是截止目前 2022/4/19（下同）的情况，近 2 年社区仍对 split lock 的处理有不同的看法，处理方式也是改变了多次，所以以下的分析仅讨论目前的情况。