CN110311806A - 一种移动应用程序界面响应延迟诊断方法、系统及终端 - Google Patents

Abstract

本发明提供了一种移动应用程序界面响应延迟诊断方法，包括在应用程序内收集打点数据，所述打点数据为应用运行时的数据信息；根据应用运行时的数据信息，判断应用程序内存使用是否趋于稳定；分析打点数据：判断瓶颈资源，并选择一个未尝试的配置使得瓶颈资源作用增强；如果存在这样的未尝试配置，则应用新配置；如果不存在这样的未尝试配置，则测试结束；定位响应延迟问题，获取问题上下文，并判断问题是否重复；如果是，则剔除；如果不是，则输出响应延迟问题。同时提供了一种移动应用程序界面响应延迟诊断系统及终端。本发明能广泛地适用于手机终端、车载电视、智能手表等各类移动设备的应用程序，诊断应用程序的性能问题。

Description

一种移动应用程序界面响应延迟诊断方法、系统及终端

技术领域

本发明涉及移动端软件技术领域，具体是一种移动应用程序界面响应延迟诊断方法、系统及终端。

背景技术

随着移动设备多样性和数量的增加，其覆盖到的用户数量越来越大。性能问题是造成App用户流失的罪魁祸首之一。App性能问题包括ANR、网络请求错误或超时、响应速度慢、页面卡顿、流量大、耗电等等。界面响应延迟问题指的是用户在使用应用程序时，程序出现卡顿等响应不及时的情况，往往是用户能直接感知到的性能问题，对界面响应延迟问题的定位和优化，是提高用户体验的关键。

应用程序开发人员需要工具来帮助识别用户可感知的界面响应延迟问题以及导致该问题的程序Activity。除了应用程序内部因素，测试设备异构性、网络条件和许多其他因素被发现对应用程序性能有显着影响。性能测试需要尝试大规模的测试配置。但这些考虑因素的测试条件在标准移动测试中很难满足，许多开发人员被动地依赖用户报告来发现性能问题。

目前没有发现同本发明类似技术的说明或报道，也尚未收集到国内外类似的资料。

发明内容

为了解决上述现有技术中存在的测试环境导致开发人员对界面响应延迟问题的定位和优化瓶颈，本发明提供了一种移动应用程序界面响应延迟诊断方法、系统及终端。本发明首先利用插桩技术(通过修改应用程序的字节码(插桩技术))在应用程序内打点收集应用运行时包括例如用户输入、网络请求和UI更新等信息；然后对收集的信息进行统计分析，具体的，对收集的信息统计分析包括：根据UI更新的响应时间标记出界面响应延迟点；回溯检测可能导致该问题的相关程序事件，包括用户输入事件，网络请求等，定位导致该问题的原因；引入了不同的测试环境配置(如网络条件、测试手机设备配置、应用运行环境是否存在资源争用)和迭代实验机制，对可能导致界面响应延迟问题的配置条件重配置并实验，以发现可能存在的新的界面响应延迟问题。

本发明是通过以下技术方案实现的。

根据本发明的一个方面，提供了一种移动应用程序界面响应延迟诊断方法，包括：

S1，在应用程序内收集打点数据，所述打点数据为应用运行时的数据信息；

S2，根据应用运行时的数据信息，判断应用程序内存使用是否趋于稳定；如果是，则执行S3，如果不是，则返回S1；

S3，分析打点数据，其中打点数据的一部分用于执行S31，打点数据的另一部分用于执行S32：

S31，判断瓶颈资源，并选择一个未尝试的配置使得瓶颈资源作用增强；如果存在这样的未尝试配置，则应用新配置，返回S1重新开始测试；如果不存在这样的未尝试配置，则测试结束；

S32，定位响应延迟问题，获取问题上下文，并判断问题是否重复；如果是，则剔除；如果不是，则输出响应延迟问题。

优选地，所述S1中，利用插桩技术在应用程序内收集打点数据；所述应用运行时的数据信息，包括：用户输入、网络请求、位图解码、垃圾收集和内存使用情况以及UI响应时间的数据信息；

所述用户输入用于收集检测到的界面响应延迟问题的上下文以及复现导致界面响应延迟问题的操作；

所述网络请求用于诊断网络活动是否为应用运行时的某一时间段内的主要资源消耗；

所述位图解码用于诊断使用大位图是否为应用运行时的某一时间段内的主要资源消耗；

所述垃圾收集和内存使用情况用于判断当前应用程序是否已达到稳定的状态以获得测试截止时间；

所述UI响应时间作为判断是否为定位响应延迟问题的度量。

优选地，所述用户输入表示为应用运行时用户交互的UI窗口；其中：一个Activity在状态改变时调用指定的生命周期，检测这些生命周期回调用于收集检测到的界面响应延迟问题的上下文；收集用户与Activity中的UI组件的交互，用于复现导致界面响应延迟问题的操作。

优选地，所述网络请求包括所有应用程序网络请求，并记录网络请求的URL、响应时间、请求的资源类型以及请求和响应的HTTP标头和正文大小。

优选地，所述位图解码包括创建的每个位图的维度、内存消耗和解码时间。

优选地，所述垃圾收集活动通过系统日志获取,包含暂停时间、回收的字节数以及垃圾收集启动时的堆使用情况的详细信息；基于垃圾收集机制执行自动内存管理，进而获取内存使用情况。

优选地，所述UI响应时间是指：定时向Choreographer发出一个空白帧，并记录实际渲染帧的时间，时间差表示用户在当前UI更新中可感知的延迟，并且被记录为UI响应时间。

优选地，所述S2中，判断应用程序内存使用是否趋于稳定，采用检测算法将滑动窗口应用于应用程序实时内存使用值，包括：对于每个滑动窗口，检测算法执行线性回归并获得斜率ki，捕获每个窗口的内存波动；获得的所有斜率进一步拟合全局斜率k*，表明波动趋势；当应用程序达到稳定的存储状态，即|k*|<ε，其中ε为设定阈值，表明应用内存使用较为稳定，即这段测试时间足够完整，设这段测试时间为截止时间W。

优选地，所述阈值ε设定为0.00001。

优选地，每一个应用程序测试时间大于等于2W。

优选地，所述S31中，判断瓶颈资源，并选择一个未尝试的配置使得瓶颈资源作用增强，包括如下步骤：

计算修改不同维度时边缘朝向相邻配置的权重；计算每个应用程序事件类型的相关系数和UI响应时间；将每个应用程序事件进一步定位到特定类型的资源，即瓶颈资源；更高的相关性表明应用程序事件对应用程序的响应性具有更大的影响，则重新配置相应的资源，获得更多的增益，进而发现更多界面响应延迟问题，选择具有最高增益的新配置；

其中，相关性与计算得到的相关系数正相关；也就是说，计算得到的相关系数越高表明当前资源对应用程序的响应性相关性越高。

优选地，所述S32中，判断问题是否重复，包括如下步骤：

对应用程序进行时间长度为2W的测试，其中W为截止时间；利用UI响应时间作为度量分析收集的数据并选择最差的10％界面响应延迟问题事件并标记它们的出现时间点；对于每个标记的时间点，回溯搜索时间点附近可能导致界面响应延迟问题的Activity，对原因重复的界面响应延迟问题进行去重；

输出响应延迟问题，采用界面响应延迟问题的可视化报告，包括界面响应延迟问题发生时重建的屏幕截图时间轴；其中，时间轴包括来自测试工具的带时间戳的屏幕截图，提供在该时刻用户交互的组件信息，并以活动的Activity为标题；通过这个可视化的时间轴，应用程序开发人员能轻松地复现该问题。

根据本发明的第二个方面，提供了一种移动应用程序界面响应延迟诊断系统，包括：

数据收集模块，用于在应用程序内收集打点数据，所述打点数据是指应用运行时的数据信息，作为问题定位模块、原因分析模块以及重配置模块的输入数据；

问题定位模块，用于对应用程序进行测试，定位响应延迟问题并判断问题是否重复；

原因分析模块，引入不同的测试环境配置和迭代试用机制，判断当前测试的瓶颈资源；

重配置模块，选择未尝试的配置使得瓶颈资源作用增强，用于创造尽可能多的界面响应延迟问题。

优选地，所述重配置模块为所有可能的测试环境配置维护一个数据库，这是所有可用设备、网络条件和运行时资源争用设置的自由组合；当完成当前的实验后，计算修改不同维度时边缘朝向相邻顶点的权重；在实验后，计算每个程序事件类型的相关系数和UI响应时间，每个程序事件进一步定位到一种特定类型的资源；在重配置时，总是选择具有最高增益的边沿，最终，将对所有测试环境配置进行测试。

根据本发明的第三个方面，提供了一种终端，包括存储器、处理器及存储在存储器上并能够在处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时能够用于执行上述任一项所述的方法。

根据本发明的第四个方面，提供了另一种终端，包括存储器、处理器及存储在存储器上并可通过处理器运行上述任一项所述的系统。

与现有技术相比，本发明具有如下的有益效果：

本发明提供的移动应用程序界面响应延迟诊断方法，能定位应用程序的界面响应延迟问题，获得问题上下文，找到界面响应延迟的原因并通过迭代实验给出可能出现的新的界面响应延迟问题，能广泛地适用于手机终端、车载电视、智能手表等各类移动设备的应用程序，诊断应用程序的性能问题，以便开发者提早发现用户可感知的界面响应延迟问题并进行优化。

附图说明

通过阅读参照以下附图对非限制性实施例所作的详细描述，本发明的其它特征、目的和优点将会变得更明显：

图1为本发明提供的移动应用程序界面响应延迟诊断系统组成模块图；

图2为本发明一实施例中所提供的重配置方法示意图；

图3为本发明提供你的移动应用程序界面响应延迟诊断方法流程图。

具体实施方式

下面对本发明的实施例作详细说明：本实施例在以本发明技术方案为前提下进行实施，给出了详细的实施方式和具体的操作过程。应当指出的是，对本领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干变形和改进，这些都属于本发明的保护范围。

本发明实施例提供了一种移动应用程序界面响应延迟诊断方法，包括如下自动化测试过程：

S1，在应用程序内收集打点数据，所述打点数据为应用运行时的数据信息；

S2，根据应用运行时的数据信息，判断应用程序内存使用是否趋于稳定；如果是，则执行S3，如果不是，则返回S1；

S3，分析打点数据，其中一部分打点数据用于执行S31，另一部分打点数据用于执行S32；

S1，判断瓶颈资源，并选择一个未尝试的配置使得瓶颈资源作用增强；如果存在这样的未尝试配置，则应用新配置，返回S1重新开始测试；如果不存在这样的未尝试配置，则测试结束；

S32，定位响应延迟问题，获取问题上下文，并判断问题是否重复；如果是，则剔除；如果不是，则输出响应延迟问题。

进一步地，所述S1中，利用插桩技术在应用程序内收集打点数据；所述应用运行时的数据信息，包括：用户输入、网络请求、位图解码、垃圾收集和内存使用情况以及UI响应时间的数据信息；其中：

所述用户输入用于收集检测到的界面响应延迟问题的上下文以及复现导致界面响应延迟问题的操作；

所述网络请求用于诊断网络活动是否为应用运行时的某一时间段内的主要资源消耗；

所述位图解码用于诊断使用大位图是否为应用运行时的某一时间段内的主要资源消耗；

所述垃圾收集和内存使用情况用于判断当前应用程序是否已达到稳定的状态以获得测试截止时间；

所述UI响应时间用于问题定位模块中作为判断是否为定位响应延迟问题事件的度量。

进一步地，所述用户输入表示为应用运行时用户交互的UI窗口；其中：

一个Activity在状态改变时调用指定的生命周期，检测这些生命周期回调用于收集检测到的界面响应延迟问题的上下文；

收集用户与Activity中的UI组件的交互，用于复现导致界面响应延迟问题的操作。

进一步地，所述网络请求包括所有应用程序网络请求，并记录网络请求的URL、响应时间、请求的资源类型以及请求和响应的HTTP标头和正文大小。

进一步地，所述位图解码包括创建的每个位图的维度、内存消耗和解码时间。

进一步地，所述垃圾收集活动通过系统日志获取,包含暂停时间、回收的字节数以及垃圾收集启动时的堆使用情况的详细信息；基于垃圾收集机制执行自动内存管理，进而获取内存使用情况。

进一步地，所述UI响应时间是指：定时向Choreographer发出一个空白帧，并记录实际渲染帧的时间，时间差表示用户在当前UI更新中可感知的延迟，并且被记录为UI响应时间。

进一步地，所述S2，判断应用程序内存使用是否趋于稳定的具体步骤为：

检测算法将滑动窗口应用于应用程序实时内存使用值，具体步骤为：对于每个滑动窗口，算法执行线性回归并获得斜率ki，捕获每个窗口的内存波动。所有获得的斜率进一步拟合全局斜率k*，表明波动趋势。当应用程序已达到稳定的存储状态，即|k*|<ε(|k*|小于一定值，该一定值可以为设定的阈值ε)，表明应用内存使用较为稳定，即这段测试时间足够完整，设这段测试时间为截止时间W。为了进一步保证测试足够完整，建议每一个应用程序测试时间不应少于2W，以保证尽量不遗漏应用程序内存稳定前发生的所有界面响应延迟问题事件。

进一步地，阈值ε可以设定为0.00001，即全局斜率|k*|小于0.00001时，表明应用内存使用较为稳定。

进一步地，所述S31中，判断瓶颈资源，并选择一个未尝试的配置使得瓶颈资源作用增强，具体包括如下步骤：

计算修改不同维度(设备，网络，争用条件)时边缘朝向相邻配置的权重。权重是增益函数的结果，代表使用目标配置查找新错误的机会。在实验后，计算每个程序事件类型的相关系数和UI响应时间。每个程序事件进一步定位到一种特定类型的资源。例如，网络请求自然受限于网络条件；GC相关问题映射到Android版本(设备)；UI线程事件和位图解码映射到CPU(设备)和竞争进程(争用条件)。更高的相关性表明程序事件对应用程序的响应性具有更大的影响，如果重新配置相应的资源，则可能获得更多的增益，也就是可能发现更多界面响应延迟问题，选择具有最高增益的新配置。

进一步地，所述S32中，定位响应延迟问题，断问题是否重复，具体包括如下步骤：

对应用程序进行时间长度为2W的测试，其中W为截止时间；利用UI响应时间作为度量分析收集的数据并选择最差的10％界面响应延迟问题事件并标记它们的出现时间点；对于每个标记的时间点，回溯搜索时间点附近可能导致界面响应延迟问题的Activity，对原因重复的界面响应延迟问题进行去重。

进一步地，所述S32中，输出响应延迟问题，采用界面响应延迟问题的可视化报告，包括界面响应延迟问题发生时重建的屏幕截图时间轴；其中，时间轴包括来自测试工具的带时间戳的屏幕截图，提供在该时刻用户交互的组件信息，并以活动的Activity为标题；通过这个可视化的时间轴，应用程序开发人员能轻松地复现该问题。

进一步地，计算截止时间的方法包括：

将滑动窗口应用于应用程序实时内存使用值；对于每个滑动窗口，执行线性回归并获得斜率ki，捕获每个窗口的内存波动；所有获得的斜率进一步拟合全局斜率k*，表明波动趋势；当应用程序已达到稳定的存储状态，即|k*|<ε，其中|k*|小于一设定值ε，表明应用内存使用较为稳定，即这段测试时间足够完整，设这段测试时间为截止时间W。

本发明实施例还提供了一种移动应用程序界面响应延迟诊断系统，包括：

数据收集模块，用于在应用程序内收集打点数据，所述打点数据是指应用运行时的数据信息，为后续三个模块提供数据；

问题定位模块，用于对应用程序进行测试，定位响应延迟问题并判断问题是否重复；

原因分析模块，引入不同的测试环境配置和迭代试用机制，判断当前测试的瓶颈资源；

重配置模块，选择未尝试的配置使得瓶颈资源作用增强，用于创造尽可能多的界面响应延迟问题。

进一步地，所述重配置模块为所有可能的测试环境配置维护一个数据库，这是所有可用设备、网络条件和运行时资源争用设置的自由组合；当完成当前的实验后，计算修改不同维度时边缘朝向相邻顶点的权重；在实验后，计算每个程序事件类型的相关系数和UI响应时间，每个程序事件进一步定位到一种特定类型的资源；在重配置时，总是选择具有最高增益的边沿，最终，将对所有测试环境配置进行测试。

下面结合附图，对本发明上述实施例所提供的技术方案进一步详细描述。

如图1所示，本发明上述实施例所提供的方法，主要包括以下自动化测试过程：

S1，在应用程序内收集打点数据，所述打点数据为应用运行时的数据信息；

S2，根据应用运行时的数据信息，判断应用程序内存使用是否趋于稳定；如果是，则执行S3，如果不是，则返回S1；

S3，分析打点数据，其中一部分打点数据用于执行S31，另一部分打点数据用于执行S32；

S31，判断瓶颈资源，并选择一个未尝试的配置使得瓶颈资源作用增强；如果存在这样的未尝试配置，则应用新配置，返回S1重新开始测试；如果不存在这样的未尝试配置，则测试结束；

S32，定位响应延迟问题，获取问题上下文，并判断问题是否重复；如果是，则剔除；如果不是，则输出响应延迟问题。

如图3所示，本发明上述实施例所提供的系统，主要包括以下几个模块：

第一，数据收集模块

利用插桩技术在应用程序内收集打点数据，收集应用运行时包括例如用户输入、网络请求、位图解码、垃圾收集和内存使用情况、UI响应时间等信息。

用户输入表示为Android应用运行时用户交互的UI窗口。一个Activity在状态改变时调用指定的生命周期方法。检测这些生命周期回调以收集检测到的界面响应延迟问题的上下文。此外，收集用户与Activity中的UI组件的交互，以便开发人员在必要时能够复现导致界面响应延迟问题的操作。

大多数应用程序运行时需要执行大量网络请求，本发明获取所有应用程序网络请求，并记录请求的URL、响应时间、请求的资源类型(MIME类型)以及请求和响应的HTTP标头和正文大小。这些数据有助于诊断网络活动是否为应用运行时的某一时间段内的主要资源消耗。

应用程序广泛使用位图图像，范围从小图标到全屏图像。位图解码会占用资源。使用大位图是性能问题的常见原因，因此本发明记录位图解码中创建的每个位图的维度，内存消耗和解码时间。

垃圾收集(GC)和内存使用情况。在Android/Java程序中，垃圾收集机制执行自动内存管理。Modern ART GC将对象标记为在专用GC线程中回收，然后短时间暂停所有正在运行的线程以回收标记对象。频繁的GC是性能和响应问题的常见原因。本发明从Android的系统日志(logcat)获取详细的GC活动，其中包含暂停时间，回收的字节数以及GC启动时的堆使用情况的详细信息。

UI响应时间。UI响应时间是一种用户可直接感知的性能因素，每秒60帧的UI刷新率可以产生流畅的用户体验。Android 4.1引入了Choreographer类来协调动画和绘图操作的处理。本发明定时向Choreographer发出一个空白帧，并记录实际渲染帧的时间。时间差表示用户在当前UI更新中可感知的延迟，并且被记录为UI响应时间。

本发明的准确性很大程度上受所收集数据量的影响。为了避免测试的过早终止导致无法发现足够多的界面响应延迟问题，本发明包括一个确保基础测试(主要是自动化测试)能够发现足够多界面响应延迟问题的截止时间计算模块，计算出一个能够出现足够多界面响应延迟问题的截止时间，定义为截止时间。截止时间计算模块计算截止时间时，采用检测算法将滑动窗口应用于应用程序实时内存使用值，具体步骤为：对于每个滑动窗口，算法执行线性回归并获得斜率ki，捕获每个窗口的内存波动。所有获得的斜率进一步拟合全局斜率k*，表明波动趋势。当应用程序已达到稳定的存储状态，即|k*|<ε(|k*|小于一定值)，表明应用内存使用较为稳定，即这段测试时间足够完整，设这段时间为截止时间W。为了进一步保证测试足够完整，建议每一个应用程序测试时间不应少于2W，以保证尽量不遗漏应用程序内存稳定前发生的所有界面响应延迟问题事件。

第二，问题定位模块

利用自动化测试工具，对应用程序进行时间长度为2W的测试，利用UI响应时间作为度量分析收集的数据并选择最差的10％界面响应延迟问题事件并标记它们的出现时间点。对于每个标记的时间点，回溯搜索时间点附近可能导致界面响应延迟问题的Activity，对原因重复的界面响应延迟问题进行去重。提供界面响应延迟问题的可视化报告，包括界面响应延迟问题发生时重建的屏幕截图时间轴；时间轴包括来自测试工具的带时间戳的屏幕截图，提供在该时刻用户交互的组件信息，并以活动的Activity为标题。通过这个可视化的时间轴，应用程序开发人员能轻松地复现该问题。

第三，原因分析模块

除了给出可能导致界面响应延迟问题的Activity信息，本发明还引入了不同的测试环境配置(如网络条件、测试手机设备配置、应用运行环境是否存在资源争用)和迭代实验机制。操作环境的不同配置将严重影响应用程序性能。例如，网络请求的响应时间将受到无线网络条件的显着影响。此外，由于硬件差异和Android ART的不同GC算法，不同的设备可能会影响应用执行任务，GC时间和频率，从而导致应用程序性能不同。因此，为了检测尽可能多的界面响应延迟问题，本发明引入了不同的测试环境配置和迭代试用机制。

本发明为所有可能的测试配置维护一个数据库，这是所有可用设备，网络条件和运行时资源争用设置的自由组合。在图2中显示的每个顶点代表一种真实的测试环境配置，有三个维度(设备，网络，争用条件)。每种测试环境配置只能在一个维度上进行修改，重配置成下一个测试环境(即当前顶点的邻居顶点)。例如从初始测试配置C1开始。完成一次实验后，从当前测试配置(顶点)的邻居C2/C3/C4中选择下一个实验环境配置。

当完成当前的实验后，计算修改不同维度时边缘朝向相邻顶点的权重。权重是增益函数的结果，代表使用目标配置查找新错误的机会。在实验后，计算每个程序事件类型的相关系数和UI响应时间。每个程序事件进一步定位到一种特定类型的资源。例如，网络请求自然受限于网络条件；GC相关问题映射到Android版本(设备)；UI线程事件和位图解码映射到CPU(设备)和竞争进程(争用条件)。更高的相关性表明程序事件对应用程序的响应性具有更大的影响，相关性最高的维度即为瓶颈资源。

第四，重配置模块

如果在瓶颈资源的维度进行重新配置实验，则可能获得更多的增益，也就是可能发现更多界面响应延迟问题。在重配置模块，在最高增益的维度选择未尝试的配置，判断是否存在这样的未尝试配置，若没有，则在第二高增益的维度选择未尝试的配置。最终，对所有顶点进行测试。

为验证本发明的有效性，下面对本发明上述实施例所提供的技术方案的有效性进行评估实验。

本实验对Google Play商店和腾讯应用市场的30个应用进行测试，涵盖主要业务类别，如新闻，音乐，视频，社交媒体，阅读，购物，制作，工具等。所有挑选的应用程序都有广泛的用户接受度(超过10万次下载)，至少有4.3的正面评级。

对所有应用进行实验，共识别出123种不同的界面响应延迟问题(每个应用程序大约有4个问题)，平均测试截止时间为15分钟。对于每个问题，本发明能根据应用程序性能指标分析原因。它主要包括UI线程耗时操作，HTTP响应和位图解码。平均而言，每个应用程序都找到至少20个证据来解释检测到的界面响应延迟问题。除此之外，通过重配置实验，应用程序发现了平均至少5个新的界面响应延迟问题。

实验证明，本发明能定位应用程序的界面响应延迟问题，获得问题上下文，找到界面响应延迟的原因并通过迭代实验给出可能出现的新的界面响应延迟问题，能广泛地适用于手机终端、车载电视、智能手表等各类移动设备的应用程序，诊断应用程序的性能问题，以便开发者提早发现用户可感知的界面响应延迟问题并进行优化。

基于本发明上述实施例提供的方法及系统，本发明实施例还提供了一种终端，包括存储器、处理器及存储在存储器上并能够在处理器上运行的计算机程序，所述处理器执行所述计算机程序时能够用于执行上述任一项所述的方法。

基于本发明上述实施例提供的方法及系统，本发明实施例还提供了另一种终端，包括存储器、处理器及存储在存储器上并可通过处理器运行上述任一项所述的系统。

进一步地，系统可用于执行上述的方法。

需要说明的是，本发明提供的所述方法中的步骤，可以利用所述系统中对应的模块、装置、单元等予以实现，本领域技术人员可以参照所述系统的技术方案实现所述方法的步骤流程，即，所述系统中的实施例可理解为实现所述方法的优选例，在此不予赘述。

本领域技术人员知道，除了以纯计算机可读程序代码方式实现本发明提供的系统及其各个模块、装置、单元以外，完全可以通过将方法步骤进行逻辑编程来使得本发明提供的系统及其各个装置以逻辑门、开关、专用集成电路、可编程逻辑控制器以及嵌入式微控制器等的形式来实现相同功能。所以，本发明提供的系统及其各项装置可以被认为是一种硬件部件，而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构；也可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。

以上对本发明的具体实施例进行了描述。需要理解的是，本发明并不局限于上述特定实施方式，本领域技术人员可以在权利要求的范围内做出各种变形或修改，这并不影响本发明的实质内容。

Claims (10)

1.一种移动应用程序界面响应延迟诊断方法，其特征在于，包括：

S1，在应用程序内收集打点数据，所述打点数据为应用运行时的数据信息；

S2，根据应用运行时的数据信息，判断应用程序内存使用是否趋于稳定；如果是，则执行S3，如果不是，则返回S1；

S3，分析打点数据，包括：

S31，判断瓶颈资源，并选择一个未尝试的配置使得瓶颈资源作用增强；如果存在这样的未尝试配置，则应用新配置，返回S1重新开始测试；如果不存在这样的未尝试配置，则测试结束；

S32，定位响应延迟问题，获取问题上下文，并判断问题是否重复；如果是，则剔除；如果不是，则输出响应延迟问题。

2.根据权利要求1所述的移动应用程序界面响应延迟诊断方法，其特征在于，所述S1中，利用插桩技术在应用程序内收集打点数据；所述应用运行时的数据信息，包括：用户输入、网络请求、位图解码、垃圾收集和内存使用情况以及UI响应时间的数据信息；

所述用户输入用于收集检测到的界面响应延迟问题的上下文以及复现导致界面响应延迟问题的操作；

所述网络请求用于诊断网络活动是否为应用运行时的某一时间段内的主要资源消耗；

所述位图解码用于诊断使用大位图是否为应用运行时的某一时间段内的主要资源消耗；

所述垃圾收集和内存使用情况用于判断当前应用程序是否已达到稳定的状态以获得测试截止时间；

所述UI响应时间作为判断是否为定位响应延迟问题的度量。

3.根据权利要求2所述的移动应用程序界面响应延迟诊断方法，其特征在于，

所述用户输入表示为应用运行时用户交互的UI窗口；其中：一个Activity在状态改变时调用指定的生命周期，检测这些生命周期回调用于收集检测到的界面响应延迟问题的上下文；收集用户与Activity中的UI组件的交互，用于复现导致界面响应延迟问题的操作；

所述网络请求包括所有应用程序网络请求，并记录网络请求的URL、响应时间、请求的资源类型以及请求和响应的HTTP标头和正文大小；

所述位图解码包括创建的每个位图的维度、内存消耗和解码时间；

所述垃圾收集活动通过系统日志获取,包含暂停时间、回收的字节数以及垃圾收集启动时的堆使用情况的详细信息；基于垃圾收集机制执行自动内存管理，进而获取内存使用情况；

所述UI响应时间是指：定时向Choreographer发出一个空白帧，并记录实际渲染帧的时间，时间差表示用户在当前UI更新中可感知的延迟，并且被记录为UI响应时间。

4.根据权利要求1所述的移动应用程序界面响应延迟诊断方法，其特征在于，所述S2中，判断应用程序内存使用是否趋于稳定，采用检测算法将滑动窗口应用于应用程序实时内存使用值，包括：对于每个滑动窗口，检测算法执行线性回归并获得斜率ki，捕获每个窗口的内存波动；获得的所有斜率进一步拟合全局斜率k*，表明波动趋势；当应用程序达到稳定的存储状态，即|k*|<ε，其中ε为设定的阈值，表明应用内存使用稳定，即这段测试时间足够完整，设这段测试时间为截止时间W。

5.根据权利要求4所述的移动应用程序界面响应延迟诊断方法，其特征在于，所述阈值ε设定为0.00001；和/或

每一个应用程序测试时间大于等于2W。

6.根据权利要求1所述的移动应用程序界面响应延迟诊断方法，其特征在于，所述S31中，判断瓶颈资源，并选择一个未尝试的配置使得瓶颈资源作用增强，包括如下步骤：

计算修改不同维度时边缘朝向相邻配置的权重；计算每个应用程序事件类型的相关系数和UI响应时间；将每个应用程序事件进一步定位到特定类型的资源，即瓶颈资源；更高的相关性表明应用程序事件对应用程序的响应性具有更大的影响，则重新配置相应的资源，获得更多的增益，进而发现更多界面响应延迟问题，选择具有最高增益的新配置；

其中，相关性与计算得到的相关系数正相关。

7.根据权利要求1所述的移动应用程序界面响应延迟诊断方法，其特征在于，所述S32中，判断问题是否重复，包括如下步骤：

对应用程序进行时间长度为2W的测试，其中W为截止时间；利用UI响应时间作为度量分析收集的数据并选择最差的10％界面响应延迟问题事件并标记它们的出现时间点；对于每个标记的时间点，回溯搜索时间点附近可能导致界面响应延迟问题的Activity，对原因重复的界面响应延迟问题进行去重；

输出响应延迟问题，采用界面响应延迟问题的可视化报告，包括界面响应延迟问题发生时重建的屏幕截图时间轴；其中，时间轴包括来自测试工具的带时间戳的屏幕截图，提供在该时刻用户交互的组件信息，并以活动的Activity为标题；通过这个可视化的时间轴，应用程序开发人员能轻松地复现该问题。

8.一种移动应用程序界面响应延迟诊断系统，其特征在于，包括：

数据收集模块，用于在应用程序内收集打点数据，所述打点数据是指应用运行时的数据信息，作为问题定位模块、原因分析模块以及重配置模块的输入数据；

问题定位模块，用于对应用程序进行测试，定位响应延迟问题并判断问题是否重复；

原因分析模块，引入不同的测试环境配置和迭代试用机制，判断当前测试的瓶颈资源；

重配置模块，选择未尝试的配置使得瓶颈资源作用增强，用于创造尽可能多的界面响应延迟问题。

9.根据权利要求8所述的移动应用程序界面响应延迟诊断系统，其特征在于，所述重配置模块为所有可能的测试环境配置维护一个数据库，这是所有可用设备、网络条件和运行时资源争用设置的自由组合；当完成当前的实验后，计算修改不同维度时边缘朝向相邻顶点的权重；在实验后，计算每个程序事件类型的相关系数和UI响应时间，每个程序事件进一步定位到一种特定类型的资源；在重配置时，总是选择具有最高增益的边沿，最终，将对所有测试环境配置进行测试。

10.一种终端，包括存储器、处理器及存储在存储器上并能够在处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时能够用于执行权利要求1至7中任一项所述的方法。