CN110955510A - 一种隔离处理方法以及相关装置 - Google Patents

Abstract

本申请实施例公开了一种隔离处理方法以及相关装置，用于在同一个目标应用中，通过切换第一容器和第二容器之间的状态，从而利用挂起态和激活态间的切换来避免第一容器和第二容器分别所对应的第一引擎、第二引擎的运行冲突，为后续多团队之间利用彼此具备优势的引擎合研目标应用提供了便捷。本申请实施例提供的隔离处理方法包括：在目标应用的第一场景下获取第一切换指令，第一场景是基于第一引擎运行的，第一引擎对应的第一容器处于激活态，第一切换指令用于指示从第一场景切换到目标应用的第二场景；根据第一切换指令，将第一容器的状态由激活态切换到挂起态，并将第二容器的状态由挂起态切换到激活态，第二容器与运行第二场景的第二引擎对应。

Description

一种隔离处理方法以及相关装置

技术领域

本申请实施例涉及计算机技术领域，具体涉及一种隔离处理方法以及相关装置。

背景技术

引擎，是指一些已经编写好的可编辑系统或者一些交互式实时图像应用程序的核心组件，这些系统能够为系统开发者提供各种编写应用所需的各种工具，其目的在于让系统开发者容易且快速地开发出应用。

目前，在视窗(Windows)操作系统上，可以较容易的使用多进程来开发同一款应用程序，从而可以使用不同的进程有效地避免引擎间的冲突。但对于移动设备的操作系统来说，比如现阶段主流的IOS(internetworking operating system-cisco)操作系统、安卓(android)操作系统等，用户通常希望在同一个应用程序就可以体验到该应用程序中所包括的所有功能，由于应用程序讲究独立性，因此移动设备的操作系统无法像Windows操作系统使用多个进程来开发出一个应用程序。而随着多公司多团队进行产品“合作研发”的场景日益增加，每个团队都可以利用自身具备优势的引擎进行开发同一个应用程序，但是，在利用不同团队的引擎在合研开发同一个应用程序时，往往由于不同的引擎之间在运行过程中都会存在一定的冲突性，导致无法研发出应用程序。

因此，在利用不同的引擎合作研发同一个应用程序时，如何避免不同的引擎之间的冲突问题，是现阶段以及未来亟需解决的问题。

发明内容

本申请实施例提供了一种隔离处理方法以及相关装置，用于在同一个目标应用中，通过第一切换指令来切换第一容器和第二容器之间的状态，从而利用挂起态和激活态间的切换来避免第一容器和第二容器分别所对应的第一引擎、第二引擎之间的运行冲突，为后续多团队之间利用彼此具备优势的引擎合作研发同一个目标应用提供了便捷。

第一方面，本申请实施例提供了一种隔离处理方法，包括：

在目标应用的第一场景下获取第一切换指令，第一场景是基于第一引擎运行的，第一引擎对应的第一容器处于激活态，第一容器包含第一引擎运行的元素，第一切换指令用于指示从第一场景切换到目标应用的第二场景；

根据第一切换指令，将第一容器的状态由激活态切换到挂起态，并将第二容器的状态由挂起态切换到激活态，第二容器与运行第二场景的第二引擎对应，第二容器包含第二引擎运行的元素。

第二方面，本申请实施例提供了一种隔离处理装置，包括：

第一获取单元，用于在目标应用的第一场景下获取第一切换指令，第一场景是基于第一引擎运行的，第一引擎对应的第一容器处于激活态，第一容器包含第一引擎运行的元素，第一切换指令用于指示从第一场景切换到目标应用的第二场景；

第一切换单元，用于根据第一获取单元获取到的第一切换指令，将第一容器的状态由激活态切换到挂起态，并将第二容器的状态由挂起态切换到激活态，第二容器与运行第二场景的第二引擎对应，第二容器包含第二引擎运行的元素。

可选地，结合上述第二方面，在第一种可能的实现方式中，隔离处理单元还包括：

第二获取单元，用于在第一切换单元将第一容器的状态由激活态切换到挂起态，并将第二容器的状态由挂起态切换到激活态之后，在第二场景下获取第二切换指令，第二切换指令用于指示从第二场景切换到目标应用的第三场景；

第二切换单元，用于根据第二获取单元获取到的第二切换指令，将第二容器的状态由激活态切换到挂起态，并将第一容器的状态由挂起态切换到激活态，其中，第三场景是基于状态由挂起态切换到激活态的第一容器对应的第一引擎运行的。

可选地，结合上述第二方面，在第二种可能的实现方式中，隔离处理装置还包括：

触发单元，用于在第二切换单元将第二容器的状态由激活态切换到挂起态时，触发保活机制，保活机制用于指示共享模块的状态为激活态，共享模块在第三场景和第二场景下被对应的第一引擎和第二引擎共用，共享模块独立于第一容器和第二容器。

可选地，结合上述第二方面第一种可能的实现方式，在第三种可能的实现方式中，隔离处理装置还包括：

第一触发单元，用于在第一切换单元将第一容器的状态由激活态切换到挂起态时，触发保活机制，保活机制用于指示共享模块的状态为激活态，共享模块在第一场景和第二场景下被对应的第一引擎和第二引擎共用，共享模块独立于第一容器和第二容器。

可选地，结合上述第二方面、第二方面第一种至第三种可能的实现方式，在第四种可能的实现方式中，第一获取单元，包括：

第一响应模块，用于响应第一场景下的用户操作，以获取第一切换指令。

可选地，结合上述第二方面、第二方面第一种至第三种可能的实现方式，在第五种可能的实现方式中，第一获取单元，包括：

第一获取模块，用于在第一引擎运行第一场景的运行时长大于或等于第一预设时长时，获取第一切换指令。

可选地，结合上述第二方面第一种至第二种可能的实现方式，在第六种可能的实现方式中，第二获取单元，包括：

第二响应模块，用于响应第二场景下的用户操作，以获取第二切换指令。

可选地，结合上述第二方面第一种至第二种可能的实现方式，在第七种可能的实现方式中，第二获取单元，包括：

第二获取模块，用于在第二引擎运行第二场景的运行时长大于或等于第二预设时长时，获取第二切换指令。

可选地，结合上述第二方面、第二方面第一种至第七种可能的实现方式，在第八种可能的实现方式中，目标应用安装于移动终端。

可选地，结合上述第二方面、第二方面第一种至第八种可能的实现方式，在第九种可能的实现方式中，目标应用包括游戏应用。

本申请第三方面提供一种社交关系的确定装置，包括：处理器以及存储器，处理器以及存储器通过通信总线相连；其中，处理器，用于调用并执行存储器中存储的程序；存储器，用于存储程序，程序用于实现如上述第一方面或第一方面任意一种可能实现方式的方法。

本申请第四方面提供一种计算机可读存储介质，计算机可读存储介质中存储有计算机可执行指令，计算机可执行指令用于执行如第一方面或第一方面任意一种可能实现方式的方法。

本申请实施例的第五方面提供了一种包含指令的计算机程序产品，当其在计算机或处理器上运行时，使得计算机或处理器执行上述任一方面的方法。

从以上技术方案可以看出，本申请实施例具有以下优点：

本申请实施例中，由于第一容器与运行第一场景的第一引擎对应，并且包含第一引擎运行的元素，第二容器与运行第二场景的第一引擎对应，且包含第二引擎运行的元素，而第一场景与第二场景都属于同一个目标应用中的场景，所以在目标应用的第一场景下获取第一切换指令，使得可以根据该第一切换指令将第一容器的状态由激活态切换到挂起态，并将第二容器的状态由挂起态切换到激活态，这样便可以在同一个目标应用中，通过第一切换指令来切换第一容器和第二容器之间的状态，从而利用挂起态和激活态间的切换来避免第一容器和第二容器分别所对应的第一引擎、第二引擎之间的运行冲突，为后续多团队之间利用彼此具备优势的引擎合作研发同一个目标应用提供了便捷。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例。

图1是本申请实施例中隔离处理的系统架构示意图；

图2是本申请实施例中隔离处理方法的一个实施例示意图；

图3是本申请实施例中隔离处理方法的另一个实施例示意图；

图4是本申请实施例中容器与共享模块的关系示意图；

图5是本申请实施例中隔离处理方法的另一个实施例示意图；

图6是申请实施例中场景切换的示意图；

图7是本申请实施例中隔离处理方法的另一个实施例示意图；

图8是本申请实施例中提供的隔离处理装置一个实施例示意图；

图9是本申请实施例中提供的隔离处理装置另一个实施例示意图；

图10是本申请实施例提供的一种移动终端的结构示意图；

图11是本申请实施例提供的另一种移动终端的结构示意图。

具体实施方式

本申请实施例提供了一种隔离处理方法以及相关装置，用于在同一个目标应用中，通过第一切换指令来切换第一容器和第二容器之间的状态，从而利用挂起态和激活态间的切换来避免第一容器和第二容器分别所对应的第一引擎、第二引擎之间的运行冲突，为后续多团队之间利用彼此具备优势的引擎合作研发同一个目标应用提供了便捷。

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

本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。在本申请中出现的对步骤进行的命名或者编号，并不意味着必须按照命名或者编号所指示的时间/逻辑先后顺序执行方法流程中的步骤，已经命名或者编号的流程步骤可以根据要实现的技术目的变更执行次序，只要能达到相同或者相类似的技术效果即可。

下面对本申请实施例涉及的一些术语进行介绍：

容器：能够将引擎针对目标应用开发出的场景、模块等元素进行存储，从而为引擎提供一个独立的操作环境。

传统的隔离处理方法是在Windows操作系统上，针对同一款应用程序，通过调用不同的进程能够有效地避免引擎间的冲突。但对于移动设备的操作系统来说，希望能够在同一个应用程序中能够体验到该应用程序中所包括的全部的功能，而由于应用程序讲究独立性，所以在移动设备上无法像Windows操作系统使用多个进程的方式来开发出一个应用程序。例如：在某种游戏应用中，通常是由“登录场景”、“商城场景”、“匹配场景”、“对局场景”、“结算场景”等多个场景构成，而在Windows操作系统上，可以使用A进程来运行“登录场景”、B进程运行“商城场景”、C进程来运行“对局场景”、D进程运行“结算场景”等，而A进程又可以通过调用第一个APP来触发，B进程、D进程又可以调用第二个APP来触发，C进程又调用第三个APP来触发等，所以在Windows操作系统上会涉及到多个不同的APP之间的互相调用来完成该游戏。但在移动终端上，总是希望能够在下载该游戏应用后，就能够在该游戏应用中直接体验到“登录场景”、“商城场景”、“匹配场景”、“对局场景”、“结算场景”等多个场景，而不是下载多个APP来体验。

所以，随着多公司多团队进行产品“合作研发”的场景日益增加，针对同一个应用程序，每个团队都可以利用自身具备优势的引擎进行共同研发，但是，在利用不同团队的引擎在合研开发同一个应用程序时，往往由于不同的引擎之间在运行过程中都会存在一定的冲突性，导致无法研发出应用程序。

因此，为解决上述问题，本申请实施例提供了一种隔离处理方法，该方法应用于如图1所示的系统架构示意图，请参阅图1，为本申请实施例中隔离处理的系统架构示意图。从图1可以看出，针对同一个目标应用，该系统可以包括第一容器、第二容器，而第一容器又可以包含第一引擎运行的元素，第二引擎又可以包含第二引擎运行的元素，那么通过将第一容器的状态由激活态切换到挂起态，并且将第二容器的状态由挂起态切换到激活态，这样第二容器中所包含的第二引擎运行的元素都变成了激活态，而第一容器所包含的第一引擎所运行的元素都成了挂起态，保证了在第二容器处于激活态的时候该第一引擎无法工作，那么，这样便可以使用处于激活态的第二引擎运行该第二引擎所开发出的元素。同理，通过将第二容器的状态由激活态切换到挂起态，并且将第一容器的状态由挂起态切换到激活态，这样第一容器中所包含的第一引擎运行的元素都变成了激活态，而第二容器所包含的第二引擎所运行的元素都成了挂起态，保证了在第一容器处于激活态的时候该第二引擎无法工作，那么，这样便可以使用处于激活态的第一引擎运行该第一引擎所开发出的元素。

需要说明的是，上述所描述的目标应用可以安装在移动终端。而涉及到的移动终端可以包括各种具有无线通信功能的手持设备、车载设备、可穿戴设备、计算设备或连接到无线调制解调器的其他处理设备，以及各种形式的用户设备(user equipment，UE)，移动台(mobile station，MS)，终端设备(terminal device)等等。为方便描述，上面提到的设备统称为移动终端。

应当理解的是，上述所描述的容器针对不同的移动终端的操作系统会有所不同。例如：在IOS操作系统中，第一容器和第二容器可以是第一视图控制器(UIviewcontroller)容器和第二视图控制器容器，而在安卓操作系统中，第一容器和第二容器可以是第一控件容器(Activity)和第二控件容器。应当理解的是，在实际应用中，移动终端的操作系统除了安卓操作系统或IOS操作系统以外，还有可能包括其他的操作系统，因此在本申请实施例中将不限定第一容器与第二容器。

另外，上述所描述的目标应用包括但不限于游戏应用，在实际应用中，目标应用还可以是其他需要进行渲染的应用，在本申请实施例中将不做具体限定。本申请实施例中仅以游戏应用为例进行说明。

为便于更好地理解本申请实施例所提出的方案，下面将以移动终端的角度对本实施例中的具体流程进行介绍。其中，该移动终端中可以安装有前述所描述的目标应用，请参阅图2，为本申请实施例中隔离处理方法的一个实施例示意图，应用于移动终端，并可以由移动终端处理器进行执行，该方法可以包括：

201、在目标应用的第一场景下获取第一切换指令，第一场景是基于第一引擎运行的，第一引擎对应的第一容器处于激活态，第一容器包含第一引擎运行的元素，第一切换指令用于指示从第一场景切换到目标应用的第二场景。

本实施例中，第一场景与第二场景均属于同一个目标应用中的场景，而第一引擎可以运行第一场景，第二引擎可以运行第二场景。由于在目标应用的第一场景下，与运行第一场景的第一引擎相对应的第一容器处于激活态，那么就说明此时第一容器中所包含的第一引擎运行的元素都是处于激活态，那么此时可以由处于激活态的第一引擎来运行第一场景，如果想要切换到另外一个场景中，移动终端就可以在该第一场景下获取第一切换指令，该第一切换指令就会指示可以从第一场景切换到该第二场景。然而，为了避免不同引擎之间在运行过程中的冲突，移动终端就需要将运行第一场景的第一引擎变成挂起态，使得第一引擎在一定时间内无法工作，从而无法干扰处于状态由挂起态切换到激活态的第二引擎运行第二场景。

需要说明的是，相较于第二引擎运行上述的第一场景，第一引擎运行上述的第一场景会大大地提升运行速度，并且能够提升该第一场景的渲染质量等。另外，上述所描述的第一引擎是第一团队在研发上述第一场景时具备优势的引擎。同理，相较于第一引擎运行上述的第二场景，第二引擎运行上述的第二场景会大大地提升运行速度，并且能够提升该第二场景的渲染质量等。另外，上述所描述的第二引擎是第二团队在研发上述第二场景时具备优势的引擎。

应当理解的是，上述所描述的第一团队和第二团队是两个隶属于不同公司的团队，在本申请实施例中将不对团队的类型进行限定。

可选地，在一些实施例中，对于在目标应用的第一场景下获取第一切换指令可以采用如下方式：

第一种，响应第一场景下的用户操作，以获取第一切换指令。

在该实施例中，可以在第一场景中设置逻辑按钮等，若用户想要从第一场景切换到第二场景中，那么就可以直接在该第一场景中点击该逻辑按钮，这样移动终端便可以获取到该第一切换指令。

第二种，当第一引擎运行第一场景的运行时长大于或等于第一预设时长时，获取第一切换指令。

本实施例中，第一预设时长可以根据不同的需求进行设置，例如，可以设置为20秒，35秒等，在本申请实施例中将不做具体限定。只要处于激活态的第一引擎运行第一场景的运行时长达到了第一预设时长，那么移动终端就会自动获取第一切换指令，触发从第一场景切换到第二场景。

202、根据第一切换指令，将第一容器的状态由激活态切换到挂起态，并将第二容器的状态由挂起态切换到激活态，第二容器与运行第二场景的第二引擎对应，第二容器包含第二引擎运行的元素。

本实施例中，由于第一切换指令用来指示可以从第一场景切换到第二场景，那么在切换结束后，此时就需要运行第二场景的第二引擎是处于激活态，倘若第一引擎仍然处于激活态，就会使得第一引擎与第二引擎共同访问底层图形接口(OpenGL II D3D)，而底层图形接口又会访问硬件设备，此时互为黑盒的第一引擎和第二引擎就会造成第二场景的渲染结果出现异常。

因此，为了避免引擎之间在运行过程中的冲突，所以移动终端可以根据该第一切换指令将第一容器的状态由激活态切换到挂起态，并且移动终端将第二容器的状态由挂起态切换到激活态，从而使得可以使用处于激活态的第二引擎运行该第二场景，而切换成挂起态的第一引擎在第二场景下因无法工作则不会对第二场景的运行造成影响。

本实施例中，在同一个目标应用中，移动终端通过第一切换指令来切换第一容器和第二容器之间的状态，从而利用挂起态和激活态间的切换来避免第一容器和第二容器分别所对应的第一引擎、第二引擎之间的运行冲突，为后续多团队之间利用彼此具备优势的引擎合作研发同一个目标应用提供了便捷。

为便于更好地理解本申请实施例所提出的方案，下面对本实施例中的具体流程进行介绍，请参阅图3，为本申请实施例中隔离处理方法的另一个实施例示意图，该方法可以包括：

301、在目标应用的第一场景下获取第一切换指令，第一场景是基于第一引擎运行的，第一引擎对应的第一容器处于激活态，第一容器包含第一引擎运行的元素，第一切换指令用于指示从第一场景切换到目标应用的第二场景。

302、根据第一切换指令，将第一容器的状态由激活态切换到挂起态，并将第二容器的状态由挂起态切换到激活态，第二容器与运行第二场景的第二引擎对应，第二容器包含第二引擎运行的元素。

本申请实施例中的步骤301至步骤302可以参见图2所示的步骤201至步骤202进行理解，具体此处不再赘述。

303、在将第一容器的状态由激活态切换到挂起态时，触发保活机制，保活机制用于指示共享模块的状态为激活态，共享模块在第一场景和第二场景下被对应的第一引擎和第二引擎共用，共享模块独立于第一容器和第二容器。

本实施例中，除了有关场景渲染等元素被放置在不同的容器之外，在第一场景与第二场景下都还有一些元素是能够被第一引擎和第二引擎共同使用的。

例如：在网游中，A玩家与B玩家组局玩游戏，那么就需要通过连接网络实现A玩家所持有的移动终端与B玩家所持有的移动终端进行连接，由于服务器并不感知移动终端的运行状况，使得该服务器并不了解当前是处于第一场景还是第二场景，如果将网络协议收发模块设置在第一容器中，倘若在从第一场景切换到第二场景后，该第一容器的状态处于挂起态时，那么该网络协议收发模块就会处于挂起态，从而无法在第二场景中接收服务器发送的网络协议。同理，如果将网络协议收发模块设置在第二容器中，倘若当前处于第一场景且移动终端并未获取第一切换指令切换到第二场景时，该第二容器的状态处于挂起态时，那么该网络协议收发模块就会处于挂起态，从而无法在第一场景中接收服务器发送的网络协议。当然，如果将网络协议收发模块分别设置在第一容器、第二容器中，倘若当前处于第一场景且移动终端并未获取第一切换指令切换到第二场景时，该第二容器的状态处于挂起态时，那么处于第二容器中的网络协议收发模块就会处于挂起态，若A玩家向B玩家发送某些消息，如：“注意，左前方有危险”，此时B玩家所持有的移动终端则无法接收到该消息。所以，无论将该网络协议收发模块设置在第一容器或第二容器中，都可能因本申请实施例中的第一容器或第二容器处于挂起态而受到影响。

因此，请参阅图4，为本申请实施例中容器与共享模块的关系示意图，从图4中可以看出，可以将共享模块独立于第一容器和第二容器，并且设置在保活(native)层，使得无论当前处于第一场景还是第二场景该共享模块一直处于激活态。这样，移动终端便可以在第一容器的状态由激活态切换到挂起态时，触发保活机制，使得第一引擎运行第一场景，第二引擎运行第二场景时都能够调用该共享模块，增强整个隔离处理方案的灵活性。

应当理解的是，前述所描述的共享模块除了上述的网络协议收发模块之外，还可以包括音效模块、输入模块、语音模块、消息显示模块等等，在本申请实施例中将不做具体限定。

本实施例中，通过将在第一场景与第二场景能够共同使用的共享模块设置在保活层，使得无论当前用于运行第一场景的第一引擎是挂起态还是处于激活态时，都能够调用该共享模块，为整个隔离方案增强了灵活性。

为便于更好地理解本申请实施例所提出的方案，下面对本实施例中的具体流程进行介绍，请参阅图5，为本申请实施例中隔离处理方法的另一个实施例示意图，该方法可以包括：

501、在目标应用的第一场景下获取第一切换指令，第一场景是基于第一引擎运行的，第一引擎对应的第一容器处于激活态，第一容器包含第一引擎运行的元素，第一切换指令用于指示从第一场景切换到目标应用的第二场景。

502、根据第一切换指令，将第一容器的状态由激活态切换到挂起态，并将第二容器的状态由挂起态切换到激活态，第二容器与运行第二场景的第二引擎对应，第二容器包含第二引擎运行的元素。

本申请实施例中的步骤501至步骤502可以参见图2所示的步骤201至步骤202进行理解，具体此处不再赘述。

503、在第二场景下获取第二切换指令，第二切换指令用于指示从第二场景切换到目标应用的第三场景。

本实施例中，第一场景、第二场景与第三场景均属于同一个目标应用中的场景，其中，第一场景与第三场景可以由同一个引擎，即第一引擎运行。除了可以从第一场景切换到第二场景之外，也可以在该第二场景下获取第二切换指令，从第二场景切换到第三场景中。

例如：在游戏应用中，上述所描述的第一场景可以是大厅场景，第二场景可以是对局场景，而第三场景可以是结算场景，即在对局场景结束之后、玩家在该局中失败或成功时，都会出现该玩家在对局中的胜率、败率等结算信息，那么此时可以通过第一引擎来运行。在实际应用中，第一场景、第二场景以及第三场景还可以除了大厅场景、对局场景以及结算场景以外的其他场景，在本申请实施例中将不做具体限定。请参阅图6，为本申请实施例中场景切换的示意图。如图6所示，针对同一个游戏应用，大厅场景与结算场景均由第一公司所研发具备优势的第一引擎来运行，而对局场景均由第二公司所研发的在对局中具备优势的第二引擎来运行，由于事先已经将第一引擎运行的元素都设置在第一容器中，将第二引擎运行的元素都设置在第二容器中，因此玩家可以通过在第一场景中点击“方形按钮”，便可以将第一场景切换至第二场景中，在这切换的过程中，运行第一场景的第一引擎就会变成了挂起态，在由挂起态变成激活态的第二引擎运行第二场景时无法继续工作。同理，倘若玩家在该对局中胜利了，那么就会产生有关胜利的结算，那么可以通过第三场景显示出来，所以也可以在第二场景中点击“方形按钮”将第二场景切换至第三场景。因此，通过在切换过程中，移动终端可以将运行不同场景的不同引擎的状态在激活态与挂起态之间的切换，实现了不同公司研发同一个游戏应用时所使用的引擎之间的运行隔离，避免了引擎运行的冲突。

需要理解的是，上述所描述的第一场景与第三场景可以相同，也就是说在第二场景下可以通过第二切换指令切换回到第一场景中。例如：可以从对局场景中切换回大厅场景等等。

可选地，在一些实施例中，对于在目标应用的第二场景下获取第二切换指令可以采用如下方式：

第一种，响应第二场景下的用户操作，以获取第二切换指令。

在该实施例中，可以在第二场景中设置逻辑按钮等，若用户想要从第二场景切换到第三场景中，那么就可以直接在该第二场景中点击该逻辑按钮，这样移动终端便可以获取到该第二切换指令。

第二种，当第二引擎运行第二场景的运行时长大于或等于第二预设时长时，获取第二切换指令。

本实施例中，第二预设时长可以根据不同的需求进行设置，例如，可以设置为30秒，一分钟等，在本申请实施例中将不做具体限定。只要处于激活态的第二引擎运行第二场景的运行时长达到了第一预设时长，那么移动终端就会自动获取第二切换指令，触发从第二场景切换到第三场景。

504、根据第二切换指令，将第二容器的状态由激活态切换到挂起态，并将第一容器的状态由挂起态切换到激活态，其中，第三场景是基于状态由挂起态切换到激活态的第一容器对应的第一引擎运行的。

本实施例中，由于第二切换指令用来指示可以从第二场景切换到第三场景，那么在切换结束后，此时就需要运行第三场景的第一引擎是处于激活态，倘若第二引擎仍然处于激活态，就会使得第一引擎与第二引擎共同访问底层图形接口(OpenGL II D3D)，而底层图形接口又会访问硬件设备，此时互为黑盒的第一引擎和第二引擎就会造成第三场景的渲染结果出现异常。

因此，为了避免引擎之间在运行过程中的冲突，所以移动终端可以根据该第二切换指令将第二容器的状态由激活态切换到挂起态，并且将第一容器的状态由挂起态切换到激活态，从而使得可以使用处于激活态的第一引擎运行该第三场景，而切换成挂起态的第二引擎在第三场景下因无法工作则不会对第三场景的运行造成影响。

为便于更好地理解本申请实施例所提出的方案，下面对本实施例中的具体流程进行介绍，请参阅图7，为本申请实施例中隔离处理方法的另一个实施例示意图，该方法可以包括：

701、在目标应用的第一场景下获取第一切换指令，第一场景是基于第一引擎运行的，第一引擎对应的第一容器处于激活态，第一容器包含第一引擎运行的元素，第一切换指令用于指示从第一场景切换到目标应用的第二场景。

702、根据第一切换指令，将第一容器的状态由激活态切换到挂起态，并将第二容器的状态由挂起态切换到激活态，第二容器与运行第二场景的第二引擎对应，第二容器包含第二引擎运行的元素。

703、在第二场景下获取第二切换指令，第二切换指令用于指示从第二场景切换到目标应用的第三场景。

704、根据第二切换指令，将第二容器的状态由激活态切换到挂起态，并将第一容器的状态由挂起态切换到激活态，其中，第三场景是基于状态由挂起态切换到激活态的第一容器对应的第一引擎运行的。

本申请实施例中的步骤701至步骤704可以参见图5所示的步骤501至步骤504进行理解，具体此处不再赘述。

705、在将第二容器的状态由激活态切换到挂起态时，触发保活机制，保活机制用于指示共享模块的状态为激活态，共享模块在第三场景和第二场景下被对应的第一引擎和第二引擎共用，共享模块独立于第一容器和第二容器。

本实施例中，除了有关场景渲染等元素被放置在不同的容器之外，在第三场景与第二场景下都还有一些元素是能够被第一引擎和第二引擎共同使用的。可以将共享模块独立于第一容器和第二容器，并且设置在保活(native)层，使得无论当前处于第三场景还是第二场景该共享模块一直处于激活态。这样，移动终端便可以在第一容器的状态由激活态切换到挂起态时，触发保活机制，使得第一引擎运行第三场景，第二引擎运行第二场景时都能够调用该共享模块，增加整个隔离处理方案的灵活性。具体可以参照图3中的步骤303进行理解，此处将不做具体赘述。

本实施例中，通过将在第一场景与第二场景能够共同使用的共享模块设置在保活层，使得无论当前用于运行第三场景的第一引擎是挂起态还是处于激活态时，又或者当前用于运行第二场景的第二引擎是挂起态还是处于激活态时都能够调用该共享模块，为整个隔离方案增强了灵活性。

上述主要从方法的角度对本申请实施例提供的方案进行了介绍。可以理解的是为了实现上述功能，包含了执行各个功能相应的硬件结构和/或软件模块。本领域技术人员应该很容易意识到，结合本申请中所公开的实施例描述的各示例的模块及算法步骤，本申请能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

本申请实施例可以根据上述方法示例对装置进行功能模块的划分，例如，可以对应各个功能划分各个功能模块，也可以将两个或两个以上的功能集成在一个处理模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。需要说明的是，本申请实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。

下面对本申请实施例中的隔离处理装置80进行详细描述，请参阅图8，图8为本申请实施例中提供的隔离处理装置80一个实施例示意图，该隔离处理装置80包括：

第一获取单元801，用于在目标应用的第一场景下获取第一切换指令，第一场景是基于第一引擎运行的，第一引擎对应的第一容器处于激活态，第一容器包含第一引擎运行的元素，第一切换指令用于指示从第一场景切换到目标应用的第二场景；

第一切换单元802，用于根据第一获取单元801获取到的第一切换指令，将第一容器的状态由激活态切换到挂起态，并将第二容器的状态由挂起态切换到激活态，第二容器与运行第二场景的第二引擎对应，第二容器包含第二引擎运行的元素。

可选地，在上述图8所对应的实施例的基础上，请参阅图9，本申请实施例提供的隔离处理装置80的另一实施例中，该隔离处理装置80还包括：

第二获取单元803，用于在第一切换单元802将第一容器的状态由激活态切换到挂起态，并将第二容器的状态由挂起态切换到激活态之后，在第二场景下获取第二切换指令，第二切换指令用于指示从第二场景切换到目标应用的第三场景；

第二切换单元804，用于根据第二获取单元803获取到的第二切换指令，将第二容器的状态由激活态切换到挂起态，并将第一容器的状态由挂起态切换到激活态，其中，第三场景是基于状态由挂起态切换到激活态的第一容器对应的第一引擎运行的。

可选地，在上述图8所对应的实施例的基础上，本申请实施例提供的确定社交关系的装置80的另一实施例中，该隔离处理装置80还包括：

触发单元，用于在第二切换单元804将第二容器的状态由激活态切换到挂起态时，触发保活机制，保活机制用于指示共享模块的状态为激活态，共享模块在第三场景和第二场景下被对应的第一引擎和第二引擎共用，共享模块独立于第一容器和第二容器。

可选地，在上述图9所对应的实施例的基础上，本申请实施例提供的确定社交关系的装置80的另一实施例中，该隔离处理装置80还包括：

第一触发单元，用于在第一切换单元802将第一容器的状态由激活态切换到挂起态时，触发保活机制，保活机制用于指示共享模块的状态为激活态，共享模块在第一场景和第二场景下被对应的第一引擎和第二引擎共用，共享模块独立于第一容器和第二容器。

可选地，在上述图8、图9以及图8和图9所对应的可选实施例的基础上，本申请实施例提供的隔离处理装置80的另一实施例中，第一获取单元801，包括：

第一响应模块，用于响应第一场景下的用户操作，以获取第一切换指令。

可选地，在上述图8、图9以及图8和图9所对应的可选实施例的基础上，本申请实施例提供的隔离处理装置80的另一实施例中，第一获取单元801，包括：

第一获取模块，用于在第一引擎运行第一场景的运行时长大于或等于第一预设时长时，获取第一切换指令。

可选地，在上述图9以及图9所对应的可选实施例的基础上，本申请实施例提供的隔离处理装置80的另一实施例中，第二获取单元803，包括：

第二响应模块，用于响应第二场景下的用户操作，以获取第二切换指令。

可选地，在上述图9以及图9所对应的可选实施例的基础上，本申请实施例提供的隔离处理装置80的另一实施例中，第二获取单元803，包括：

第二获取模块，用于在第二引擎运行第二场景的运行时长大于或等于第二预设时长时，获取第二切换指令。

上面从模块化功能实体的角度对本申请实施例中的隔离处理装置80进行描述，下面从硬件处理的角度对本申请实施例中的移动终端100进行描述。请参阅图10，图10是本申请实施例公开的一种移动终端的结构示意图。如图10所示，该移动终端100包括处理器1001和存储器1002，其中，移动终端100还可以包括总线1003，处理器1001和存储器1002可以通过总线1003相互连接，总线1003可以是外设部件互连标准(Peripheral ComponentInterconnect，简称PCI)总线或扩展工业标准结构(Extended Industry StandardArchitecture，简称EISA)总线等。总线1003可以分为地址总线、数据总线、控制总线等。为便于表示，图10中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。其中，移动终端100还可以包括输入输出设备1004，输入输出设备1004可以包括显示屏，例如液晶显示屏。存储器1002用于存储包含指令的一个或多个程序；处理器1001用于调用存储在存储器1002中的指令执行上述图1至图7中的部分或全部方法步骤。

本申请实施例还提供了另一种移动终端，如图11所示，为了便于说明，仅示出了与本申请实施例相关的部分，具体技术细节未揭示的，请参照本申请实施例方法部分。该移动终端可以为包括手机、平板电脑、PDA(Personal Digital Assistant，个人数字助理)、POS(Point of Sales，销售终端)、车载电脑等任意终端设备，以移动终端为手机为例：

图11示出的是与本申请实施例提供的移动终端相关的手机的部分结构的框图。参考图11，手机包括：射频(Radio Frequency，RF)电路1110、存储器1120、输入单元1130、显示单元1140、传感器1150、音频电路1160、无线保真(Wireless Fidelity，WiFi)模块1170、处理器1180、以及电源1190等部件。本领域技术人员可以理解，图11中示出的手机结构并不构成对手机的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

下面结合图11对手机的各个构成部件进行具体的介绍：

RF电路1110可用于信息的接收和发送。通常，RF电路1110包括但不限于天线、至少一个放大器、收发信机、耦合器、低噪声放大器(Low Noise Amplifier，LNA)、双工器等。此外，RF电路1110还可以通过无线通信与网络和其他设备通信。上述无线通信可以使用任一通信标准或协议，包括但不限于全球移动通讯系统(Global System of Mobilecommunication，GSM)、通用分组无线服务(General Packet Radio Service，GPRS)、码分多址(Code Division Multiple Access，CDMA)、宽带码分多址(Wideband Code DivisionMultiple Access,WCDMA)、长期演进(Long Term Evolution，LTE)、第五代(5thgeneration，5G)移动通信系统或新无线(new radio，NR)通信系统以及未来的移动通信系统，电子邮件、短消息服务(Short Messaging Service，SMS)等。

存储器1120可用于存储软件程序以及模块，处理器1180通过运行存储在存储器1120的软件程序以及模块，从而执行手机的各种功能应用以及数据处理。存储器1120可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序等；存储数据区可存储根据手机的使用所创建的数据等。此外，存储器1120可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。

输入单元1130可用于接收输入的数字或字符信息，以及产生与手机的用户设置以及功能控制有关的键信号输入。具体地，输入单元1130可包括指纹识别模组1131以及其他输入设备1132。指纹识别模组1131，可采集用户在其上的指纹数据。除了指纹识别模组1131，输入单元1130还可以包括其他输入设备1132。具体地，其他输入设备1132可以包括但不限于触控屏、物理键盘、功能键(比如音量控制按键、开关按键等)、轨迹球、鼠标、操作杆等中的一种或多种。

显示单元1140可用于显示由用户输入的信息或提供给用户的信息以及手机的各种菜单。显示单元1140可包括显示屏1141，可选的，可以采用液晶显示器(Liquid CrystalDisplay，LCD)、有机或无机发光二极管(Organic Light-Emitting Diode,OLED)等形式来配置显示屏1141。

手机还可包括至少一种传感器1150，比如光传感器、运动传感器、压力传感器、温度传感器以及其他传感器。具体地，光传感器可包括环境光传感器(也称为光线传感器)及接近传感器，其中，环境光传感器可根据环境光线的明暗来调节手机的背光亮度，进而调节显示屏1141的亮度，接近传感器可在手机移动到耳边时，关闭显示屏1141和/或背光。作为传感器的一种，加速计传感器可检测各个方向上(一般为三轴)加速度的大小，静止时可检测出重力的大小及方向，可用于识别手机姿态的应用(比如横竖屏切换、磁力计姿态校准)、振动识别相关功能(比如计步器、敲击)等；至于手机还可配置的陀螺仪、气压计、湿度计、温度计、红外线传感器等其他传感器，在此不再赘述。

音频电路1160、扬声器1161，传声器1162可提供用户与手机之间的音频接口。音频电路1160可将接收到的音频数据转换后的电信号，传输到扬声器1161，由扬声器1161转换为声音信号播放；另一方面，传声器1162将收集的声音信号转换为电信号，由音频电路1160接收后转换为音频数据，再将音频数据播放处理器1180处理后，经RF电路1110以发送给比如另一手机，或者将音频数据播放至存储器1120以便进一步处理。

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

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

手机还包括给各个部件供电的电源1190(比如电池)，优选的，电源可以通过电源管理系统与处理器1180逻辑相连，从而通过电源管理系统实现管理充电、放电、以及功耗管理等功能。

手机还可以包括摄像头11100，摄像头11100用于拍摄图像与视频，并将拍摄的图像和视频传输到处理器1180进行处理。

手机还可以蓝牙模块等，在此不再赘述。

前述图1至图7所示的实施例中，各步骤方法流程可以基于该手机的结构实现。

本申请实施例还提供一种计算机存储介质，其中，该计算机存储介质存储用于电子数据交换的计算机程序，该计算机程序使得计算机执行如上述方法实施例中记载的任何一种隔离处理方法的部分或全部步骤。

本申请实施例还提供一种计算机程序产品，所述计算机程序产品包括存储了计算机程序的非瞬时性计算机可读存储介质，所述计算机程序可操作来使计算机执行如上述方法实施例中记载的任何一种隔离处理方法的部分或全部步骤。

需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明并不受所描述的动作顺序的限制，因为依据本发明，某些步骤可以采用其他顺序或者同时进行。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(read-only memory，ROM)、随机存取存储器(random access memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

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

Claims (15)

1.一种隔离处理方法，其特征在于，所述隔离处理方法包括：

在目标应用的第一场景下获取第一切换指令，所述第一场景是基于第一引擎运行的，所述第一引擎对应的第一容器处于激活态，所述第一容器包含所述第一引擎运行的元素，所述第一切换指令用于指示从所述第一场景切换到所述目标应用的第二场景；

根据所述第一切换指令，将所述第一容器的状态由激活态切换到挂起态，并将第二容器的状态由挂起态切换到激活态，所述第二容器与运行所述第二场景的第二引擎对应，所述第二容器包含所述第二引擎运行的元素。

2.根据权利要求1所述的隔离处理方法，其特征在于，在将所述第一容器的状态由激活态切换到挂起态，并将第二容器的状态由挂起态切换到激活态之后，还包括：

在所述第二场景下获取第二切换指令，所述第二切换指令用于指示从所述第二场景切换到所述目标应用的第三场景；

根据所述第二切换指令，将所述第二容器的状态由激活态切换到挂起态，并将所述第一容器的状态由挂起态切换到激活态，其中，所述第三场景是基于状态由挂起态切换到激活态的所述第一容器对应的所述第一引擎运行的。

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

在将所述第二容器的状态由激活态切换到挂起态时，触发保活机制，所述保活机制用于指示共享模块的状态为激活态，所述共享模块在所述第三场景和所述第二场景下被对应的所述第一引擎和所述第二引擎共用，所述共享模块独立于所述第一容器和所述第二容器。

4.根据权利要求1所述的隔离处理方法，其特征在于，还包括：

在将所述第一容器的状态由激活态切换到挂起态时，触发保活机制，所述保活机制用于指示共享模块的状态为激活态，所述共享模块在所述第一场景和所述第二场景下被对应的所述第一引擎和所述第二引擎共用，所述共享模块独立于所述第一容器和所述第二容器。

5.根据权利要求1-4中任一所述的隔离处理方法，其特征在于，所述在目标应用的第一场景下获取第一切换指令，包括：

响应所述第一场景下的用户操作，以获取第一切换指令。

6.根据权利要求1-4中任一所述的隔离处理方法，其特征在于，所述在目标应用的第一场景下获取第一切换指令，包括：

当所述第一引擎运行所述第一场景的运行时长大于或等于第一预设时长时，获取第一切换指令。

7.根据权利要求2-3中任一所述的隔离处理方法，其特征在于，所述在所述第二场景下获取第二切换指令，包括：

响应所述第二场景下的用户操作，以获取第二切换指令。

8.根据权利要求2-3中任一所述的隔离处理方法，其特征在于，所述在所述第二场景下获取第二切换指令，包括：

当所述第二引擎运行所述第二场景的运行时长大于或等于第二预设时长时，获取第二切换指令。

9.权利要求1-8中任一所述的隔离处理方法，其特征在于，所述目标应用安装于移动终端。

10.根据权利要求1-9中任一所述的隔离处理方法，其特征在于，所述目标应用包括游戏应用。

11.一种隔离处理装置，其特征在于，包括：

第一获取单元，用于在目标应用的第一场景下获取第一切换指令，所述第一场景是基于第一引擎运行的，所述第一引擎对应的第一容器处于激活态，所述第一容器包含所述第一引擎运行的元素，所述第一切换指令用于指示从所述第一场景切换到所述目标应用的第二场景；

第一切换单元，用于根据所述第一获取单元获取到的所述第一切换指令，将所述第一容器的状态由激活态切换到挂起态，并将第二容器的状态由挂起态切换到激活态，所述第二容器与运行所述第二场景的第二引擎对应，所述第二容器包含所述第二引擎运行的元素。

12.根据权利要求11所述的隔离处理装置，其特征在于，还包括：

第二获取单元，用于在所述第一切换单元将所述第一容器的状态由激活态切换到挂起态，并将第二容器的状态由挂起态切换到激活态之后，在所述第二场景下获取第二切换指令，所述第二切换指令用于指示从所述第二场景切换到所述目标应用的第三场景；

第二切换单元，用于根据所述第二获取单元获取到的所述第二切换指令，将所述第二容器的状态由激活态切换到挂起态，并将所述第一容器的状态由挂起态切换到激活态，其中，所述第三场景是基于状态由挂起态切换到激活态的所述第一容器对应的所述第一引擎运行的。

13.根据权利要求11所述的隔离处理装置，其特征在于，还包括：

触发单元，用于在将所述第二容器的状态由激活态切换到挂起态时，触发保活机制，所述保活机制用于指示共享模块的状态为激活态，所述共享模块在所述第三场景和所述第二场景下被对应的所述第一引擎和所述第二引擎共用，所述共享模块独立于所述第一容器和所述第二容器。

14.一种移动终端，其特征在于，包括：处理器以及存储器，所述处理器以及存储器通过通信总线相连；其中，所述处理器，用于调用并执行所述存储器中存储的程序；所述存储器，用于存储程序，所述程序用于实现如权利要求1至10任意一项所述的隔离处理方法。

15.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机可执行指令，所述计算机可执行指令用于执行权利要求1至10任意一项所述的隔离处理方法。

Images