使用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，解决了这个问题。这里就介绍一下相关的实现原理。

长页面在前端开发中是非常常见的。例如下图中的电商首页，楼层数据来自运营人员在后台的配置，楼层数量是不固定的，同时每个楼层可能会依赖更多翻页数据。在这种情况下，如果一次性将页面全部渲染，可想而知，我们的页面直出效率（fmp, fid）会受到影响。

为了更好的用户体验，我们需要考虑在用户滚动到下一屏时，渲染下一屏的组件。

“A/B测试不一定是最好的评估方法。它不是万能的，但不会A/B测试肯定是不行的。”4月20日，首个火山引擎技术开放日在北京方恒时尚中心举办，字节跳动副总

有状态应用云原生化过程中在状态管理、基础能力增强、自动化运维等方面的挑战和应对。

Raphael [1]是西瓜视频基础技术团队开发的一款 native 内存泄漏检测工具，广泛用于字节跳动旗下各大 App 的 native 内存泄漏治理，收益显著。工具现已开源，本文将通过原理、方案和实践来剖析 Raphael 的相关细节。