CN115016866A - 应用启动时的数据处理方法、电子设备及存储介质 - Google Patents

Abstract

本申请提供了一种应用启动时的数据处理方法、电子设备及存储介质，涉及通信技术领域。响应于对第一应用的点击事件，执行第一应用的应用启动过程，该应用启动过程包括活动activity创建、进程创建以及窗口动效绘制；获取应用启动跟手阶段的耗时信息，当耗时信息对应的统计数值大于或等于预设阈值时，获取***状态信息，该***状态信息包括在应用启动跟手阶段的各项***性能参数。由于在应用启动时一旦应用启动跟手阶段耗时超过阈值，则触发***状态信息的采集，通过分析***状态信息可实现及时发现跟手性差的场景或问题，找到应用启动慢（即跟手耗时较长）的原因，以通过软件升级和测试来提升跟手体验。

Description

应用启动时的数据处理方法、电子设备及存储介质

技术领域

本申请涉及通信技术领域，尤其涉及一种应用启动时的数据处理方法、电子设备及存储介质。

背景技术

随着电子技术及通信技术的发展，智能手机安装的应用程序（application，APP）越来越丰富，使用功能越来越多样化，例如用户在智能手机上通常会安装社交类、新闻类、金融类、娱乐类、阅读类等各种应用。

用户通过点击桌面应用图标，可以触发应用启动。在应用启动过程中，手机通常会先完成应用的启动窗口动效绘制，即完成窗口动效绘制，然后手机再展示应用的主界面，供用户操作。

然而，当用户触发启动应用时，会发生点击应用图标后到启动窗口动效绘制过程慢的情况，这些问题从用户角度可以描述为“卡顿不流畅、点击屏幕响应慢、跟手性较差”。面临应用启动慢的问题，目前需要在软件上进行测试及改进，以提升跟手体验。

发明内容

本申请提供一种应用启动时的数据处理方法及电子设备，能够针对目前应用启动慢的问题准确定位软件实现的细节问题，并获取相应的***状态数据，供软件测试及改进使用，从而提升跟手体验。

为达到上述目的，本申请采用如下技术方案：

第一方面，本申请提供一种应用启动时的数据处理方法，该方法包括：

检测到与桌面中的第一应用图标对应的点击事件，第一应用图标对应于第一应用；

响应于点击事件，执行第一应用的应用启动过程，该应用启动过程包括活动activity创建、进程创建以及窗口动效绘制；

获取应用启动耗时信息，应用启动耗时信息用于指示从点击第一应用图标的时刻到窗口动效绘制的时刻之间的第一时间段；

当第一时间段大于或等于第一预设时长阈值时，获取***状态信息，该***状态信息包括电子设备的操作***在第一时间段内，与应用启动过程相关的各项性能参数。

通过本申请方案，响应于对第一应用的点击事件，执行第一应用的应用启动过程，该应用启动过程包括活动activity创建、进程创建以及窗口动效绘制；获取应用启动跟手阶段的耗时信息，当耗时信息对应的统计数值大于或等于预设阈值时，获取***状态信息，该***状态信息包括在应用启动跟手阶段的各项***性能参数。由于在应用启动时一旦应用启动跟手阶段耗时超过阈值，则触发***状态信息的采集，通过分析***状态信息可实现及时发现跟手性差的场景或问题，找到应用启动慢（即跟手耗时较长）的原因，以便于通过软件升级和测试来提升跟手体验。

其中，上述***状态信息可以包括CPU运行的频率、大小核运行负载（CPU的占用率）、是否有因输入/输出（I/O）、内存导致的阻塞、应用启动过程中主进程在CPU不同核心上执行的分布情况、各线程执行耗时、应用与***之间交互的运行情况等信息等与应用启动过程相关的各项性能参数。这些性能参数可以用于分析应用启动慢（即跟手耗时较长）的原因。这样在准确定位出问题后，可以通过软件升级和测试来提升跟手体验。

需要说明的是，由于不同应用、不同手机在不同负载情况下，跟手耗时存在差异，不同芯片能力的手机统计到的数据值也不同，因此根据大数据摸底应用启动时跟手的耗时数据，当该耗时数据值超过该手机预置的门限后，即认为超过该时长后，此次启动响应是用不可接受的慢，即存在卡顿的情况，从而去捕获当前手机的运行状态，用于定位和分析该应用启动场景为何出现了卡顿的情况。

其中，当用户点击桌面中的第一应用图标以启动第一应用时，触发点击事件。示例性的，上述点击操作可以为单击、双击或者连续点击预设次数的操作。

其中，应用启动耗时信息包括点击第一应用图标的时刻、活动activity创建所需的时长，进程创建所需的时长，以及窗口动效绘制所需的时长。

其中，第一预设时长阈值可以人为设置也可以是通过终端自定，具体数值根据实际使用需求进行设置。

在一种可能实现方式中，在上述获取***状态信息之后，上述方法还包括：根据***状态信息，分析应用启动过程中导致卡顿的因素。

在一种可能实现方式中，在分析应用启动过程中导致卡顿的因素之后，方法还包括：根据应用启动过程中导致卡顿的因素，对电子设备的操作***进行软件升级和测试。

需要说明的是，在电子设备获取***状态信息之后，电子设备可以将这些***状态信息上传到云端，并在云端进行存储。云端可以不断接收电子设备上传的***状态信息，从而存储大量的***状态信息。在需要软件升级和测试时，可以从云端获取大量的***状态信息，然后根据***状态信息分析应用启动慢（即跟手耗时较长）的原因，进而进行软件升级和测试。

在一种可能实现方式中，在获取***状态信息之后，方法还包括：将***状态信息记录于日志中；在对电子设备的操作***进行软件升级和测试时，从日志中读取***状态信息。

在一种可能实现方式中，***状态信息包括第一状态信息、第二状态信息和第三状态信息；其中，第一状态信息用于指示电子设备的操作***在活动activity创建过程中的各项性能参数；第二状态信息用于指示电子设备的操作***在进程创建过程中的各项性能参数；第二状态信息用于指示电子设备的操作***在窗口动效绘制过程中的各项性能参数。

在一种可能实现方式中，获取应用启动耗时信息，包括：获取应用启动跟手阶段的时间信息，根据所述应用启动跟手阶段的时间信息，获取应用启动耗时信息。其中，应用启动跟手阶段的时间信息包括：点击所述第一应用图标的时刻、所述活动activity创建的时刻、所述进程创建的时刻、所述窗口动效绘制的时刻。

其中，第一时间段可以为第一时长、第二时长和第三时长的总和。其中，第一时长为从点击第一应用图标的时刻到活动activity创建的时刻；第二时长为从活动activity创建的时刻到进程创建的时刻；第三时长为从进程创建的时刻到窗口动效绘制的时刻。

在一种可能实现方式中，方法还包括：在活动activity创建开始处，添加第一时间戳；在进程创建开始处，添加第二时间戳；以及在窗口动效绘制开始处，添加第三时间戳。上述活动activity创建的时刻可以根据第一时间戳确定，进程创建的时刻可以根据第二时间戳确定，窗口动效绘制可以根据第三时间戳确定。

在一种可能实现方式中，在执行第一应用的应用启动过程之前，方法还包括：若操作***不存在第一应用的进程，则确定按照冷启动方式执行第一应用的应用启动过程；其中，冷启动方式对应的应用启动过程包括活动activity创建、进程创建以及窗口动效绘制。

在一种可能实现方式中，在检测到与桌面中的第一应用图标对应的点击事件之后，方法还包括：

响应于点击事件，若操作***存在第一应用的进程以及活动activity对象，则按照热启动方式执行第一应用的应用启动过程，热启动方式对应的应用启动过程包括窗口动效绘制，其中不包括活动activity创建和进程创建；

获取热启动耗时信息，热启动耗时信息用于指示窗口动效绘制完成的第二时间段；

当第二时间段大于或等于第二预设时长阈值时，获取热启动***状态信息，热启动***状态信息包括电子设备的操作***在第二时间段内，与应用启动过程相关的各项性能参数。

在一种可能实现方式中，在检测到与桌面中的第一应用图标对应的点击事件之后，方法还包括：

响应于点击事件，若操作***存在第一应用的进程但不存在活动activity对象，则按照温启动方式执行第一应用的应用启动过程，热启动方式对应的应用启动过程包括活动activity创建以及窗口动效绘制，其中不包括进程创建；

获取温启动耗时信息，温启动耗时信息用于指示从活动activity创建开始到窗口动效绘制结束的第三时间段；

当第三时间段大于或等于第三预设时长阈值时，获取温启动***状态信息，温启动***状态信息包括电子设备的操作***在第三时间段内，与应用启动过程相关的各项性能参数。

在一种可能实现方式中，方法还包括：通过在多次应用启动过程中采集应用启动耗时信息，得到应用启动耗时样本数据；根据应用启动耗时样本数据，确定第一预设时长阈值。

在一种可能实现方式中，电子设备的操作***为安卓操作***。

在一种可能实现方式中，安卓操作***包括桌面应用启动器Launcher。

其中，在检测到与桌面中的第一应用图标对应的点击事件之后，方法还包括：桌面应用启动器Launcher获取第一应用图标对应的第一应用标识；桌面应用启动器Launcher根据第一应用标识，确定第一应用为待启动的应用。

在一种可能实现方式中，安卓操作***还包括框架层。

在桌面应用启动器Launcher根据第一应用标识，确定第一应用为待启动的应用之后，方法还包括：桌面应用启动器Launcher向框架层通知启动第一应用。

其中，执行第一应用的应用启动过程，包括：电子设备通过框架层执行第一应用的应用启动过程，并通过框架层获取应用启动跟手阶段的时间信息，所述应用启动跟手阶段的时间信息包括：点击所述第一应用图标的时刻、所述活动activity创建的时刻、所述进程创建的时刻、所述窗口动效绘制的时刻。

在一种可能实现方式中，安卓操作***还包括***Native层；其中，在通过框架层获取应用启动跟手阶段的时间信息之后，方法还包括：框架层向***Native层发送应用启动跟手阶段的时间信息；***Native层对应用启动跟手阶段的时间信息进行数据处理。

在一种可能实现方式中，安卓操作***还包括数据处理平台和应用启动测试模块；其中，在***Native层对应用启动跟手阶段的时间信息进行数据处理之后，方法还包括：

***Native层将处理后的数据发送给数据处理平台；

数据处理平台根据处理后的数据统计得到第一时间段；

数据处理平台判断第一时间段是否大于或等于第一预设时长阈值；

当第一时间段大于或等于第一预设时长阈值时，数据处理平台指示电子设备的应用启动测试模块获取***状态信息；

应用启动测试模块根据数据处理平台的指示，获取***状态信息。

在一种可能实现方式中，应用启动测试模块获取***状态信息，包括：应用启动测试模块调用Systrace接口函数，Systrace接口函数具有捕获***状态信息的功能；应用启动测试模块通过Systrace接口函数，获取***状态信息。

第二方面，本申请提供一种应用启动时的数据处理装置，该装置包括用于执行上述第一方面中的方法的单元。该装置可对应于执行上述第一方面中描述的方法，该装置中的单元的相关描述请参照上述第一方面的描述，为了简洁，在此不再赘述。

其中，上述第一方面描述的方法可以通过硬件实现，也可以通过硬件执行相应的软件实现。硬件或软件包括一个或多个与上述功能相对应的模块或单元。例如，处理模块或单元、显示模块或单元等。

第三方面，本申请提供一种电子设备，电子设备包括处理器，处理器与存储器耦合，存储器用于存储计算机程序或指令，处理器用于执行存储器存储的计算机程序或指令，使得第一方面中的方法被执行。例如，处理器用于执行存储器存储的计算机程序或指令，使得该装置执行第一方面中的方法。

第四方面，本申请提供一种计算机可读存储介质，其上存储有用于实现第一方面中的方法的计算机程序（也可称为指令或代码）。例如，该计算机程序被计算机执行时，使得该计算机可以执行第一方面中的方法。

第五方面，本申请提供一种芯片，包括处理器。处理器用于读取并执行存储器中存储的计算机程序，以执行第一方面及其任意可能的实现方式中的方法。可选地，芯片还包括存储器，存储器与处理器通过电路或电线连接。

第六方面，本申请提供一种芯片***，包括处理器。处理器用于读取并执行存储器中存储的计算机程序，以执行第一方面及其任意可能的实现方式中的方法。可选地，芯片***还包括存储器，存储器与处理器通过电路或电线连接。

第七方面，本申请提供一种计算机程序产品，该计算机程序产品包括计算机程序（也可称为指令或代码），该计算机程序被计算机执行时使得该计算机实现第一方面中的方法。

可以理解的是，上述第二方面至第七方面的有益效果可以参见上述第一方面中的相关描述，在此不再赘述。

附图说明

图1为电子设备启动应用过程的界面示意图；

图2相关技术中应用启动时的一种统计输入事件的方法流程图；

图3为本申请实施例公开的一种电子设备的结构示意图；

图4为本申请实施例公开的一种电子设备的软件架构示意图；

图5为本申请实施例公开的应用启动时的数据处理方法的流程示意图；

图6为本申请实施例公开的一种应用启动时的数据处理方法的时序图；

图7为本申请实施例公开的一种应用启动时的数据处理装置的结构示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

本文中术语“和/或”，是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。本文中符号“/”表示关联对象是或者的关系，例如A/B表示A或者B。

本文中的说明书和权利要求书中的术语“第一”和“第二”等是用于区别不同的对象，而不是用于描述对象的特定顺序。在本申请实施例的描述中，除非另有说明，“多个”的含义是指两个或者两个以上，例如，多个处理单元是指两个或者两个以上的处理单元等；多个元件是指两个或者两个以上的元件等。

在本申请实施例中，“示例性的”或者“例如”等词用于表示作例子、例证或说明。本申请实施例中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念。

为便于理解本申请实施例，以下对本申请实施例的部分用语进行解释说明，以便于本领域技术人员理解。

APP的启动速度极大影响到用户体验，启动又分为冷启动、热启动和温启动三种，冷启动是从零创建进程并完成初始化的过程，是三种启动方式里面挑战最大的，而且优化了冷启动速度，也能间接优化其他启动方式，通常的启动速度优化指的是冷启动速度优化。

冷启动：指APP在手机启动后第一次运行，或者APP进程被清理（例如由于***内存紧张而引发的清理，或者用户主动触发的清理）后再次启动。也就是说，在启动应用前，***还没有该APP的任何进程。冷启动需要创建进程，APP需要初始化。冷启动的过程包括：process.start->ApplicationCreate->attachbaseContext->onCreate->onStart->onResume->activity生命周期。其中，在活动（activity）生命周期结束后，activity会被回收，即activity被删除。

热启动：指在退出APP之后，重新启动APP，在启动时APP进程存在，并且Activity对象仍然存在内存中，可以避免对象初始化以及布局解析绘制。与冷启动相比，热启动过程减少了对象初始化、用户界面（user interface，UI）的布局和渲染。例如，当用户触发手机从视频应用界面切换到桌面，查看短消息后，再返回视频应用界面，此时视频应用的启动属于热启动。热启动的过程包括：onResume->activity生命周期。

温启动：指在退出APP之后，重新启动APP,在启动时APP进程存在，但是activity对象可能因为内存不足而被回收。此时启动APP不需要重新创建进程，但是需要重新执行activity的onCreate。温启动的生命周期：onCreate->onStart->onResume->activity生命周期。

在上述三种启动方式中，冷启动耗时最长，热启动耗时最短。

应用窗口：指某个应用启动后显示内容的窗口。例如，游戏应用的应用窗口用于显示游戏应用内的内容。又例如，视频应用的应用窗口用于显示翻译应用内的内容。又例如，阅读应用的应用窗口用于显示阅读应用内的内容。

需要说明的是，每个应用的界面由一个个活动（activity）组成，而activity又由view组成，view是窗口的存在形式，窗口是view的载体。当启动activity时，通知应用进程，任何activity都隶属于应用进程。也就是说，例如阅读应用对应一个activity，备忘录对应另一个activity；这是因为备忘录应用和阅读应用是不同的应用，因而二者对应不同的activity。

点击事件：一次点击事件由一次down事件，多次move事件和一次up事件构成。down表示手势事件开始，up表示结束，move则代表着过程。其中，move事件出现的次数由用户的按压效果决定。对点击事件的检测与触控采样率有关。

触控采样率，指屏幕每一秒感知到手指动的次数。触控采样率也称为触控灵敏度，在行业里将该用户体验性能称为跟手性。触控采样率的数值越高，手指在屏幕上滑动时的跟手性或跟手体验越好，画面刷新所需时间越小，画面越流畅。例如，触控采样率可以为120Hz，即屏幕每一秒感知到手指动的次数为120次，即每秒可以采集120次数据，以120Hz的频率或速度检测点击事件。

图1示出了电子设备启动应用过程的界面示意图。如图1所示，用户点击桌面应用图标以触发应用启动的过程，从界面变化角度可以体现为以下几个节点：初始状态-->用户点击桌面应用图标-->窗口动效变化-->展示应用启动窗口-->展示应用主界面。其中，用户点击桌面应用图标到图标动效变化的这一阶段可以称为应用启动跟手阶段。窗口动效变化也称为窗口动效绘制或者窗口动效切换。

具体地，应用启动过程按照执行逻辑可分解为以下步骤：接收到用户点击桌面图标的操作-->创建应用activity-->创建应用进程-->窗口动效绘制-->展示应用启动窗口-->展示应用主界面。其中，若用户点击应用图标到窗口动效反应的时间越短，则跟手性或跟手体验越好。若点击到窗口动效反应的时间越长，则跟手性越差。

目前，通过用户体验的调研可知，用户在使用安卓设备启动应用时，会发生点击应用图标后到窗口动画展示过程慢的情况，这些问题从用户角度可以描述为“卡顿不流畅、点击屏幕响应慢、跟手性较差”。因此，为了提升跟手体验，目前针对应用启动慢的问题需要准确定位软件实现的细节问题并且相应地做软件上的改进。

图2为相关技术中应用启动时的一种统计输入事件的方法流程图，如图2所示，该方法包括S101至S107。其中，实现该方法的功能模块包括显示屏、框架层模块（Framework）、本地方法层模块（Native）和存储模块。

首先需要说明的是，安卓（Android）操作***是一种以Linux为基础的操作***，主要用于便携设备。Android***中上层（例如应用层和框架层）应用的开发一般基于Java完成。由于有些底层的任务用Java实现起来并不容易，因此当涉及本地服务、链接库或硬件驱动等方面的任务时，通常需要允许C程序来实现，而C程序运行在***Native库。***Native库包括供Java调用C++代码的接口。

S101，显示屏接收用户输入，感知到发生显示屏输入事件。

当用户在显示屏上操作时，显示屏会接收到用户输入，并感知到发生显示屏输入事件。

其中，显示屏输入事件的类型可以是点击、双击、滑动或者取消等。可以理解，这里显示屏输入事件的类型为示例性地说明，在实际实现时，显示屏输入事件的类型还可以包括其他类型的输入。

S102，显示屏向框架层模块（Framework）通知显示屏输入事件。

S103，框架层模块（Framework）解析显示屏输入事件，得到解析结果。

例如，假设显示屏输入事件为用户点击显示屏中的某一应用图标，那么框架层模块（Framework）解析显示屏输入事件，得到解析结果包括：输入事件的类型可以是点击；以及输入事件发生的时刻。

其中，解析结果可以为Java代码形式的数据。

S104，框架层模块将解析结果发送给本地方法层模块（Native）。

S105，***Native库根据解析结果进行数据处理。

由于***Native库包括供Java调用C++代码的接口，因此框架层模块（Framework）可以调用***Native库中的接口对解析结果进行数据处理。

S106，本地方法层模块（Native）将处理后的数据发送给存储模块。

S107，存储模块将处理后的数据缓存到本地。

通过上述步骤可知，在发生显示屏输入事件之后，通过在安卓框架层模块（Framework）***打点信息，解析输入事件并将解析后的数据发送给本地方法层模块（Native），由本地方法层模块（Native）对解析后的数据进行处理，最终将处理后的数据记录在本地的存储模块。其中，记录的数据包括输入事件发生的频次、时刻，以及输入事件的类型等信息。

通过图2所示步骤可知，相关技术可以针对应用内的点击、滑动等输入事件的耗时情况进行统计。

然而，通过上述现有手段无法复现或抓取该现象发生时的***运行情况，同时也无法对应用启动慢场景发生时的耗时情况进行量化和统计。

基于此，本申请实施例提供一种应用启动时的数据处理方法（简称为维护测试方法）及电子设备，通过在手机***底层的改进，以提高用户体验。

其中，通过该维护测试方法，记录应用启动跟手相关数据以及抓取***运行情况，以实现对安卓设备应用启动跟手场景的数据的监控以及量化，并且在应用启动相关数据的统计结果满足设定规则时，获取应用启动跟手阶段的***运行状态，为维护测试统计提供了数据支持。在维护测试过程中，根据***状态信息，分析应用启动慢（即跟手耗时较长）的原因，并定位问题，以通过软件升级和测试来提升跟手体验。

需要说明的是，由于不同应用、不同手机在不同负载情况下，跟手耗时存在差异，不同芯片能力的手机统计到的数据值也不同，因此根据大数据摸底应用启动时跟手的耗时数据，当该耗时数据值超过该手机预置的门限后，即认为超过该时长后，此次启动响应是用不可接受的慢，即存在卡顿的情况，从而去捕获当前手机的运行状态，用于定位和分析该应用启动场景为何出现了卡顿的情况。

参见图3，为本申请实施例提供的一种电子设备的结构示意图。电子设备100可以包括处理器110，外部存储器接口120，内部存储器121，通用串行总线（universal serialbus，USB）接口130，充电管理模块140，电源管理模块141，电池142，天线1，天线2，移动通信模块150，无线通信模块160，音频模块170，扬声器170A，受话器170B，麦克风170C，耳机接口170D，传感器模块180，按键190，马达191，指示器192，摄像头193，显示屏194，以及用户标识模块（subscriber identification module，SIM）卡接口195等。其中传感器模块180可以包括压力传感器180A，陀螺仪传感器180B，磁传感器180D，加速度传感器180E，距离传感器180F，接近光传感器180G，指纹传感器180H，触摸传感器180K，环境光传感器180L等。

可以理解的是，本申请实施例示意的结构并不构成对电子设备100的具体限定。在本申请另一些实施例中，电子设备100可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件，软件或软件和硬件的组合实现。

处理器110可以包括一个或多个处理单元，例如：处理器110可以包括应用处理器（application processor，AP），调制解调处理器，图形处理器（graphics processingunit，GPU），图像信号处理器（image signal processor，ISP），控制器，存储器，视频编解码器，数字信号处理器（digital signal processor，DSP），基带处理器，和/或神经网络处理器（neural-network processing unit，NPU）等。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。例如，处理器110用于执行本申请实施例中的环境光的检测方法。

其中，控制器可以是电子设备100的神经中枢和指挥中心。控制器可以根据指令操作码和时序信号，产生操作控制信号，完成取指令和执行指令的控制。

处理器110中还可以设置存储器，用于存储指令和数据。在一些实施例中，处理器110中的存储器为高速缓冲存储器。该存储器可以保存处理器110刚用过或循环使用的指令或数据。如果处理器110需要再次使用该指令或数据，可从存储器中直接调用。避免了重复存取，减少了处理器110的等待时间，因而提高了***的效率。

外部存储器120一般指外存储器，在本申请实施例中，外部存储器是指除电子设备的内存及处理器的高速缓存以外的储存器，该储存器一般为非易失性存储器。

内部存储器121，也可以称为“内存”，可以用于存储计算机可执行程序代码，所述可执行程序代码包括指令。内部存储器121可以包括存储程序区和存储数据区。其中，存储程序区可存储操作***，至少一个功能所需的应用程序（比如声音播放功能，图像播放功能等）等。

显示屏194用于显示图像，视频等。显示屏194包括显示面板。显示面板可以采用有机发光二极管（organic light-emitting diode，OLED）。在一些实施例中，电子设备100可以包括1个或N个显示屏194，N为大于1的正整数。

电子设备100还包括各类传感器，可以将各种不同的物理信号转换为电信号。示例性的，压力传感器180A用于感受压力信号，可以将压力信号转换成电信号。陀螺仪传感器180B可以用于确定电子设备100的运动姿态。气压传感器180C用于测量气压。磁传感器180D包括霍尔传感器。加速度传感器180E可检测电子设备100在各个方向上（一般为三轴）加速度的大小。距离传感器180F，用于测量距离。电子设备100可以通过红外或激光测量距离。接近光传感器180G可以包括例如发光二极管（LED）和光检测器，例如光电二极管。环境光传感器180L用于感知环境光亮度。电子设备100可以根据感知的环境光亮度自适应调节显示屏194亮度。指纹传感器180H用于采集指纹。电子设备100可以利用采集的指纹特性实现指纹解锁，访问应用锁，指纹拍照，指纹接听来电等。温度传感器180J用于检测温度。在一些实施例中，电子设备100利用温度传感器180J检测的温度，执行温度处理策略。骨传导传感器180M可以获取振动信号。

触摸传感器180K，也称“触控面板”。触摸传感器180K可以设置于显示屏194，由触摸传感器180K与显示屏194组成触摸屏，也称“触控屏”。触摸传感器180K用于检测作用于其上或附近的触摸操作。触摸传感器可以将检测到的触摸操作传递给应用处理器，以确定触摸事件类型。可以通过显示屏194提供与触摸操作相关的视觉输出。在另一些实施例中，触摸传感器180K也可以设置于电子设备100的表面，与显示屏194所处的位置不同。

示例性的，在本申请实施例中，触摸传感器180K可以检测用户对应用程序的图标的点击操作，并将检测到的点击操作传递给应用处理器，确定该点击操作用于启动或运行该应用程序，进而执行该应用程序的运行操作。

电子设备100的无线通信功能可以通过天线1，天线2，移动通信模块150，无线通信模块160，调制解调处理器以及基带处理器等实现。

电子设备100可以通过音频模块170，扬声器170A，受话器170B，麦克风170C，耳机接口170D，以及应用处理器等实现音频功能。例如音乐播放，录音等。

电子设备100通过GPU，显示屏194，以及应用处理器等实现显示功能。GPU为图像处理的微处理器，连接显示屏194和应用处理器。GPU用于执行数学和几何计算，用于图形渲染。处理器110可包括一个或多个GPU，其执行程序指令以生成或改变显示信息。

电子设备100可以通过ISP，摄像头193，视频编解码器，GPU，显示屏194以及应用处理器等实现拍摄功能。

以上是以电子设备100为例对本申请实施例作出的具体说明。应该理解的是，本申请实施例示意的结构并不构成对电子设备100的具体限定。电子设备100可以具有比图中所示的更多的或者更少的部件，可以组合两个或多个的部件，或者可以具有不同的部件配置。图中所示出的各种部件可以在包括一个或多个信号处理和/或专用集成电路在内的硬件、软件、或硬件和软件的组合中实现。

本申请实施例提供的电子设备可以是用户设备（user equipment，UE），例如可以为移动终端（例如用户手机）、平板电脑、桌面型、膝上型笔记本电脑、手持计算机、上网本、个人数字助理（personal digital assistant，PDA）等设备。

另外，在上述部件之上，运行有操作***，例如Android开源操作***，在该操作***上可以安装运行应用程序。

电子设备100的操作***可以采用分层架构，事件驱动架构，微核架构，微服务架构，或云架构。本申请实施例以分层架构的Android***为例，示例性说明电子设备100的软件结构。

图4是本申请实施例的电子设备100的软件结构框图。

分层架构将软件分成若干个层，每一层都有清晰的角色和分工。层与层之间通过软件接口通信。在一些实施例中，将Android***分为四层，从上至下分别为应用程序层（applications），Java框架层（framework），***Native库（C++/C）和安卓运行时（AndroidRuntime），以及内核层（kernel）。

其中，应用程序层可以包括一系列应用程序包。例如，应用程序层可以包括相机，图库，日历，通话，地图，导航，WLAN，蓝牙，音乐，视频，短信息、读书、旅游、运动健康、智慧生活等应用程序（应用程序可以简称为桌面应用），本申请实施例对此不做任何限制。并且，应用程序层还包括桌面应用启动器（Launcher），用于实现桌面应用的启动。

本申请实施例中，应用程序层还可以包括情景感知模块、业务逻辑处理模块和业务呈现模块等。情景感知模块、业务逻辑处理模块和业务呈现模块可以是独立的APP，或者可以分别集成在不同的APP中，或者可以集成在同一个APP中，本申请不做限定。

其中，情境感知模块，常驻运行或以低功耗形式运行，具有感知外部事实或者环境的能力。情境感知模块可以通过应用程序接口（application programming interface，API）从应用程序层的其他应用程序或Java框架层或***Native库或内核层来检测相关事件和获取事件的状态，比如检测蓝牙连接、网络连接、监测用户短信、定制定时器等。在本申请实施例中，情境感知模块主要作用是监听显示屏是否有输入事件，当监听到显示屏有输入事件，将输入事件通知给业务逻辑处理模块。情境感知模块还可以用于获取该输入事件触发开启的应用（APP）的应用信息，例如应用包名。也就是说，情境感知模块可以识别输入事件是针对某个具体的应用进行的操作事件。

业务逻辑处理模块（如：计算引擎）具有业务逻辑处理能力，用于实现判断是否启动应用以及如何启动应用的逻辑。例如，业务逻辑处理模块接收到用户触发的显示屏输入事件及情境感知模块发送的被触发应用图标对应的应用信息，并由此判断是否满足应用启动条件，从而判断是否启动该应用。

业务呈现模块（如：YOYO建议），用于将应用启动窗口以及应用主界面显示或者消失在手机的屏幕上。例如，业务呈现模块接收到业务逻辑处理模块发送的启动第一应用的命令，通知窗口管理器在电子设备上显示第一应用的启动窗口，然后显示第一应用的主界面。

Java框架层为应用程序层的应用程序提供应用编程接口（applicationprogramming interface，API）和编程框架。Java框架层包括一些预先定义的函数。Java框架层可以包括窗口管理器，内容提供器，视图***，资源管理器，通知管理器等，活动管理器，剪贴板管理器等，本申请实施例对此不做任何限制。

窗口管理器用于管理窗口程序，窗口管理器可以获取显示屏尺寸，判断是否有状态栏，锁定屏幕，截取屏幕等。在本申请中，窗口管理器用于控制窗口动效绘制以及显示应用启动窗口。其中窗口动效绘制可以为窗口的尺寸由小变大以及窗口的内容由浅变深。

活动管理器用于管理各个应用程序的生命周期以及导航回退功能，负责Android的主线程创建，各个应用程序的生命周期的维护。

资源管理器为应用程序提供各种资源，比如本地化字符串，图标，图片，布局文件，视频文件等等。

Android Runtime包括核心库和虚拟机。Android Runtime负责安卓***的调度和管理。

核心库包含两部分：一部分是java语言需要调用的功能函数，另一部分是安卓的核心库。

应用程序层和Java框架层运行在虚拟机中。虚拟机将应用程序层和Java框架层的java文件执行为二进制文件。虚拟机用于执行对象生命周期的管理，堆栈管理，线程管理，安全和异常的管理，以及垃圾回收等功能。

***Native库可以包括多个功能模块。例如：表面管理器（surface manager），媒体库（media libraries），三维图形处理库（例如：openGL ES），二维图形引擎（例如：SGL）等。表面管理器用于对显示子***进行管理，并且为多个应用程序提供了二维图层和三维图层的融合。

内核层是硬件和软件之间的层。内核层至少包含显示驱动，摄像头驱动，音频驱动，传感器驱动。

需要说明的是，本申请实施例提供的应用启动时的数据处理方法可以应用于手机产品的测试（beta）阶段。应用启动时的数据处理方法包括如下两个阶段：

第一阶段：制定用于提升应用启动跟手性的测试规则。

在本申请实施例中，首先，针对相同或不同产品，多次采集在启动应用过程中跟手阶段的耗时情况，可以得到应用启动跟手阶段耗时信息（称为应用启动跟手阶段耗时的大数据）。

然后，基于采集到的应用启动跟手阶段耗时的大数据，制定用于提升应用启动跟手性的测试规则。其中，应用启动跟手阶段可以包括以下子节点：创建应用activity，创建并启动应用进程，以及窗口动效绘制（也称为应用启动窗口动效变化、桌面动效变化或者桌面动效切换）。

在本申请方案中，通过在应用启动跟手阶段的各个子节点的执行逻辑开始处分别***代码桩点（例如用于记录时间戳的代码），获取各个子节点执行的开始时刻，统计该数据并进行汇总处理，由此可以得到应用启动跟手阶段中各个子节点的耗时数据。

需要说明的是，在制定用于提升应用启动跟手性的测试规则时，可针对不同芯片能力的产品设置不同的触发阈值。

在本申请实施例中，可以基于大样本的数据制定测试规则的阈值，例如当从点击事件的时刻到窗口动效绘制的时刻之间的时长超过某个阈值时，调用Systrace接口函数，触发Systrace捕获功能，以获取应用启动跟手阶段的***状态信息。

第二阶段：当应用启动跟手阶段的耗时大于或等于阈值时，即满足测试规则，获取应用启动跟手阶段的***状态信息。

其中，该***状态信息包括电子设备的操作***在应用启动跟手阶段与应用启动过程相关的各项性能参数，如CPU运行的频率、大小核运行负载（CPU的占用率）、是否有因输入/输出（I/O）、内存导致的阻塞、应用启动过程中主进程在CPU不同核心上执行的分布情况、各线程执行耗时、应用与***之间交互的运行情况等信息。该***状态信息可以用于在测试阶段对应用启动慢问题进行准确定位及分析，进一步通过软件升级，以解决应用启动慢、卡顿的问题。

当应用启动跟手阶段的耗时超过了设置的触发阈值（即满足测试规则）时，调用Systrace接口函数，该Systrace接口函数能够实现捕获***状态信息的功能。通过调用Systrace接口函数，获取应用启动跟手阶段（问题发生时刻前后）的***状态信息，并将***状态信息记录在日志中，以便于维护测试时定位问题。

其中，Systrace接口函数是Android平台提供的一款工具，用于记录短期内的设备活动，其中记录报告中汇总了Android内核中的数据，例如CPU调度程序、磁盘活动和应用线程。这份报告可用于了解如何以最佳方式改善APP使用性能。因此，通过Systrace接口函数可以获取应用启动跟手阶段的***状态信息并记录日志，用于分析出现应用启动慢、导致卡顿的原因。

需要说明的是，由于不同应用、不同手机在不同负载情况下，跟手耗时存在差异，不同芯片能力的手机统计到的数据值也不同，因此根据大数据摸底应用启动时跟手的耗时数据，当该耗时数据值超过该手机预置的门限后，即认为超过该时长后，此次启动响应是用不可接受的慢，即存在卡顿的情况，从而去捕获当前手机的***运行状态，用于定位和分析该应用启动场景为何出现了卡顿的情况。

图5示出了本申请实施例提供的应用启动时的数据处理方法的软件架构示意图。如图5所示，以用户点击屏幕上的应用图标以启动应用为例，方法流程如下：

A1：当用户点击手机屏幕上的某一应用图标时，应用程序层感知到对桌面应用图标的点击事件。

其中，点击事件可以指手指点击，还可以指手写笔点击，本申请对此不作限定。

A2：应用程序层将点击事件通知给桌面应用启动器（Launcher）。

A3：桌面应用启动器（Launcher）识别到待启动应用为应用图标1，然后桌面应用启动器（Launcher）与Java框架层（Framework）中的服务模块进行通信，并执行APP1应用的启动过程。

在本申请实施例中，应用启动过程在安卓***的Java框架层（Framework）完成，主要涉及到Java框架层中的以下服务模块：活动任务管理服务（ActivityTaskManagerService），活动管理服务（ActivityManagerService），以及过渡动画控制模块（AppTransitionController）。

具体地，在应用启动过程中，在活动任务管理服务（ActivityTaskManagerService）中执行activity启动的行为，在活动管理服务（ActivityManagerService）中完成进程创建的行为，在过渡动画控制模块（AppTransitionController）中完成窗口动效绘制的过程。

A4：***在执行应用启动过程时，采集应用启动跟手阶段的时间信息，并将采集到的时间信息发送给***Native库的服务模块进行处理。

其中，应用启动跟手阶段也称为应用启动关键阶段，应用启动跟手阶段的时间信息也称为关键数据信息。

具体地，采集应用启动跟手阶段的时间信息，可以指采集在启动应用过程中各阶段的耗时情况，其中各阶段可以包括以下节点：创建应用activity、创建并启动应用进程，以及窗口动效绘制。进一步地，当应用启动跟手阶段耗时超过了设置的阈值时，调用Systrace接口函数，触发Systrace捕获功能，捕获问题发生时刻前后的***状态信息并将该***状态信息记录在日志中，便于维护测试时定位问题。

A5：***Native库将处理后的时间数据通过约定的格式发送给数据处理平台，数据处理平台对处理后的时间数据进行记录和统计。

基于大样本量的数据统计，可以制定满足实际使用需求的跟手测试规则。

A6：当数据统计结果满足设定的跟手测试规则时，触发调用Systrace接口函数，获取本次应用启动过程中的***状态信息。

其中，上述数据统计结果满足设定的跟手测试规则，可以指应用启动跟手阶段耗时超过了设置的阈值。如果应用启动跟手阶段耗时超过了设置的阈值（第一预设时长阈值），那么触发维护测试数据的采集，可实现及时发现跟手性差的场景或问题，将问题发生时刻前后的***状态信息记录在日志中，便于根据问题发生时刻前后的***状态信息来定位问题，以便于软件维护测试。

A7：启动其他应用（例如APP2应用）时，执行上述A1至A6相同的流程。

可以理解的是，本申请实施例中，当应用启动跟手阶段耗时超过了设置的阈值时，捕获当前手机的***运行状态，用于定位和分析该应用启动场景为何出现了卡顿的情况。

其中，该***状态信息包括电子设备的操作***在应用启动跟手阶段，与应用启动过程相关的各项性能参数。

需要说明的是，本申请实施例虽然以Android***为例进行说明，但是其基本原理同样适用于基于iOS或Windows等操作***的电子设备。

需要说明的是，本申请实施例提供的应用启动时的数据处理方法适用于应用冷启动、热启动以及温启动（应用内启动activity）等场景。

本申请实施例提供的应用启动时的数据处理方法的执行主体可以为上述的电子设备，也可以为该电子设备中能够实现该应用启动时的数据处理方法的功能模块和/或功能实体，并且本申请方案能够通过硬件和/或软件的方式实现，具体的可以根据实际使用需求确定，本申请实施例不作限定。下面以电子设备为例，结合附图对本申请实施例提供的应用启动时的数据处理方法进行示例性的说明。

需要说明的是，在本申请实施例中，应用启动过程主要在安卓***的Java框架层（Framework）完成。Java框架层中包括活动任务管理服务（ActivityTaskManagerService），活动管理服务（ActivityManagerService），以及过渡动画控制模块（AppTransitionController）。

具体地，在应用启动过程中，在活动任务管理服务（ActivityTaskManagerService）中执行activity启动的行为，在活动管理服务（ActivityManagerService）中完成进程创建的行为，在过渡动画控制模块（AppTransitionController）中完成窗口动效绘制的过程。

还需要说明的是，本申请方案在以上各阶段逻辑执行的开始处分别***桩点，获取其执行的开始时刻，当统计到以上数据后，通过安卓内部提供的进程间通信的通道，将采集到的数据发送至***Native库进行汇总处理。

在本申请实施例提供的应用启动时的数据处理方法中，桌面应用检测到与桌面中的第一应用图标（第一应用图标对应于第一应用）对应的点击事件。响应于点击事件，桌面应用启动器（Launcher）调用框架层服务，执行第一应用的应用启动过程，该应用启动过程可以包括活动activity创建、进程创建以及窗口动效绘制。框架层服务在第一应用的应用启动过程中获取应用启动耗时信息，该应用启动耗时信息用于指示从点击第一应用图标的时刻到窗口动效绘制的时刻之间的第一时间段。当第一时间段大于或等于第一预设时长阈值时，获取***状态信息，该***状态信息包括电子设备的操作***在第一时间段内，与应用启动过程相关的各项性能参数。

示例性地，***状态信息包括第一状态信息、第二状态信息和第三状态信息；其中，第一状态信息用于指示电子设备的操作***在活动activity创建过程中的各项性能参数；第二状态信息用于指示电子设备的操作***在进程创建过程中的各项性能参数；第二状态信息用于指示电子设备的操作***在窗口动效绘制过程中的各项性能参数。

可选地，上述获取应用启动耗时信息，包括：获取第一时长、第二时长和第三时长；其中，第一时间段为第一时长、第二时长和第三时长的总和。其中，第一时长为从点击第一应用图标的时刻到活动activity创建的时刻；第二时长为从活动activity创建的时刻到进程创建的时刻；第三时长为从进程创建的时刻到窗口动效绘制的时刻。

可选地，可以在活动activity创建开始处，添加第一时间戳；并在进程创建开始处，添加第二时间戳；以及在窗口动效绘制开始处，添加第三时间戳。其中，第一时长根据点击第一应用图标的时刻和第一时间戳确定，第二时长根据第一时间戳和第二时间戳确定，第三时长根据第二时间戳和第三时间戳确定。

其中，可以通过在多次应用启动过程中采集应用启动耗时信息，得到应用启动耗时样本数据；并根据应用启动耗时样本数据，确定第一预设时长阈值。

在执行第一应用的应用启动过程之前，在本申请实施例中，在桌面应用检测到与桌面中的第一应用图标（第一应用图标对应于第一应用）对应的点击事件之后，先判断操作***是否存在第一应用的进程以及是否存在活动activity对象。若操作***不存在第一应用的进程也不存在活动activity对象，则确定按照冷启动方式执行第一应用的应用启动过程；其中，冷启动方式对应的应用启动过程包括活动activity创建、进程创建以及窗口动效绘制。

在另一种可能的情况下，在检测到与桌面中的第一应用图标对应的点击事件之后，若操作***存在第一应用的进程以及活动activity对象，则按照热启动方式执行第一应用的应用启动过程，热启动方式对应的应用启动过程包括窗口动效绘制，其中不包括活动activity创建和进程创建。然后，获取热启动耗时信息，热启动耗时信息用于指示窗口动效绘制完成的第二时间段。然后，当第二时间段大于或等于第二预设时长阈值时，获取热启动***状态信息，热启动***状态信息包括电子设备的操作***在第二时间段内，与应用启动过程相关的各项性能参数。

在再一种可能实现方式中，在检测到与桌面中的第一应用图标对应的点击事件之后，若操作***存在第一应用的进程但不存在活动activity对象，则按照温启动方式执行第一应用的应用启动过程，热启动方式对应的应用启动过程包括活动activity创建以及窗口动效绘制，其中不包括进程创建。然后，获取温启动耗时信息，温启动耗时信息用于指示从活动activity创建开始到窗口动效绘制结束的第三时间段。然后，当第三时间段大于或等于第三预设时长阈值时，获取温启动***状态信息，温启动***状态信息包括电子设备的操作***在第三时间段内，与应用启动过程相关的各项性能参数。

其中，上述获取***状态信息，包括：调用Systrace接口函数，通过Systrace接口函数，获取***状态信息；Systrace接口函数具有捕获***状态信息的功能。

下面结合具体的实施例介绍本申请实施例提供的应用启动时的数据处理方法。

实施例一

图6是本申请实施例提供的应用启动时的数据处理方法的流程示意图。参照图6所示，该方法100包括下述的步骤S201-S212。

S201，当用户点击桌面中的应用图标时，桌面应用感知点击事件。

S202，桌面应用向桌面应用启动器（Launcher）通知点击事件。

其中，点击事件的相关信息可以包括：被点击应用图标对应的应用包名，即应用名称。例如，应用包名为youxi.exe。

S203，桌面应用启动器在获知点击事件后，识别要启动的APP。

其中，桌面应用启动器可以根据应用包名，识别要启动的APP。

其中，桌面应用启动器可以调用框架层的各个模块对要启动的APP，执行应用启动过程。

S204，桌面应用启动器指示框架层模块（Framework）执行应用启动过程。

需要说明的是，应用启动过程主要是在安卓***的Java框架层（Framework）完成，主要涉及到Java框架层中的以下服务模块：ActivityTaskManagerService，ActivityManagerService，以及AppTransitionController。具体地，在应用启动过程中，通过ActivityTaskManagerService执行activity启动的行为，并通过ActivityManagerService完成进程创建的行为，并通过AppTransitionController完成窗口动效绘制的过程。

S205，框架层模块执行应用启动过程，并采集应用启动过程中关键阶段的时间信息。

再次参考图1，在从用户点击桌面应用图标到屏幕完全展示应用主界面的过程中，主要影响应用启动跟手性的阶段为应用启动跟手阶段。其中，从用户交互界面角度来看，该应用启动跟手阶段为从点击应用图标到窗口动效绘制的过程。从软件实现角度来看，该应用启动跟手阶段包括如下几个子节点：创建应用activity-->创建应用进程-->窗口动效绘制（也称为窗口动效绘制或者窗口动效绘制），为应用的启动做准备。

其中，上述S205中的关键阶段可以包括启动应用activity，创建应用进程以及窗口动效绘制等过程。

为了量化这几个阶段的耗时情况，需要在***的代码中梳理出应用启动代码执行的逻辑，并在创建应用activity、创建应用进程以及窗口动效绘制过程中，分别***代码桩点（例如用于记录时间戳的代码），用于记录对应行为发生的***时刻。

其中，上述S205中的时间信息可以包括手指点击图标的时刻（即手指点击图标抬起的时刻），应用activity创建的时刻、应用进程创建的时刻，以及启动窗口动效绘制的时刻。

S206，框架层模块向***Native库发送关键阶段的时间信息。

S207，***Native库对时间信息进行数据处理。

其中，***Native库中驻留了预设函数，用于统计点击事件发生的时刻、类型等。

当***Native库通过进程间通信接收到来自框架层Framework采集的应用启动相关数据后，***Native库将应用启动相关数据与最近的一次up事件关联，构成如下一组数据：即手指点击图标抬起的时刻、应用activity创建的时刻、应用进程创建的时刻、以及启动动效变化的时刻。

需要说明的是，启动动效变化的时刻与点击应用图标的时刻（up事件）之间的差值（即处理后的应用启动相关数据），可以反映此次启动应用跟手的耗时情况。或者，动效变化结束的时刻与点击应用图标的时刻之间的差值（即处理后的应用启动相关数据），也可以反映此次启动应用跟手的耗时情况。

S208，***Native库将处理后的应用启动相关数据发送给数据处理平台。

***Native库将处理后的应用启动相关数据通过通信协议传输至数据处理平台（大数据平台），该数据处理平台具有汇总、展示数据等功能。

其中，数据处理平台可以是电子设备侧具有数据处理功能的模块，或者数据处理平台可以是与电子设备连接的，具有数据处理功能的***设备或服务器。

S209，数据处理平台对处理后的应用启动相关数据进行记录并统计。

S210，数据处理平台判断数据统计结果是否满足设定的测试规则。

本申请方案应用于手机产品的测试（beta）阶段，采集在启动应用过程中各阶段的耗时情况，并基于采集到的大数据制定应用启动跟手测试规则，不同产品采集到的应用耗时分布不同，因此制定的规则也会随产品芯片能力有所变化。

需要说明的是，基于采集到的大数据所制定的测试规则，可针对不同芯片能力的产品设置不同的触发阈值，当应用启动跟手阶段耗时超过了设置的阈值时，就触发调用Systrace接口函数捕获功能，将问题发生时刻前后的***状态信息记录在日志中，便于维护测试时定位问题。

S211，若数据统计结果满足设定规则，则数据处理平台触发应用启动测试模块启用测试采集功能。

其中，测试采集功能也称为维测采集功能、测试数据采集功能或者维护测试数据的采集功能。

S212，应用启动测试模块调用Systrace接口函数，采集***状态信息，用于分析应用启动慢的原因。

需要说明的是，图2所示的相关技术方案中仅针对应用内的点击、滑动等输入事件的耗时情况进行统计，而未考虑该耗时数据对APP启动跟手场景的应用。与相关技术相比，本申请方案对输入事件的应用场景进行扩展，本申请方案通过对应用启动跟手阶段进行拆解，在应用启动的执行过程中添加代码逻辑，实现对应用启动跟手耗时情况的量化，丰富了相关技术方案设计的使用场景，并且制定跟手测试规则，为维护测试统计提供了数据支持。

在本申请实施例中，在应用启动测试模块获取***状态信息之后，应用启动测试模块可以根据***状态信息，分析应用启动过程中导致卡顿的因素。这样，在维护测试过程中，根据***状态信息，分析应用启动慢的原因，并定位问题。

在本申请实施例中，在分析应用启动过程中导致卡顿的因素之后，应用启动测试模块可以根据应用启动过程中导致卡顿的因素，对电子设备的操作***进行软件升级和测试。

其中，在应用启动测试模块获取***状态信息之后，应用启动测试模块可以将***状态信息记录于日志中。在对电子设备的操作***进行软件升级和测试时，从日志中读取***状态信息。

本申请方案中，可以获取应用启动过程中activity创建、进程启动和窗口动效绘制（动效绘制）等关键阶段的时间信息，并与已有技术结合，量化应用启动跟手阶段的耗时情况，覆盖应用冷启动、热启动以及应用内启动activity等场景，由此可以实现多场景下应用启动跟手阶段的数据采集。

下面说明本申请实施例中采集应用启动跟手阶段的时间信息的实现方式。

可选地，数据记录格式可以由6元组（#PKG，#INT，#DOWN，#ST1，#ST2，#ST3）构成。以从桌面启动应用为例，在***Native库完成对数据的处理，并生成如下形式的一条记录：

其中，#PKG（安装包配置文件）表示从桌面应用启动器Launcher启动应用。#INT表示启动的应用名称；#DOWN表示手指点击屏幕的***时刻。#ST1表示应用activity创建的***时刻。#ST2表示应用进程启动的***时刻，若#ST2为0表示该应用进程存在，这次启动为热启动。#ST3表示应用启动是窗口动画开始绘制的时刻。#T表示该条记录进行记录的***时刻。

可以理解，上述数据记录格式只是示例性的列举，具体可以根据实际使用需求确定，本申请实施例不作限定。

通过本申请方案，响应于对第一应用的点击事件，执行第一应用的应用启动过程，该应用启动过程包括活动activity创建、进程创建以及窗口动效绘制；获取应用启动跟手阶段的耗时信息，当耗时信息对应的统计数值大于或等于预设阈值时，获取***状态信息，该***状态信息包括在应用启动跟手阶段的各项***性能参数。由于在应用启动时一旦应用启动跟手阶段耗时超过阈值，则触发***状态信息的采集，通过分析***状态信息可实现及时发现跟手性差的场景或问题，找到应用启动慢（即跟手耗时较长）的原因，以便于通过软件升级和测试来提升跟手体验。

需要说明的是，本申请方案适用于获取手机或平板设备等电子设备的维护测试信息，同时也支持获取在手指点击、手写笔点击等点击场景中应用启动的维护测试信息。

还需要说明的是，本申请方案不仅支持通过点击桌面图标以启动应用场景中获取维护测试信息，同时支持通过下拉菜单以启动应用场景中获取维护测试信息。

也需要说明的是，在本申请实施例中，“大于”可以替换为“大于或等于”，“小于或等于”可以替换为“小于”，或者，“大于或等于”可以替换为“大于”，“小于”可以替换为“小于或等于”。

本文中描述的各个实施例可以为独立的方案，也可以根据内在逻辑进行组合，这些方案都落入本申请的保护范围中。

可以理解的是，上述各个方法实施例中由电子设备实现的方法和操作，也可以由可用于电子设备的部件（例如芯片或者电路）实现。

上文描述了本申请提供的方法实施例，下文将描述本申请提供的装置实施例。应理解，装置实施例的描述与方法实施例的描述相互对应，因此，未详细描述的内容可以参见上文方法实施例，为了简洁，这里不再赘述。

上文主要从方法步骤的角度对本申请实施例提供的方案进行了描述。可以理解的是，为了实现上述功能，实施该方法的电子设备包含了执行各个功能相应的硬件结构和/或软件模块。本领域技术人员应该可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，本申请能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的保护范围。

本申请实施例可以根据上述方法示例，对电子设备进行功能模块的划分，例如，可以对应各个功能划分各个功能模块，也可以将两个或两个以上的功能集成在一个处理模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。需要说明的是，本申请实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有其它可行的划分方式。下面以采用对应各个功能划分各个功能模块为例进行说明。

图7为本申请实施例提供的应用启动时的数据处理装置300的示意性框图。该装置300可以用于执行上文方法实施例中电子设备所执行的动作。该装置300包括人机交互单元310和处理单元320。

人机交互单元310，用于检测到与桌面中的第一应用图标对应的点击事件，第一应用图标对应于第一应用；

处理单元320，用于响应于点击事件，执行第一应用的应用启动过程，该应用启动过程包括活动activity创建、进程创建以及窗口动效绘制；

处理单元320，还用于获取应用启动耗时信息，应用启动耗时信息用于指示从点击第一应用图标的时刻到窗口动效绘制的时刻之间的第一时间段；

处理单元320，还用于当第一时间段大于或等于第一预设时长阈值时，获取***状态信息，该***状态信息包括电子设备的操作***在第一时间段内，与应用启动过程相关的各项性能参数。

通过本申请方案，响应于对第一应用的点击事件，执行第一应用的应用启动过程，该应用启动过程包括活动activity创建、进程创建以及窗口动效绘制；获取应用启动跟手阶段的耗时信息，当耗时信息对应的统计数值大于或等于预设阈值时，获取***状态信息，该***状态信息包括在应用启动跟手阶段的各项***性能参数。由于在应用启动时一旦应用启动跟手阶段耗时超过阈值，则触发***状态信息的采集，通过分析***状态信息可实现及时发现跟手性差的场景或问题，找到应用启动慢（即跟手耗时较长）的原因，以便于通过软件升级和测试来提升跟手体验。

根据本申请实施例的装置300可对应于执行本申请实施例中描述的方法，并且装置300中的单元的上述和其它操作和/或功能分别为了实现方法的相应流程，为了简洁，在此不再赘述。

可以理解的是，电子设备为了实现上述功能，其包含了执行各个功能相应的硬件和/或软件模块。结合本文中所公开的实施例描述的各示例的算法步骤，本申请能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。本领域技术人员可以结合实施例对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

本实施例可以根据上述方法示例对电子设备进行功能模块的划分，例如，可以对应各个功能划分各个功能模块，也可以将两个或两个以上的功能集成在一个处理模块中。上述集成的模块可以采用硬件的形式实现。需要说明的是，本实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。

在采用对应各个功能划分各个功能模块的情况下，电子设备还可以被划分为包括显示单元、检测单元和处理单元等。需要说明的是，上述方法实施例涉及的各步骤的所有相关内容均可以援引到对应功能模块的功能描述，在此不再赘述。

本实施例提供的电子设备，用于执行上述应用启动时的数据处理方法，因此可以达到与上述实现方法相同的效果。

在采用集成的单元的情况下，电子设备可以包括处理模块、存储模块和通信模块。其中，处理模块可以用于对电子设备的动作进行控制管理；存储模块可以用于支持电子设备执行存储程序代码和数据等；通信模块，可以用于支持电子设备与其他设备的通信。

其中，处理模块可以是处理器或控制器。其可以实现或执行结合本申请公开内容所描述的各种示例性的逻辑方框，模块和电路。处理器也可以是实现计算功能的组合，例如包含一个或多个微处理器组合，数字信号处理（digital signal processing，DSP）和微处理器的组合等等。存储模块可以是存储器。通信模块具体可以为射频电路、蓝牙芯片、Wi-Fi芯片等与其他电子设备交互的设备。

在一个实施例中，当处理模块为处理器，存储模块为存储器时，本实施例所涉及的电子设备可以为具有图3所示结构的设备。

本申请还提供一种芯片，该芯片与存储器耦合，该芯片用于读取并执行存储器中存储的计算机程序或指令，以执行上述各实施例中的方法。

本申请还提供一种电子设备，该电子设备包括芯片，该芯片用于读取并执行存储器存储的计算机程序或指令，使得各实施例中的方法被执行。

本实施例还提供一种计算机可读存储介质，该计算机可读存储介质中存储有计算机指令，当该计算机指令在电子设备上运行时，使得电子设备执行上述相关方法步骤实现上述实施例中的应用启动时的数据处理方法。

本实施例还提供了一种计算机程序产品，该计算机可读存储介质存储有程序代码，当该计算机程序产品在计算机上运行时，使得计算机执行上述相关步骤，以实现上述实施例中的应用启动时的数据处理方法。

另外，本申请的实施例还提供一种装置，这个装置具体可以是芯片，组件或模块，该装置可包括相连的处理器和存储器；其中，存储器用于存储计算机执行指令，当装置运行时，处理器可执行存储器存储的计算机执行指令，以使芯片执行上述各方法实施例中的应用启动时的数据处理方法。

其中，本实施例提供的电子设备、计算机可读存储介质、计算机程序产品或芯片均用于执行上文所提供的对应的方法，因此，其所能达到的有益效果可参考上文所提供的对应的方法中的有益效果，此处不再赘述。

本申请实施例并未对本申请实施例提供的方法的执行主体的具体结构进行特别限定，只要能够通过运行记录有本申请实施例提供的方法的代码的程序，以根据本申请实施例提供的方法处理应用启动相关数据即可。例如，本申请实施例提供的方法的执行主体可以是电子设备，或者，是电子设备中能够调用程序并执行程序的功能模块。

在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个装置，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

在本申请所提供的几个实施例中，应该理解到，所揭露的***、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个***，或一些特征可以忽略，或不执行。此外，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上，或者说对现有技术做出贡献的部分，或者该技术方案的部分，可以以计算机软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，该计算机软件产品包括若干指令，该指令用以使得一台计算机设备（可以是个人计算机，服务器，或者网络设备等）执行本申请各个实施例所述方法的全部或部分步骤。前述的存储介质可以包括但不限于：U盘、移动硬盘、ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (19)

1.一种应用启动时的数据处理方法，其特征在于，包括：

检测到与桌面中的第一应用图标对应的点击事件，所述第一应用图标对应于第一应用；

响应于所述点击事件，执行所述第一应用的应用启动过程，所述应用启动过程包括活动activity创建、进程创建以及窗口动效绘制；

获取应用启动耗时信息，所述应用启动耗时信息用于指示从点击所述第一应用图标的时刻到所述窗口动效绘制的时刻之间的第一时间段；

当所述第一时间段大于或等于第一预设时长阈值时，获取***状态信息，所述***状态信息包括电子设备的操作***在所述第一时间段内，与所述应用启动过程相关的各项性能参数。

2.根据权利要求1所述的方法，其特征在于，在所述获取***状态信息之后，所述方法还包括：

根据所述***状态信息，分析所述应用启动过程中导致卡顿的因素。

3.根据权利要求2所述的方法，其特征在于，在所述分析所述应用启动过程中导致卡顿的因素之后，所述方法还包括：

根据所述应用启动过程中导致卡顿的因素，对所述电子设备的操作***进行软件升级和测试。

4.根据权利要求1所述的方法，其特征在于，在所述获取***状态信息之后，所述方法还包括：

将所述***状态信息记录于日志中；

在对所述电子设备的操作***进行软件升级和测试时，从所述日志中读取所述***状态信息。

5.根据权利要求1至4中任一项所述的方法，其特征在于，所述***状态信息包括第一状态信息、第二状态信息和第三状态信息；

其中，所述第一状态信息用于指示所述电子设备的操作***在所述活动activity创建过程中的各项性能参数；

所述第二状态信息用于指示所述电子设备的操作***在所述进程创建过程中的各项性能参数；

所述第二状态信息用于指示所述电子设备的操作***在所述窗口动效绘制过程中的各项性能参数。

6.根据权利要求1至4中任一项所述的方法，其特征在于，所述获取应用启动耗时信息，包括：

获取应用启动跟手阶段的时间信息，所述应用启动跟手阶段的时间信息包括：点击所述第一应用图标的时刻、所述活动activity创建的时刻、所述进程创建的时刻、所述窗口动效绘制的时刻；

根据所述应用启动跟手阶段的时间信息，获取所述应用启动耗时信息。

7.根据权利要求6所述的方法，其特征在于，所述方法还包括：

在所述活动activity创建开始处，添加第一时间戳；

在所述进程创建开始处，添加第二时间戳；

在所述窗口动效绘制开始处，添加第三时间戳；

其中，所述活动activity创建的时刻根据所述第一时间戳确定，所述进程创建的时刻根据所述第二时间戳确定，所述窗口动效绘制的时刻根据所述第三时间戳确定。

8.根据权利要求1至4中任一项所述的方法，其特征在于，在所述执行所述第一应用的应用启动过程之前，所述方法还包括：

若所述操作***不存在所述第一应用的进程，则确定按照冷启动方式执行所述第一应用的应用启动过程；

其中，所述冷启动方式对应的应用启动过程包括所述活动activity创建、所述进程创建以及所述窗口动效绘制。

9.根据权利要求1至4中任一项所述的方法，其特征在于，在所述检测到与桌面中的第一应用图标对应的点击事件之后，所述方法还包括：

响应于所述点击事件，若所述操作***存在所述第一应用的进程以及活动activity对象，则按照热启动方式执行所述第一应用的应用启动过程，所述热启动方式对应的应用启动过程包括所述窗口动效绘制，其中不包括所述活动activity创建和所述进程创建；

获取热启动耗时信息，所述热启动耗时信息用于指示所述窗口动效绘制完成的第二时间段；

当所述第二时间段大于或等于第二预设时长阈值时，获取热启动***状态信息，所述热启动***状态信息包括电子设备的操作***在所述第二时间段内，与所述应用启动过程相关的各项性能参数。

10.根据权利要求1至4中任一项所述的方法，其特征在于，在所述检测到与桌面中的第一应用图标对应的点击事件之后，所述方法还包括：

响应于所述点击事件，若所述操作***存在所述第一应用的进程但不存在活动activity对象，则按照温启动方式执行所述第一应用的应用启动过程，所述温启动方式对应的应用启动过程包括所述活动activity创建以及所述窗口动效绘制，其中不包括所述进程创建；

获取温启动耗时信息，所述温启动耗时信息用于指示从所述活动activity创建开始到所述窗口动效绘制结束的第三时间段；

当所述第三时间段大于或等于第三预设时长阈值时，获取温启动***状态信息，所述温启动***状态信息包括电子设备的操作***在所述第三时间段内，与所述应用启动过程相关的各项性能参数。

11.根据权利要求1至4中任一项所述的方法，其特征在于，所述方法还包括：

通过在多次应用启动过程中采集所述应用启动耗时信息，得到应用启动耗时样本数据；

根据所述应用启动耗时样本数据，确定所述第一预设时长阈值。

12.根据权利要求1至4中任一项所述的方法，其特征在于，所述电子设备的操作***为安卓操作***。

13.根据权利要求12所述的方法，其特征在于，所述安卓操作***包括桌面应用启动器Launcher；

其中，在所述检测到与桌面中的第一应用图标对应的点击事件之后，所述方法还包括：

所述桌面应用启动器Launcher获取所述第一应用图标对应的第一应用标识；

所述桌面应用启动器Launcher根据所述第一应用标识，确定所述第一应用为待启动的应用。

14.根据权利要求13所述的方法，其特征在于，所述安卓操作***还包括框架层；

在所述桌面应用启动器Launcher根据所述第一应用标识，确定所述第一应用为待启动的应用之后，所述方法还包括：所述桌面应用启动器Launcher向所述框架层通知启动所述第一应用；

其中，所述执行所述第一应用的应用启动过程，包括：所述电子设备通过所述框架层执行所述第一应用的应用启动过程，并通过所述框架层获取应用启动跟手阶段的时间信息，所述应用启动跟手阶段的时间信息包括：点击所述第一应用图标的时刻、所述活动activity创建的时刻、所述进程创建的时刻、所述窗口动效绘制的时刻。

15.根据权利要求14所述的方法，其特征在于，所述安卓操作***还包括***Native层；其中，在所述通过所述框架层获取应用启动跟手阶段的时间信息之后，所述方法还包括：

所述框架层向所述***Native层发送所述应用启动跟手阶段的时间信息；

所述***Native层对所述应用启动跟手阶段的时间信息进行数据处理。

16.根据权利要求15所述的方法，其特征在于，所述安卓操作***还包括数据处理平台和应用启动测试模块；其中，在所述***Native层对所述应用启动跟手阶段的时间信息进行数据处理之后，所述方法还包括：

所述***Native层将处理后的数据发送给所述数据处理平台；

所述数据处理平台根据处理后的数据统计得到所述第一时间段；

所述数据处理平台判断所述第一时间段是否大于或等于所述第一预设时长阈值；

当所述第一时间段大于或等于所述第一预设时长阈值时，所述数据处理平台指示所述电子设备的应用启动测试模块获取所述***状态信息；

所述应用启动测试模块根据所述数据处理平台的指示，获取所述***状态信息。

17.根据权利要求16所述的方法，其特征在于，所述应用启动测试模块获取所述***状态信息，包括：

所述应用启动测试模块调用Systrace接口函数，所述Systrace接口函数具有捕获所述***状态信息的功能；

所述应用启动测试模块通过所述Systrace接口函数，获取所述***状态信息。

18.一种电子设备，其特征在于，包括处理器，所述处理器与存储器耦合，所述处理器用于执行所述存储器中存储的计算机程序或指令，以使得所述电子设备实现如权利要求1至17中任一项所述的方法。

19.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机程序，当所述计算机程序在电子设备上运行时，使得所述电子设备执行如权利要求1至17中任一项所述的方法。

Images