rogeryi_个人页

Flutter 图片解码与缓存管理研究

图片解码和缓存管理是渲染引擎的一个重要模块，这是因为图片解码的耗时很长，特别是对于设计为跨平台的通用渲染引擎来说，依赖于CPU来做图片解码，会消耗大量的CPU时间，并且图片解码后占用的内存很大，一张 1024x1024 分辨率的图片解码后就需要 4M 内存（除非硬件支持实时生成无损压缩格式纹理，通常这也不在通用渲染引擎的考虑范围之内）。所以一个设计良好的图片解码和缓存管理模块需要平衡很多不同的因素

TextureView 的血与泪

越来越多的应用需要使用自己的绘制引擎进行复杂内容的绘制，比如需要使用 GL 绘制 3D 的内容，或者绘制复杂的文档，图表时不希望阻塞 UI 线程，或者部分内容是通过类似 Flutter 这样的第三方 UI Toolkit 进行绘制。通常这部分内容会通过 SurfaceView 或者 TextureView 呈现在 UI 界面上。 一般来说 SurfaceView 能够提供更好的性能，但是因为

U4 4.0 混合光栅化

我在蚂蚁 [Codeday#4 广州站的演讲][1]上介绍了为 U4 4.0 新设计的渲染流水线， 我们称为直接合成（Direct Compositing），区别于原生 WebView 同步合成（Synchronous Compositing）的渲染流水线。 新渲染流水线除了更好的系统兼容性和支持独立 GPU 进程外，也希望通过简化合成器架构和支持直接光栅化来提升渲染性能，减少 GPU 内存

使用 Snapdragon Profiler 分析 Android 应用的 GPU 内存泄露

前几天同事发现一个正在开发的小程序在反复进入退出时，应用的 GPU 内存占用会一直上涨直到触发 OOM，因为小程序使用了内核作为渲染引擎，所以怀疑是内核发生内存泄露，让我帮忙分析看看。 > Snapdragon Profiler Snapshot Capture 进入小程序后，使用 [Snapdragon Profiler][1] Snapshot Capture 抓取了当前帧的

MotionMark 浏览器图形性能测试套件深入分析

[MotionMark][1] 是 Apple 开发的一个浏览器图形性能测试套件，用来[测试和评估 Safari/WebKit 的图形性能][2]，这里的图形性能并不仅仅包括光栅化和合成，而是涵盖了完整的浏览器渲染流水线，包括 DOM API，样式计算，排版等。 MotionMark 虽然不能涵盖浏览器图形性能的所有方面，但是作为衡量浏览器图形性能的其中一项指标，还是有不错的参考价值。Ch

渲染流水线中的光栅化

Rasterization，光栅化，又称为栅格化，它用于执行绘图指令生成像素的颜色值。光栅化是渲染流水线中的一个重要环节，但是不同的 UI Toolkit 和不同浏览器渲染引擎使用的光栅化策略并不一样，本文主要讨论各种不同的光栅化策略和它们各自的优劣。 ## 渲染流水线 ![rasterization_1.png](https://i.loli.net/2019/08/16/8aHV5

Chromium Viz 浅析 - SkiaRenderer & SkiaOutputSurface

**关于 Viz 的系列文章** [Chromium Viz 浅析 - 介绍篇][1] [Chromium Viz 浅析 - 合成器架构篇][2] ---- Chromium 关于光栅化和合成的一些主要性能优化项目包括 OOPD (Out of Process Display Compositor，进程外 Display 合成器), OOPR (Out of Process R

Chromium Viz 浅析 - 合成器架构篇

**关于 Viz 的系列文章** [Chromium Viz 浅析 - 介绍篇][1] ---- ## Mojo 快速入门 因为后面的内容需要读者对 Mojo 有一定了解，如果以前没接触过的话，这部分内容提供了一个快速的入门。 简单的说 Mojo 是一个 Client/Service 的通讯机制，支持跨进程。一个 Mojo 链接建立的过程一般如下： 1. Cli

Chromium Viz 浅析 - 介绍篇

很遗憾 Chromium 的工程师没有写一篇 How Viz Works 的文章来详细解析 Viz 这个重要的模块，能找到的一些相关文档都比较零散，所以我打算自己来写，不过个人研究深度有限，无法包括所有的细节，还请读者见谅。 计划写两到三篇文章，第一篇文章对 Viz 做一个概要的介绍，和它在 Chromium 整个合成器架构里面的角色。因为 Viz 的代码变动很快，所以文章的内容只是针对当前

How cc Works 中文译文

Chromium 的工程师们写了两篇技术文章 [How Blink Works][1] ([中文译文][2]) 和 [How cc Works][3]，分别介绍了 Chrome 浏览器内核内部的两个重要模块 Blink 和 cc 内部设计和实现的一些细节。对于想要了解 Chromium 内核内部实现的同学，这两篇文章提供了不错的入门指引。在征得作者同意后，我将其翻译成中文，以馈读者。 文中部

How Blink Works 中文译文

Chromium 的工程师们写了两篇技术文章 [How Blink Works][1] 和 [How cc Works][2]，分别介绍了 Chrome 浏览器内核内部的两个重要模块 Blink 和 cc 内部设计和实现的一些细节。对于想要了解 Chrome 内核内部实现的同学，这两篇文章提供了不错的入门指引。在征得作者同意后，我将其翻译成中文，以馈读者。 文中部分术语觉得难以翻译成合适的中

Chrome 图片解码与 Image Decoding Hint

我在之前的一篇文章[Chrome 图片解码与 Image.decode API][1]，说明了为什么图片解码可能会导致非合成器动画的阻塞和如何使用 Image.decode API 来避免动画的阻塞。不过虽然 Image.decode API 给页端提供了更灵活的控制图片解码时机的能力，但是使用起来较为复杂，也容易误用，而 Image Decoding Hint 属性则更简单，容易使用，同时也满足

Chrome 图片解码与 Image.decode API

在这篇文章里面，我会对 Chrome 是何时对图片进行解码进行说明，并结合 Chrome 的渲染流水线说明为什么图片解码可能会造成动画卡顿，而新的 Image.decode API 是如何让我们控制图片解码的时机，通过预先解码来避免动画卡顿。 为了让读者更好地了解本文的内容，请阅读我之前的文章 —— [浏览器渲染流水线解析与网页动画性能优化][1]。 ## 图片解码 ### 图片

BlinkOn9 - Speed Focus for 2018

BlinkOn9 - Layered APIs

BlinkOn9 - WebAssembly

> 作者在 4 月 18~19 期间和同事一起在湾区参加了为其两天的 BlinkOn 9 会议。每次 BlinkOn 都是了解当前 Blink & Chrome 和 Web 技术演进现状和发展方向的一个不错机会，两天的会议下来大概听了 6 ～ 7 场分享，有些主题是之前已经有所了解，这次又更新了最新的进展信息；有些主题则是完全陌生，在这次 BlinkOn 上才第一次知悉。作者接下来会撰写一系列文章

BlinkOn9 - Viz Update

BlinkOn9 - Blink Rendering

作者在 4 月 18~19 期间和同事一起在湾区参加了为其两天的 BlinkOn 9 会议。每次 BlinkOn 都是了解当前 Blink & Chrome 和 Web 技术演进现状和发展方向的一个不错机会，两天的会议下来大概听了 6 ～ 7 场分享，有些主题是之前已经有所了解，这次又更新了最新的进展信息；有些主题则是完全陌生，在这次 BlinkOn 上才第一次知悉。

BlinkOn9 - WebAssembly

作者在 4 月 18~19 期间和同事一起在湾区参加了为其两天的 BlinkOn 9 会议。每次 BlinkOn 都是了解当前 Blink & Chrome 和 Web 技术演进现状和发展方向的一个不错机会，两天的会议下来大概听了 6 ～ 7 场分享，有些主题是之前已经有所了解，这次又更新了最新的进展信息；有些主题则是完全陌生，在这次 BlinkOn 上才第一次知悉。