1.Android Systrace 基础知识(8)-基于 Choreographer 的源码渲染机制详解
2.Perfetto工具使用简介
3.Android 基于 Choreographer 的渲染机制详解
4.你的debug包在Android 14变卡了吗？｜得物技术

Android Systrace 基础知识(8)-基于 Choreographer 的渲染机制详解

       Android Systrace 系列文章的第八篇深入探讨了Choreographer在渲染机制中的关键作用。这个工具旨在帮助开发者更好地理解Android Framework的解析运行流程，尤其是源码与帧绘制和主线程交互的细节。Choreographer的解析主要职责是配合Vsync，为应用提供稳定的源码消息处理时机，确保.6ms（Hz）屏幕刷新时，解析快站平台源码每一帧的源码绘制操作都在正确的时间执行，从而实现流畅的解析用户体验。

       在Android的源码早期版本中，没有Vsync机制，解析导致帧率不稳定，源码而引入Vsync后，解析结合TripleBuffer和Choreographer，源码系统通过调整Vsync周期，解析确保了fps的源码稳定帧率。Choreographer在这个过程中充当了桥梁角色，它与MessageQueue、Looper、SurfaceFlinger等紧密协作，确保了App的u盘感染源码稳定运行。

       通过Systrace和MethodTrace的分析，我们可以观察到Choreographer的工作流程，例如在滑动桌面场景中，从Vsync到来到开始绘制，Choreographer如何组织和管理这些操作。源码解析部分揭示了Choreographer的初始化过程、FrameHandler的使用，以及如何通过FrameCallback和FrameInfo来记录帧绘制信息。

       对于性能监控，Choreographer提供了FrameCallback接口，允许开发者监测App的性能，如TinyDancer就利用了这个接口计算FPS。此外，Choreographer还与APM工具结合，比如BlockCanary和SurfaceFlinger的PageFlip机制，用于深入性能分析。

       最后，厂商们也利用Choreographer进行优化，如移动事件响应提前、荒野行动锁头源码后台动画控制、帧绘制策略调整等，以适应不同屏幕刷新率和性能需求。本文通过实例和源码分析，帮助开发者更直观地理解Choreographer在Android渲染机制中的重要角色。

Perfetto工具使用简介

       Perfetto工具是Android下一代全新的统一的trace收集和分析框架，可以抓取平台和app的trace信息，是用来取代systrace的，但systrace由于历史原因也还会一直存在，并且Perfetto抓取的trace文件也可以同样转换成systrace视图，如果习惯用systrace的，可以用Perfetto UI的"Open with legacy UI"转换成systrace视图来看，Perfetto的几个主要特点如下所示：

        在讲具体的收集流程之前，可以先看一下它的整体框架图，它的进程结构，其中有几个重要的进程需要说明一下：

        暂时还没有去研究它的源码，所以还无法将上面的两种视图一一对应起来，这里列出另一种视图，只是想让大家增加对这个工具的更深一步了解，上面说了除了标准的tracepoints之外，Perfetto还可以提供很好的可扩展性，这里我们先看一下标准的tracepoints有哪些，如下图所示，相对于以前的systrace来说，我们发现Perfetto还是可以提供一些其他的功能的，例如它可以直接抓取event log了，还有Virtual memory events等等。

        在Pixel和Pixel2机型上面，traced和traced_probes这两个进程是默认开启的，但是在其他机型上面，可能需要执行如下命令才会开启这两个进程，开启这两个进程之后，才能正常抓取trace信息，开启的方式也很方便，只要设置一个属性就可了。

        执行上面的命令后，如果看到如下类似的Log，那么就说明开启成功了，也可以直接ps看有没有这两个进程。

        开启了守护进程之后，就可以执行perfetto命令行工具了，这个命令行的工具的使用方式,具体参数的含义就不一一介绍了，直接看comment就好。

        其中 --out是用来指定trace输出文件，--config 是用来指定配置的，也就是像抓多长时间，间隔多久把内存数据写回文件，抓取哪些tracepoints等等，这个config文件内容，我们可以自己手动编写，也可以用Perfetto UI网站生成，另外在Perfetto里面默认集成了一个test配置，你可以使用如下命令抓取一个使用test config的trace文件。

        抓取完后，把/data/misc/perfetto-traces/trace文件内容pull出来，然后使用Perfetto UI网站打开即可，如下所示：

        目前最方便的配置文件生成方式是使用 ui.perfetto.dev Perfetto UI来帮助生成，点开Perfetto UI的"Record new trace"之后，你会看到有很多的配置界面，如以下几个图所示：

Android 基于 Choreographer 的渲染机制详解

       Photo by Peter Thomas on Unsplash

       本文深入探讨了 Android 开发者可能不常接触，但在框架渲染流程中至关重要的 Choreographer 类。我们将从引入背景、简介、源码解析、与核心组件的关系以及手机厂商优化思路等方面进行详述，旨在帮助开发者深入了解程序每一帧运行的原理，以及提升对关键组件如 Message、Handler、Looper、MessageQueue、Measure、Layout、Draw 的php财务模块源码理解。

       了解 Choreographer 有助于开发者掌握渲染机制的核心，从而优化应用性能。Choreographer 在渲染链路中作为连接器，确保 App 以稳定的帧率运行，减少帧率波动带来的不适感。通过结合 Systrace 和 MethodTrace 工具，开发者能更直观地理解这一机制。

       在演进过程中，引入了 Vsync、TripleBuffer 和 Choreographer 机制，以提供稳定的帧率输出，使得软件层和硬件层同步工作。Choreographer 的引入，配合 Vsync 信号周期调整，控制了每一帧的绘制操作时机，确保 App 在 Hz 刷新率下稳定运行。

       Choreographer 承担着渲染流程中的重要角色，通过与 SurfaceFlinger、Vsync 和 TripleBuffer 的中枢箱体指标源码协同工作，确保了以 fps 的帧率稳定输出画面。这一机制不仅提高了用户体验，还为开发者提供了优化应用性能的途径。

       Choreographer 的初始化、单例初始化、构造函数等核心部分，以及 FrameHandler、Choreographer 初始化链等细节，均涉及到关键的代码逻辑和流程。通过源码解析，我们能深入理解 Choreographer 如何在 Android 主线程中组织和管理每一帧的绘制过程。

       Choreographer 处理一帧的逻辑主要围绕 doFrame 函数展开，包括计算掉帧、记录帧绘制信息、执行回调等关键步骤。通过 Systrace 观察这一流程，可以清晰地了解 Choreographer 如何组织和优化每一帧的渲染。

       Choreographer 与 APM（应用性能监控）工具相结合，提供了丰富的性能监控接口，如 FrameCallback 和 FrameInfo，帮助开发者监控和优化应用性能。此外，Choreographer 还与 MessageQueue 和 Looper 等核心组件紧密关联，通过自定义 MessageLogging 等特性，增强了性能监控和优化能力。

       针对移动事件优化、后台动画优化、帧绘制优化、应用启动优化以及高帧率优化，手机厂商通过修改源码，实现了对 Choreographer 的定制化增强，提高了系统性能和用户体验。这些优化策略展示了 Choreographer 在现代移动设备中的重要作用。

       总之，Choreographer 是 Android 渲染链路中的关键组件，它通过稳定的帧率输出、优化的渲染流程以及与核心组件的高效协同，为开发者提供了强大的工具，以提升应用性能和用户体验。深入理解 Choreographer，将有助于开发者在实际应用中实现性能优化，实现更流畅、高效的移动应用。

你的debug包在Android 变卡了吗？｜得物技术

       一、背景

       在使用Android 时，突然发现debug包运行变卡顿，经过排查发现是Android 系统中debug包执行效率降低导致。

       二、问题排查纪录

       使用systrace、dutrace等工具进行常规排查，发现CPU空闲，主线程无明显阻塞，问题出在方法执行耗时。

       在使用dutrace工具时发现异常现象，怀疑与解释执行方式有关。分析源码后，发现Android 版本使用了switch解释执行方式，而Android 、版本则使用mterp或nterp，怀疑是解释执行导致卡顿。

       尝试修改debuggable属性，测试结果表明，与解释执行方式相关，但不是直接原因。接着怀疑是native方法执行耗时问题，再次排查，发现问题主要出在debuggable属性的影响。

       分析AndroidManifest文件和Process类，发现debuggable属性影响了runtimeFlags，导致系统启动时加载了额外的flag，这可能是问题源头。

       尝试通过hook系统进程参数，发现移除DEBUG_JAVA_DEBUGGABLE后，debug包运行流畅，而加上此标志后，所有应用变卡，确认问题是由于DEBUG_JAVA_DEBUGGABLE导致的。

       继续分析后发现，DeoptimizeBootImage方法将bootImage中的AOT代码转换为java可调试，导致方法执行切换到switch解释执行，这是问题的关键。

       进一步分析发现，即使hook了CanRuntimeUseNterp方法，方法执行依然切换到switch解释执行，因此确认是bootImage中的方法在Android 中执行效率低下的问题。

       验证问题为系统层面的问题，并通过社区反馈和补全问题报告，等待官方修复。

       三、临时解决

       尝试在等待修复的同时，通过修改代码逻辑，使用UpdateEntrypointsForDebuggable方法，根据规则重新设置方法执行方式，以绕过问题，结果发现流畅度提高。

       进一步思考发现，虽然问题解决，但仍有部分卡顿现象，分析后决定在调用UpdateEntrypointsForDebuggable前将RuntimeDebugState设置为非debugable状态，调用后恢复为debugable状态，最终实现了流畅的debug包体验。

       四、最后

       在后续的分析中，发现高通工程师已确认Google将在Android 中修复此问题，对于海外版本的Android 设备，Google计划通过com.android.artapex模块更新解决。国内用户则需等待手机厂家主动合入修复。

       总结，通过上述方法，临时解决了debug包在Android 中的卡顿问题，并提供了相关代码示例供其他开发者参考。