愿历尽千帆 归来仍少年

愿历尽千帆 归来仍少年

优化实践:从系统层面优化应用启动速度
应用的启动表现特别是冷启动的速度,是用户对App的第一印象。很多时候也会被评测机构用来测试一个手机性能的依据,所以对启动速度的优化一直以来是App和手机厂商发力的重点 故事背景最近,测试提了很多应用启动速度落后于竞品荣耀x20的问题单以其中的支付宝为例, 如下是测试提供的支付宝冷启数据(通过高速相机,以手指松开为起点,以首页内容加载出为结束点) 从高速相机均值数据上,我们的机器上冷启支付宝比竞品机慢了29%,另外通过实测同时打开,直观感受上发现绝大部分时候确实慢于竞品机。顺便说一句:测试冷启速度最佳方式是通过高速相机,这种方式最贴近用户实际感受,其次便是通过Systrace,但是Sy...
Systrace角度: 拆解分析应用的启动流程
上周看了一个支付宝启动速度逊色于对比机的案例,花了些时间整理了下这个过程。应用启动过程中牵扯的知识点较多,基本涵盖了Android几大重要的子系统,非一篇文章能够讲清。本文将以支付宝为例,介绍下从input事件触发到首页帧显示完成的整个流程,后面会单独成文介绍与竞品的差异分析。 本文深受androidperformance系列文章启发 测试步骤 使用user版本,开机后连接信号好的WIFI网络,清理后台所有程序。登录支付宝账号后先启动几次,最后再forceStop 手机放置五分钟后,确保机器未发热,此时打开Systrace录制,通过高速相机拍摄,点击icon冷启,再forceStop下,...
案例分析:打开应用后操作界面无响应(Systrace)
问题现象打开应用(热启动)后,概率性出现手指滑动界面无任何响应(界面控件支持上下滑动) Systrace角度分析先看下应用区域帧绘制的情况 这个时间段除了开头的几帧,后面几乎是空白的,复现时手指明明是一直滑动的。 先确认下input事件是否正常,在分析input事件流转是否正常之前 我们先简单的介绍下input事件大概的流转过程 1.触摸屏每隔几毫秒扫描一次,如果有触摸事件,那么把事件上报到对应的驱动 2.InputReader 读取触摸事件交给 InputDispatcher 进行事件派发 3.InputDispatcher 将触摸事件发给注册了 Input 事件的 App 4.a...
第三视角: 一个ART GC的优化故事
前言从事过整机性能优化的同事,在实际项目上相信都遇到过GC引起的性能问题。有了上一篇文章的铺垫,阅读本文将会比较轻松。笔者在梳理GC这块的代码过程中,深感其复杂并非一蹴而就,如果你对其某处代码的设计缘由不甚理解,不妨试着去追踪它的提交记录。通过其一系列的patch更新以及comment,跟着提交owner的思路历程,便可以了解这个”成品”是如何被加工出来的。 故事的缘起笔者在梳理GC这块的代码时,偶然看到一处友商的提交,不禁有点好奇。为了探究其修改的缘由,仔细阅读了这笔修改的提交更新以及所有的comment之后,觉得其中一些思路对我们有启发作用,故而决定将这个思路过程尽可能的还原出来。P...
对Android S ART GC的源码梳理
前言本文是GC系列文章的首篇,主要为下一篇《第三视角: 一个ART GC优化的故事》文章做铺垫。本文将根据下面的大纲,简单的介绍下GC相关的基础知识,GC这块的内容较多,也相对较为复杂。如果想要研究清楚细节,需要花费较多的时间,也需要有读者有足够的耐心和相关知识背景。本文深受ART虚拟机 | GC的触发时机和条件一文的启发 文中涉及代码均摘自Android S。 大纲 研究ART GC目的 ART GC诞生背景 里程碑(引入CC) ART GC重要特性 ART GC类别划分 Multiplier的引入 堆可分配字节数的计算 GC触发阈值的计算 从Systrace角度看GC 参数修改策略 ...
对进程压缩消费Zram速度的优化
从全局看Zram 修改演变历程 小结当前的修改方案可能不是最优方案,但是解决了之前遇到的实际问题,后面如果遇到新的问题可能还会进行调整。 Have a good day~
AMS锁严重竞争导致的整机卡顿
日志抓取在问题机器上抓了一份Systrace1.操作步骤: 进入设置界面滑动再退出2.问题现象: 进入设置出现较长时间白屏,退出时有拖影,下拉状态栏尤为卡顿,解锁亮屏很慢。 问题分析从下图可以看到进入设置时,Resume耗时近400ms,主要耗费在等binder上来到对端1188_19线程所在区域,看下这个时间点1188_19在做什么操作?1188_19是SystemServer中的线程,从上图可以看出,它在等AMS锁到这里大致梳理如下1.进入设置应用走到onResume环节时,调用到AMS的registerReceiverWithFeature注册广播,这是应用启动过程中很常见的操作,...
GC超时导致的后台应用崩溃问题分析
写在前面这个问题之所以会拿出来仔细分析,一方面是因为这个问题不是简单的应用崩溃而是框架层的报错,另一方面是因为希望通过这个问题梳理下后台GC的超时检测机制怎样的,这样我们后面在应用层如果重写finalize方法回收时会考虑的更加全面点。 问题背景复现概率: 偶现问题版本: Android R问题现象: 处于微信界面,突然弹出王者荣耀停止运行 初步分析拿到问题日志后,先看下报错的堆栈123456709-02 20:53:26.679 2073 2089 E AndroidRuntime: FATAL EXCEPTION: FinalizerWatchdogDaemon09-02 20:...
从tcpdump看miracast的play流程(工具篇)
前言:基于高通平台,其他平台都是类似的本文作为工具篇,记录下来的目的是以便后续如再接触投屏工作能够快速对照上手 当我们开始准备连接sink设备时,开始的时候,source会创建一个socket监听着并等待sink端过来连接,sink端会触发”connect”的socket函数并开始tcp 握手之路,这个时候source接收到之后,它会触发”accept”的socket函数来处理sink发过俩的连接请求 开始是握手 Key Message #1~#4 RTSP connect M1~M8: DHCP ACK 如果这里DHCP Discover -> DHCP ACK耗时超过 5s, ...
一次SystemServer OOM导致的系统重启分析之路
测试步骤MTBF测试跑出来的机器重启,先解释下何为MTBF?MTBF测试(Mean Time Between Failure)主要测试终端在连续工作状态下,出现死机、重启、冻屏、应用强制关闭等严重故障的概率。通过在一个周期内以自动化方式反复执行规定用例,记录测试过程中被测终端出现的故障数 复现概率1/200 问题现象机器出现重启,并自动给出源头是OOM导致的结论 初步分析正常步骤先看bugreport确定下是否是OOM导致的重启,搜索关键字”system_server_crash”或”am_crash”1234567892020-12-07 10:56:18 system_server_...
avatar
Steven li