通过提供 Flutter 键盘调用流程相关分析和已知问题的解决思路，让开发者对 Flutter 键盘使用有更深入的了解和认识。

本文介绍如何基于计算存储分离架构，在分布式KV存储的基础上研发一款MQ的核心思路。

创作资源是指道具、模板、小程序等由设计师制作的资源，会应用于抖音、火山、剪映、轻颜、醒图等多款字节 APP 上。随着 UGC 模式的发展，越来越多的用户也加入到创作者行列，提供了大量、新颖的创意与玩法。创作者的增加，也导致资源数量急剧上涨，安全与质量问题也日益突出，而人工检测也存在着较大的效率、漏审等问题。为提升效率和测试覆盖率，给予创作者更好的创作环境与用户更好的使用体验，我们打造了一个专业垂类化测试服务化平台——创作质量平台（简称 CQ ），来保障创作者生产资源的质量。

我们选择 webRTC API 直接录制的方案实现了录屏功能，并在后续踩了一些列的坑，以下是一些分享。

Node.js 提供的 Inspector 非常强大，不仅可以用来调试 Node.js 代码，还可以实时收集 Node.js 进程的 Heap Snapshot、Cpu Profile 等数据。

谈到模糊测试（fuzzing）与变异测试（mutation），在很多场合下这两个概念会被混为一谈，可能很多人分不清它们究竟有什么区别。他们之间的相同点在于，这两种方法都是通过<改变某些东西>来引入变化，从而实现检测<系统，接口，服务，测试用例集，etc.>的稳定性与有效性。

本文整理自火山引擎开发者社区 Meetup 第四期同名演讲，主要为大家介绍了为什么要做 A/B 测试、火山引擎 A/B 测试系统架构及最佳实践。

随着 Android App 开发的技术栈不断向 native 层扩展，native hook 已经被用于越来越多的技术场景中。Android native hook 的实现方式有很多种，其中使用最广泛，并且通用性最强的是 inline hook 和 PLT hook。

inline hook 的功能无疑是最强大的，它受到的限制很少，几乎可以 hook 任何地方。inline hook 在线下场景中使用的比较多，业内现有的通用的 inline hook 开源方案或多或少都存在一些稳定性问题，而且基本都缺乏大规模的线上验证。

PLT hook 的优点是稳定性可控，可以真正的在线上全量使用。但 PLT hook 只能 hook 通过 PLT 表跳转的函数调用，这在一定程度上限制了它的使用场景。

在真实的线上环境中，经常是 PLT hook 和 inline hook 并存的，这样它们可以各自扬长避短，在不同的场景中发挥作用。

现在判断一个元素是否能被用户看见的使用场景越来越多，监听 scroll 事件以及通过 Element.getBoundingClientRect() 获取节点位置的方式，又麻烦又不好用。

什么是个性化推荐？简单说，就是给用户推荐他喜欢的物品。近 10 年，移动互联网高速发展，个性化推荐扮演了很重要的角色。以运营一款内容类产品为例：用户增长团队通过广告投放等手段为产品拉新，提升 DAU；产品技术团队为用户分发感兴趣的内容，提升留存及停留时长；商业化团队分发用户可能感兴趣的广告，提升单位流量变现效率；商业化收入又用于用户增长，形成正向循环。个性化推荐技术贯穿每个环节，成为了很多公司的高速增长引擎。

怎么做个性化推荐？通常，对一项业务来说，首先会定义出多个优化目标（例如视频的播放时长、点赞、分享，电商的点击、加购、购买等），之后构建一个或多个模型来预估这些目标，最后融合多个目标的预估分来完成排序。对推荐系统来说，最核心的工作，便是构建精准的预估模型。这些年，业界的推荐模型一直朝着大规模、实时化、精细化的趋势不断演进。大规模是指数据量和模型非常大，训练样本达到百亿甚至数万亿，单个模型达到 TB 甚至 10TB 以上；实时化是指特征、模型、候选实时更新；精细化则在特征工程、模型结构、优化方法等多方面有所体现，各种创新思路层出不穷。

大规模推荐系统的落地，工程挑战很大。本文选择大家最关心的 Training 和 Serving 系统，介绍搭建过程中会遇到哪些挑战，我们做了哪些工作。对任何一家公司来说，从 0 搭建这样一套系统都绝非易事，投入非常大。在字节跳动内部，我们也经过了多年的探索与沉淀，有上千名工程师，不断迭代和优化推荐系统。那么，搭建推荐系统一般会遇到哪些问题？

卡顿 & ANR 在各 APP 中都是非常影响用户体验的问题，关于其的分析和治理一直也是个老生常谈的话题。过去调查卡顿 & ANR 问题主要依赖上报的堆栈和 traceInfo 文件，通过这些信息还原问题的现场情况。但是在实践过程中发现，现有监控机制下堆栈的抓取时机是晚于问题发生的，大部分情况获取到的是问题发生后某一瞬间的堆栈，随机性强，是不置信的，无法反映问题的真实现场情况，同一个问题可能聚合到不同堆栈中，无法清晰的归类和定位问题，这就使得很多开发者清楚原理，但到了具体 case 时无从下手，调查起来缺乏方向甚至因堆栈聚合的不置信而陷入了错误的排查方向，效率低下。另一方面，大多能够准确衡量性能的工具本身会带来严重耗时问题，无法用于线上，而性能问题大多发生于复杂的线上用户场景。所以，如何对卡顿 & ANR 进行有效的防治就是我们需要考虑的问题。

抖音的无障碍功能实现主要是通过开启 Google TalkBack（或第三方屏幕阅读）功能，将用户在屏幕上触摸选中区域的内容朗读出来，使得视障人士可以根据朗读的内容获取自己当前操作区域的信息，从而提升视障人士的使用和交互体验。

通过Android调用链算法落地自动化测试场景，能够提供自动的、精准的测试能力，从而提高代码的质量保障以及减少测试的人耗。

火山引擎数据质量平台是如何弥合大数据场景下数据质量校验与计算消耗资源大、校验计算时间长的冲突？

卡顿和 ANR 问题一直是 Android 性能优化的重点问题，直接关系到用户体验。当主线程的消息执行耗时过长时，轻则出现不流畅，不跟手，重则有肉眼可见的卡顿感，最严重则是发生 ANR，系统会弹出弹窗提示用户等待或关掉程序，严重影响用户体验。

对于卡顿的监控，现有的方案大多是在消息执行前埋点，当消息耗时过长时进行抓栈操作，ANR 的监控则是通过监听 SIGQUIT 信号并判断进程状态，在 ANR 时拿到各线程堆栈及各类辅助信息来定位问题。这种抓堆栈的方案对于单点长耗时是有效果的，比如锁等待和死锁，但是对于由多个消息和函数耗时累积造成的 ANR，一次堆栈是无法定位问题的，所以经常会出现 ANR 堆栈不准的情况。

西瓜视频的 Android TOP 1 ANR 就是聚类到了 nativePollOnce，根据 ANR 前的消息调度耗时可以看到存在许多长耗时消息，这些长消息是造成 ANR 的根本原因，而不是真的阻塞在了 nativePollOnce。分析发现其实这部分问题都是由于抓栈时机滞后导致的，从感知到 ANR 到完成抓栈存在一定的时间间隔，很容易错过现场，而 nativePollOnce 是主线程中执行频率最高的函数，抓栈很容易落到这里，所以导致很多 ANR 都是 nativePollOnce 的堆栈。另外传统的监控方案对于多个耗时消息累积导致的 ANR 也很难做到有效监控，单次抓栈大概率无法明确问题。所以如果能拿到 ANR 前的一段时间的 Method Trace，那么就能看到主线程到底在做什么，进而准确定位问题。

抖音音乐业务在端内开展 Hybrid 场景时，就选择了 Lynx 技术框架。得益于公司自研，业务在监控上有了非常多的自主性。针对实际业务场景，从用户视角出发，定制了一套业务监控指标。