CN113094126A - 终端应用的窗体处理方法、应用服务器、终端及存储介质 - Google Patents

Abstract

本申请涉及计算机领域，公开了一种终端应用的窗体处理方法、应用服务器、终端及存储介质，在启动应用之后，创建与目标页面对应的窗体，在窗体创建之后，若用户退出该窗体时，该窗体并不会被销毁，而是将该窗体的目标数据缓存到缓存列表，在用户下次重新访问该窗体时，直接从缓存列表中查找该窗体的目标数据进行访问即可，无需再重建该窗体。相比于重建窗体而言，采用本申请提供的技术方案，在用户重新访问同一窗体时，节省了窗体重建的时间，从而进一步节省用户的时间，提升了用户流畅体验感。

Description

终端应用的窗体处理方法、应用服务器、终端及存储介质

技术领域

本发明涉及计算机技术领域，尤其涉及一种终端应用的窗体处理方法、应用服务器、终端及存储介质。

背景技术

终端的应用可以和使用者进行交互，一般具有可视的使用者界面。用户在打开一个应用时，通过窗体与用户进行交互，窗体是用户进入应用并浏览该应用的信息时，在终端上进行显示的显示页面。如用户启动一个应用时，创建的该应用的首页便可称为一个窗体。用户再点击该应用的另一个页面并进入时，又创建形成一个新的窗体。当用户点击退出该已创建完成的窗体时，该窗体便会被销毁。对于一个窗体而言，其在终端上呈现的数据包含用户界面(User Interface，UI)数据和每个窗体对应的应用内容数据。当用户退出已创建完成的窗体时，该窗体被完全销毁。当用户再次进入该窗体时，便又会重建该窗体的UI数据和应用内容数据，在重建窗体的过程中，会耗费用户大量的时间。

发明内容

本申请实施例提供了一种终端应用的窗体处理方法、应用服务器、终端及存储介质，在用户重新进入同一个窗体时，无需重建该窗体便可实现对该窗体的访问，节省了用户的时间，提升了用户流畅体验感。

第一方面，本申请实施例提供了一种终端应用的窗体处理方法，终端应用的窗体处理方法包括：

启动应用，在用户访问该应用的目标页面时，创建与该目标页面对应的窗体，其中，用户访问应用的目标页面可以有多个，对应的会创建多个窗体，当用户退出一窗体时，将该窗体作为目标窗体，退出该目标窗体的退出指令为第一目标指令，在用户退出目标窗体时，目标窗体的目标数据并不会被销毁，而是缓存到缓存列表中，在用户下一次访问同一个目标窗体时，直接从缓存列表中查找该目标窗体的目标数据进行使用，无需再重建该目标窗体。其中，用户再次访问同一个目标窗体的指令可称为第二目标指令；创建窗体时的数据包括但不限于UI数据和应用内容数据，目标窗体的目标数据包括但不限于UI数据和/或应用内容数据，UI数据包括窗体的布局结构数据、surface对象实例数据、窗体实例数据以及窗体的view树结构以及布局数据等，应用内容数据包括但不限于图片、网络数据等；其中，窗体的创建指的是用户访问一目标页面时，创建该目标页面的UI数据和应用内容数据形成供用户浏览的窗体，在创建UI数据时，从窗体的布局结构、surface对象实例、窗体实例、view树结构以及布局等方面进行创建，然后再更新应用内容数据，完成整个窗体的创建。在创建窗体的过程中，由于需要构建整个窗体的框架和布局，会耗费较长的时间。

本申请第一方面公开的一种终端应用的窗体处理方法，在启动应用之后，创建与目标页面对应的窗体，在窗体创建之后，若用户退出该窗体时，该窗体并不会被销毁，而是将该窗体的目标数据缓存到缓存列表，在用户下次重新访问该窗体时，直接从缓存列表中查找该窗体的目标数据进行访问即可，无需再重建该窗体，相比于重建窗体而言，采用本申请提供的技术方案，在用户重新访问同一窗体时，节省了窗体重建的时间，进一步节省了用户的时间，提升了用户流畅体验感。

进一步地，在上述第一方面的可能实现中，在启动应用后，用户会浏览很多个页面，对应的，也就会产生很多窗体，如果对这些窗体的数据都进行缓存，则会占用大量的内存和存储空间，为了避免此类情况发生，可以基于用户访问窗体的访问频率以及访问窗体的访问时间缓存目标窗体。在用户退出一窗体时，统计预定时间段内用户访问该窗体的访问频率是否超出第一阈值，如果超出第一阈值，则说明该窗体为常用窗体，并对该常用窗体的目标数据进行缓存。其中，预定时间段可以为1小时，第一阈值可以自定义设置，也可以根据创建的所有窗体的访问频率的排序进行设置，自定义设置时，可以设置为任意数据，如5次、3次等；按照访问频率的排序进行设置可以是在预定时间段内，对所有已经创建的窗体和用户退出的该窗体的访问频率进行降序排序，选择排序在前的30％的窗体作为目标窗体，如果用户退出的该窗体处于排序在前的30％的范围内，则将其作为目标窗体并缓存。

进一步地，在上述第一方面的可能实现中，在判断目标窗体是否为常用窗体时，可以以目标窗体的创建时刻开始至目标窗体退出时刻为预定时间段，在预定时间段内统计使用目标窗体的使用时间，如果预定时间段内用户的使用时间超出第二阈值，第二阈值可以自定义设置，也可以根据预定时间段内的所有的目标窗体的使用时间的排序进行降序排列，选择排序在前的30％作为常用窗体，如果“天猫超市”的窗体的使用时间处于排序在前的30％的常用窗体的范围内，则将“天猫超市”的窗体设为常用窗体，如“天猫超市”的窗体为目标窗体，用户首次访问“天猫超市”的窗体时，其访问时间为5分钟，其使用的时间超出了第二阈值4分钟，则将“天猫超市”的窗体作为常用窗体。

进一步地，在上述第一方面的可能实现中，为了便于对常用窗体进行区分，终端应用的窗体处理方法还包括对所述常用窗体进行标识。

进一步地，在上述第一方面的可能实现中，为了避免缓存目标窗体的所有的数据引起过度占用存储空间的问题，缓存的所述目标数据包括UI数据。通过只缓存目标窗体的UI数据可以避免占用手机过多的内存导致手机CPU响应速度降低的问题。

进一步地，在上述第一方面的可能实现中，在目标窗体的目标数据被缓存后，在用户长时间不使用不访问该目标窗体后，为了避免缓存的数据占用存储空间，终端应用的窗体处理方法还包括：所述目标窗体在设定时间内未被访问时，销毁缓存的所述目标窗体的所述目标数据。

进一步地，在上述第一方面的可能实现中，若所述缓存列表中不存在与所述目标窗体对应的所述目标数据，终端应用的窗体处理方法还包括：创建与所述第二目标指令对应的窗体。

进一步地，在上述第一方面的可能实现中，在所述从缓存列表中查找与所述目标窗体对应的目标数据之前还包括：

判断与所述第二目标指令对应的目标窗体是否携带常用窗体的标识；

若是，则进入所述从缓存列表中查找与所述目标窗体对应的目标数据的步骤；

若否，则创建所述目标窗体。

第二方面，本申请实施例提供了一种应用服务器，应用服务器包括：

启动模块，用于启动应用；

创建模块，用于创建用户访问的与所述应用的目标页面对应的窗体；

缓存模块，用于当接收到第一目标指令时，对与所述第一目标指令对应的目标窗体的目标数据进行缓存，所述第一目标指令描述所述用户退出所述目标窗体的执行动作；

访问模块，用于当接收到第二目标指令时，从缓存列表中查找与所述第二目标指令对应的目标窗体的目标数据，并基于所述目标数据访问所述目标窗体，所述第二目标指令描述访问所述目标窗体的访问动作。

第三方面，本申请实施例公开了一种终端，包括：

存储器，用于存储处理程序；

处理器，所述处理器执行所述处理程序时，实现如以上任意一种所述的终端应用的窗体处理方法的步骤。

第四方面，本申请实施例公开了一种计算机可读存储介质，所述计算机可读存储介质存储有处理程序，所述处理程序被处理器执行时，实现如以上任意一种所述的终端应用的窗体处理方法的步骤。

本发明其他特征和相应的有益效果在说明书的后面部分进行阐述说明，且应当理解，至少部分有益效果从本发明说明书中的记载变的显而易见。

附图说明

图1为本申请实施例公开的一种实现本申请实施例的一种移动终端的结构示意图；

图2为本申请实施例公开的一种终端应用的窗体处理方法的流程示意图；

图3(a)为本申请实施例公开的一种移动终端上的显示面板上显示的应用程序的状态示意图；

图3(b)为本申请实施例公开的一种窗体入栈缓存的流程示意图；

图4为本申请实施例提供的另一种终端应用的窗体处理方法的流程示意图；

图5为本申请实施例公开的一种应用服务器的结构示意图；

图6为本申请实施例公开的一种终端的结构示意图；

图7为本申请实施例公开的一种SOC的结构示意图。

具体实施方式

以下由特定的具体实施例说明本发明的实施方式，本领域技术人员可由本说明书所揭示的内容轻易地了解本发明的其他优点及功效。虽然本发明的描述将结合较佳实施例一起介绍，但这并不代表此发明的特征仅限于该实施方式。恰恰相反，结合实施方式作发明介绍的目的是为了覆盖基于本发明的权利要求而有可能延伸出的其它选择或改造。为了提供对本发明的深度了解，以下描述中将包含许多具体的细节。本发明也可以不使用这些细节实施。此外，为了避免混乱或模糊本发明的重点，有些具体细节将在描述中被省略。需要说明的是，在不冲突的情况下，本发明中的实施例及实施例中的特征可以相互组合。

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

在本申请实施例中，终端可以以各种形式进行实施，其包括但不限于手机、平板、笔记本电脑、掌上电脑、智能手环等移动终端，以及数字TV、台式计算机等固定终端。

在本申请实施例中，以终端为移动终端为例进行说明，本领域技术人员可以理解的是，根据本申请的实施方式的构造也能够应用于固定类型的固定终端。

如图1所示的，图1为本申请实施例公开的一种实现本申请实施例的一种移动终端的结构示意图，移动终端10包括但不限于WiFi模块100、A/V(音频/视频)输入单元101、传感器102、显示单元103、用户输入单元104、接口单元105、存储器106、处理器107、以及电源108等部件。本领域技术人员可以理解，图1中示出的移动终端结构并不构成对移动终端的限定，移动终端可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

下面结合图1对移动终端10的各个部件进行具体的介绍：

WiFi属于短距离无线传输技术，移动终端通过WiFi模块100可以帮助用户收发电子邮件、浏览网页和访问流式媒体等，它为用户提供了无线的宽带互联网访问。虽然图1示出了WiFi模块100，但是可以理解的是，其并不属于移动终端的必须构成，完全可以根据需要在不改变发明的本质的范围内而省略。

A/V输入单元101用于接收音频或视频信号。A/V输入单元101可以包括图形处理器(Graphics Processing Unit，GPU)1011和麦克风1012，图形处理器1011对在视频捕获模式或图像捕获模式中由图像捕获装置(如摄像头)获得的静态图片或视频的图像数据进行处理。处理后的图像帧可以显示在显示单元103上。经图形处理器1011处理后的图像帧可以存储在存储器106(或其它存储介质)中或者经由WiFi模块100进行发送。麦克风1012可以在电话通话模式、记录模式、语音识别模式等等运行模式中经由麦克风1012接收声音(音频数据)，并且能够将这样的声音处理为音频数据。麦克风1012可以实施各种类型的噪声消除(或抑制)算法以消除(或抑制)在接收和发送音频信号的过程中产生的噪声或者干扰。

显示单元103用于显示由用户输入的信息或提供给用户的信息。显示单元103可包括显示面板1031，可以采用液晶显示器(Liquid Crystal Display，LCD)、有机发光二极管(Organic Light-Emitting Diode,OLED)等形式来配置显示面板1031。

用户输入单元104可用于接收输入的数字或字符信息，以及产生与移动终端10的用户设置以及功能控制有关的键信号输入。具体地，用户输入单元104可包括触控面板1041以及其他输入设备1042。触控面板1041，也称为触摸屏，可收集用户在其上或附近的触摸操作(比如用户使用手指、触笔等任何适合的物体或附件在触控面板1041上或在触控面板1041附近的操作)，并根据预先设定的程序驱动相应的连接装置。触控面板1041可包括触摸检测装置和触摸控制器两个部分。其中，触摸检测装置检测用户的触摸方位，并检测触摸操作带来的信号，将信号传送给触摸控制器；触摸控制器从触摸检测装置上接收触摸信息，并将它转换成触点坐标，再送给处理器107，并能接收处理器107发来的命令并加以执行。此外，可以采用电阻式、电容式、红外线以及表面声波等多种类型实现触控面板1041。除了触控面板1041，用户输入单元104还可以包括其他输入设备1042。具体地，其他输入设备1042可以包括但不限于物理键盘、功能键(比如音量控制按键、开关按键等)、轨迹球、鼠标、操作杆等中的一种或多种，具体此处不做限定。

进一步的，触控面板1041可覆盖显示面板1031，当触控面板1041检测到在其上或附近的触摸操作后，传送给处理器107以确定触摸事件的类型，随后处理器107根据触摸事件的类型在显示面板1031上提供相应的视觉输出。虽然在图1中，触控面板1041与显示面板1031是作为两个独立的部件来实现移动终端10的输入和输出功能，但是在某些实施例中，可以将触控面板1041与显示面板1031集成而实现移动终端10的输入和输出功能，具体此处不做限定。

接口单元105用作至少一个外部装置与移动终端10连接可以通过的接口。例如，外部装置可以包括有线或无线头戴式耳机端口、外部电源(或电池充电器)端口、有线或无线数据端口、存储卡端口、用于连接具有识别模块的装置的端口、音频输入/输出(I/O)端口、视频I/O端口、耳机端口等等。接口单元105可以用于接收来自外部装置的输入(例如，数据信息、电力等等)并且将接收到的输入传输到移动终端100内的一个或多个元件或者可以用于在移动终端10和外部装置之间传输数据。

存储器106可用于存储软件程序以及各种数据。存储器106可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作***、至少一个功能所需的应用程序(比如声音播放功能、图像播放功能等)等；存储数据区可存储根据手机的使用所创建的数据(比如音频数据、电话本等)等。此外，存储器106可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。

处理器107是移动终端10的控制中心，利用各种接口和线路连接整个移动终端10的各个部分，通过运行或执行存储在存储器106内的软件程序和/或模块，以及调用存储在存储器106内的数据，执行移动终端10的各种功能和处理数据，从而对移动终端进行整体监控。处理器107可包括一个或多个处理单元；优选的，处理器107可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作***、用户界面和应用程序等，调制解调处理器主要处理无线通信。可以理解的是，上述调制解调处理器也可以不集成到处理器107中。

移动终端10还可以包括给各个部件供电的电源108(比如电池)，优选的，电源108可以通过电源管理***与处理器107逻辑相连，从而通过电源管理***实现管理充电、放电、以及功耗管理等功能。

尽管图1未示出，移动终端10还可以包括蓝牙模块、RF(Radio Frequency，射频)单元、传感器单元以及音频输出单元等，在此不再赘述。

基于以上的移动终端10，以移动终端10为手机为例对本申请的各个实施例进行说明，用户可以通过触控面板1041点击在显示面板1031上显示的某一应用，从而启动应用，在启动应用之后，用户可以通过触控面板1041点击显示面板1031上显示的该应用的各个模块从而浏览各个功能模块的详细的内容，在用户点击该应用的各个功能模块时，各个功能模块呈现的各个页面可以称为窗体。本申请以下提到的窗体的处理方法包括对窗体进行缓存以及对窗体的访问的步骤，下面结合具体图例对本申请实施例提供的一种窗体处理的方法进行说明。

下面结合图2和图3(a)对本申请实施例公开的一种终端应用的窗体处理方法进行说明，图2为本申请实施例公开的一种终端应用的窗体处理方法的流程示意图，图3(a)为本申请实施例公开的一种移动终端上的显示面板上显示的应用程序的状态示意图，图2示出的窗体处理方法包括：

步骤S20：用户通过触控面板点击手机上的应用，以启动应用。

在本申请的一些实施例中，应用是指设置在手机上的应用程序，如图3(a)所示的手机的显示面板上所显示的各个应用程序的图标，每个应用程序的图标都代表一个应用，如用户点击图3(a)中的淘宝应用时，淘宝应用便启动并为用户呈现首页的页面，首页的页面可以形成为一个窗体。与应用对应的是应用服务器，是指设置在服务器上，具备数据储存及分析能力，通过网络接受应用的请求、数据上传以及向用于应用发布命令、数据返回的应用程序。

在本申请的一些实施例中，应用启动可以是基于手机启动而自动启动，或者基于用户指令的启动、或者基于其他应用的启动的联动启动。

步骤S21：用户通过触控面板点击在显示面板上显示的应用的功能模块，创建与该功能模块的目标页面对应的窗体。

在本申请的一些实施例中，以淘宝应用为例，在用户通过触控面板启动淘宝之后，淘宝的首页呈现“天猫新品”、“天猫国际”、“饿了么”、“天猫超市”等功能模块，在用户通过触控面板点击“天猫超市”的功能模块时，应用服务器创建“天猫超市”的显示页面的窗体并在移动终端的显示面板上显示。

在本申请的一些实施例中，创建窗体的数据包括但不限于UI数据和应用内容数据，UI数据包括窗体的布局结构数据、surface对象实例数据(其一般为窗体绘制结果)、窗体实例数据以及窗体的view树结构、属性取值以及布局数据等，view树的属性取值可以是编辑文本对象中的文本数据等、view树的布局数据包括但不限于measure计算结果和layout计算结果，应用内容数据包括但不限于图片、网络数据等。进一步的，UI数据可以由用户在调用onSaveInstanceState()进行定义和设定。

可以理解的是，在本申请的一些实施例中，可以将窗体中的数据中的不变量进行缓存，如上述的UI数据，对于窗体中动态变化的数据(如网络数据、图片等)可以不作缓存。此外，对于缓存的窗体的数据也可以为其他数据，本申请实施例在此并不作限定。

步骤S22：在用户通过触控面板点击在显示面板上显示的退出该功能模块的目标窗体的图标时，应用服务器对该目标窗体的UI数据进行缓存。

在本申请的一些实施例中，以上述步骤S21中的淘宝为例继续进行说明，用户通过触控面板点击手机上的“back”键，即退出“天猫超市”的功能模块，也就是退出形成的“天猫超市”的目标窗体，现有技术中，在用户点击手机上的“back”键以退出该功能模块时，销毁创建完成的“天猫超市”的目标窗体，及销毁目标窗体的所有的数据，采用本申请实施例提供的技术方案，由应用服务器拉取“天猫超市”的目标窗体的UI数据作为目标数据缓存到手机的存储器中，只缓存目标窗体的UI数据可以避免占用手机过多的内存导致手机CPU响应速度降低的问题，此外，当用户点击手机上的“back”键退出“天猫超市”的窗体后，再次点击手机上的“back”键便退出整个应用。可以理解的是，退出功能模块的目标窗体也可以是用户点击关闭的图标“×”或者清除该应用的进程(即关闭整个应用)等方式，本申请实施例在此并不作限定，此外，若手机的存储空间足够，窗体的缓存的目标数据也可以包括“天猫超市”的目标窗体的页面网络数据等，本申请实施例对于缓存的数据的类型也并不作限定。

步骤S23：在用户通过触控面板重新点击目标窗体的功能模块时，从缓存列表中查找该功能模块的目标窗体的UI数据，并使用该UI数据以访问目标窗体。

在本申请的一些实施例中，以上述步骤S21和S22中的淘宝为例继续进行说明，在用户点击手机上的“back”键退出“天猫超市”的目标窗体后，用户再次点击“天猫超市”的功能模块的图标，可以由应用服务器从缓存列表中查找“天猫超市”的功能模块对应的目标窗体的同名窗体，即从缓存列表中查找“天猫超市”的UI数据并更新“天猫超市”的功能模块的应用内容数据以重现目标窗体并完成对目标窗体的访问。采用本申请实施例提供的技术方案，无需重建目标窗体，节省了重建目标窗体所耗费的时间，减少了应用的窗体启动耗时，提升用户流畅体验感。

在本申请的一些实施例中，缓存列表可以为窗体栈，即缓存的窗体可以以入栈的方式进行缓存，如图3(b)所示的，图3(b)为本申请实施例公开的一种窗体入栈缓存的流程示意图，启动一应用之后，用户首先分别点击了该应用的首页的两个功能模块并对应产生窗体A和窗体B，窗体A和窗体B由用户点击手机的“home”键以入栈的方式缓存到窗体栈，在用户点击另一功能模块时，生成窗体C，在用户点击手机上的“back”键后，退出窗体C，此时，按照现有技术的方案，窗体C会被销毁，而采用本申请实施例的技术方案，窗体C并不会被销毁，而是以入栈的方式缓存到窗体栈中，在用户下次访问窗体C对应的功能模块时，直接从窗体栈中拉取窗体C即可，无需重建，节省了窗体C的重建时间，减少了窗体C的启动耗时，提升了用户流畅体验感。

如下表1所示的，采用现有技术的方案和采用本申请实施例提供的技术方案，以微信应用为例，用户打开微信会话中的“相册”、“红包”以及“拍摄”三个功能模块的耗时如下表1所示：

表1

显而易见的是，在采用现有技术的方案，用户四次打开微信会话中的“相册”、“红包”以及“拍摄”三个功能模块的平均值均远远超出采用本申请提供的技术方案的平均值，性能提升均超出了15％，其中，打开“相册”和“红包”的性能更是超出了50％。明显减少了打开微信会话中的“相册”、“红包”以及“拍摄”三个功能模块的耗时，提升了用户流畅体验感。

在本申请的一些实施例中，因手机故障或者手机定期清理缓存等，缓存列表中的目标窗体的UI数据可能会被清理，未从缓存列表中查找到该目标窗体的UI数据时，可以采用和步骤S21中同样的方式重建该目标窗体。

在本申请的一些实施例中，针对与手机某一应用而言，按照用户的习惯和爱好，用户会更偏向访问自己感兴趣的一些功能模块，对于另一些功能模块可能只是偶尔浏览，为了避免对用户浏览过的所有的应用的功能模块的窗体的数据进行缓存而导致占用大量的手机存储空间，而降低手机的CPU处理性能的情况发生，本申请提供了另一种实施例，请参见图4，图4为本申请实施例提供的另一种终端应用的窗体处理方法的流程示意图，另一种终端应用的窗体处理方法包括：

步骤S40：用户通过触控面板点击手机上的应用，以启动应用。

步骤S41：用户通过触控面板点击在显示面板上显示的应用的功能模块，创建与该功能模块的目标页面对应的窗体。

在本申请的一些实施例中，以淘宝应用为例，在用户通过触控面板启动淘宝之后，淘宝的首页呈现“天猫新品”、“天猫国际”、“饿了么”、“天猫超市”等功能模块，在用户通过触控面板点击“天猫超市”的功能模块时，应用服务器创建“天猫超市”的显示页面的窗体并在移动终端的显示面板上显示。

可以理解是，在用户启动“淘宝”应用后，其可以通过触控面板点击淘宝的多个功能模块，从而由应用服务器创建形成多个窗体。

在本申请的一些实施例中，应用服务器创建窗体的数据包括但不限于UI数据和应用内容数据，UI数据包括窗体的布局结构数据、surface对象实例数据、窗体实例数据以及窗体的view树结构以及布局数据等，应用内容数据包括但不限于图片、网络数据等。

步骤S42：在用户通过触控面板点击在显示面板上显示的退出该功能模块的目标窗体的图标时，判断该目标窗体是否为常用窗体，若是，则进入S43，若否，则进入S44。

在本申请的一些实施例中，以上述步骤S41中的淘宝为例继续进行说明，用户在启动“淘宝”应用后，通过手机的触控面板在“淘宝”应用的首页先点击了“天猫超市”的功能模块，并由应用服务器创建形成一窗体，在用户点击手机的“home”键使得“天猫超市”的窗体缓存，并再次“淘宝”应用的首页通过手机的触控面板点击“天猫国际”的功能模块并由应用服务器创建形成“天猫国际”的窗体，然后用户点击手机的“home”键使得“天猫国际”的窗体缓存，用户点击手机的“菜单键”再次访问缓存的“天猫超市”的窗体，“天猫超市”的窗体被访问了两次，“天猫国际”的窗体访问了一次。

在本申请的一些实施例中，在判断目标窗体是否为常用窗体时，可以统计预定时间段内，例如以1小时为设定时间段，在1小时内用户通过手机的触控面板对目标窗体的访问频率，在访问频率超出第一阈值时，则将该目标窗体设为常用窗体，第一阈值可以自定义设置，也可以根据创建的所有窗体的访问频率的排序进行设置，自定义设置时，可以设置为任意数据，如5次、3次等；按照访问频率的排序进行设置可以是在预定时间段内，对所有已经创建的窗体和用户退出的该窗体的访问频率进行降序排序，选择排序在前的30％的窗体作为常用窗体，如果用户退出的该窗体处于排序在前的30％的范围内，则将其作为常用窗体并缓存。如“天猫超市”的窗体为目标窗体，在退出“天猫超市”的窗体时，由于“天猫超市”的窗体被用户通过触控面板访问了两次，则可以将“天猫超市”的窗体作为常用窗体。

此外，在本申请的一些实施例中，在在判断目标窗体是否为常用窗体时，可以以目标窗体的点击频率或者活跃程度进行判断，以目标窗体的创建时刻开始至目标窗体退出时刻的这一时间段为基准，统计在此期间用户操作目标窗体，例如点击或者拉动目标窗体的次数，如果在1小时内用户点击目标窗体的次数超出了5次(第三阈值)，则将该目标窗体设置为常用窗体。这里所列举的统计，也可以是对多次访问窗体的行为总体上统计的点击频率。可以理解的是，设定时间段根据实际情况也可以设定为其余数值，判断目标窗体是否为常用窗体的判断基准的第三阈值也可以设定为其他值，本申请实施例在此均不作限定。

在本申请的一些实施例中，在判断目标窗体是否为常用窗体时，可以以目标窗体的创建时刻开始至目标窗体退出时刻为预定时间段，在预定时间段内统计使用目标窗体的使用时间，如果预定时间段内用户的使用时间超出第二阈值，第二阈值可以自定义设置，也可以根据预定时间段内的所有的目标窗体的使用时间的排序进行降序排列，选择排序在前的30％作为常用窗体，如果“天猫超市”的窗体的使用时间处于排序在前的30％的常用窗体的范围内，则将“天猫超市”的窗体设为常用窗体，如“天猫超市”的窗体为目标窗体，用户首次访问“天猫超市”的窗体时，其访问时间为5分钟，其使用的时间超出了第二阈值4分钟，则将“天猫超市”的窗体作为常用窗体。

可以理解的是，常用窗体的判断基准根据实际情况也可以为其他形式，如用户访问的访问时间，即在特定的时间段内，访问该应用的任意一个功能模块而形成的窗体都可以作为常用窗体，特定时间段可以为北京时间“20点至22点”的区间段。

步骤S43：对常用窗体的UI数据进行缓存并标识常用窗体。

在本申请的一些实施例中，对常用窗体进行标识可以采用添加标签的方式进行标识，如将常用窗体标记为“1”，将非常用窗体标记为“0”。可以理解的是，对于常用窗体的标识也可以采用其他方式，本申请实施例在此并不作限定。

在本申请的一些实施例中，在目标窗体为常用窗体时，才对常用窗体的目标数据进行缓存，避免了对创建的所有的窗体的数据都进行缓存，而引起过度占用手机的存储空间的问题。

步骤S44：销毁该目标窗体。

步骤S45：在用户通过触控面板重新点击目标窗体的功能模块时，判断重新点击的该目标窗体是否携带常用窗体的标识，若是，则进入S46，若否，则进入S47。

步骤S46：从缓存列表中查找重新点击的该功能模块的目标窗体的UI数据，并使用该UI数据以访问目标窗体。

步骤S47：创建用户重新点击的该功能模块的目标窗体。

可以理解的是，本申请实施例公开的另一种终端应用的窗体处理方法与本申请上述实施例公开的一种终端应用的窗体处理方法相同内容可以互相参照，本申请实施例对于相同部分不再赘述。

可以理解的是，在本申请的一些实施例中，在目标窗体的目标数据被缓存后，在用户长时间不使用不访问该目标窗体后，为了避免缓存的数据占用存储空间，终端应用的窗体处理方法还包括：目标窗体在设定时间内未被访问时，销毁缓存的目标窗体的目标数据。预定时间可以设置为三天或者其他数据，根据实际情况可自定义设置，本申请实施例在此并不作限定。

请参见图5，图5为本申请实施例公开的一种应用服务器的结构示意图，图5示出的应用服务器包括：

启动模块50，用于启动应用；

创建模块51，用于创建用户访问的与应用的目标页面对应的窗体；

缓存模块52，用于当接收到第一目标指令时，对与第一目标指令对应的目标窗体的目标数据进行缓存，第一目标指令描述用户退出目标窗体的执行动作；

访问模块53，用于当接收到第二目标指令时，从缓存列表中查找与第二目标指令对应的目标窗体的目标数据，并基于目标数据访问目标窗体，第二目标指令描述访问目标窗体的访问动作。

在本申请的一些实施例中，启动模块50在接收到用户通过触控面板输入的指令后启动应用，创建模块51根据用户通过触控面板输入的点击该应用的某一功能模块的指令后，创建用户访问的与该应用的该功能模块对应的目标页面的窗体，用户点击浏览多个功能模块便会对应生成多个窗体，在用户通过触控面板点击手机的显示面板上显示的退出目标窗体的图标后，缓存模块52将该目标窗体的目标数据进行缓存，当用户通过触控面板再次点击与该目标窗体对应的功能模块后，访问模块53从缓存列表中查找与该目标窗体对应的目标数据，并基于目标数据对目标窗体进行访问。

可以理解的是，根据本实施例的应用服务器所执行的处理与对应的终端应用的窗体处理方法相同，相同部分可以相互参照，本申请实施例在此不再赘述。

在本申请的一些实施例中，在本申请一些实施例中，还提供了一种终端，下面结合图6对本申请实施例中的终端进行介绍。图6为本申请实施例公开的一种终端的结构示意图。

对于至少一个实施例，控制器中枢804经由诸如前端总线(FSB)之类的多分支总线、诸如快速通道互连(QPI)之类的点对点接口、或者类似的连接与处理器801进行通信。处理器801执行控制一般类型的数据处理操作的指令。在一实施例中，控制器中枢804包括，但不局限于，图形存储器控制器中枢(GMCH)(图中未示出)和输入/输出中枢(IOH)(其可以在分开的芯片上)(图中未示出)，其中GMCH包括存储器和图形控制器并与IOH耦合。

终端800还可包括耦合到控制器中枢804的协处理器806和存储器802。或者，存储器802和GMCH中的一个或两者可以被集成在处理器801内(如本申请中所描述的)，存储器802和协处理器806直接耦合到处理器801以及控制器中枢804，控制器中枢804与IOH处于单个芯片中。

在一个实施例中，存储器802可以是例如动态随机存取存储器(DRAM)、相变存储器(PCM)或这两者的组合。存储器802中可以包括用于存储数据和/或指令的一个或多个有形的、非暂时性计算机可读介质。计算机可读存储介质中存储有指令，具体而言，存储有该指令的暂时和永久副本。

在一个实施例中，协处理器806是专用处理器，诸如例如高吞吐量MIC处理器、网络或通信处理器、压缩引擎、图形处理器、GPGPU、或嵌入式处理器等等。协处理器806的任选性质用虚线表示在图6中。

在一个实施例中，终端800可以进一步包括网络接口(NIC)803。网络接口803可以包括收发器，用于为终端800提供无线电接口，进而与任何其他合适的设备(如前端模块，天线等)进行通信。在各种实施例中，网络接口803可以与终端800的其他组件集成。网络接口803可以实现上述实施例中的通信单元的功能。

在一个实施例中，如图6所示的，终端800可以进一步包括输入/输出(I/O)设备805。输入/输出(I/O)设备805可以包括：用户界面，该设计使得用户能够与终端800进行交互；***组件接口的设计使得***组件也能够与终端800交互；和/或传感器设计用于确定与终端800相关的环境条件和/或位置信息。

值得注意的是，图6仅是示例性的。即虽然图6中示出了终端800包括处理器801、控制器中枢804、存储器802等多个器件，但是，在实际的应用中，使用本申请各方法的设备，可以仅包括终端800各器件中的一部分器件，例如，可以仅包含处理器801和NIC803。图6中可选器件的性质用虚线示出。

在本申请一些实施例中，该终端800的计算机可读存储介质中存储有指令可以包括：由处理器中的至少一个单元执行时导致终端800实施如图2和图4提到的终端应用的窗体处理方法的指令。当指令在计算机上运行时，使得计算机执行上述如图2和图4所提到的终端应用的窗体处理方法。

现在参考图7，图7为本申请实施例公开的一种SOC的结构示意图，所示为根据本申请的一实施例的SoC(System on Chip，片上***)1000的框图。在图7中，相似的部件具有同样的附图标记。另外，虚线框是更先进的SoC的可选特征。该SoC可以被用于根据本申请的一实施例的终端，根据其内所存储的指令，可以实现相应的功能。

在图7中，SoC 1000包括：互连单元1002，其被耦合至处理器1001；***代理单元1006；总线控制器单元1005；集成存储器控制器单元1003；一组或一个或多个协处理器1007，其可包括集成图形逻辑、图像处理器、音频处理器和视频处理器；静态随机存取存储器(SRAM)单元1008；直接存储器存取(DMA)单元1004。在一个实施例中，协处理器1007包括专用处理器，诸如例如网络或通信处理器、压缩引擎、GPGPU、高吞吐量MIC处理器、或嵌入式处理器等等。

静态随机存取存储器(SRAM)单元1008中可以包括用于存储数据和/或指令的一个或多个计算机可读介质。计算机可读存储介质中可以存储有指令，具体而言，存储有该指令的暂时和永久副本。

在SoC 1000被应用于根据本申请的终端上时，计算机可读存储介质中存储有指令可以包括：由处理器中的至少一个单元执行时导致终端实施如图2和图4所提到的终端应用的窗体处理方法的指令。当指令在计算机上运行时，使得计算机执行上述如图2和图4所提到的图片处理方法。

此外，本申请实施例还公开了一种计算机可读存储介质，计算机可读存储介质上存储有处理程序，处理程序被处理器执行时实现如图2和图4提到的终端应用的窗体处理方法。

计算机可读存储介质可以为只读存储器、随机存取存储器、硬盘或者光盘等。

本申请实施例公开的一种终端应用的窗体处理方法、应用服务器、终端及存储介质，具有以下有益效果：

在启动应用之后，创建与目标页面对应的窗体，在窗体创建之后，若用户退出该窗体时，该窗体并不会被销毁，而是将该窗体的目标数据缓存到缓存列表，在用户下次重新访问该窗体时，直接从缓存列表中查找该窗体的目标数据进行访问即可，无需再重建该窗体，相比于重建窗体而言，采用本申请提供的技术方案，在用户重新访问同一窗体时，节省了窗体重建的时间，进一步节省了用户的时间，提升了用户体验感。

最后应说明的是：以上各实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述各实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的范围。

Claims (13)

1.一种终端应用的窗体处理方法，其特征在于，所述方法包括：

启动应用，创建用户访问的与所述应用的目标页面对应的窗体；

当接收到第一目标指令时，对与所述第一目标指令对应的目标窗体的目标数据进行缓存，所述第一目标指令描述所述用户退出所述目标窗体的执行动作；

当接收到第二目标指令时，从缓存列表中查找与所述第二目标指令对应的目标窗体的目标数据，并基于所述目标数据访问所述目标窗体，所述第二目标指令描述访问所述目标窗体的访问动作。

2.如权利要求1所述的终端应用的窗体处理方法，其特征在于，所述方法还包括：

当接收到所述第一目标指令时，基于统计预定时间段内的与所述目标窗体对应的活动数据对所述目标窗体的目标数据进行缓存，所述活动数据包括所述用户在所述预定时间段内访问所述目标窗体的访问频率。

3.如权利要求2所述的终端应用的窗体处理方法，其特征在于，所述目标窗体为所述预定时间段内用户的访问频率超出第一阈值的常用窗体。

4.如权利要求2所述的终端应用的窗体处理方法，其特征在于，所述活动数据还包括所述用户在所述预定时间段内使用所述目标窗体的使用时间。

5.如权利要求4所述的终端应用的窗体处理方法，其特征在于，所述目标窗体为所述预定时间段内所述用户的使用时间超出第二阈值的常用窗体。

6.如权利要求5所述的终端应用的窗体处理方法，其特征在于，所述方法还包括：

对所述常用窗体进行标识。

7.如权利要求1-6任意一项所述的终端应用的窗体处理方法，其特征在于，缓存的所述目标数据包括UI数据。

8.如权利要求1-6任意一项所述的终端应用的窗体处理方法，其特征在于，所述方法还包括：

所述目标窗体在设定时间内未被访问时，销毁缓存的所述目标窗体的所述目标数据。

9.如权利要求1-6任意一项所述的终端应用的窗体处理方法，其特征在于，若所述缓存列表中不存在与所述目标窗体对应的所述目标数据，所述方法还包括：

创建与所述第二目标指令对应的窗体。

10.如权利要求1-6任意一项所述的终端应用的窗体处理方法，其特征在于，在所述从缓存列表中查找与所述目标窗体对应的目标数据之前还包括：

判断与所述第二目标指令对应的目标窗体是否携带常用窗体的标识；

若是，则进入所述从缓存列表中查找与所述第二目标指令对应的目标窗体的目标数据的步骤；

若否，则创建所述目标窗体。

11.一种应用服务器，其特征在于，包括：

启动模块，用于启动应用；

创建模块，用于创建用户访问的与所述应用的目标页面对应的窗体；

缓存模块，用于当接收到第一目标指令时，对与所述第一目标指令对应的目标窗体的目标数据进行缓存，所述第一目标指令描述所述用户退出所述目标窗体的执行动作；

访问模块，用于当接收到第二目标指令时，从缓存列表中查找与所述第二目标指令对应的目标窗体的目标数据，并基于所述目标数据访问所述目标窗体，所述第二目标指令描述访问所述目标窗体的访问动作。

12.一种终端，其特征在于，包括：

存储器，用于存储处理程序；

处理器，所述处理器执行所述处理程序时，实现如权利要求1-10任意一项所述的终端应用的窗体处理方法的步骤。

13.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有处理程序，所述处理程序被处理器执行时，实现如权利要求1-10任意一项所述的终端应用的窗体处理方法的步骤。

Images