linux内存分析工具linux内存工具
linux如何看内存颗粒信息？查看内存信息（显示插槽个数和每个插槽里内存条的分析大小）
dmidecode-tmemory|grepSize查看内存条厂家dmidecode-tmemory|grepManufacturerfree查看当前内存使用情况
linux下有什么检测内存溢出的工具？
内存泄漏指由于疏忽或错误造成程序未能释放已经不再使用的内存的情况。内存泄漏并非指内存在物理上的源码消失，而是分析应用程序分配某段内存后，由于设计错误，源码失去了对该段内存的分析借书小程序源码控制，因而造成了内存的源码浪费。
可以使用相应的分析软件测试工具对软件进行检测。
1.ccmalloc－Linux和Solaris下对C和C++程序的源码简单的使用内存泄漏和malloc调试库。
2.Dmalloc－DebugMallocLibrary.
3.Electric
Fence－Linux分发版中由BrucePerens编写的分析malloc()调试库。
4.Leaky－Linux下检测内存泄漏的源码程序。
5.LeakTracer－Linux、分析Solaris和HP-UX下跟踪和分析C++程序中的源码内存泄漏。
6.MEMWATCH－由Johan
Lindh编写，分析是源码一个开放源代码C语言内存错误检测工具，主要是通过gcc的precessor来进行。
7.Valgrind－DebuggingandprofilingLinuxprograms,aimingat
programswritteninCandC++.
8.KCachegrind－Avisualizationtoolfortheprofilingdata
generatedbyCachegrindandCalltree.
9.Leak
Monitor－一个Firefox扩展，能找出跟Firefox相关的泄漏类型。
.IELeakDetector
(Drip/IESieve)－Drip和IESieveleak
detectors帮助网页开发员提升动态网页性能通过报告可避免的因为IE局限的内存泄漏。
.WindowsLeaks
Detector－探测任何Win应用程序中的任何资源泄漏(内存，句柄等)，基于WinAPI调用钩子。
.SAPMemory
Analyzer－是一款开源的JAVA内存分析软件，可用于辅助查找JAVA程序的内存泄漏，能容易找到大块内存并验证谁在一直占用它，它是基于Eclipse
RCP(RichClientPlatform)，可以下载RCP的独立版本或者Eclipse的插件。
.DTrace－即动态跟踪Dynamic
Tracing，是一款开源软件，能在Unix类似平台运行，用户能够动态检测操作系统内核和用户进程，以更精确地掌握系统的资源使用状况，提高系统性能，减少支持成本，并进行有效的调节。
.IBMRationalPurifyPlus－帮助开发人员查明C/C++、托管.NET、Java和VB6代码中的性能和可靠性错误。PurifyPlus
将内存错误和泄漏检测、应用程序性能描述、代码覆盖分析等功能组合在一个单一、完整的工具包中。
.ParasoftInsure++－针对C/C++应用的运行时错误自动检测工具，它能够自动监测C/C++程序，发现其中存在着的内存破坏、内存泄漏、指针错误和I/O等错误。并通过使用一系列独特的技术（SCI技术和变异测试等），彻底的检查和测试我们的代码，精确定位错误的准确位置并给出详细的诊断信息。能作为Microsoft
VisualC++的一个插件运行。
.CompuwareDevPartnerforVisualC++BoundsChecker
Suite－为C++开发者设计的运行错误检测和调试工具软件。作为MicrosoftVisualStudio和C++6.0的一个插件运行。
.ElectricSoftwareGlowCode－包括内存泄漏检查，code
profiler，函数调用跟踪等功能。给C++和.Net开发者提供完整的错误诊断，和运行时性能分析工具包。
.CompuwareDevPartnerJava
Edition－包含Java内存检测,代码覆盖率测试,代码性能测试,线程死锁,分布式应用等几大功能模块。
.QuestJProbe－分析Java的内存泄漏。
.ej-technologiesJProfiler－一个全功能的Java剖析工具，专用于分析J2SE和J2EE应用程序。它把CPU、执行绪和内存的剖析组合在一个强大的应用中。JProfiler可提供许多IDE整合和应用服务器整合用途。JProfiler直觉式的GUI让你可以找到效能瓶颈、抓出内存泄漏、并解决执行绪的问题。4.3.2注册码：A-G#F-1olm9mv1i5uuly#
.BEAJRockit－用来诊断Java内存泄漏并指出根本原因，专门针对Intel平台并得到优化，能在Intel硬件上获得最高的性能。
.SciTechSoftwareAB.NETMemory
Profiler－找到内存泄漏并优化内存使用针对C#，VB.Net，或其它.Net程序。
.YourKit.NETJavaProfiler－业界领先的Java和.NET程序性能分析工具。
.AutomatedQAAQTime－AutomatedQA的获奖产品performanceprofiling和memory
debugging工具集的下一代替换产品，支持Microsoft,Borland,Intel,Compaq和
GNU编译器。可以为.NET和Windows程序生成全面细致的报告，从而帮助您轻松隔离并排除代码中含有的性能问题和内存/资源泄露问题。支持.Net
1.0,1.1,2.0,3.0和Windows/位应用程序。
.JavaScriptMemoryLeakDetector－微软全球产品开发欧洲团队(GlobalProduct
Development-Europeteam,GPDE)
发布的一款调试工具，用来探测JavaScript代码中的easy源码审计系统内存泄漏，运行为IE系列的一个插件。
如何限制linux所有进程可使用的总内存？
下面的shell脚本可以实时的监控系统中各个进程的CPU和内存的占用情况，用于限制进程CPU占用率更加合理。
#!/bin/shPIDS=`top-bn1|grep^*|awk’{ if($9>||$>id-u$2>)print$1}’`forPIDin$PIDSdorenice+$PIDechorenice+$PIDdone能够将这个脚本放到cron中运行，比如每分钟检查一次，只需以root身份添加crontab项：
#crontab-e*****limit.sh以后每个一分钟就会检查一次，调整占用%以上CPU或%内存的进程的nice值，从而使这样的进程优先级变低，被调度的机会减少，同时会向root发邮件提示该进程被调整过。
但是，限制内存使用最好还是用PAM，RedHat能够在/etc/security/limits.conf中配置。
如何让linux生成内存dump？
在Linux上只要打开coredump文件开关，当程序crash时系统生成相应的core文件。下面是简单的一些步骤：
1.查看当前是否已经打开了此开关通过命令：ulimit-c如果输出为0，则代表没有打开。如果为unlimited则已经打开了,就没必要在做打开。
2.通过命令打开ulimit-cunlimited.然后通过步骤1，可以监测是否打开成功。
3.如果你要取消，很简单：ulimit-c0就可以了通过上面的命令修改后，一般都只是对当前会话起作用，当你下次重新登录后，还是要重新输入上面的命令，所以很麻烦。我们可以把通过修改/etc/profile文件来使系统每次自动打开。步骤如下：1.首先打开/etc/profile文件一般都可以在文件中找到这句语句：ulimit-S-c0>/dev/null2>1.ok，根据上面的例子，我们只要把那个0改为unlimited就ok了。然后保存退出。2.通过source/etc/profile使当期设置生效。3.通过ulimit-c查看下是否已经打开。其实不光这个命令可以加入到/etc/profile文件中，一些其他我们需要每次登录都生效的都可以加入到此文件中，因为登录时linux都会加载此文件。比如一些环境变量的设置。还有一种方法可以通过修改/etc/security/limits.conf文件来设置，这个方法没有试过，也是网上看到。不过上面两种就可以了！最后说一下生成coredump文件的位置，默认位置与可执行程序在同一目录下，文件名是core.***，其中***是一个数字。coredump文件名的模式保存在/proc/sys/kernel/core_pattern中，缺省值是core。通过以下命令可以更改coredump文件的位置(如希望生成到/tmp/cores目录下)echo“/tmp/cores/core”>/proc/sys/kernel/core_pattern设置完以后我们可以做个测试，写个程序，产生一个异常。然后看到当前目录会有个core*的文件。
Linux释放内存页由什么程序实现？
释放内存页由命令free来实现。
tracert工作原理&路由原理
1:1 <1 ms <1 ms <1 ms proxy.huayuan.hy [...1]
2 * ms ms ..2.3
3 ms ms ms ...
4 ms ms ms ..7.
5 ms ms ms ..3.
6 ms ms ms ..3.
7 ms ms ms xd--5-a8.bta.net.cn [...5]
Trace complete.
看一下上面这个过程 应该不用解释了
下面我们来分析一下 我们是怎么看到这个回显的
大家都知道我们所发送的tracert数据包 属于icmp数据包的一种
关于ttl的概念不知道能否理解
ttl 就是生存时间的意思 也就是我们所发送的数据包 在转发过程中的寿命问题
很好理解 如果寿命为0的话 就不能到达目的地 每经过一个三层设备我们的数据包的
ttl值都会减一 如果减到0 就证明不能到达就会给我们的源主机一个回应显示
并告知源主机 在哪个三层设备将这个生存值置0的 然后将这个三层设备的ip地址转发给
源主机
上面我们说的是ttl的一个原理和作用
下面我们来说 tracert包的原理
我们发送TRACERT包时 第一次的包的ttl值为1 这样到第一个三层设备那就会给
源主机一个回应 并告知其IP
依次类推 第二次发送的时候的TTL值等于2
第三次为3 默认最大hop为
也就是说ttl最大升到
这样我门就能清楚的看到 我们的数据包是怎么到达目的地的
2:当IP子网中的一台主机发送IP分组给同一IP子网的另一台主机时，它将直接把IP分组送到网络上，对方就能收到。而要送给不同IP子网上的主机时，它要选择一个能到达目的子网上的路由器，把IP分组送给该路由器，由路由器负责把IP分组送到目的地。如果没有找到这样的路由器，主机就把IP分组送给一个称为“缺省网关（default gateway）”的路由器上。“缺省网关”是每台主机上的一个配置参数，它是接在同一个网络上的某个路由器端口的IP地址。
路由器转发IP分组时，只根据IP分组目的IP地址的网络号部分，选择合适的端口，把IP分组送出去。同主机一样，路由器也要判定端口所接的是否是目的子网，如果是，就直接把分组通过端口送到网络上，否则，也要选择下一个路由器来传送分组。路由器也有它的缺省网关，用来传送不知道往哪儿送的IP分组。这样，通过路由器把知道如何传送的IP分组正确转发出去，不知道的IP分组送给“缺省网关”路由器，这样一级级地传送，IP分组最终将送到目的地，送不到目的靓号源码开源地的IP分组则被网络丢弃了。目前TCP／IP网络，全部是通过路由器互连起来的，Internet就是成千上万个IP子网通过路由器互连起来的国际性网络。网络称为以路由器为基础的网络（router based network），形成了以路由器为节点的“网间网”。在“网间网”中，路由器不仅负责对IP分组的转发，还要负责与别的路由器进行联络，共同确定“网间网”的路由选择和维护路由表。路由动作包括两项基本内容：寻径和转发。寻径即判定到达目的地的最佳路径，由路由选择算法来实现。由于涉及到不同的路由选择协议和路由选择算法，要相对复杂一些。为了判定最佳路径，路由选择算法必须启动并维护包含路由信息的路由表，其中路由信息依赖于所用的路由选择算法而不尽相同。路由选择算法将收集到的不同信息填入路由表中，根据路由表可将目的网络与下一站（nexthop）的关系告诉路由器。路由器间互通信息进行路由更新，更新维护路由表使之正确反映网络的拓扑变化，并由路由器根据量度来决定最佳路径。这就是路由选择协议（routing protocol），例如路由信息协议（RIP）、开放式最短路径优先协议（OSPF）和边界网关协议（BGP）等。
转发即沿寻径好的最佳路径传送信息分组。路由器首先在路由表中查找，判明是否知道如何将分组发送到下一个站点（路由器或主机），如果路由器不知道如何发送分组，通常将该分组丢弃；否则就根据路由表的相应表项将分组发送到下一个站点，如果目的网络直接与路由器相连，路由器就把分组直接送到相应的端口上。这就是路由转发协议（routed protocol）。
路由转发协议和路由选择协议是相互配合又相互独立的概念，前者使用后者维护的路由表，同时后者要利用前者提供的功能来发布路由协议数据分组。
VC中release和debug版本的区别?
Debug通常称为调试版本，它包含调试信息，并且不作任何优化，便于程序员调试程序。Release称为发布版本，它往往是进行了各种优化，使得程序在代码大小和运行速度上都是最优的，以便用户很好地使用。
Debug 和 Release 的真正秘密，在于一组编译选项。下面列出了分别针对二者的选项（当然除此之外还有其他一些，如/Fd /Fo，但区别并不重要，通常他们也不会引起 Release 版错误，在此不讨论）
Debug 版本
参数 含义
/MDd /MLd 或 /MTd 使用 Debug runtime library (调试版本的运行时刻函数库)
/Od 关闭优化开关
/D "_DEBUG" 相当于 #define _DEBUG,打开编译调试代码开关 (主要针对assert函数)
/ZI 创建 Edit and continue(编辑继续)数据库，这样在调试过程中如果修改了源代码不需重新编译
/GZ 可以帮助捕获内存错误
/Gm 打开最小化重链接开关， 减少链接时间
Release 版本
参数 含义
/MD /ML 或 /MT 使用发布版本的运行时刻函数库
/O1 或 /O2 优化开关，使程序最小或最快
/D "NDEBUG" 关闭条件编译调试代码开关 (即不编译assert函数)
/GF 合并重复的字符串， 并将字符串常量放到只读内存， 防止被修改
实际上，Debug 和 Release 并没有本质的界限，他们只是一组编译选项的集合，编译器只是按照预定的选项行动。事实上，我们甚至可以修改这些选项，从而得到优化过的调试版本或是带跟踪语句的发布版本。
哪些情况下 Release 版会出错
有了上面的介绍，我们再来逐个对照这些选项看看 Release 版错误是怎样产生的
1、Runtime Library：链接哪种运行时刻函数库通常只对程序的性能产生影响。调试版本的 Runtime Library 包含了调试信息，并采用了一些保护机制以帮助发现错误，因此性能不如发布版本。编译器提供的 Runtime Library 通常很稳定，不会造成 Release 版错误；倒是由于 Debug 的 Runtime Library 加强了对错误的检测，如堆内存分配，有时会出现 Debug 有错但 Release 正常的现象。应当指出的是，如果 Debug 有错，即使 Release 正常，程序肯定是有 Bug 的，只不过可能是 Release 版的某次运行没有表现出来而已。
2、优化：这是造成错误的主要原因，因为关闭优化时源程序基本上是直接翻译的，而打开优化后编译器会作出一系列假设。机构突破指标源码这类错误主要有以下几种：
1. 帧指针(Frame Pointer)省略（简称FPO）：在函数调用过程中，所有调用信息（返回地址、参数）以及自动变量都是放在栈中的。若函数的声明与实现不同（参数、返回值、调用方式），就会产生错误，但 Debug 方式下，栈的访问通过 EBP 寄存器保存的地址实现，如果没有发生数组越界之类的错误（或是越界“不多”），函数通常能正常执行；Release 方式下，优化会省略 EBP 栈基址指针，这样通过一个全局指针访问栈就会造成返回地址错误是程序崩溃。
C++ 的强类型特性能检查出大多数这样的错误，但如果用了强制类型转换，就不行了。你可以在 Release 版本中强制加入/Oy-编译选项来关掉帧指针省略，以确定是否此类错误。此类错误通常有：MFC 消息响应函数书写错误。正确的应为：
afx_msg LRESULT OnMessageOwn
(WPARAM wparam, LPARAM lparam);
ON_MESSAGE 宏包含强制类型转换。防止这种错误的方法之一是重定义 ON_MESSAGE 宏，把下列代码加到 stdafx.h 中（在#include "afxwin.h"之后）,函数原形错误时编译会报错。
#undef ON_MESSAGE
#define ON_MESSAGE(message, memberFxn) /
{
message, 0, 0, 0, AfxSig_lwl, /
(AFX_PMSG)(AFX_PMSGW)
(static_cast< LRESULT (AFX_MSG_CALL /
CWnd::*)(WPARAM, LPARAM) > (&memberFxn)
},
2. volatile 型变量：volatile 告诉编译器该变量可能被程序之外的未知方式修改（如系统、其他进程和线程）。优化程序为了使程序性能提高，常把一些变量放在寄存器中（类似于 register 关键字），而其他进程只能对该变量所在的内存进行修改，而寄存器中的值没变。
如果你的程序是多线程的，或者你发现某个变量的值与预期的不符而你确信已正确的设置了，则很可能遇到这样的问题。这种错误有时会表现为程序在最快优化出错而最小优化正常。把你认为可疑的变量加上 volatile 试试。
3. 变量优化：优化程序会根据变量的使用情况优化变量。例如，函数中有一个未被使用的变量，在 Debug 版中它有可能掩盖一个数组越界，而在 Release 版中，这个变量很可能被优化调，此时数组越界会破坏栈中有用的数据。当然，实际的情况会比这复杂得多。与此有关的错误有非法访问，包括数组越界、指针错误等。例如：
void fn(void)
{
int i;
i = 1;
int a[4];
{
int j;
j = 1;
}
a[-1] = 1;
//当然错误不会这么明显，例如下标是变量
a[4] = 1;
}
j 虽然在数组越界时已出了作用域，但其空间并未收回，因而 i 和 j 就会掩盖越界。而 Release 版由于 i、j 并未其很大作用可能会被优化掉，从而使栈被破坏。
3. DEBUG 与 NDEBUG ：当定义了 _DEBUG 时，assert() 函数会被编译，而 NDEBUG 时不被编译。此外，TRACE() 宏的编译也受 _DEBUG 控制。
所有这些断言都只在 Debug版中才被编译，而在 Release 版中被忽略。唯一的例外是 VERIFY()。事实上，这些宏都是调用了assert()函数，只不过附加了一些与库有关的调试代码。如果你在这些宏中加入了任何程序代码，而不只是布尔表达式（例如赋值、能改变变量值的函数调用等），那么Release版都不会执行这些操作，从而造成错误。初学者很容易犯这类错误，查找的方法也很简单，因为这些宏都已在上面列出，只要利用 VC++ 的 Find in Files 功能在工程所有文件中找到用这些宏的地方再一一检查即可。另外，有些高手可能还会加入 #ifdef _DEBUG 之类的条件编译，也要注意一下。
顺便值得一提的是VERIFY()宏，这个宏允许你将程序代码放在布尔表达式里。这个宏通常用来检查 Windows API的返回值。有些人可能为这个原因而滥用VERIFY()，事实上这是危险的，因为VERIFY()违反了断言的在线书签源码php思想，不能使程序代码和调试代码完全分离，最终可能会带来很多麻烦。因此，专家们建议尽量少用这个宏。
4. /GZ 选项：这个选项会做以下这些事：
1. 初始化内存和变量。包括用 0xCC 初始化所有自动变量，0xCD ( Cleared Data ) 初始化堆中分配的内存（即动态分配的内存，例如 new ），0xDD ( Dead Data ) 填充已被释放的堆内存（例如 delete ），0xFD( deFencde Data ) 初始化受保护的内存（debug 版在动态分配内存的前后加入保护内存以防止越界访问），其中括号中的词是微软建议的助记词。这样做的好处是这些值都很大，作为指针是不可能的（而且 位系统中指针很少是奇数值，在有些系统中奇数的指针会产生运行时错误），作为数值也很少遇到，而且这些值也很容易辨认，因此这很有利于在 Debug 版中发现 Release 版才会遇到的错误。要特别注意的是，很多人认为编译器会用0来初始化变量，这是错误的（而且这样很不利于查找错误）。
2. 通过函数指针调用函数时，会通过检查栈指针验证函数调用的匹配性。（防止原形不匹配）
3. 函数返回前检查栈指针，确认未被修改。（防止越界访问和原形不匹配，与第二项合在一起可大致模拟帧指针省略 FPO ）通常 /GZ 选项会造成 Debug 版出错而 Release 版正常的现象，因为 Release 版中未初始化的变量是随机的，这有可能使指针指向一个有效地址而掩盖了非法访问。除此之外，/Gm/GF等选项造成错误的情况比较少，而且他们的效果显而易见，比较容易发现。
怎样“调试” Release 版的程序
遇到Debug成功但Release失败，显然是一件很沮丧的事，而且往往无从下手。如果你看了以上的分析，结合错误的具体表现，很快找出了错误，固然很好。但如果一时找不出，以下给出了一些在这种情况下的策略。
1. 前面已经提过，Debug和Release只是一组编译选项的差别，实际上并没有什么定义能区分二者。我们可以修改Release版的编译选项来缩小错误范围。如上所述，可以把Release 的选项逐个改为与之相对的Debug选项，如/MD改为/MDd、/O1改为/Od，或运行时间优化改为程序大小优化。注意，一次只改一个选项，看改哪个选项时错误消失，再对应该选项相关的错误，针对性地查找。这些选项在Project/Settings...中都可以直接通过列表选取，通常不要手动修改。由于以上的分析已相当全面，这个方法是最有效的。
2. 在编程过程中就要时常注意测试 Release 版本，以免最后代码太多，时间又很紧。
3. 在 Debug 版中使用 /W4 警告级别，这样可以从编译器获得最大限度的错误信息，比如 if( i =0 )就会引起 /W4 警告。不要忽略这些警告，通常这是你程序中的 Bug 引起的。但有时 /W4 会带来很多冗余信息，如 未使用的函数参数 警告，而很多消息处理函数都会忽略某些参数。我们可以用:
#progma warning(disable: )
//禁止
//...
#progma warning(default: )
//重新允许来暂时禁止某个警告，或使用
#progma warning(push, 3)
//设置警告级别为 /W3
//...
#progma warning(pop)
//重设为 /W4
来暂时改变警告级别，有时你可以只在认为可疑的那一部分代码使用 /W4。
4. 你也可以像Debug一样调试你的Release版，只要加入调试符号。在Project/Settings... 中，选中 Settings for "Win Release"，选中 C/C++ 标签，Category 选 General，Debug Info 选 Program Database。再在 Link 标签 Project options 最后加上 "/OPT:REF" (引号不要输)。这样调试器就能使用 pdb 文件中的调试符号。
但调试时你会发现断点很难设置，变量也很难找到?这些都被优化过了。不过令人庆幸的是，Call Stack窗口仍然工作正常，即使帧指针被优化，栈信息（特别是返回地址）仍然能找到。这对定位错误很有帮助。
Android性能优化：定性和定位Android图形性能问题——以后台录屏进程为例
简介发现、定性与定位
总结
跟不上旋律节奏的VSYNC
严重异常耗时的dequeueBuffer
VirtualDisplay合成耗时
结论
FPS
初步定位问题
定性问题
定位问题
成果展示
参考
简介本文记录一次Android图形性能问题的分析过程——发现、定性和定位图形性能问题，以及探讨的性能优化方案。
环境：Android Q + MTK + ARM Mali-G。
所分析的性能问题（下称case）：打开录屏应用并启动后台录屏，滑动前台应用（滑屏）。性能表现差：CPU、GPU负载显著升高、掉帧、用户明显卡顿感，帧率不足帧，帧渲染、合成耗时急剧飙升（渲染耗时平均为ms左右）。
经过优化后，相同环境和条件下，渲染帧率稳定在帧（提升一倍），渲染耗时平均为8.ms左右（为优化前的不到三分之一的消耗）。
关键词 Keywords: Screen Recording; Frame rate; FPS; GPU utilization; Jank; MediaProjection; VirtualDisplay; MediaCodec; Perfetto; Inferno; Surface; SurfaceTexture; VSYNC; SurfaceFlinger; HWC; Hardware composer; GPU; OpenGL;
发现、定性与定位FPS计算FPS的方法和工具 Android框架层通过hwui配合底层完成渲染。该框架本身提供了逐帧渲染分段耗时记录。通过dumpsys gfxinfo可以获取。
io.microshow.screenrecorder/io.microshow.screenrecorder.activity.MainActivity/android.view.ViewRootImpl@6b9b8a9?(visibility=0)DrawPrepare?Process?Execute3...................1................使用工具统计帧率与平均耗时（同时打印GPU负载），在开启后台录屏的情况下滑动屏幕，平均渲染耗时高达~ms，超出.ms一倍，导致帧率仅帧，显著低于帧。
Average?elapsed?.?msFPS:??│?9.?0.?.?2.#?GPU负载?LOADING?BLOCKING?IDLE?0?#?case的对比——未开启后台录屏Average?elapsed?9.?msFPS:??│?1.?0.?5.?1.通过gfx柱状图直观感受性能数据 直观地感受图形渲染性能，除了帧率感受、触控延时外，还可以通过将gfxinfo的分段耗时通过柱状图展示在屏幕上。
这是case性能问题的gfxinfo柱状图，可以看到红柱和绿柱都非常高，远远超越了流畅标准。其中，绿柱异常放大表明两个Vsync之间耗时显著增长，红柱异常放大表明应用层应用加速使用的DisplayLists大量增长、或图形层使用GLES调用GPU耗时显著增多导致的GPU执行绘制指令耗时变长。
初步定位问题本节记录初步的分析思路和定位过程。首先我们完成实验（启停后台录屏并滑动屏幕触发渲染）、观测以及记录，拿到了后台录屏启停情况下的FPS、分阶段耗时以及GPU负载（相关数据位于FPS小节）。
开发的工具输出的统计数据计算结果非常直观，一眼可见，后台录屏为Draw阶段带来额外的~8倍或~8ms耗时，给Process阶段带来额外的~2倍或~ms耗时。帧率从帧坠落到~帧。
耗时分析 可以看到，主要的额外耗时来自Draw和Process。接下来重点围绕着两part定位问题问题。
StageDescriptionCompDraw创建DisplayLists的耗时。Android的View如果支持硬件加速，绘制工作均通过DisplayLists由GPU绘制，可以处理为onDraw的耗时额外~8ms或~8倍Prepare准备没有额外耗时ProcessDisplayLists执行耗时。即硬件加速机制下提交给GPU绘制的工作耗时额外~ms或~2倍ExecuteFramebuffer前后缓冲区flip动作的耗时，上屏耗时额外不到~1msHz下，上述4个步骤合计耗时小于.ms为正常情况。case为~ms。主要增量来自Draw和Process。
经过上述初步分析、观测后，接下来的分析可以围绕Draw和Process开展。由于Android Draw部分涉及较广，包含App 渲染线程（DisplayLists）、UI线程（onDraw方法创建DisplayLists），以及图形栈耗时如SurfaceFlinger、RenderEngine等都可能增加Draw耗时。
这里一个技巧可以初步判断耗时来自App进程(渲染线程和UI线程)还是来自图形栈。如果能判断耗时来自App或图形栈，那么可以缩小分析范围、减少分析工作量。上述四大阶段的耗时统计分类比较宽，实际上还有更详细的分阶段耗时，它呈现在前文描述过的gfx统计信息柱状图上。gfx柱状图会以蓝色（RGB(,,)）呈现onDraw方法创建和更新DisplayLists的耗时。如果case与正常情况对比后，这部分耗时（蓝柱大小对比）差异很小，即可说明额外的Draw耗时不是来自App的，极可能来自图形栈。Besides，结合过度绘制分析，判断case与正常情况下是否有更多的额外绘制次数可以协同判断。
——根据上述指导思想，排查出了case的额外Draw耗时与App onDraw无关，多出来的DisplayLists来自App以外的进程，可能是图形栈如SurfaceFlinger。
定性问题本小节介绍问题追踪过程，通过一些方法定位到各阶段的耗时原因，并定性地得出case性能问题的性质。从本小节开始，围绕Perfetto进行分析。这里贴出perfetto的总览，我将关键的信息排序到顶部。前四行分别为SF负责图形的线程、提交到GPU等待完成的工作、Vsync-App、Vsync-sf，最后两行为case中出现卡顿掉帧的App的主线程(UI)和渲染线程(RenderThread)。
跟不上旋律节奏的VSYNC容易看到，Vsync-sf非常不规律。Vsync-sf是触发SurfaceFlinger一次合成工作的基于Hardware VSYNC虚拟出来的一个信号。它相对于真实硬件信号（HW_VSYNC）一个规律的偏移（在case设备上，Vsync-app与Vsync-sf都被配置为8.3ms，即硬件VSYNC到达后，虚拟的Vsync-app和Vsync-sf延时8.3ms后发出，分别触发App绘制、SurfaceFlinger合成。
而case的Vsync-sf交错、残次、不齐、无规律，显然工况不佳。它将导致SurfaceFlinger不能按照预期的时间间隔将合成的帧提交到Framebuffer（经过Flip后，被提交的Framebuffer将上屏成为显示器的下一帧图像），出现掉帧/丢帧。
As we can see，case的VSYNC-sf出现严重的漂移（见图，第二行的VSYNC-sf残次不齐、跟不上规律、难看且混乱），这导致了丢帧。（但VSYNC-sf的失控仅表示与丢帧的相关性，并不直接表明因果性。）
VSYNC-sf为什么会出现偏差？ 出于功耗的考虑，VSYNC-sf合VSYNC-app并不是一定会触发的。如果app或sf并没有更新画面的需求，那么死板固定地调度它们进行绘制和合成是不必的。编程上，负责触发VSYNC-sf和VSYNC-app的两个EventThread会在requestNextVsync调用后才会将下一个VSYNC-sf或VSYNC-app发出。因此，当（各自EventThread的）requestNextVsync没有调用时，VSYNC-app和VSYNC-sf也就出现漂移。BufferQueueLayer::onFrameAvailable会在应用提交后调用，该方法通过调用SF的signalLayerUpdate触发产生下一个VSYNC-sf。
换而言之，出于功耗，或别的什么原因（比如耗时导致的延期，人家是线程实现的消息队列），SurfaceFlinger的SFEventThread有可能不调用requestNextVsync，这将导致Vsync-sf在窗口期内短暂消失——但是也不会出现参差不齐的情况。结合case的VSYNC信号报告来看，VSYNC-sf信号异常切实地提示了性能问题——它的不规律现象表明前后Vsync之间有异常耗时，而非低功耗机制被激活或无屏幕刷新（case性能问题复现时一直在滑前台应用的屏，它每ms都有画面更新的需求）。
VSYNC-sf虽然出现了偏差，但是它与卡顿问题仅有相关性（或者说它是性能问题的结果），并非因果关系。猜测是其他卡顿问题导致了SF延缓了对VSYNC的request，导致其信号出现漂移。VSYNC-sf信号偏差实质上指导意义重大，因为它能提示我们，问题发生在比App更底层的地方（前文分析的结论），且比SurfaceFlinger提交到Framebuffer更上层的位置（VSYNC-sf用于触发合成，合成完成后提交到屏幕双缓冲区）。
这样，将case性能问题的上下界都确定了，问题分析范围从原先的整个图形栈，有效的缩小到了SurfaceFlinger渲染和合成阶段了。
严重异常耗时的dequeueBuffer通读Perfetto，可以看到，出了难看的Vsync-sf以外，还可以看到刺眼的超长耗时的draw（App UI线程）以及耗时变态长的dequeueBuffer(App 渲染线程)调用。相对于正常情况，perfetto报告提示的case的draw方法成倍增长的耗时非常容易被误认为耗时“居然来自一开始就排除掉的App进程"，这与前文提出的”问题范围“是不能自洽的——它们是相反的结论，肯定哪里不对。仔细分析才能发现，draw方法确实是消耗了更多墙上时间（但是不意味着消耗了更多CPU时间，因为等待过程是sleep的），但是draw方法是因为等待渲染线程的dequeueBuffer造成的耗时，而dequeueBuffer的严重异常耗时却是被底层的图形栈拖累的。
我们看到，draw严重耗时，渲染线程dequeueBuffer消耗掉~ms的时间。As we all known，Android的Graphics buffer是生产者消费者模型，当作为消费者的SF来不及处理buffer并释放，渲染线程也就需要额外耗时等待buffer就绪。上面还有一段"Waiting GPU Completion"的trace没有贴上来（下图），这段耗时比不开启后台录屏的case下高得多（~3ms对比~ms），说明了一定的GPU性能问题或SF的性能问题，甚至有可能是Display有问题（HWC release耗时过长也会导致SF释放buf、生产者渲染线程dequeueBuffer额外等待）。
这里的机制比较复杂，不熟悉底层Graphics buffer的流水线模型就不好理解。In one world, dequeueBuffer申请的buffer不是凭空new出来的，而是在App-SurfaceFlinger-Framebuffer这一流水线中循环使用的。流水线中的buffer不是无限的，而是有穷的几个。当底层的伙计，如SF和HWC，使用了buffer但是没有来得及释放时（它们的工作没做完之前不会释放buffer），流水线（可以理解成头尾相接的单向队列（ring buffer））没有可用的buffer，此时dequeueBuffer就不得不进入等待，出现耗时看上去很长的问题。实际上，dequeueBuffer耗时的唯一原因几乎仅仅只有一个：底层消费太慢了，流水线没有剩余buffer，因此需要等待。
这个模型抽象理解非常简单。下图，右边消费者是底层图形栈——它每消费完一个buffer就会释放掉，每释放一个buffer应用层能用的buffer就加1。左边生产者是App渲染线程——它调用dequeueBuffer申请一个buffer以将它的画面绘制到这个buffer上。buffer送入BufferQueue后由右边的消费者（图形栈）进行消费（合成、上屏显示），然后释放buffer。当图形栈来不及release buffer时，dequeueBuffer的调用者（App渲染线程）将由于无可用buffer，就必须挂起等待了，在perfetto上就留下长长的一段”耗时“（实际上是墙上时间，大部分都没有占用CPU）。
以上，这就是为什么说App渲染线程dequeueBuffer严重耗时中的耗时为什么要打引号，为什么要说是被图形层拖累了。
下图可以看到，刨去dequeueBuffer的严重异常耗时，执行渲染的部分耗时相对于正常的case几乎没有差异，这可以断言渲染线程的惨烈耗时主要就是被dequeueBuffer浪费了。
从GPU Completion来看，此时GPU正在为SF工作，因为在图中看到（不好意思没有截全，下图你是看不出来的），dequeueBuffer总是在SF的GPU Completion结束之后结束的，这就表明SF正在通过GPU消费buffer（调用GPU进行合成后提交，然后标记buffer允许被渲染线程dequeue）。dequeueBuffer获取到就绪的buffer此时此刻取决于SF的消费能力——因为case中它是短板。（当然图形层的buffer可用不止SurfaceFlinger需要释放，因为SF释放后buffer实质上流转到更底层的HWC，等它将Buffer提交到屏幕后才会释放，这里释放后才能给App再次使用(上面哪个模型图把SF和HWC合并为流水线的图形层buffer消费者)。
从perfetto报告看HWC release非常及时、余量充足，SF的GPU Completion则较紧密地接着dequeueBuffer返回，基本断言是SF太慢了——排除HWC的责任。（下图看不出来，当时没有截图到HWC的release情况。）
到这里，除了再次确认排除了前台App的问题外，还可以断言问题来自SurfaceFlinger过分耗时。此外将问题范围的下界从整个SF合成流程（上文的Vsync-sf）缩小到了排除HWC的范围。
结论：渲染耗时一切正常，问题出现在SF消费buffer（合成图形）失速了，导致没有可用的buffer供渲染线程使用。从下图的SF的工况（第三列）来看，情况确实如此。
既然一口咬定是SF的锅，那就瞧瞧SF。先看SF的INVALIDATE，这没啥好看的，异常case和正常case都是~2.5ms。主要看refresh，正常case ~6.8ms，异常case ~.8ms。refresh包含SF的合成四件套，包括rebuildLayerStack、CalcuateWorkingSet、Prepare、doComposition。Perfetto报告直接表明，case的后台录屏导致的额外一次合成和配套工作是主要的耗时增量。
之所以会执行两次合成，是因为后台录屏工具编程上通过Android SDK提供的MediaProjection配合VirtualDisplay实现一个虚拟的镜像的屏幕。SurfaceFlinger会将画面输送一份到这个虚拟的Display以实现屏幕图像传送到录屏工具，虚拟的屏幕要求额外的一次合成。从上图可以直接得出结论，case带来的额外工作消耗就是对该录屏用的VirtualDisplay的合成工作(doComposition)带来的。
VirtualDisplay合成耗时由于问题范围已经缩小到了很小的一个范围，在SurfaceFlinger的Refresh过程中，case相对正常应用有巨大的差异耗时，几乎完全来自于对VirtualDisplay的合成耗时(doComposition)。同时也可以看到，两次合成（一次是设备的物理屏幕，一次是case的后台录屏工具创建的虚拟屏幕）中，虚拟屏幕的耗时远远高于物理屏幕（4倍以上）。
通过查看ATRACE的tag（上图，Perfetto中SurfaceFlinger中主线程的各个trace point都是用ATRACE打的tag），结合dumpsys SurfaceFlinger，能直接看到的线索是：
虚拟屏显著耗时，且合成工作通过GLES调用GPU完成
物理屏合成耗时很小，它通过HWC合成
结合图中提示的trace tag、耗时，可以得出结论，使用GPU合成的虚拟屏中因GPU合成耗时很长，导致它显著高于物理屏HWC合成耗时。如果GPU合成能够和HWC合成一样快，或者干脆让虚拟屏也使用HWC合成，那么可以预期SurfaceFlinger的合成工作的消耗将显著降低。
结论本小节综合上述三个小节的分析，对节”定性问题“下一个结论。
耗时的本质已经被看透，录屏工具申请创建的VirtualDisplay没有通过HWC进行合成，而是通过GPU进行合成，它耗时很长导致界面卡顿。In one word，case使用的VirtualDisplay的合成方式不够高效。
HWC是Hardward Composer。它接收图形数据，类似于往桌面（真的桌面，不是电脑和手机的桌面）上面叠放照片和纸张——即合成过程。这个工作能将界面上几个窗口叠加在一起后送到屏幕上显示。通过GLES调动GPU也能干这活，不过HWC执行合成的动作是纯硬件的——它很快，比GPU快几倍。
定位问题前面虽然定性了问题原因是合成方式不够高效，但是没有得出其中的原理——为什么虚拟屏不使用高效的HWC进行合成。本节通过介绍HWC的原理、SurfaceFlinger控制合成方式、虚拟屏Surface特性等来介绍图形栈中合成方式的处理模式。掌握了相关管理后，探讨一些尽量通用的共性的解决方案实现性能优化。最后着重介绍多套优化方案中的一种直面根本原因的解决方法——MediaCodec.MediaFormat创建的支持HWC合成的Surface方案。
SurfaceFlinger如何决定使用HWC还是GPU合成？ SurfaceFlinger合成主要可以依靠两条路径。其中之一是”纯硬“的HWC合成（在dumpsys SurfaceFlinger中可以看到Composition type为DEVICE），另一个是通过OpenGL让GPU进行合成（Composition type为CLIENT）。
除非是功耗上的设计，否则SurfaceFlinger总是会优先检查本次合成是否支持使用HWC。编程上，在合成阶段之一的prepare过程中，SurfaceFlinger通过prepareFrame在RenderSurface与Hardware Composer（即HWC）的HIDL服务通信，完成hwc layer的创建。但是，layer能够成功创建不意味着一定支持HWC合成。SurfaceFlinger通过getChangedCompositionTypes向HWC查询不支持HWC合成的Layer。该方法返回的layer如果被标记为CLIENT合成，那么这部分Layer无法由HWC进行合成，而只能通过GPU进行合成——case的VirtualDisplay就是这个情况。
部分layer可能不能由HWC合成的原因（除功耗策略、其他软件策略外）：
HWC layer达到上限 Hardware Composer支持的layer数量是有限的。查阅公开资料可知，HWC合成动作属于硬件提供的能力，它们的合成能力受到硬件本身的限制。Google官方资料对Android设备的要求是，HWC最少应该支持4个Layer，分别用于一个常规页面上最常见的4个层：壁纸、状态栏、导航栏和应用窗口。 在case设备中，经过测试，该平台的HWC最多支持7个能进行HWC合成的layer，从第8个layer开始，完完全全只能使用CLIENT合成亦即SurfaceFlinger调用RenderEngine通过OpenGL调动GPU进行合成。 正是由于HWC合成layer有上限，因此在弹出多个弹窗、叠加过于复杂时，即使界面简单也有可能出现比较明显的卡顿。
VirtualDisplay的Surface格式不受HWC支持 HWC的硬件合成能力对buffer（Surface封装）内保存的图像的格式有要求。比如，HWC不能处理缩放，仅支持一部分的格式，大多数都还有其他因素会导致不支持，如旋转、部分Alpha等等。In one word，图像格式的数量是远远多于HWC支持的类型数的。当HWC碰到不支持合成的Surface时，就会在前文提过的getChangedCompositionTypes中通知SurfaceFlinger，由SurfaceFlinger转为使用GPU合成。
结合上述几种情况，设计实验验证。其中通过在物理屏上弹窗来增加Layer以获取HWC Layer上限。确认case无法使用HWC合成不是Layer上限导致的问题后，通过对比来验证Surface格式问题。Surface是对native层的buffer的封装，其类型广泛、实现复杂，一个一个试是不现实的。通过对比性能强劲的类似实现可以一探究竟。Android adb提供一个出厂自带的录屏命令screenrecord、用于测试双屏显示功能的虚拟辅助屏幕（开发者模式-模拟辅助屏）、著名远程窥屏工具scrcpy等三个工具是一系列重要参考。
经过测试，screenrecord和scrcpy创建的VirtualDisplay支持HWC合成——这是优化目标。首先看看它们的实现。
编程上，虚拟辅助屏幕采用了与case一模一样的实现——通过创建VirtualDisplay让图形层额外合成一次屏幕到该虚拟屏幕中。虚拟屏幕本质上将画面发送给录屏功能实现，而非进行显示来完成录屏。
通读screenrecord源码，逻辑上，它与虚拟辅助屏、case录屏应用是相同的——VirtualDisplay录屏。但是编程上略有差异：
screenrecord直接通过binder与SurfaceFlinger通信，获取了raw VirtualDisplay，而
跪求大神帮忙看看，PHP源代码错误 Method name must be a string
只有一句错误代码啊。。但是提示看着像是语法错误，函数名必须是一个字符串。
你试着把你这句代码分开写试试。比如：
$this->data['FromUserName']改成 $tmpdata = $this->data; 再用 $tmpdata['FromUserName'];
2024-12-26 15:02
2024-12-26 14:22
2024-12-26 13:51
2024-12-26 13:43
2024-12-26 13:40
