WebXR 是一组支持将渲染 3D 场景用来呈现虚拟世界（虚拟现实，也称作 VR ）或将图形图像添加到现实世界（增强现实，也称作 AR ）的标准。通过该 API 可以访问 VR/AR 虚拟设备和跟踪用户姿态动作。它用于替换已经废弃的 WebVR API。 Khronos 的 OpenXR API 基本覆盖了 WebXR API 基础功能，但是它们与 WebGL 和 OpenGL 的关系不同，WebGL 和 OpenGL 关系是 1:1 的映射，而 WebXR 和 OpenXR 是由两个不同的组织开发，所以它们之间会有一些相同概念用不同的方式来表示。
本文介绍了 Android 插件化框架中，插件使用宿主资源时资源错乱的问题，以及错乱的原因、业界通用解决方案、我们提出的优化方案。 本文将按照如下顺序，循序渐进地进行讲解： 简单介绍 Android 插件化中资源部分的动态化。 简单介绍 Android 中的资源的一些基础知识、使用方式及其编译原理。 介绍插件化场景下出现的资源错乱问题及业界通用的解决方案。 介绍一种新的方案——免资源固定方案，用于解决资源错乱问题。 单独介绍一下免资源固定方案中的一个技术点：修改 apk 中的资源文件。
BitSail是字节跳动开源数据集成引擎，支持多种异构数据源间的数据同步，并提供离线、实时、全量、增量场景下全域数据集成解决方案，目前支撑了字节内部和火山引擎多个客户的数据集成需求。经过字节跳动各大业务线海量数据的考验，在性能、稳定性上得到较好验证。本篇将围绕字节跳动开源数据集成引擎BitSail的演进历程与能力解析展开分享。
字节数据中台 DataLeap 的 Data Catalog 系统通过接收 MQ 中的近实时消息来同步部分元数据。Apache Atlas 对于实时消息的消费处理不满足性能要求，内部使用 Flink 任务的处理方案在 ToB 场景中也存在诸多限制，所以团队自研了轻量级异步消息处理框架，很好的支持了字节内部和火山引擎上同步元数据的诉求。本文定义了需求场景，并详细介绍框架的设计与实现。
KubeGateway 是字节跳动针对 kube-apiserver 流量特征专门定制的七层网关，它彻底解决了 kube-apiserver 负载不均衡的问题，同时在社区范围内首次实现了对 kube-apiserver 请求的完整治理，包括请求路由、分流、限流、降级等，显著提高了 Kubernetes 集群的可用性。
Notebook 是一种支持 REPL 模式的开发环境。所谓「REPL」，即「读取-求值-输出」循环：输入一段代码，立刻得到相应的结果，并继续等待下一次输入。它通常使得探索性的开发和调试更加便捷。在 Notebook 环境，你可以交互式地在其中编写你的代码、运行代码、查看输出、可视化数据并查看结果，使用起来非常灵活。 在数据开发领域，Notebook 广泛应用于数据清理和转换、数值模拟、统计建模、数据可视化、构建和训练机器学习模型等方面。 但是显然，做数据开发，只有 Notebook 是不够的。在火山引擎 DataLeap 数据研发平台，我们提供了任务开发、发布调度、监控运维等一系列能力。我们将 Notebook 作为一种任务类型，加入了数据研发平台，使用户既能拥有 Notebook 交互式的开发体验，又能享受一站式大数据研发治理套件提供的便利。
2022 年 10 月 25 日（美国时间）支持 HEVC 硬解功能的 Chrome 107 已正式开始全量推送给所有用户。10 月 21 日 Chrome 官方在更新日志中做了正式说明。 这个事件的背后离不开一位来自字节的开源贡献者的努力，ByteTech 了解到了相关背景，特意邀请了斯杰同学对整件事的来龙去脉作了梳理，以飨读者。
数据地图平台是字节跳动内部的大数据检索平台，每天近万的字节员工在此查找所需数据。数据地图通过提供便捷的找数，理解数服务，大大节省了内部数据的沟通和建设成本。 血缘图谱由 xGraph 与数据地图平台团队合作研发。xGraph 从 Dataleap 业务中孵化，从底至上完全自研，提供设计成熟的内置节点、连线、分组样式，精心打磨图分析产品中常用布局和交互，帮助用户快速搭建关系图产品。血缘图谱解决方案已沉淀到 xGraph 为更多团队复用。
RTC（Real Time Communication）是音视频基础设施，它已经融入了大家生活的方方面面：工作中，我们组织视频会议，即使团队成员身处异国，也能保证项目推进；休息时，我们打开抖音，看主播直播连麦；来一局游戏时，我们打开小队语音，大杀四方；学习时，我们相聚线上互动课堂，知识传播不再受距离的桎梏。RTC 拉近了大家的距离，丰富了大家的生活。 在这些场景里，我们最不能忍受的是什么？是延迟！想象一下，开会或者主播连麦时，一个人讲完话，其他人隔 10 秒才能做出反应，这几乎是完全不能接受的体验。 那么什么样的延迟才是好的体验呢？根据 ITU-T G.114 的建议：延时低于 400ms 的通话体验是可接受的，低于 200ms 是令人愉悦的。
