事件处理及操作系统管理方法、装置、设备以及存储介质
技术领域
本公开涉及操作系统技术领域,特别是涉及一种事件处理及操作系统管理方法、装置、设备以及存储介质。
背景技术
操作系统为了扩展适用范围,大多会通过多种融合方法来兼容其它操作系统的应用,以使得操作系统能支持更广泛的应用生态圈。
但是,在不同操作系统在同一设备中运行的情况下,由于不同操作系统环境中编程模型、IPC(Inter-Process Communication,进程间通信)模型、窗口管理以及渲染流程等存在不同,因此如何向用户提供无缝的交互体验,是目前亟需解决的问题。
举例来说,在A操作系统和B操作系统在同一设备中运行的情况下,设备的屏幕上展示的界面元素可能既包括运行在A操作系统中的应用提供的界面元素,又包括运行在B操作系统中的应用提供的界面元素。例如,在前台运行应用是运行在B操作系统中的应用时,当前展示界面可以认为是B操作系统应用+A操作系统提供的状态栏(如剩余电量、网络制式、闹铃、应用通知消息等)这一组合界面,对于这种组合界面,在设备发生旋转时,需要保证B操作系统对前台运行的B操作系统应用的动画旋转和A操作系统对状态栏的动画旋转同步进行,以使得用户能获得无缝的旋转体验。
发明内容
本公开主要解决的技术问题是提供一种能够使运行在同一电子设备中的第一操作系统和第二操作系统同步处理事件的事件处理及操作系统管理方法、装置、设备以及存储介质。
根据本公开的第一个方面,提供了一种事件处理方法,包括:响应于事件触发,第一操作系统向第二操作系统发送第一通知,并且第一操作系统为处理事件进行准备;响应于第一通知,第二操作系统为处理事件进行准备;第一操作系统处理事件,并且向第二操作系统发送第二通知;以及响应于第二通知,第二操作系统处理事件。
可选地,第一操作系统在准备就绪后,处理事件,并且向第二操作系统发送第二通知;以及/或者第二操作系统在准备就绪,并且接收到第二通知的情况下,处理事件。
可选地,事件处理方法还包括:在第二操作系统接收到第一通知超过预定时间阈值,未接收到第二通知,并且第二操作系统准备就绪的情况下,第二操作系统处理事件。
可选地,事件处理方法还包括:在第一操作系统通知第二操作系统准备处理事件后,对当前展示界面做屏幕锁定处理,直至第一操作系统发出第二通知。
可选地,事件为与界面展示相关的事件。
可选地,事件包括以下一项或多项:旋转屏幕事件;缩放事件;移动事件。
可选地,响应于事件触发,第一操作系统还向第二操作系统通知与事件相关的参数。
可选地,响应于事件触发,在前台运行应用包括在第一操作系统中运行的应用的情况下,第一操作系统向第二操作系统发送第一通知。
可选地,事件处理方法还包括:响应于事件触发,在前台运行应用包括在第一操作系统中运行的应用的情况下,第一操作系统还向第二操作系统通知第一操作系统未准备就绪。
可选地,响应于事件触发,在前台运行应用不包括在第一操作系统中运行的应用的情况下,第一操作系统向第二操作系统发送第一通知后,第一操作系统不再处理事件。
可选地,事件处理方法还包括:在第一操作系统被卸载的情况下,响应于事件触发,由第二操作系统独立处理事件。
可选地,第一操作系统为兼容操作系统,第二操作系统为主操作系统。
可选地,第一操作系统和第二操作系统运行在同一电子设备中,并且电子设备的屏幕上展示的界面元素包括在第一操作系统中运行的应用的界面元素和在第二操作系统中运行的应用的界面元素。
根据本公开的第二个方面,还提供了一种操作系统管理方法,包括:为第一操作系统维护第一通信模块;为第二操作系统维护第二通信模块,第一操作系统和第二操作系统运行在同一电子设备中,并且第一操作系统通过第一通信模块与第二通信模块之间的通信,向第二操作系统发送通知以协调两个操作系统的事件处理过程。
可选地,第一操作系统和第二操作系统执行本公开第一个方面述及的事件处理方法。
根据本公开的第三个方面,还提供了一种事件处理装置,包括:第一通知装置,响应于事件触发,第一操作系统通过第一通知装置向第二操作系统发送第一通知,并且第一操作系统为处理事件进行准备,响应于第一通知,第二操作系统为处理事件进行准备;以及第二通知装置,第一操作系统处理事件,并且通过第二通知装置向第二操作系统发送第二通知,响应于第二通知,第二操作系统处理事件。
可选地,第一操作系统在准备就绪后,处理事件,并且向第二操作系统发送第二通知;以及/或者第二操作系统在准备就绪,并且接收到第一操作系统的准备就绪的通知的情况下,处理事件。
可选地,在第二操作系统接收到第一通知超过预定时间阈值,未接收到第二通知,并且第二操作系统准备就绪的情况下,第二操作系统处理事件。
可选地,事件处理装置还包括:屏幕锁定装置,用于在第一操作系统发出第一通知后,对当前展示界面做屏幕锁定处理,直至第一操作系统通知第二操作系统发出第二通知。
可选地,事件为与界面展示相关的事件。
可选地,事件包括以下一项或多项:旋转屏幕事件;缩放事件;移动事件。
可选地,事件处理装置还包括第三通知装置,响应于事件触发,第一操作系统还通过第三通知装置向第二操作系统通知与事件相关的参数。
可选地,响应于事件触发,在前台运行应用包括在第一操作系统中运行的应用的情况下,第一操作系统通过第一通知装置向第二操作系统发送第一通知。
可选地,事件处理装置还包括第四通知装置,在前台运行应用包括在第一操作系统中运行的应用的情况下,第一操作系统还通过第四通知装置向第二操作系统通知第一操作系统未准备就绪。
可选地,响应于事件触发,在前台运行应用不包括在第一操作系统中运行的应用的情况下,在第一操作系统向第二操作系统发送第一通知后,第一操作系统不再处理事件。
可选地,在第一操作系统被卸载的情况下,响应于事件触发,由第二操作系统独立处理事件。
可选地,第一操作系统为兼容操作系统,第二操作系统为主操作系统。
可选地,第一操作系统和第二操作系统运行在同一电子设备中,并且电子设备的屏幕上展示的界面元素包括在第一操作系统中运行的应用的界面元素和在第二操作系统中运行的应用的界面元素。
根据本公开的第四个方面,还提供了一种操作系统管理装置,包括:与第一操作系统对应的第一通信模块;以及与第二操作系统对应的第二通信模块,第一操作系统和第二操作系统同时运行在同一电子设备中,并且第一操作系统通过第一通信模块与第二通信模块之间的通信,向第二操作系统发送通知以协调两个操作系统的事件处理过程。
可选地,第一操作系统和第二操作系统执行本公开第一个方面述及的事件处理方法。
根据本公开的第五个方面,还提供了一种电子设备,其中运行第一操作系统和第二操作系统,包括:显示器;处理器,以及存储器;其上存储有可处理代码,当可处理代码被处理器处理时,使处理器执行如本公开的第一个方面或第二个方面述及的方法。
根据本公开的第六个方面,还提供了一种计算设备,包括:处理器;以及存储器,其上存储有可处理代码,当可处理代码被处理器处理时,使处理器执行本公开的第一个方面或第二个方面述及的方法。
根据本公开的第七个方面,还提供了一种非暂时性机器可读存储介质,其上存储有可处理代码,当可处理代码被电子设备的处理器处理时,使处理器执行本公开的第一个方面或第二个方面述及的方法。
由此,对于需要运行在同一电子设备中的第一操作系统和第二操作系统同步处理的事件,例如旋转屏幕事件,本公开通过控制关键节点的消息同步,可以实现该事件被两个操作系统同步处理,而至于第一操作系统和第二操作系统各自对事件的具体处理流程,可以是按照各自的处理机制进行。
附图说明
通过结合附图对本公开示例性实施方式进行更详细的描述,本公开的上述以及其它目的、特征和优势将变得更加明显,其中,在本公开示例性实施方式中,相同的参考标号通常代表相同部件。
图1示出了根据本公开一实施例的事件处理方法的示意性流程图。
图2示出了根据本公开另一实施例的事件处理方法的示意性流程图。
图3示出了根据本公开一实施例的冻屏机制的示意性流程图。
图4示出了第一操作系统和第二操作系统之间的通信结构示意图。
图5示出了根据本公开一实施例的事件处理装置的结构示意图。
图6示出了根据本公开一实施例的操作系统管理装置的结构示意图。
图7示出了根据本公开一实施例的电子设备的结构示意图。
图8示出了根据本公开一实施例的计算设备的结构示意图。
具体实施方式
下面将参照附图更详细地描述本公开的优选实施方式。虽然附图中显示了本公开的优选实施方式,然而应该理解,可以以各种形式实现本公开而不应被这里阐述的实施方式所限制。相反,提供这些实施方式是为了使本公开更加透彻和完整,并且能够将本公开的范围完整地传达给本领域的技术人员。
【术语解析】
Android,Google研发的一款市场主流操作系统。
OS,Operating System,操作系统。
App,在操作系统中运行的应用。
Weston,操作系统中的图形合成器。
Host/Guest,运行在同一电子设备中的操作系统包含的两部分子系统,Host为主操作系统,Guest为兼容操作系统,主操作系统主要用于兼容运行兼容操作系统的应用。
Binder,用于进程间通信的工具。
Wayland,Weston中用于进程间通信的工具。
【适用场景】
首先,就本公开的一种适用场景做示例性说明。
目前,市场中的操作系统为了扩展使用范围,大多会试图通过各种融合方法来兼容其它操作系统应用或重用已有操作系统驱动,例如Android应用或是Android驱动。
例如,Jolla推出的Sailfish OS(旗鱼系统)采用了第三方的闭源方案AlienDalvik(虚拟机程序)来提供Android应用所需要的运行环境。它本质上是一个Android应用的framework(框架),同时需要对Android的framework进行修改来与之对接。
OpenMobile提供了可将Android应用运行于非Android系统的方案。它被实现为host操作系统上的兼容层,使AOSP(Android Open-Source Project,Android开放源代码项目)、Dalvik(Google公司设计的用于Android平台的虚拟机)及其应用可以运行在其上。
但是,以上的技术方案各有其局限性。
1、兼容性得不到保证,且升级成本大。如Sailfish OS,对Android的framework做较多修改后,与原生系统的差异可能会使兼容性得不到保证,且会增加维护成本及日后升级的难度。
2、不能做到无缝融合,破坏用户体验。如Emulator(模拟器)+HAXM(HardwareAccelerated Execution Manager,硬件加速管理器),BlueStacks(一个可以让Android应用程序运行在Windows系统中的软件)以及Cell(一种模拟器)等方案,都是采用了轻量级或重量级的虚拟化方案。尽管采用了不同的技术,但从用户视角都能清楚地看到双系统的存在,不能使用户平滑地在已有系统和新系统间过渡。
3、缺乏相关资料。如OpenMobile,由于没有开源,且资源有限,无法对其实际效果进行准确评估。
本公开即是针对运行在同一电子设备(优选地为手机、IPAD等移动设备)中的两个不同的操作系统(OS)提出的。为了便于区分,两个不同的操作系统可以分别称为第一操作系统和第二操作系统。第一操作系统可以是兼容操作系统(Guest),第二操作系统可以是主操作系统(Host)。第一操作系统可以是基于第二操作系统创建的虚拟操作环境,例如虚拟机,除去第一操作系统之外的部分可以视为第二操作系统。
也就是说,第二操作系统可以提供兼容操作系统的虚拟机支持平台,基于该平台可以动态地创建能够兼容运行第一操作系统应用的虚拟机,该虚拟机即可视为是第一操作系统。如上文提及的AliOS,也可以通过容器(container)技术隔离兼容操作系统(Android)和主操作系统(AliOS)。
另外,第一操作系统和第二操作系统也可以不分主次,而是能够共同独立在同一电子设备中运行的两个操作系统。
关于第一操作系统和第二操作系统的具体类型,以及两个操作系统运行在同一电子设备中的具体实现方式,不是本公开的重点,对此本公开不做具体限定。
在第一操作系统和第二操作系统同时运行在同一电子设备中的情况下,电子设备的屏幕上展示的界面元素可能同时包括在第一操作系统中运行的应用中的界面元素以及在第二操作系统中运行的应用中的界面元素。
以第一操作系统为兼容操作系统,第二操作系统为主操作系统为例,电子设备的屏幕上的剩余电量、网络制式、闹铃、通知消息(如短消息提示消息、未接来电显示消息、应用通知消息等)等状态栏可以是由第二操作系统提供的,并且电子设备的屏幕上也可以运行兼容操作系统应用。因此,电子设备的屏幕上展示的界面元素可能是兼容操作系统应用+状态栏这一组合。
另外,在电子设备支持分屏操作的情况下,电子设备的屏幕上的前台运行应用可能既包括第一操作系统应用,也包括第二操作系统应用。因此,电子设备的屏幕上展示的界面元素还可能是第一操作系统应用+第二操作系统应用这一组合。
综上,在电子设备的屏幕上展示的界面元素同时包括在第一操作系统中运行的应用的界面元素和在第二操作系统中运行的应用的界面元素的情况下,当出现与界面展示相关的事件时,需要第一操作系统和第二操作系统对运行在各自操作系统中的前台运行应用中做同步处理,以使得用户获得无缝的交互体验。
例如,当电子设备的屏幕发生旋转时,需要第一操作系统和第二操作系统同步对运行在各自操作系统中的应用中的界面元素进行旋转控制,以使得用户获得无缝的旋转体验。
再例如,当用户对当前展示界面做缩放处理时,也需要第一操作系统和第二操作系统同步对运行在各自操作系统中的应用中的界面元素进行缩放控制,以使得用户获得无缝的缩放体验。
还例如,当用户对当前展示界面中的界面元素做移动(或者拖拽)处理时,如果移动事件同时牵涉分别属于两个操作系统中的界面元素,例如在要移动的界面元素遮挡与其属于不同操作系统中的其他界面元素时,也需要第一操作系统和第二操作系统同步处理,以使得用户获得无缝的操作体验。
另外,还可以是其它多种类型的需要第一操作系统和第二操作系统同步处理的事件,此处不再赘述。
本公开即是针对这种需要运行在同一电子设备中的第一操作系统和第二操作系统同步处理的事件(例如旋转屏幕事件、缩放事件、移动事件),提出的一种事件处理方案。
【事件处理方法】
图1示出了根据本公开一实施例的事件处理方法的示意性流程图。
参见图1,在步骤S110,响应于事件触发,第一操作系统向第二操作系统发送第一通知,并且第一操作系统为处理事件进行准备。
关于第一操作系统和第二操作系统可以参见上文描述,此处不再赘述。
此处述及的事件是指需要第一操作系统和第二操作系统共同处理的事件,优选地,可以是需要第一操作系统和第二操作系统同步处理的事件。例如,该事件可以是与界面展示相关的事件,如可以是上文提及的旋转屏幕事件、缩放事件、移动事件。
响应于事件触发,第一操作系统可以开始为处理事件进行准备。并且,第一操作系统为处理事件进行准备的时机可以与第一操作系统向第二操作系统发送第一通知这一事件无关,即第一操作系统可以在第一操作系统发送第一通知之前、之后或者同时,为处理事件进行准备。
在步骤S120,响应于第一通知,第二操作系统为处理事件进行准备。
第一通知用于触发第二系统为处理事件进行准备。
在本公开中,“为处理事件进行准备”是指为执行事件做准备工作。例如,以旋转屏幕事件为例,为旋转屏幕事件的执行而做的准备工作,是指根据旋转屏幕事件的屏幕旋转方向对相关应用(即前台展示应用)的尺寸大小进行重新布局,以使得重新布局后的应用在大小和方向方面均适应旋转后的屏幕。对于其它类型的事件(例如缩放事件、移动事件),为处理相应事件进行准备的具体实现过程不尽相同,本公开对于操作系统如何为处理事件进行准备的实现流程不做限定,即各操作系统(第一操作系统/第二操作系统)可以按照自身的事件处理机制为处理事件做相应准备工作。
在步骤S130,第一操作系统处理该事件,并且向第二操作系统发送第二通知。
第一操作系统可以在准备就绪后,处理该事件,并且向第二操作系统发送第二通知。优选地,第一操作系统可以在向第二操作系统发送第二通知后,即刻开始处理该事件。
在步骤S140,响应于第二通知,第二操作系统处理该事件。
第二通知用于触发第二系统处理事件。第二通知可以是第一操作系统已经准备就绪的通知,也可以是用于告知第二操作系统开始处理事件的通知。
第二操作系统可以在自身准备就绪后,并且收到第一操作系统发送的第二通知后,立刻开始处理该事件。
在第一操作系统为兼容操作系统,第二操作系统为主操作系统的情况下,第二操作系统的处理速度要远快于第一操作系统。因此,第一操作系统在准备就绪后,可以向第二操作系统发送第二通知,并且在发出第二通知后,第一操作系统可以立即开始处理该事件。而第二操作系统在接收到第一操作系统发送的第二通知时,早已准备就绪,因此可以响应于接收到第一操作系统发送的第二通知,立刻处理该事件,如此可以保证第一操作系统和第二操作系统能够同步处理该事件。
可见,本公开通过控制关键节点的消息同步,可以实现第一操作系统和第二操作系统同步处理该事件,至于第一操作系统和第二操作系统各自处理该事件的具体实现流程(包括准备流程和处理流程),本公开不做限定,即第一操作系统和第二操作系统可以按照各自的处理机制处理。
并且,在事件的整个处理过程中,可以仅由第一操作系统单方向通知第二操作系统,而无需第二操作系统向第一操作系统发送通知。因此,可以保证第一操作系统的行为完全保持最初的状态,避免用户的第一操作系统使用体验发生变化。
作为本公开的一个示例,响应于事件(如旋转屏幕事件、缩放事件、移动事件等与界面展示相关的事件)触发,可以首先判断是否需要第一操作系统和第二操作系统同步处理。在判定不需要第一操作系统和第二操作系统同步处理的情况下,第一操作系统可以在向第二操作系统发送第一通知后,不再关注该事件,即不再处理该事件。
需要说明的是,对于不同类型的事件,判断是否需要第一操作系统和第二操作系统同步处理的条件可能存在一定的差异。例如,对于旋转屏幕事件、屏幕缩放事件,在当前展示界面上同时存在运行在第一操作系统中的应用的界面元素和运行在第二操作系统中的应用的界面元素的情况下,可以判定需要第一操作系统和第二操作系统同步处理。而对于移动事件,还需进一步判断该移动事件是否牵涉同时运行在第一操作系统中的应用的界面元素和第二操作系统中的应用的界面元素,对此本公开不再赘述。
下面以旋转屏幕事件、屏幕缩放事件为例,就判断是否需要第一操作系统和第二操作系统同步处理的过程进行说明。
响应于旋转屏幕事件、屏幕缩放事件的触发,可以判断当前展示界面(即电子设备的屏幕)上是否同时存在运行在第一操作系统中的应用的界面元素和运行在第二操作系统中的应用的界面元素。
在判定为同时存在的情况下,表明需要第一操作系统和第二操作系统对各自系统中运行的应用的界面元素进行同步处理,此时可以执行图1所示的方法;在判定当前展示界面上的界面元素属于运行在一个操作系统中的应用(可以是一个或多个应用)的情况下,表明不需要第一操作系统和第二操作系统同步处理,此时可以由对应的单个操作系统单独处理。
如上文所述,第一操作系统可以是兼容操作系统,第二操作系统可以是主操作系统。主操作系统可以提供诸如剩余电量、网络制式、闹铃、应用通知消息等状态栏,显示在电子设备的屏幕上,兼容操作系统主要用于提供用于运行兼容应用的运行环境。
因此,在第一操作系统为兼容操作系统,第二操作系统为主操作系统的情况下,响应于事件(如旋转屏幕事件)触发,也可以判断前台运行应用是否包括运行在兼容操作系统中的应用,如果包括容操作系统系统,则表明当前展示界面很可能是兼容应用+状态栏,或者在设备支持分屏的情况下还可以是兼容应用+主操作系统应用,或者兼容应用+主操作系统应用+状态栏,需要第一操作系统和第二操作系统同步处理该事件。
如果前台运行应用不包括运行在兼容操作系统中的应用,则表明当前展示界面中的界面元素均是运行在主操作系统中的应用(可以是一个或多个)的界面元素,因此第一操作系统通知第二操作系统准备处理该事件后,第一操作系统可以不再关注该事件,即后续不再处理该事件,而由第二操作系统单独处理。
响应于事件触发,在判定需要第一操作系统和第二操作系统同步处理的情况下,第一操作系统还可以向第二操作系统通知第一操作系统未准备就绪。并且,第一操作系统还可以向第二操作系统通知与事件相关的参数。例如,在事件为旋转屏幕事件的情况下,第一操作系统还可以向第二操作系统通知旋转屏幕事件的屏幕旋转方向;在事件为缩放事件的情况下,第一操作系统还可以向第二操作系统通知缩放事件的缩放比例;在事件为移动事件的情况下,第一操作系统还可以向第二操作系统通知移动事件的移动位置等参数。
在本公开中,第一操作系统可以通过发送独立于第一通知的其它通知(可以是一个,也可以是两个)来告知第二操作系统第一操作系统的为处理事件进行准备的准备状态以及与事件相关的参数。另外,第一操作系统发送的第一通知中也可以包括第一操作系统为处理事件进行准备的准备状态和/或与事件相关的参数。
进一步地,为了保证事件处理流程不被其他事件干扰,在第一操作系统向第二操作系统发送第一通知后,可以对当前展示界面做屏幕锁定处理(即冻屏处理),直至第一操作系统向第二操作系统发送第二通知后,才停止对当前展示界面做屏幕锁定处理。此处述及的屏幕锁定处理是指对当前展示界面进行锁定,锁定期间内当前展示界面不变。
另外,在第二操作系统接收到第一操作系统发送的第一通知超过预定时间阈值,未接收到第一操作系统发送的第二通知,并且第二操作系统已经准备就绪的情况下,第二操作系统可以直接开始处理事件。
进一步地,第一操作系统可以设计为可插拔结构,在第一操作系统被卸载的情况下,响应于事件触发,可以由第二操作系统独立处理事件,第二操作系统可以按照其处理机制处理该事件,处理流程不再赘述。在第一操作系统启动的情况下,响应于事件触发,可以按照上文描述的处理流程进行处理。
下面以旋转屏幕事件为例,就本公开的事件处理方法的具体实现流程做进一步说明。应该知道,本公开的事件处理方法也可以适用于其它类型的需要第一操作系统和第二操作系统同步处理的事件,如缩放事件、移动事件。
图2示出了根据本公开另一实施例的事件处理方法的示意性流程图。
参见图2,在Guest被卸载的情况下,只有右侧的Host部分,此时旋转屏幕事件的屏幕旋转方向可以由Host计算,如可以通过①设置新的方向(即屏幕旋转方向)。
在Guest启动的情况下,路线①被禁止,此时旋转屏幕事件的屏幕旋转方向的计算可以由Guest提供,并根据不同的状态通过路线③或④设置新的方向。
具体地,在Guest启动的情况下,当设备发生旋转时,如左侧Guest部分所示,可以首先判断前台运行应用是否包括Guest应用,在不包括的情况下,此时展示界面为Host应用+Host状态栏组合,则Guest只需要通过③发送新方向的消息(可以是IPC消息,即进程间通信消息)给Host即可,此后,Guest可以不再关注旋转屏幕事件,即可以认为Guest部分的旋转结束。
在前台运行应用包括Guest应用的情况下,此时会出现Guest应用+Host状态栏的融合组合,另外在设备支持分屏的情况下,也可能会出现Guest应用+Host应用或者Guest应用+Host应用+Host状态栏的融合组合。这些情况均需要考虑动画的同步旋转。
在前台运行应用包括Guest应用的情况下,Guest可以通过②向Host通知Guest的状态,如旋转准备未就绪。例如Guest可以通过②发送Guest旋转没有就绪的IPC消息到Host。并且Guest可以通过④发送新方向的IPC消息给Host。
Guest和Host可以分别根据新方向对相关应用(前台展示应用)的尺寸大小进行重新布局,其中Guest和Host可以按照其各自的处理机制实现重新布局,重新布局的实现流程此处不再赘述。一般地,Host的处理速度要远快于Guest,即Host旋转准备就绪的时间要早于Guest。
当Guest准备就绪,或者开始旋转动画时,可以通过⑤发送旋转就绪的IPC消息到Host。Host只有在Host应用旋转准备就绪和收到Guest旋转就绪的IPC消息之后才开始旋转动画。由于Host应用更新速度远远快于Guest应用,所以Host可以在收到Guest通知的旋转就绪消息后立刻开始Host旋转动画。
另外,Host还可以设置一个定时器,如果Host接收到Guest发送的新方向的消息超过预定时间(即Time Out,超时),仍未收到Guest通知的旋转就绪消息,并且Host此时准备就绪的情况下,Host可以直接开始旋转动画。
由此,通过以上关键节点的消息同步,可以将Host配置为和Android一样的旋转动画类型和时间,使得Host和Guest能够同时开始旋转动画。而对于Host和Guest准备旋转以及开始旋转的具体实现过程,本公开不做限定,即Host和Guest可以按照各自的处理机制处理。
另外为了保证从开始收到旋转消息到开始旋转动画这一段时间内,旋转流程不会被别的事件或者显示打断,在旋转准备过程中,还可以进行冻屏处理(即上文述及的屏幕锁定处理)。如图3所示,Guest和Host在确定旋转方向,开始准备就绪时,可以对电子设备的屏幕做冻屏处理,直至旋转准备就绪,两者同时结束冻屏,然后再同步开始动画旋转,直至旋转结束。
为了实现交互和控制上的统一,本公开还提供了一种操作系统管理方法,以建立跨操作系统(例如可以是从Android到AliOS)的数据/控制连接通路。
【操作系统管理方法】
图4示出了基于本公开构建的第一操作系统和第二操作系统之间的数据/控制连接通路的结构示意图。其中,第一操作系统和第二操作系统运行在同一电子设备中。
参见图4,可以分别第一操作系统维护第一通信模块,为第二操作系统维护第二通信模块。第一操作系统可以通过第一通信模块与第二通信模块进行通信,与第二操作系统进行通信,即第一操作系统可以通过第一通信模块与第二通信模块之间的通信,向第二操作系统发送通知,以协调两个操作系统的事件处理过程。其中两个通信模块之间可以通过IPC模块(进程间通信模块,例如可以是dbus/wayland)发送数据或者函数调用请求。
具体地,响应于需要第一操作系统和第二操作系统同步处理的事件(例如旋转屏幕事件)的触发,第一操作系统中的窗口管理服务可以通过第一通信模块发送旋转方向和/或第一操作系统的状态的消息至第二通信模块,第二操作系统中的图形合成器可以通过第二通信模块接收第一通信模块发送的消息。
对于需要第一操作系统和第二操作系统同步处理的事件,第一操作系统和第二操作系统可以使用上文述及的事件处理方法处理该事件,此处不再赘述。
由此,基于这种跨操作系统(OS)的进程间通信,可以实现关键节点的消息同步,使得应用级融合的交互体验变得无缝。其中,在第一操作系统和第二操作系统同步处理旋转屏幕事情、缩放事件等于界面展示相关的事件的情况下,第二操作系统中的模块为图形合成器(weston),第一操作系统模块为窗口管理服务(WMS),两者之间的IPC(进程间通信)可以通过wayland来实现。
综上,对于需要同步处理的事件,本公开可以让第一操作系统应用和第二操作系统应用做到从用户角度透明,即让用户感觉在一个系统中操作,从而提升用户体验,实现新老系统的自然过渡。
并且,该设计对第一操作系统改动很小,第一操作系统中自身窗口管理等模块都可以最大限度的重用。这样既减少了维护成本,又保证了用户在第二操作系统上可以达到与在第一操作系统原生设备上一致的体验。
进一步地,与原生的第一操作系统相比,只需增加事件处理状态和事件参数(例如屏幕旋转方向)的三次IPC操作,且该IPC是异步的,因此对性能的损耗很小。
综上,基于本公开的事件处理方法,在新的移动操作系统与兼容操作系统同时运行在同一电子设备中时,可以提供旋转、缩放、拖拽等界面展示相关事件的同步处理的兼容性,支持旋转、缩放、拖拽等界面展示相关事件在内容、交互和显示上无缝用户体验,并且可以动态适配兼容操作系统的启动和卸载。
换言之,本公开可以为运行双操作系统环境的系统中提供了一种将来自两个操作系统环境中的旋转、缩放、拖拽等界面展示相关事件的同步处理方案。基于本公开至少可以产生如下有益效果。
1.兼容操作系统(例如Android)的可插拔
主操作系统(例如AliOS)的屏幕旋转、缩放、拖拽(移动)等事件处理功能可以支持兼容操作系统的动态插拔,即当动态的启动/卸载兼容操作系统时,可以实时调整控制算法,保证不同切换状态下处理逻辑的正确性和一致性。
2.显示效果的同步
虽然Host APP和Guest APP的动画是由不同系统控制的,但是通过关键控制节点的IPC消息同步和冻屏机制,可以保证旋转、缩放、拖拽等动画效果的同步。
3.无缝的交互体验
主操作系统与兼容操作系统的系统模块会相互传递控制和数据请求,这些控制流和数据流通过本公开提供的IPC模型在两个操作系统环境中传输。这些控制流和数据流是提供无缝交互和控制体验的基础。
作为示例,本公开的事件处理方案及操作系统管理方案可以应用于AliOS中。
AliOS采用了全新的设计思想,首先将新系统(AliOS)与Android分别作为Host(主操作系统)与guest(兼容操作系统),通过container(容器)技术隔离,从而减小Host对Android子系统的依赖,并保证Android子系统的可剥离性。同时又将Android中的图形系统架空,并桥接到Host中的图形系统,实现了双系统的统一合成渲染。这种兼具了分与合理念的架构设计,既提供了最佳的Android应用兼容性,又实现了双系统的无缝用户体验。
并且,AliOS采用了Android SF/WMS(Window Manager Service,窗口管理服务)对接Weston的方法,做到了统一的合成渲染图形系统,在显示层面上Android应用窗口和AliOS Native的应用窗口是无缝的。
【事件处理装置】
图5示出了根据本公开一实施例的事件处理装置的结构示意图。其中,事件处理装置500的功能模块可以由实现本发明原理的硬件、软件或硬件和软件的结合来实现。本领域技术人员可以理解的是,图5所描述的功能模块可以组合起来或者划分成子模块,从而实现上述发明的原理。因此,本文的描述可以支持对本文描述的功能模块的任何可能的组合、或者划分、或者更进一步的限定。
事件处理装置500可以具有的功能模块以及各功能模块可以执行的操作做简要说明,对于其中涉及的细节部分可以参见上文描述,这里不再赘述。
参见图5,事件处理装置500可以包括第一通知装置510和第二通知装置520。其中,本实施例述及的各通知装置可以是同一通信装置,也可以是不同通信装置,例如本公开述及的通知装置可以是下文图6中示出的第一通信模块和第二通信模块。
响应于事件触发,第一操作系统可以通过第一通知装置510向第二操作系统发送第一通知,并且第一操作系统为处理事件进行准备,响应于第一通知,第二操作系统为处理事件进行准备。
此处述及的事件优选地是指需要第一操作系统和第二操作系统同步处理的事件,例如可以是与界面展示相关的事件,如可以是旋转屏幕事件、缩放事件、移动事件。
可以是在前台运行应用包括在第一操作系统中运行的应用的情况下,第一操作系统通过第一通知装置510向第二操作系统发送第一通知。如果在前台运行应用不包括在第一操作系统中运行的应用的情况下,第一操作系统在向第二操作系统发送第一通知后,第一操作系统可以不再处理该事件。
第一操作系统在准备就绪后,可以处理该事件,并且第一操作系统可以通过第二通知装置520向第二操作系统发送第二通知。
第一操作系统可以为兼容操作系统,第二操作系统可以为主操作系统。第二操作系统可以在准备就绪并且接收到第一操作系统发送的第二通知后,开始处理事件。
如图5所示,事件处理装置500还可以包括第三通知装置530和第四通知装置540。
第一操作系统还可以通过第三通知装置530向第二操作系统通知与事件相关的参数,例如响应于旋转屏幕事件触发,第一操作系统还可以通过第三通知装置530向第二操作系统通知旋转屏幕事件的屏幕旋转方向。另外,对于缩放事件、移动事件,第一操作系统还可以分别向第二操作系统通知缩放比例、移动位置等参数。
另外,在前台运行应用包括在第一操作系统中运行的应用的情况下,第一操作系统还可以通过第四通知装置540向第二操作系统通知第一操作系统未准备就绪。
在第二操作系统接收到第一通知超过预定时间阈值,未接收到第二通知,并且第二操作系统准备就绪的情况下,第二操作系统可以直接开始处理事件。
作为本公开的一个可选示例,在第一操作系统被卸载的情况下,响应于事件触发,可以由第二操作系统独立处理事件。
如图5所示,事件处理装置500还可以包括屏幕锁定装置550。屏幕锁定装置550可以用于在第一操作系统发送第一通知后,对当前展示界面做屏幕锁定处理,直至第一操作系统发送第二通知。
【操作系统管理装置】
图6示出了根据本公开一实施例的操作系统管理装置的结构示意图。其中,操作系统管理装置600的功能模块可以由实现本发明原理的硬件、软件或硬件和软件的结合来实现。本领域技术人员可以理解的是,图5所描述的功能模块可以组合起来或者划分成子模块,从而实现上述发明的原理。因此,本文的描述可以支持对本文描述的功能模块的任何可能的组合、或者划分、或者更进一步的限定。
操作系统管理装置500可以具有的功能模块以及各功能模块可以执行的操作做简要说明,对于其中涉及的细节部分可以参见上文描述,这里不再赘述。
参见图6,操作系统管理装置600可以包括与第一操作系统对应的第一通信模块610以及与第二操作系统对应的第二通信模块620。
第一操作系统和第二操作系统运行在同一电子设备中,并且第一操作系统可以通过第一通信模块与第二通信模块进行通信,向第二操作系统发送通知以协调两个操作系统的事件处理过程。
其中,在第一通信模块610和第二通信模块620的作用下,响应于需要第一操作系统和第二操作系统同步处理的事件的触发,第一操作系统和第二操作系统可以执行上文述及的事件处理方法。
【电子设备】
图7示出了根据本公开一实施例的电子设备的结构示意图。电子设备700可以是可以实施为各种类型的计算装置,例如台式机、便携式计算机、平板电脑、智能手机、个人数据助理(PDA),或者其它类型的计算机装置,但是不限于任何特定形式。电子设备700中运行第一操作系统和第二操作系统。作为示例,第一操作系统可以是兼容操作系统,如可以是Android,第二操作系统可以是主操作系统,如可以是AliOS。
参见图7,电子设备700包括显示器710、处理器720以及存储器730。
存储器730上存储有可处理代码,当可处理代码被处理器处理720时,可以使处理器执行上文述及的事件处理方法或操作系统管理方法。
【计算设备】
图8示出了根据本公开一实施例的计算设备的结构示意图。
参见图8,计算设备800包括处理器810和存储器820。
存储器820上存储有可处理代码,当可处理代码被处理器处理810时,可以使处理器810执行上文述及的事件处理方法或操作系统管理方法。
上文中已经参考附图详细描述了根据本发明的事件处理及操作系统管理方法、装置及设备。
此外,根据本发明的方法还可以实现为一种计算机程序或计算机程序产品,该计算机程序或计算机程序产品包括用于处理本发明的上述方法中限定的上述各步骤的计算机程序代码指令。
或者,本发明还可以实施为一种非暂时性机器可读存储介质(或计算机可读存储介质、或机器可读存储介质),其上存储有可处理代码(或计算机程序、或计算机指令代码),当所述可处理代码(或计算机程序、或计算机指令代码)被电子设备(或计算设备、服务器等)的处理器处理时,使所述处理器处理根据本发明的上述方法的各个步骤。
本领域技术人员还将明白的是,结合这里的公开所描述的各种示例性逻辑块、模块、电路和算法步骤可以被实现为电子硬件、计算机软件或两者的组合。
附图中的流程图和框图显示了根据本发明的多个实施例的系统和方法的可能实现的体系架构、功能和操作。在这点上,流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分,所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可处理指令。也应当注意,在有些作为替换的实现中,方框中所标记的功能也可以以不同于附图中所标记的顺序发生。例如,两个连续的方框实际上可以基本并行地处理,它们有时也可以按相反的顺序处理,这依所涉及的功能而定。也要注意的是,框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合,可以用处理规定的功能或操作的专用的基于硬件的系统来实现,或者可以用专用硬件与计算机指令的组合来实现。
以上已经描述了本发明的各实施例,上述说明是示例性的,并非穷尽性的,并且也不限于所披露的各实施例。在不偏离所说明的各实施例的范围和精神的情况下,对于本技术领域的普通技术人员来说许多修改和变更都是显而易见的。本文中所用术语的选择,旨在最好地解释各实施例的原理、实际应用或对市场中的技术的改进,或者使本技术领域的其它普通技术人员能理解本文披露的各实施例。