供应信息和文章都能优化的采集软件(Android中的卡顿丢帧原因概述-低内存篇1. )

　　供应信息和文章都能优化的采集软件(Android中的卡顿丢帧原因概述-低内存篇1.

)

　　一般来说，手机厂商和App开发者都会非常重视Android手机在使用过程中的卡顿问题。因此，无论是手机厂商还是App开发商，都会非常重视口吃问题。一般会有专门的基础组或者优化组来进行优化。

　　目前市场上有一些很棒的第三方性能监控工具，比如腾讯的Matrix；手机厂商一般也有自己的性能监控解决方案。由于可以修改源代码，避免权限问题，手机厂商可以获得更多的数据，分析起来会更方便。

　　说到流畅度，其实就是操作过程中的丢帧。本来图片一秒需要更新60帧，但是如果这期间只更新了55帧，那么在用户看来就是丢帧，主观感觉就是卡住了。尤其是在帧率波动的时候，用户的感知会更加明显。丢帧的原因有很多，包括硬件层面，软件层面，还有App自身的问题。所以这部分分成四篇文章来聊一聊，我简单说一下用户感觉卡顿掉帧的原因：

　　0. Android-Methodology 中丢帧原因概述

　　1. Android-System 丢帧原因概述

　　2. Android-Application 丢帧原因概述

　　3. Android-Low memory 丢帧原因概述

　　1. 流畅度相关工作内容概览

　　作为手机厂商优化组的一员，有必要先简单介绍一下我们的工作过程，然后再开始。在系统开发过程中，Android滞后的原因有很多，但最直观的用户和测试体验是正在使用的。应用掉帧，不流畅。由于测试和用户无法直接确定卡顿的原因，bug通常是直接给我们提的，所以我们的角色更像是卡顿问题的接口人，负责分析卡顿的原因，卡顿的原因，然后将bug分配给对应的模块负责人解决，比如framework\App\multimedia\Display\BSP等。

　　因此，我们直接解决的问题并不多。我们经常使用专门的分析工具结合源代码来定位和分析问题。最常用的工具如下：

　　Systrace\strace\ftrace：从整个系统的层面看问题的大致原因 MethodTrace：可以从进程的角度以详细调用栈的形式展示Android Studio的Profile工具MAT：用于分析内存问题 Log：LogReport 捕获或者记录的Log，里面收录了很多信息，包括各种常规的Log（Main Log、System Log、Event Log、Kernel Log、Crash Log等），以及一些由系统添加的日志制造商（电源日志、性能日志等）），还包括事故发生时的截图\录制的视频等，本地复制等。

　　要确定滞后的根本原因，这需要对Android App开发\Android框架知识\显示知识\Linux Kernel知识有一定的了解，了解基本的工作流程，能够熟练使用相应的工具，区分不同的场景，以及快速找到他们问题的原因，然后与相关模块的负责人讨论优化。

　　对于一些全系统的解决方案，我们需要与相应的模块负责人一起分析解决问题。必要时，我们也会开发一些功能来解决问题。

　　2. 一些性能问题分析的工具和例程

　　应用程序滞后问题的原因有很多。在数据埋点不完善的情况下，更依赖Systrace从全局角度分析滞后的具体原因：

　　Systrace分析首先确认卡顿的App可以通过App的主线程和SurfaceFlinger的主线程信息判断卡顿对Systrace的实时分析。Systrace 的分析需要一定的知识储备：你需要知道 Systrace 的各个模块显示的内容是如何与用户交互的。您觉得对应的内容；你需要知道Systrace上各个模块的交互展示是怎样的；你需要知道Binder调用信息；需要看Kernel信息（Systrace系列以后会继续完善）如果App主线程耗时，分析App主线程原因（有app的原因卡在case）如果是系统问题，需要分析System_Server\SurfaceFlinger\HWC\CRTC\CPU等。（具体可以参考下面的系统卡死原因） TraceView+源码分析使用Systrace确定原因后，可以结合源码使用TraceView查看对应的代码逻辑。Android Studio的Profile工具可以在一个进程的基础上进行Method profile，可以打印非常详细的函数调用栈，可以对应Systrace源码分析。可以使用Android Studio进行断点调试App或Framework，观察Debug信息是否与预期一致。很多问题也需要用Log工具捕获的Log来分析。Log分析了Log中一些比较重要的点。原因，不过可以结合Systrace做一些辅助分析）截图：

　　过滤日志，在出现卡顿时找出异常日志，多抓几条Systrace，有助于确定原因。测试可以提供一些LogReport中没有的信息来分析用户当时手机的整体状态。adb shell dumpsys 活动 oomadb shell dumpsys meminfoadb shell cat /proc/buddyinfoadb shell dumpsys cpuinfoadb shell dumpsys inputadb shell dumpsys window3。通过性能数据进行数据分析

　　由于用户反馈的不确定性和内部测试的不完整性，通过分析系统或App的性能数据是改进系统的好方法。一方面不需要用户主动参与，另一方面有很多数据可以用来分析，看趋势。

　　目前国内各大手机厂商和App厂商基本都有自己的APM平台，负责监控App或系统的监控水平，做出相应的优化方案。比如腾讯的Matrix平台已经监控到以下内容，其他App厂商可以直接访问

　　由于手机厂商有代码权限，所以可以采集获取更多的数据，比如内核相关的数据：cpu load\io load\Memory load\FSync\异常监控\温度监控\存储大小监控等，每个大项中都有几十个小项。所以会有很多可以监控的数据，也可以从多个技术指标分析问题。这就需要一个在这方*敏*感*词*有丰富经验的团队来定义这些监测指标，确定最终采集哪些信息，如何分析采集到的数据等。

　　至于后续的优化工作，将考验各厂商的研发能力。正如微林在这篇文章中所说的文章：那些年我们一起经历的Android系统性能优化，目前能力比较强的手机厂商，底层的所有模块都是结合硬件进行优化的，因为归根结底是资源的配置；而一些研发能力不是很强的厂商，仍然注重根据场景配置资源。

　　4. 总结

　　这里简单介绍一下流畅度问题的一般分析思路和分析工具，由于我的方向主要是Framework和App，所以很多东西都是从上层的角度来看的，Kernel优化团队会有更好的视角。和分析。

　　您可以阅读这篇总结，了解各家厂商的优化情况。那些年，我们一起经历过的Android系统性能优化，华米OV都有涉及，以下是摘录的总结，大家可以看看

　　展望未来，我想把手机厂商分为三类：

　　一类是苹果，它自己开发芯片和核心部件，拥有自己的操作系统和生态；第二种是三星和华为，他们自己开发芯片和核心部件（当然华为和三星还是有区别的），共享Android操作系统和生态，当然三星的本土化不如华为等顶级厂商；第三类是其他安卓手机厂商，芯片和核心部件来自不同的供应商，共享安卓操作系统和生态；

　　从技术角度：

　　苹果永远站在性能的第一阵营，从硬件到OS再到APP层面的任何性能保障方案都能顺利实现；三星和华为属于第二阵营，可以在芯片-OS层面实现集成和优化；其他顶级安卓手机厂商差距不会太大。他们有多个不同的SoC供应商，解决方案也不同。很多时候不涉及芯片底层，更多是做纯软件级的战略优化，有价值但不容易形成壁垒，注意这个壁垒不容易形成是指顶级厂商，一些小厂商经常仍然有足够的能量。但我仍然期待看到更多的突破。

　　这也是流利文章系列文章中的一篇，可以点击下方链接查看本系列其他文章。

　　0. Android-Methodology 中丢帧原因概述

　　1. Android-System 丢帧原因概述

　　2. Android-Application 丢帧原因概述

　　本文知乎地址

　　由于博文交流不便，点赞或交流，可移至本文知乎界面

　　知乎-Android-Methodology中丢帧原因概述

　　关于我 && blog 关于我，真心希望和大家交流，共同进步。博客内容导航优秀博客文章记录-Android性能优化必知必知

　　一个人可以走得更快，一群人可以走得更远