应用程序线上启动的监控方法、装置、服务器和客户端与流程

1.本公开涉及计算机技术领域，尤其涉及一种应用程序线上启动的监控方法、装置、服务器和客户端。


背景技术：

2.应用程序(application，app)线上启动的监控方法可主要实现三个目标：一是统计启动时长指标，有助于清楚地了解到线上用户启动app的时长，大致反映出用户使用app的体验；二是发现线上的函数耗时，指导app的优化方向；三是基于线上用户启动app的统计数据，有助于发现app的版本是否出现启动劣化问题。


技术实现要素：

3.为了解决上述技术问题或者至少部分地解决上述技术问题，本公开提供了一种应用程序线上启动的监控方法、装置、服务器和客户端。
4.第一方面，本公开提供了一种应用程序线上启动的监控方法，包括：
5.接收应用程序的第一版本中的不同用户的堆栈集合，每个用户的堆栈集合中包括应用程序的第一版本的启动阶段中的全部耗时函数的堆栈，每个耗时函数的堆栈是基于耗时函数的函数调用关系得到的，耗时函数为启动阶段中的自身耗时时长大于等于预设阈值的函数；
6.对不同用户的堆栈集合中的相同耗时函数的堆栈进行聚合，得到相同堆栈集合，并确定相同堆栈集合所对应的耗时函数；
7.按照预设策略，对相同堆栈集合所对应的耗时函数进行优化处理。
8.通过第一方面提供的方法，客户端确定应用程序的一个版本的启动阶段中的自身耗时时长大于等于预设阈值的全部耗时函数，并基于每个耗时函数的函数调用关系获取全部耗时函数的堆栈。客户端向服务器发送包括全部耗时函数的堆栈的一个堆栈集合，使得服务器可从不同客户端接收到应用程序的一个版本中的不同用户的堆栈集合。服务器便可对不同用户上报的不同耗时函数的堆栈中的相同耗时函数的堆栈进行聚合，得到相同堆栈集合，并按照预设策略所对应的处理顺序，对相同堆栈集合对应的耗时函数进行优化处理。从而，全面监控应用程序线上启动的函数，分析出应用程序线上启动的耗时函数，实现了自动化的耗时数据监控，指导了耗时函数的优化处理方式，有助于全面了解函数在应用程序运行在线上时的耗时和分布情况，提高了应用程序的监控效率，提升了用户使用应用程序的体验感。
9.在一种可能的设计中，该方法还包括：接收应用程序的第二版本中的不同用户的堆栈集合，其中，应用程序的第二版本中的不同用户与应用程序的第一版本中的不同用户的设备分布一致；从应用程序的第一版本中的不同用户的堆栈集合以及应用程序的第二版本中的不同用户的堆栈集合中，获取相同用户数量的堆栈集合；基于相同用户数量的堆栈集合，对应用程序的第二版本和应用程序的第一版本进行比较，得到比较结果；基于比较结
果，对应用程序的第一版本的线上启动进行监控。从而，服务器能够基于两个版本中相同数量的堆栈集合，确定出应用程序的一个版本相比于应用程序的另一个版本而言是否在线上出现启动劣化以及启动劣化原因。
10.在一种可能的设计中，按照预设策略，对相同堆栈集合所对应的耗时函数进行优化处理，包括：按照相同堆栈集合包括的堆栈的数量从多到少的顺序，先对包括堆栈数量多的相同堆栈集合所对应的耗时函数进行优化处理，再对包括堆栈数量少的相同堆栈集合所对应的耗时函数进行优化处理。
11.在一种可能的设计中，该方法还包括：接收不同用户的堆栈集合中的堆栈所对应的耗时函数的自身耗时时长。
12.在一种可能的设计中，按照预设策略，对相同堆栈集合所对应的耗时函数进行优化处理，包括：按照耗时函数的平均自身耗时时长从大到小的顺序，先对相同堆栈集合所对应的平均自身耗时时长大的耗时函数进行优化处理，再对相同堆栈集合所对应的平均自身耗时时长小的耗时函数进行优化处理，每个耗时函数的平均自身耗时时长为耗时函数对应的相同堆栈集合包括的全部堆栈各自耗时函数的自身耗时时长之和与全部堆栈的数量的比值。
13.在一种可能的设计中，按照预设策略，对相同堆栈集合所对应的耗时函数进行优化处理，包括：按照相同堆栈集合对应的耗时函数的总自身耗时时长从大到小的顺序，先对相同堆栈集合中总自身耗时时长大的堆栈所对应的耗时函数进行优化处理，再对相同堆栈集合中总自身耗时时长小的堆栈所对应的耗时函数进行优化处理，每个相同堆栈集合对应的耗时函数的总自身耗时时长为相同堆栈集合包括的全部堆栈各自的耗时函数的自身耗时时长之和。
14.第二方面，本公开提供了一种应用程序线上启动的监控方法，包括：
15.确定应用程序的启动阶段中的全部耗时函数，耗时函数为启动阶段中的自身耗时时长大于等于预设阈值的函数；
16.基于全部耗时函数中的每个耗时函数的函数调用关系，获取每个耗时函数的堆栈，并将全部耗时函数的堆栈作为堆栈集合；
17.向服务器发送堆栈集合，以使服务器对不同用户的堆栈集合中的相同耗时函数的堆栈进行聚合，得到相同堆栈集合，并确定相同堆栈集合所对应的耗时函数；并按照预设策略，对相同堆栈集合所对应的耗时函数进行优化处理。
18.通过第二方面提供的方法，服务器可从不同客户端接收到应用程序的一个版本中的不同用户的堆栈集合，每个用户的堆栈集合中包括全部耗时函数的堆栈，每个耗时函数的堆栈是基于耗时函数的函数调用关系得到的，耗时函数为应用程序的一个版本的启动阶段中的自身耗时时长大于等于预设阈值的函数。服务器便可对不同用户上报的不同耗时函数的堆栈中的相同耗时函数的堆栈进行聚合，得到相同堆栈集合，并按照预设策略所对应的处理顺序，对相同堆栈集合对应的耗时函数进行优化处理。从而，全面监控应用程序线上启动的函数，分析出应用程序线上启动的耗时函数，实现了自动化的耗时数据监控，指导了耗时函数的优化处理方式，有助于全面了解函数在应用程序运行在线上时的耗时和分布情况，提高了应用程序的监控效率，提升了用户使用应用程序的体验感。
19.在一种可能的设计中，确定应用程序的启动阶段中的全部耗时函数，包括：在应用
程序的运行期间，基于在应用程序的编译过程对应用程序的启动阶段中的全部函数的插桩结果，获取全部函数在启动阶段中各自的自身耗时时长；确定全部函数中的耗时函数为自身耗时时长大于等于预设阈值的函数。
20.在一种可能的设计中，基于在应用程序的编译过程对应用程序的启动阶段中的全部函数的插桩结果，获取全部函数在启动阶段中各自的自身耗时时长，包括：基于在应用程序的编译过程对应用程序的第一版本的启动阶段中的全部函数的插桩结果，分别得到全部函数的总执行耗时；基于函数调用关系，获取全部函数在启动阶段中各自的自身耗时时长。
21.在一种可能的设计中，该方法还包括：向服务器发送堆栈集合中的堆栈所对应的耗时函数的自身耗时时长，以使服务器基于耗时函数的自身耗时时长，按照预设策略，对相同堆栈集合所对应的耗时函数进行优化处理。
22.第三方面，本公开提供了一种应用程序线上启动的监控装置，包括：
23.接收模块，用于接收应用程序的第一版本中的不同用户的堆栈集合，每个用户的堆栈集合中包括应用程序的第一版本的启动阶段中的全部耗时函数的堆栈，每个耗时函数的堆栈是基于耗时函数的函数调用关系得到的，耗时函数为启动阶段中的自身耗时时长大于等于预设阈值的函数；
24.第一确定模块，用于对不同用户的堆栈集合中的相同耗时函数的堆栈进行聚合，得到相同堆栈集合，并确定相同堆栈集合所对应的耗时函数；
25.处理模块，用于按照预设策略，对相同堆栈集合所对应的耗时函数进行优化处理。
26.在一种可能的设计中，接收模块，还用于接收应用程序的第二版本中的不同用户的堆栈集合，其中，应用程序的第二版本中的不同用户与应用程序的第一版本中的不同用户的设备分布一致；
27.处理模块，还用于从应用程序的第一版本中的不同用户的堆栈集合以及应用程序的第二版本中的不同用户的堆栈集合中，获取相同用户数量的堆栈集合；
28.处理模块，还用于基于相同用户数量的堆栈集合，对应用程序的第二版本和应用程序的第一版本进行比较，得到比较结果；
29.处理模块，还用于基于比较结果，对应用程序的第一版本的线上启动进行监控。
30.在一种可能的设计中，处理模块，具体用于按照相同堆栈集合包括的堆栈的数量从多到少的顺序，先对包括堆栈数量多的相同堆栈集合所对应的耗时函数进行优化处理，再对包括堆栈数量少的相同堆栈集合所对应的耗时函数进行优化处理。
31.在一种可能的设计中，接收模块，还用于接收不同用户的堆栈集合中的堆栈所对应的耗时函数的自身耗时时长。
32.在一种可能的设计中，处理模块，具体用于按照耗时函数的平均自身耗时时长从大到小的顺序，先对相同堆栈集合所对应的平均自身耗时时长大的耗时函数进行优化处理，再对相同堆栈集合所对应的平均自身耗时时长小的耗时函数进行优化处理，每个耗时函数的平均自身耗时时长为耗时函数对应的相同堆栈集合包括的全部堆栈各自耗时函数的自身耗时时长之和与全部堆栈的数量的比值。
33.在一种可能的设计中，处理模块，具体用于按照相同堆栈集合对应的耗时函数的总自身耗时时长从大到小的顺序，先对相同堆栈集合中总自身耗时时长大的堆栈所对应的耗时函数进行优化处理，再对相同堆栈集合中总自身耗时时长小的堆栈所对应的耗时函数
进行优化处理，每个相同堆栈集合对应的耗时函数的总自身耗时时长为相同堆栈集合包括的全部堆栈各自的耗时函数的自身耗时时长之和。
34.上述第三方面以及上述第三方面的各可能的设计中所提供的应用程序线上启动的监控装置，其有益效果可以参见上述第一方面和第一方面的各可能的实施方式所带来的有益效果，在此不再赘述。
35.第四方面，本公开提供了一种应用程序线上启动的监控装置，包括：
36.第二确定模块，用于确定应用程序的启动阶段中的全部耗时函数，耗时函数为启动阶段中的自身耗时时长大于等于预设阈值的函数；
37.获取模块，用于基于全部耗时函数中的每个耗时函数的函数调用关系，获取每个耗时函数的堆栈，并将全部耗时函数的堆栈作为堆栈集合；
38.发送模块，用于向服务器发送堆栈集合，以使服务器对不同用户的堆栈集合中的相同耗时函数的堆栈进行聚合，得到相同堆栈集合，并确定相同堆栈集合所对应的耗时函数；并按照预设策略，对相同堆栈集合所对应的耗时函数进行优化处理。
39.在一种可能的设计中，第二确定模块，具体用于在应用程序的运行期间，基于在应用程序的编译过程对应用程序的启动阶段中的全部函数的插桩结果，获取全部函数在启动阶段中各自的自身耗时时长；确定全部函数中的耗时函数为自身耗时时长大于等于预设阈值的函数。
40.在一种可能的设计中，第二确定模块，具体用于基于在应用程序的编译过程对应用程序的第一版本的启动阶段中的全部函数的插桩结果，分别得到全部函数的总执行耗时；基于函数调用关系，获取全部函数在启动阶段中各自的自身耗时时长。
41.在一种可能的设计中，发送模块，还用于向服务器发送堆栈集合中的堆栈所对应的耗时函数的自身耗时时长，以使服务器基于耗时函数的自身耗时时长，按照预设策略，对相同堆栈集合所对应的耗时函数进行优化处理。
42.上述第四方面以及上述第四方面的各可能的设计中所提供的应用程序线上启动的监控装置，其有益效果可以参见上述第二方面和第二方面的各可能的实施方式所带来的有益效果，在此不再赘述。
43.第五方面，本公开提供了一种服务器，包括：存储器和处理器；存储器用于存储程序指令；处理器用于调用存储器中的程序指令使得服务器执行第一方面及第一方面任一种可能的设计中的应用程序线上启动的监控方法。
44.第六方面，本公开提供了一种客户端，包括：存储器和处理器；存储器用于存储程序指令；处理器用于调用存储器中的程序指令使得客户端执行第二方面及第二方面任一种可能的设计中的应用程序线上启动的监控方法。
45.第七方面，本公开提供了一种计算机存储介质，包括计算机指令，当计算机指令在电子设备上运行时，使得电子设备执行第一方面及第一方面任一种可能的设计中的应用程序线上启动的监控方法，或者，使得电子设备执行第二方面及第二方面任一种可能的设计中的应用程序线上启动的监控方法。
46.第八方面，本公开提供了一种计算机程序产品，当计算机程序产品在计算机上运行时，使得计算机执行第一方面及第一方面任一种可能的设计中的应用程序线上启动的监控方法，或者，使得计算机执行第一方面及第二方面任二种可能的设计中的应用程序线上
启动的监控方法。
47.第九方面，本公开提供了一种芯片系统，芯片系统包括：处理器；当处理器执行存储器中存储的计算机指令时，电子设备执行第一方面及第一方面任一种可能的设计中的应用程序线上启动的监控方法，或者，电子设备执行第二方面及第二方面任一种可能的设计中的应用程序线上启动的监控方法。
附图说明
48.此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。
49.为了更清楚地说明本公开实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，对于本领域普通技术人员而言，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
50.图1为本公开实施例提供的通信系统的示意图；
51.图2为本公开实施例提供的应用程序线上启动的监控方法的信令交互示意图；
52.图3为本公开实施例提供的应用程序线上启动的监控方法的流程示意图；
53.图4为本公开实施例提供的应用程序线上启动的监控方法的流程示意图；
54.图5为本公开实施例提供的一个调用树的示意图；
55.图6为本公开实施例提供的一个调用树的示意图；
56.图7为本公开实施例提供的应用程序线上启动的监控装置的结构示意图；
57.图8为本公开实施例提供的应用程序线上启动的监控装置的结构示意图。
具体实施方式
58.为了能够更清楚地理解本公开的上述目的、特征和优点，下面将对本公开的方案进行进一步描述。需要说明的是，在不冲突的情况下，本公开的实施例及实施例中的特征可以相互组合。
59.在下面的描述中阐述了很多具体细节以便于充分理解本公开，但本公开还可以采用其他不同于在此描述的方式来实施；显然，说明书中的实施例只是本公开的一部分实施例，而不是全部的实施例。
60.示例性地，本公开提供一种应用程序线上启动的监控方法、装置、服务器、客户端、计算机存储介质以及计算机程序产品，可在应用程序运行在线上时，分析应用程序的启动阶段中的全部函数的自身耗时时长(self time)，将自身耗时时长大于等于预设阈值的函数确定为耗时函数，来基于每个耗时函数的函数调用关系获取耗时函数的堆栈，将一个耗时函数的堆栈作为一个耗时问题来看待，以便对不同用户上报的不同耗时函数的堆栈中的相同耗时函数的堆栈进行聚合，得到相同堆栈集合，并按照预设策略所对应的处理顺序，对相同堆栈集合对应的耗时函数进行优化处理。从而，全面监控应用程序线上启动的函数，分析出应用程序线上启动的耗时函数，实现了自动化的耗时数据监控，指导了耗时函数的优化处理方式，有助于全面了解函数在应用程序运行在线上时的耗时和分布情况，提高了应用程序的监控效率，提升了用户使用应用程序的体验感。
61.另外，基于应用程序的不同版本中出现的耗时函数的比对，可快速且准确定位出
应用程序的新版本是否出现启动劣化以及启动劣化原因。
62.请参阅图1，图1为本公开实施例提供的通信系统的示意图。如图1所示，本公开的通信系统可以包括：服务器和多个客户端，服务器与每个客户端可实现通信连接。
63.其中，客户端可通过终端设备中的应用程序(application，app)实现本公开的应用程序线上启动的监控方法，终端设备可以是手机(如折叠屏手机、智能手机等)、个人数字助理(personal digital assistant，pda)、平板电脑、笔记本电脑、超级移动个人计算机(ultra-mobile personal computer，umpc)、上网本等设备，本公开对终端设备的具体类型不作任何限制。
64.基于前述描述，本公开以实施例将以图1中的服务器和客户端为例，结合附图和应用场景，对本公开提供的应用程序线上启动的监控方法进行详细阐述。
65.请参阅图2，图2为本公开实施例提供的应用程序线上启动的监控方法的信令交互示意图。如图2所示，本公开提供的应用程序线上启动的监控方法可以包括：
66.s101、客户端确定应用程序的第一版本的启动阶段中的全部耗时函数，耗时函数为启动阶段中的自身耗时时长大于等于预设阈值的函数。
67.在应用程序的第一版本的启动阶段中，客户端可将自身耗时时长大于等于预设阈值的函数确定为耗时函数。从而，客户端可确定出应用程序的第一版本的启动阶段中的全部耗时函数。其中，应用程序的第一版本为应用程序的一个版本。
68.其中，本公开提及的启动阶段为应用程序从开始启动到显示预设初始页面的时间段。具体地，启动阶段可以为应用程序从开始启动到显示主页面之间的时间段，或者，应用程序从开始启动到显示第一个页面(如引流页面)之间的时间段。另外，启动阶段也可以理解为应用程序执行主进程和主线程的阶段，对应地，主进程和主线程用于实现应用程序从开始启动到显示主页面，或者，主进程和主线程用于实现应用程序从开始启动到显示第一个页面。
69.其中，本公开提及的自身耗时时长可以理解为一个函数执行自身代码所消耗的时长，并不包括该函数直接和间接调用的函数所消耗的时长。由此，能够更加精确的定位耗时函数，减少函数优化的工作量。例如，函数a的总耗时是105ms，函数a调用了b，函数b的耗时是100ms。如果客户端将函数a和函数b作为耗时函数上报，则会造成不需要进行优化的函数a作为耗时函数进行了统计，从而增加了后续工作量。并且，本公开对预设阈值的大小不做限定。
70.s102、客户端基于全部耗时函数中的每个耗时函数的函数调用关系，获取每个耗时函数的堆栈，并将全部耗时函数的堆栈作为堆栈集合。
71.客户端基于一个耗时函数的函数调用关系，可采集一个耗时函数的堆栈(也可称为执行堆栈)。其中，耗时函数不同，耗时函数对应的堆栈不同。并且，耗时函数的堆栈中，耗时函数通常为栈顶。
72.例如，如图5所示，假设函数fun调用函数fun2，函数fun2调用函数fun21。那么，函数fun21的堆栈为fun-》fun2-》fun21，函数fun、函数fun2和函数fun21依次进入到该堆栈中，函数fun为该堆栈的栈底，fun21为该堆栈的栈顶。函数fun2的堆栈为fun-》fun2，函数fun和函数fun2依次进入到该堆栈中，函数fun为该堆栈的栈底，函数fun2为该堆栈的栈顶。并且，这是两个不同的堆栈。
73.从而，客户端可获取到全部耗时函数的堆栈。
74.s103、客户端向服务器发送一个堆栈集合，堆栈集合中包括全部耗时函数的堆栈。
75.基于步骤s102的描述，客户端可将每个堆栈看成是一个耗时问题上报给服务器。从而，客户端可将全部耗时函数的堆栈生成一个堆栈集合，并将该堆栈集合发送给服务器，使得服务器可基于该堆栈集合获知该客户端的耗时问题。
76.s104、服务器对不同用户的堆栈集合中的相同耗时函数的堆栈进行聚合，得到相同堆栈集合，并确定相同堆栈集合所对应的耗时函数。
77.基于步骤s103的描述，服务器可从每个客户端接收到该客户端上报的一个用户的堆栈集合，以便服务器可接收到不同用户的堆栈集合。从而，服务器可对不同用户的堆栈集合中的相同耗时函数的堆栈进行聚合，得到相同堆栈集合，并确定出相同堆栈集合对应的耗时函数，以便将相同堆栈集合对应的耗时函数作为一个耗时问题来看待。
78.另外，服务器还可显示相同堆栈集合对应的耗时函数，以便向开发人员直观展示应用程序中的耗时函数，使得应用程序中的耗时函数所带来的耗时问题能够及时得到解决。
79.s105、服务器按照预设策略，对相同堆栈集合所对应的耗时函数进行优化处理。
80.服务器按照预设策略所对应的处理顺序，可对相同堆栈集合所对应的耗时函数进行优化处理。
81.其中，预设策略用于确定耗时函数的优化处理顺序。并且，除了客户端向服务器上报堆栈集合之外，客户端还可将堆栈集合中的堆栈所对应的耗时函数的自身耗时时长发送给服务器。
82.其中，本公开对预设策略的具体实现方式不做限定。
83.在一些实施例中，预设策略为基于堆栈次数来确定耗时函数的优化处理顺序。
84.服务器可按照相同堆栈集合包括的堆栈的数量从多到少的顺序，先对包括堆栈数量多的相同堆栈集合所对应的耗时函数进行优化处理，再包括堆栈数量多的相同堆栈集合所对应的耗时函数进行优化处理。
85.在另一些实施例中，预设策略为基于耗时函数的平均自身耗时时长来确定耗时函数的优化处理顺序。其中，每个耗时函数的平均自身耗时时长为耗时函数对应的相同堆栈集合包括的全部堆栈各自耗时函数的自身耗时时长之和与全部堆栈的数量的比值。
86.服务器可按照耗时函数的平均自身耗时时长从大到小的顺序，先对相同堆栈集合所对应的平均自身耗时时长大的耗时函数进行优化处理，再对相同堆栈集合所对应的平均自身耗时时长小的耗时函数进行优化处理。
87.例如，假设两个用户a和用户b。用户a的耗时函数包括：函数fun1(70ms)、函数fun11(60ms)、函数fun12(70ms)、函数fun21(100ms)、函数fun3(60ms)。用户b的耗时函数包括：函数fun1(60ms)、函数fun11(80ms)、函数fun12(90ms)、函数fun21(70ms)、函数fun3(70ms)。
88.那么，上述耗时函数的平均自身耗时时长分别为：函数fun1(65ms)、函数fun11(70ms)、函数fun12(80ms)、函数fun21(85ms)、函数fun3(65ms)。服务器对上述函数的平均自身耗时时长进行排序，顺序为函数fun21》函数fun12》函数fun11》函数fun1＝函数fun3。故，服务器可先优化处理函数fun21的耗时问题，以便用户能够快速启动应用程序。
89.在另一些实施例中，预设策略为基于相同堆栈集合对应的耗时函数的总自身耗时时长来确定耗时函数的优化处理顺序。其中，每个相同堆栈集合对应的耗时函数的总自身耗时时长的计算方式可以为：一个相同堆栈集合包括的全部堆栈堆栈各自的耗时函数的平均自身耗时时长与全部堆栈的数量的乘积，或者，相同堆栈集合包括的全部堆栈各自的耗时函数的自身耗时时长之和。
90.服务器可按照相同堆栈集合对应的耗时函数的总自身耗时时长从大到小的顺序，先对相同堆栈集合中总自身耗时时长大的堆栈所对应的耗时函数进行优化处理，再对相同堆栈集合中总自身耗时时长小的堆栈所对应的耗时函数进行优化处理。
91.需要说明的是，本公开不限于上述提及的预设策略的实现方式。
92.本公开提供的应用程序线上启动的监控方法，通过客户端确定应用程序的一个版本的启动阶段中的自身耗时时长大于等于预设阈值的全部耗时函数，并基于每个耗时函数的函数调用关系获取全部耗时函数的堆栈。客户端向服务器发送包括全部耗时函数的堆栈的一个堆栈集合，使得服务器可从不同客户端接收到应用程序的一个版本中的不同用户的堆栈集合。服务器便可对不同用户上报的不同耗时函数的堆栈中的相同耗时函数的堆栈进行聚合，得到相同堆栈集合，并按照预设策略所对应的处理顺序，对相同堆栈集合对应的耗时函数进行优化处理。从而，全面监控应用程序线上启动的函数，分析出应用程序线上启动的耗时函数，实现了自动化的耗时数据监控，指导了耗时函数的优化处理方式，有助于全面了解函数在应用程序运行在线上时的耗时和分布情况，提高了应用程序的监控效率，提升了用户使用应用程序的体验感。
93.基于上述实施例的描述，服务器还可监测应用程序的不同版本中出现的耗时函数，通过比对应用程序的不同版本中出现的耗时函数的种类是否有新增、耗时函数的平均自身耗时时长是否发生变化、耗时函数对应的堆栈的次数是否有发生变化等问题，来快速定位出应用程序的新版本是否出现启动劣化以及启动劣化原因。
94.请参阅图3，图3为本公开实施例提供的应用程序线上启动的监控方法的流程示意图。如图3所示，本公开提供的应用程序线上启动的监控方法可以包括：
95.s201、服务器接收应用程序的第二版本中的不同用户的堆栈集合，其中，应用程序的第二版本中的不同用户与应用程序的第一版本中的不同用户的设备分布一致。
96.基于图2实施例中的步骤s101-s103的描述，每个客户端可获取到应用程序的第二版本中的一个用户的堆栈集合。其中，使用应用程序的第一版本的设备与使用应用程序的第二版本的设备的分布一致，避免由于设备的软件和硬件等性能的不同而导致应用程序的版本的差异。例如，应用程序的第一版本中的不同用户与应用程序的第二版本中的不同用户使用的设备为相同类型的设备。
97.从而，服务器可从不同客户端接收到应用程序的第二版本中的不同用户的堆栈集合。其中，应用程序的第一版本与应用程序的第二版本不同，且应用程序的第二版本为应用程序的一个版本。
98.s202、服务器从应用程序的第一版本中的不同用户的堆栈集合以及应用程序的第二版本中的不同用户的堆栈集合中，获取相同用户数量的堆栈集合。
99.服务器基于应用程序的第一版本中的不同用户的堆栈集合以及应用程序的第二版本中的不同用户的堆栈集合，可对应用程序的两个版本进行比对。
100.从而，服务器可获取相同用户数量的堆栈集合，避免了由于用户群体的差异而导致的耗时函数的计算差异。
101.s203、服务器基于相同数量的堆栈集合，对应用程序的第二版本和应用程序的第一版本进行比较，得到比较结果。
102.s204、服务器基于比较结果，对应用程序的第一版本的线上启动进行监控。
103.服务器基于两个版本中相同用户数量的堆栈集合，可确定应用程序的一个版本中是否存在：耗时函数的种类是否有新增、耗时函数的平均自身耗时时长是否发生变化、耗时函数对应的堆栈的次数是否有发生变化等问题。从而，服务器能够快速定位出应用程序的新版本是否出现启动劣化以及启动劣化原因。由此，服务器可实现应用程序的一个版本的线上启动的监控。
104.例如，耗时函数fun21的平均自身耗时时长变大，则服务器可确定应用程序的新版本中的耗时函数fun21对应的代码出现问题。
105.基于上述实施例的描述，客户端可采用多种方式可确定应用程序的一个版本中的全部耗时函数。
106.请参阅图4，图4为本公开实施例提供的应用程序线上启动的监控方法的流程示意图。如图4所示，本公开提供的应用程序线上启动的监控方法可以包括：
107.s301、客户端在应用程序的运行期间，基于在应用程序的编译过程对应用程序的启动阶段中的全部函数的插桩结果，获取全部函数在启动阶段中各自的自身耗时时长。
108.基于步骤s101的描述，使得服务器能够获取到全部函数的自身耗时时长。在应用程序的编译期间，客户端可对应用程序的一个版本的启动阶段中的全部函数进行插桩处理。
109.其中，本公开对插桩处理的具体实现方式不做限定。在一些实施例中，在应用程序的编译期间，对启动阶段中的全部函数的“出口”和“入口”插入“桩函数”。
110.另外，本公开还可启动阶段的起始函数和终止函数进行配置。起始函数用于启动阶段的启动，终止函数用于启动阶段的终止。本公开对启动阶段、起始函数和终止函数的具体实现方法不做限定。
111.从而，客户端在应用程序的运行期间，基于插桩处理，可获取全部函数在启动阶段中各自的自身耗时时长。
112.如果一个函数在启动阶段中被调用，则“桩函数”便可记录下来该函数。在启动阶段截止后，“桩函数”便停止记录，即终止函数首次执行后，便停止收集启动阶段中被调用的函数。在一个函数没有调用其他函数时，“桩函数”记录的起始时刻与终止时刻之间的时间差(即执行时长)为该函数的自身耗时时长。在一个函数有调用其他函数时，“桩函数”记录的起始时刻与终止时刻之间的时间差(即执行时长)，采用该时间差再减去全部调用函数的自身耗时时长便为该函数的自身耗时时长。
113.s302、客户端确定全部函数中的耗时函数为自身耗时时长大于等于预设阈值的函数。
114.基于步骤s301的描述客户端可确定全部函数的自身耗时时长。在一个函数的自身耗时时长大于等于预设阈值时，客户端可确定该函数为耗时函数。从而，客户端可确定全部函数中的全部耗时函数。
115.图5中的调用树中，假设fun函数是应用程序的启动阶段中的一个主线程的根函数，函数fun调用了函数fun1、函数fun2和函数fun3，函数fun1调用了函数fun11和函数fun12，函数fun2调用了函数fun21，函数fun3未调用函数。且，函数fun的执行时长为410ms，函数fun1的执行时长为200ms，函数fun11的执行时长为60ms，函数fun12的执行时长为70ms，函数fun2的执行时长为140ms，函数fun21的执行时长为100ms，函数fun3的执行时长为6ms。
116.基于上述内容，服务器可计算出每个函数的自身耗时时长。图6中的调用树中，函数fun的自身耗时时长为10ms，函数fun1的自身耗时时长为70ms，函数fun11的自身耗时时长为60ms，函数fun12的自身耗时时长为70ms，函数fun2的自身耗时时长为40ms，函数fun21的自身耗时时长为100ms，函数fun3的自身耗时时长为6ms。
117.从而，服务器可将上述函数的自身耗时时长超过预设阈值的函数确定为耗时函数，则在预设阈值设为50ms时，全部耗时函数可以包括：函数fun1(70ms)、函数fun11(60ms)、函数fun12(70ms)、函数fun21(100ms)和函数fun3(60ms)。
118.其中，插桩结果可以包括全部函数的总执行耗时。从而，客户端基于在应用程序的编译过程对应用程序的第一版本的启动阶段中的全部函数的插桩结果，可分别得到全部函数的总执行耗时。客户端基于函数调用关系，可获取全部函数在启动阶段中各自的自身耗时时长。
119.需要说明的是，除了客户端向服务器上报堆栈集合和堆栈集合中的堆栈所对应的耗时函数的自身耗时时长之外，客户端还可将堆栈集合中的堆栈所对应的耗时函数的执行时长发送给服务器，以便服务器备份耗时函数的执行时长和自身耗时时长，方便后续操作。
120.另外，客户端可将应用程序的一个版本的启动阶段中的全部函数的执行时长发送给服务器，使得服务器基于预设阈值来确定耗时函数以及确定耗时函数的堆栈，以便优化耗时函数以及定位劣化情况。
121.示例性地，本公开提供一种应用程序线上启动的监控装置。
122.请参阅图7，图7为本公开实施例提供的应用程序线上启动的监控装置的结构示意图。本公开的应用程序线上启动的监控装置可设置在服务器中，可实现上述图1-图6实施例的应用程序线上启动的监控方法对应于服务器的操作。如图7所示，本公开提供的应用程序线上启动的监控装置100可以包括：接收模块101、第一确定模块102和处理模块103。
123.接收模块101，用于接收应用程序的第一版本中的不同用户的堆栈集合，每个用户的堆栈集合中包括应用程序的第一版本的启动阶段中的全部耗时函数的堆栈，每个耗时函数的堆栈是基于耗时函数的函数调用关系得到的，耗时函数为启动阶段中的自身耗时时长大于等于预设阈值的函数；
124.第一确定模块102，用于对不同用户的堆栈集合中的相同耗时函数的堆栈进行聚合，得到相同堆栈集合，并确定相同堆栈集合所对应的耗时函数；
125.处理模块103，用于按照预设策略，对相同堆栈集合所对应的耗时函数进行优化处理。
126.在一些实施例中，接收模块101，还用于接收应用程序的第二版本中的不同用户的堆栈集合，其中，应用程序的第二版本中的不同用户与应用程序的第一版本中的不同用户的设备分布一致；
127.处理模块103，还用于从应用程序的第一版本中的不同用户的堆栈集合以及应用程序的第二版本中的不同用户的堆栈集合中，获取相同用户数量的堆栈集合；
128.处理模块103，还用于基于相同用户数量的堆栈集合，对应用程序的第二版本和应用程序的第一版本进行比较，得到比较结果。
129.处理模块103，还用于基于比较结果，对应用程序的第一版本的线上启动进行监控。
130.在一些实施例中，处理模块103，具体用于按照相同堆栈集合包括的堆栈的数量从多到少的顺序，先对包括堆栈数量多的相同堆栈集合所对应的耗时函数进行优化处理，再对包括堆栈数量少的相同堆栈集合所对应的耗时函数进行优化处理。
131.在一些实施例中，接收模块101，还用于接收不同用户的堆栈集合中的堆栈所对应的耗时函数的自身耗时时长。
132.在一些实施例中，处理模块103，具体用于按照耗时函数的平均自身耗时时长从大到小的顺序，先对相同堆栈集合所对应的平均自身耗时时长大的耗时函数进行优化处理，再对相同堆栈集合所对应的平均自身耗时时长小的耗时函数进行优化处理，每个耗时函数的平均自身耗时时长为耗时函数对应的相同堆栈集合包括的全部堆栈各自耗时函数的自身耗时时长之和与全部堆栈的数量的比值。
133.在一些实施例中，处理模块103，具体用于按照相同堆栈集合对应的耗时函数的总自身耗时时长从大到小的顺序，先对相同堆栈集合中总自身耗时时长大的堆栈所对应的耗时函数进行优化处理，再对相同堆栈集合中总自身耗时时长小的堆栈所对应的耗时函数进行优化处理，每个相同堆栈集合对应的耗时函数的总自身耗时时长为相同堆栈集合包括的全部堆栈各自的耗时函数的自身耗时时长之和。
134.本公开提供的应用程序线上启动的监控装置，可执行上述方法实施例，其具体实现原理和技术效果，可参见上述方法实施例，本公开此处不再赘述。
135.示例性地，本公开提供一种应用程序线上启动的监控装置。
136.请参阅图8，图8为本公开实施例提供的应用程序线上启动的监控装置的结构示意图。本公开的应用程序线上启动的监控装置可设置在客户端中，可实现上述图1-图6实施例的应用程序线上启动的监控方法对应于客户端的操作。如图8所示，本公开提供的应用程序线上启动的监控装置200可以包括：第二确定模块201、获取模块202和发送模块203。
137.第二确定模块201，用于确定应用程序的启动阶段中的全部耗时函数，耗时函数为启动阶段中的自身耗时时长大于等于预设阈值的函数；
138.获取模块202，用于基于全部耗时函数中的每个耗时函数的函数调用关系，获取每个耗时函数的堆栈，并将全部耗时函数的堆栈作为堆栈集合；
139.发送模块203，用于向服务器发送堆栈集合，以使服务器对不同用户的堆栈集合中的相同耗时函数的堆栈进行聚合，得到相同堆栈集合，并确定相同堆栈集合所对应的耗时函数；并按照预设策略，对相同堆栈集合所对应的耗时函数进行优化处理。
140.在一些实施例中，第二确定模块201，具体用于在应用程序的运行期间，基于在应用程序的编译过程对应用程序的启动阶段中的全部函数的插桩结果，获取全部函数在启动阶段中各自的自身耗时时长；确定全部函数中的耗时函数为自身耗时时长大于等于预设阈值的函数。
141.在一些实施例中，第二确定模块201，具体用于基于在应用程序的编译过程对应用程序的第一版本的启动阶段中的全部函数的插桩结果，分别得到全部函数的总执行耗时；基于函数调用关系，获取全部函数在启动阶段中各自的自身耗时时长。
142.在一些实施例中，发送模块203，还用于向服务器发送堆栈集合中的堆栈所对应的耗时函数的自身耗时时长，以使服务器基于耗时函数的自身耗时时长，按照预设策略，对相同堆栈集合所对应的耗时函数进行优化处理。
143.本公开提供的应用程序线上启动的监控装置，可执行上述方法实施例，其具体实现原理和技术效果，可参见上述方法实施例，本公开此处不再赘述。
144.示例性地，本公开提供一种服务器，包括：一个或多个处理器；存储器；以及一个或多个计算机程序；其中一个或多个计算机程序被存储在存储器中；一个或多个处理器在执行一个或多个计算机程序时，使得服务器实现前文实施例的应用程序线上启动的监控方法。
145.示例性地，本公开提供一种客户端，包括：一个或多个处理器；存储器；以及一个或多个计算机程序；其中一个或多个计算机程序被存储在存储器中；一个或多个处理器在执行一个或多个计算机程序时，使得客户端实现前文实施例的应用程序线上启动的监控方法。
146.示例性地，本公开提供一种芯片系统，芯片系统应用于包括存储器和传感器的电子设备；芯片系统包括：处理器；当处理器执行前文实施例的应用程序线上启动的监控方法。
147.示例性地，本公开提供一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器使得电子设备执行时实现前文实施例的应用程序线上启动的监控方法。
148.示例性地，本公开提供一种计算机程序产品，当计算机程序产品在计算机上运行时，使得计算机执行前文实施例的应用程序线上启动的监控方法。
149.在上述实施例中，全部或部分功能可以通过软件、硬件、或者软件加硬件的组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行计算机程序指令时，全部或部分地产生按照本公开实施例的流程或功能。计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。计算机指令可以存储在计算机可读存储介质中。计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，dvd)、或者半导体介质(例如，固态硬盘(solid state disk，ssd))等。
150.需要说明的是，在本文中，诸如“第一”和“第二”等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括要素的过程、方法、物品或者设备中还存在另外的相同要素。
151.以上仅是本公开的具体实施方式，使本领域技术人员能够理解或实现本公开。对
这些实施例的多种修改对本领域的技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本公开的精神或范围的情况下，在其它实施例中实现。因此，本公开将不会被限制于本文的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。