CN111240937A - 应用程序内方法耗时统计方法、装置、计算机设备和介质 - Google Patents

Abstract

本申请涉及一种应用程序内方法耗时方法、装置、计算机设备和介质。所述方法包括：在应用程序启动时，开启耗时分析进程以监听应用程序内各个方法的生命周期；判断是否执行到插桩插件，当执行到插桩插件时，则通过所述插桩插件记录应用程序中所涉及的方法的执行开始时间和执行结束时间；将所述执行开始时间和执行结束时间发送至所述耗时分析进程；在所述耗时分析进程中，根据所述执行开始时间和执行结束时间计算得到各个方法的耗时时间，并将所述耗时时间进行存储。采用本方法能够准确地统计应用程序内方法耗时。

Description

应用程序内方法耗时统计方法、装置、计算机设备和介质

技术领域

本申请涉及计算机技术领域，特别是涉及一种应用程序内方法耗时统计方法、装置、计算机设备和介质。

背景技术

应用内方法的耗时是反映应用程序流畅度的一个重要因素，特别是在像在基于单进程消息模型的系统中，在这类系统中仅存在一个主进程对UI界面进行刷新，一旦主进程内的方法耗时较高，界面的绘制就会变得非常卡顿。因此，能够快速统计应用内主进程方法的耗时情况并针对高耗时的方法进行优化，对于提高应用的流畅度具有重要的意义。

以Android应用程序的方法耗时统计为例，现有统计应用内方法耗时的工具主要有Traceview、Systrace等。Traceview工具存在两种模式，分别是sample和instrument模式，sample模式仅仅对部分方法耗时进行统计，并不能统计应用内的全部方法耗时，而instrument模式虽然可以获得应用内的全部方法的耗时情况和调用逻辑，但是此模式会带来极大的性能开销，方法耗时统计的结果与实际情况相差很大并且统计结果分析较复杂等。Systrace工具虽然性能损耗较小，但是此工具仅能监控系统应用的耗时情况。

发明内容

基于此，有必要针对上述技术问题，提供一种能够准确统计应用内方法耗时的应用程序内方法耗时统计方法、装置、计算机设备和介质。

一种应用程序内方法耗时统计方法，所述方法包括：

在应用程序启动时，开启耗时分析进程以监听应用程序内各个方法的生命周期；

判断是否执行到插桩插件，当执行到插桩插件时，则通过所述插桩插件记录应用程序中所涉及的方法的执行开始时间和执行结束时间；

将所述执行开始时间和执行结束时间发送至所述耗时分析进程；

在所述耗时分析进程中，根据所述执行开始时间和执行结束时间计算得到各个方法的耗时时间，并将所述耗时时间进行存储。

在其中一个实施例中，所述通过所述插桩插件记录应用程序中所涉及的方法的执行开始时间和执行结束时间，包括：

通过所述插桩插件判断是否存在方法入口；

当存在方法入口时，则获取所述方法入口对应的方法的第一签名，并获取当前的系统时间作为执行开始时间，将所述第一签名和执行开始时间关联存储；

通过所述插桩插件判断是否存在方法出口；

当存在方法出口时，则获取所述方法出口对应的方法的第二签名，并获取当前的系统时间作为执行结束时间，将所述第二签名和执行结束时间关联存储。

在其中一个实施例中，所述在所述耗时分析进程中，根据所述执行开始时间和执行结束时间计算得到各个方法的耗时时间，包括：

在所述耗时分析进程中，获取所述第一签名和第二签名相同的执行开始时间和执行结束时间；

根据所获取的执行开始时间和执行结束时间计算得到对应方法的耗时时间。

在其中一个实施例中，所述开启耗时分析进程以监听应用程序内各个方法的生命周期之前，还包括：

获取当前编译环境，并判断所述当前编译环境是否为预设编译环境；

当所述当前编译环境为预设编译环境时，则继续执行开启耗时分析进程以监听应用程序内各个方法的生命周期。

在其中一个实施例中，所述通过所述插桩插件记录应用程序中所涉及的方法的执行开始时间和执行结束时间，包括：

通过钩子拦截所述应用程序的打包过程；

在所述打包过程中第一类型文件转换成第二类型文件之前，通过所述插桩插件遍历所述第一类型文件中所涉及的方法，并记录所遍历的方法的执行开始时间和执行结束时间。

在其中一个实施例中，所述将所述耗时时间进行存储之后，还包括：

通过耗时分析界面接收耗时方法获取请求；

根据所述耗时方法获取请求查询并显示所存储的各个方法的耗时时间。

一种应用程序内方法耗时统计装置，所述装置包括：

进程启动模块，用于在应用程序启动时，开启耗时分析进程以监听应用程序内各个方法的生命周期；

插件执行模块，用于判断是否执行到插桩插件，当执行到插桩插件时，则通过所述插桩插件记录应用程序中所涉及的方法的执行开始时间和执行结束时间；

发送模块，用于将所述执行开始时间和执行结束时间发送至所述耗时分析进程；

耗时分析模块，用于在所述耗时分析进程中，根据所述执行开始时间和执行结束时间计算得到各个方法的耗时时间，并将所述耗时时间进行存储。

在其中一个实施例中，所述插件执行模块包括：

第一判断单元，用于通过所述插桩插件判断是否存在方法入口；

第一记录单元，用于当存在方法入口时，则获取所述方法入口对应的方法的第一签名，并获取当前的系统时间作为执行开始时间，将所述第一签名和执行开始时间关联存储；

第二判断单元，用于通过所述插桩插件判断是否存在方法出口；

第二记录单元，用于当存在方法出口时，则获取所述方法出口对应的方法的第二签名，并获取当前的系统时间作为执行结束时间，将所述第二签名和执行结束时间关联存储。

一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现上述中任一项所述方法的步骤。

一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现上述中任一项所述的方法的步骤。

上述应用程序内方法耗时统计方法、装置、计算机设备和介质，在应用程序启动后，通过插桩插件来统计应用程序中所涉及的方法的执行开始时间和执行结束时间，这样耗时分析进程中就可以根据应用程序中所涉及的方法的执行开始时间和执行结束时间计算得到耗时时间，这样通过插桩插件来进行遍历可以统计所有的方法，且采用另外的进程来进行计算可以减少性能开销，提高准确性。

附图说明

图1为一个实施例中应用程序内方法耗时统计方法的流程示意图；

图2为图1所示实施例中的步骤S104的流程图；

图3为另一实施例中的应用程序内方法耗时统计方法的流程图；

图4为一个实施例中应用程序内方法耗时统计装置的结构框图；

图5为一个实施例中计算机设备的内部结构图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。

在一个实施例中，如图1所示，提供了一种应用程序内方法耗时统计方法，本实施例以该方法应用于终端进行举例说明，可以理解的是，该方法也可以应用于服务器，还可以应用于包括终端和服务器的系统，并通过终端和服务器的交互实现。本实施例中，该方法包括以下步骤：

S102：在应用程序启动时，开启耗时分析进程以监听应用程序内各个方法的生命周期。

具体地，耗时分析进程是与应用程序的启动进程相对应的，当操作系统判断出应用程序启动时，则开启耗时分析进程，该耗时分析进程是用于监听应用程序启动进程中启动过程中所涉及到的方法的耗时的。

此处为了避免应用程序启动时占用大量的资源导致应用程序启动变慢，因此开启一新的耗时分析进程对应用程序启动进程中所涉及的方法进行监听。

S104：判断是否执行到插桩插件，当执行到插桩插件时，则通过插桩插件记录应用程序中所涉及的方法的执行开始时间和执行结束时间。

具体地，插桩插件时预先生成的，该插桩插件可以注册到应用程序的打包流程中，这样在应用程序启动的时候，可以执行该插桩插件的代码。所涉及的方法的执行开始时间和执行结束时间是在进入方法时和方法执行结束时的时间。

其中该插桩插件的功能是通过钩子Hook Android应用程序打包过程，这样在Class文件转换成Dex文件之前遍历Class内的方法，同时使用字节码操作操作工具，在进入方法时记录当前系统时间，在方法结束时也记录当前系统时间，从而可以根据两者之差计算方法耗时，进而进行存储以备耗时分析进程对数据进行分析。

S106：将执行开始时间和执行结束时间发送至耗时分析进程。

这样在应用程序启动时，应用程序启动进程可以判断是否执行到插桩插件，若是，则将应用程序中所涉及的方法的执行开始时间和执行结束时间发送给耗时分析进程，例如耗时分析进程可以在应用程序启动进程中注册registerActivityLifecycleCallback来监听Activity的生命周期。

S108：在耗时分析进程中，根据执行开始时间和执行结束时间计算得到各个方法的耗时时间，并将耗时时间进行存储。

具体地，耗时分析进程在监听到方法的执行开始时间和执行结束时间后，可以通过执行结束时间减去执行开始时间得到耗时时间，且可选地，耗时分析进程可以在每监听到一个方法则进行计算，这样可以提高效率。例如耗时分析进程一方面在监听应用程序启动进程中方法的生命周期，另一方面根据所监听到的执行开始时间和执行结束时间实时计算得到耗时时间。

且耗时分析进程可以将所计算的耗时时间进行存储，例如存储到终端的外部存储器中，此外还可以将执行开始时间、执行结束时间以及方法所属的线程等进行存储。这样可以便于后续对耗时时间进行分析，包括但不限于，对一些方法耗时的查询和过滤功能。比如：可以按照方法的耗时时间长短排序；按照方法名字查找某个方法的耗时时，是否在主线程；以及按照时间段来过滤耗时在指定时间段的方法有哪些等。这样可以找到比较耗时的方法，进而来优化这些方法。

此外，还将上述方法封装为SDK，该SDK装置自动监听页面停留时间并上报。本实施例中分为插桩插件和耗时分析统计部分，将它们分别以jar包和aar的形式发布到私有仓库，其他项目想使用的时候直接依赖即可以完成耗时方法的统计。

上述应用程序内方法耗时统计方法，在应用程序启动后，通过插桩插件来统计应用程序中所涉及的方法的执行开始时间和执行结束时间，这样耗时分析进程中就可以根据应用程序中所涉及的方法的执行开始时间和执行结束时间计算得到耗时时间，这样通过插桩插件来进行遍历可以统计所有的方法，且采用另外的进程来进行计算可以减少性能开销，提高准确性。

在其中一个实施例中，请参见图2所示，图2为图1所示实施例中的步骤S104的流程图，在该实施例中，该步骤S204，即通过插桩插件记录应用程序中所涉及的方法的执行开始时间和执行结束时间，包括：

S202：通过插桩插件判断是否存在方法入口。

具体地，插桩插件的自定义过程可以包括新建一个Android Library项目，然后除了主目录删除主目录中的所有文件；在main目录下建立groovy目录和resources目录，groovy目录用于写插件逻辑，resources目录下用于声明自定义的插件；书写插件的方法就是，写一个类实现Plugin类，并实现其apply方法，在apply方法中完成插件逻辑；在resources目录下(建立/META-INF/gradle-plugins目录，并)建立一个(plugin.)properties的文件，在里面声明自定义的插件。这个properties文件的名称是应用插件时使用的名称。

因此在使用插桩插件的时候，可以监听Plugin类的apply方法，注册自定义的Transform，利用Transform API，第三方的插件可以在.class文件转为dex文件之前，对一些.class文件进行处理，也就是重写Transform的transform方法遍历本应用的类文件，通过ASM拿到类文件的所有方法。

S204：当存在方法入口时，则获取方法入口对应的方法的第一签名，并获取当前的系统时间作为执行开始时间，将第一签名和执行开始时间关联存储。

具体地，终端通过插桩插件找到每一个方法的入口，插入开始统计每个方法的一些字段，包括但不限于当前的系统时间作为执行开始时间、所属线程、以及方法签名等。方法签名是为了唯一确定某一个方法的标识。这样终端将当前方法的执行开始时间和所属线程的实体类作为value，存储到一个以当前方法的签名为key的map1对象中。

S206：通过插桩插件判断是否存在方法出口。

S208：当存在方法出口时，则获取方法出口对应的方法的第二签名，并获取当前的系统时间作为执行结束时间，将第二签名和执行结束时间关联存储。

终端还用于找到每一个方法的出口，插入开始统计方法的一些字段：当前的系统时间作为执行结束时间、所属线程、方法签名。终端将当前方法的执行结束时间和所属线程的实体类作为value，存储到一个以当前方法的签名为key的map2对象中。

这样就可以完成执行开始时间和执行结束时间的采集。

这样，在其中一个实施例中，在耗时分析进程中，根据执行开始时间和执行结束时间计算得到各个方法的耗时时间，包括：在耗时分析进程中，获取第一签名和第二签名相同的执行开始时间和执行结束时间；根据所获取的执行开始时间和执行结束时间计算得到对应方法的耗时时间。

也就是说耗时分析进程收到执行开始时间和执行结束时间之后，循环遍历map1并以map1的方法签名key在map2中取出对应的value，计算出方法的耗时时间＝执行结束时间-执行开始时间,并将这个方法的方法签名、耗时信息和所属线程存储到手机外部存储中。

上述实施例中，给出了插桩插件的实现方法。

在其中一个实施例中，开启耗时分析进程以监听应用程序内各个方法的生命周期之前，还包括：获取当前编译环境，并判断当前编译环境是否为预设编译环境；当当前编译环境为预设编译环境时，则继续执行开启耗时分析进程以监听应用程序内各个方法的生命周期。

具体地，为了不污染生产环境的代码，插桩插件是在编译debug包的时候使用，所以程序运行的时候也要判断编译环境为debug环境的编译出的安装包时候才能获取到方法的耗时。

也就是说编译开始，判断编译环境，如果编译环境是Debug模式，直接使用插桩插件，即启动耗时分析线程，否则直接跳过此插桩插件。

上述实施例中，通过预先对编译环境的判断，可以保证不污染生产环境的代码。

在其中一个实施例中，通过插桩插件记录应用程序中所涉及的方法的执行开始时间和执行结束时间，包括：通过钩子拦截应用程序的打包过程；在打包过程中第一类型文件转换成第二类型文件之前，通过插桩插件遍历第一类型文件中所涉及的方法，并记录所遍历的方法的执行开始时间和执行结束时间。

具体地，第一类型文件为Class文件，第二类型文件为Dex文件。

本实施例中需要自定义一个Gradle插桩插件，通过钩子Hook Android应用程序打包过程，在Class文件转换成Dex文件之前遍历Class内的方法，同时使用字节码操作操作工具，在进入方法时记录当前系统时间，在方法结束时计算方法耗时并存储以备耗时分析进程对数据进行分析。

这样当开发者编译Debug安装包时，将上述插桩插件注册到打包流程中，应用启动时判断当前安装包的编译环境，当为Debug安装包时在终端启动一个单独的进程根据插桩插件统计的数据对方法的耗时进行分析并提供友好的UI界面展示。

上述实施例中，给出了插桩插件的执行方法。

在其中一个实施例中，将耗时时间进行存储之后，还包括：通过耗时分析界面接收耗时方法获取请求；根据耗时方法获取请求查询并显示所存储的各个方法的耗时时间。

具体地，本实施例中可以使用一个单独的界面，读取存储在手机外部存储设备中数据并展示出来，此界面支持方法名、耗时时段和所属线程等多个维度的搜索。也就是说耗时分析进程可以根据存储的执行开始时间、执行结束时间以及方法对耗时时间进行分析，包括但不限于，对一些方法耗时的查询和过滤功能。比如：可以按照方法的耗时时间长短排序；按照方法名字查找某个方法的耗时时，是否在主线程；以及按照时间段来过滤耗时在指定时间段的方法有哪些等。这样分析后的数据进行存储，以便于后续读取存储在手机外部存储设备中数据并展示出来。

具体地，请参见图3，图3为另一实施例中的应用程序内方法耗时统计方法的流程图，在该实施例中该应用程序内方法耗时统计方法可以包括：

S302：在应用程序启动时候，判断当前的编译环境，如果编译环境是Debug模式，直接启动耗时分析的Service进程跳转到步骤S304，否则直接跳过。

S304：耗时分析进程启动后，对当前应用程序注册registerActivityLifecycleCallback来监听Activity的生命周期。

S306：当进入插桩插件的方法时，将当前方法的执行开始时间和所属线程的实体类为value存储到一个以当前方法的签名为key的map1对象中。

S308：当退出插桩插件的方法时，将当前方法的执行结束时间和所属线程的实体类为value存储到一个以当前方法的签名为key的map2对象中。

S310：当监听到onActivityDestroyed执行时候，将上述统计的数据传递到耗时分析的Service进程，并清空当前map1和map2的数据。

S312：耗时分析进程收到数据之后，循环遍历map1并以map1的key在map2中取出对应的value，计算出方法的耗时t＝t2-t1，并将这个方法的方法签名、耗时信息和所属线程存储到手机外部存储中。

S314：使用一个单独的界面，读取存储在手机外部存储设备中数据并展示出来，此界面支持方法名、耗时时段和所属线程等多个维度的搜索。

此外，本实施例中将上述方法封装为SDK，该SDK装置自动监听页面停留时间并上报。即将插桩插件和耗时分析统计部分分别以jar包和aar的形式发布到私有仓库，其他项目想使用的时候直接依赖即可以完成耗时方法的统计。

应该理解的是，虽然图1-3的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，图1-3中的至少一部分步骤可以包括多个步骤或者多个阶段，这些步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤中的步骤或者阶段的至少一部分轮流或者交替地执行。

在一个实施例中，如图4所示，提供了一种应用程序内方法耗时统计装置，包括：进程启动模块100、插件执行模块200、发送模块300和耗时分析模块400，其中：

进程启动模块100，用于在应用程序启动时，开启耗时分析进程以监听应用程序内各个方法的生命周期；

插件执行模块200，用于判断是否执行到插桩插件，当执行到插桩插件时，则通过插桩插件记录应用程序中所涉及的方法的执行开始时间和执行结束时间；

发送模块300，用于将执行开始时间和执行结束时间发送至耗时分析进程；

耗时分析模块400，用于在耗时分析进程中，根据执行开始时间和执行结束时间计算得到各个方法的耗时时间，并将耗时时间进行存储。

在其中一个实施例中，插件执行模块200包括：

第一判断单元，用于通过插桩插件判断是否存在方法入口；

第一记录单元，用于当存在方法入口时，则获取方法入口对应的方法的第一签名，并获取当前的系统时间作为执行开始时间，将第一签名和执行开始时间关联存储；

第二判断单元，用于通过插桩插件判断是否存在方法出口；

第二记录单元，用于当存在方法出口时，则获取方法出口对应的方法的第二签名，并获取当前的系统时间作为执行结束时间，将第二签名和执行结束时间关联存储。

在其中一个实施例中，上述的耗时分析模块400可以包括：

时间获取单元，用于在耗时分析进程中，获取第一签名和第二签名相同的执行开始时间和执行结束时间；

计算单元，用于根据所获取的执行开始时间和执行结束时间计算得到对应方法的耗时时间。

在其中一个实施例中，上述的应用程序内方法耗时统计装置还可以包括：

判断模块，用于获取当前编译环境，并判断当前编译环境是否为预设编译环境；

进程启动模块100还用于当当前编译环境为预设编译环境时，则继续执行开启耗时分析进程以监听应用程序内各个方法的生命周期。

在其中一个实施例中，插件执行模块200可以包括：

拦截单元，用于通过钩子拦截应用程序的打包过程；

遍历单元，用于在打包过程中第一类型文件转换成第二类型文件之前，通过插桩插件遍历第一类型文件中所涉及的方法，并记录所遍历的方法的执行开始时间和执行结束时间。

在其中一个实施例中，上述的应用程序内方法耗时统计装置还可以包括：

请求接收模块，用于通过耗时分析界面接收耗时方法获取请求；

显示模块，用于根据耗时方法获取请求查询并显示所存储的各个方法的耗时时间。

关于应用程序内方法耗时统计装置的具体限定可以参见上文中对于应用程序内方法耗时统计方法的限定，在此不再赘述。上述应用程序内方法耗时统计装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。

在一个实施例中，提供了一种计算机设备，该计算机设备可以是终端，其内部结构图可以如图5所示。该计算机设备包括通过系统总线连接的处理器、存储器、通信接口、显示屏和输入装置。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统和计算机程序。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的通信接口用于与外部的终端进行有线或无线方式的通信，无线方式可通过WIFI、运营商网络、NFC(近场通信)或其他技术实现。该计算机程序被处理器执行时以实现一种应用程序内方法耗时统计方法。该计算机设备的显示屏可以是液晶显示屏或者电子墨水显示屏，该计算机设备的输入装置可以是显示屏上覆盖的触摸层，也可以是计算机设备外壳上设置的按键、轨迹球或触控板，还可以是外接的键盘、触控板或鼠标等。

本领域技术人员可以理解，图5中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

在一个实施例中，提供了一种计算机设备，包括存储器和处理器，存储器中存储有计算机程序，该处理器执行计算机程序时实现以下步骤：在应用程序启动时，开启耗时分析进程以监听应用程序内各个方法的生命周期；判断是否执行到插桩插件，当执行到插桩插件时，则通过插桩插件记录应用程序中所涉及的方法的执行开始时间和执行结束时间；将执行开始时间和执行结束时间发送至耗时分析进程；在耗时分析进程中，根据执行开始时间和执行结束时间计算得到各个方法的耗时时间，并将耗时时间进行存储。

在一个实施例中，处理器执行计算机程序时所实现的通过插桩插件记录应用程序中所涉及的方法的执行开始时间和执行结束时间，包括：通过插桩插件判断是否存在方法入口；当存在方法入口时，则获取方法入口对应的方法的第一签名，并获取当前的系统时间作为执行开始时间，将第一签名和执行开始时间关联存储；通过插桩插件判断是否存在方法出口；当存在方法出口时，则获取方法出口对应的方法的第二签名，并获取当前的系统时间作为执行结束时间，将第二签名和执行结束时间关联存储。

在一个实施例中，处理器执行计算机程序时所实现的在耗时分析进程中，根据执行开始时间和执行结束时间计算得到各个方法的耗时时间，包括：在耗时分析进程中，获取第一签名和第二签名相同的执行开始时间和执行结束时间；根据所获取的执行开始时间和执行结束时间计算得到对应方法的耗时时间。

在一个实施例中，处理器执行计算机程序时所实现的开启耗时分析进程以监听应用程序内各个方法的生命周期之前，还包括：获取当前编译环境，并判断当前编译环境是否为预设编译环境；当当前编译环境为预设编译环境时，则继续执行开启耗时分析进程以监听应用程序内各个方法的生命周期。

在一个实施例中，处理器执行计算机程序时所实现的通过插桩插件记录应用程序中所涉及的方法的执行开始时间和执行结束时间，包括：通过钩子拦截应用程序的打包过程；在打包过程中第一类型文件转换成第二类型文件之前，通过插桩插件遍历第一类型文件中所涉及的方法，并记录所遍历的方法的执行开始时间和执行结束时间。

在一个实施例中，处理器执行计算机程序时所实现的将耗时时间进行存储之后，还包括：通过耗时分析界面接收耗时方法获取请求；根据耗时方法获取请求查询并显示所存储的各个方法的耗时时间。

在一个实施例中，提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现以下步骤：在应用程序启动时，开启耗时分析进程以监听应用程序内各个方法的生命周期；判断是否执行到插桩插件，当执行到插桩插件时，则通过插桩插件记录应用程序中所涉及的方法的执行开始时间和执行结束时间；将执行开始时间和执行结束时间发送至耗时分析进程；在耗时分析进程中，根据执行开始时间和执行结束时间计算得到各个方法的耗时时间，并将耗时时间进行存储。

在一个实施例中，计算机程序被处理器执行时所实现的通过插桩插件记录应用程序中所涉及的方法的执行开始时间和执行结束时间，包括：通过插桩插件判断是否存在方法入口；当存在方法入口时，则获取方法入口对应的方法的第一签名，并获取当前的系统时间作为执行开始时间，将第一签名和执行开始时间关联存储；通过插桩插件判断是否存在方法出口；当存在方法出口时，则获取方法出口对应的方法的第二签名，并获取当前的系统时间作为执行结束时间，将第二签名和执行结束时间关联存储。

在一个实施例中，计算机程序被处理器执行时所实现的在耗时分析进程中，根据执行开始时间和执行结束时间计算得到各个方法的耗时时间，包括：在耗时分析进程中，获取第一签名和第二签名相同的执行开始时间和执行结束时间；根据所获取的执行开始时间和执行结束时间计算得到对应方法的耗时时间。

在一个实施例中，计算机程序被处理器执行时所实现的开启耗时分析进程以监听应用程序内各个方法的生命周期之前，还包括：获取当前编译环境，并判断当前编译环境是否为预设编译环境；当当前编译环境为预设编译环境时，则继续执行开启耗时分析进程以监听应用程序内各个方法的生命周期。

在一个实施例中，计算机程序被处理器执行时所实现的通过插桩插件记录应用程序中所涉及的方法的执行开始时间和执行结束时间，包括：通过钩子拦截应用程序的打包过程；在打包过程中第一类型文件转换成第二类型文件之前，通过插桩插件遍历第一类型文件中所涉及的方法，并记录所遍历的方法的执行开始时间和执行结束时间。

在一个实施例中，计算机程序被处理器执行时所实现的将耗时时间进行存储之后，还包括：通过耗时分析界面接收耗时方法获取请求；根据耗时方法获取请求查询并显示所存储的各个方法的耗时时间。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和易失性存储器中的至少一种。非易失性存储器可包括只读存储器(Read-Only Memory，ROM)、磁带、软盘、闪存或光存储器等。易失性存储器可包括随机存取存储器(Random Access Memory，RAM)或外部高速缓冲存储器。作为说明而非局限，RAM可以是多种形式，比如静态随机存取存储器(Static Random Access Memory，SRAM)或动态随机存取存储器(Dynamic Random Access Memory，DRAM)等。

以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。

Claims (10)

1.一种应用程序内方法耗时统计方法，所述方法包括：

在应用程序启动时，开启耗时分析进程以监听应用程序内各个方法的生命周期；

判断是否执行到插桩插件，当执行到插桩插件时，则通过所述插桩插件记录应用程序中所涉及的方法的执行开始时间和执行结束时间；

将所述执行开始时间和执行结束时间发送至所述耗时分析进程；

在所述耗时分析进程中，根据所述执行开始时间和执行结束时间计算得到各个方法的耗时时间，并将所述耗时时间进行存储。

2.根据权利要求1所述的方法，其特征在于，所述通过所述插桩插件记录应用程序中所涉及的方法的执行开始时间和执行结束时间，包括：

通过所述插桩插件判断是否存在方法入口；

当存在方法入口时，则获取所述方法入口对应的方法的第一签名，并获取当前的系统时间作为执行开始时间，将所述第一签名和执行开始时间关联存储；

通过所述插桩插件判断是否存在方法出口；

当存在方法出口时，则获取所述方法出口对应的方法的第二签名，并获取当前的系统时间作为执行结束时间，将所述第二签名和执行结束时间关联存储。

3.根据权利要求2所述的方法，其特征在于，所述在所述耗时分析进程中，根据所述执行开始时间和执行结束时间计算得到各个方法的耗时时间，包括：

在所述耗时分析进程中，获取所述第一签名和第二签名相同的执行开始时间和执行结束时间；

根据所获取的执行开始时间和执行结束时间计算得到对应方法的耗时时间。

4.根据权利要求1所述的方法，其特征在于，所述开启耗时分析进程以监听应用程序内各个方法的生命周期之前，还包括：

获取当前编译环境，并判断所述当前编译环境是否为预设编译环境；

当所述当前编译环境为预设编译环境时，则继续执行开启耗时分析进程以监听应用程序内各个方法的生命周期。

5.根据权利要求1至4任意一项所述的方法，其特征在于，所述通过所述插桩插件记录应用程序中所涉及的方法的执行开始时间和执行结束时间，包括：

通过钩子拦截所述应用程序的打包过程；

在所述打包过程中第一类型文件转换成第二类型文件之前，通过所述插桩插件遍历所述第一类型文件中所涉及的方法，并记录所遍历的方法的执行开始时间和执行结束时间。

6.根据权利要求1至4任意一项所述的方法，其特征在于，所述将所述耗时时间进行存储之后，还包括：

通过耗时分析界面接收耗时方法获取请求；

根据所述耗时方法获取请求查询并显示所存储的各个方法的耗时时间。

7.一种应用程序内方法耗时统计装置，其特征在于，所述装置包括：

进程启动模块，用于在应用程序启动时，开启耗时分析进程以监听应用程序内各个方法的生命周期；

插件执行模块，用于判断是否执行到插桩插件，当执行到插桩插件时，则通过所述插桩插件记录应用程序中所涉及的方法的执行开始时间和执行结束时间；

发送模块，用于将所述执行开始时间和执行结束时间发送至所述耗时分析进程；

耗时分析模块，用于在所述耗时分析进程中，根据所述执行开始时间和执行结束时间计算得到各个方法的耗时时间，并将所述耗时时间进行存储。

8.根据权利要求7所述的装置，其特征在于，所述插件执行模块包括：

第一判断单元，用于通过所述插桩插件判断是否存在方法入口；

第一记录单元，用于当存在方法入口时，则获取所述方法入口对应的方法的第一签名，并获取当前的系统时间作为执行开始时间，将所述第一签名和执行开始时间关联存储；

第二判断单元，用于通过所述插桩插件判断是否存在方法出口；

第二记录单元，用于当存在方法出口时，则获取所述方法出口对应的方法的第二签名，并获取当前的系统时间作为执行结束时间，将所述第二签名和执行结束时间关联存储。

9.一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，其特征在于，所述处理器执行所述计算机程序时实现权利要求1至6中任一项所述方法的步骤。

10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至6中任一项所述的方法的步骤。

Images