本申请涉及信息处理技术领域，尤其涉及显示设备及其处理方法。
背景技术：
目前操作系统允许第三方应用弹出一种悬浮窗口，该悬浮窗的大小、内容、背景等都可以由应用控制，同时，由于是一个悬浮窗，该界面可以覆盖在当前任意一个应用的界面之上，如图1所示，显示屏上位于中间区域的窗口20，就是一个悬浮窗，该窗口盖住了下面的应用窗口30，虽然可见区域只有窗口20，但是该悬浮窗是全屏的，即窗口20占据整个显示屏10，只不过除了窗口20之外的地方的背景色都是全透明的而已。这样就造成了这个窗口不消失的时候用户永远点击不到下面应用窗口30。
技术实现要素：
本申请实施例提供了显示设备及其处理方法，用以实现对全屏窗口显示界面的异常检测，从而消除异常，保证用户及时对显示界面进行准确操作。
本申请实施例提供的一种显示设备，包括：
存储器，用于存储程序指令；
处理器，用于调用所述存储器中存储的程序指令，按照获得的程序执行：
确定当前运行的应用的显示界面为悬浮窗；
接收用户对所述悬浮窗进行的关于更改窗口大小的操作；
若所述悬浮窗的窗口大小在所述操作之后未发生变化，则清理所述应用的进程。
因此，本申请实施例提供的显示设备通过当悬浮窗的窗口大小在用户进行了关于更改窗口大小的操作之后未发生变化时，清理应用的进程，实现了对全屏窗口显示界面的异常检测，从而消除异常，保证用户及时对显示界面进行准确操作。
可选地，所述悬浮窗的类型为覆盖类型。
可选地，所述操作为连续点击操作。
可选地，若所述悬浮窗的窗口大小在所述操作之后未发生变化，则清理所述应用的进程，具体包括：
若所述悬浮窗的窗口大小在用户连续点击预设次数之后未发生变化，则清理所述应用的进程。
可选地，所述处理器包括：
窗口管理服务模块，用于将用户对所述悬浮窗的操作输出至日志；
行为管理服务模块，用于分析所述日志，并判断连续点击操是否达到预设次数。
可选地，所述行为管理服务模块通过广播的方式通知所述窗口管理服务模块重新确定所述悬浮窗的窗口大小。
本申请实施例提供的一种显示设备的处理方法，包括以下步骤：
确定当前运行的应用的显示界面为悬浮窗；
接收用户对所述悬浮窗进行的关于更改窗口大小的操作；
若所述悬浮窗的窗口大小在所述操作之后未发生变化，则清理所述应用的进程。
可选地，所述操作为连续点击操作。
可选地，若所述悬浮窗的窗口大小在所述操作之后未发生变化，则清理所述应用的进程，具体包括：
若所述悬浮窗的窗口大小在用户连续点击预设次数之后未发生变化，则清理所述应用的进程。
本申请另一实施例提供了一种计算机存储介质，所述计算机存储介质存储有计算机可执行指令，所述计算机可执行指令用于使所述计算机执行上述任一种方法。
附图说明
为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简要介绍，显而易见地，下面描述中的附图仅是本申请的一些实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1为现有技术中出现悬浮窗遮挡全屏的示意图；
图2为本申请实施例提供的应用窗口检查流程示意图；
图3为本申请实施例提供的触屏检查流程示意图；
图4为本申请实施例提供的窗口复查流程示意图；
图5为本申请实施例提供的一种显示设备的结构示意图；
图6为本申请实施例提供的处理器的结构示意图；
图7为本申请实施例提供的一种显示设备的处理方法的流程示意图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，并不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
因为在现有技术中，应用(app)创建了悬浮窗口后，如何使用该悬浮窗口，是应用自己的逻辑，也就是说，应用完全可以创建一个全屏窗口(window)盖住当前界面，但这种做法系统是无法检测出来的，因为这属于应用实现效果，而不是一个异常，并不会有异常日志(log)输出。
因此，在现有技术上，如何鉴别此类问题并恢复正常，是本申请实施例提供的方案所解决的技术问题。
本申请实施例提供了显示设备及其处理方法，用以实现对全屏窗口显示界面的异常检测，从而消除异常，保证用户及时对显示界面进行准确操作。
本申请实施例涉及的显示设备可以是终端设备，可以是指向用户提供语音和/或数据连通性的设备，具有无线连接功能的手持式设备、或连接到无线调制解调器的其他处理设备。在不同的系统中，终端设备的名称可能也不相同，例如在5g系统中，终端设备可以称为用户设备(userequipment，ue)。无线终端设备可以经ran与一个或多个核心网进行通信，无线终端设备可以是移动终端设备，如移动电话(或称为“蜂窝”电话)和具有移动终端设备的计算机，例如，可以是便携式、袖珍式、手持式、计算机内置的或者车载的移动装置，它们与无线接入网交换语言和/或数据。例如，个人通信业务(personalcommunicationservice，pcs)电话、无绳电话、会话发起协议(sessioninitiatedprotocol，sip)话机、无线本地环路(wirelesslocalloop，wll)站、个人数字助理(personaldigitalassistant，pda)等设备。无线终端设备也可以称为系统、订户单元(subscriberunit)、订户站(subscriberstation)，移动站(mobilestation)、移动台(mobile)、远程站(remotestation)、接入点(accesspoint)、远程终端设备(remoteterminal)、接入终端设备(accessterminal)、用户终端设备(userterminal)、用户代理(useragent)、用户装置(userdevice)，本申请实施例中并不限定。
下面结合说明书附图对本申请各个实施例进行详细描述。需要说明的是，本申请实施例的展示顺序仅代表实施例的先后顺序，并不代表实施例所提供的技术方案的优劣。
参见图2，应用窗口检测(由wms执行)流程如下：
s201、开启操作系统之后，应用可用的悬浮窗类型是type_application_overlay类型窗口(即覆盖类型的窗口，占据屏幕的整个显示区域)，因此，当应用通过调用系统接口创建悬浮窗口时，通过判断是否是type_application_overlay类型，来启动相关的监控动作。
s202、当系统的窗口管理(windowmanager)服务(简称wms)模块，判断应用要创建的窗口是type_application_overlay悬浮窗时，执行步骤s203，否则结束。
s203、系统首先获取应用申请的窗口大小，比如图1所示的窗口20的大小为高1904*宽1080，系统屏幕高2048*宽1080，状态栏高48，导航栏高96。
s204、确定显示屏大小。
s205、将应用申请的窗口大小跟系统屏幕大小做一个比例，记作窗口占比，比如上述例子中，窗口占比为(1904*1080)/(2048*1080)＝0.93。
s206、判断窗口占比是否大于预设值0.7，如果是，则执行步骤s207，否则执行步骤s208。
s207、当窗口占比大于0.7(经验值，即预先设置的值，该值可以根据实际需要而定)时，认为该界面已经影响用户正常对下方应用的操作使用。因此，将窗口名称 窗口占比写入第一标记位，该第一标记位可以使用系统属性(即systemproperties)，比如属性名为sys.topwindow.pkg，值为该窗口的名称，比如floatingwindow：0.93。
s208、若窗口占比小于0.7，则清空第一标记位。
此处第一标记位采用属性systemproperties，主要是基于后面的流程中，有些地方(如触屏检测)只能用属性systemproperties获取标记，而不能使用如数据库或者广播的方式。
参见图3，触屏的检测(inputdispatcher)流程如下：
s301、收到点击事件；
s302、判断第一标记位sys.topwindow.pkg是否有值，如果是，则执行步骤s303，否则结束。
s303、获取点击对象，即确定当前点击的窗口的名称。
s304、解析第一标记位，即当点击屏幕后，若sys.topwindow.pkg有值，取出该值后按照“：”进行字符串分割获得对应的标记窗口名称floatingwindow。
s305、判断第一标记位中记录的窗口名称，与用户当前点击的窗口的名称是否相同，如果是，则执行步骤s306，否则执行步骤s307。
s306、判断触屏点击的窗口名称跟第一标记位的内容一致时，记录一个第二标记位，第二标记位的值是点击sys.topwindow.pkg对应标记窗口的次数，每次点击对象是第一标记位记录的窗口时，则第二标记位的值加1。
s307、如果点击对象不是第一标记位中记录的窗口，则将第二标记位重置为0。
s308、将“标记标签(tag)” “点击窗口” “第二标记位”组合起来输出到日志(log)中。其中，所述标记标签，即用来标记该log的标签，便于后续log流检测流程中检测该标签所标记的log。
所述log举例可以按照如下格式输出：
04-0116:28:00.624842842einputdispatcher:touchtopx:floatingwindow:3
其中，“touchtopx”是标记tag，用来给其它模块进行log处理用，“floatingwindow”是当前点击到的窗口名称，“3”是第二标记位记录的次数。
这里要说明一点，之所以需要打log，而不是直接去发广播、写属性标记等操作，是因为发广播、写属性标记等操作会非常频繁，若执行这些操作，会导致系统被堵塞。所以采用log流输出的方式更省资源。
log流检测流程(例如可以由ams模块执行)如下：
当系统启动后，在系统的行为管理(activitymanager)服务(ams)模块中对当前系统输出的log进行逐行过滤解析，解析规则是判断log中，包含touchtopx(标记tag)字样的log字符串。若检测到该行log，则开始log解析。
log解析，可以根据触屏检测流程中规定好的格式(例如上述log输出格式04-0116:28:00.624842842einputdispatcher:touchtopx:floatingwindow:3)进行字符串解析，比如这里可以采用标记tag后面按“：”分割的方式，获取到floatingwindow和3，这个3就是第二标记位记录的次数了，例如可以当这个次数大于等于3时(即用户在floatingwindow界面连续点击了3次以上)，启动窗口复查流程。
启动窗口复查流程的方式可以通过发广播到另外一个服务中进行处理，也可以在ams内部实现。这里我们考虑查询的便捷性，通过广播方式通知wms进行窗口复查，即ams通知wms进行窗口复查，因为wms中包含了所有窗口的参数，可以直接使用，这样效率更高。
ams解析第一标记位，获取到floatingwindow对应的窗口占比0.93。
例如，这里ams可以发送如下的广播：com.window.recheck，携带参数floatingwindow和窗口占比0.93。
参见图4，窗口复查流程：
s401、本申请实施例中，在系统开机时，可以预先在wms中注册名称为com.window.recheck的广播监听，当收到该名称的广播时，则启动窗口复查流程。
s402、窗口复查流程开始，首先获取广播参数(floatingwindow和窗口占比0.93)，可以得到要查询的窗口名称floatingwindow和该窗口的初始窗口占比(即原窗口占比)0.93。
s403、在wms中，查询名为floatingwindow的窗口现在的大小，并与实际屏幕再算出一个新的窗口占比。
s404、判断窗口占比是否发生变化，若是，则执行步骤s405，否则执行步骤s407。
s405、若新的窗口占比发生变化，则更新新的窗口占比到第一标记位的sys.topwindow.pkg中，并退出窗口复查流程。
s406、若新的窗口占比，跟第一标记位中记录的原窗口占比相同，则认为当前悬浮窗口出现异常，即当前运行的应用的显示界面的窗口不能及时变小或消失，需要发起清理广播。在wms中查询floatingwindow所属的应用包名，例如是com.test.floatingtest。
s407、发送清理广播，广播名比如是com.window.clear，携带参数com.test.floatingtest，即携带需要清理的应用的名称。
清理流程：
清理模块(比如systemui)收到com.window.clear广播后，获取其参数com.test.floatingtest，而后调用系统接口，将com.test.floatingtest包名对应的所有进程全部删除。清理完成。
由于系统现有技术中，只要清理掉一个应用的所有进程，其所创建的所有窗口也都会跟着被销毁。因此，经过清理流程后，应用遮挡的界面就会被自动销毁，遮挡问题也就没有了。现有技术中存在的问题至此得到了解决。
综上所述，参见图5，本申请实施例提供的一种显示设备，包括：
存储器21，用于存储程序指令；
处理器22，用于调用所述存储器中存储的程序指令，按照获得的程序执行：
确定当前运行的应用的显示界面为悬浮窗；
接收用户对所述悬浮窗进行的关于更改窗口大小的操作；例如，该操作可以是触摸操作，也可以是用户利用其它设备(例如鼠标或遥控器等)对悬浮窗进行操作；
若所述悬浮窗的窗口大小在所述操作之后未发生变化，则清理所述应用的进程。
其中，关于更改窗口大小的操作，例如是点击(可以是一次或连续多次点击)缩小窗口的按键，或者是点击(可以是一次或连续多次点击)关闭窗口的按键等。
因此，本申请实施例提供的显示设备通过当悬浮窗的窗口大小在用户进行了关于更改窗口大小的操作之后未发生变化时，清理应用的进程，实现了对全屏窗口显示界面的异常检测，从而消除异常，保证用户及时对显示界面进行准确操作。
可选地，所述悬浮窗的类型为覆盖类型。
所述覆盖类型，例如前面所述的type_application_overlay类型。
可选地，所述操作为连续点击操作，例如用户连续点击三次关闭悬浮窗按键的操作。
可选地，若所述悬浮窗的窗口大小在所述操作之后未发生变化，则清理所述应用的进程，具体包括：
若所述悬浮窗的窗口大小在用户连续点击预设次数之后未发生变化，则清理所述应用的进程。例如，用户连续点击关闭悬浮窗按键的操作超过三次，则认为出现异常，需要清理该悬浮窗对应的应用进程。
具体地，例如上述实施例中所述的，若悬浮窗的窗口占比大于预设值，则记录该悬浮窗的名称和所述窗口占比；当用户连续点击所述悬浮窗的次数超过预设值时，重新确定该悬浮窗的窗口占比；若重新确定的窗口占比与之前记录的窗口占比一致，则清理该悬浮窗对应的应用的所有进程。
当然，也可以仅根据窗口大小，判断是否清理应用进程，无需计算窗口占比。例如，仅计算悬浮窗的窗口大小，当用户连续点击该悬浮窗的次数达到预设次数时，若该悬浮窗的窗口大小未发生变化，则清理所述应用的进程。
可选地，参见图6，所述处理器22包括：
窗口管理服务模块11，用于将用户对所述悬浮窗的操作输出至日志；
行为管理服务模块12，用于分析所述日志，并判断连续点击操是否达到预设次数。
其中，窗口管理服务模块11，例如前面所述的wms模块。
行为管理服务模块12，例如前面所述的ams模块。
可选地，所述行为管理服务模块12通过广播的方式通知所述窗口管理服务模块11重新确定所述悬浮窗的窗口大小。
参见图7，本申请实施例提供的一种显示设备的处理方法，包括以下步骤：
s101、确定当前运行的应用的显示界面为悬浮窗；
s102、接收用户对所述悬浮窗进行的关于更改窗口大小的操作；
s103、若所述悬浮窗的窗口大小在所述操作之后未发生变化，则清理所述应用的进程。
可选地，所述操作为连续点击操作。
可选地，若所述悬浮窗的窗口大小在所述操作之后未发生变化，则清理所述应用的进程，具体包括：
若所述悬浮窗的窗口大小在用户连续点击预设次数之后未发生变化，则清理所述应用的进程。
需要说明的是，本申请实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。另外，在本申请各个实施例中的各功能模块可以集成在一个处理单元中，也可以是各个模块单独物理存在，也可以两个或两个以上模块集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
所述集成的模块如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(processor)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(read-onlymemory，rom)、随机存取存储器(randomaccessmemory，ram)、磁碟或者光盘等各种可以存储程序代码的介质。
本申请实施例提供的显示设备，具体可以为电视机、桌面计算机、便携式计算机、智能手机、平板电脑、个人数字助理(personaldigitalassistant，pda)等。显示设备可以包括中央处理器(centerprocessingunit，cpu)、存储器、输入/输出设备等，输入设备可以包括键盘、鼠标、触摸屏等，输出设备例如液晶显示器(liquidcrystaldisplay，lcd)、阴极射线管(cathoderaytube，crt)等。
存储器可以包括只读存储器(rom)和随机存取存储器(ram)，并向处理器提供存储器中存储的程序指令和数据。在本申请实施例中，存储器可以用于存储本申请实施例提供的任一所述方法的程序。
处理器通过调用存储器存储的程序指令，处理器用于按照获得的程序指令执行本申请实施例提供的任一所述方法。
本申请实施例提供了一种计算机存储介质，用于储存为上述本申请实施例提供的装置所用的计算机程序指令，其包含用于执行上述本申请实施例提供的任一方法的程序。
所述计算机存储介质可以是计算机能够存取的任何可用介质或数据存储设备，包括但不限于磁性存储器(例如软盘、硬盘、磁带、磁光盘(mo)等)、光学存储器(例如cd、dvd、bd、hvd等)、以及半导体存储器(例如rom、eprom、eeprom、非易失性存储器(nandflash)、固态硬盘(ssd))等。
上述方法处理流程可以用软件程序实现，该软件程序可以存储在存储介质中，当存储的软件程序被调用时，执行上述方法步骤。
本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器和光学存储器等)上实施的计算机程序产品的形式。
本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。
1.一种显示设备，其特征在于，包括：
存储器，用于存储程序指令；
处理器，用于调用所述存储器中存储的程序指令，按照获得的程序执行：
确定当前运行的应用的显示界面为悬浮窗；
接收用户对所述悬浮窗进行的关于更改窗口大小的操作；
若所述悬浮窗的窗口大小在所述操作之后未发生变化，则清理所述应用的进程。
2.根据权利要求1所述的显示设备，其特征在于，所述悬浮窗的类型为覆盖类型。
3.根据权利要求1或2所述的显示设备，其特征在于，所述操作为连续点击操作。
4.根据权利要求3所述的显示设备，其特征在于，若所述悬浮窗的窗口大小在所述操作之后未发生变化，则清理所述应用的进程，具体包括：
若所述悬浮窗的窗口大小在用户连续点击预设次数之后未发生变化，则清理所述应用的进程。
5.根据权利要求4所述的显示设备，其特征在于，所述处理器包括：
窗口管理服务模块，用于将用户对所述悬浮窗的操作输出至日志；
行为管理服务模块，用于分析所述日志，并判断连续点击操是否达到预设次数。
6.根据权利要求5所述的显示设备，其特征在于，所述行为管理服务模块通过广播的方式通知所述窗口管理服务模块重新确定所述悬浮窗的窗口大小。
7.一种显示设备的处理方法，其特征在于，包括以下步骤：
确定当前运行的应用的显示界面为悬浮窗；
接收用户对所述悬浮窗进行的关于更改窗口大小的操作；
若所述悬浮窗的窗口大小在所述操作之后未发生变化，则清理所述应用的进程。
8.根据权利要求7所述的方法，其特征在于，所述操作为连续点击操作。
9.根据权利要求8所述的方法，其特征在于，若所述悬浮窗的窗口大小在所述操作之后未发生变化，则清理所述应用的进程，具体包括：
若所述悬浮窗的窗口大小在用户连续点击预设次数之后未发生变化，则清理所述应用的进程。
10.一种计算机存储介质，其特征在于，所述计算机存储介质存储有计算机可执行指令，所述计算机可执行指令用于使所述计算机执行权利要7至9任一项所述的方法。
技术总结