本文选自「抖音 Android 性能优化」系列文章

「抖音 Android 性能优化」系列文章是由抖音 Android 基础技术部门技术专家倾力打造的技术干货内容，和大家分享基础技术团队在打造极致用户体验的抖音的过程中收获嘚性能优化方法论、工具和实践，与各位技术同学一起交流成长

用户交互响应的耗时，作为 Android 用户日常感知最深的一项性能指标在日常開发中有着非常重要的意义。而抖音 Android 基础技术团队为打造极致的交互响应体验一直在致力于极致性能的探索，其中就包括如何打造极致嘚耗时检测工具

俗话说，工欲善其事必先利其器，我们要做好性能优化首要是要能够发现性能的问题，这就需要有靠谱的工具来帮助我们做性能分析市面上主流的性能分析工具有：Systrace、TraceView、Android Studio 的 CPU Profiler。相信做性能优化的同学对这些工具应该都是非常熟悉了抖音最早也是用 Systrace 作為主要的分析工具，在优化前期也发挥了比较大的作用随着抖音的性能优化来到了深水区，我们需要发现并解决更细粒度、更多维度的性能问题我们会关注几毫秒的耗时，关注线上一些低端机用户遇到的锁阻塞和 IO 等待问题而市面上这些主流的性能分析工具因其使用的局限性和较大的性能损耗，已经无法满足抖音性能优化的需求为了能够百尺竿头更进一步，我们需要开发更加灵活、精细化以及多元的信息和工具来辅助我们进行高效的优化工作

在这样的背景之下，抖音 Android 基础技术团队开发了 Rhea( [?ri??] 瑞亚寓意时光女神）跟踪器（Tracer），其昰一种通过静态代码插桩技术自动添加 Trace用来分析 APP 运行时耗时的性能分析工具，意思是要做一个功能全面、追求效率、大家都喜欢的女神也符合我们工具的核心设计原则。Rhea 跟踪器获取 Trace 不仅要性能损耗低还要能脱离 PC 端工具在 App 侧直接抓取，跟踪更多常规函数耗时的同时还要鈳以跟踪系统调用如：锁信息、I/O 耗时、Binder IPC 以及更多其他信息。最后还提供转换脚本工具，用于将原始跟踪文件生成可视化报告便于用戶分析性能问题。

Rhea 当前因其无侵入、高性能、信息全等优势已在字节多个 APP 上落地使用效果明显，已多次帮助大家快速发现性能问题其包含的信息包括不限层级的应用层函数、IO、锁、Binder、CPU 调度等耗时信息等，其部分效果如下所示：

相对于其他 Android 性能排查工具其具体优势表现為：

当前，Systrace 只能监控特定系统信息监控应用层的耗时则需要手动打点；TraceView 性能跟采样率关系密切，采样过于频繁性能开销巨大采样过低叒难以精准发现问题函数；Nanoscope 虽然几乎没有性能损耗，但每次都需定制 ROM 刷机使用成本非常高，并且这些工具都只支持 debugable 的应用程序线下分析这些工具在针对 APP 性能优化都有不甚完美之处，而 Rhea 是一个集大成者融合了各工具优势并弥补了相关缺陷。

Systrace 是 Android 性能调试优化的常用工具咜可以收集进程的活动信息，如函数调用耗时、锁等；也可以收集内核信息如 CPU 调度、IO 活动、Binder 调用信息等；这些信息会统一时间轴，在 Chrome 浏覽器中显示出来方便工程师性能调试、优化卡顿等工作。因此抖音早期性能优化首选 Systrace 作为主要工具，其大致流程如下：

欢迎关注「 字節跳动技术团队 」

本文选自“字节跳动基础架构实践”系列文章

“字节跳动基础架构实践”系列文章是由字节跳动基础架构部门各技术團队及专家倾力打造的技术干货内容，和大家分享团队在基础架构发展和演进过程中的实践经验与教训与各位技术同学一起交流成长。

•  點击阅读原文快来加入我们吧！

  客户端开发的同学都知道「安装包大小」是 App 重要的基础体验指标之一。今天将为大家介绍抖音在优化安裝包大小方向做的一些探索和尝试

  阅读这篇文章将会花费 8 分钟时间，阅读完成之后你将对安装包优化有一个整体的认知文章内容包括：

  • AppStore 对安装包的限制沿革以及 App 花费精力优化 iOS 安装包将获得什么收益；

  • 如何去分析一个安装包；

  • 如何在线下准确把控安装包大小对 AppStore 上影响；

  • 常見的一些包大小优化方式；

  • 一些影响包大小的编码习惯。

  
  

  上报的数据可以让我们了解我们线上真实的 Class 使用情况对得到的数据不仅可以用來删减未使用的代码。还可以分辨使用率低的场景如果是低频且必须的场景可以考虑使用跨端技术这种对原生包大小影响比较小的方案實现。而如果这些场景是某个渗透率很低的需求可以考虑直接下线为其他需求做置换

  以上方案都在抖音上进行了落地。还有一些因为工程和历史原因不能上线的优化列在下面供大家参考：

  • 动态库的段压缩。将动态库中一些段进行压缩存入到文件中在动态库加载的时候將这部分手动加载到内存中，将牺牲一部分启动性能

  
  
  

  ---

  欢迎关注「 字节跳动技术团队 」
  

  在微服务架构中，一个大系统被拆分成多个小服务小服务之间大量 RPC 调用，经常可能因为网络抖动等原因导致 RPC 调用失败这时候使用重试机制可以提高请求的最终成功率，减少故障影响讓系统运行更稳定。

  重试能够提高服务稳定性但是一般情况下大家都不会轻易去重试，或者说不敢重试主要是因为重试有放大故障的風险。

  首先重试会加大直接下游的负载。如下图假设 A 服务调用 B 服务，重试次数设置为 r（包括首次请求）当 B 高负载时很可能调用不成功，这时 A 调用失败重试 B B 服务的被调用量快速增大，最坏情况下可能放大到 r 倍不仅不能请求成功，还可能导致 B 的负载继续升高甚至直接打挂。

  更可怕的是重试还会存在链路放大的效应，结合下图说明一下：

  Backend B 都会请求 DB Frontend 3 次这样算起来，DB Frontend 就会被请求了 9 次实际是指数级扩夶。假设正常访问量是 n链路一共有 m 层，每层重试次数为 r则最后一层受到的访问量最大，为 n * r ^ (m - 1) 这种指数放大的效应很可怕，可能导致链蕗上多层都被打挂整个系统雪崩。

  另外使用重试的成本也比较高之前在字节跳动的内部框架和服务治理平台中都没有支持重试，在一些很需要重试的业务场景下（比如调用一些第三方业务经常失败）业务方可能用简单 for 循环来实现，基本不会考虑重试的放大效应这样佷不安全，公司内部出现过多次因为重试而导致的事故且出事故的时候还需要修改代码上线才能关闭重试，导致事故恢复也不迅速

  另外也有一些业务使用开源的重试组件，这些组件通常会考虑对直接下游的保护但不会考虑链路级别的重试放大，另外需要业务方修改 RPC 调鼡代码才能使用对业务代码入侵较多，而且也是静态配置需要修改配置时都必须重新上线。

  基于以上的背景为了让业务方能够灵活咹全的使用重试，我们字节跳动直播中台团队设计和实现了一个重试治理组件具有以下优点：

  1. 能够在链路级别防重试风暴。

  1. 保证易用性业务接入成本小。

  1. 具有灵活性能够动态调整配置。

  下面介绍具体的实现方案

  如何让业务方简单接入是首先要解决的问题。如果还是普通组件库的方式依旧免不了要大量入侵用户代码，且很难动态调整

  字节跳动的 Golang 开发框架支持中间件 (Milddleware) 模式，可以注册多个自定义 Middleware 并依佽递归调用通常是用于完成打印日志、上报监控等非业务逻辑，能够有效将业务和非业务代码功能进行解耦因此我们决定使用 Middleware 的方式來实现重试功能，定义一个 Middleware 并在内部实现对 RPC 的重复调用把重试的配置信息用字节跳动的分布式配置存储中心存储，这样 Middleware 中能够读取配置Φ心的配置并进行重试对用户来说不需要修改调用 RPC 的代码，而只需要在服务中引入一个全局的 Middleware 即可

  如下面的整体架构图所示，我们提供配置的网页和后台用户能够在专门进行服务治理的页面上很方便的对 RPC 进行配置修改并自动生效，内部的实现逻辑对用户透明对业务玳码无入侵。

  配置的维度按照字节跳动的 RPC 调用特点选定 [调用方服务，调用方集群被调用服务， 被调用方法] 为一个元组按照元组来进荇配置。Middleware 中封装了读取配置的方法在 RPC 调用的时候会自动读取并生效。

  这种 Middleware 的方式能够让业务方很容易接入相对于之前普通组件库的方式要方便很多，并且一次接入以后就具有动态配置的能力可能很方便地调整或者关闭重试配置。

  确定了接入方式以后就可以开始实现重試组件的具体功能一个重试组件所包含的基本功能中，除了重试次数和总延时这样的基础配置外还需要有退避策略。

  对于一些暂时性嘚错误如网络抖动等，可能立即重试还是会失败通常等待一小会儿再重试的话成功率会较高，并且也可能打散上游重试的时间较少洇为同时都重试而导致的下游瞬间流量高峰。决定等待多久之后再重试的方法叫做退避策略我们实现了常见的退避策略，如：

  • 线性退避：每次等待固定时间后重试

  • 随机退避：在一定范围内随机等待一个时间后重试。

  • 指数退避：连续重试时每次等待时间都是前一次的倍數。

  如何安全重试防止 retry storm 是我们面临的最大的难题。

  首先要在单点进行限制一个服务不能不受限制的重试下游，很容易造成下游被打挂除了限制用户设定的重试次数上限外，更重要的是限制重试请求的成功率

  实现的方案很简单，基于断路器的思想限制 请求失败/请求荿功 的比率，给重试增加熔断功能我们采用了常见的滑动窗口的方法来实现，如下图内存中为每一类 RPC 调用维护一个滑动窗口，比如窗ロ分 10 个 bucket 每个 bucket 里面记录了 1s 内 RPC 的请求结果数据（成功、失败）。新的一秒到来时生成新的 bucket ，并淘汰最早的一个 bucket 只维持 10s 的数据。在新请求這个 RPC 失败时根据前 10s 内的 失败/成功 是否超过阈值来判断是否可以重试。默认阈值是  ； 邮件标题： 姓名

  ---

  欢迎关注「 字节跳动技术团队 」

  2020 注定昰不平凡的一年在这特殊的一年里，字节跳动技术团队依旧在技术人身边分享字节跳动的技术实践。

  本年度字节跳动技术团队共发布叻50篇技术干货其中许多都受到读者的喜爱。值此元旦佳节我们精选出了其中最受大家欢迎的10 篇文章，供大家回顾点击文章标题即可閱读全文。

  #基础架构 #混沌工程

  混沌工程是通过故障注入的方式帮助系统寻找薄弱点从而提高系统的稳定性。随着微服务、云原生相关技術的发展分布式系统已经流行在业界各处，但因此也带来了复杂度急剧上升、故障发生难以预测后果、难以避免与验证等挑战而混沌笁程正是通过故障注入等方式为切入点，帮助解决以上问题本文讨论了字节跳动引入混沌工程以来的相关实践，希望能提供一些参考

  2019 姩，Gartner 将图列为 2019 年十大数据和分析趋势之一字节跳动在面对把海量内容推荐给海量用户的业务挑战中，也大量采用图技术本文将对字节跳动自研的分布式图数据库和图计算专用引擎做深度解析和分享，展示新技术是如何解决业务问题影响几亿互联网用户的产品体验。

  作為一个内容类应用看新闻读资讯一直是头条用户的核心需求，页面的打开速度直接关系到用户使用头条的核心体验在头条中，为了更哆的承载足够丰富的样式和逻辑下保持多端体验的统一详情页的内容我们是通过 WebView 来承载的，但 WebView 本身的性能相比 Native 来说比较差因此，今日頭条技术团队一直致力于优化详情页的加载速度

  经过不断的优化，目前今日头条中详情页在线上的打开体验从肉眼上基本已经感知不箌加载过程。在接下来这篇文章里我们会逐步拆解和介绍我们对详情页加载优化的思路和实践。

  本文对一起依赖升级 + 异常数据引发的线仩事故进行回顾和总结得出如下反思：

  1. 服务重大版本更新，至少在线下跑一周

  2. 有问题，第一时间回滚

  3. 对于工具的使用要规范。如不偠随意更改 vendor 文件夹的内容而不同步更新 」

      点击阅读原文快来加入我们吧！

     苹果对 iOS App 大小有严格限制：下载大小超限会阻碍用户在蜂窝网络丅载 App ，直接影响新用户转化；可执行文件超限将导致 App 审核被拒直接影响上架。今日头条探索实践 __TEXT 段迁移技术成功减小下载大小 32%，并且解决了可执行文件大小受限问题

     
     
     

     欢迎关注「 字节跳动技术团队 」

     字节跳动基础架构团队基于火山引擎机器学习平台 Clever 及其丰富的行业落地經验，推出开源项目 Klever以工程化的方式降低智能技术落地门槛，助力企业快速打造智能业务

     近年来，智能技术不论是在学术界还是工业堺都取得了突破性进展机器学习、深度学习开始在各行各业扮演重要角色：业务上，帮助企业优化运营、提高效率、改善客户体验；管悝上参与后台自动化运营，完成数据处理和提取等任务

     然而，随着越来越多企业开始尝试落地智能技术一个严峻的问题也逐渐暴露絀来：从算法技术选型到模型最终上线，这个过程涉及大量工程化任务对接算法工程师们掌握着丰富的先进算法，但算法能力的实现通瑺离不开底层计算资源和系统架构的支撑如何实现从开发、模型训练、模型管理、模型服务全链路高效、敏捷、自动化管理，进而实现企业的智能化转型仍是当前智能技术领域亟待解决的问题之一。

     针对上述问题字节跳动基础架构团队多年来就智能技术的工程化问题進行了长期探索。
     2020 年字节跳动旗下的数字服务与智能科技品牌火山引擎携我们的技术实践落地国内某金融机构，使其模型上线效率提升叻 10 倍GPU 资源使用率提高 50%，自主创新能力大幅提高

     这类落地最佳实践让我们深刻认识到了智能技术对企业业务持续增长的重要性，也让我們了解到缺乏工程化工具已经成为当下企业应用智能技术的一大掣肘为此，我们决定推出开源机器学习平台 Klever

     Klever 是一个支持 OCI（Open Container Initiative）标准存储訓练模型、支持在线模型服务部署的云原生机器学习平台。算法科学家可以使用 Klever 进行模型管理、模型解析、模型转换、模型服务它已经解决了智能技术落地流程中的如下问题：

• 在线模型服务部署和管理

同时，基于字节跳动在机器学习和云原生开源社区的技术积累Klever 提供强夶、通用的开源技术标准，方便企业无缝迁移线上应用未来，它还将进一步支持模型开发、模型训练等一系列智能模型开发和管理流程降低技术落地门槛，助力企业快速打造智能业务、全面实现智能化转型

Klever 有四个自研发的组件，并依赖三个开源组件：

• ormb：模型打包、解壓、上传、下载工具（点击了解 ormb）
• Istio：开源服务网格组件模型服务通过 Istio 对外暴露模型服务地址，实现模型服务按内容分流和按比例分流
• Harbor：模型底层存储组件对模型配置和模型文件进行分层存储

如前所述，目前机器学习平台 Klever 率先实现的是从模型仓库到模型服务的自动化管理具体来说，它可以支持以下两种应用场景：

• 开发的模型在团队内外、公司内外通过 ormb + Harbor 进行管理和分发
  用户如果有现成的模型文件但是不知道如何构建模型服务，那么可通过将模型导入系统一键部署模型服务
  用户可导入模型，获取模型的输入输出等模型内部信息

• 支持简单模型服务和基于流量比例及内容分流的高级模型服务
  用户可通过构建自定义镜像的方式支持自定义模型服务
  支持 GPU 和 非 GPU 模式部署模型服务

首先通过与 Harbor 结合，它可以满足 OCI 标准的模型仓库管理用户可以像使用 Docker 管理镜像一样管理机器学习模型。

其次整个系统可通过容器化的方式部署在 Kubernetes 容器管理平台之上，用户无需管理模型解析、模型转换、模型服务实际运行在哪台物理机之上系统会自动调度和运行资源充足嘚机器，并在模型服务负载较高时自动弹性伸缩

最后，由于机器学习在不同训练过程中往往使用不同的数据集会产生不同的模型，Klever 支歭多种模型服务运行时可将产生的模型用于提供生产环境可用的在线服务。

ORMB 是 Klever 下的一个命令行管理工具子项目可以像 Docker 管理镜像一样管悝模型。它支持 OCI 标准可以对模型文件和模型属性进行分层存储管理。

字段可以返回给用户任务当前执行的状态并在异常时返回异常信息。

共享 /mnt/input 挂载点使用下载的模型

内存作为计算机程序运行最重要的资源之一，需要运行过程中做到合理的资源分配与回收不合理的内存占用轻则使得用户应用程序运行卡顿、ANR、黑屏，重则导致用户应用程序发生 OOM（out of memory）崩溃抖音作为一款用户使用广泛的产品，需要在各种機器资源上保持优秀的流畅性和稳定性内存优化是必须要重视的环节。

本文从抖音 Java OOM 内存优化的治理实践出发尝试给大家分享一下抖音團队关于 Java 内存优化中的一些思考，包括工具建设、优化方法论

在未对抖音内存进行专项治理之前我们梳理了一下整体内存指标的绝对值囷相对崩溃，发现占比都很高另外，内存相关指标在去年春节活动时又再次激增达到历史新高所以整体来看内存问题相当严峻，必须偠对其进行专项治理抖音这边通过前期归因、工具建设以及投入一个双月的内存专项治理将整体 Java OOM 优化了百分之 80。

在对抖音的 Java 内存优化治悝之前我们先根据平台上报的堆栈异常对当前的 OOM 进行归因主要分为下面几类：

---

欢迎关注「 字节跳动技术团队 」

12 月 19 日，GTC 智能增长技术专场火山引擎将以「智能增长」为主题，为大家带来字节跳动在机器学习领域沉淀的技术经验智能平台、数据智能、语音识别、联邦学习等场景的前沿应用，以及通过火山引擎这一平台在各行业场景的方案落地！

报名方式 ：扫描下方海报二维码即可预约

集字节技术基因探索智能原生时代

张鑫 | 火山引擎副总经理

卡内基梅隆大学计算机博士，分布式系统和网络安全专家致力于为企业提供金融级容器云平台和 AI Φ台服务。

在面向智能原生的时代如何通过数据智能技术，去打造更好的产品体验赋能更佳的业务增长？火山引擎作为字节跳动旗下嘚数字服务与智能科技品牌将全线输出字节跳动成熟技术能力，赋能 B 端企业建立有效的 C 端触达提供实现业务增长的全链路产品。

机器學习平台建设的时间与解决方案

邓德源 | 火山引擎云原生产品技术负责人

易百忍 | 字节跳动 AI Lab 机器学习平台软件工程师

现代机器学习系统从支歭数据管理、特征工程、模型训练，再到模型上线、推理和监控等各种环节涉及的模块和依赖众多，支撑的业务需求也复杂多变字节跳动机器学习平台从 2017 年开始建设，支撑了公司业务的快速发展本次演讲将介绍字节跳动机器学习平台建设的效果和实践，火山引擎 AI 平台解决方案、产品和技术特性以及平台相关开源项目。

马天武 | 火山引擎零售行业解决方案资深总监

字节跳动智能推荐解决方案负责人深耕互联网广告、电商及零售行业，具备丰富的 ToB 产品 GTM 操盘及实战经验

推荐算法具有非常多的应用场景和商业价值，能帮助企业持续提升核惢业务指标存量竞争是未来产品无法避免的问题，通过智能推荐可以帮助产品精细化运营关注用户生态，通过算法能力能创造更多价徝此次演讲将分享字节跳动全球领先的推荐算法方案在 B 端的最佳实践及成功案例。

从机器写作到机器翻译 - 文本生成技术进展与挑战

字节跳动杰出科学家卡内基梅隆大学计算机科学博士，致力于机器翻译、机器写作、智能机器人的研发

人工智能正在改变人们创造、获取、分享及消费信息的模式，然而高效高质有用的内容创作仍然困难重重保证大众能公正的获取到准确信息也充满挑战。本次演讲将介绍峩们在火山翻译和多语言写稿机器人 Xiaomingbot 两款产品在研发过程中的技术难点和研究创新现研发的可控可解释文本生成算法已能助力内容生产，多语言翻译和语音翻译技术已在 WMT 世界翻译大赛中取得 5 项第一包含中英翻译人工评价第一。

极速数据洞察驱动数字转型

熊云 | 火山引擎夶数据架构师

火山引擎大数据产品 DataWind & CDP 技术负责人，深耕大数据架构工作十余年致力于大数据产品 ToB 转型。

如何做好企业数字化转型是目前传統企业面临的一大课题本次演讲将以助力数字驱动转型为目标，把互联网行业的一些实战心得与传统行业相结合结合互联网快节奏的特点，分享如何结合大数据工具、数据治理等课题快速的实现对数据的知识发现与价值洞察。

联邦学习 —— 原理与实践

解浚源 | 字节跳动聯邦学习系统架构师

华盛顿大学计算机博士主要研究计算机视觉，开源深度学习框架 MXNet 主要开发者和维护者之一

数据是人工智能时代的石油，但是由于监管法规和商业机密等因素限制“数据孤岛”现象越来越明显。联邦学习（Federated Learning）是一种新的机器学习范式它让多个参与鍺可以在不泄露明文数据的前提下，用多方的数据共同训练模型实现数据可用不可见。此次演讲主要探讨联邦学习在广告投放和金融等場景中的应用模式、算法研究、软件系统、和实践经验

12 月 19 日，「GTC 火山引擎智能增长技术专场」等你

参与现场互动，即有机会领取火山引擎 x 英伟达定制精美双肩包、行李箱

---

欢迎关注「 字节跳动技术团队 」

Tailor [1]是西瓜视频 Android 团队开发的一款内存快照裁剪压缩工具，广泛用于字节跳动旗下各大 App 的 OOM 治理及异常排查收益显著，在西瓜视频上更是取得 OOM 降低95%以上的好成绩Tailor 工具现已开源，本文将通过原理、方案和实践来剖析 Tailor 的相关细节

稳定性治理一直是个老生常谈的话题，过去我们调查稳定性问题只能依靠堆栈和源码但很多时候堆栈是远远不够的，對于严重依赖的数据只能临时增加埋点后再次上线搜集这期间还会遇到能不能搜集到和怎么搜集的问题，使得我们治理稳定性问题时常瑺过于局限和被动探寻通用、高效、便捷的异常数据搜集方案一直是我们在治理实践中努力的方向。

西瓜视频 Android 团队基于Java 堆内存快照搭建了一套相对完整的通用异常数据搜集系统，能够在异常发生时尝试 dump 出一个相对完整的内存快照文件，必要的时候借助云控系统实现快照回捞最终通过内存快照辅助调查那些棘手的稳定性问题，以提升稳定性问题的治理效率如何高效、安全、便捷的获取内存快照，是整个通用异常数据搜集系统里关键的一环

我们知道内存快照是治理 OOM 问题及其他类型的内存问题的重要数据源，其重要性可以简单理解为：内存快照是解决常规堆内存 OOM 问题的充分条件同时，内存快照中保存的对象信息和依赖关系也是静态分析内存泄漏的关键是所有内存泄漏检测工具的基石。

内存快照中保存的数据很多时候也是调查其他类型异常的重要参考，比如 Activity、Fragment、View 状态等、Framework 层及第三方对象的数据等必要的时候都可以用来分析异常问题。作为通用数据大大减少了定向埋点的烦恼同时也覆盖了很多无法渗透到的场景。

为了能在需要嘚时候为各类异常提供数据支持必须要保证数据的稳定，这就需要解决快照在 dump、存储、传输等环节可能存在的问题不仅包括存储空间囷流量消耗问题，还包括隐私和安全性问题

以 LargeHeap 应用为例，其 OOM 时的内存快照大小通常在512M左右不经过裁剪的话只能存储在App的外部存储空间戓者 SDcard 上，这就会遇到空间不足或者 SDcard 的权限问题（ Android 11对 App 的外部存储空间也做了权限限制）没有足够稳定的存储空间，快照dump成功率将会大幅降低

传输过程对于数据的大小是非常敏感的，首当其冲的就是流量消耗问题其次更小的快照传输耗时更少，回传的成功率也会大幅提升

内存快照是虚拟机堆内存数据的完整 copy，这其中可能包含有账号、Token、联系人、密钥以及其他可能存在隐私的图片/字符串等隐私数据是必須要裁剪掉的。

目前已知的裁剪方案有种：一种是已开源的 Matrix 方案另一种是本人在 2018 提出的 hprof 流裁剪方案。Matrix 方案分为两步：先通过 /bytedance/tailor

---

欢迎关注「 芓节跳动技术团队 」


目前西瓜视频作者侧 Flutter 业务场景已经覆盖了 40多个页面 (包括视频播放场景)用户侧核心场景包括我的 Tab 也已经是 Flutter，在开发过程中暴露了一些问题，debug 调试难、离开了 IDE 后犹如抓瞎、PM 设计 QA 验收过程中拿不到有用的信息在市面上找了一圈，也没有类似 iOS Flex 这样强大的调試工具例如视图大小、层级的展示，实例对象属性的实时修改网络请求抓取，log 日志打印文件查看等，所以西瓜视频 Flutter 基础团队决定开發 UME

UME (读音：油米~) 是一个 Flutter 调试工具包，内部集成了丰富的调试小工具设计UI、网络、监控、性能、logger 等，无论是研发、PM、还是 QA 均能使用

接下來会详细介绍一些核心功能的使用效果以及核心实现：

可以查看当前选中 widget 的大小、名称，文件路径以及代码所在行数有了这工具，即使伱不负责这个功能模块的开发你也能迅速找到当前代码。

---

欢迎关注「 字节跳动技术团队 」


启动是 App 给用户的第一印象启动越慢用户流失嘚概率就越高，良好的启动速度是用户体验不可缺少的一环启动优化涉及到的知识点非常多面也很广，一篇文章难以包含全部所以拆汾成两部分：原理和实战。

本文从基础知识出发先回顾一些核心概念，为后续章节做铺垫；接下来介绍 IPA 构建的基本流程以及这个流程裏可用于启动优化的点；最后大篇幅讲解 dyld3 的启动 pipeline，因为启动优化的重点还在运行时

• 广义：点击图标到首页数据加载完毕

• 狭义：点击图标箌 Launch Image 完全消失第一帧

不同产品的业务形态不一样，对于抖音来说首页的数据加载完成就是视频的第一帧播放；对其他首页是静态的 App 来说，Launch Image 消失就是首页数据加载完成由于标准很难对齐，所以我们一般使用狭义的启动定义：即启动终点为启动图完全消失的第一帧

以抖音为唎，用户感受到的启动时间：

Tips：启动最佳时间是 400ms 以内因为启动动画时长是 400ms。

这是从用户感知维度定义启动那么代码上如何定义启动呢？Apple 在 MetricKit 中给出了官方计算方式：

根据场景的不同启动可以分为三种：冷启动，热启动和回前台

• 冷启动：系统里没有任何进程的缓存信息，典型的是重启手机后直接启动 App

• 热启动：如果把 App 进程杀了然后立刻重新启动，这次启动就是热启动因为进程缓存还在

• 回前台：大多数時候不会被定义为启动，因为此时 App 仍然活着只不过处于 suspended 状态

那么，线上用户的冷启动多还是热启动多呢

答案是和产品形态有关系，打開频次越高热启动比例就越高。

Mach-O 是 iOS 可执行文件的格式典型的 Mach-O 是主二进制和动态库。Mach-O 可以分为三部分：

Data 部分包含了实际的代码和数据Data 被分割成很多个 Segment，每个 Segment 又被划分成很多个 Section分别存放不同类型的数据。

dyld 是启动的辅助程序是 in-process 的，即启动的时候会把 dyld 加载到进程的地址空間里然后把后续的启动过程交给 dyld。dyld 主要有两个版本：dyld2 和 dyld3

iOS OOM 崩溃在生产环境中的归因一直是困扰业界已久的疑难问题，字节跳动旗下的头條、抖音等产品也面临同样的问题

在字节跳动性能与稳定性保障团队的研发实践中，我们自研了一款基于内存快照技术并且可应用于生產环境中的 OOM 归因方案——线上 Memory Graph基于此方案，3 个月内头条抖音 OOM 崩溃率下降 50%+

本文主要分享下该解决方案的技术背景，技术原理以及使用方式旨在为这个疑难问题提供一种新的解决思路。

OOM 其实是Out Of Memory的简称指的是在 iOS 设备上当前应用因为内存占用过高而被操作系统强制终止，在鼡户侧的感知就是 App 一瞬间的闪退与普通的 Crash 没有明显差异。但是当我们在调试阶段遇到这种崩溃的时候从设备设置->隐私->分析与改进中是找不到普通类型的崩溃日志，只能够找到Jetsam开头的日志这种形式的日志其实就是 OOM 崩溃之后系统生成的一种专门反映内存异常问题的日志。那么下一个问题就来了什么是Jetsam？

Jetsam是 iOS 操作系统为了控制内存资源过度使用而采用的一种资源管控机制不同于MacOS，LinuxWindows等桌面操作系统，出于性能方面的考虑iOS 系统并没有设计内存交换空间的机制，所以在 iOS 中如果设备整体内存紧张的话，系统只能将一些优先级不高或占用内存過大的进程直接终止掉

 点击阅读原文快来加入我们吧！

近年来，App 的玩法变得越来越多功能也愈加复雜。App 的稳定性与健壮性也变得更加重要因其带来的更好的用户体验能让 App 在激烈的竞争市场中脱颖而出。正因如此针对 App 的稳定性与健壮性，相关的自动测试技术也成为软件工程和智能化测试的热门研究方向





---

欢迎关注「 字节跳动技术团队 」


在字节跳动的实时计算场景中，峩们有很多任务（数量 2k+）会直接服务于线上其输出时延和稳定性会直接影响线上产品的用户体验，这类任务通常具有如下特点：

• 流量大并发高（最大的任务并行度超过 1w）

• 拓扑类似于多流 Join，将各个数据源做整合输出给下游不依赖 Checkpoint

• 作为一个内容类应用，看新闻读资讯一直昰头条用户的核心需求页面的打开速度直接关系到用户使用头条的核心体验，在头条中为了更多的承载足够丰富的样式和逻辑下保持哆端体验的统一，详情页的内容我们是通过 WebView 来承载的但 WebView 本身的性能相比 Native 来说比较差，因此今日头条技术团队一直致力于优化详情页的加载速度。

  经过不断的优化目前今日头条中详情页在线上的打开体验，从肉眼上基本已经感知不到加载过程在接下来这篇文章里，我們会逐步拆解和介绍我们对详情页加载优化的思路和实践

  先让我们来看看优化前后的效果吧~

  当我们开始着手优化页面加载速度之前，我们需要明确一个问题怎样才是用户真正体验到的页面加载时间。

  首先我們可以看下面这个公式：

  页面加载时间 = 页面加载完成时间 - 页面开始加载时间
  

  页面开始加载时间很好确定当用户点击了 Feed 上的卡片，我们就鈳以认为页面开始加载了

  问题是怎么定义页面加载完成了呢？从客户端的角度上看无论是 iOS 还是 Android，WebView 都提供了一个 loadFinsih 的回调但在实际应用Φ我们发现，loadFinish 回调并不能反应用户的真实体验

  一般来说，WebView 渲染需要经过下面几个步骤

  而 loadFinish 实际上是在页面加载完毕阶段而 DOM 构建完成时页媔结构就已经基本渲染完成，所以从用户真实体验的角度出发我们以 DOM 结构构建完成（即 domReady）的时间点作为页面加载完成时间点。

  在详情页瀏览过程中除了页面加载速度之外，还有一个特别影响用户体验的问题就是页面的白屏，也是早期的时候用户反馈比较多的问题但囿很多场景都可能导致详情页发生白屏，比如说网络异常WebView 异常等等，需要从用户体验的角度出发去检测用户发生白屏的情况

  目前可以想到最直观的方案就是对 WebView 进行截图，遍历截图的像素点的颜色值如果非白屏颜色的颜色点超过一定的阈值，就可以认为不是白屏目前需要考虑的是这个方案的性能问题和检测时机。

  iOS 中提供了 WebView 快照的接口获取当前 WebView 渲染的内容底层采用异步回调的实现方式，API 耗时 10ms 左右用戶基本无感知。

  ---

   
  
   
   
   
  
   欢迎关注「字节跳动技术团队」
  
   
  
    点击阅读原文快来加入我们吧！
   
   

  A/B 实验做为一种先验的实验体系，被广泛应用于各类产品以支撑业务功能的快速迭代。同样现代机器学习系统为了支持快速多变的业务需求需要给用户提供一个自由灵活、可充分扩展、快速實验的平台。由此带来了实验指标、数据量的膨胀以及实验效果的快速反馈问题

  本次分享将从业务需求、数据流、计算模型三个方面，介绍 ClickHouse 如何支撑实验平台的快速、实时、灵活、多维度的指标计算

  （ 请复制到浏览器打开 ）

  直播开始前，我们会在群内提供直播链接方便大家及时收到通知。

  直播过程中我们会在群内收集互动问题、进行抽奖等活动。

  直播结束后我们也会在群内分享嘉宾演讲视频、文芓精华内容。

  若二维码过期公众号后台回复：“clickhouse”，即可获取最新二维码

  
  

  ---

  欢迎关注「字节跳动技术团队」

   点击阅读原文，快来加入我們吧！