本文分享的是 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 语言自带的快吗？排序算法方面业界最新的进展是什么呢，有没有一个算法是最快的？

作为数据目录产品，Data Catalog 通过汇总技术和业务元数据，解决大数据生产者组织梳理数据、数据消费者找数和理解数的业务场景，并服务于数据开发和数据治理的产品体系。本文介绍了字节跳动Data Catalog系统的构建和迭代过程，将分为上、下篇发布。上篇围绕Data Catalog调研思路及技术架构展开。下篇重点介绍Data Catalog关键技术和未来规划。

本文针对生活中常见的协同编辑场景，介绍了几种业内常见的解决方案及其原理，适合对协同编辑算法零基础的同学进行科普性的学习。

本文主要从服务端角度针对 2022 年春节 Flower 活动中钱包提现模块做一下总结与反思，希望可以对整个开发过程中使用的技术和遇到的问题进行整理和沉淀，在后续类似的活动中可以产生一些帮助。

作为数据目录产品，Data Catalog 通过汇总技术和业务元数据，解决大数据生产者组织梳理数据、数据消费者找数和理解数的业务场景，并服务于数据开发和数据治理的产品体系。本文介绍了字节跳动Data Catalog系统的构建和迭代过程，将分为上、下篇发布。上篇主要围绕Data Catalog调研思路及技术架构展开。

日期时间的处理，一直是计算机系统中看似简单，实则经常爆雷的问题。

例如，每隔几年，都会爆出的「千年虫问题」的各种变种，通常因为系统在设计之初，没有设计好日期时间的数据存储方式，或者低估了产品设计的生命周期，导致最初选型的数据结构不够用了。

MIDI 协议即数字音乐接口（Musical Instrument Digital Interface），是电子乐器、合成器等演奏设备之间的一种即时通信协议，用于硬件之间的实时演奏数据传递。MIDI 协议诞生之初希望解决的事情是通过统一通信协议让不同乐器制造商的设备可以互相兼容，比如把 Roland 键盘接入 Yamaha 合成器。MIDI 协议的编码经过拓展后也可以作为一种记录音乐信息的文件格式，被称为“标准 MIDI 文件格式”。

在音乐技术研发中除了需要与音频打交道之外，许多场景中还需要直接处理音符信息。如果说 wav 与 mp3 记录的是音乐的物理现象，那么 MIDI 协议与 MIDI 文件则记录的是音乐这门语言的“文字”。本文的目的是让开发中涉及到音乐“本体”的同学可以了解这一最通用的演奏信息交互和文件存储格式的编码规则。同时通过对 MIDI 事件流等概念的认识，能在开发中更好地抽象自己的业务逻辑。

支付测试，是游戏QA功能测试中的一小块，不过因为参与方比较多，往往发生问题后，排查比较困难，因此需要梳理一下流程，为一些常见的问题提供清晰明了的排查思路。

iOS稳定性不好？耗电太快？戳文了解如何使用官方框架提升APP性能与稳定性！

面向快速迭代，如何降低上线风险？字节跳动DataTester团队找到风险与迭代的平衡点——渐进式发布。

在一个典型的分布式文件系统中，目录文件元数据操作（包括创建目录或文件，重命名，修改权限等）在整个文件系统操作中占很大比例，因此元数据服务在整个文件系统中扮演着重要的角色，随着大规模机器学习、大数据分析和企业级数据湖等应用，分布式文件系统数据规模已经从 PB 级到 EB 级，当前多数分布式文件系统（如 HDFS 等）面临着元数据扩展性的挑战。

以 Google、Facebook 和 Microsoft 等为代表的公司基本实现了能够管理 EB 级数据规模的分布式文件系统，这些系统的共同架构特征是依赖于底层分布式数据库能力来实现元数据性能的水平扩展，如 Google Colossus 基于 BigTable，Facebook 基于 ZippyDB，Microsoft ADLSv2 基于 Table Storage，还有一些开源文件系统包括 CephFS 和 HopsFS 等也基本实现了水平扩展的能力。

我们说到的 bias，一般是指一种相对不公平、偏离客观公正的理想状态，或者在整体的各个方面上表现出 unbalanced issues 的现象。对于“客观公正的理想状态”，在各种场景中没有一个统一的定义，而是在各自场景的讨论中会产生一些达成共识的概念。然而，这个概念也是随着人们认知的加深而不断延展的。因此 bias 仍然是一个非常 open 的话题。

推荐系统是一个涉及到众多环节的复杂系统。在系统中，推荐模型基于发生过的用户行为进行学习，对用户进行 item（视频、文章、商品等）的展现，用户对展现出来的 item 产生反馈，反馈的用户行为数据继续被模型学习。在整个链路中，没有哪个环节是绝对意义上的“因”和“果”，它们是一个相互影响的关系。

得益于现在前端生态系统的快速发展，Vite 基于下面两个新特性去解决上述存在的问题，浏览器开始支持原生 ES 模块。越来越多 JavaScript 工具使用编译型语言如 Go 等进行编写，加快了构建速度。