learnframework的博客

其实Fallbackhome出来这些年，各个手机厂商们也在不断尝试优化去除Fallbackhome的优化。从以前的压根不优化Fallbackhome显示到加入相关的美化版的过渡动画Fallbackhome，再到彻底去除Fallbackhome直接让Launcher进行运行，也可以发现虽然一直有尝试这块的优化，但是依然还是和我们最初的认知没有任何差异。依然是桌面不能未解锁启动是因为有其他很多第三方的依赖，也就是只要可以处理好这块的依赖，让他们进行延时解锁后进行启动，让桌面大部分功能可以在未解锁时候启动。

在android开发中经常会有需求来分析一些内存问题，比如内存泄露，内存过大等，针对java相关的进程其实内存都还比较好定位，因为大家app开发时候都会经常使用Android Studio抓取hprof内存快照，然后与MAT工具结合起来一起分析定位内存泄露相关的问题。这里使用一个demo来测试，使用在onCreate中进行Bitmap的构造，看看是否可以看到它的一个内存情况。这里就需要看你前面config设置的是哪个进程名字，然后去对应进程中找下面的Heap Profile。

例如，调度器可能宁愿等待一段时间，希望当前 CPU 上运行的线程进入空闲状态，从而避免跨 CPU 迁移，这在开销和功耗方面可能代价更高。sched_switch 事件仅在线程处于 R(可运行) 状态且正在 CPU 运行队列上运行时发出，而 sched_waking 事件则在任何导致线程状态改变的事件发生时发出。表中的每一行显示了特定线程(utid)开始运行的时间(ts)、在哪个核心上运行(cpu)、运行了多长时间(dur)，以及它停止运行的原因：end_state。那么cpu片段这块的信息到底如何看呢？

错误地强制扫描包含“abc”的所有 /sys/devices 子目录，导致 /sys/devices/abc 和 /sys/devices/xyz/abc 都成为匹配项。支持无缝 (A/B) 更新的设备在首次启动时会极大地受益于文件系统调整（例如，Google Pixel 的启动时间缩短了 20 秒）。在早期阶段，仅装载不需要运行检查的分区（例如 system/ 和 vendor/），然后启动启动动画服务及其依赖项（例如 servicemanager 和 surfaceflinger）。

如果工作负载使用的 CPU 资源较多，则时钟速度会提高，且工作负载最终会移至更大的核心。如果您的应用将此 API 与热状态监控功能结合使用，则可以为操作系统提供更明智的提示，而无需使用忙循环和其他可能导致受限制的编码方法。每当目标工作时长发生变化时（例如，当播放器选择不同的目标帧速率时），请调用 updateTargetWorkDuration 方法来告知系统，以便操作系统可以根据新目标调整资源。例如，如果您稍后创建了物理线程，并需要将其添加到会话中，则可以使用此 setThreads API。

如果 getThermalHeadroom() 返回的值大于 1.0，则实际状态可能是 THERMAL_STATUS_SEVERE 或更高，请立即减少工作负载并保持较低的工作负载，直到 getThermalHeadroom() 返回较低的值。isAPISupported() 会检查对 getThermalHeadroom 的第一次调用的值，以确保其不为 0 或 NaN，如果第一个值为 0 或 NaN，则会跳过使用该 API。如果您想读取热余量范围的简化分组，可以查看热状态，以了解当前设备上的热余量值。

这些perfetto上展示的执行块slice，其实一般都是在aosp的原生代码中进行的埋点，简单说看到每个slice其实都是有对应的埋点代码，当然这个代码可能是java，c++等，而且哪怕都是java和c++这种也分为是基于源码编译的java，c++代码还是说基于sdk和ndk的java、c++代码，这些都是有差异的，所以针对这些不同的代码和编译情况今天都进行汇总，给大家展示应该如何在自己程序埋入perfetto的slice。跟踪一个动画的开始与结束，可以看出它的执行时长，和同步执行那种单线程完全不一样。

例如高通基线上在2018年左右就有一笔提交，优化应用进程侧的Input事件处理流程，大概思路就是识别应用UI线程中收到第一个ACTION_DOWN的Touch事件后，调用sendMessageAtFrontOfQueue接口在应用UI线程的消息队列的最前面插入一帧doFrame绘制任务，这样界面不用等待下一个Vsync的信号的到来就能直接上帧显示，从而减少整个Input触控事件的响应延迟。从微博应用对应的“wq”队列可以看到，应用进程一直有没有完成处理消费的Input事件，说明问题在微博应用进程侧；

前面讲解perfetto的查看信息时候，没有重点讲解cpu区域的内容，今天本文将补充讲解perfetto/systrace的CPU Trace信息详解，同时以前有讲解如何抓取开机时刻的perfetto/systrace的方法，但是也有同学反馈使用了对应config后，没有抓取到对应的cpu相关信息，本文针对上面两个知识来进行补充讲解。相比perfetto而言，systrace对cpu展示内容还多了，不过其实多的地方相对不那么核心，主要内容还是cpu的执行片段内容和cpu频率最重要。

大家都可能为了提高开机启动速度，或者说不想让用户看到Fallbackhome画面也好，都会有想办法去除Fallbackhome的需求或者想法，但是大家需要注意的是android以前也是没有Fallbackhome的，也是指导出现了CE加密才出现的，本质上Fallbackhome就是作为系统还没解锁前作为launcher的Activity进行启动，不然系统啥Activity都无法启动的话，就会一直处于开机动画，无法进入系统。那么最后是否可以去除Fallbackhome呢？

【代码】perfetto抓取方式汇总官方英文文档：Quickstart: Record traces on Android。

上面其实看出，本质上就是下载个tracebox文件，然后执行这个tracebox文件既可以，但是下载这个tracebox文件一般国内网络都不行哈，所以这里可能又会阻碍一批人，不过这里马哥给大家提供一个 ubuntu 64位可以直接执行的文件。最后发现确实模拟器设备用WebUsb方式无法发现设备，原因暂时没有追究，不过尝试实体机手机确实是可以发现的，插上实体手机后就会有相关提示，当然前提需要手机需要开启usb调试相关。点击这种“ADB + WebSocket”方式后，发现有一堆错误提示，无法链接发现设备。

在很多同学做开启时间性能优化相关工作时候，经常用的比较多的方法肯定是抓取开机的perfetto或者systrace方法，这种方法当然是比较准确，一般抓取这个时候都是开始准备比较细微的局部优化。AMS启动完成后开始屏幕，从此以后屏幕才能响应用户的触摸，它在WindowManagerService发出退出开机动画的时间节点之前，而真正退出开机动画还会花费少许时间，具体依赖animation zip 包中的desc.txt。上面都是毫秒为单位，有了这个时间指标就可以拿来作为优化前后对比，或者各个机器之间的䶏。

正常我们抓取perfetto或者systrace都是采用的手动抓取方式，但是手动抓取方式一般适用于一些必现的场景，但是经常一些性能问题都不是必现的。本文就来带大家简单实现一个自动化监测系统性能，当性能低下时候可以实现对系统进行perfetto的抓取trace，方便分析问题。这里为了简单起见，我们就简单认为cpu使用率为性能低下的参考指标，也就是cpu使用率太高就代表当前系统性能低，要触发对应的perfetto来抓对应trace。1、cpu使用率过高，可以代表当前cpu负载太大，当前系统可能存在卡顿。

难道都需要一个去网络找这个功能要抓取应该在perfetto后面加上什么参数么，这样肯定太低效，而且也很可能是错的，所以最权威的还是看看官网的是如何配置这些抓取参数。那么现在已经有了要抓取数据的配置config后，应该如何使用这个config进行trace的抓取呢？配置参数其实都不需要一个个手动添加，我们只需要在官网配置页面操作一个个开关按钮就可以。或者是分析trace时候可以看到调用的一些堆栈，都是一些新功能，需要额外配置参数。最常见的的就是ATRACE的TAG开启，这个也是我们老方法也会开启的。

想要抓取开机启动整个过程的trace，放到perfetto上进分析，但是发现开机过程中无法连接上设备，没办法抓到完整的trace，所以perfetto无法分析出整个开机过程。准备好一个config文件，主要用于配置perfetto抓取时候的相关配置，比如要抓哪些tag等，是否也抓取日志等，这个配置官网给了一个最简单的版本。push boottrace.pbtxt文件到/data/misc/perfetto-configs/boottrace.pbtxt。重启设备，获取perfetto的trace文件。

正常在产生ANR时候，都会发送一个SIGNAL_QUIT信号给app进程来实现退出，所以就是抓住这个信号的发送与接受作为切入点来实现监测ANR。

因此，在 UI 主线程相对繁忙时，通过 IdleHandler 来分摊任务，可以让系统先处理用户的核心交互，就比如onCreate是生命周期方法，如理里面初始化太多东西影响冷启动速度，针对一些可以延后不那么紧急任务可以待系统空闲时再处理任务，充分利用 CPU 空闲时间。它允许开发者在主线程处于空闲时，执行一些低优先级的任务。3、如果IdleHandler的queueIdle返回false则会从mIdleHandlers删除，下次空闲就不会在执行这个IdleHandler，否则true的话会每次空闲都执行。

近来有学员朋友询问到了一个他做性能优化时候的一个疑问，那就是他不知道自己的手机设备上的一个cpu情况，他想要知道目前的平台哪些是cpu的大核哪些是cpu的小核，问马哥有没有啥命令或者方法进行查看，这样就可以不需要通过问其同事了，每次问都容易忘记，而且每个平台也不一样。一般平时常说的cpu大小核情况，其实说的是cpu一般情况下都是有多个核心的，和我们电脑上cpu是一个情况，但是多核心为了综合性能和功耗上都兼顾，就不能说所有核心都是大核或者小核，一般都是大小核都是共同存在的。cpu的4-7属于大核。

首先这个service call就是直接调用到SurfaceFlinger这个service的onTransact方法，1041代表是code，i32代表是data的int类型，1和0代表就是值。那么选着Transaction选项后抓取Winscope，看看winscope_proxy.py程序的相关输出，看看有没有线索可以查到是如何获取系统的相关Transaction数据。在使用Winscope过程经常会有如下的一些选项供我们进行选择，不同的选项最后就会展示不同的数据项出来。具体这些数据是哪里来的呢？

针对开机时间优化，如果其他地方实在做不出来更多优化后，可以考虑看看自己开机动画是否有优化的空间，确定有优化空间后再考虑具体方案进行，这里注意一定要考虑交互体验等结合起来。不然优化后会引入一堆的闪黑，开机动画播放不完整等问题就得不偿失。

有针对native的c++代码，也有系统app的java代码，但是缺少了普通第三方app如何打印trace，有学员朋友在第三方app尝试打印trace时候发现了一些问题，那就是使用perfetto抓取的trace死活没有自己打印的trace，马哥这边经过验证也确实有存在相关的问题，下面针对第三方app没办法打印trace问题来进行详细的分析。下面分别分析一下普通tag和ATRACE_TAG_APP是如何进行设置的，这里为了简单方便拿atrace代码来分析。//trace代表结束，与上面方法成对出现。

开机启动相关的详细信息，一般都是可以通过logcat中查看boot_progress相关查看，这种方式查看相对不那么方便，毕竟开机过程中涉及的进程较多，要查看也较多，而且还经常需要查看代码才可以对应起来，但有另一种方式可以通过看bootchart方式更加直观。最重要就是把pybootchartgui直接变成~/demos/bootchart/pybootchartgui.py。打包好成了 bcl.tar.gz文件，再进行导出用bootchart.jar进行解析生成图片。

一般perfetto看trace时候都会针对某一个进程进行查看其运行，因为perfetto/systrace都是以进程为单位进行划分的,每个进程又分为若干个线程，接下来又是主要看一个个的线程情况。比如，当一个进程向磁盘读写数据时，为了保证数据的一致性，在得到磁盘回复前，它是不能被其他进程或者中断打断的。这个部分和线程没啥关系，即不是说有单独一个线程在专门计数这个，可以理解为一个程序里面全局的一个变量值展示，比如在surfaceflinger的vsync时候就用到了。通常是低内存导致等待、各种各样的内核锁。

正因为有了系统中各个地方埋下的这些tag，才让我们可以根据这些方法tag分析出整个系统的运行情况。但是大家有没有想过，请问这些tag是怎么打上去的？如果我们自己要打印自己方法的tag应该怎么搞？

近来有一些同学反馈性能分析，现在大部分都是其实已经开始使用perfetto了，连sdk上都已经找不到哦systrace相关工具，让马哥可以分享一些这个相关内容，其实以前企业里面那时候大部分都是使用老版本systrace的，相比新版本的perfetto确实功能上要差一些，今天就带大家来探索一下相关的perfetto抓取方法。这里没有采用chrome浏览器直接抓取方式，而是使用了的源码的中自带的record_android_trace工具。以上抓取后直接自己会打开相关的chrome的浏览器。