本申请是于2010年10月1日提交的标题为“Multi-OperatingSystemPortableDockingDevice”的美国临时申请No.61/389,117、于2011年7月13日提交的标题为“DockableMobileSoftwareArchitecture”的61/507,199、于2011年7月13日提交的标题为“Cross-EnvironmentCommunicationFramework”的61/507,201、于2011年7月13日提交的标题为“Multi-OperatingSystem”的61/507,203、于2011年7月13日提交的标题为“Auto-ConfigurationofaDockedSysteminaMulti-OSEnvironment”的61/507,207、以及于2011年7月13日提交的标题为“Auto-WakingofaSuspendedSecondaryOSinaDockableSystem”的61/507,209的非临时申请并且要求其提交日的权益，其中通过引用将上述优先权申请的全部内容合并于此用于所有目的。
技术领域：
本申请一般地涉及移动计算环境领域，更具体地涉及通过在单个移动计算设备中使用多个操作系统来支持多用户环境。
背景技术：
：移动计算设备在当今社会中变得无处不在。例如，到2008年末，百分之九十的美国人具有移动无线设备。并发，移动设备的能力正迅速地发展，包括将高级计算能力与移动电话能力集成的智能电话。移动运营商在过去三年中已基于几个不同的平台（例如AppleiPhone、Android、BlackBerry、Palm和WindowsMobile）投放了数百种新的智能电话。在美国，智能电话畅销度到2010年中期达到接近23%，并且在一些年龄组中超过35%。在欧洲，智能电话市场从2009年至2010年增长了41%，仅在五个最大的欧洲国家中到2010年7月具有超过6千万智能电话用户。虽然智能电话在流行度和计算能力在增加，但是它们提供有限的用户体验。具体地，它们典型地具有针对移动设备硬件而修改的操作系统和可用于修改的操作系统的有限应用集。例如，许多智能电话运行谷歌的Android（安卓）操作系统。Android仅运行被专门开发来在基于Java的虚拟机运行环境中运行的应用。此外，虽然Android基于修改的Linux内核，但是它使用与Linux不同标准的C库、系统管理器和服务。因此，针对Lixux编写的应用在不经修改或转变（porting）的情况下不能在Android上运行。类似地，Apple的iPhone使用iOS移动操作系统。再次，虽然iOS源自MacOSX，但是针对OSX开发的应用不能运行在iOS上。因而，虽然许多应用可用于诸如Android和iOS的移动操作系统，但是用于诸如Linux和MacOSX的桌面操作系统的许多其他公共应用不可用于移动平台。因此，智能电话典型地适合于有限的用户体验集，并且提供主要为移动环境设计的应用。具体地，智能电话不提供适合的桌面用户体验，它们也不运行大部分公共的桌面应用。结果，许多用户携带和使用包括智能电话、膝上型电脑和/或平板计算机的多个计算设备。在该情况下，每个设备具有其自己的CPU、存储器、文件存储和操作系统。在智能电话和其他计算设备之间的连接和文件共享涉及通过无线或有线连接来将一个设备（例如运行移动OS的智能电话）链接到第二完全不同的设备（例如笔记本、桌上型计算机或运行桌面OS的平板计算机）。通过使在于每个设备上分离运行的应用之间的数据同步来跨越设备共享信息。通常被称为“同步”的该过程是麻烦的并且通常需要用户的主动管理。技术实现要素：本发明的实施例涉及在单个移动计算设备中提供智能电话的移动计算体验和辅助终端环境的适当用户体验。辅助终端环境可用是通过有线（例如USB、Firewire、Thunderbolt）或无线（例如蓝牙、WiFi等）连接而连接到计算设备的视觉渲染设备（例如监视器或显示器）、输入设备（例如鼠标、触摸板、触摸屏、键盘等）和其他计算外围设备（例如HDD、光盘驱动、存储棒、相机、打印机等）的某个组合。在实施例中，与移动环境的用户体验相关联的移动计算系统和与辅助终端环境的用户体验相关联的桌面操作系统在共享内核中并发并独立地运行。根据与各实施例一致的方面，通过以下来提供跨环境工作流：利用在第一操作系统上运行的第一应用打开文档文件，文档文件的用户内容表示存储的文档状态；在第一应用中接受用户输入，第一应用具有作为对用户输入的响应结果的第一用户交互状态，第一用户交互状态包括修改的文档状态；将表示第一用户交互状态的应用状态信息存储在第一计算环境内，应用状态信息包括应用上下文信息；在不将修改的文档状态保存到文档文件的情况下，通过第一应用来释放文档文件的文件锁；通过在第二操作系统上运行的第二应用打开文档文件；通过第二应用来访问与第一用户交互状态相关联的应用状态信息；以及通过第二应用来应用应用上下文信息，以呈现与第一用户交互状态基本类似的第二应用的交互状态。根据与各实施例一致的其他方面，跨环境工作流包括通过第二应用打开由第一应用创建的临时文档文件，临时文档文件表示在存储的文档状态和修改的文档状态之间的改变。应用上下文信息可用包括到临时文件的线索。第一应用可以被显示在第一用户环境内，以及第二应用可以被显示在第二用户环境内。第一和第二操作系统可以在移动设备的共享内核上并发运行。应用上下文信息可以通过应用编程接口被存储在由第一和第二应用访问的数据库中。根据与各实施例一致的其他方面，应用上下文信息可以包括没有在文档文件中表示的至少一个用户交互状态。应用上下文信息可以包括与未完成的用户动作相关联的信息和/或用户内容信息的当前用户选择相关联的信息。第二应用打开文档文件可以是响应于检测到移动设备的对接事件。附图说明参考附图来说明本发明的实施例，其中在整个附图的描述中相同的数字指代相同的元素。图1图示根据各实施例的提供多用户计算体验的计算环境。图2图示根据各实施例的用于移动计算设备的示范性系统体系结构。图3图示根据各实施例的用于计算环境的操作系统体系结构。图4图示根据各实施例的可在多操作系统计算环境中采用的移动操作系统体系结构。图5图示根据各实施例的用于计算环境的操作系统体系结构的各方面。图6图示根据各实施例的可在移动操作系统计算环境中采用的移动操作系统体系结构。图7图示根据各实施例的用于跨越在单独的操作系统中运行的应用而提供应用数据、用户设置和/或应用上下文的转化的多操作系统计算环境。图8图示根据各实施例的计算环境配置。图9图示根据各实施例的其中将移动计算设备与辅助终端环境对接的计算环境配置。图10图示根据各实施例的示出图7的计算环境的各方面如何跨越在单独的操作系统上运行的多个应用而提供无缝工作流的计算环境配置。图11图示根据各实施例的用于在独立操作系统上运行并且被显示在单独的用户环境中的单独应用之间的应用数据的转化的示范性过程。图12图示根据各实施例的用于在独立操作系统上运行并且被显示在单独的用户环境中的单独应用之间的应用数据的转化的另一示范性过程。具体实施方式包括计算能力的移动电话设备（即智能电话、手持机、移动台、便携式通信设备等）在流行度方面正在增加。这些智能电话中的许多包括在移动处理器上运行的移动操作系统（“OS”）。虽然移动处理器和移动OS已提高了这些设备的能力，但是至少由于所提供的有限的用户体验，智能电话还没有趋向于替代诸如桌面或笔记本计算机的个人计算机（“PC”）环境（即Windows、MacOSX、Linux）。具体地，在智能电话上发现的用户接口设备（或多个）典型地适合于移动环境。例如，智能电话典型地使用小的拇指型QWERTY键盘、触摸屏显示器、点击轮和/或滚动轮作为用户接口设备。移动OS以及为移动OS而开发的应用（即“App”）典型地针对包括移动设备上存在的移动处理器和用户接口设备（或多个）的移动环境的约束来设计。因而，已为PC操作系统开发的许多应用不可用于移动OS（即不是为其编译的并且不能在移动OS上运行）。此外，对于诸如键入或编辑文档的某些任务，全尺寸的键盘和大的显示器比在智能电话上典型地发现的用户接口组件更易于使用。因此，用户典型地对于每个计算体验使用单独的计算设备，包括智能电话、平板计算机、膝上型计算机、和/或桌上型计算机。在该情况下，每个设备具有其自己的CPU、存储器、文件存储和OS。在智能电话和其他设备之间的连接和文件共享涉及通过无线或有线连接来将一个设备（例如运行移动OS的智能电话）链接到第二完全不同的设备（例如运行桌面OS的笔记本、桌上型计算机或平板计算机）。通过使分别运行在每个设备上的应用之间的数据同步来跨越设备共享信息。通常被称为“同步”的该过程是麻烦的并且通常需要用户的主动管理。图1图示根据各实施例的计算环境100，其利用包括与单独的用户交互空间（即用户环境）相关联的多个操作系统的移动设备提供多用户计算体验。计算环境100的第一用户交互空间115包括移动计算设备110的显示器（或多个）116和I/O设备118。当移动计算设备110作为单机移动设备操作时，移动OS130通过用户交互空间115呈现典型的移动计算用户体验。移动OS130提供的移动计算体验典型地包括移动电话能力以及适于包括显示器（或多个）116和I/O设备（或多个）118的用户交互空间115的图形用户接口（“GUI”）。例如，显示器（或多个）116可以是触摸屏显示器（或多个），并且可以使用触摸屏显示器（或多个）116主要通过移动OS130的基于手势的GUI来控制在移动OS上运行的应用程序（即“App”）。在计算环境100中，移动计算设备110可以与包括I/O设备144、146和/或148的辅助终端环境140对接。在实施例中，通过将移动计算设备110的端口120连接到辅助终端环境140的端口142，移动计算设备110与辅助终端环境140对接。在该情况下，辅助终端环境140呈现计算环境100的第二用户交互空间。在一些情况下，第二用户交互空间可以更适合于桌面计算体验。在这些情况下，桌面OS160可以与辅助终端环境140相关联，以通过第二用户交互空间来提供笔记本、平板或桌面计算机环境的完全能力。在实施例中，移动OS130和桌面OS160在移动计算设备110的处理器上的共享内核上并发运行。在于2011年8月24日提交的标题为“MULTI-OPERATINGSYSTEM”美国专利申请No.13/217,108中更详细地描述了移动OS和桌面OS在共享内核上的并发执行，通过引用将其合并于此。以此方式，单个移动计算设备可以通过第一用户交互空间提供移动计算体验并通过第二用户交互空间提供桌面计算体验。虽然携带通过单独的用户交互空间能够并发执行多个操作系统的一个移动设备的能力为用户解决了多个问题，但是每个用户交互空间（通过并发运行移动OS和桌面OS）通常提供单独的可用应用集和用户功能集。本发明的实施例旨在使用在单独的、独立的操作系统上运行的提供类似功能的多个应用来提供无缝跨环境工作流。实施例便于多个应用共享单个的表观上（apparent）的用户交互状态。在实施例中，用户可以从利用在第一OS（例如移动OS130）上运行的应用与用户内容的交互无缝地切换到利用在第二OS（例如桌面OS160）上运行的应用与同一用户内容的交互。应注意，当用户切换到第二应用时，维持当前的用户交互状态的应用上下文信息，包括典型地没有作为关于应用的文档文件的一部分而存储的应用上下文信息。例如，考虑用户正在通过第一用户环境使用在第一OS上运行的第一文字处理应用来编辑文档。用户希望切换，以使用在与第二用户环境相关联的第二OS上运行的类似文字处理应用通过第二用户环境来编辑同一文档。例如，用户可能已将移动计算设备与第二用户环境对接，并且希望切换以利用第二用户环境来编辑文档。用户期望无缝地发生该转变，使得他们能够在其停止第一应用的地方使用第二应用准确地重拾（pickup），包括任何未保存的数据和未完成的用户动作。处理该方案涉及以在单独的操作系统上的单独过程中运行的应用呈现单个表观上的应用交互状态的方式来管理用户文档文件和应用状态信息。因此，实施例提供了用于管理在多个单独的操作系统上运行的多个应用的应用状态信息和文档文件的各种新颖技术。实施例包括用于针对主要对本地用户内容操作的应用、客户端-服务器应用和基于因特网的应用管理应用状态信息的技术。如上所述，计算环境100通过与并发运行多个操作系统的移动设备相关联的多个用户交互空间来提供多用户计算体验。具体地，因为移动计算设备110包括多个OS，其中每个OS适合于特定的计算环境，所以移动计算设备110可以利用外部I/O设备适配，以利用单个移动计算设备来提供广泛范围的用户体验。例如，用户可以具有移动计算设备110和辅助终端环境140，辅助终端环境140包括在膝上型外壳中的键盘、显示器和/或指示设备（或多个）。当移动计算设备110与该膝上型辅助终端环境对接时，桌面OS160的全部能力通过辅助终端环境140是可用的。图2图示根据各实施例的用于移动计算设备110的示范性硬件系统体系结构。移动计算设备硬件112包括包含一个或更多个CPU核心204和外部显示接口220的移动处理器114。一般地，移动计算设备硬件112还包括I/O设备118、存储器206、存储设备208、连接到触摸屏显示器116的触摸屏显示器控制器210、连接到电池216的电力管理IC214、蜂窝调制解调器218、通信设备222和/或通过各种通信信号及接口连接到处理器114的其他设备224。I/O设备118通常包括按钮和在移动计算设备110中可以采用的其他用户接口组件。例如，I/O设备118可以包括一组按钮（例如回退、菜单、主页、搜索等）、离屏手势区域、点击轮、滚动轮、QWERTY键盘等。其他设备224可以包括例如GPS设备、LAN连接、麦克风、扬声器、相机、加速器和/或MS/MMC/SD/SDIO卡接口。外部显示接口220可以是任何合适的显示接口（例如VGA、DVI、HDMI等）。处理器114可以是基于ARM的移动处理器。在实施例中，移动处理器114是基于移动ARM的处理器，诸如TexasInstrumentsOMAP3430、MarvellPXA320、FreescaleiMX51、或QualcommQSD8650/8250。然而，移动处理器可以是另一合适的基于ARM的移动处理器或基于其他处理器体系结构的处理器，诸如例如基于x86的处理器体系结构或其他基于RISC的处理器体系结构。虽然图2图示了用于移动计算设备110的一个示范性硬件实现112，但是预期其他体系结构在本发明的范围内。例如，图2中被图示为在移动处理器114外部的各个组件可以被集成到移动处理器114中。可选地，图2中被图示为集成到移动处理器114中的外部显示接口220可以在移动处理器114外部。另外，利用系统总线、单独的图形处理器和/或其他体系结构变体的其他计算机体系结构适合于利用本发明的各方面。图3图示根据各实施例的可以被利用来在移动计算设备110上并发运行移动OS130和桌面OS160的OS体系结构300。如图3中所图示的，移动OS130和桌面OS160是独立的操作系统。具体地，移动OS130和桌面OS160可以具有独立并且不兼容的用户库、图形系统和/或框架层。用于OS体系结构300的功能和指令可以作为计算机程序代码被存储在移动计算设备110的有形计算机可读介质上。例如，用于OS体系结构300的指令可以被存储在移动计算设备硬件112的存储设备（或多个）208中。在OS体系结构300中，移动OS130和桌面160在共享内核320上并发运行。这意味着移动OS130和桌面OS160同时运行在共享内核上。具体地，移动OS130和桌面OS160两者例如通过做出到共享内核320的系统呼叫来通过同一内核接口322而接口到共享内核320。共享内核320管理用于移动OS130和桌面OS160二者的过程的任务调度。在该方面，移动OS130和桌面OS160在共享内核320上独立地且并发地运行。此外，共享内核320直接运行在移动计算设备硬件112的移动处理器114上，如通过硬件接口312图示的。具体地，共享内核320直接管理移动计算设备硬件112的计算资源，诸如CPU调度、存储器访问和I/O。在该方面，硬件资源不是虚拟的，这意味着移动OS130和桌面OS160在不用虚拟的存储器或I/O访问的情况下通过内核接口322进行系统呼叫。如图3中所图示的，移动OS130具有库层（librarylayer）330、应用框架层340和应用层350。在移动OS130中，应用352和354运行在由移动OS130的应用框架层340支持的应用层350中。应用框架层340包括由在移动OS130上运行的应用所使用的管理器（或多个）342和服务（或多个）344。例如，应用框架层340可以包括用于移动环境的窗口管理器、活动管理器、包管理器、资源管理器、电话管理器、手势控制器和/或其他管理器和服务。应用框架层340可以包括执行为移动OS130开发的应用的移动应用运行环境。移动应用运行环境可以针对诸如较低处理能力和/或有限存储器空间的移动计算环境来优化。移动应用运行环境对于过程隔离、存储器管理和线程支持可以依赖于内核。库层330包括用户库332，其实现诸如I/O和字符串操纵、图形功能、数据库能力、通信能力和/或其他功能和能力的公共功能。如图3中所图示的，桌面OS160具有库层360、框架层370和应用层380。在桌面OS160中，应用382和384运行在由桌面OS160的应用框架层370支持的应用层380中。应用框架层370包括由在桌面OS160上运行的应用使用的管理器（或多个）372和服务（或多个）374。例如，应用框架层370可以包括对桌面环境来说是公共的窗口管理器、活动管理器、包管理器、资源管理器和/或其他管理器和服务。库层360可以包括用户库362，其实现诸如I/O和字符串操纵、图形功能、数据库能力、通信能力和/或其他功能和能力的公共功能。在本公开的各实施例中，桌面OS160运行在与移动OS130单独的执行环境中。例如，移动130可以运行在根执行环境中，并且桌面OS160可以运行在于根执行环境之下建立的辅助执行环境中。运行在移动OS130上的过程和应用访问根执行环境中的用户库332、管理器（或多个）342和服务（或多个）344。运行在桌面OS160上的过程和应用访问辅助执行环境中的用户库362、管理器（或多个）372和服务（或多个）374。在实施例中，移动OS130和桌面160是具有不兼容的用户库、图形系统和/或应用框架的独立操作系统。因而，针对移动OS130开发的应用可能不直接运行在桌面OS160上，并且针对桌面OS160开发的应用可能不直接运行在移动OS130上。例如，运行在移动OS130的应用层350中的应用352可能与桌面OS160不兼容，这意味着应用352不能运行在桌面OS160上。具体地，应用352可以依赖于移动OS130的管理器（或多个）342、服务（或多个）344和/或库332，其对桌面OS160的管理器（或多个）372、服务（或多个）374和/或库362来说既不可用也不兼容。结果，移动OS130和桌面OS160可能具有不同的可用应用集。在该方面，OS体系结构300的移动OS130和桌面OS160通过经由单独的用户交互空间可访问的单独的应用集来提供单独的用户体验。用户可以通过与移动OS130相关联的第一用户交互空间来访问在移动OS130上可用的（即为移动OS130编译并加载在移动OS130的执行环境内）应用，并且通过与桌面OS160相关联的第二用户交互空间来访问在桌面OS160上可用的应用。如上所述，移动操作系统典型地不使用与桌面操作系统相同的图形环境。用于桌面OS的图形环境是针对灵活性和高性能设计的。例如，由一些桌面OS使用的X窗口以较大的处理和系统资源为代价来提供平台和网络独立性。相比而言，用于移动OS的图形环境是更多针对效率和移动计算环境的特定用户输入设备而更少针对灵活性来设计的。因为移动OS和桌面OS的图形环境通常是不同的，所以运行在移动OS上的应用可能不能通过将来自移动OS的图形服务器的图形信息重定向到桌面OS的图形服务器来直接显示在桌面OS的用户空间内。最广泛采用的移动OS是谷歌的Android。虽然Android是基于Linux的，但是它包括针对移动环境和移动处理器的对内核和其他OS层的修改。具体地，虽然Linux内核是针对PC（即x86）CPU体系结构设计的，但是Android内核针对基于ARM的移动处理器而修改。Android设备驱动器还特别针对其它设备中典型地在移动硬件体系结构中存在的设备进行调整，所述设备包括触摸屏、移动连接（GSM/EDGE、CDMA、Wi-Fi等）、电池管理、GPS、加速度计以及相机模块。此外，Android不具有本原XWindowSystem，也不支持全部标准GUN库，这使得难以将现有的GUN/Linux应用或库转变到Android。Apple的iOS操作系统（运行在iPhone上）和Microsoft的WindowsPhone7类似地针对移动环境和移动硬件体系结构而修改。例如，虽然iOS源自MacOSX桌面OS，但是公共的MacOSX应用不本原地运行在iOS上。具体地，iOS应用通过标准的开发包（“SDK”）开发以运行在iOS的“CocoaTouch”运行环境内，其提供基本的应用基础设施并支持关键iOS特征，诸如基于触摸的输入、推送通知和系统服务。因而，针对MacOSX编写的应用在不经转变的情况下不能运行在iOS上。此外，因为两个OS的用户库和/或应用框架层之间的差异，和/或移动硬件与桌面硬件的系统资源中的差异，可能难以将MacOSX应用转变到iOS。在与OS体系结构300一致的一个实施例中，Android移动OS和全LinuxOS独立地且并发地在修改的Android内核上运行。在该实施例中，AndroidOS可以是修改的Android分布，而LinuxOS（“Hydroid”）可以是修改的DebianLinux桌面OS。图4-6更详细地图示了根据各个实施例的可以在OS体系结构300中采用的Android移动OS430、Android内核520和HydroidOS660。如图4中所示，AndroidOS430包括库层432中通过应用框架层440访问的C/C++库集。库层432包括针对Android特别开发的比“glibc”LinuxC库更小并且更快的“仿生（bionic）”系统C库439。库层432还包括过程间通信（“IPC”）库436，其包括用于AndroidOS的“Binder”IPC机制的基础类。Binder是针对Android特别开发的，以允许在过程和服务之间的通信。图4中的库层432内所示其他库包括支持媒体格式的记录和播放的媒体库435、管理对显示子系统和来自多个应用的合成图形层的访问的表面管理器434、2D和3D图形引擎438、以及轻量级关系数据库引擎437。可以包括在库层432中但是在图4中没有绘出的其他库包括位图和矢量字体渲染库、工具库、浏览器工具（即WebKit等）、和/或安全通信库（即SSL等）。AndroidOS430的应用框架层440提供允许开发者使用设备硬件的组件、访问位置信息、运行后台服务、设置警报、向状态栏添加通知等的开发平台。框架层440还允许应用发布它们的能力和利用其他应用的发布的能力。Android移动OS430的应用框架层440的组件包括活动管理器441、资源管理器442、窗口管理器443、对接管理器444、硬件和系统服务445、桌面监视服务446、多显示管理器447、以及远程通信服务448。可以包括在Android移动OS430的框架层440中的其他组件包括其他管理器和服务中的视图系统、电话管理器、包管理器、位置管理器、和/或通知管理器。运行在AndroidOS430上的应用在Android运行环境433中的Dalvik虚拟机431内运行在Android面向对象的应用框架的上面。Dalvik虚拟机431是基于注册的虚拟机，并且运行被设计为降低存储器使用和处理需求的压缩可执行格式。运行在AndroidOS430上的应用包括主页屏幕451、电子邮件应用452、电话应用453、浏览器应用454、和/或其他应用（或多个）（“App”）455。AndroidOS图形系统使用客户端/服务器模型。表面管理器（“SurfaceFlinger”）是图形服务器，并且应用是客户端。SurfaceFlinger维持显示ID的列表，并且对向显示ID分配应用保持跟踪。在一个实施例中，移动计算设备110具有多触摸屏显示器116。在该实施例中，显示ID0与触摸屏显示器116中的一个相关联，并且显示ID1与另一个触摸屏显示器116相关联。显示ID2与两个触摸屏显示器116相关联（即应用被同时显示在两个显示器上）。大于2的显示ID是虚拟显示器，这意味着它们不与在移动计算设备硬件112上物理地存在的显示器相关联。用于Android应用的图形信息包括窗口、视图和画布。每个窗口、视图和/或画布是用基础的表面对象实现的。表面对象是用于绘制的双缓冲（前和后缓冲器）且同步的交叉过程。FurfaceFlinger维持允许Android内的所有过程在它们内访问且绘制而不用昂贵的复制操作且无需使用诸如X窗口的服务器侧绘制协议的共享存储器池中的所有表面。在SurfaceFlinger从前缓冲器读取时，应用总是绘制到后缓冲器中。SurfaceFlinger创建每个表面对象，维持所有表面对象，并且还为每个应用维持表面对象的列表。当应用完成后缓冲器中的绘制时，其将事件张贴到SurfaceFlinger，这将后缓冲器交换到前缓冲器，并且对将表面信息渲染到帧缓冲器的任务排队。SurfaceFlinger监视所有窗口改变事件。当一个或更多个窗口改变事件发生时，SurfaceFlinger将表面信息渲染到用于一个或更多个显示器的帧缓冲器。渲染包括合成表面，即基于表面的尺寸、透明度、z次序和可见性来合成最终的图像帧。渲染还可以包括硬件加速（例如用于图形处理硬件的OpenGL2D和/或3D接口）。SurfaceFlinger在所有表面对象上循环，并且以它们的Z次序将它们的前缓冲器渲染到帧缓冲器。图5更详细地图示了根据各个实施例的修改的Android内核520。修改的Android内核520包括触摸屏显示器驱动器521、相机驱动器（或多个）522、蓝牙驱动器（或多个）523、共享存储器分配器524、IPC驱动器（或多个）525、USB驱动器（或多个）526、WiFi驱动器（或多个）527、I/O驱动器（或多个）528、和/或电力管理模块530。I/O设备驱动器（或多个）528包括用于外部I/O设备的设备驱动器，所述设备包括可以通过端口120连接到移动计算设备110的设备。修改的Android内核520可以包括其他驱动器和功能块，包括低存储器消除器、内核调试器、记日志能力、和/或其他硬件设备驱动器。图6更详细地图示了根据各个实施例的HydroidOS660。Hydroid是能够运行针对标准Linux分布开发的几乎任何应用的全LinuxOS。具体地，HydroidOS660的库层662包括支持联网、图形处理、数据库管理和其他公共程序功能的Linux库。例如，用户库662可以包括“glibc”LinuxC库664、Linux图形库662（例如GTK、（OpenGL等）、Linux工具库661、Linux数据库库、和/或其他Linux用户库。应用使用X服务器674、窗口管理器673、和/或桌面环境672运行在X窗口Linux图形环境内的Hydroid上。图示的应用包括文字处理器681、电子邮件应用682、电子数据表应用683、浏览器684、以及其他应用（或多个）685。LinuxOS图形系统基于X窗口（或“X11”）图形系统。X窗口是独立于平台的联网图形框架。X窗口使用客户端/服务器模型，其中X服务器是图形服务器，并且应用是客户端。X服务器控制与LinuxOS相关联的输入/输出硬件，诸如显示、触摸屏显示器、键盘、指示设备（或多个）等。在该方面，X窗口提供服务器侧绘制图形体系结构，即X服务器维持包括窗口和像素映射的可绘制内容。X客户端通过经由通信信道交换描述绘制操作的数据分组来与X服务器通信。X客户端通过标准例程库（“Xlib”）来访问X通信协议。例如，X客户端可以向X服务器发送请求以在客户端窗口中绘制矩形。X服务器向X客户端发送输入事件，例如键盘或指示设备输入、和/或窗口移动或调整大小。输入事件与客户端窗口相关。例如，如果当指示器在窗口内时用户进行点击，则X服务器向与窗口相关联的X客户端发送包括输入事件的分组，包括与窗口相关的事件的动作和定位。因为在操作系统框架、图形系统和/或库中的差异，所以针对Android编写的应用通常不运行在HydroidOS660上，并且针对标准Linux分布编写的应用通常不运行在AndroidOS430上。在该方面，用于AndroidOS430和HydroidOS660的应用不是字节码兼容的，这意味着为一个编译且用于其的可执行程序不能运行在另一个上。在一个实施例中，HydroidOS660包括通过共享内核520促进与AndroidOS430的通信的跨环境通信框架的组件。这些组件包括IPC库663和远程通信服务671，IPC库663包括用于AndroidOS的BinderIPC机制的基础类。在一个实施例中，HydroidOS660在于Android根环境内创建的chrooted（利用“chroot”命令创建的）辅助执行环境中运行。HydroidOS660内的过程和应用运行在辅助执行环境内，使得这些过程和应用看到的表观根目录是辅助执行环境的根目录。以此方式，因为Linux用户库662可用于在chrooted辅助执行环境中的HydroidOS660上运行的过程，所以Hydroid660可以在不用修改的情况下运行针对标准Linux分布而编写的程序。返回参考图3，移动OS130和桌面160在移动设备上的共享内核上主动并发执行。移动OS130和桌面OS160可以关于用户库、图形系统、和/或应用框架不兼容。这意味着针对一个OS编译的（即对照那个OS的用户库等编译的）应用将不在另一个OS上执行。因此，OS体系结构300的移动OS130和桌面OS160通过经由单独的用户交互空间可访问的不同应用来提供单独的用户体验。在一些实例中，应用可用于提供与可用于桌面OS160的应用类似的功能的移动OS130。尽管单独的应用针对不同的OS而编译，但是这些应用从包括文档文件的用户数据的观点看可以是兼容的。在两种OS上可用（针对两种OS编译并加载在两种OS的执行环境内）的应用的示例可以包括web浏览器、电子邮件客户端应用、办公产品应用（例如文字处理、电子数据表、演示等）、图片和视频编辑应用、和/或其他应用。因此，对于用户来说，可以使用在移动OS130上运行的第一应用来编辑某个文档文件，随后使用在桌面OS160上运行的第二应用来编辑同一文档文件。然而，这不提供无缝的用户体验。为了在利用第一应用来编辑文档文件和使用第二应用来编辑该文档之间切换，用户必须利用第一应用关闭文档文件，启动桌面OS上的第二应用，并且利用第二应用来重新打开文档文件。在该过程中，用户丢失未保存在该文档文件中的与他们使用第一应用的当前状态相关的任何应用状态信息。这可能包括例如当前编辑或光标位置、当前视图、取消信息、当前编辑模式（例如具有标记或不具有标记进行查看等）、当前选择的文本、选择的菜单标签、应用选项（打开工具条、打印选项等）。本发明的实施例扩展OS体系结构300的功能，以通过跨越在不同OS上执行的应用共享应用状态信息来在多OS计算环境中提供更无缝的计算体验，使得它们提供单个表观上的应用交互状态。该功能例如使得用户能够从使用在第一OS中运行的第一应用与用户数据集的交互无缝切换到使用在第二OS中运行的第二应用与同一用户数据集的交互。特别地，维持当前的用户交互状态，以提供无缝的跨环境工作流。这意味着用户不必在切换到使用第二应用与用户数据交互之前关闭与用户数据相关联的应用文档。此外，跨越在单独的OS上运行的单独应用，维持可能不是应用文档文件的一部分的应用交互状态信息。例如，可以跨越在单独的OS中运行的应用来维持用户选择的对象或文本，使得用户可以利用在第一OS中运行的应用开始对用户数据集的用户动作，并且利用在第二单独的OS上运行的应用完成该动作。为了提供无缝的跨环境工作流，下面描述的实施例提供允许在独立的操作系统中运行的两个或更多个应用程序共享用户交互状态信息的方法和系统。实施例提供跨越在两个或更多个单独的操作系统中运行的应用来共享用户交互状态信息。共享的用户交互状态信息可以包括用户数据、用户设置、和/或应用上下文信息。以该方式，针对单独的OS编译并在其上运行的两个或更多个应用可以呈现单个表观上的用户交互状态。图7图示了扩展图3中图示的计算环境300的计算环境300a，以跨越在单独的操作系统中运行的应用提供应用数据、用户设置、和/或应用上下文的无缝转化。在计算环境300a中，应用752和754是针对移动OS130编译的并在其上运行。应用782和784是针对桌面OS160编译的并在其上运行，所述桌面OS160与移动OS130在共享内核320上并发运行。在移动OS130上可用的一个或更多个应用可以包括对于与在桌面OS160上可用的对应应用的应用数据的无缝转化的功能。例如，移动OS130的应用754可以是针对移动OS130编译的文字处理应用。桌面OS160的应用782可以是针对桌面OS160编译的兼容的（即兼容的文档文件类型）文字处理应用。计算环境300a包括用于跨越应用提供包含应用数据、应用用户设置、和/或应用上下文信息的当前应用交互状态的无缝转化的功能。在计算环境300a中，应用状态信息被存储在移动OS130的应用状态数据存储742内。尽管应用状态数据存储被图示为移动OS130的组件，但是应用状态数据存储742可以替选地是桌面OS160的组件。应用状态数据存储742可由在移动OS130内的应用和桌面OS160内的应用访问。在一个实施例中，应用状态数据存储742是由移动OS130的服务维持的数据库。通过共享内核320的过程间通信信道725来提供在桌面OS160上运行的应用与应用状态数据存储之间的通信。在于2011年8月24日提交的标题为“Cross-EnvironmentCommunicationFramework”的共同未决美国专利申请No.13/217,099和于2011年9月28日提交的标题为“Cross-EnvironmentCommunicationUsingApplicationSpaceAPI”的共同未决美国专利申请No.13/247,885中更详细地描述了提供用于桌面OS160的应用与移动OS130的服务和应用通信的通信信道的跨环境通信框架，每个专利申请的内容通过引用合并于此。然而，可以使用任何适当的过程间通信机制来提供由在桌面OS160上运行的应用对应用状态数据存储的访问。在图7中图示的实施例中，计算环境300a包括移动OS130的应用通信API758和桌面OS160的应用通信API788。应用通信API758和应用通信API788提供应用与应用状态数据存储742通信以设置和查询应用状态信息的低级别功能。使用这些功能，移动OS应用向下调用应用通信API758以设置和查询应用状态数据。例如，应用754调用具有名称/值对的API758的功能以设置和查询应用状态数据。桌面OS应用向下调用应用通信API788以设置应用状态数据并从应用状态数据存储742查询应用状态数据。计算环境300a的应用通信API可以在第一和/或第二OS内的应用空间中。例如，API758可以被实现为移动OS130的运行库。在一个实施例中，API758被实现为用于Android移动OS的Dalvik运行环境的JAR文件。在其他实施例中，计算环境300a的应用通信API可以在OS的应用可访问的用户库或其他库内。例如，在一个实施例中，桌面OS160的API788被实现为LinuxOS中的共享用户库。在替选实施例中，计算环境不包括移动OS130和桌面OS160中的API。在这些实施例中，应用直接与应用状态数据存储通信，以设置和查询应用状态信息。移动OS130和桌面OS160的应用也可以通过移动OS130或桌面OS160的服务与应用状态数据存储通信。图8-10图示了根据各实施例的计算环境300a如何允许无缝跨环境工作流。在图8图示的第一计算环境配置800a中，用户使用在移动设备110上的移动OS130上运行的第一电子数据表应用（“CALCAPP”）来主动与信息集（例如电子数据表文档）交互。桌面OS160在共享内核320上与移动OS130并发运行在移动设备上（移动设备110的处理器140上）。第一电子数据表应用的当前用户交互状态包括用户内容、用户设置、和应用上下文。用户内容可以包括用户正编辑的数据和数据的格式。用户内容可以被存储在在移动计算设备的非易失性存储介质上存储的文档文件824中。临时文档文件834也可以包含用户内容。在各实施例中，临时文档文件834包括用户尚未保存到文档文件824的用户内容。例如，临时文档文件834可以包括自用户最后保存到文档文件824以来的对用户文档进行的改变。值得注意的是，文档文件824和/或临时文档文件834可以替选地与移动计算设备远程存储。例如，实施例可以通过局域或非局域网将一些或所有数据存储在移动计算设备可访问的远程服务器上的外部存储（例如外部硬盘驱动、大拇哥霹雳碟（thumbdrive）等）中，或通过公共因特网将其存储在移动计算设备可访问的远程（例如“云”）存储上，或将其存储在任何其他有用的位置。其他实施例本地存储一些文件，并且非本地存储其他文件。再一些实施例本地存储非本地文件的副本（例如临时版本等），并且提供用于同步这些文件的额外功能（例如跟踪修改、执行其他文件管理任务等）。因此，在此参考本地存储的文件而描述的实施例旨在可应用于在非本地存储中存储一些或所有它们的文件的应用。在一些情况中，通过如下面更全面讨论的客户端-服务器交互等来促进远程文件的处理。用户设置包括用户选择的选项，诸如例如缺省的文档格式和视图、可视化菜单、热键、文档评论选项、证据选项、和/或用户定制。典型地，文档特定设置和选项被存储在文档文件中，而其他选项可以被存储在与应用程序相关联的文件中。在计算环境300a中，典型地被存储在与应用程序相关联的文件中的选项可以被存储在应用状态数据存储742中。应用上下文包括定义应用的当前用户交互状态的信息。例如，典型地不存储在文档或用户设置文件中的应用上下文信息可以包括当前的光标位置、选择的文本或对象、先前的用户动作（例如取消级别和动作）、当前视图、选择的菜单标签、和/或其他信息。在计算环境配置800a中，应用上下文信息包括光标位置855和选择的单元856。该应用上下文信息被维持在应用状态数据存储742中，并通过应用状态844被表示在计算环境配置800a中。此外，用户自最后保存文档文件824以来已输入了数据。例如，用户可能自最后保存用户文档以来已在计算环境配置800a中输入了公式。该信息被存储在临时文档文件834中。在使用移动设备上的第一电子数据表应用与信息集交互的某个时间段之后，用户将移动设备与第二用户环境（例如桌面用户环境）对接。例如，图9图示了根据各实施例的其中移动计算设备110与辅助终端环境940对接的计算环境配置800b。辅助终端环境940包括显示器944、键盘946、和指示设备948。在该方面，辅助终端环境940是类似桌面的终端环境。当通过对接接口940对接时，移动设备将桌面OS160与辅助终端环境940相关联，使得桌面OS的用户界面980被显示在第二用户环境940的显示器944上。如图9中所示，对接接口922可以包括对接支架941和/或对接线缆943。在该实例中，用户希望使用适合于第二用户环境的上下文的应用来继续与同一用户内容（即通过“File.ods”表示的电子数据表）交互，而不丢失用户交互状态。例如，虽然从文档文件类型的观点来看是可兼容的，但是可用于移动OS的应用在某些方面可以与可用于桌面OS的应用不同。这些差异可以包括屏幕分辨率、菜单、可视文档面积、功能等。由于这些原因，当移动计算设备对接到辅助终端环境时，用户可以容易使用桌面OS应用来编辑用户内容。图10图示了根据各实施例的示出计算环境700的各方面如何跨越在单独的操作系统上运行的多个应用来提供无缝工作流的计算环境配置800c。当用户将移动计算设备110对接到辅助终端环境940时，第一电子数据表应用854关闭文档文件824和临时文档文件834，并且关闭或暂停（不再使用移动OS130的计算资源），如图10中虚轮廓所示。应用1084启动桌面OS160，并访问应用状态数据存储742，以检索应用854的当前用户交互状态（即恰在移动计算设备110与辅助计算环境940对接之前的应用854的用户交互状态）。如上所述，用户交互状态信息844包括用户内容、用户设置、和应用上下文信息。用户交互状态信息844包括到包含用户内容信息的文档文件824和临时文件834的指针。第二电子数据表应用打开文档文件824和临时文档文件834，并且对应用状态信息844查询用户设置和应用上下文信息。例如，第二应用在其他应用上下文信息中检索光标位置855和活动单元856。因此，第二电子数据表应用1084在辅助终端环境上呈现应用窗口1086，其允许用户恰在他们离开第一应用854的地方处无缝地重拾与电子数据表用户数据的交互。使用类似的过程，当用户使移动计算设备解除对接时用户可以切换回使用在移动OS上运行的第一电子数据表应用854来编辑用户数据。在第一OS上运行的第一应用不必具有与在第二OS上运行的第二应用完全相同的用户接口来使用上述实施例呈现单个表观上的用户交互状态。例如，用户接口风格、与用户接口交互的方式、和/或用户接口组件可以不同，但是仍然被认为呈现单个表观上的用户交互状态。具体地，每个应用可以被适合于其所运行于的操作系统的上下文以及显示其的用户环境，同时共享单个表观上的用户交互状态。例如，移动应用可以被适合于在典型的移动计算环境中存在的基于触摸的用户输入和更小的显示屏。相比而言，桌面应用可以被适合于更大的屏幕和基于指示设备（或多个）的输入。例如，桌面文字处理应用可以比为移动OSGUI设计的文字处理应用具有更多的可视化菜单和菜单图标。然而，使用上述实施例，可以共享应用上下文信息以提供单个表观上的用户交互状态，所述单个表观上的用户交互状态向用户提供用于使用移动应用或桌面应用来编辑用户内容的无缝工作流。在上述实施例中，在单独的操作系统上运行的应用之间的切换和共享应用状态信息基于事件（例如对接、解除对接等）自动发生。也就是说，计算环境假定当用户对接移动设备时用户旨在切换到桌面应用。然而，在用户正与之主动交互的应用之间的切换可以作为用户提示的结果、或基于用户设置而发生。例如，当用户对接移动设备时，可以提示用户以确定他们是想继续与在移动OS上运行的第一应用交互、还是切换为通过在桌面OS上运行的第二应用与同一用户数据交互。替选地，用户设置可以确定：对于某些应用，当移动设备被对接时用户想自动切换；而对于其他应用，用户想被提示或不想被切换到桌面应用。在实施例中，在单独的OS上运行并共享单个表观上的用户交互状态的应用可以同时都在运行。例如，在移动OS130上运行的应用854可以正在运行并且通过与移动OS130相关联的用户环境呈现用户应用窗口。同时，应用1084正在桌面OS160上运行并且在与桌面OS160相关联的第二用户环境上呈现应用窗口1086。在该实例中，如上所述，应用854和1084可以共享用户设置和应用上下文信息。当应用上下文信息响应于用户对应用854和1084中的一个的输入而改变（即用户交互状态被更新）时，在应用状态数据存储742中更新应用上下文信息。应用状态数据存储742通过通知信道将该改变推送到其他应用，使得其他应用维持与第一应用一致的用户交互状态。为了在单独的操作系统并发运行应用，可以以几种方式来释放文档文件824和临时文档文件834上的锁。在一个实施例中，响应于在并发运行的应用中的一个中的用户输入，释放或建立文档文件。图11图示了根据各实施例的在单独的用户环境（例如运行在独立的操作系统上，每一个操作系统与单独的用户环境相关联）中显示的单独的应用之间的应用数据的无缝转化的过程流1100。过程流1100开始于框1102，其中在第一操作系统上运行的第一应用打开文档文件，文档文件的用户内容表示存储文档状态。在框1104，第一应用接受用户输入，并且作为该用户输入的结果，具有第一用户交互状态。在该第一用户交互状态中，文档具有修改的文档状态。也就是说，用户文档已被用户修改，变为修改的用户文档。在框1106，表示第一用户交互状态的应用状态信息被存储在第一计算环境内，应用状态信息包括应用上下文信息。在框1108，在不将修改的文档状态保存到文档文件的情况下，第一应用释放文档文件的文件锁。在框1110，在第二操作系统上运行的第二应用打开文档文件。在框1112，第二应用访问与第一用户交互状态相关联的应用状态信息。在框1114，第二应用应用所述应用上下文信息，以呈现与第一用户交互状态基本类似的第二应用的交互状态。作为应用应用上下文信息的结果，修改的文档已从在第一OS上运行的第一应用转化到在第二OS上运行的第二应用，其中维持了应用上下文。也就是说，用户不丢失他们当前工作的应用状态，而不用必须保存、关闭和重新打开该文件，并且不丢失未保存在文档文件中的应用上下文信息。在单独的操作系统上运行的应用之间的应用数据的无缝转化对于不同类型的应用存在不同的问题。上面提供的描述示出了对于主要用来创建和修改本地用户内容的应用类别可以如何跨越在多个单独的操作系统上运行的应用来提供无缝工作流。该类别包括例如文字处理应用、电子数据表应用、演示应用、以及图片和视频编辑应用等。另一类别的应用包括作为主要方面包含与远程服务器通信的应用。这些应用可以被称为是客户端-服务器型应用。例如，该类别可以包括客户端-服务器通信应用，诸如电子邮件客户端应用、web浏览器应用、基于云或“作为服务的软件”应用等。这些应用可以与主要对本地用户内容进行操作的应用不同地存储用户数据和设置。例如，电子邮件客户端应用可以连接到提供对电子邮件文件夹的存储的电子邮件服务器。电子邮件服务器可以维持大部分用户内容的文件夹，并且允许多个平台上的多个电子邮件客户端连接到服务器以与用户内容交互。该服务器可以将所接收的电子邮件推送到所连接的电子邮件客户端。因此，客户端-服务器型应用可以比主要对本地用户内容进行操作的应用本地地存储更有限的信息集。然而，应理解，应用本地存储一些信息并且非本地存储其他信息正变得越来越普遍。这样，根据其数据存储的类型对应用进行分类仅旨在使得对各实施例的功能的讨论更加清晰，而不旨在将任何实施例的范围限于落在仅仅单个功能类别内。例如，电子邮件客户端在某些使用情况中（例如当使用基于非web的电子邮件客户端来撰写电子邮件的本地保存的草稿时）可以更类似于应用的本地存储类型来动作，而同一电子邮件客户端在其他使用情况中（例如当与远程电子邮件服务器交换电子邮件数据时）可以更类似于客户端-服务器应用来动作。事实上，当应用是客户端-服务器类型应用（或更类似其动作）时，该应用可能需要提供在具有纯本地交互的应用中可能不需要的功能。例如，对于特定的客户端-服务器应用，多个客户端中的每一个可能需要从服务器发送和接收信息，同时维持单个的、基本统一的应用交互状态。在客户端-服务器上下文中的在多个客户端应用之间提供应用状态的无缝转化的一个实施例中，在第一操作系统（例如移动OS130）上运行的第一客户端应用（例如电子邮件客户端）通过通信协议（例如IMAP、POP3、Exchange等）与远程通信服务器通信。第一客户端将所有应用状态信息存储在第一操作系统上的应用状态数据存储中。例如，电子邮件客户端应用可以存储用户数据（例如电子邮件文件夹、草稿电子邮件、日程约定等）、用户设置（例如屏幕布局、消息外观、通知设置等）、以及应用上下文信息（例如当前光标位置、高亮的文本、取消信息和级别等）。作为与第一客户端应用的用户交互的结果，第一客户端应用具有当前用户交互状态。响应于事件（例如对接事件），第二客户端应用启动第二操作系统，并且连接到应用状态数据存储。第二应用从应用状态数据存储接收关于第一应用的当前用户交互状态的应用状态信息，包括用户内容、用户设置和应用上下文信息。也就是说，第二客户端应用不直接与服务器通信。相反，第一客户端应用执行与服务器的所有通信，并且将所有应用状态数据的本地副本维持在应用状态数据存储中。第二客户端应用从应用状态数据存储接收应用状态信息。在客户端-服务器上下文中在多个客户端应用之间提供应用状态的无缝转化的替选实施例中，在第一操作系统（例如移动OS130）上运行的第一客户端应用（例如电子邮件客户端）通过通信协议（例如IMAP、POP3、Exchange等）与远程通信服务器通信。第一客户端将应用状态信息存储在应用状态数据存储中。应用状态信息包括典型地不存储在远程服务器上的用户内容、用户设置和应用上下文信息。例如，电子邮件客户端应用可以存储用户设置（例如屏幕布局、消息外观、通知设置等）、以及应用上下文信息（例如当前光标位置、高亮的文本、取消信息和级别等）。作为与第一客户端应用的用户交互的结果，第一客户端应用具有当前用户交互状态。响应于事件（例如对接事件），第二客户端应用启动第二操作系统，连接到远程服务器，并且连接到应用状态数据存储以接收应用状态信息。例如，在第二OS上运行的电子邮件客户端应用可以连接到用于大部分用户内容（例如电子邮件文件夹、草稿电子邮件、日程约定等）的服务器，并且连接到用于额外应用状态信息的应用状态数据存储，所述额外应用状态信息包括用户设置（例如屏幕布局、消息外观、通知设置等）以及应用上下文信息（例如当前光标位置、高亮的文本、取消信息和级别等）。第二应用根据自远程服务器接收的用户内容和自应用状态数据存储接收的应用状态信息来重新构建第一应用的当前用户交互状态。一些其他类型的客户端-服务器应用提供接口和功能以导航和呈现基于因特网的内容。这些类型的应用可以包括例如web浏览器和基于云的应用（例如产品应用、文件管理和/或存储应用、流传输媒体应用、因特网无线电应用、基于IP的电话和/或会议应用等）。跨越在多个用户环境中运行的这些类型的应用来保持明显共同的应用交互状态可以与涉及纯本地应用的那些情况存在不同和/或额外的问题。例如，web浏览器可以维持与用户设置和浏览器的会话相关的充足量的信息。此外，web内容能够是高度动态和交互性的（例如CSS、flash动画、小程序、Javascript、表格等）。Web浏览器也可以在浏览器内运行应用（例如，小程序等），具有或支持对插件的多样化访问等。在一些实例中，web浏览器可以被用作操作系统内的虚拟操作系统（例如小程序、基于云的应用）。另外，web浏览器可以用以提供安全会话和/或其他安全通信、用户认证和/或跟踪等。为了说明而返回图8-10，移动浏览器在移动OS130上作为应用854运行，并且正通过与移动OS130相关联的用户环境呈现用户应用窗口。桌面OS160在共享内核320上与移动OS130一起并发运行在移动设备上（在移动设备110的处理器114上）。移动浏览器应用的当前用户交互状态包括用户内容、用户设置和应用上下文。关于移动浏览器应用的用户内容可以包括cookie、令牌、用户数据（例如提供到表格等）、和/或与浏览器相关地为用户或由用户生成的任何其他信息（例如包括任何实现浏览器的应用或会话）。用户设置可以包括主页设置、保存的浏览历史、保存的书签或收藏、代理设置和/或与浏览器相关地为用户存储的任何其他信息）。应用上下文可以包括关于浏览器的当前状态信息。在一些实施例中，应用上下文仅包括当前显示的URL。在其他实施例中，应用上下文包括额外信息，诸如当前选择的文本、当前的指针位置等。在某个时间，用户将移动计算设备110对接到辅助终端环境940（例如如图9中图示的）。可能期望将用户的交互上下文信息从移动浏览器切换到在桌面OS160上运行的桌面浏览器应用1084，并且在与桌面OS160相关联的第二用户环境上呈现应用窗口1086（例如如图10中图示的）。移动浏览器应用854和桌面浏览器应用1084可以如上所述共享用户设置和应用上下文信息。在一些情况下，共享的应用上下文涉及仅转移当前的URL；而在其他情况下，发生更高级的上下文共享，如下面更全面描述的。如上面所讨论的，可以在应用状态数据存储742中更新应用上下文信息，并且在期望时，应用状态数据存储742可以通过通知信道将该改变推送到其他应用以维持一致的用户交互状态。多个浏览器特定问题可以由不同的实施例以不同的方式来处理。一个这样的问题是许多web服务器被配置为对于不同类型的浏览器转移不同的内容（或以不同的格式显示的相同内容）。对于移动对桌面类型的浏览器来说，这可能尤为适用，因为许多网页不同地被设计为开发不同的用户交互环境（例如在显示尺寸、分辨率、对类似Flash的插件的支持等的差异）。来自浏览器的对网页的HTML请求可以包括识别浏览器特征的“代理串”，包括浏览器类型。Web服务器能够取决于代理串是否指示该请求来自移动对桌面浏览器而不同地对请求进行响应。假设用户正在通过移动浏览器应用在移动设备上观看网页的移动版本，并且然后用户与桌面环境对接。在一个方案中，网页的移动版本被显示在桌面环境上，作为移动浏览器的远程渲染的窗口。例如，在于2011年9月27日提交的标题为“InstantRemoteRendering”的美国专利申请No13/246,665中描述了用于以此方式远程渲染的技术，其全部内容通过引用合并于此。可以将该类型的远程渲染实现为对于对接事件之前正观看的所有页面的缺省状况。替选地，可以在做出将不渲染网页的移动版本（例如从桌面浏览器请求网页的移动版本将导致错误）或网页将以不适当或不期望的方式渲染的确定之后调用远程渲染。在另一个方案中，网页的移动版本的URL被转移到桌面浏览器作为上下文信息。桌面浏览器然后可以再次请求URL和/或使用任何缓存的信息（例如其可以被存储为用户数据或上下文信息）。取决于网页的实现，可能有多个结果。例如，桌面可以能够显示从web服务器返回的信息，web服务器可以返回指示浏览器与该请求不兼容的错误，web服务器可以重新解释该请求并返回所请求的网站的桌面版本等。替选地，桌面浏览器可以被配置为改变请求中的代理串以作为移动浏览器出现。另一个这样的与浏览器相关的问题能够在用户正通过SSL会话与内容交互等时发生。一些实施例可以简单地不允许将该会话转移到桌面环境（例如到桌面浏览器），并且可以例如返回错误、报警或其他指示。其他实施例通过代理服务器建立SSL会话，代理服务器可以有效地将SSL会话路由到适当的移动或桌面浏览器。例如，代理服务器可以被配置为作为网络地址翻译器（NAT）来动作，网络地址翻译器处理SSL会话并将会话通信路由（例如安全地）到移动或桌面浏览器中的一个或更多个。还一些实施例从移动浏览器向桌面环境远程地渲染SSL会话，如上面所讨论的。这些实施例中的任何一个可以进一步包括在执行功能以处理SSL会话之前检测SSL会话。还一个这样的与浏览器相关的问题能够在对接事件之前在用户正与涉及cookie的网页交互等时发生。根据一些实施例，cookie信息在对接后转移到桌面浏览器环境或被存储为桌面浏览器可访问的上下文信息。某些类型的cookie等不能转移（或至少不能以可靠或有用的方式转移）。因此，一些实施例通过忽略它、或在可能的情况下将其翻译成可转移的信息等来处理该类型的cookie信息。可以通过各实施例在用户认证信息、令牌等的上下文中处理类似的方案。例如，在用户已登录到的网页的情况下，在对接之后，桌面浏览器可以取决于网页源代码的实现等将用户返回到登录页或无附带事件地显示页面。替选地，可以检测该类型的用户认证，并且对接事件可以导致交互环境的转移被另外处理（例如通过远程渲染、通过代理服务器处理等）。还另一个这样的与浏览器相关的问题能够在用户正与涉及用户数据的基于web的内容交互时发生。取决于内容的实现，用户数据可以被本地和/或非本地存储。例如，基于web的产品应用（例如文字处理器、电子数据表应用等）、游戏等可以包括当前的用户状态、选择的文本、设置等。实施例典型地如上所述地处理本地存储的数据。关于非本地的数据，一些实施例可以在对接之后当需要时重新请求关于新浏览器环境的数据，或当实际上不能重新请求数据时忽略它。又另一个这样的与浏览器相关的问题能够在用户正并发地与多个网页交互（例如主动地交互或仅仅是打开）时发生。典型地，移动浏览器被配置为每次只显示单个网页（或非常有限数目的网页），而桌面浏览器能够使用多个浏览器窗口和/或多个标签来每次显示许多网页。一些实施例将在移动浏览器中每个打开的网页转移到桌面浏览器中的新标签或窗口（例如根据用户设置、缺省设置等）。如上面所讨论的，可能出现其中网页不能从移动环境被简单地转移（或不能以期望方式（转移）到桌面环境的许多情况。根据某些实施例，独立地对待要转移的每个网页。例如，对于不能被简单地转移的每个网页，网页也不被转移（例如仅保持在移动环境上），通过远程渲染被显示，被翻译为适当的桌面版本，通过代理被路由等。图12图示了根据各实施例的在客户端-服务器上下文中在多个客户端应用之间无缝转化应用状态的过程流1200。过程流1200开始于框1202，其中用户设置和应用上下文信息与在第一计算环境的第一操作系统上运行的第一客户端/服务器应用相关地被维持在第一计算环境中，其中第一计算环境被配置为在共享内核上并发运行第一操作系统和第二操作系统。在框1204，根据用户设置和应用上下文信息经由第一计算环境显示第一客户端-服务器应用的第一用户交互环境，第一用户交互环境反映当前的交互状态。在框1206，检测指示移动计算环境与桌面计算环境对接的对接事件。在框1208，在第二操作系统中运行的第二客户端-服务器应用应用所述应用上下文信息，以在基本反映当前交互状态的第二计算环境的显示器上经由第二客户端-服务器应用来呈现第二用户交互环境。通过过程流1200，用户能够从第一计算环境中的第一客户端/服务器应用无缝切换到第二计算环境中的第二客户端/服务器应用，而不丢失当前的交互状态。应理解，上述问题和方案仅旨在说明可能的情况和用于处理这些情况的技术。许多其他类似情况是可能的，并且能够根据上述的技术来处理。此外，具体应用网页的描述在大多数情况中也可以对于诸如基于web（例如基于云、作为服务的软件等）游戏和应用的其他基于web的内容被类似地处理。因此，不应将客户端-服务器应用的上面特定描述认为限制在此描述的实施例的范围。处于说明和描述的目的呈现了前面的描述。此外，该描述不旨在将本发明的实施例限于在此公开的形式。虽然上面已讨论了许多示范性方面和实施例，但是本领域技术人员将认识到其某些变化、修改、置换、增加和子组合。上述的方法的各种操作可以由能够执行对应功能的任何适当装置来执行。所述装置可以包括各种硬件和/或软件组件和/或模块，包括但不限于电路、专用集成电路（ASIC）或处理器。所描述的各种图示的逻辑块、模块和电路可以利用被设计为执行在此描述的功能的通用处理器、数字信号处理器（DSP）、ASIC、现场可编程门阵列信号（FPGA）、或其他可编程逻辑设备（PLD）、离散门、或晶体管逻辑、离散硬件组件或其组合来实现和执行。通用处理器可以是微处理器，但是替选地，处理器可以是任何商业可获得的处理器、控制器、微控制器、或状态机。处理器也可以被实现为计算设备的组合，例如DSP和微处理器的组合；多个微处理器；与DSP核心结合的一个或更多个微处理器；或任何其他这样的配置。结合本公开描述的方法或算法的步骤可以被直接实现在硬件中、右处理器执行的软件模块中、或这两者的组合中。软件模块可以以任何形式的有形存储介质存在。可以使用的存储介质的一些示例包括随机存取存储器（RAM）、只读存储器（ROM）、闪速存储器、EPROM存储器、EEPROM存储器、寄存器、硬盘、可移动盘、CD-ROM等。存储介质可耦接到处理器，使得处理器能够从存储介质读取信息，或向存储介质写入信息。替选地，存储介质可以集成到处理器。软件模块可以是单个指令，或许多指令，并且可以分布在若干不同的代码段上、不同的程序中、以及在多个存储介质上。在此公开的方法包括用于获得所描述的方法的一个或更多个动作。该方法和/或动作可以彼此交换，而不背离权利要求的范围。换句话说，除非指定了特定次序，否则可以修改特定动作的次序和/或使用，而不背离权利要求的范围。所描述的功能可以实现在硬件、软件、固件或其任何组合中。如果实现在软件中，功能可以作为一个或更多个指令被存储在有形的计算机可读介质上。存储介质可以是能够由计算机访问的任何可获得的有形介质。通过示例的方式，并且不是限制，这样的计算机可读介质可以包括RAM、ROM、EEPROM、CD-ROM，或其他光盘存储、磁盘存储或其他磁存储设备，或能够用来执行或存储以指令或数据的形式的期望程序代码以及能够由计算机访问的其他有形介质。在此使用的磁盘和光盘包括压缩盘（CD）、激光盘、光盘、数字多媒体盘（DVD）、软盘和，其中磁盘通常磁性地再现数据，而光盘利用激光光线地再现数据。因而，计算机程序产品可以执行在此呈现的操作。例如，这样的计算机程序产品可以是在其上有形地存储（和/或编码）有指令的计算机可读的有形介质，指令可由一个或更多个处理器执行以执行在此描述的操作。计算机程序产品可以包括封装材料。也可以通过传输介质来发送软件或指令。例如，可以使用诸如同轴电缆、光纤、双绞线、数字订户线（DSL）的传输介质或诸如红外、无线电或微波的无线技术来从网站、服务器或其他远程源来发送软件。另外，在可应用的情况下，能够用户终端和/或基站下载和/或以其他方式获得用于执行在此描述的方法和技术的模块和/或其他适当装置。例如，这样的设备可以耦接到服务器，以便利用与执行在此描述的方法的装置的转移。替选地，能够经由存储装置（例如RAM、ROM、诸如CD或软盘的物理存储介质等）提供在此描述的各种方法，使得用户终端和/或基站能够在耦接到设备或向设备提供存储装置后获得各种方法。此外，可以利用用于提供在此描述的方法和技术的任何其他适当的技术。其他示例和实现在本公开或所附权利要求的范围和精神内。例如，由于软件的本质，能够使用由处理器、硬件固件、硬连线或任何这些的组合执行的软件来实现上面描述的功能。实现功能的特征也可以物理地位于各位置，包括被分发使得功能的部分被实现在不同的物理位置。而且，如在此使用的，包括权利要求，在“至少一个”开始的项目列表中的使用的“或”指示选言列表，使得例如“A、B或C中的至少一个”的列表意味着A或B或C或AB或AC或BC或ABC（即A和B和C）。另外，术语“示范性”不意味着所描述的方法是优选的或比其他示例好。在不背离如所附权利要求中定义的教导的技术的情况下，可以进行对在此描述的技术的各种改变、替换和修改。此外，本公开和权利要求的范围不限于上面描述的过程、机器、产品、物质成分、装置、方法和动作的特定方面。也可以利用目前存在的或以后开发的执行与在此描述的相应方面基本相同的功能或获得基本相同的结果的过程、机器、产品、物质成分、装置、方法和动作。因此，所附权利要求包括在其范围内的这样的过程、机器、产品、物质成分、装置、方法和动作。当前第1页1 2 3