CN112650959A - 页面加载时长的统计方法、装置、设备及存储介质 - Google Patents

Abstract

本申请提供了一种页面加载时长的统计方法、装置、设备及存储介质；所述方法包括：基于接收到的加载页面的操作指令，利用运行时机制对业务类实例进行键值监听；当监听到页面初始化事件时，获取所述页面初始化事件的第一起始时间；当监听到页面可见事件时，获取所述页面可见事件的第一结束时间；基于所述第一起始时间和所述第一结束时间，确定页面加载时长。通过本申请，能够高效且准确地统计出页面加载时长。

Description

页面加载时长的统计方法、装置、设备及存储介质

技术领域

本申请涉及互联网技术领域，尤其涉及一种页面加载时长的统计方法、装置、设备及存储介质。

背景技术

随着互联网技术以及智能终端的发展，人们的娱乐方式已经有了翻天覆地的变化。人们可以随时随地地利用智能终端查看新闻、观看视频、听音乐、玩网络游戏等。不管是通过浏览器去查看新闻、观看视频、还是通过专属的应用去玩游戏、购物等，页面加载时长都是用户体验极其重要的一项指标，因此统计页面加载时长成为开发者改善应用的性能指标的一项重要任务。

目前统计页面加载时长的方法主要包括基于运行时调配(runtime swizzling)的统计方案、截图分析纯色占比方案等，现有的统计方案或者实现复杂、效率低，亦或者统计准确度不高。

发明内容

本申请实施例提供一种页面加载时长的统计方法、装置及存储介质，能够高效且准确地统计出页面加载时长。

本申请实施例的技术方案是这样实现的：

本申请实施例提供一种页面加载时长的统计方法，包括：

基于接收到的加载页面的操作指令，利用运行时机制对业务类实例进行键值监听；

当监听到页面初始化事件时，获取所述页面初始化事件的第一起始时间；

当监听到页面可见事件时，获取所述页面可见事件的第一结束时间；

基于所述第一起始时间和所述第一结束时间，确定页面加载时长。

本申请实施例提供一种页面加载时长的统计装置，包括：

监听模块，基于接收到的加载页面的操作指令，利用运行时机制对业务类实例进行键值监听；

第一获取模块，用于当监听到页面初始化事件时，获取所述页面初始化事件的第一起始时间；

第二获取模块，用于当监听到页面可见事件时，获取所述页面可见事件的第一结束时间；

第一确定模块，用于基于所述第一起始时间和所述第一结束时间，确定页面加载时长。

本申请实施例提供一种页面加载时长的统计设备，包括：

存储器，用于存储可执行指令；

处理器，用于执行所述存储器中存储的可执行指令时，实现本申请实施例提供的方法。

本申请实施例提供一种存储介质，存储有可执行指令，用于引起处理器执行时，实现本申请实施例提供的方法。

本申请实施例具有以下有益效果：

在本申请实施例提供的页面加载时长的统计方法中，在接收到加载页面的操作指令时，利用运行时(runtime)机制，对业务类实例进行键值监听，以监听页面初始化和页面可见事件，并且分别记录页面初始化时间的开始时间和页面可见事件的结束时间，从而能够精确且高效的统计出页面加载时长。

附图说明

图1为本申请实施例页面加载时长的统计方法的网络架构示意图；

图2是本申请实施例提供的用户终端100的组成结构示意图；

图3为本申请实施例提供的页面加载时长的统计方法的一种实现流程示意图；

图4为本申请实施例提供确定方法执行时间的实现流程示意图；

图5为本申请实施例提供的页面加载时长的统计方法的另一种实现流程示意图；

图6为本申请实施例利用KVO监听业务类实例的示意图；

图7为本申请实施例重写父类方法的示意图；

图8为本申请实施例主线程堆栈信息的示意图。

具体实施方式

为了使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请作进一步地详细描述，所描述的实施例不应视为对本申请的限制，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本申请保护的范围。

在以下的描述中，涉及到“一些实施例”，其描述了所有可能实施例的子集，但是可以理解，“一些实施例”可以是所有可能实施例的相同子集或不同子集，并且可以在不冲突的情况下相互结合。

在以下的描述中，所涉及的术语“第一\第二\第三”仅仅是是区别类似的对象，不代表针对对象的特定排序，可以理解地，“第一\第二\第三”在允许的情况下可以互换特定的顺序或先后次序，以使这里描述的本申请实施例能够以除了在这里图示或描述的以外的顺序实施。

除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述本申请实施例的目的，不是旨在限制本申请。

对本申请实施例进行进一步详细说明之前，对本申请实施例中涉及的名词和术语进行说明，本申请实施例中涉及的名词和术语适用于如下的解释。

1)运行时(runtime)：iOS系统提供的运行时环境，可以在运行时改变程序的行为；

2)键值监听(KVO，Key Value Observing)机制：利用观察者模式实现的键值监听机制，用于“捕捉”对象属性的变化；

3)页面加载时长：用户点击打开新页面到页面内容可见的一段时间。

4)基类：在使用继承时，原来的类称为基类，也可以称为父类。

5)派生类：利用继承机制，从已有的类中派生出的类，也可以称为子类。

为了更好地理解本申请实施例，首先对相关技术中的页面加载时长的统计方法及存在的缺点进行说明。

在相关技术中页面加载时长的统计方案有以下几种：

第一种：基于runtime swizzling的统计方案。

该方案的基本思路是利用swizzling在viewDidLoad方法里保存一个初始时间，然后在viewDidAppear里得到页面出现的时间，计算这两个时间差，最终得到页面的加载时长。

第二种：基于KVO的统计方案。

在第一种方案中存在一个问题：swizzling的viewDidLoad方法其实是父类UIViewController的方法，子类其实是调用了super viewDidLoad方法，这种处理方式没办法对每种页面都进行处理，需要各自建立对应分类，实现复杂，效率低。该方案利用KVO拿到派生的子类进行指向方法实现的指针(IMP，Impl ementation)的替换，从而解决了这个问题。

第三种：截图分析纯色占比方案。

第一种方案和第二种方案虽然都可以统计页面加载时长，但页面的数据有时候需要等网络请求回来后再刷新页面，也就是用户看到有内容的页面，如果要统计这段时长，上述两个方案都无法做到。该方案利用图像纯色占比来判断当前页面是否是加载完成。简单来说，就是开启一个CADisplayLink定时器，对当前页面进行截图，然后利用计算纯色占比的算法算出比例，当比例大于某一个阈值，就说明页面已经加载成功了。

上述三种统计方案中存在的缺点分别为：

第一种方案无法对每种页面都进行处理，需要各自建立对应分类，实现复杂，效率低；第二种方案虽然解决了第一种方案中的缺点，以简单的方式精确统计页面的时长，但无法统计耗时函数；第三种方案以截图分析纯色占比来统计页面加载时长，如果有些页面被故意设计成有较多留白，使得时长统计准确率低，而且也无法统计耗时函数。

基于此，本申请实施例提供一种页面加载时长的方法，首先基于KVO模式，利用runtime机制，监听页面初始化和页面可见事件，分别记录开始时间和结束时间，从而精确统计页面加载时长。与此同时，在子线程中按照固定的时间间隔来跟踪主线程的堆栈信息，通过统计比较时间间隔之间的堆栈状态，来推算某个方法的执行时间，并获得一个近似值，从而在页面初始化到页面内容可见这段时间内筛选出耗时最多的方法，再结合上下文环境，逐个优化。

下面说明实现本申请实施例的装置的示例性应用，本申请实施例提供的装置可以实施为终端设备。下面，将说明装置实施为终端设备时涵盖终端设备的示例性应用。

参见图1，图1为本申请实施例页面加载时长的统计方法的网络架构示意图，如图1所示，在该网络架构中至少包括用户终端100、服务器200、网络300和开发者终端400。为实现支撑一个示例性应用，用户终端100和开发者终端400分别通过网络300连接服务器200，网络300可以是广域网或者局域网，又或者是二者的组合，使用无线链路实现数据传输。

当用户通过用户终端100打开网页或者应用中的页面时，用户终端100监听页面初始化和页面可见事件，分别记录开始时间和结束时间，从而精确统计页面加载时长，并在子线程中按照固定的时间间隔来跟踪主线程的堆栈信息，通过统计比较时间间隔之间的堆栈状态，来推算某个方法的执行时间，从而在页面初始化到页面内容可见这段时间内筛选出耗时最多的方法，进而用户终端100通过网络300将页面加载时长和耗时最多的方法发送至服务器200，服务器200可以再讲页面加载时长和耗时最多的方法发送给开发终端400，进而使得开发人员再结合上下文环境，对各方法进行逐个优化。

在下文的描述中，为了描述方便，将上述各种可能方式的服务器都统称为服务器，因此服务器200不应简单理解为一个或一类服务器，而是根据上述的示例，在实际应用中为了支撑应用或网页而部署的各种可能形式的服务器。

本申请实施例提供的装置可以实施为硬件或者软硬件结合的方式，下面说明本申请实施例提供的装置的各种示例性实施。

根据图2示出的用户终端100的示例性结构，可以预见用户终端100的其他的示例性结构，因此这里所描述的结构不应视为限制，例如可以省略下文所描述的部分组件，或者，增设下文所未记载的组件以适应某些应用的特殊需求。

图2所示的用户终端100包括：至少一个处理器110、存储器140、至少一个网络接口120和用户接口130。用户终端100中的每个组件通过总线系统150耦合在一起。可理解，总线系统150用于实现这些组件之间的连接通信。总线系统150除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见，在图2中将各种总线都标为总线系统150。

用户接口130可以包括显示器、键盘、鼠标、触感板和触摸屏等。

存储器140可以是易失性存储器或非易失性存储器，也可包括易失性和非易失性存储器两者。其中，非易失性存储器可以是只读存储器(ROM，Read Only Memory)。易失性存储器可以是随机存取存储器(RAM，Random Access Memory)。本申请实施例描述的存储器140旨在包括任意适合类型的存储器。

本申请实施例中的存储器140能够存储数据以支持用户终端100的操作。这些数据的示例包括：用于在用户终端100上操作的任何计算机程序，如操作系统和应用程序。其中，操作系统包含各种系统程序，例如框架层、核心库层、驱动层等，用于实现各种基础业务以及处理基于硬件的任务。应用程序可以包含各种应用程序。

作为本申请实施例提供的方法采用软件实施的示例，本申请实施例所提供的方法可以直接体现为由处理器110执行的软件模块组合，软件模块可以位于存储介质中，存储介质位于存储器140，处理器110读取存储器140中软件模块包括的可执行指令，结合必要的硬件(例如，包括处理器110以及连接到总线150的其他组件)完成本申请实施例提供的方法。

作为示例，处理器110可以是一种集成电路芯片，具有信号的处理能力，例如通用处理器、数字信号处理器(DSP，Digital Signal Processor)，或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等，其中，通用处理器可以是微处理器或者任何常规的处理器等。

将结合本申请实施例提供的终端的示例性应用和实施，说明本申请实施例提供的页面加载时长的统计方法。

参见图3，图3为本申请实施例提供的页面加载时长的统计方法的一种实现流程示意图，应用于图1所示的用户终端，将结合图3示出的步骤进行说明。

步骤S101，用户终端基于接收到的加载页面的操作指令，利用运行时机制对业务类实例进行键值监听。

这里，用户终端可以是移动电话(手机)、平板电脑、笔记本电脑等具有无线通信能力的移动终端，还可以实施为不便移动的具有计算功能的台式计算机、桌面电脑等。用户终端中可以安装有各种应用客户端，例如可以安装有游戏应用客户端、社交应用客户端、购物应用客户端、浏览器应用客户端等，用户可以通过用户终端中安装的各种应用客户端打开相应的页面，以进行游戏、社交、购物、浏览新闻等。

加载页面的操作指令可以是用户点击了页面的统一资源定位(URL，Unif ormResource Locator)地址而触发的，还可以是用户点击了加载页面的按钮控件而触发的；当然在一些实施例中，还可以是用户发出加载页面的预设语音或者用户做出加载页面的预设手势而触发的。

在本申请实施例中，当用户终端接收到加载页面的操作指令后，利用runtime机制，对业务类实例进行KVO，也可以理解成为业务类实例注册KVO功能或将业务类实例设置为KVO模式，以利用观察者模式实现键值监听机制。

在一些实施例中，利用运行时机制对业务类实例进行键值监听在实现时，可以是当业务类实例初始化时，为所述业务类创建键值监听派生类，其中，所述键值监听派生类通过调用所述业务类的方法实现。

步骤S102，当所述用户终端监听到页面初始化事件时，获取所述页面初始化事件的第一起始时间。

这里，监听页面初始化事件在实现时，可以是监听页面初始化所需要调用的方法(也可以称为函数)是否被调用，当监听到页面初始化所需要调用的方法被调用时，则认为监听到页面初始化事件，此时获取所述页面初始化事件的第一起始时间。

在本申请实施例中，页面初始化事件的第一起始时间可以是页面初始化所需要调用的方法的执行开始时间。第一起始时间可以是页面初始化所需要调用的方法的执行第一条指令的系统时间。在实际实现中，可以是监测到页面初始化所需要调用的方法的第一条指令被执行时，增加一条获取系统时间的代码，以获取第一起始时间。

在一些实施例中，还可以在检测到页面初始化所需要调用的方法的最后一条指令被执行时，同样增加一条获取系统时间的代码，以获取第二结束时间。

步骤S103，当所述用户终端监听到页面可见事件时，获取所述页面可见事件的第一结束时间。

这里，监听页面可见事件在实现时，可以是监听表征页面可见所需要调用的方法(也可以称为函数)是否被调用，当监听到表征页面可见所需要调用的方法被调用时，则认为监听到页面可见事件，在表征页面可见所需要调用的方法执行结束时，获取所述页面可见事件的第一结束时间。

在本申请实施例中，页面可见事件的第一结束时间可以是表征页面可见所需要调用的方法的执行结束时间。第一结束时间可以是表征页面可见所需要调用的方法执行最后一条指令的系统时间。在实际实现中，可以是监测到表征页面可见所需要调用的方法的最后一条指令被执行时，增加一条获取系统时间的代码，以获取第一结束时间。

在一些实施例中，还可以在表征页面可见所需要调用的方法第一条指令被执行时，增加一条获取系统时间的代码，以获取第二起始时间。

步骤S104，所述用户终端基于所述第一起始时间和所述第一结束时间，确定页面加载时长。

这里，步骤S104在实现时，是将第一结束时间减去第一起始时间从而得到页面加载时长。例如，第一结束时间为2019年10月9日10：04：30，第一开始时间为2019年10月9日10：04：20，那么将第一结束时间减去第一开始时间，得到页面加载时长为10秒。

在本申请实施例提供的页面加载时长的统计方法中，在接收到加载页面的操作指令时，利用运行时(runtime)机制，对业务类实例进行键值监听，以监听页面初始化和页面可见事件，并且分别记录页面初始化时间的开始时间和页面可见事件的结束时间，如此对现有的业务代码的改动很小，只需要增加获取第一起始时间和第一结束时间的实现代码即可，对业务代码的侵入性几乎可以忽略不计，并且能够精确且高效的统计出页面加载时长。

在一些实施例中，可以通过以下步骤进行页面初始化，并确定是否监听到页面初始化事件：

步骤S21，确定所述键值监听派生类的视图加载方法是否有对应的实现。

这里，由于键值监听派生类一般是通过调用所述业务类的方法实现的，因此一般情况下键值监听派生类的视图加载方法没有对应的实现，此时需要进入步骤S23，通过调用基类，也就是业务类的视图加载方法，以进行页面初始化；如果键值监听派生类的视图加载方法有对应的实现时，此时进入步骤S22，调用键值监听派生类的视图加载方法，以进行页面初始化。

步骤S22，当确定所述键值监听派生类的视图加载方法有对应的实现时，调用键值监听派生类的视图加载方法，以进行页面初始化。

这里，视图加载方法可以是用来创建用户界面视图控制器(UIViewController)的视图(view)的，因此也可以认为是视图创建方法。在本申请实施例中，键值监听派生类的视图加载方法可以是kvo_loadView方法。

步骤S23，当确定所述键值监听派生类的视图加载方法没有对应的实现时，调用所述业务类的视图加载方法，以进行页面初始化。

这里，当键值监听派生类的视图加载方法没有对应的实现时，调用该键值监听派生类的父类，也即业务类的视图加载方法。业务类的视图加载方法可以是loadView方法。

在本申请实施例中，当监听到视图加载方法被调用时，确定监听到页面初始化事件，进一步地，当监听到kvo_loadView方法或loadView方法被调用时，认为开始进行页面初始化，此时确定监听到页面初始化事件，进入步骤S102获取页面初始化事件的第一起始时间。

在一些实施例中，可以通过以下步骤确定是否监听到页面可见事件：

步骤S31，当达到预设的页面可见条件时，确定所述键值监听派生类的视图可见方法是否有对应的实现。

这里，当用户终端确定达到预设的页面可见条件时，需要调用视图可见方法。在页面加载过程中，经过页面初始化之后，需要对页面将要显示的内容进行渲染并显示，当监测到显示的内容占屏幕显示内容的比例大于一定阈值后认为达到预设的页面可见条件；在一些实施例中，还可以监测显示出的图形控件等，当显示出预设的图形控件时认为达到预设的页面可见条件。

由于键值监听派生类一般是通过调用所述业务类的方法实现的，因此与视图加载方法类似，一般情况下键值监听派生类的视图可见方法没有对应的实现，此时需要进入步骤S33，通过调用基类，也就是业务类的视图可见方法，以实现页面可见；如果键值监听派生类的视图可见方法有对应的实现时，此时进入步骤S32，调用键值监听派生类的视图可见方法，以实现页面可见。

步骤S32，当确定所述键值监听派生类的视图可见方法有对应的实现时，调用键值监听派生类的视图可见方法。

这里，视图可见方法来触发视图完全显示在屏幕上之后的行为，例如任何动画。键值监听派生类的视图可见方法可以是kvo_viewDidAppear方法。

步骤S33，当确定所述键值监听派生类的视图可见方法没有对应的实现时，调用所述业务类的视图可见方法。

这里，当键值监听派生类的视图可见方法没有对应的实现时，调用该键值监听派生类的父类，也即业务类的视图可见方法，业务类的视图可见方法可以是viewDidAppear方法。

其中，当监听到视图可见方法被调用时，确定监听到页面可见事件，进一步地，当监听到kvo_viewDidAppear方法或viewDidAppear方法被调用时，确定监听到页面可见事件。

在一些实施例中，在步骤S104确定出页面加载时长之后，还可以执行以下步骤：

步骤S105，获取所加载页面的页面标识。

步骤S106，建立所述页面标识和页面加载时长之间的对应关系，并存储所述对应关系。

这里，由于一个页面可能被加载多次，因此在一些实施例中，对应关系中还可以包括第一起始时间，从而可以确定出一个页面在不同的时刻被加载时所消耗的页面加载时长。

步骤S107，基于页面标识和页面加载时长的对应关系，确定所述页面标识对应的平均加载时长。

这里，由于一个页面可能会被加载多次，因此一个页面标识对应有多个页面加载时长，根据页面标识可以获取到该页面的各个页面加载时长，并基于各个页面加载时长确定平均加载时长，从而可以根据平均加载时长确定分析页面加载性能。

在一些实施例中，页面加载的过程中，还可以通过如图4所示的步骤41至步骤44进一步确定各个方法的执行时间：

步骤S41，在监听到页面初始化事件之后，按照预设时间间隔获取页面加载的主线程的堆栈信息。

这里，由于监听到页面初始化事件之后，即认为页面加载开始，此时按照预设时间间隔获取页面加载的主线程的堆栈信息，其中主线程的堆栈信息中包括各个方法(函数)的调用情况和执行状态。

举例来说，在监听到页面初始化事件之后，即获取一次主线程的堆栈信息，进而再启动计时器进行计时，在计时器的计时时长达到预设时间间隔时，再次获取一次主线程的堆栈信息，并将计时器归零，继续计时，在在计时器的计时时长达到预设时间间隔时，再次获取一次主线程的堆栈信息，直至页面加载完成。在一些实施例中，也可以是，在监听到页面初始化事件之后，获取一次主线程的堆栈信息，并且启动计时器开始计时，当计时器的计时时长达到预设时间间隔的整数倍后，再次获取主线程的堆栈信息。

步骤S42，当页面加载完成时，基于获取到的堆栈信息确定所出现的各个方法的出现次数。

这里，由于堆栈信息中包括有各个方法的调用情况和执行状态，因此通过多次获取的堆栈信息，可以确定出各个方法的出现次数。

在实际实现中，由于堆栈信息中存储的是各个方法的方法标识的二进制表示，因此在统计各个方法的出现次数时，可以首先对堆栈信息中的方法标识进行符号化，也即通过方法标识的二进制表示，查询二进制表示和方法标识的字符表示的对应关系，确定出方法标识的字符表示，并确定各个方法的出现次数。

在一些实施例中，还可以是直接基于方法标识的二进制表示确定出各个方法的出现次数，进而再对方法标识进行符号化，得到方法标识的字符标识。

步骤S43，基于各个方法的出现次数和预设时间间隔，确定各个方法的执行时间。

这里，步骤S43在实现时，将各个方法的出现次数乘以预设时间间隔T，即可得到各个方法的执行时间。举例来说func1分别在第三次获取和第四次获取的堆栈信息中出现，也就是说func1出现了两次，在第三次获取堆栈信息时开始执行，在第四次获取堆栈信息中也在执行，并且在第五次获取堆栈信息中已执行完毕，那么可以近似认为在第四获取堆栈信息中func1执行完毕，因此，func1的执行时间为2*T。

步骤S44，对各个方法的执行时间进行排序，并基于排序结果确定目标方法。

这里，步骤S44在实现时，可以是将各个方法的执行时间按照从大到小或者从小到大的顺序进行排序，从而根据排序结果确定出执行时间最长的一个或多个方法，并确定为目标方法。

在一些实施例中，当确定出页面加载时长以及目标方法之后，还可以执行以下步骤：

步骤S45，判断页面加载时长和/或平均加载时长是否均超过时长阈值。

这里，步骤S45在实现时，可以是仅判断本次的页面加载时长是否超过时长阈值，当本次的页面加载时长超过时长阈值时进入步骤S46，当本次的页面加载时长不超过时长阈值时不执行发送操作；也可以是仅判断平均加载时长是否超过时长阈值，当平均加载时长超过时长阈值时进入步骤S46，当平均加载时长不超过时长阈值时不执行发送操作；当然也可以是判断页面加载时长和平均加载时长是否均超过时长阈值，当页面加载时长和平均加载时长超过时长阈值时，进入步骤S46，将页面加载时长和目标方法的方法标识发送至开发者终端；当页面加载时长不超过时长阈值，或者平均加载时长不超过时长阈值时，不执行发送操作。

步骤S46，将所述页面加载时长和所述目标方法的方法标识发送至开发终端，以使得开发终端基于目标方法的方法标识进行优化处理。

这里，步骤S46在实现时，可以是将页面加载时长和目标方法的方法标识发送至服务器，然后由服务器发送给开发终端，或者由开发终端主动获取页面加载时长和目标方法的方法标识。在一些实施例中，如果用户终端与开发终端建立有直接的通信连接，也可以由用户终端直接将页面加载时长和目标方法的方法标识发送至开发终端，进而能够使得开发人员及时了解耗时较长的方法，并结合上下文，对各个方法进行逐个优化，从而提高页面加载性能。

基于前述的实施例，本申请实施例再提供一种页面加载时长的统计方法，应用于图1所示的网络架构中，图5为本申请实施例页面加载时长的统计方法的再一种实现流程示意图，如图5所示，所述方法包括：

步骤S501，用户终端基于接收到的加载页面的操作指令，利用运行时机制对业务类实例进行键值监听。

这里，在本申请实施例中，当用户终端接收到加载页面的操作指令后，利用runtime机制，对业务类实例进行KVO，也可以理解成为业务类实例注册KVO功能或将业务类实例设置为KVO模式，以利用观察者模式实现键值监听机制。

在一些实施例中，利用运行时机制对业务类实例进行键值监听在实现时，可以是当业务类实例初始化时，为所述业务类创建键值监听派生类，其中，所述键值监听派生类通过调用所述业务类的方法实现。

步骤S502，用户终端调用视图加载方法，以进行页面初始化，并每间隔预设时间间隔获取页面加载主线程的堆栈信息。

这里，由于键值监听派生类是通过调用基类，也就是业务类的方法实现的，因此，一般情况下，键值监听派生类的视图加载方法没有对应的实现，从而需要调用所述业务类的视图加载方法，以进行页面初始化。并且在本申请实施例中，在开始页面加载时，每间隔预设时间间隔获取一次页面加载主线程的堆栈信息，堆栈信息中至少包括各个方法的调用情况和执行状态。

步骤S503，用户终端获取调用视图加载方法的第一起始时间。

这里，当监听到调用视图加载方法时，则认为监听到页面初始化事件，此时获取视图加载方法执行第一条指令时的系统时间，并将该系统时间确定为第一起始时间。

步骤S504，用户终端确定是否为第一次加载视图。

这里，当确定是第一次加载视图时，需要进入步骤S505，调用viewDidLoad方法，以加载视图；当不是第一次加载视图时，则可以跳过调用viewDidLoad方法的步骤，而进入步骤S506，调用viewWillAppear方法。

步骤S505，用户终端调用viewDidLoad方法，以加载视图。

这里，viewDidLoad方法是当第一次加载view时调用，以后都不会用到，而viewDidAppear是每当切换到view时就调用。，如果是在代码中创建的视图加载器，viewDidLoad方法将会在loadView方法后被调用，如果是从nib视图页面输出，viewDidLoad方法将会在视图设置好后被调用。

步骤S506，用户终端调用viewWillAppear方法。

这里，viewWillAppear方法在视图即将可见时调用。默认情况下不执行任何操作。调用viewWillAppear方法用于更新准备显示的视图的信息。viewWillAppear方法被调用时，视图可能还没有被加载。

步骤S507，用户终端调用viewDidAppear方法。

这里，viewDidAppear方法在视图已完全过渡到屏幕上时调用，用于表征页面可见，也即页面加载完成。调用viewDidAppear方法能够触发视图完全显示在屏幕上之后的行为，例如显示动画。

步骤S508，用户终端获取调用viewDidAppear方法的第一结束时间。

这里，viewDidAppear方法执行完成时，可以认为页面加载完成，因此可以将viewDidAppear方法的最后一条指令的执行时间确定为第一结束时间。

步骤S509，用户终端基于第一起始时间和第一结束时间确定页面加载时长。

这里，步骤S509在实现时，是将第一结束时间减去第一起始时间从而得到页面加载时长。

步骤S510，用户终端基于当页面加载完成时，基于获取到的堆栈信息确定所出现的各个方法的出现次数。

这里，由于堆栈信息中包括有各个方法的调用情况和执行状态，因此通过多次获取的堆栈信息，可以确定出各个方法的出现次数。

在实际实现中，由于堆栈信息中存储的是各个方法的方法标识的二进制表示，因此在统计各个方法的出现次数时，可以首先对堆栈信息中的方法标识进行符号化，进而再获取各个方法的出现次数。

步骤S511，用户终端基于各个方法的出现次数和预设时间间隔，确定各个方法的执行时间。

这里，步骤S511在实现时，将各个方法的出现次数乘以预设时间间隔T，即可得到各个方法的执行时间。

步骤S512，用户终端对各个方法的执行时间进行排序，并基于排序结果确定目标方法。

这里，可以是将各个方法的执行时间按照从大到小或者从小到大的顺序进行排序，从而根据排序结果确定出执行时间最长的一个或多个方法，并确定为目标方法。

步骤S513，用户终端判断页面加载时长是否超过时长阈值。

这里，当页面加载时长超过时长阈值时，进入步骤S514；当页面加载时长不超过时长阈值时，结束流程。

步骤S514，用户终端将页面加载时长和目标方法的方法标识发送给服务器。

步骤S515，服务器将页面加载时长和目标方法的方法标识发送给开发终端。

步骤S516，开发终端基于接收到的页面加载时长和目标方法的方法标识结合上下文，对各个方法进行逐个优化。

在本申请实施例提供的页面时长的统计方法中，在用户终端接收到加载页面的操作指令后，首先基于KVO模式，利用runtime机制，监听表征页面初始化时间的视图加载方法，并记录第一起始时间，进而监听表征页面可见事件的视图可见方法，并记录第一结束时间，从而精确统计页面加载时长，并对现有的业务代码的侵入几乎可以忽略不计。与此同时，按照固定的时间间隔来跟踪主线程的堆栈信息，通过统计各次堆栈信息中方法的出现次数，推算某个方法的执行时间，并获得一个近似值，从而在页面初始化到页面内容可见这段时间内筛选出耗时最多的方法，实现自动监测页面加载耗时函数并发送至开发人员分析原因，统计关键函数，以进行专项优化，最终达到缩短页面的加载时长，提升用户页面浏览体验的目的。

下面，将说明本申请实施例在一个实际的应用场景中的示例性应用。

本申请实施例提供一种页面加载时长的统计方法，应用于用户终端。当用户终端接收到加载页面的操作指令时，首先利用runtime机制，对业务类实例进行KVO，当业务类实例初始化时，系统会自动为该业务类创建一个派生类，所创建的派生类通过调用基类对应函数实现。图6为本申请实施例利用KVO监听业务类实例的示意图，如图6所示，当页面初始化时，会先执行KVO子类的kvo_loadView方法601，如果KVO子类的kvo_loadView方法没有对应的实现，则会直接调用业务基类的loadView方法602，从而初始化页面。

其次，在子类NSKVONotifying_ClassXXX中实现页面生命周期的关键回调方法：loadView和viewDidAppear。图7为本申请实施例重写父类方法的示意图，如图7所示，页面实例初始化时会调用loadView方法701，当页面可见时，会调用viewDidAppear方法702。

如图7所示，loadView方法701和viewDidAppear方法702的实现逻辑大体上一致的，都是先记录开始时间，然后调用父类对应的方法，最后再记录结束时间。当loadView和viewDidAppear方法执行完成时，就会获得4个时间值，分别为loadView方法的开始时间T1、loadView方法的结束时间T2、viewDidAppear方法的开始时间T3和viewDidAppear方法的结束时间T4，从而精确统计页面的加载时长，也即(T4-T1)。

在本申请实施例中，还可以统计方法的执行耗时。在相关技术中，可以按照固定的时间间隔来跟踪每一个线程的堆栈信息，通过统计并比较时间间隔之间的堆栈状态，来推算某个方法执行了多久，并获得一个近似值。按照这个思路，在本申请实施例中，在页面加载过程中，每隔时间T获取一次主线程的堆栈信息，并在页面加载完成时，统计所有堆栈中各个方法出现的次数，这样就可以计算出每个方法的执行时间。而间隔时间T，是根据性能测试数据来动态设置的。

在统计各个方法的执行耗时的技术方案中，首先在页面实例初始化时，开启子线程，每间隔时间T获取一次主线程的堆栈信息，由于堆栈帧在内存中是以二进制地址表示的，而在本申请实施例中需要具体的函数名称，所以需要先对堆栈信息进行符号化，从而得到具体的函数名，再将具体的函数名保存在内存数组中，如图8所示。图8为本申请实施例主线程堆栈信息的示意图，如图3所示，在stack1中func1、func2和func3分别出现了1次，在stack2中func1和func2分别出现了1次，…，在stackn中func4和func5分别出现了1次。

其次，在页面加载完成时，也就是页面对用户可见之后，采用HashMap统计所有堆栈中各个方法出现的次数，例如在图8中，func1和func2都出现了2次，func3出现了1次，再根据间隔时间参数T，就可以近似估算出func1和func2的执行时间是2T，func3的执行时间是T。

最后，对所有方法按执行时间从大到小排序，筛选出耗时最多的方法，用户终端将耗时最多的方法发送给服务器，服务器可以进一步发送给开发终端，以使得开发人员结合业务当前上下文，对方法进行逐个优化，从而缩短页面加载时长。本申请实施例提供的方法执行时间的统计方案不仅对现有业务代码无任何侵入，而且对开发者来说是透明的，对于后续的业务扩展也是完全支持的。

在本申请实施例提供的页面加载时长的统计方法中，通过记录loadView方法的开始时间和viewDidAppear方法的结束时间能够精确统计页面加载时长，并且能够通过主线程的堆栈信息自动监测页面加载耗时函数并分析原因，统计关键函数，以指导开发者进行专项优化，最终缩短页面的加载时长，从而提升用户页面浏览体验。

下面继续说明本申请实施例提供的页面加载时长的统计装置80(以下简称统计装置)的实施为软件模块的示例性结构，在一些实施例中，如图2所示，存储在存储器140的统计装置80中的软件模块可以包括：

监听模块81，基于接收到的加载页面的操作指令，利用运行时机制对业务类实例进行键值监听；

第一获取模块82，用于当监听到页面初始化事件时，获取所述页面初始化事件的第一起始时间；

第二获取模块83，用于当监听到页面可见事件时，获取所述页面可见事件的第一结束时间；

第一确定模块84，用于基于所述第一起始时间和所述第一结束时间，确定页面加载时长。

在一些实施例中，所述监听模块81，包括：

创建单元，用于当业务类实例初始化时，为所述业务类创建键值监听派生类，其中，所述键值监听派生类通过调用所述业务类的方法实现。

在一些实施例中，所述统计装置还包括：

第二确定模块，用于确定所述键值监听派生类的视图加载方法是否有对应的实现；

第一调用模块，用于当确定所述键值监听派生类的视图加载方法有对应的实现时，调用键值监听派生类的视图加载方法，以进行页面初始化；

第二调用模块，用于当确定所述键值监听派生类的视图加载方法没有对应的实现时，调用所述业务类的视图加载方法，以进行页面初始化；

其中，当监听到视图加载方法被调用时，确定监听到页面初始化事件。

在一些实施例中，所述统计装置还包括：

第三确定模块，用于当达到预设的页面可见条件时，确定所述键值监听派生类的视图可见方法是否有对应的实现；

第三调用模块，用于当确定所述键值监听派生类的视图可见方法没有对应的实现时，调用键值监听派生类的视图可见方法；

第四调用模块，用于当确定所述键值监听派生类的视图可见方法没有对应的实现时，调用所述业务类的视图可见方法，其中，当监听到视图可见方法被调用时，确定监听到页面可见事件。

在一些实施例中，所述统计装置还包括：

第三获取模块，用于获取所加载页面的页面标识；

建立模块，用于建立所述页面标识和页面加载时长之间的对应关系，并存储所述对应关系；

第四确定模块，用于基于页面标识和页面加载时长的对应关系，确定所述页面标识对应的平均加载时长。

在一些实施例中，所述统计装置还包括：

第四获取模块，用于在监听到页面初始化事件之后，按照预设时间间隔获取页面加载的主线程的堆栈信息；

第五确定模块，用于当页面加载完成时，基于获取到的堆栈信息确定所出现的各个方法的出现次数；

第六确定模块，用于基于各个方法的出现次数和预设时间间隔，确定各个方法的执行时间；

排序模块，用于对各个方法的执行时间进行排序，并基于排序结果确定目标方法。

在一些实施例中，所述统计装置还包括：

发送模块，用于当所述页面加载时长和/或平均加载时长超出时长阈值时，将所述页面加载时长和所述目标方法的方法标识发送至开发终端，以使得开发终端基于目标方法的方法标识进行优化处理。

本申请实施例提供一种存储有可执行指令的存储介质，其中存储有可执行指令，当可执行指令被处理器执行时，将引起处理器执行本申请实施例提供的方法，例如，如图3、图4和图5示出的方法。

在一些实施例中，存储介质可以是FRAM、ROM、PROM、EPROM、EEPROM、闪存、磁表面存储器、光盘、或CD-ROM等存储器；也可以是包括上述存储器之一或任意组合的各种设备。

在一些实施例中，可执行指令可以采用程序、软件、软件模块、脚本或代码的形式，按任意形式的编程语言(包括编译或解释语言，或者声明性或过程性语言)来编写，并且其可按任意形式部署，包括被部署为独立的程序或者被部署为模块、组件、子例程或者适合在计算环境中使用的其它单元。

作为示例，可执行指令可以但不一定对应于文件系统中的文件，可以可被存储在保存其它程序或数据的文件的一部分，例如，存储在超文本标记语言(HTML，Hyper TextMarkup Language)文档中的一个或多个脚本中，存储在专用于所讨论的程序的单个文件中，或者，存储在多个协同文件(例如，存储一个或多个模块、子程序或代码部分的文件)中。

作为示例，可执行指令可被部署为在一个计算设备上执行，或者在位于一个地点的多个计算设备上执行，又或者，在分布在多个地点且通过通信网络互连的多个计算设备上执行。

以上所述，仅为本申请的实施例而已，并非用于限定本申请的保护范围。凡在本申请的精神和范围之内所作的任何修改、等同替换和改进等，均包含在本申请的保护范围之内。

Claims (10)

1.一种页面加载时长的统计方法，其特征在于，包括：

基于接收到的加载页面的操作指令，利用运行时机制对业务类实例进行键值监听；

当监听到页面初始化事件时，获取所述页面初始化事件的第一起始时间；

当监听到页面可见事件时，获取所述页面可见事件的第一结束时间；

基于所述第一起始时间和所述第一结束时间，确定页面加载时长。

2.根据权利要求1中所述的方法，其特征在于，所述利用运行时机制对业务类实例进行键值监听，包括：

当业务类实例初始化时，为所述业务类创建键值监听派生类，其中，所述键值监听派生类通过调用所述业务类的方法实现。

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

确定所述键值监听派生类的视图加载方法是否有对应的实现；

当确定所述键值监听派生类的视图加载方法有对应的实现时，调用键值监听派生类的视图加载方法，以进行页面初始化；

当确定所述键值监听派生类的视图加载方法没有对应的实现时，调用所述业务类的视图加载方法，以进行页面初始化；

其中，当监听到视图加载方法被调用时，确定监听到页面初始化事件。

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

当达到预设的页面可见条件时，确定所述键值监听派生类的视图可见方法是否有对应的实现；

当确定所述键值监听派生类的视图可见方法没有对应的实现时，调用键值监听派生类的视图可见方法；

当确定所述键值监听派生类的视图可见方法没有对应的实现时，调用所述业务类的视图可见方法，其中，当监听到视图可见方法被调用时，确定监听到页面可见事件。

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

获取所加载页面的页面标识；

建立所述页面标识和页面加载时长之间的对应关系，并存储所述对应关系；

基于页面标识和页面加载时长的对应关系，确定所述页面标识对应的平均加载时长。

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

在监听到页面初始化事件之后，按照预设时间间隔获取页面加载的主线程的堆栈信息；

当页面加载完成时，基于获取到的堆栈信息确定所出现的各个方法的出现次数；

基于各个方法的出现次数和预设时间间隔，确定各个方法的执行时间；

对各个方法的执行时间进行排序，并基于排序结果确定目标方法。

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

当所述页面加载时长和/或所述平均加载时长超出时长阈值时，将所述页面加载时长和所述目标方法的方法标识发送至开发终端，以使得开发终端基于目标方法的方法标识进行优化处理。

8.一种页面加载时长的统计装置，其特征在于，包括：

监听模块，基于接收到的加载页面的操作指令，利用运行时机制对业务类实例进行键值监听；

第一获取模块，用于当监听到页面初始化事件时，获取所述页面初始化事件的第一起始时间；

第二获取模块，用于当监听到页面可见事件时，获取所述页面可见事件的第一结束时间；

第一确定模块，用于基于所述第一起始时间和所述第一结束时间，确定页面加载时长。

9.一种页面加载时长的统计设备，其特征在于，包括：

存储器，用于存储可执行指令；

处理器，用于执行所述存储器中存储的可执行指令时，实现权利要求1至7任一项所述的方法。

10.一种存储介质，其特征在于，存储有可执行指令，用于引起处理器执行时，实现权利要求1至7任一项所述的方法。

Images