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 的处理有不同的看法，处理方式也是改变了多次，所以以下的分析仅讨论目前的情况。

近年来，基于 feed 流推荐的短视频业务带来了巨大的广告商业价值，例如，抖音推出的「游戏发行人计划」就是一个鼓励达人发布游戏相关短视频，从而为游戏推广带量并实现流量变现的有效工具。相比于专业的广告素材（PGC），这些由达人自主创作的原生广告素材（UGC）往往具有显著的成本优势，而且风格多样、素材量大。但是，在发行人计划产生的大量 UGC 短视频中，有许多优质素材由于作者热度等原因无法得到足够的曝光，导致这些素材的价值无法得到充分利用。因此，我们通过挑选「游戏发行人计划」中有广告价值的素材进行素材加热（dou+投放），并借助智能投放、人群定向等其他技术，更精准有效地为游戏获量，最大限度挖掘游戏达人素材的潜在价值，更好地实现内容营销。所谓素材优选，即是从海量的短视频素材中，寻找出广告投放效果最好的素材。

目前，安卓端对于包体积的优化方案已经多如过江之鲫，我们系列的上一篇文章介绍了 Class 字节码的优化，本期我们将关注点聚焦到资源文件上，从资源二进制文件的全新角度，拓展出包体积优化的新思路。

在资源文件优化方面，通常的优化手段多集中在图片/文件压缩、资源文件名称混淆、离线下载资源文件等方面，而我们的新思路基于对于常规思路的深度分析及思考。

“异常感知——发现根因——解决问题”，基于该理念，火山引擎APM团队设计了高可用易扩展的SDK和消费平台，形成了一种面向Web监控的解决方案，该方案紧密关联了各个功能，足以支撑复杂场景下的性能、异常数据消费和分析的需求。目前，字节内部已有超过3000+个项目接入，在进行不断迭代、打磨后，决定把它融合入火山引擎全链路监控，为广大外部的应用开发者提供服务。

2021 年 WWDC，在 iOS 15 系统上推出了一个新的 StoreKit 2 库，该库采用了完全新的 API 来解决应用内购买问题。

本文分享的是 Bytedoc 3.0 关于集群交付方面的内容以及一些云原生的实践：如何将 Bytedoc 3.0 与云原生的能力结合起来，交付用户一个开箱即用的集群，与软件层的能力相匹配，最大化展示 Bytedoc 3.0 具备的“弹性”能力。

飞书最近在进行耗电治理的专项优化，本篇文章将分析 Android 系统的耗电原理，分享飞书的耗电治理规划。

作为 Android 开发者，相信大家都碰到过 Java OOM 问题，导致 OOM 的原因可能是应用存在内存泄漏，也可能是因为手机的 heapsize 比较小不能满足复杂应用对内存资源的大量需求。对于 Java 内存泄漏治理，业界已经有比较成熟的方案，这里不做介绍，本文主要针对第二点尝试进行分析和优化。

举个例子：我们在监控平台查看稳定性数据，发现 heapsize=256M 的设备发生的 OOM 崩溃最多，而 heapsize=512M 的设备很少发生 OOM 崩溃。且除此之外，还有一个特点：OOM 崩溃绝大多数发生在 Android 8.0 之前的设备。

说到排序算法，很多同学会想起快速排序、堆排序、冒泡排序这些耳熟能详的算法。了解得深一些的同学，也可能看过例如 Python 的 timsort 以及 C++ intro sort 之类的排序算法。

但是我们也会有很多疑问，例如 Go 语言中使用的快速排序和我们书上学到的快速排序有什么区别呢？如果我们自己写一个快排，会比 Go 语言自带的快吗？排序算法方面业界最新的进展是什么呢，有没有一个算法是最快的？