learnframework的博客

您可以使用 Play Feature Delivery 和 Play Asset Delivery 来增加应用的大小，但应用大小的增加可能会对安装成功率产生负面影响，并增加卸载量，因此我们建议您遵守本页介绍的指南，尽可能缩减应用的下载大小。应用上传完毕后，Google Play 的应用服务模式会使用您的 app bundle，根据每位用户的设备配置，生成并提供经过优化的 APK，因此用户只需下载运行应用所需的代码和资源。当用户下载您的应用时，其设备会根据设备的功能和设置接收正确的 APK。

strace是一个集诊断、调试、分析于一体的Linux系统工具，它可以拦截并记录进程发起的所有系统调用（system call）以及接收到的信号。简单来说，它能让你“看见”一个程序在运行时，向内核发出了什么请求，内核又是如何响应的。系统调用是用户态程序与内核交互的唯一入口，比如读写文件（openreadwrite）、创建进程（forkclone）、网络通信（socketconnectsend）等。通过观察这些调用，我们可以精准地定位程序在哪个环节出现了问题。

本章我们沿着代码逻辑学习了应用是如何申请到画布、使用android的View系统如何绘图、绘图完成后如何提交buffer，本章所述的逻辑均是指通过android的View系统绘图的过程，也可以称其为hwui绘图流程，从上面代码流程可以知道，hwui的绘图流程是被vsync信号触发的，开始于vsync信号到达UI线程调用performTraversals函数， hwui的画面更新是被vsync信号驱动的。这句是将指令发送给GPU执行，这其中是如何“翻译”的细节笔者暂时尚未研究，这里先不做讨论。

其实安卓性能优化岗位的相关工作都是可以让对应模块的业务开发者进行完成，但是整体手机模块很多各个模块之间负责人可能各不相同，经常出现性能优化等问题需要多模块协同完成，基于这个背景公司为了整机的性能，响应速度有更好的提升，经常会设置专门的性能优化岗位，专门负责手机系统的性能优化相关的工作，这样就可以让系统整体性能优化提升更加明显，更好的性能优化协同工作，不会出现一个性能问题涉及多模块没人愿意接受，相互推诿，扯皮。2、会优化一些app启动速度，开机速度，分析一些卡顿问题，多屏问题等，整机慢等。

使用基本的布局结构会导致 最高效的布局不过，您添加到应用中的每个微件和布局 需要进行初始化、布局和绘制。例如，使用嵌套 实例 LinearLayout 会导致视图层次结构过深。此外，将多个 使用 layout_weight 的 LinearLayout 实例 参数的开销可能特别大，因为每个子参数都需要测量两次。在反复膨胀布局时，这尤为重要，例如 在 RecyclerView。本文档介绍了如何使用 布局检查器和 lint 来检查和优化布局。

通过查看该结构，您会发现 struct DIR 中 mutex_ 的偏移量为 sizeof(int) + sizeof(size_t) + sizeof(dirent*)，在 32 位设备上表示为 4 + 4 + 4 = 12 = 0xc，这样便可以找到错误所在：调用程序向 readdir 传递了一个 Null 指针。在以下示例中，尽管崩溃函数在 libc.so 内，但由于字符串函数仅在指定给它们的指针处进行操作，因此您可以推断出在调用 strlen(3) 时指定的是 Null 指针；

平时马哥也是基于上面的方法去分析对应的No Focused Window ANR问题，在工作过程中其实遇到的No Focused ANR其实也是非常非常多的类型，绝不是简单的一两种案例那么简单哈，在工作中积累了这块的ANR类型应该有多达20+种不同原因和类型，当然这里的20+种也不代表真的全部覆盖，只是这里提供给大家一些处理的经验，应该也可以覆盖%90以上的No Focused Window ANR问题。应用在绘制前卡住，或拦截了绘制，这块主要排查app的draw方法相关执行分析为啥卡住。

在实际开发工作各种类型的ANR层出不穷，之前一直也想google官方开发人员是否有解决各种ANR问题的一些文档等，主要是想看看自己平时自己分析套路是否也和google的人一样，还有就是想看看goole是否有啥分析ANR的新套路方法等，今天刚好找到了google关于各种ANR问题的详细指导文档，本来想用翻译成中文的版本，但是感觉自动翻译的其实并不是太好，所以直接上英文，马哥搬运google的干货。下面是google官方文档，底部也有原文链接。

ANR是Android稳定性问题分析的一个难点，其中比较常见的一种是窗口无焦点Not have a Focused Window，这类无焦点窗口ANR相比其他Application not response无响应更难分析。focused ANR一定是wms问题？如果对该ANR的原理不了解，会直接认为窗口焦点是WMS控制，出现无焦点就一定是WMS导致。

此指标用于测量应用生成第一帧所用的时间，包括冷启动期间的进程初始化、冷启动或温启动期间的 activity 创建，以及显示第一帧。如果您的应用正在执行延迟加载，并且初始显示不包含所有资源（例如，当您的应用从网络提取图片时），您可能需要延迟调用 reportFullyDrawn，直到应用可供使用后再调用，以便将列表填充时间纳入基准时间的计算范围。在经常使用各种app时候，大家都会有一个体验：在点击打开app展示第一帧画面时候，发现往往第一帧画面显示的内容是无法点击的，一般这个画面是个默认的内容画面。

这种糟糕的体验可能会导致用户在 Play 商店针对您的应用给出很低的评分，甚至完全抛弃您的应用。本页面提供了有助于优化应用启动时间的信息，包括启动流程的内部机制概述、如何分析启动性能，以及一些常见的启动时间问题和有关如何解决这些问题的提示。通常，onCreate() 方法对加载时间的影响最大，因为它执行工作的开销最高：加载和膨胀视图，以及初始化运行 activity 所需的对象。当应用启动时，空白启动窗口将保留在屏幕上，直到系统首次完成应用绘制。此时，系统进程会切换应用的启动窗口，让用户与应用互动。

大家做公司的性能优化部分工作时候，有一个非常关键的指标那就是和竞品对比系统各个app的冷启动优化时间，特别是针对一些主流的第三方App，因为他们Apk一般都是同一个，所以参考各个第三方app的冷启动时间，确实可以反应出手机的一个性能如何，一般情况下冷启动时间越短肯定就是性能越好。对于我们开发人员来说，最常用的肯定是方法1，2，不太可能每次优化都用摄像机来拍摄的。其实这个肯定是可以有的，方法大家应该也都可以想到，可以借助脚本进行测试，脚本进行测试结果报告对比分析等。-W参数：列出启动过程中统计到的具体数据；

其实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的浏览器。