卡顿确定方法、装置及终端与流程

本发明实施例涉及计算机领域，特别涉及一种卡顿确定方法、装置及终端。

背景技术：

卡顿是指在终端运行的过程中画面滞帧的现象。比如：在终端运行游戏程序时，在一段时间内不再刷新用户界面(userinterface，ui)的图像帧，导致终端显示的游戏画面停滞。通常卡顿是由于终端中的用户界面线程在执行耗时操作引起的，比如：用户界面线程发起一条网络请求，且服务器未立即响应该网络请求。

为了提高终端运行程序的流畅度，操作系统需要确定终端是否存在卡顿；并在确定出存在卡顿时，创建子线程来执行用户界面线程执行的耗时操作，从而解决该卡顿。其中，用户界面线程具有对用户界面进行刷新的功能，子线程是指通过用户界面线程创建的线程。

目前操作系统确定卡顿的方法中，操作系统消耗的资源较大。

技术实现要素：

为了解决操作系统在确定卡顿时消耗的资源较大的问题，本发明实施例提供了一种卡顿确定方法、装置及终端。所述技术方案如下：

第一方面，提供了一种卡顿确定方法，所述方法包括：

确定处理组件是否为用户界面线程创建的组件，所述处理组件用于处理消息队列中的至少一条消息，所述用户界面线程具有对用户界面进行刷新的功能；

在所述处理组件是由所述用户界面线程创建的组件时，获取所述消息队列中至少一条消息对应的处理耗时；

在所述处理耗时大于预设时长时，确定存在卡顿。

第二方面，提供了一种卡顿确定装置，所述装置包括：

第一确定模块，用于确定处理组件是否为用户界面线程创建的组件，所述处理组件用于处理消息队列中的至少一条消息，所述用户界面线程具有对用户界面进行刷新的功能；

获取模块，用于在所述处理组件是由所述用户界面线程创建的组件时，获取所述消息队列中至少一条消息对应的处理耗时；

第二确定模块，用于在所述处理耗时大于预设时长时，确定存在卡顿。

第三方面，提供了一种终端，所述终端包括：处理器、与所述处理器相连的存储器，以及存储在所述存储器上的程序指令，所述处理器执行所述程序指令时实现如第一方面所述的卡顿确定方法。

第四方面，一种计算机可读介质，其上存储有程序指令，所述程序指令被处理器执行时实现如第一方面所述的卡顿确定方法。

本发明实施例提供的技术方案带来的有益效果是：

通过确定处理组件是否为用户界面线程创建的组件；若是，则获取该消息对应的处理耗时，在该处理耗时大于预设时长时，确定终端存在卡顿；解决了操作系统在确定是否存在卡顿时消耗的资源过多的问题；由于终端的卡顿是由于用户界面线程处理耗时操作造成的，而在用户界面线程处理耗时操作时，消息对应的处理耗时较长，因此，在处理组件是由用户界面线程创建的组件时，获取该处理组件处理的消息对应的处理耗时，该处理耗时能够反映终端是否存在卡顿，无需获取所有处理组件处理的消息对应的处理耗时；既保证了确定终端是否存在卡顿的准确性，又节省了确定终端是否存在卡顿时消耗的资源。

附图说明

为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本发明一个实施例提供的消息处理机制的示意图；

图2是本发明一个实施例提供的卡顿确定方法的流程图；

图3是本发明另一个实施例提供的卡顿确定方法的流程图；

图4是本发明一个实施例提供的卡顿确定装置的结构方框图；

图5是本发明一个实施例提供的终端的结构示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明实施方式作进一步地详细描述。

首先，对本申请涉及的若干个名词进行介绍。

用户界面线程(或称：主线程)：具有对用户界面进行刷新的功能。

可选地，用户界面线程也可以执行与用户界面刷新无关的操作，比如：读写操作、查询数据库操作等。

可选地，用户界面线程是操作系统通过入口方法开始执行程序时创建的线程。

子线程(或称：非用户界面线程、非主线程)：通过用户界面线程创建的线程。示意性地，在用户界面线程运行时，操作系统在用户界面线程中创建子线程。

可选地，当用户界面线程执行耗时操作时，操作系统会创建子线程来执行该耗时操作，避免终端通过用户界面线程执行该耗时操作造成用户界面线程阻塞，终端卡顿的问题。

可选地，用户界面线程中创建的子线程与该用户界面线程同时工作。

消息(message)：操作系统需要执行某一操作时生成的消息，线程通过执行该消息来完成操作系统需要执行的操作。比如：终端接收到用户输入的单击操作时，操作系统根据该单击操作生成消息1，线程通过执行消息1执行界面刷新操作。其中，线程为用户界面线程或子线程。

可选地，操作系统生成消息后，调用处理组件将该消息发送至该处理组件对应的线程的消息队列中，在该消息队列中等待被该处理组件处理。

可选地，消息具有供不同的线程之间进行通信的功能。比如：用户界面线程创建的处理组件将该子线程的消息队列中的消息发送至用户界面线程的消息队列，用户界面线程创建的处理组件通过执行该消息实现用户界面的刷新。

可选地，在某些实施例中，消息也可称为系统消息、队列化消息、队列消息等，本实施例不对消息的具体名称作限定。

通过上述消息处理机制，驱动了操作系统中各个程序的运行。

处理组件：线程创建出的类，处理组件用于将操作系统生成的消息发送至该处理组件对应的消息队列，并对该消息队列中的消息按序进行处理。

示意性地，处理组件为安卓(android)操作系统和windows操作系统中的处理者(handler)。

可选地，每个线程对应一个处理组件，不同的线程对应的处理组件不同。换句话说，线程与处理组件是一一对应的关系。

可选地，在某些实施例中，处理组件也可称为绘制函数，本实施例不对处理组件的具体名称作限定。

消息队列(messagequeue)：线程创建的用于存储消息的链表。消息队列符合“先进先出”原则，即，先入队的消息先出队被处理组件处理。

可选地，每个线程对应一个消息队列，不同的线程对应的消息队列不同。换句话说，线程与消息队列是一一对应的关系。

可选地，本申请中，终端可以是手机、平板电脑、可穿戴电子设备、电子书阅读器、mp3(movingpictureexpertsgroupaudiolayeriii，动态影像专家压缩标准音频层面3)播放器、mp4(movingpictureexpertsgroupaudiolayeriv，动态影像专家压缩标准音频层面4)播放器和膝上型便携计算机等。终端中存储有至少一段程序，该程序是指一段静态代码。

可选地，操作系统为windows操作系统，或者为安卓操作系统等其他操作系统。

为了更清楚地理解消息的处理机制，下面以安卓操作系统为例对消息处理机制进行介绍。

图1是本发明的一个示例性实施例示出的终端的操作系统中的消息处理机制的示意图。操作系统中的消息处理机制至少由四个部分完成，这四个部分分别为：消息110、处理组件120、消息队列130和循环体(looper)140。

假设处理组件120、消息队列130和循环体140是用户界面线程1创建的。

操作系统生成消息110，调用处理组件120将该消息110发送至消息队列130。

可选地，消息队列中的消息110也可以通过子线程创建的处理组件发送至该子线程对应的消息队列中；或者，子线程对应的消息队列中的消息也可以通过用户界面线程1创建的处理组件120发送至消息队列130。

消息队列130存储处理组件120发送的消息110。消息队列130中的消息110符合“先进先出”原则。

消息队列130中的消息110处于等待被处理的状态。

循环体140在确定出消息队列130中存储有消息110时，每次从消息队列130中取出一条消息110，将该消息110传递给处理组件120处理。

可选地，每个线程包括一个循环体，不同的线程对应的不同的循环体，即，线程与循环体为一一对应的关系。

可选地，本申请中，以各个实施例的执行主体为处理组件为例进行说明。

基于图1所示的消息处理机制，若操作系统中除了用户界面线程之外，还包括多个子线程，且每个线程对应一个消息队列130，操作系统需要获取所有消息队列中每个消息的处理耗时，根据该处理耗时确定终端是否存在卡顿，在消息的数量较多时，终端会消耗大量的资源来确定是否存在卡顿。基于上述技术问题，本申请提供如下技术方案来节省终端的资源。

图2是本发明的一个示例性实施例示出的卡顿确定方法的方法流程图。该卡顿确定方法包括：

步骤201，确定处理组件是否为用户界面线程创建的组件。

可选地，处理组件在处理消息时，确定该处理组件是否为用户界面线程创建的组件。

其中，消息来源于处理组件对应的消息队列，由该消息队列对应的循环体从该消息队列中取出并递交至处理组件。

可选地，消息包括：用于刷新用户界面的消息；和/或，用于供不同的线程进行通信的消息；和/或，用于实现后台操作的消息。

线程在创建处理组件时，会在该处理组件中生成记录信息，该记录信息至少包括该线程的标识，处理组件通过获取该记录信息得到线程的标识，比较该线程的标识是否与用户界面线程的标识相同，来确定处理组件是否为用户界面线程创建的组件。

处理组件确定是否为用户界面线程创建的组件，包括：获取创建处理组件的线程对应的第一线程标识；若第一线程标识与用户界面线程的第二线程标识相同，则确定处理组件是由用户界面线程创建的组件。

可选地，第一线程标识和第二线程标识为线程的名称和线程的身份标识(identity，id)中的至少一种。

可选地，处理组件通过信息获取接口获取线程在创建该处理组件时生成的记录信息。信息获取接口操作系统提供的通用接口。

比如：信息获取接口为thread.currentthread.getname。其中，currentthread表示获取创建处理组件的线程；getname表示获取该线程的名称。第二线程标识为main，则确定处理组件是否为用户界面线程创建的组件可表示为：a.equals(b)。其中，equals表示a与b进行比较。

参考图1，对于用户界面线程1对应的消息队列130中的消息110，循环体140取出该消息110发送给处理组件120，处理组件120获取该消息110后，确定创建该处理组件120的线程是否为用户界面线程。

可选地，本步骤也可以在循环体对从消息队列中取消息时由循环体执行，本实施例对此不作限定。

可选地，当处理组件确定出该处理组件是用户界面线程创建的组件时，执行步骤202；当处理组件确定出该处理组件不是用户界面线程创建的组件时，本次确定终端是否存在卡顿的流程结束。

步骤202，在处理组件是由用户界面线程创建的组件时，获取消息队列中至少一条消息对应的处理耗时。

在处理组件是由用户界面线程创建的组件时，处理组件处理的消息来源于用户界面线程对应的消息队列。

可选地，用户界面线程对应的消息队列中的消息主要用于刷新用户界面。当然，用户界面线程对应的消息队列中的消息也可以用于实现后台操作，本实施例对此不作限定。

可选地，用户界面线程对应的消息队列中的消息可以是子线程发送的，此时，该消息还具有供不同的线程间进行通信的功能。

可选地，用户界面线程对应的消息队列中的消息可以是操作系统根据用户操作生成的。比如：操作系统根据用户执行的点击操作生成消息，由用户界面线程对应的处理组件将该消息发送至用户界面线程对应的消息队列。

终端的卡顿通常是在用户界面线程执行耗时操作时产生的，比如：用户界面线程用于发起一条网络请求时，服务器未立即响应该请求，此时，若该耗时操作由子线程来处理，则终端通常不会产生卡顿。

子线程在执行耗时操作时，子线程对应的处理组件处理该子线程对应的消息队列中的消息的耗时较长。然而，子线程执行耗时操作并不会造成终端的卡顿，因此，即使处理组件获取到消息对应的处理耗时，该处理耗时也无法反映出终端是否存在卡顿。

用户界面线程在执行耗时操作时，用户界面线程对应的处理组件处理该用户界面线程对应的消息队列中的消息的耗时较长，而用户界面线程执行耗时操作会造成终端的卡顿，因此，通过在处理组件是用户界面线程创建的组件时，获取消息对应的处理耗时，该处理耗时能够反映出终端是否存在卡顿，提高了终端通过消息对应的处理耗时来确定终端是否存在卡顿的准确性。

由于终端无需获取所有消息对应的处理耗时，也无需根据所有消息对应的处理耗时来确定终端是否存在卡顿，节省了操作系统确定终端是否存在卡顿时消耗的资源。

可选地，本步骤中，处理组件可以在每次处理一条消息结束时获取该消息对应的处理耗时；或者，也可以在处理预设条数的消息结束时，获取该预设条数的消息对应的处理耗时；或者，也可以在处理消息队列中的所有消息结束时，获取所有消息对应的处理耗时，本实施例对此不作限定。

处理耗时是第一时刻至第二时刻经过的时长。

可选地，第一时刻是处理组件将消息发送至消息队列时的时刻，第二时刻是处理组件处理消息结束时的时刻。此时，处理耗时包括消息对应的两个阶段的耗时，第一个阶段是消息在消息队列中等待的耗时；第二个阶段是处理组件处理该消息的耗时。

可选地，第一时刻是处理组件将消息发送至消息队列时的时刻，第二时刻是循环体从消息队列中取出消息时的时刻。此时，处理耗时为消息在消息队列中等待的耗时。

可选地，第一时刻是循环体将消息发送至处理组件的时刻，第二时刻是处理组件处理消息结束时的时刻。此时，处理耗时为处理组件处理该消息的耗时。

步骤203，在处理耗时大于预设时长时，确定存在卡顿。

若终端不存在卡顿，此时，消息对应的处理耗时通常小于或等于预设时长；若终端存在卡顿，此时，消息对应的处理耗时通常大于预设时长时。因此，通过确定消息对应的处理耗时与预设时长之间的大小，能够反映出终端是否存在卡顿。

可选地，本步骤中，处理组件可以在处理一条消息结束后，根据该条消息对应的处理耗时确定是否存在卡顿；或者，处理组件可以在处理预设条数的消息结束后，根据预设条数的消息对应的处理耗时的平均值来确定是否存在卡顿；或者，处理组件还可以在处理消息队列中的所有消息结束后，根据所有消息对应的处理耗时的平均值来确定是否存在卡顿。

可选地，本步骤之前，处理组件检测消息对应的处理耗时是否大于预设时长，若检测出处理耗时大于预设时长，则执行本步骤。

本实施例不对预设时长的取值作限定，示意性地，预设时长为16.67ms。

综上所述，本实施例提供的卡顿确定方法，通过确定处理组件是否为用户界面线程创建的组件；若是，则获取该消息对应的处理耗时，在该处理耗时大于预设时长时，确定终端存在卡顿；解决了操作系统在确定是否存在卡顿时消耗的资源过多的问题；由于终端的卡顿是由于用户界面线程处理耗时操作造成的，而在用户界面线程处理耗时操作时，消息对应的处理耗时较长，因此，在处理组件是由用户界面线程创建的组件时，获取该处理组件处理的消息对应的处理耗时，该处理耗时能够反映终端是否存在卡顿，无需获取所有处理组件处理的消息对应的处理耗时；既保证了确定终端是否存在卡顿的准确性，又节省了确定终端是否存在卡顿时消耗的资源。

可选地，处理组件确定出终端存在卡顿之后，创建子线程来执行用户界面线程执行的耗时操作。

可选地，处理组件确定出终端存在卡顿之后，继续根据下一条消息对应的处理耗时，确定终端是否存在卡顿；即，再次执行步骤201至203。

可选地，在上述实施例中，处理组件获取消息队列中至少一条消息对应的处理耗时，包括：获取处理组件向消息队列发送消息时的第一时刻；获取处理组件处理消息结束时的第二时刻；根据第一时刻和第二时刻，确定消息对应的处理耗时。

在相关技术中，处理组件将开始处理消息的时刻作为第一时刻，此时，处理组件仅能获取到该处理组件处理消息的耗时，并未考虑消息在消息队列中等待的耗时。由于终端产生卡顿时，处理组件处理消息的耗时可能仍旧处于正常范围内，因此，仅根据处理组件处理消息的耗时来确定终端是否存在卡顿并不准确。

而在本实施例中，处理组件获取到的第一时刻是该处理组件将消息发送至消息队列中的时刻，此时，处理组件获取到消息的对应处理耗时既包括消息在消息队列中的等待的耗时，又包括处理组件处理该消息的耗时。由于终端产生卡顿时，消息在消息队列中等待的耗时较长，因此，即使处理组件处理该消息的耗时处于正常范围内，由于该消息在消息队列中等待的耗时较长，该消息对应的处理耗时也会超过正常范围，即，消息对应的处理耗时大于预设时长，提高了确定终端是否存在卡顿的准确性。

可选地，第一时刻是处理组件发送消息时记录的时刻。此时，在步骤201之前，处理组件向消息队列发送消息时，调用时间记录接口记录第一时刻；相应地，处理组件获取处理组件向消息队列发送消息时的第一时刻，包括：读取时间记录接口记录的第一时刻。

可选地，第二时刻是处理组件处理消息结束时记录的时刻。此时，步骤201之后，处理组件处理消息结束时，调用时间记录接口记录第二时刻；相应地，获取处理组件处理消息结束时的第二时刻，包括：读取时间记录接口记录的第二时刻。

可选地，处理组件将第一时刻作为消息的属性添加至该消息中。

比如：处理组件在向消息队列发送一条消息时，在该消息中添加当前时间，即，第一时刻。

第二时刻是处理组件在处理消息结束时记录的时间。

可选地，处理组件将第二时刻作为消息的属性添加至该消息中。

示意性地，时间记录接口为操作系统预先设置的打印接口。

可选地，处理组件读取时间记录接口记录的第一时刻和第二时刻。

可选地，处理组件根据第一时刻和第二时刻，确定消息的处理耗时，包括：将第二时刻减去第一时刻，得到处理耗时。

比如：消息的第一时刻为t1，第二时刻为t2，那么，该消息对应的处理耗时为t3＝t2-t1。

综上所述，本实施例提供的卡顿确定方法，通过根据消息对应的处理耗时确定终端是否存在卡顿，该处理耗时包括消息在消息队列中等待的耗时和处理组件处理该消息的耗时；解决了仅根据处理组件处理该消息的耗时来确定终端是否存在卡顿时，确定出的结果不够准确的问题；由于该处理耗时包括消息在消息队列中等待的耗时和处理组件处理该消息的耗时，因此，当终端实际存在卡顿时，即使处理耗时中的一种时长处于正常范围，操作系统也会由于另一种时长超出正常范围，而确定出终端存在卡顿，提高了确定终端是否存在卡顿的准确性。

可选地，操作系统可以将消息离开消息队列的时间，或者，循环体取出消息的时间确定为该消息的第二时刻，这样，操作系统能够获取到消息在消息队列中等待的耗时，并根据该等待的耗时确定终端是否存在卡顿。

为了更清楚地理解本发明实施例提供的卡顿确定方法，下面结合一实例对该卡顿确定方法进行说明。

图3是本发明的一个示例性实施例示出的卡顿确定方法的方法流程图，该方法包括以下几个步骤：

步骤301，在操作系统需要对用户界面刷新操作时，操作系统生成消息；

处理组件通过执行该消息实现用户界面的刷新。

操作系统需要进行用户界面刷新的场景包括但不限于以下几种：

第一种：操作系统接收到用户输入的界面刷新指令；

第二种：操作系统中当前运行的程序调用了另一程序；

第三种：操作系统定时对用户界面进行刷新。

步骤302，处理组件向用户界面线程对应的消息队列发送消息。

处理处理是用户界面线程创建的。

步骤303，处理组件调用时间记录接口记录处理组件发送消息的第一时刻。

步骤304，循环体检测消息队列是否为空；若为空，则重新执行本步骤；若不为空，则执行步骤305。

循环体在从消息队列中取消息之前，会检测该消息队列是否为空；若为空，说明消息队列中未存储有消息，此时，循环体继续对消息队列进行监控，即，继续检测消息队列是否为空；若不为空，说明消息队列中存储有至少一条消息，此时，执行步骤305。

步骤305，循环体从消息队列中取出该消息队列中的第一条消息，并将该第一条消息从消息队列中移除。

消息队列符合“先进先出”规则，消息队列中的第一条消息是最先进入该消息队列的消息，因此，循环体取出该第一条消息的。

步骤306，循环体将第一条消息递交至处理组件，处理组件处理该第一条消息。

步骤307，处理组件检测该处理组件是否为用户界面线程创建的；若是，则执行步骤308；若否，则流程结束。

步骤308，处理组件通过时间记录接口记录该处理组件处理消息结束时的第二时刻。

步骤309，处理组件根据第一时刻和第二时刻，确定消息对应的处理耗时。

步骤310，处理组件检测处理耗时是否大于预设时长；若是，则执行步骤311；若否，则执行步骤312。

步骤311，处理组件确定终端存在卡顿，流程结束。

步骤312，处理组件确定终端不存在卡顿。

需要补充说明的是，步骤307可以在步骤304至306之间的任一时机执行，本实施例不对步骤307的执行时机作限定。

下述为本发明装置实施例，可以用于执行本发明方法实施例。对于本发明装置实施例中未披露的细节，请参照本发明方法实施例。

请参考图4，其示出了本发明一个实施例提供的卡顿确定装置的结构方框图，该卡顿确定装置可通过软件、硬件或者两者的结合实现成为终端的部分或者全部。该卡顿确定装置可以包括：第一确定模块410、获取模块420和第二确定模块430。

第一确定模块410，用于确定处理组件是否为用户界面线程创建的组件，处理组件用于处理消息队列中的至少一条消息，用户界面线程具有对用户界面进行刷新的功能；

获取模块420，用于在处理组件是由用户界面线程创建的组件时，获取消息队列中至少一条消息对应的处理耗时；

第二确定模块430，用于在处理耗时大于预设时长时，确定存在卡顿。

可选地，第一确定模块410，包括：第一获取单元和第一确定单元。

第一获取单元，用于获取创建处理组件的线程对应的第一线程标识，线程为用户界面线程或子线程，子线程是指通过用户界面线程创建的线程；

第一确定单元，用于在第一线程标识与用户界面线程的第二线程标识相同时，确定处理组件是由用户界面线程创建的组件。

可选地，获取单元，还用于：通过信息获取接口获取线程在创建处理组件时生成的记录信息，记录信息包括第一线程标识。

可选地，获取模块420，包括：第二获取单元、第三获取单元和第二确定单元。

第二获取单元，用于获取处理组件向消息队列发送消息时的第一时刻；

第三获取单元，用于获取处理组件处理消息结束时的第二时刻；

第二确定单元，用于根据第一时刻和第二时刻，确定消息对应的处理耗时。

可选地，该装置还包括：第一调用模块。

第一调用模块，用于在处理组件向消息队列发送消息时，调用时间记录接口记录第一时刻；

第二获取单元，用于读取时间记录接口记录的第一时刻。

可选地，该装置还包括：第二调用模块。

第二调用模块，用于在处理组件处理消息结束时，调用时间记录接口记录第二时刻；

第三获取单元，用于读取时间记录接口记录的第二时刻。

相关细节参见上述方法实施例。

图5示出了本发明一个示例性实施例所涉及的终端的结构示意图。该终端包括：该终端包括：处理器511、接收器512、发射器513、存储器514和总线515。

处理器511包括一个或者一个以上处理核心，存储器514通过总线515与处理器511相连，存储器514用于存储程序指令，处理器511执行存储器514中的程序指令时实现上述方法实施例中卡顿确定方法。

接收器512和发射器513可以实现为一个通信组件，该通信组件可以是一块通信芯片，用于对信息进行调制和/或解调，并通过无线信号接收或发送该信息。

此外，存储器514可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随时存取存储器(sram)，电可擦除可编程只读存储器(eeprom)，可擦除可编程只读存储器(eprom)，可编程只读存储器(prom)，只读存储器(rom)，磁存储器，快闪存储器，磁盘或光盘。

上述结构示意仅为对终端的示意性说明，终端可以包括更多或更少的部件，比如终端可以不包括发送器，或者，终端还包括传感器、显示屏、电源等其它部件，本实施例不再赘述。

本发明实施例还提供一种计算机可读介质，其上存储有程序指令，程序指令被处理器511执行时实现上述方法实施例中的卡顿确定方法。

上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。

本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。

以上所述仅为本申请的较佳实施例，并不用以限制本申请，凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。