定位函数性能问题的方法及装置与流程

本申请涉及定位函数的性能问题的技术，尤其涉及定位函数性能问题的方法及装置。

背景技术：

程序开发人员经常需要了解程序中的函数调用是否存在性能问题。目前存在对函数性能进行测试的系统工具，例如苹果公司所开发的系统调试工具Instrument。该工具可以输出一对运行结果的日志图标，根据整个应用程序运行消耗时间分布和百分比，通过人工大量的分析可以定位可能存在性能问题的函数。由此可知，系统调试工具是对系统所运行的程序提供通用性的整体检测，因此很难区分出系统内部函数、第三方代码库的函数以及当前应用程序代码的函数，从而无法自动获知程序开发人员所关心的应用程序中实际代码性能是否存在问题，且需要人工参与分析才能通知到性能问题的代码的责任人。

技术实现要素：

本申请提供定位函数性能问题的方法及装置，能够定位出存在性能问题的程序代码以及代码的责任人。

根据本申请实施例的第一方面，提供一种定位函数性能问题的方法，该方法包括步骤：

获取程序的代码；

确定程序的代码中存在性能问题的函数，并生成存在性能问题的函数的 日志；

从所述日志中获取关键信息，所述关键信息包括存在性能问题的函数的标识；

根据所述关键信息定位存在性能问题的函数的代码来源。

根据本申请实施例的第一方面，提供一种定位函数性能问题的装置，包括：

性能测试模块，用于获取程序的代码，确定程序的代码中存在性能问题的函数，并生成存在性能问题的函数的日志；

提取模块，用于从所述日志中获取关键信息，所述关键信息包括存在性能问题的函数的标识；

定位模块，用于根据所述关键信息定位存在性能问题的函数的代码来源。

本申请的各步骤是针对某个程序的代码中各函数逐个测试分析，且直接输出包含性能问题的函数的日志，各个程序代码的日志相互独立，因此可以将所关注的程序与系统程序和其他第三方代码库的程序的日志分开，直观的确定存在性能问题的单个函数，并从日志中提取该函数的关键信息，通过关键信息从代码系统中找到该函数所在的程序代码的来源，从而可以定位到具体的责任人。

附图说明

图1为本申请实施例中定位函数性能问题的方法的流程图；

图2a为本申请实施例中应用实例的场景图；

图2b为本申请实施例中应用实例的服务M的流程图；

图3为本申请实施例中定位函数性能问题的装置的硬件架构图；

图4为本申请实施例中定位函数性能问题的装置的软件逻辑框图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的 描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本申请可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

针对在很多环境中程序运行时定位性能问题存在困难的情况，本申请提出定位函数性能问题的方法及装置。

本申请可适用于多种智能设备。智能设备常见的可以是手机、平板电脑、电脑、智能耳机、智能电视、智能手表等设备。

程序常见的运行于操作系统中，本申请所适用的操作系统可以是IOS系统、Android系统、Windows系统、Unix系统等。

程序可以是应用程序，例如客户端软件的应用程序(导航App、音乐App、购物App等)，以及操作系统所运行的应用程序(可以是短信服务程序、电话服务程序等)。

参见图1，本申请定位函数性能问题的方法的流程如下所述。

S101，获取程序的代码；

S102，确定程序的代码中存在性能问题的函数，并生成存在性能问题的 函数的日志；

S103，从存在性能问题的函数的日志中获取关键信息，关键信息包括存在性能问题的函数的标识；

S104，根据关键信息定位存在性能问题的函数的代码来源。

作为一个实施例，可以通过自行编写的脚本来执行本申请图1中的流程，因此可以不需要编译。脚本可以例如Python、vbscript、javascript、installshield script、ActionScript等。当然，不排除通过其他高级语言执行的情况。

确定存在性能问题的函数的方式可以存在多种方式，例如，可以获取函数的运行时长，根据函数的运行时长判断该函数是否存在性能问题，或者可以程序运行时调用系统的API接口获取CPU的占用情况，根据函数对CPU占用情况来判断该函数是否存在性能问题等。

以通过运行时长判断函数是否存在性能问题为例，当需要测试某个程序的函数的性能时，脚本可以从程序的代码系统中获取程序的代码，记录函数的开始时间和结束时间。代码系统中可以存放程序开发人员所编写的程序的代码的文件名、函数标识(可以包括类标识和方法标识)，以及识别程序开发人员的标识信息(例如程序开发人员的账户)等信息。记录时间的方式可以是在程序的代码编译前，识别函数的函数头(即函数的入口)和结束位置，插入记录开始时间和结束时间的语句。

函数运行的过程可以是通过脚本将程序代码编译后，将程序代码内各函数链接成可运行的执行程序，运行该程序，当执行到某个函数时，记录该函数的开始运行的时间，当退出该函数时记录函数的结束时间。根据所标记的开始时间和结束时间可以计算出该函数的运行时长。

在获得函数的运行时长后，确定该函数是否存在性能问题的方式可以存在多种，例如，可以设定一个第一预设值，如果运行时长超过这个第一预设值则认为该函数存在性能问题等。

从上述描述可以看出，本申请可以获得某个程序代码中每个函数的运行时长，因此方便了解单个函数的耗时情况，能够准确定位到具体的程序代码 以及具体的函数，方便直观，有别于现有技术Instrument等系统工具无法直观的区分单个函数，需要获取dsym函数描述文件后经过分析才可以获得哪个程序代码的哪个函数的运行状态存在异常。

另外，本申请所获得的函数的运行时长可以包括线程的切换时间，解决了在系统性能测试工具中无法记录线程运行时长的问题。这是由于本申请是在程序本身的代码中插入记录开始时间和结束时间的语句，以便记录该程序代码运行时的系统时间，因此程序在运行时不会像系统工具在测试程序性能时受到CPU分配给每个线程的时间片的影响，从而不被线程的切换时间所干扰。

作为一个实施例，如果确定函数的性能存在问题，则将该函数的日志输出，当然也可以根据业务需求，输出该程序代码的所有函数的日志，或输出该程序代码的特定函数的日志。

输出的日志中可以只包括该程序本身的函数，当然如果设计需要，也可以输出系统相关的函数或者调用的第三方程序的函数。

为了能够定位到代码来源，所输出的日志中包含的关键信息至少包含存在性能问题的函数的标识，另外，还包括函数的运行时长、函数的运行时间、函数的文件名等信息中的一项或多项信息，函数的标识中可以包含该函数的类标识和方法标识。

作为一个实施例，可以根据设计的需要从日志中取出满足设定条件的函数的关键信息，例如，如果需要对日志中输出的每个函数重新优化处理，则逐一读出日志的各个函数的关键信息。再例如，虽然日志中的函数的运行时长超出了第一预设值，但如果目前需要定位的性能问题函数是针对第二预设值(这个第二预设值可以大于第一预设值)，则可以通过Grep脚本根据设定的第二预设值从存在性能问题的函数的日志中获取满足条件的关键信息。

可以将提取出的存在性能问题函数的关键信息在代码系统中进行查找，可以找到该函数的代码来源，例如该函数的代码所相关的程序开发人员的账户，发送通知提醒，可以将相关的日志一并发给该程序开发人员。

在一个例子中，程序开发人员在收到通知后可以对出现性能问题的函数进行优化，优化后的函数代码重新提交到代码系统。本申请中执行步骤S101至S104的脚本可以周期性的或不定期的从代码系统中获取程序的代码。获取的规则可以根据设计需求而定。脚本可以是被运行成一个服务的形式，系统可以按照预定规则执行此脚本，例如，如果需要对某些程序进行多次重复性能测试，则无论该程序是否在之前的测试中存在性能问题的函数，均从代码系统中多次获取该程序的代码进行测试。或者可以在脚本检查代码系统中的代码的更新时间是否晚于上次编译的时间，如果是，则执行步骤S102至S104，如果不是，则忽略该程序的代码。

另外，在获得存在性能问题的函数的关键信息后，还可以根据关键信息对存在性能问题的函数归类，根据归类结果对存在性能问题的函数统计和分析。例如，可以将函数名作为关键字，统计包含该函数名的程序，以方便了解调用容易出现性能问题的函数，也可以通过统计函数名定位到相关的程序开发人员，对程序开发人员的代码质量进行监控等等。

以下是一个应用实例中对一个应用程序的性能测试和定位性能存在问题的函数的过程。

图2a是本应用实例的场景图。

图中在S200阶段，程序开发人甲、乙、丙等人将各自程序的代码提交到代码系统S中。

在S201阶段，代码系统S记录程序开发人员的账户信息、程序的文件名等信息。甲所提交的程序代码A中的函数a1、a2、a3、a4；乙所提交的程序代码B中的函数b1、b2、b3；丙提交的程序的代码C中的函数c1、c2、c3、c4、c5。

服务M是本申请执行定位函数性能问题的方法的脚本，在S202阶段，服务M被运行，测试程序的各函数的性能，并输出存在性能问题的函数的日志。过程参见图2b并进行如下描述。

S2021，服务M从代码系统S中获取程序代码A；

S2022，检查该程序代码是否被编译过；

S2023，如果已经被编译过，则判断在代码系统S中登记的时间是否晚于该程序代码上次的编译时间，如果未被编译过，或者程序代码A是上次编译后重新递交的新代码，则识别每个函数的函数头和函数结束位置；

S2023，在每个函数的函数头和函数结束位置插入标记时间的语句；

S2024，将程序代码A进行编译和链接的打包操作；

S2025，运行打包后的程序A，记录每个函数的开始时间和结束时间；

S2026，根据函数的开始时间和结束时间计算各函数的运行时长；

S2027，将每个函数的运行时长与预设时长对比，判断是否超出预定时长，预设时长为90ms；

S2028，将运行时长超过预设时长的函数输出日志，日志中包含该函数的运行时长、函数名、运行时间、程序代码A的文件名。

S2029，通过运行Grep脚本，从输出的日志搜索运行时长超过150ms的函数名；

S2030，将提取出的函数名在代码系统S中查找匹配字段，定位到上传该代码文件的账户；

S2031，向该账户发通知邮件，可以将日志一并发给该账户。

S202阶段服务M对程序代码B和程序代码C的处理过程可参照图2b，不再赘述。

服务M所输出的存在性能问题的日志程序代码A的日志和程序代码B的日志。程序代码A中存在性能问题的函数为a1，程序代码B中存在性能问题的函数为b2、b3。

在S203阶段，服务M向甲和乙发送通知邮件。

甲和乙对存在性能问题的函数进行优化，优化后提交到代码系统S，代码系统S收到新提交的程序代码后所做的处理以及服务M再次获取程序代码后所做的处理不再赘述。

与前述定位函数性能问题的方法的实施例相对应，本申请还提供了定位 函数性能问题的装置的实施例。

本申请定位函数性能问题的装置的实施例可以应用在计算机设备上。装置实施例可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在计算机设备的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。从硬件层面而言，如图3所示，为本申请定位函数性能问题的装置所在计算机设备的一种硬件结构图，除了图3所示的处理器、内存、网络接口、以及非易失性存储器之外，实施例中装置所在的计算机设备通常根据该计算机设备的实际功能，还可以包括其他硬件，对此不再赘述。

请参考图4，定位函数性能问题的装置400，包括：

性能测试模块401，用于获取程序的代码，确定程序的代码中存在性能问题的函数，并生成存在性能问题的函数的日志；

提取模块402，用于从日志中获取关键信息，所述关键信息包括存在性能问题的函数的标识；

定位模块403，用于根据所述关键信息定位存在性能问题的函数的代码来源。

在一个实施例中，性能测试模块401还可以用于：

记录函数的开始时间和结束时间；

根据所述开始时间和结束时间计算函数的运行时长。

另外，性能测试模块401确定存在性能问题的函数可以包括：

如果函数的运行时长超过第一预定值，则确定函数是存在性能问题的函数。

关键信息还可以包括以下至少一项：

函数的运行时长、函数的文件名、函数的运行时间、提交所述程序的代码的账户名。

在一个实施例中，提取模块402从存在性能问题的函数的日志中获取关键信息可以包括：

通过Grep脚本根据第二预定值从存在性能问题的函数的日志中获取关键信息。

定位模块403还可以用于确定存在性能问题的函数的代码来源后，发送通知提醒。

另外还可以包括统计模块(图中未示出)，用于从根据所述提取模块获取的关键信息对存在性能问题的函数归类，根据归类结果对存在性能问题的函数统计和分析。

上述装置中各个单元的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。

对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本申请方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。