众所周知，字节跳动的推荐在业内处于领先水平，而精确的推荐离不开大量埋点，常见的埋点采集方案是在响应用户行为操作的路径上进行埋点。但是由于App通常会有比较多界面和操作路径，主动埋点的维护成本就会非常大。所以行业的做法是无埋点，而无埋点实现需要AOP编程。

我们有一个项目使用了 Electron 开发桌面应用，使其能够在 Windows / Mac 两端上跨平台运行，因此核心逻辑都是通过 JavaScript 编写的，黑客非常容易对我们的应用进行解包、修改逻辑破解商业化限制、重新打包，去再分发破解版。

虽然我们已经对应用做了数字签名，但是这还远远不够。要想真正解决问题，除了把所有商业化逻辑做到服务端，我们还需要对代码进行加固，避免解包、篡改、二次打包、二次分发。

精准测试是质量工程智能化建设的重要趋势，为项目研发验收全流程建立公信力度量指标，解决用例与代码的双向关联，精准匹配和投放测试资源（人力/机架），削弱/打破项目规模增长与质量保障资源增长的强正相关关系。

Service Mesh 技术能够提供哪些流量治理能力来保证微服务的稳定和安全?

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 问题的原因以及相关的优化解决方案。