Lottie 动画方案、使用方法、与 Gif 动画的性能测试对比，以及在飞书中的应用和注意事项。

VM-Mapping 是通过数据驱动UI和数据映射的方式，提供了解决多场景下数据状态一致性问题的方案。

字节跳动混沌工程与系统高可用建设实践。

作为近两年的「新时尚」，暗色/深色模式已经几乎成为了各家系统、应用以及 Web 站点的标配功能。想要支持暗色模式，本质是判断在暗色模式下，更改生效的颜色值。在 Web 站点中，一种简单的做法是通过 CSS 变量 来实现。

使用css实现一个立方体，很简单。有想过怎么来实现一个360°无死角的圆柱体吗？

去年 9 月份开始，许多用户升级到 iOS 14 之后，线上出现很多 ImageIO 相关堆栈的 Crash 问题，而且公司内几乎所有的 APP 上都有出现，在部分 APP上甚至达到了 Top 3 Crash。

得益于 APM 平台精准数据采集机制和丰富的异常信息现场，我们通过收集到详细的 Crash 日志信息进行分析解决。

本文以抖音中最为复杂的功能，也是最重要的功能之一的交互区为例，和大家分享一下此次重构过程中的思考和方法，主要侧重在架构、结构方面。

dva 首先是一个基于redux和redux-saga的数据流方案，然后为了简化开发体验，dva 还额外内置了react-router和fetch，所以也可以理解为一个轻量级的应用框架。

我们的一些业务组件需要支持多语言，这些单独发包的组件翻译文案通常都维护在项目一些文件夹下，并且每个需要翻译的文案在代码中都需要手动用 intl.get(key)包裹来实现运行时翻译，开发者也需要根据这些文案一个一个去谷歌进行多种语言翻译，然后再写到项目中。这在无形中给组件开发者加重了开发成本，并且如果翻译有误，PM 和运营同学也无法去代码仓库去修改这些翻译。所以业务组件需要一套更标准，更轻量的多语言方案，来替代上面这些手动工作。经过一些调研后，决定采用公司的 translate-cli + 国际化翻译平台 + 外部开源的 react-intl-universal 来完成组件的多语言。

既然决定了采用新的多语言方案，那么目前翻译文案维护在本地的现存组件就要去改造来接入新的多语言方案。但是现存的组件有 30+个，如果让这些组件的开发者每个组件一个一个文件去改造，会带来很大的成本。而且这些组件的修改内容其实都是一样的，那么完全可以开发一个 CLI 命令去让开发者在自己的组件根目录执行一次，一键完成组件的多语言方案迁移。这样就能很大的减轻了开发者的改造成本。

汉字自动描红是 大力爱辅导-语文字词专项 中的重要功能部分。前期技术调研阶段发现，公司内部已经存在能够满足需求效果的Native SDK，但是考虑到以下原因：

1. 字词专项的技术选型是Flutter作为主要实现
2. 汉字绘制或者描红的需求在多功能、多界面中出现
3. 大量使用PlatformView对Flutter界面的性能有较大伤害 最终决定，使用Flutter实现一套汉字自动描红的方案，便于集成和后续相似功能迭代。

汉字笔顺动画是常见的语文教育需求，我们导入网上开源的 Hanzi Writter 并部署编辑器，应用在大力智能作业灯上。在原版前端实现基础上我们扩展了 Android 和 iOS 端实现，提供更优化的笔顺动画性能。增强对笔顺绘制的控制能力，实现了指定笔顺/笔段渲染，支持笔顺批改和描红能力。

本文从源码层面分析在加载和写入过程中，导致 ANR 问题的原因以及相关的优化解决方案。

功能引导组件就是互联网产品中的指示牌，它旨在带领用户参观产品，帮助用户熟悉新的界面、交互与功能。

Pitaya是专门为移动端打造的端智能一体化方案，与传统方案相比，它在使用成本、动态化能力、多方协作效率及算法、模型的高度复用等方面具备领先优势。

这个“宝藏”框架背后的技术是怎样实现的呢？

Kubernetes 上运行的应用如何进行服务暴露以及网关管理？

苹果升级 14.2，全球 iOS 遭了秧。libffi 在 iOS14.2 上发生了 crash, 我司的许多 App 深受困扰，有许多基础库都是用了 libffi。

经过定位，发现是 vmremap 导致的 code sign error。我们通过使用静态 trampoline 的方式让 libffi 不需要使用 vmremap，解决了这个问题。这里就介绍一下相关的实现原理。