公司：字节跳动
北京字节跳动科技有限公司，简称字节跳动，是一家位于中国北京的跨国互联网技术公司，成立于2012年3月，旗下有产品媒体聚合服务今日头条和短影音抖音（及其海外版本TikTok）、西瓜视频、社交平台Lemon8等，也有一些加入人工智能技术的专业生产力软件，例如剪映、办公套装拉客（lark，中国版本称飞书）等业务。
至2018年，字节跳动的移动应用月度用户超过十亿人，估值750亿美元，超越Uber成为全球最有价值的创业公司。截至2019年7月，字节跳动的产品和服务已覆盖全球150个国家和地区、75个语种，曾在40多个国家和地区位居应用商店总榜前列。
在中国互联网企业中，字节跳动是第一家没有向阿里巴巴、腾讯或百度寻求商业保护或融资的创业公司；相反地，字节跳动被认为与百度、腾讯两大巨头有强烈的竞争关系，因字节跳动资金主要来源于抖音和今日头条的广告收入。
至2020年3月，字节跳动已经有六万员工，并计划再增员一万人。投资人和内部消息将字节跳动2019年的营收定在1,040亿元至1,400亿元人民币，超过了Uber、Snapchat和推特的总和。在中国，其广告收入也超越了腾讯、仅次于阿里巴巴。抖音的全球下载量达1.15亿次，固定用户近10亿。
iOS StoreKit 2 新特性解析
2021 年 WWDC，在 iOS 15 系统上推出了一个新的 StoreKit 2 库，该库采用了完全新的 API 来解决应用内购买问题。
ByteDoc 3.0：MongoDB 云原生实践
本文分享的是 Bytedoc 3.0 关于集群交付方面的内容以及一些云原生的实践：如何将 Bytedoc 3.0 与云原生的能力结合起来，交付用户一个开箱即用的集群，与软件层的能力相匹配，最大化展示 Bytedoc 3.0 具备的“弹性”能力。
分析 Android 耗电原理后，飞书是这样做耗电治理的
飞书最近在进行耗电治理的专项优化，本篇文章将分析 Android 系统的耗电原理，分享飞书的耗电治理规划。
抖音 Android 性能优化系列：Java OOM 优化之 NativeBitmap 方案
作为 Android 开发者，相信大家都碰到过 Java OOM 问题，导致 OOM 的原因可能是应用存在内存泄漏，也可能是因为手机的 heapsize 比较小不能满足复杂应用对内存资源的大量需求。对于 Java 内存泄漏治理，业界已经有比较成熟的方案，这里不做介绍，本文主要针对第二点尝试进行分析和优化。
举个例子：我们在监控平台查看稳定性数据，发现 heapsize=256M 的设备发生的 OOM 崩溃最多，而 heapsize=512M 的设备很少发生 OOM 崩溃。且除此之外，还有一个特点：OOM 崩溃绝大多数发生在 Android 8.0 之前的设备。
打造 Go 语言最快的排序算法
说到排序算法，很多同学会想起快速排序、堆排序、冒泡排序这些耳熟能详的算法。了解得深一些的同学，也可能看过例如 Python 的 timsort 以及 C++ intro sort 之类的排序算法。
但是我们也会有很多疑问，例如 Go 语言中使用的快速排序和我们书上学到的快速排序有什么区别呢？如果我们自己写一个快排，会比 Go 语言自带的快吗？排序算法方面业界最新的进展是什么呢，有没有一个算法是最快的？
字节跳动构建Data Catalog数据目录系统的实践（下）
作为数据目录产品，Data Catalog 通过汇总技术和业务元数据，解决大数据生产者组织梳理数据、数据消费者找数和理解数的业务场景，并服务于数据开发和数据治理的产品体系。本文介绍了字节跳动Data Catalog系统的构建和迭代过程，将分为上、下篇发布。上篇围绕Data Catalog调研思路及技术架构展开。下篇重点介绍Data Catalog关键技术和未来规划。
浅谈文档的实时协同编辑
本文针对生活中常见的协同编辑场景，介绍了几种业内常见的解决方案及其原理，适合对协同编辑算法零基础的同学进行科普性的学习。
大流量活动下钱包提现方案的设计与实现
本文主要从服务端角度针对 2022 年春节 Flower 活动中钱包提现模块做一下总结与反思，希望可以对整个开发过程中使用的技术和遇到的问题进行整理和沉淀，在后续类似的活动中可以产生一些帮助。
字节跳动构建Data Catalog数据目录系统的实践（上）
作为数据目录产品，Data Catalog 通过汇总技术和业务元数据，解决大数据生产者组织梳理数据、数据消费者找数和理解数的业务场景，并服务于数据开发和数据治理的产品体系。本文介绍了字节跳动Data Catalog系统的构建和迭代过程，将分为上、下篇发布。上篇主要围绕Data Catalog调研思路及技术架构展开。
一文读懂全球化系统中的日期时间处理问题
日期时间的处理，一直是计算机系统中看似简单，实则经常爆雷的问题。
例如，每隔几年，都会爆出的「千年虫问题」的各种变种，通常因为系统在设计之初，没有设计好日期时间的数据存储方式，或者低估了产品设计的生命周期，导致最初选型的数据结构不够用了。
音乐研发必备：理解 MIDI 协议与标准 MIDI 文件格式
MIDI 协议即数字音乐接口（Musical Instrument Digital Interface），是电子乐器、合成器等演奏设备之间的一种即时通信协议，用于硬件之间的实时演奏数据传递。MIDI 协议诞生之初希望解决的事情是通过统一通信协议让不同乐器制造商的设备可以互相兼容，比如把 Roland 键盘接入 Yamaha 合成器。MIDI 协议的编码经过拓展后也可以作为一种记录音乐信息的文件格式，被称为“标准 MIDI 文件格式”。
在音乐技术研发中除了需要与音频打交道之外，许多场景中还需要直接处理音符信息。如果说 wav 与 mp3 记录的是音乐的物理现象，那么 MIDI 协议与 MIDI 文件则记录的是音乐这门语言的“文字”。本文的目的是让开发中涉及到音乐“本体”的同学可以了解这一最通用的演奏信息交互和文件存储格式的编码规则。同时通过对 MIDI 事件流等概念的认识，能在开发中更好地抽象自己的业务逻辑。
游戏支付测试分享
支付测试，是游戏QA功能测试中的一小块，不过因为参与方比较多，往往发生问题后，排查比较困难，因此需要梳理一下流程，为一些常见的问题提供清晰明了的排查思路。
iOS X Metirckit｜如何使用官方框架提升APP性能及稳定性
iOS稳定性不好？耗电太快？戳文了解如何使用官方框架提升APP性能与稳定性！
升级上线忐忑不安？来试试渐进式发布吧
面向快速迭代，如何降低上线风险？字节跳动DataTester团队找到风险与迭代的平衡点——渐进式发布。
DanceNN：字节自研千亿级规模文件元数据存储系统概述
在一个典型的分布式文件系统中，目录文件元数据操作（包括创建目录或文件，重命名，修改权限等）在整个文件系统操作中占很大比例，因此元数据服务在整个文件系统中扮演着重要的角色，随着大规模机器学习、大数据分析和企业级数据湖等应用，分布式文件系统数据规模已经从 PB 级到 EB 级，当前多数分布式文件系统（如 HDFS 等）面临着元数据扩展性的挑战。
以 Google、Facebook 和 Microsoft 等为代表的公司基本实现了能够管理 EB 级数据规模的分布式文件系统，这些系统的共同架构特征是依赖于底层分布式数据库能力来实现元数据性能的水平扩展，如 Google Colossus 基于 BigTable，Facebook 基于 ZippyDB，Microsoft ADLSv2 基于 Table Storage，还有一些开源文件系统包括 CephFS 和 HopsFS 等也基本实现了水平扩展的能力。
一文读懂推荐系统中的debias
我们说到的 bias，一般是指一种相对不公平、偏离客观公正的理想状态，或者在整体的各个方面上表现出 unbalanced issues 的现象。对于“客观公正的理想状态”，在各种场景中没有一个统一的定义，而是在各自场景的讨论中会产生一些达成共识的概念。然而，这个概念也是随着人们认知的加深而不断延展的。因此 bias 仍然是一个非常 open 的话题。
推荐系统是一个涉及到众多环节的复杂系统。在系统中，推荐模型基于发生过的用户行为进行学习，对用户进行 item（视频、文章、商品等）的展现，用户对展现出来的 item 产生反馈，反馈的用户行为数据继续被模型学习。在整个链路中，没有哪个环节是绝对意义上的“因”和“果”，它们是一个相互影响的关系。