CN110888740B - 小程序的增量内存确定方法、装置、设备及存储介质 - Google Patents

Abstract

本申请提供一种小程序的增量内存确定方法、装置、设备及存储介质，涉及计算机技术领域，用以提升评估小程序运行的内存开销的准确度。该方法包括：获取目标小程序进程的激活时间，其中所述目标小程序进程为加载目标小程序的进程；获取所述目标小程序进程在激活时间的基准内存；获取所述目标小程序进程运行过程中的进程内存；以及确定所述进程内存与所述基准内存的差值为所述目标小程序的增量内存，所述增量内存表示所述目标小程序运行时占用的内存开销。该方法在评估小程序运行消耗的增量内存时，将目标小程序进程中不属于目标小程序的内存开销排除在外，提升了评估小程序运行的内存消耗的准确度。

Description

小程序的增量内存确定方法、装置、设备及存储介质

技术领域

本申请涉及计算机技术领域，尤其涉及一种小程序的增量内存确定方法、装置、设备及存储介质。

背景技术

随着计算机技术的发展，出现了小程序，小程序是一种通过HTML5技术等运行在浏览器或者应用APP中，不需要下载和安装即可使用的应用，且可以针对产品需求定位随意添加，越来越受欢迎；小程序在运行中也会占用一定的内存开销，目前常用加载小程序的进程消耗的整体内存评估小程序运行的内存开销，但是运行小程序的进程消耗的整体内存中还包括了诸多不属于小程序消耗的内存开销，如进程自身的内存开销、基础库的内存开销、浏览器组件如Webview的内存开销等，进而通过进程消耗的整体内存评估小程序运行的内存开销误差大。

发明内容

本申请实施例提供一种小程序的增量内存确定方法、装置、设备及存储介质，用于提升评估小程序运行的内存开销的准确度。

本申请第一方面，提供一种小程序的增量内存确定方法，包括：

获取目标小程序进程的激活时间，其中所述目标小程序进程为加载目标小程序的进程；

获取所述目标小程序进程在激活时间的基准内存；

获取所述目标小程序进程运行过程中的进程内存；以及

确定所述进程内存与所述基准内存的差值为所述目标小程序的增量内存，所述增量内存表示所述目标小程序运行时占用的内存开销。

本申请第二方面，提供一种小程序的增量内存确定装置，包括：

激活时间确定单元，用于获取目标小程序进程的激活时间，其中所述目标小程序进程为加载目标小程序的进程；

基准内存获取单元，用户获取所述目标小程序进程在激活时间的基准内存；

进程内存获取单元，用于获取所述目标小程序进程运行过程中的进程内存；以及

增量内存确定单元，用于确定所述进程内存与所述基准内存的差值为所述目标小程序的增量内存，所述增量内存表示所述目标小程序运行时占用的内存开销。

作为一种可能的实施方式，所述进程内存获取单元具体用于在所述目标小程序进程运行过程中，通过通信接口向运行所述目标小程序进程的客户端发送多个内存获取指令，由所述多个内存获取指令获得所述目标小程序进程在不同时间的多个进程内存；以及

所述增量内存确定单元具体用于，分别确定每个进程内存与所述基准内存的差值，获得所述目标小程序在不同时间的多个增量内存。

作为一种可能的实施方式，所述目标小程序进程为加载所述目标小程序的目标子进程；

所述目标小程序进程在激活时间的基准内存，为所述目标子进程在激活时间的内存；

所述目标小程序进程运行过程中的进程内存，为所述目标子进程在运行过程中的内存。

作为一种可能的实施方式，所述激活时间确定单元用于，通过所述通信接口向运行所述目标小程序进程的客户端发送激活进程检测指令，获取所述目标小程序进程的激活时间。

作为一种可能的实施方式，所述激活时间确定单元用于：

通过日志抓取工具监控预设关键事件；

确定监控到所述预设关键事件的时间为所述目标小程序进程的激活时间。

作为一种可能的实施方式，所述目标小程序进程为加载所述目标小程序的目标主进程；

所述目标小程序进程在激活时间的基准内存，为所述目标主进程在激活时间的内存；

所述目标小程序进程运行过程中的进程内存，为所述目标主进程运行所述目标小程序过程中的内存。

作为一种可能的实施方式，所述激活时间确定单元用于：

获取所述目标小程序的启动时间；

确定所述启动时间为所述目标小程序进程的激活时间。

本申请第三方面，提供一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现第一方面及任一种可能的实施方式中任一所述的方法。

本申请第四方面，提供一种计算机可读存储介质，所述计算机可读存储介质存储有计算机指令，当所述计算机指令在计算机上运行时，使得计算机执行如第一方面及任一种可能的实施方式中任一所述的方法。

由于本申请实施例采用上述技术方案，至少具有如下技术效果：

本申请中以目标小程序进程在激活时间的内存作为基准内存，用进程内存与基准内存的差值作为目标小程序运行时消耗的增量内存，将目标小程序进程中不属于目标小程序的内存开销排除在外，用增量内存评估目标小程序运行的内存消耗，提升了评估小程序运行的内存开销的准确度。

附图说明

图1为本申请实施例提供的一种检测客户端的处理机制示意图；

图2为本申请实施例提供的一种确定小程序的增量内存的场景示例图；

图3为本申请实施例提供的一种检测客户端的命令行窗口示意图；

图4为本申请实施例提供的小程序的增量内存确定方法的过程示意图；

图5为本申请实施例提供的一种确定即时通讯应用中的小游戏的增量内存的原理示意图；

图6为本申请实施例提供的一种通过ADB工具确定即时通讯应用的小游戏的增量内存的过程示意图；

图7为本申请实施例提供的另一种确定即时通讯应用中的小游戏的增量内存的原理示意图；

图8为本申请实施例提供的另一种通过ADB工具确定即时通讯应用的小游戏的增量内存的过程示意图；

图9为本申请实施例提供的确定某掌上游戏应用中的小游戏的增量内存的原理示意图；

图10为本申请实施例提供的一种通过ADB工具确定某掌上游戏应用的小游戏的增量内存的过程示意图；

图11为本申请实施例提供的一个确定的小程序的增量内存的示意图；

图12为本申请实施例提供的一种小程序的增量内存确定装置的结构示意图；

图13为本申请实施例提供的另一种小程序的增量内存确定装置的结构示意图；

图14为本申请实施例提供的一种终端设备的结构示意图。

具体实施方式

为了更好的理解本申请实施例提供的技术方案，下面将结合说明书附图以及具体的实施方式进行详细的说明。

为了便于本领域技术人员更好地理解本申请的技术方案，下面对本申请涉及的专有名词进行说明。

终端设备：可以是移动终端、固定终端或便携式终端，例如移动手机、站点、单元、设备、多媒体计算机、多媒体平板、互联网节点、通信器、台式计算机、膝上型计算机、笔记本计算机、上网本计算机、平板计算机、个人通信系统(PCS)设备、个人导航设备、个人数字助理(PDA)、音频/视频播放器、数码相机/摄像机、定位设备、电视接收器、无线电广播接收器、电子书设备、游戏设备或者其任意组合，包括这些设备的配件和外设或者其任意组合。

小程序容器：运行小程序的应用APP，提供运行H5应用的webivew组件，常见的小程序容器有即时通讯应用、掌上游戏应用、即时通讯应用游戏等；小程序可能运行在小程序容器可中主进程，也可能运行在小程序容器的子进程中，不同应用的实现方式不同，如即时通讯应用会创建子进程作为小程序进程，而在某掌上游戏应用中，小程序只能运行在主进程中。

下面对本申请的设计思想进行说明。

应用APP运行在单独的进程中，应用APP运行时消耗的进程内存是应用独享，该进程内存的大小反应了应用APP运行时的资源占用、内存开销，通过测试应用APP的进程内存，可以准确评估应用APP的客户端性能。

但是小程序的运行时的内存开销与应用APP运行时的内存开销不同，小程序运行在小程序容器的进程的Webview中，可能是主进程的Webview，也可能是子进程的Webview；如果以运行小程序的进程的进程内存对小程序运行消耗的内存进行评估，会由于进程内存中包含小程序以外的内存开销，如加载基础库的内存开销、Webview的内存开销等，这些内存开销会影响对小程序运行的内存开销的评估准确度。

鉴于此，发明人设计了一种小程序的增量内存确定方法、装置、设备及存储介质，该方法包括获取目标小程序进程的激活时间，进而获取目标小程序进程在激活时间的内存为基础内存；在目标小程序进程运行过程中，获取目标小程序的进程内存；以及将获取的进城内存和基础内存的差值作为上述目标小程序的增量内存，该增量内存表示目标小程序运行时占用的内存开销。

其中上述目标小程序进程为加载目标小程序的进程，上述目标小程序可以但不局限于为游戏小程序、购物小程序、阅读信息类小程序等。

由于目标小程序运行在小程序容器中，上述基准内存表示小程序容器完成基础库的加载，但运行目标小程序前进程的内存大小；从用户打开目标小程序到目标小程序页面首次显示完成，通常包含目标小程序的基础库加载、目标小程序代码包下载、代码执行和页面渲染等过程；执行每个步骤会逐渐增加内存开销，基准内存是小程序容器完成基础库加载，但未下载目标小程序的代码包时目标小程序进程的内存开销。

小程序容器需要为目标小程序运行提供各类能力，如页面渲染、JavaScript执行环境、本地服务的应用程序接口(Application Programming Interface，API)等。这些能力通过小程序容器中的基础库提供，以即时通讯应用的小程序为例，即时通讯应用的基础库包括提供页面渲染的Exparser框架，内置组件如表单类、媒体类、地图等组件，本地服务API如网络访问、文件、位置等，其他自定义组件和插件等。不同小程序容器的基础库各不相同，但功能类似。基础库通常内置在小程序容器内，在打开目标小程序前先要加载和初始化基础库，为目标小程序运行准备执行环境。

为了更清楚地理解本申请的设计思路，以下对检测客户端的处理机制进行示例介绍。

请参照图1，表示一种检测客户端的处理机制示例图，或者也可以表示一种终端设备的内部架构示意图。图1中通过检测客户端120检测目标小程序的基准内存和进程内存。在用户安装被检测客户端110之后，检测客户端120可以通过通信接口获取被检测客户端110的基本信息，其中检测客户端120和被检测客户端110可以在一个终端设备上，如终端设备为电脑时，以在电脑中同时安装检测客户端120和被检测客户端110，此时通信接口可以是终端设备中的应用列表GetApplist接口；检测客户端120和被检测客户端110还可以分别在不同的终端设备上，此时的通信接口可以是USB接口。

上述基本信息包括包名，包名是指客户端对应的安装包的名称。基本信息还可以包括被检测客户端110的应用名称、应用图标、进程的进程信息中的一种或几种组合等。在检测客户端120获取基本信息之后，检测客户端120就可以在其界面上显示该被检测客户端110的基本信息。

在用户想要检测小程序的增量内存时，用户可以在检测客户端120中开启被检测客户端110，例如用户可以点击该被检测客户端110等，其中，被检测客户端110可以是任意类型的客户端，例如游戏客户端、视频客户端、查询信息类应用客户端等等，本申请不限制被检测客户端110的具体类型。

在介绍完本申请实施例的设计思想之后，下面对本申请实施例的技术方案能够适用的应用场景做一些简单介绍，需要说明的是，以下介绍的应用场景仅用于说明本申请实施例而非限定。在具体实施过程中，可以根据实际需要灵活地应用本申请实施例提供的技术方案。

请参见图2，表示一种应用场景示例图，该应用场景中包括多个终端设备100，一些终端设备100安装有检测客户端120，一些终端设备安装有被检测客户端110，在检测客户端120和被检测客户端110通过通信接口进行通信。

其中，被检测客户端110安装有可运行目标小程序的应用，在应用对应的进程中可以运行目标小程序。

检测客户端120可以检测目标小程序进程在激活时间的基准内存以及运行过程中的进程内存，进而根据基准内存和进程内存确定目标小程序的增量内存，其中目标小程序进程为加载目标小程序的进程，其可能为应用的主进程或子进程。

被检测客户端110为手机时，上述检测客户端120可以是手机辅助(AndroidDebugBridge，ADB)工具，ADB工具是一个命令行窗口，参见图3，该命令行窗口即为指令操作界面，可以通过终端设备如电脑与模拟器或者真实设备进行交互，技术人员可以向该命令行窗口输入操作指令，并将操作指令发送给被检测客户端110，被检测客户端110可以将响应操作指令的一些信息或者被检测客户端输出的日志等信息发送到上述命令行窗口显示，如图3所示的命令行窗口，其中“C:\User\Administrator\Desktop\platform-tools>adb xxxxx”中的“adb xxxxx”表示ADB工具向手机发送的操作指令。

本申请实施例中涉及的小程序的增量内存确定方法可以适用于用户使用小程序的过程中，实时检测小程序的增量内存，也可以适用于小程序测试过程中，便于工作人员获知小程序运行消耗的增量内存。

基于图2的应用场景，下面对本申请实施例设计的小程序的增量内存确定方法进行示例性说明。

请参见图4，提供本申请实施例设计的小程序的增量内存确定方法的过程示意图，应用于检测客户端，具体如下：

步骤S401，获得目标小程序进程的激活时间。

目标小程序进程可以是加载目标小程序的目标子进程，也可以是加载目标小程序的目标主进程。

作为一种实施例，目标小程序为目标子进程时，检测客户端可以通过通信接口向被检测客户端发送激活进程检测指令，获取上述目标小程序进程的激活时间，可以将激活进程检测指令检测到目标小程序进程激活的时间作为上述激活时间，其中被检测客户端为运行上述目标小程序进程的客户端。

进一步，若上述目标子进程的应用中包括日志抓取工具，则可以通过日志抓取工具监控预设关键事件，确定监控到预设关键事件的时间为上述激活时间。

上述预设监控事件可以但不局限于是应用预加载事件、创建目标子进程、目标子进程初始化等事件。

更进一步，检测客户端可以以第一预设周期，周期性检测目标子程序是否激活，第一设定周期会影响检测激活时间的精确度，如第一设定周期为1秒时，表示检测到激活时间的精度为1秒，理论上第一设定周期越小越好，但第一设定周期过小时，检测目标子进程是否激活的操作过于频繁，影响检测客户端的其他性能，因此本领域的技术人员可根据实际需求设置上述第一设定周期。

作为一种实施例，目标小程序为目标主进程时，检测客户端可以获取目标小程序的启动时间，将获取的启动时间作为上述激活时间，其中上述启动时间可以用户记录的打开目标小程序的时间。

步骤S402，获取目标小程序进程在激活时间的基准内存。

作为一种实施例，目标小程序为目标子进程时，检测客户端可以在激活时间，向被检测客户端发送内存获取指令，获取目标小程序进程的内存作为基准内存。

作为一种实施例，目标小程序为目标主进程时，检测客户端确定目标主进程激活后，周期性地采集目标主进程的内存，将采集的激活时间的目标主进程的内存作为基准内存。

步骤S403，获取目标小程序进程运行过程中的进程内存。

在上述目标小程序进程运行过程中，通过通信接口向被检测客户端发送多个内存获取指令，由多个内存获取指令采集目标小程序在不同时间的多个进程内存。

检测客户端可以以第二设定周期，周期性向被检测客户端发送内存获取指令，获取目标小程序进程的进程内存，对第二设定周期不做过多限定，本领域的技术人员可根据实际需求设置，如将上述第二设定周期设置为1秒、0.5秒等。

作为一种实施例，目标小程序为目标子进程时，由内存获取指令采集目标子进程的多个内存，将获取的内存作为目标小程进程运行中的进程内存。

作为一种实施例，目标小程序为目标主进程时，将目标主进程运行目标小程序过程中的内存作为进程内存，其中，检测客户端可以获取目标小程序的关闭时间，将在目标小程序的启动时间和关闭时间内，目标主进程的内存作为上述进程内存。

步骤S404，根据获取的进程内存和基准内存确定目标小程序的基准内存。

将进程内存与基准内存的差值确定为目标小程序的增量内存。

若在步骤S403中获取了目标小程序在不同时间的多个进程内存，则此处分别确定每个进程内存与基准内存的差值，将获取的多个差值作为目标小程序在不同时间的多个增量内存。

为便于理解本申请方案，以下给出小程序的增量内存确定的几个示例。

示例1：目标小程序进程为目标子进程

此处以手机作为被检测客户端，以手机辅助(AndroidDebugBridge，ADB)工具作为检测客户端，以第一即时通讯应用中的小游戏作为目标小程序进行说明，该第一即时通讯应用中的小游戏运行在第一即时通讯应用的子进程中，用户启动小游戏后会在对应的子进程中运行小游戏，此处将运行小游戏的子进程即为上述目标子进程。

请参见图5，第一即时通讯应用启动后，用户在第一即时通讯应用中启动小游戏后，检测客户端会采集启动小游戏时目标子进程的内存作为基准内存，其中，用户启动小游戏时，会在第一即时通讯应用中创建运行小游戏的目标子进程；用户在体验小游戏的过程中，检测客户端会持续采集目标子进程的内存作为进程内存，用户关闭小游戏后，检测客户端根据基准内存和进程内存计算小游戏的增量内存。

以下对计算第一即时通讯应用中小游戏的增量内存的方法进行详细说明。

此示例中运行小游戏的目标子进程名称为com.tencent.mm:appbrand或com.tencent.mm:appbrandx，其中x为已启动的目标子进程的个数，x的数值可能是1、2、3等不同的数值。

用户在第一即时通讯应用中打开小游戏时，依次经过如下步骤：第一即时通讯应用拉起目标子进程，在目标子进程中加载基础库，下载小游戏的资源包和代码包，在目标子进程中执行代码、渲染小游戏画面，上述每个步骤由于加载不同的资源，目标子进程的内存在不断发生变化，上述资源包可以包括小游戏的动画或图画画面等。

通过通信接口向手机发送“dumpsys activity”，可以获取手机的安卓系统上已运行的所有应用的应用信息如应用的包名，将获取的应用信息保存到应用信息列表等；通过激活进程检测指令如grep top从应用信息列表中筛选出当前位于前台的应用，上述位于前台的应用即为激活的应用。

不同的应用位于前台时，dumpsys activity|grep top的结果不同，例如当第一即时通讯应用位于前台，dumpsys activity|grep top的执行结果为Proc#0:fore T/A/Ttrm:0 5257:com.tencent.mm/u0a257(top-activity)，其中包含第一即时通讯应用的进程的名称信息com.tencent.mm；当第一即时通讯应用的目标小游戏位于前台时，表示该目标小游戏激活，执行结果为Proc#2:fore T/A/T trm:0 13836:com.tencent.mm:appbrand0/u0a257(top-activity)，包含进程小游戏进程名com.tencent.mm:appbrand0。

根据上述指令的执行结果，使用正则表达式判断执行结果中是否包含形如“com.tencent.mm:appbrandx”的字符串，即可判断小游戏是否被拉起。为了监控目标子进程何时切换到前台，需要循环执行dumpsys activity|grep top的指令，并根据指令的结果进行字符串匹配。循环循环执行dumpsys activity|grep top的指令的第一设定周期会影响采集到的目标子进程是否在前台时间的精度，通过大量实验，当采用ADB工具作为检测客户端时，上述第一设定周期可以设置为0.3秒，在保证ADB服务稳定、可用的前提下，尽量提高采集精度。

当检测到目标子进程位于前台时，通过内存获取指令dumpsys meminfo–pid可获得目标子进程的内存，其中“pid”为目标子进程的进程标识。

如图6所示，给出了一种ADB工具确定第一即时通讯应用的小游戏的增量内存的过程示意图：

ADB工具开始监控后，以第一设定周期，周期性执行激活进程检测指令dumpsysactivity|grep top，并根据激活进程检测指令的执行结果，判断前台的进程是否是目标子程序。

确定检测前台的进程为目标子进程的时间为激活时间，在激活时间向被检测客户端发送内存获取指令dumpsys meminfo-pid，获取目标子进程的内存为基准内存。

进而继续以第一设定周期，周期性执行dumpsys activity|grep top判断目标子进程是否结束运行，若dumpsys activity|grep top检测出前台的进程不是目标子程序则确定目标子进程结束运行，以第二设定周期，周期性向被检测客户端发送内存获取指令dumpsys meminfo–pid，获取目标子进程的多个内存为多个进程内存。

若确定目标子进程不在前台后，则根据多个进程内存与基准内存计算小游戏的增量内存，计算增量内存后结束测试。

示例2：目标小程序进程为目标子进程

此示例中以监控到预设关键事件的时间为目标小程序进程的激活时间，此处以手机作为被检测客户端，以ADB工具作为检测客户端，以第二即使通讯应用中的小游戏作为目标小程序进行说明，。

请参见图7，第二即时通讯应用中的小游戏也运行在的子进程中，第二即时通讯应用启动后，用户启动小游戏时，第二即时通讯应用的主进程、加载小游戏的目标子进程会分别输出logcat日志，将监控到预设关键事件的logcat日志的时间为激活时间，在激活时间采集目标子进程的内存作为基准内存；用户在体验小游戏的过程中，检测客户端会持续采集目标子进程的内存作为进程内存，用户关闭小游戏后，检测客户端根据基准内存和进程内存计算小游戏的增量内存。

以下对计算第二即时通讯应用中小游戏的增量内存的方法进行详细说明。

第二即时通讯应用中运行小游戏的目标子进程名称为“com.tencent.mobile第二即时通讯应用:mini”或“com.tencent.mobile第二即时通讯应用:minix”，其中x为已启动的目标子进程的个数，x的数值可能是1、2、3等不同的数值。

第二即时通讯应用中的小游戏存在预加载机制，在未打开小游戏前，第二即时通讯应用的主进程会创建空闲的mini子进程、加载基础库、小游戏的游戏引擎等。当用户在第二即时通讯应用中打开小游戏时，第二即时通讯应用的主进程会寻找空闲的mini子进程加载和运行小游戏。mini子进程加载小游戏后即为目标子进程，目标子进程在启动、加载时会在日志抓取工具logcat日志系统中输出logcat日志，表示相应事件加载完成；例如，在目标子进程开始预加载时，logcat日志系统中输出do_preload，表示目标子进程开始加载，当目标子进程加载完成，logcat日志中输出miniapp-start。

第二即时通讯应用的主进程选择运行小游戏的目标子进程的时间为激活时间，在激活时间会在logcat日志输出obtain idle processor from stack:pid信息，从中可以解析出目标子进程的进程号pid，此时通过内存获取指令dumpsys meminfo-pid采集进程号为pid的目标子进程的内存作为基准内存。

在logcat日志系统中读取第二即时通讯应用的主进程、mini子进程的logcat日志，从logcat日志中筛选结果并进行字符串匹配，当匹配目标字符串时即可确定运行小游戏的目标子进程的检测湿巾；可以将从主进程的logcat日志系统中检测到miniapp-start的时间确定开始加载；当从目标子进程的logcat日志中检测到onCreate关键字，可确认目标子进程已完成加载。

如图8所示，给出了一种ADB工具确定第二即时通讯应用的小游戏的增量内存的过程示意图：

ADB工具开始监控后，以第一设定周期，周期性执行指令adb logcat|findstrminiapp监控第二即时通讯应用的主进程、目标子进程输出的logcat日志，并判断输出的logcat日志中是否包含预设关键事件。

确定检测预设关键事件的时间为激活时间，在激活时间从logcat日志中提取目标子进程的进程号pid，向被检测客户端发送内存获取指令dumpsys meminfo-pid，获取目标子进程的内存为基准内存。

进而继续以第一设定周期，周期性执行dumpsys activity|grep top判断目标子进程是否结束运行，若确定目标子进程结束运行，以第二设定周期，周期性向被检测客户端发送内存获取指令dumpsys meminfo–pid，获取目标子进程的多个内存为多个进程内存。

若确定目标子进程不在前台后，则根据多个进程内存与基准内存计算小游戏的增量内存，计算增量内存后结束测试。

示例3：目标小程序进程为目标主进程

此处以手机作为被检测客户端，以ADB工具作为检测客户端，以某掌上游戏应用中的小游戏作为目标小程序进行说明。

某掌上游戏应用是某游戏应用的助手类APP，在APP内玩家可以查看最新的游戏资讯、视频，也可以发帖、上传视频交流玩法心得。在APP内提供了部分小游戏，与端游玩法联动；在小游戏内游戏玩家可以对某游戏应用中的新英雄、主题活动进行尝鲜体验，游戏玩家在APP内通过Webview打开小游戏即可体验。

请参见图9，由于某掌上游戏应用中没有独立的子进程，也没有logcat日志系统，因此，小游戏只能在某掌上游戏应用的主进程中运行，此时某掌上游戏应用的主进程即为上述目标主进程某掌上游戏应用中小游戏的基准内存，以拉起小游戏前主进程的内存为准；将用户在体验小游戏的过程中，目标主进程的内存作为进程内存，用户关闭小游戏后，检测客户端根据基准内存和进程内存计算小游戏的增量内存。

如图10所示，给出了一种ADB工具确定某掌上游戏应用的小游戏的增量内存的过程示意图：

ADB工具开始监控后，以第一设定周期，周期性执行激活进程检测指令dumpsysactivity|grep top，判断某掌上游戏应用的目标主进程及是否位于前台，即判断目标主进程是否激活。

确定目标主进程激活后，以第二设定周期，周期性向被检测客户端发送内存获取指令dumpsys meminfo–pid，获取目标子进程的多个内存为多个进程内存。

用户在体验小游戏时，可以记录小游戏的启动时间和小游戏的关闭时间，将小游戏的启动时间作为小游戏的激活时间，将激活时间和关闭时间输入检测客户端。

检测客户端在获取激活时间和关闭时间后，将目标主进程在激活时间的内存确定为基准内存，将目标主进程在激活时间和关闭时间之间的多个内存作为多个进程内存，并根据多个进程内存与基准内存计算小游戏的增量内存，计算增量内存后结束测试。

为便于理解本申请的实施效果，本申请还提供了一个小程序的增量内存的示意图，具体可参见图11，其中横轴表示采集目标小程序进程的进程内存的时间点，其单位为秒；纵轴表示进程内存、基准内存和增量内存的内存大小，其单位为“MB”。

本申请中以目标小程序激活时的内存作为基准内存，用进程内存与基准内存的差值作为增量内存，以增量内存评估目标小程序运行时的内存开销，排除了加载基础库的内存开销以及Webview的内存开销，更准确地体现出小程序运行时占用的内存开销，以便技术人员更精确地评估小程序和被检测客户端的性能。

请参照图12，提供一种小程序的增量内存确定装置1200，该装置相当于前文论述的检测客户端120，包括：

激活时间确定单元1201，用于获取目标小程序进程的激活时间，其中上述目标小程序进程为加载目标小程序的进程；

基准内存获取单元1202，用户获取上述目标小程序进程在激活时间的基准内存；

进程内存获取单元1203，用于获取上述目标小程序进程运行过程中的进程内存；以及

增量内存确定单元1204，用于确定上述进程内存与上述基准内存的差值为上述目标小程序的增量内存，上述增量内存表示上述目标小程序运行时占用的内存开销。

作为一种实施例，上述进程内存获取单元具体用于在上述目标小程序进程运行过程中，通过通信接口向运行上述目标小程序进程的客户端发送多个内存获取指令，由上述多个内存获取指令获得上述目标小程序进程在不同时间的多个进程内存；以及

上述增量内存确定单元具体用于，分别确定每个进程内存与上述基准内存的差值，获得上述目标小程序在不同时间的多个增量内存。

作为一种实施例，上述目标小程序进程为加载上述目标小程序的目标子进程；

上述目标小程序进程在激活时间的基准内存，为上述目标子进程在激活时间的内存；

上述目标小程序进程运行过程中的进程内存，为上述目标子进程在运行过程中的内存。

作为一种实施例，上述激活时间确定单元用于，通过上述通信接口向运行上述目标小程序进程的客户端发送激活进程检测指令，获取上述目标小程序进程的激活时间。

作为一种实施例，上述激活时间确定单元用于：

通过日志抓取工具监控预设关键事件；

确定监控到上述预设关键事件的时间为上述目标小程序进程的激活时间。

作为一种实施例，上述目标小程序进程为加载上述目标小程序的目标主进程；

上述目标小程序进程在激活时间的基准内存，为上述目标主进程在激活时间的内存；

上述目标小程序进程运行过程中的进程内存，为上述目标主进程运行上述目标小程序过程中的内存。

作为一种实施例，上述激活时间确定单元用于：

获取上述目标小程序的启动时间；

确定上述启动时间为上述目标小程序进程的激活时间。

作为一种实施例，图12中的装置可以用于实现前文论述的任意一种小程序的增量内存确定方法。

基于同一发明构思，本申请实施例提供一种小程序的增量内存确定装置，该装置相当于前文论述的被检测客户端110，请参照图13，该装置1300包括收发模块1301和处理模块1302，其中：

收发模块1301，用于在处理模块1302的控制下，接收并执行检测客户端发送的各种操作指令，并将各种操作指令的执行结果通过通信接口发送给检测客户端。

作为一种实施例，图13中的装置可以用于实现前文论述的小程序的增量内存确定方法。

请参照图14，本实施例提供的终端设备100包括显示单元1440、处理器1480以及存储器1420，其中，显示单元1440包括显示面板1441，用于显示由用户输入的信息或提供给用户的信息以及检测客户端120和被检测客户端110的各种操作界面等，在本申请实施例中主要用于显示终端设备100中已安装的客户端的界面、快捷窗口等。

可选的，可以采用液晶显示器(Liquid Crystal Display，LCD)或有机发光二极管OLED(Organic Light-Emitting Diode)等形式来配置显示面板1441。

处理器1480用于读取计算机程序，然后执行计算机程序定义的方法，例如处理器1480读取检测应用或者被检测应用等，从而在该终端设备100上运行应用，在显示单元1440上显示应用的界面。处理器1480可以包括一个或多个通用处理器，还可包括一个或多个DSP(Digital Signal Processor，数字信号处理器)，用于执行相关操作，以实现本申请实施例所提供的技术方案。

存储器1420一般包括内存和外存，内存可以为随机存储器(RAM)，只读存储器(ROM)，以及高速缓存(CACHE)等。外存可以为硬盘、光盘、USB盘、软盘或磁带机等。存储器1420用于存储计算机程序和其他数据，该计算机程序包括客户端对应的应用程序等，其他数据可包括操作系统或应用程序被运行后产生的数据，该数据包括系统数据(例如操作系统的配置参数)和用户数据。本申请实施例中程序指令存储在存储器1420中，处理器1480执行存储其中存储器1420中的程序指令，实现前文图论述的任意的一种小程序的增量内存确定方法。

此外，终端设备100还可以包括显示单元1440，用于接收输入的数字信息、字符信息或接触式触摸操作/非接触式手势，以及产生与终端设备100的用户设置以及功能控制有关的信号输入等。具体地，本申请实施例中，该显示单元1440可以包括显示面板1441。显示面板1441例如触摸屏，可收集用户在其上或附近的触摸操作(比如用户使用手指、触笔等任何适合的物体或附件在显示面板1441上或在显示面板1441的操作)，并根据预先设定的程式驱动相应的连接装置。可选的，显示面板1441可包括触摸检测装置和触摸控制器两个部分。其中，触摸检测装置检测玩家的触摸方位，并检测触摸操作带来的信号，将信号传送给触摸控制器；触摸控制器从触摸检测装置上接收触摸信息，并将它转换成触点坐标，再送给处理器1480，并能接收处理器1480发来的命令并加以执行。在本申请实施例中，若用户点击被检测客户端110，则在显示面板1441中的触摸检测装置检测到触摸操作，则将检测到的触摸操作对应的信号发送的触摸控制器，触摸控制器将信号转换成触点坐标发送给处理器1480，处理器1480根据接收到的触点坐标确定用户需要对被检测客户端110进行检测。

其中，显示面板1441可以采用电阻式、电容式、红外线以及表面声波等多种类型实现。除了显示单元1440，终端设备100还可以包括输入单元1430，输入单元1430可以包括但不限于物理键盘、功能键(比如音量控制按键、开关按键等)、轨迹球、鼠标、操作杆等中的一种或多种。

除以上之外，终端设备100还可以包括用于给其他模块供电的电源1490、音频电路1460、近场通信模块1470和RF电路1410。终端设备100还可以包括一个或多个传感器1450，例如加速度传感器、光传感器、压力传感器等。音频电路1460具体包括扬声器1461和麦克风1462等，例如终端设备100可以通过麦克风1462采集用户的声音，进行相应的操作等。

作为一种实施例，处理器1480的数量可以是一个或多个，处理器1480和存储器1420可以是耦合设置，也可以是相对独立设置。

作为一种实施例，图14中的处理器1480可以用于实现如图12中的激活时间确定单元1201、基准内存获取单元1202、进程内存获取单元1203和增量内存确定单元1204的功能。

作为一种实施例，图14中的处理器1480可以用于实现如图13中的处理模块1301和收发模块1302的功能。

作为一种实施例，图14中的处理器1480可以用于实现前文论述的检测客户端120的功能，和/或被检测客户端的110功能。

基于同一技术构思，本申请实施例还一种计算机可读存储介质，该计算机可读存储介质存储有计算机指令，当上述计算机指令在计算机上运行时，使得计算机执行如前文论述的小程序的增量内存确定方法。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

Claims (10)

1.一种小程序的增量内存确定方法，其特征在于，应用于检测客户端，包括：

获取目标小程序进程的激活时间，其中所述目标小程序进程为加载目标小程序的进程；

获取所述目标小程序进程在激活时间的基准内存；其中，所述基准内存是小程序容器完成基础库加载，但未下载目标小程序的代码包时所述目标小程序进程的内存开销；

获取所述目标小程序进程运行过程中的进程内存；以及

确定所述进程内存与所述基准内存的差值为所述目标小程序的增量内存，所述增量内存表示所述目标小程序运行时占用的内存开销。

2.如权利要求1所述的方法，其特征在于，所述获取所述目标小程序进程运行过程中的进程内存，具体包括：

在所述目标小程序进程运行过程中，通过通信接口向运行所述目标小程序进程的客户端发送多个内存获取指令，由所述多个内存获取指令获得所述目标小程序进程在不同时间的多个进程内存；以及

所述确定所述进程内存与所述基准内存的差值为所述目标小程序的增量内存，具体包括：

分别确定每个进程内存与所述基准内存的差值，获得所述目标小程序在不同时间的多个增量内存。

3.如权利要求1或2所述的方法，其特征在于，所述目标小程序进程为加载所述目标小程序的目标子进程；

所述目标小程序进程在激活时间的基准内存，为所述目标子进程在激活时间的基准内存；

所述目标小程序进程运行过程中的进程内存，为所述目标子进程在运行过程中的内存。

4.如权利要求3所述的方法，其特征在于，所述获取目标小程序进程的激活时间，包括：

通过通信接口向运行所述目标小程序进程的客户端发送激活进程检测指令，获取所述目标小程序进程的激活时间。

5.如权利要求3所述的方法，其特征在于，所述获取目标小程序进程的激活时间，包括：

通过日志抓取工具监控预设关键事件；

确定监控到所述预设关键事件的时间为所述目标小程序进程的激活时间。

6.如权利要求1或2所述的方法，其特征在于，所述目标小程序进程为加载所述目标小程序的目标主进程；

所述目标小程序进程在激活时间的基准内存，为所述目标主进程在激活时间的基准内存；

所述目标小程序进程运行过程中的进程内存，为所述目标主进程运行所述目标小程序过程中的内存。

7.如权利要求3所述的方法，其特征在于，所述获取目标小程序进程的激活时间，包括：

获取所述目标小程序的启动时间；

确定所述启动时间为所述目标小程序进程的激活时间。

8.一种小程序的增量内存确定装置，其特征在于，所述装置包括：

激活时间确定单元，用于获取目标小程序进程的激活时间，其中所述目标小程序进程为加载目标小程序的进程；

基准内存获取单元，用户获取所述目标小程序进程在激活时间的基准内存；其中，所述基准内存是小程序容器完成基础库加载，但未下载目标小程序的代码包时所述目标小程序进程的内存开销；

进程内存获取单元，用于获取所述目标小程序进程运行过程中的进程内存；以及

增量内存确定单元，用于确定所述进程内存与所述基准内存的差值为所述目标小程序的增量内存，所述增量内存表示所述目标小程序运行时占用的内存开销。

9.一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时实现权利要求1-7中任一权利要求所述方法的步骤。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机指令，当所述计算机指令在计算机上运行时，使得计算机执行权利要求1-7中任一项所述的方法。

Images