CN110780871A - 一种负一屏加载方法、装置、终端及计算机可读存储介质 - Google Patents

一种负一屏加载方法、装置、终端及计算机可读存储介质 Download PDF

Info

Publication number
CN110780871A
CN110780871A CN201810856248.6A CN201810856248A CN110780871A CN 110780871 A CN110780871 A CN 110780871A CN 201810856248 A CN201810856248 A CN 201810856248A CN 110780871 A CN110780871 A CN 110780871A
Authority
CN
China
Prior art keywords
screen
negative
loading
code
resource
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN201810856248.6A
Other languages
English (en)
Inventor
张南
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
ZTE Corp
Original Assignee
ZTE Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by ZTE Corp filed Critical ZTE Corp
Priority to CN201810856248.6A priority Critical patent/CN110780871A/zh
Priority to US17/261,169 priority patent/US11966795B2/en
Priority to PCT/CN2019/098638 priority patent/WO2020024989A1/zh
Publication of CN110780871A publication Critical patent/CN110780871A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/542—Event management; Broadcasting; Multicasting; Notifications
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G06F8/38—Creation or generation of source code for implementing user interfaces
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44505—Configuring for program initiating, e.g. using registry, configuration files
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/451—Execution arrangements for user interfaces
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45537—Provision of facilities of other operating environments, e.g. WINE
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/541—Interprogram communication via adapters, e.g. between incompatible applications
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45566—Nested virtual machines
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45583—Memory management, e.g. access or allocation

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Human Computer Interaction (AREA)
  • Multimedia (AREA)
  • User Interface Of Digital Computer (AREA)
  • Stored Programmes (AREA)

Abstract

本发明实施例提供一种负一屏加载方法、装置、终端及计算机可读存储介质，剥离了原本混杂的负一屏代码与桌面容器代码，使得二者独立。在加载负一屏时，先将负一屏代码和负一屏资源分别加载到虚拟机，然后创建负一屏的运行上下文来替换桌面容器的运行上下文，并根据负一屏的运行上下文加载出负一屏。由于负一屏的运行上下文中包括负一屏资源的资源获取途径，因此，在虚拟机运行负一屏代码时，可以获取负一屏对应的资源，从而在负一屏代码与桌面容器代码独立的情况下完成负一屏的加载。在保证负一屏正常加载的同时，减小了负一屏业务逻辑与桌面容器业务逻辑的耦合度，降低了负一屏与桌面容器版本维护成本，有利于了负一屏与桌面容器各自的版本更迭。

Description

一种负一屏加载方法、装置、终端及计算机可读存储介质
技术领域
本发明涉及终端技术领域，尤其涉及一种负一屏加载方法、装置、终端及计算机可读存储介质。
背景技术
手机桌面作为用户手机中所有应用的入口，是一些手机系统中最基础、最重要、使用最频繁的应用之一。作为操作系统的“门面”，各大手机厂商也都根据的自己的产品风格设计着自己独特的手机桌面，力争为用户提供更加简单实用的功能、更加美观的界面、以及更加便捷的服务。
不过由于Launcher(桌面启动器)桌面以宫格的形式来展示所有的应用，故展现方式很单一，无法为用户提供更加丰富、多样的其他服务。在此基础上，Google提出了“负一屏”的概念，即在原来的桌面屏最左端添加一屏。由于原来第一屏在代码实现中是以“0”为序号的，故在第一屏左边所加的屏的序号就是“-1”，故称负一屏。由于负一屏有着自己特殊的优势，如进入简单，可呈现的内容样式丰富，可以为用户提供好多便捷操作，还可以接入第三方业务，实现软件营收等。因此目前各个手机厂商和市面上的操作系统桌面都会开发其自己的负一屏，而且也在不断的持续优化和改进中，旨在为用户提供便捷、实用的功能。
不过目前负一屏的代码和Launcher桌面容器的代码是混杂在一起的，二者的业务逻辑也是耦合在一起的，这使得负一屏与桌面容器的版本维护代价高，非常不利于负一屏与桌面容器各自的版本更迭。
发明内容
本发明实施例提供的一种负一屏加载方法、装置、终端及计算机可读存储介质，主要解决的技术问题是：相关技术中负一屏的代码和桌面容器的代码混杂，业务逻辑耦合度高，不利于二者的版本更迭。
为解决上述技术问题，本发明实施例提供一种负一屏加载方法，包括：
将负一屏代码和负一屏资源分别加载到虚拟机，负一屏代码与桌面容器代码独立；
创建负一屏的运行上下文并替换桌面容器的运行上下文，负一屏的运行上下文中包括负一屏资源的资源获取途径；
根据负一屏的运行上下文加载负一屏。
本发明实施例还提供一种负一屏加载装置，包括：
代码资源加载模块，用于将负一屏代码和负一屏资源分别加载到虚拟机，负一屏代码与桌面容器代码独立；
运行环境创建模块，用于创建负一屏的运行上下文并替换桌面容器的运行上下文，负一屏的运行上下文中包括负一屏资源的资源获取途径；
负一屏加载模块，用于根据负一屏的运行上下文加载负一屏。
本发明实施例还提供一种终端，终端包括处理器、存储器及通信总线；
通信总线用于实现处理器和存储器之间的连接通信；
处理器用于执行存储器中存储的一个或者多个程序，以实现如上的负一屏加载方法的步骤。
本发明实施例还提供一种计算机可读存储介质，其特征在于，计算机可读存储介质存储有一个或者多个程序，一个或者多个程序可被一个或者多个处理器执行，以实现如上的负一屏加载方法的步骤。
本发明的有益效果是：
根据本发明实施例提供的负一屏加载方法、装置、终端及计算机可读存储介质，剥离了原本混杂在一起的负一屏代码与桌面容器代码，使得二者独立。在加载负一屏时，先将负一屏代码和负一屏资源加载到虚拟机，然后创建负一屏的运行上下文来替换桌面容器的运行上下文，并根据负一屏的运行上下文加载出负一屏。由于负一屏的运行上下文中包括负一屏资源的资源获取途径，因此，在虚拟机运行负一屏代码时，可以获取负一屏对应的资源，从而在负一屏代码与桌面容器代码独立的情况下，实现将负一屏显示在桌面容器的效果，完成负一屏的加载。在保证负一屏正常加载的基础上，减小了负一屏业务逻辑与桌面容器业务逻辑的耦合度，降低了负一屏与桌面容器版本维护成本，有利于了负一屏与桌面容器各自的版本更迭。
另外，由于负一屏需要请求的默认权限比较多，而Google的测试对桌面所请求默认权限的限制较大，因此本发明实施例中负一屏与桌面容器业务逻辑独立，因此可以使得负一屏所请求的默认权限与桌面无关，默认权限获取不受Google测试的限制，从而轻松获取期望的默认权限。
本发明其他特征和相应的有益效果在说明书的后面部分进行阐述说明，且应当理解，至少部分有益效果从本发明说明书中的记载变的显而易见。
附图说明
图1为本发明实施例一中提供的负一屏加载方法的一种流程图；
图2为本发明实施例一中提供的普通屏的一种结构示意图；
图3为本发明实施例一中提供的负一屏的一种结构示意图；
图4为本发明实施例一中提供的负一屏私有数据区数据读取的一种流程图；
图5为本发明实施例一中提供的负一屏私有数据区数据写入的一种流程图；
图6为本发明实施例二中提供的负一屏加载方法的一种流程图；
图7为本发明实施例三中提供的负一屏加载装置的一种结构示意图；
图8为本发明实施例三中提供的负一屏加载装置的另一种结构示意图；
图9为本发明实施例三中提供的负一屏加载装置的又一种结构示意图；
图10为本发明实施例四中提供的终端的一种结构示意图；
图11为图10中终端所在通信网络系统的一种系统架构图。
具体实施方式
为了使本发明的目的、技术方案及优点更加清楚明白，下面通过具体实施方式结合附图对本发明实施例作进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。
实施例一：
为了解决相关技术中因将负一屏代码和桌面容器代码混在一起，导致负一屏的业务逻辑与桌面容器业务逻辑耦合，无法单独对负一屏进行升级，导致负一屏的版本维护成本高的问题，本实施例提供一种负一屏加载方法，请参见图1示出的负一屏加载方法的流程图：
步骤S102：将负一屏代码和负一屏资源分别加载到虚拟机。
在本实施例中，负一屏代码和桌面容器代码是独立的，二者没有混杂在一起：桌面容器有自己的安装包，例如Apk(AndroidPackage，安卓安装包)，同样的，负一屏也有自己独立的安装包。本实施例中要将负一屏加载到桌面容器中，使得用户在第一屏上进行触控可以正常进入到负一屏，让代码独立的负一屏可以如同相关技术中的负一屏一样向用户提供业务服务。这里可以将负一屏视作桌面容器的一个插件，插件化的负一屏最终会运行在桌面容器中，下面以Launcher桌面为例，对Launcher桌面的结构进行简单介绍，请参见图2和图3：
在引入负一屏之后，Launcher桌面分为负一屏和普通屏，可以理解的是普通屏的数目可以不只一个。图2示出的是普通屏20的结构示意图，在普通屏20中包括工作空间(Workspace)21、热门位置(Hotseat)22以及导航点23。Workspace21是一个可左右滑动的组件，在普通屏20中它是应用图标的容器，应用图标可以在Workspace 21内部被拖拽。导航点23用于指示当前处于哪一个普通屏。Hotseat 22用于存放一些很常用的应用图标，在包括两个或多个普通屏的情况下，在用户控制Workspace 21左右滑动时，普通屏20中Hotseat22不会随着Workspace 21的移动而移动。
图3示出的是负一屏30的结构示意图，在负一屏30中包括桌面容器31、负一屏根布局32，负一屏根布局32运行在桌面容器31中。负一屏30的显示布局不再受普通屏20显示布局样式的限制：例如，负一屏30可以支持上下滑动，相较于普通屏20的显示内容，负一屏30可以向用户呈现更多的内容。而且，负一屏30显示的内容不限于各种应用图标，例如负一屏30可以接入第三方业务，实现软件营收。
为了实现负一屏的加载，需要将插件安装包中的代码，也即负一屏代码加载到虚拟机中。可以理解的是，将负一屏代码加载到虚拟机中，实际上就是将负一屏代码中的class(类)文件加载到Java虚拟机中。而在Android的编译系统中，对class文件做了进一步的处理，使其变成dex文件。dex文件是Android平台上的可执行文件，相当于Windows平台中的exe文件。每个Apk安装包中都有dex文件，里面包含了该安装包的所有源码，所以，加载插件安装包中的代码，实质就是加载这个插件安装包中的dex文件。
在加载class的时候，可以采用ClassLoader(类加载器)进行，为了加载dex文件，就可以采用DexClassLoader(Dex类加载器)，DexClassLoader是一个继承于ClassLoader的类。所以，在本实施例中，终端可以采用DexClassLoader来加载负一屏的dex文件，具体地，DexClassLoader从负一屏的安装包中加载dex文件。
在DexClassLoader将负一屏的dex文件加载到虚拟机之后，实际上就将负一屏对应的class加载到虚拟机中了，在这种情况下，终端虚拟机可以采用反射加载的方式加载出负一屏的根布局：虚拟机从已加载的class中找到加载负一屏根布局的方法，从而根据该方法加载出负一屏的根布局。
在将负一屏代码加载到虚拟机后，还需要将负一屏资源也加载到虚拟机中。负一屏资源(Resource)包括文字、图片、词条等。在安卓系统中，可以采用getResource方法获取对应的Resource对象，而创建Resource对象时所需的各种参数需要通过Asset Manager(资源管理器)来传入。所以，在本实施例中，为了加载负一屏资源，终端可以先构建AssetManager，然后通过Asset Manager构建Resource对象，再根据Resource对象加载负一屏资源到虚拟机。
步骤S104：创建负一屏的运行上下文并替换桌面容器的运行上下文。
虽然通过S102，终端可以将负一屏的代码和资源加载到虚拟机中，但是由于在DexClassLoader将负一屏Apk中的dex文件加载到桌面容器进程中，反射加载负一屏根布局时传入的是桌面容器的Context(运行上下文)。因此，在这种情况下，负一屏代码在桌面容器的进程中运行，实际上是处于桌面容器的运行环境中，负一屏在获取资源时只能获取到桌面容器的资源。其本身的各种资源(如图片、布局、词条等)在桌面容器的资源中是无法被找到的。
所以，为了保证负一屏在运行时，可以获取到其本身的资源，在本实施例中，当终端将负一屏资源加载到虚拟机之后，还需要对表征负一屏运行环境的Context进行处理：终端创建属于负一屏的Context，例如终端自定义Mcontext，Mcontext继承于ContextWrapper(运行上下文封装器)，其作为负一屏的Context，其中包括有负一屏资源的资源获取途径。
步骤S106：根据负一屏的运行上下文加载负一屏。
在终端创建了负一屏的Context之后，可以根据该Context加载负一屏。可以理解的是，根据负一屏的运行上下文加载负一屏，实际上就是根据负一屏的运行上下文运行负一屏代码，并在代码运行过程中引用负一屏资源，向用户呈现负一屏。或者说，就是虚拟机在负一屏运行上下文所对应的运行环境中，运行负一屏代码，引用负一屏资源向用户提供负一屏服务。此时，负一屏运行在属于负一屏的运行环境中，可以获取到自己的资源，而非运行在桌面容器的运行环境中，只能获取桌面容器的资源。
通过上述过程，可以实现负一屏的加载，不过由于负一屏与桌面容器属于不同的进程，因此二者之间无法进行直接通信，这会使得桌面容器无法将用户滑入负一屏以及用户滑出负一屏等事件通知给负一屏。可以理解的是，如果负一屏可以了解用户何时滑入，则其可以在用户滑入的时候进行内容更新，以便给用户提供最新、最实时的业务服务。同时，如果负一屏了解用户何时滑出，则其可以及时地释放内存，结束某些监听，从而避免资源占用，资源浪费。因此，如果负一屏不能与桌面容器通信，负一屏可能只能定时进行内容更新以及资源释放等，无法给用户提供优质的业务服务，这样容易导致用户体验不高，所以，为了让负一屏了解用户的滑入、滑出等事件本实施例提供一种通信方法：
终端可以调用View(用户界面)事件分发机制中的dispatch Key Event(关键事件调度)实现桌面容器与负一屏间的通信：当桌面容器监测到有针对负一屏的事件时，可以调用dispatch Key Event向负一屏分发事件。可以理解的是，dispatch Key Event不仅用于向负一屏分发事件，而且还会向桌面容器分发属于普通屏的事件(又称系统事件)。所以，在dispatch Key Event进行事件分发的时候，需要区分当前待分发的事件是属于普通屏还是属于负一屏。
在本实施例中，终端可以通过事件属性信息来进行区分当前待分发事件是属于负一屏还是系统原有事件。事件属性信息包括事件类型(action)与信息码(code)，其中，action包括按键按下事件、按键弹起事件等；而code则用于指示是针对哪一按键的事件。为了区分负一屏事件与系统原有事件，桌面容器中父view在分发事件前可以保证二者的事件属性信息不同。这样，当dispatch KeyEvent进行事件分发时，可以根据事件属性信息确定当前的事件是否属于负一屏。可以理解的是，只要负一屏事件的事件属性信息中有一个信息与系统事件的事件属性信息中的不同，则可以达到区分的目的。当然，在本实施例的一些示例中，可以让负一屏事件的action、code均不同于系统各事件的action、code。
由于系统事件的事件类型与信息码通常是正数或者是非负数，所以在本实施例的一些示例当中，为了便于区分可以将负一屏事件的事件属性信息中的至少一个信息设置为负数，这样，当dispatch Key Event确定当前待分发的事件的事件属性信息中包括负数，则可以直接确定该事件是负一屏的事件。例如，在本实施例的一个示例中，负一屏事件的action、code均为负数，而系统事件的action、code均为正数。
在本实施例中，负一屏的代码运行在桌面容器进程中，因此无法直接从负一屏的私有数据区中读写数据。在一些相关的方案当中，针对这种情况，是借助AIDL(AndroidInterface Definition Language，Android接口定义语言)和Service(服务)来完成跨进程通信的，不过这种方案存在以下几个缺陷：
1)在负一屏运行的过程中，需要持续保证Service存活。换言之，负一屏在有借助Service进行数据读写的需求时，需要先判断Service是否处于运行状态，若判断Service处于运行状态，则可正常读取数据；否则，必须要要先启动Service，然后才能进行数据读写。也就是说，本次数据读写需求是无法被正常响应的。
2)由于在加载负一屏根布局时，可能需要负一屏私有数据区中保存的数据。如果在加载负一屏根布局的时候Service没启动起来，就无法加载负一屏。在这种情况下，负一屏的加载流程会被打断，会导致负一屏加载时间变长。
3)由于这种从负一屏私有数据区进行数据读写的方案是基于Service和AIDL进行的，所以，当有数据读写需求时，就需要给AIDL扩展对应的接口，Service中也得实现该接口。这样第三方aar(Android Archive，安卓二进制归档文件)包要想读数据的话也需要通过回调的方式来为其提供接口，这样会使得逻辑复杂，耦合度高。
为了避免上面的各种问题，本实施例还提供另一种在负一屏私有数据区进行数据读写的方案：
终端采用Content Provider(内容提供器)来封装形成第一SharedPreferences(共享偏好)接口，并采用该第一SharedPreferences接口替换掉加载负一屏根布局时反射传入的Context(即桌面容器的Context)中的Shared Preferences接口。换言之，在负一屏的运行上下文Mcontext中，还可以包括第一SharedPreferences接口，对于负一屏而言，其可以拥有两个SharedPreferences接口，一个即是上述采用Content Provider封装形成的第一SharedPreferences接口；另一个是真正的SharedPreferences接口，这里将其称为第二SharedPreferences接口。在负一屏加载完成后，可以通过第一Shared Preferences接口以及负一屏的第二Shared Preferences接口实现在负一屏的私有数据区的数据读写。
先对从负一屏的私有数据区中进行数据读取的流程进行简单介绍，请参见图4：
步骤S402：通过第一Shared Preferences接口接收桌面容器发送的针对第一目标数据的读取请求。
当桌面容器有从负一屏私有数据区进行数据读取的需求时，可以通过第一SharedPreferences接口向负一屏发送针对第一目标数据的读取请求，可以理解的是，在该读取请求中可以包括用于对待读取的第一目标数据进行指示的信息。
步骤S404：通过第二Shared Preferences接口根据读取请求从私有数据区中读取第一目标数据。
在通过第一Shared Preferences接口接收到来自桌面容器的读取请求后，负一屏可以采用第二Shared Preferences接口按照读取请求从私有数据区中读取第一目标数据。
步骤S406：通过第一Shared Preferences接口将第二Shared Preferences接口读取的第一目标数据发送给桌面容器。
在第二Shared Preferences接口从负一屏的私有数据区中读取到第一目标数据之后，可以再次通过第一Shared Preferences接口将读取到的第一目标数据发送给桌面容器。
下面结合图5示出的数据写入流程图对向负一屏私有数据区中写入数据的过程进行介绍：
步骤S502：通过第一Shared Preferences接口接收桌面容器发送的写入请求。
当桌面容器需要将第二目标数据写入到负一屏的私有数据区时，桌面容器可以通过第一Shared Preferences接口向负一屏发送写入请求，在该写入请求中至少包括待写入的第二目标数据。
S504：控制第二Shared Preferences接口将第二目标数据写入到私有数据区。
在负一屏通过第一Shared Preferences接口接收到桌面容器发送的写入请求之后，可以对写入请求进行解析得到第二目标数据，然后负一屏通过第二SharedPreferences接口将第二目标数据写入到私有数据区中。
从图4示出的数据读取流程和图5示出的数据写入流程中可以看出，第一SharedPreferences接口相当于是桌面容器与负一屏之间跨进程通信的桥梁，而第二SharedPreferences接口则主要是实现负一屏与私有数据区之间的通信。对于第三方而言，其直接调用第一Shared Preferences接口即可实现负一屏私有数据区中数据的读写，并不会感知到桌面容器与负一屏之间存在跨进程通信，因此减小了与第三方的耦合。
本实施例中提供的负一屏加载方法，在将负一屏代码与桌面容器代码剥离的情况下，通过将负一屏代码以及负一屏资源加载到虚拟机中，创建创建指向负一屏资源的负一屏的运行上下文，并以该负一屏运行上下文替换桌面容器的运行上下文，使得负一屏可以运行在属于自己的运行环境中，引用自己的资源。从而在降低负一屏与桌面容器耦合的情况下，实现负一屏在桌面容器进程中的加载。而且，通过view事件分发机制中的dispatchKey Event，可以将用户滑入负一屏、滑出负一屏等事件通知给负一屏，让负一屏可以向用户提供更优质的服务。同时，通过第一Shared Preferences接口与第二SharedPreferences接口的相互配合，可以使得第三方在感知不到跨进程通信的情况下实现向负一屏私有数据区的数据读写，避免了借助AIDL和Service进行数据读写时所带来的各种问题。
另外，由于负一屏代码与桌面容器代码独立，因此，负一屏所需要的默认权限不会再被归属为桌面容器所需要的默认权限，这使得负一屏在要求默认权限时，能够更轻松得通过Google的测试。
第二实施例：
为了让本领域技术人员更清楚本发明所提供负一屏加载方案的优点与细节，本实施例将在第一实施例的基础上继续对负一屏加载方法进行介绍，请参见图6：
步骤S602：采用DexClassLoader将负一屏Apk中的dex文件加载到虚拟机中。
DexClassLoader可以采用如下构造函数实现负一屏对应的dex文件的加载：
DexClassLoader(String dexPath,String optimizedDirectory,StringlibraryPath,ClassLoader parent)；
其中，dexPath是被解压的Apk路径，通常不能为空；optimizedDirectory为解压后的dex文件的存储路径，通常也不能为空，且对于该路径建议使用应用的私有路径；libraryPath为so(shared object，共享对象)库存放的路径；parent为父亲加载器，一般为context.getClassLoader()使用当前上下文的类加载器。
在本实施例中，DexClassLoader是从负一屏的Apk中加载dex文件到虚拟机，不过实际上DexClassLoader不仅可以从Apk中加载形式为dex文件的class，也可以从jar(JavaArchive，Java归档文件)文件中加载class。
S604：从已加载的dex文件中查找与加载负一屏根布局对应的class。
由于负一屏Apk中的dex文件包括负一屏的各个class，因此在终端采用DexClassLoader将负一屏对应的各class加载到虚拟机后，可以从这些class中找到与加载负一屏根布局对应的class，该class可以表征加载负一屏根布局的方法。
步骤S606：根据查找出的class反射加载负一屏根布局。
找到与加载负一屏根布局对应的class后，就相当于找到了加载负一屏根布局的方法，所以终端可以根据查找出的class加载出负一屏根布局。具体方法为：
ClassLoader.loadClass(String name).getMethod(String name,Class<？>...parameterTypes).invoke(Object obj,Object...args)；
步骤S608：构建Asset Manager。
在将负一屏代码，即负一屏的dex文件加载到虚拟机之后，终端需要将负一屏资源加载到虚拟机中。为了加载负一屏资源，终端需要先构建AssetManager，这里给出了一种构建AssetManager的示例：
AssetManager assetManager＝AssetManager.class.newInstance()；
Method addAssetPath＝
assetManager.getClass().getDeclaredMethod("addAssetPath",String.class)；
addAssetPath.invoke(assetManager,path)；
S610：根据构建的Asset Manager构建Resource对象。
在创建出Asset Manager后，终端可以根据构建出的Asset Manager构建Resource对象，构造函数可以参照如下所示：
Resources(AssetManager assets,DisplayMetrics metrics,Configurationconfig)；
步骤S612：构建第一Shared Preferences接口。
为了实现Launcher桌面容器与负一屏之间的跨进程通信，便于Launcher桌面容器向负一屏的私有数据区中读写数据，本实施例中，终端还需要构建第一SharedPreferences接口，终端在构建第一Shared Preferences接口，可以采用ContentProvider来封装第一SharedPreferences接口。在本实施例的一种示例中，借助ContentProvider实现从负一屏私有数据区进行数据读取的方法如下：
private Object getValue(String prefName,String key,int type)；
步骤S614：创建包含上述Resource对象和第一Shared Preferences接口的Mcontext。
可以理解的是，在终端根据查找出的class反射加载负一屏根布局的时候，会反射传入Launcher桌面的Context。不过该Context并不是属于负一屏的Context，在Context所对应的运行环境中，负一屏也无法正常运行，例如负一屏无法引用自己的资源，同时也无法实现针对负一屏的私有数据区的数据读写过程，所以，在本实施例中，在构建出Resource对象以及第一Shared Preferences接口后，终端需要自定义创建出属于负一屏的MContext，该MContext继承于ContextWrapper，构造方法如下：
MContext(Context paramContext,ClassLoader paramClassLoader,StringparamPath)；
在该MContext中包括终端前面构建出的Resource对象和第一SharedPreferences接口。
步骤S616：根据MContext加载负一屏。
在构建出负一屏的MContext之后，终端可以根据该MContext加载负一屏。在这种情况下，由于终端采用负一屏对应的Resource对象替代了原桌面容器Context中Resource对象，所以负一屏在采用getResource函数引用资源时，获取到的是属于自己的资源，而非桌面容器的资源。
另一方面，由于在负一屏的Mcontext中包括第一Shared Preferences接口，所以，Launcher桌面容器可以与负一屏之间可以通过该第一Shared Preferences接口实现跨进程通信，Launcher桌面容器可以通过第一Shared Preferences接口向负一屏传递针对第一目标数据的读取请求，接收负一屏发送的第一目标数据；或者Launcher桌面容器可以通过第一Shared Preferences接口向负一屏传递包括第二目标数据的写入请求。
Shared Preferences接口在向负一屏发送读取请求时，可以调用getValue函数，getValue函数包括getString(读取字符串数据的函数)、getInt(读取整型数据的函数)、getLong(读取长整型数据的函数)等几种类型。对应的，写入数据的函数包括putString、putInt、putLong等几种类型。不过由于本实施例中第一Shared Preferences接口通过ContentProvider实现，而ContentProvider由Bundle(束)携带返回数据，因此为了数据统一，故负一屏在通过第一Shared Preferences接口传输第一目标数据时，将所有的数据类型都转换为String类型，当桌面容器接收到第一目标数据之后，再对接收到的第一目标数据进行数据类型转换。
在本实施例中，由于负一屏的View在Launcher桌面的父View中，因此，当桌面容器需要向负一屏进行事件通知时，可以借用View事件分发机制的dispatchKeyEvent方法来将事件传递给负一屏。为了防止负一屏事件和系统原有事件冲突，在本实施例中，负一屏和Launcher桌面容器之间可以约定负一屏事件的action和code均为负数。在dispatchKeyEvent在分发事件前，Launcher桌面中父View需要对当前待分发事件的事件类型和信息码进行重新编码：若待分发事件属于负一屏，则保证该事件的action和code为负数。当负一屏收到事件后，可以进行解析并根据解析结果执行对应的操作。
本发明实施例提供的负一屏加载方法，在将负一屏代码，即负一屏的dex文件加载到虚拟机之后，通过构建负一屏资源对应的Resource对象以及第一Shared Preferences接口，并基于构建出的Resource对象以及第一SharedPreferences接口得到属于负一屏的Mcontext，从而在该Mcontext对应的运行环境中加载负一屏，使得负一屏可以在代码与桌面容器代码独立的情况下，正常运行在桌面容器进程中，且不影响负一屏对资源的引用以及对私有数据区的使用。本实施例提供的负一屏加载方法，在保障负一屏基本功能的情况下，减小了负一屏同桌面容器之间的业务逻辑耦合，使得二者的版本更迭独立，减小了各级版本维护的成本。
实施例三：
本实施例提供一种负一屏加载装置，请参见图7示出的负一屏加载装置的结构示意图：
负一屏加载装置70包括代码资源加载模块702、运行环境创建模块704以及负一屏加载模块706，其中，代码资源加载模块702用于将与桌面容器代码独立的负一屏代码分别加载到虚拟机，同时还用于将负一屏资源也加载到虚拟机中。运行环境创建模块704用于创建包括负一屏资源之资源获取途径的负一屏的运行上下文，并采用该负一屏的运行上下文替代桌面容器的运行上下文。负一屏加载模块706用于根据该负一屏的运行上下文加载负一屏。
在本实施例中，负一屏代码和桌面容器代码是独立的，二者没有混杂在一起：桌面容器有自己的安装包，同样的，负一屏也有自己独立的安装包。本实施例中要将负一屏加载到桌面容器中，使得用户在第一屏上进行触控可以正常进入到负一屏，让代码独立的负一屏可以如同相关技术中的负一屏一样向用户提供业务服务。这里可以将负一屏视作桌面容器的一个插件，插件化的负一屏最终会运行在桌面容器中，下面以Launcher桌面为例，对Launcher桌面的结构进行简单介绍，请参见图2和图3：
在引入负一屏之后，Launcher桌面分为负一屏和普通屏，可以理解的是普通屏的数目可以不只一个。图2示出的是普通屏20的结构示意图，在普通屏20中包括Workspace21、Hotseat 22以及导航点23。Workspace 21是一个可左右滑动的组件，在普通屏20中它是应用图标的容器，应用图标可以在Workspace 21内部被拖拽。导航点23用于指示当前处于哪一个普通屏。Hotseat 22用于存放一些很常用的应用图标，在包括两个或多个普通屏的情况下，在用户控制Workspace 21左右滑动时，普通屏20中Hotseat 22不会随着Workspace21的移动而移动。
图3示出的是负一屏30的结构示意图，在负一屏30中包括桌面容器31、负一屏根布局32，负一屏根布局32运行在桌面容器31中。负一屏30的显示布局不再受普通屏20显示布局样式的限制：例如，负一屏30可以支持上下滑动，相较于普通屏20的显示内容，负一屏30可以向用户呈现更多的内容。而且，负一屏30显示的内容不限于各种应用图标，例如负一屏30可以接入第三方业务，实现软件营收。
为了实现负一屏的加载，代码资源加载模块702需要将插件安装包中的代码，也即负一屏代码加载到虚拟机中。可以理解的是，代码资源加载模块702将负一屏代码加载到虚拟机中，实际上就是将负一屏代码中的class文件加载到Java虚拟机中。而在Android的编译系统中，对class文件做了进一步的处理，使其变成dex文件。dex文件是Android平台上的可执行文件，相当于Windows平台中的exe文件。每个Apk安装包中都有dex文件，里面包含了该安装包的所有源码，所以，代码资源加载模块702加载插件安装包中的代码，实质就是加载这个插件安装包中的dex文件。
在加载class的时候，代码资源加载模块702可以采用ClassLoader进行，为了加载dex文件，就可以采用DexClassLoader。DexClassLoader是一个继承于ClassLoader的类。所以，在本实施例中，代码资源加载模块702可以采用DexClassLoader来加载负一屏的dex文件，具体地，代码资源加载模块702通过DexClassLoader从负一屏的安装包中加载dex文件。
在DexClassLoader将负一屏的dex文件加载到虚拟机之后，实际上就将负一屏对应的class加载到虚拟机中了，在这种情况下，代码资源加载模块702可以采用反射加载的方式加载出负一屏的根布局：代码资源加载模块702从已加载的class中找到加载负一屏根布局的方法，从而根据该方法加载出负一屏的根布局。
在将负一屏代码加载到虚拟机后，代码资源加载模块702还需要将负一屏资源也加载到虚拟机中。负一屏资源包括文字、图片、词条等。在安卓系统中，可以采用getResource方法获取对应的Resource对象，而创建Resource对象时所需的各种参数需要通过Asset Manager来传入。所以，在本实施例中，为了加载负一屏资源，代码资源加载模块702可以先构建Asset Manager，然后通过AssetManager构建Resource对象，再根据Resource对象加载负一屏资源到虚拟机。
通过代码资源加载模块702的处理，可以将负一屏的代码和资源加载到虚拟机中，但是由于在DexClassLoader将负一屏安装包Apk中的dex文件加载到桌面容器进程中，反射加载负一屏根布局时传入的是桌面容器的Context。因此，在这种情况下，负一屏代码在桌面容器的进程中运行，实际上是处于桌面容器的运行环境中，负一屏在获取资源时只能获取到桌面容器的资源。其本身的各种资源(如图片、布局、词条等)在桌面容器的资源中是无法被找到的。
所以，为了保证负一屏在运行时，可以获取到其本身的资源，在本实施例中，当代码资源加载模块702将负一屏资源加载到虚拟机之后，运行环境创建模块704还需要对表征负一屏运行环境的Context进行处理：运行环境创建模块704创建属于负一屏的Context，例如运行环境创建模块704自定义Mcontext，Mcontext继承于ContextWrapper，其作为负一屏的Context，其中包括有负一屏资源的资源获取途径。
在运行环境创建模块704创建了负一屏的Context之后，负一屏加载模块706可以根据该Context加载负一屏。可以理解的是，负一屏加载模块706根据负一屏的运行上下文加载负一屏，实际上就是根据负一屏的运行上下文运行负一屏代码，并在代码运行过程中引用负一屏资源，向用户呈现负一屏。或者说，就是负一屏加载模块706在负一屏运行上下文所对应的运行环境中，运行负一屏代码，引用负一屏资源向用户提供负一屏服务。此时，负一屏运行在属于负一屏的运行环境中，可以获取到自己的资源，而非运行在桌面容器的运行环境中只能获取桌面容器的资源。
通过上述过程，可以实现负一屏的加载，不过由于负一屏与桌面容器属于不同的进程，因此二者之间无法进行直接通信，这会使得桌面容器无法将用户滑入负一屏以及用户滑出负一屏等事件通知给负一屏。可以理解的是，如果负一屏可以了解用户何时滑入，则其可以在用户滑入的时候进行内容更新，以便给用户提供最新、最实时的业务服务。同时，如果负一屏了解用户何时滑出，则其可以及时地释放内存，结束某些监听，从而避免资源占用，资源浪费。因此，如果负一屏不能与桌面容器通信，负一屏可能只能定时进行内容更新以及资源释放等，无法给用户提供优质的业务服务，这样容易导致用户体验不高，所以，为了让负一屏了解用户的滑入、滑出等事件本实施例提供一种解决方案：
请参见图8示出的本实施例一种示例中负一屏加载装置的结构示意图：在该示例中，负一屏加载装置80除了包括代码资源加载模块802、运行环境创建模块804以及负一屏加载模块806以外，还包括事件分发模块808，事件分发模块808可以调用View事件分发机制中的dispatch Key Event实现桌面容器与负一屏间的通信：当桌面容器监测到有针对负一屏的事件时，事件分发模块808可以调用dispatch Key Event向负一屏分发事件。可以理解的是，dispatch KeyEvent不仅用于向负一屏分发事件，而且还会向桌面容器分发属于普通屏的事件(又称系统事件)。所以，在dispatch Key Event进行事件分发的时候，需要区分当前待分发的事件是属于普通屏还是属于负一屏。
在本实施例中，事件分发模块808可以通过事件属性信息来进行区分当前待分发事件是属于负一屏还是系统原有事件。事件属性信息包括action与code，其中，action包括按键按下事件、按键弹起事件等；而code则用于指示是针对哪一按键的事件。为了区分负一屏事件与系统原有事件，桌面容器中父view在分发事件前保证二者的事件属性信息不同。这样，当事件分发模块808控制dispatch Key Event进行事件分发时，dispatch Key Event可以根据事件属性信息确定当前的事件是否属于负一屏。可以理解的是，只要负一屏事件的事件属性信息中有一个信息与系统事件的事件属性信息中的不同，则可以达到区分的目的。当然，在本实施例的一些示例中，可以让负一屏事件的action、code均不同于系统各事件的action、code。
由于系统事件的事件类型与信息码通常是正数或者是非负数，所以在本实施例的一些示例当中，为了便于区分可以将负一屏事件的事件属性信息中的至少一个信息设置为负数，这样，当dispatch Key Event确定当前待分发的事件的事件属性信息中包括负数，则可以直接确定该事件是负一屏的事件。例如，在本实施例的一个示例中，负一屏事件的action、code均为负数，而系统事件的action、code均为正数。
在本实施例中，负一屏的代码运行在桌面容器进程中，因此无法直接从负一屏的私有数据区中读写数据。在一些相关的方案当中，针对这种情况，是借助AIDL和Service来完成跨进程通信的，不过这种方案存在以下几个缺陷：
1)在负一屏运行的过程中，需要持续保证Service存活。换言之，负一屏在有借助Service进行数据读写的需求时，需要先判断Service是否处于运行状态，若判断Service处于运行状态，则可正常读取数据；否则，必须要要先启动Service，然后才能进行数据读写。也就是说，本次数据读写需求是无法被正常响应的。
2)由于在加载负一屏根布局时，可能需要负一屏私有数据区中保存的数据。如果在加载负一屏根布局的时候Service没启动起来，就无法加载负一屏。在这种情况下，负一屏的加载流程会被打断，会导致负一屏加载时间变长。
3)由于这种从负一屏私有数据区进行数据读写的方案是基于Service和AIDL进行的，所以，当有数据读写需求时，就需要给AIDL扩展对应的接口，Service中也得实现该接口。这样第三方aar(Android Archive，安卓二进制归档文件)包要想读数据的话也需要通过回调的方式来为其提供接口，这样会使得逻辑复杂，耦合度高。
为了避免上面的各种问题，本实施例还提供一种负一屏加载装置，请参见图9：
负一屏加载装置90中包括包括代码资源加载模块902、运行环境创建模块904以及负一屏加载模块906，另外，负一屏加载装置90还包括数据读写模块908。数据读写模块908采用Content Provider来封装形成第一SharedPreferences接口，并采用该第一SharedPreferences接口替换掉加载负一屏根布局时反射传入的Context(即桌面容器的Context)中的Shared Preferences接口。换言之，在负一屏的运行上下文Mcontext中，还可以包括第一SharedPreferences接口，对于负一屏而言，其可以拥有两个SharedPreferences接口，一个即是上述采用Content Provider封装形成的第一SharedPreferences接口；另一个是真正的SharedPreferences接口，这里将其称为第二SharedPreferences接口。在负一屏加载完成后，数据读写模块908可以通过第一SharedPreferences接口以及负一屏的第二Shared Preferences接口实现在负一屏的私有数据区的数据读写。
当桌面容器有从负一屏私有数据区进行数据读取的需求时，数据读写模块908可以控制桌面容器通过第一Shared Preferences接口向负一屏发送针对第一目标数据的读取请求，可以理解的是，在该读取请求中可以包括用于对待读取的第一目标数据进行指示的信息。在负一屏通过第一Shared Preferences接口接收到来自桌面容器的读取请求后，数据读写模块908可控制负一屏采用第二Shared Preferences接口按照读取请求从私有数据区中读取第一目标数据。在第二Shared Preferences接口从负一屏的私有数据区中读取到第一目标数据之后，数据读写模块908可以再次通过第一Shared Preferences接口将读取到的第一目标数据发送给桌面容器。
当桌面容器需要将第二目标数据写入到负一屏的私有数据区时，数据读写模块908可控制桌面容器通过第一Shared Preferences接口向负一屏发送写入请求，在该写入请求中至少包括待写入的第二目标数据。在负一屏通过第一SharedPreferences接口接收到桌面容器发送的写入请求之后，数据读写模块908可以对写入请求进行解析得到第二目标数据，然后控制负一屏通过第二SharedPreferences接口将第二目标数据写入到私有数据区中。
根据上述介绍可知，第一Shared Preferences接口相当于是桌面容器与负一屏之间跨进程通信的桥梁，而第二Shared Preferences接口则主要是实现负一屏与私有数据区之间的通信。对于第三方而言，其直接调用第一Shared Preferences接口即可实现负一屏私有数据区中数据的读写，并不会感知到桌面容器与负一屏之间存在跨进程通信，因此减小了与第三方的耦合。
在本实施例中，负一屏加载装置可以部署在终端上，例如带有安卓系统的手机、平板电脑以及智能穿戴设备等等。可以理解的是，在该负一屏加载装置中可以同时包括事件分发模块和数据读写模块。对于代码资源加载模块、运行环境创建模块、负一屏加载模块以及事件分发模块、数据读写模块的功能，均可以通过终端的处理器实现。
本实施例中提供的负一屏加载装置，在将负一屏代码与桌面容器代码剥离的情况下，通过将负一屏代码以及负一屏资源加载到虚拟机中，创建创建指向负一屏资源的负一屏的运行上下文，并以该负一屏运行上下文替换桌面容器的运行上下文，使得负一屏可以运行在属于自己的运行环境中，引用自己的资源。从而在降低负一屏与桌面容器耦合的情况下，实现负一屏在桌面容器进程中的加载。而且，通过view事件分发机制中的dispatchKey Event，可以将用户滑入负一屏、滑出负一屏等事件通知给负一屏，让负一屏可以向用户提供更优质的服务。同时，通过第一Shared Preferences接口与第二SharedPreferences接口的相互配合，可以使得第三方在感知不到跨进程通信的情况下实现向负一屏私有数据区的数据读写，避免了借助AIDL和Service进行数据读写时所带来的各种问题。
另外，由于负一屏代码与桌面容器代码独立，因此，负一屏所需要的默认权限不会再被归属为桌面容器所需要的默认权限，这使得负一屏在要求默认权限时，能够更轻松得通过Google的测试。
实施例四：
本实施例提供一种计算机可读存储介质和一种终端，首先对该存储介质进行说明：
计算机可读存储介质中可以存储有一个或多个可供一个或多个处理器读取、编译并执行的计算机程序，在本实施例中，该计算机可读存储介质中可以存储负一屏加载程序，负一屏加载程序可供一个或多个处理器执行实现前述实施例一或实施例二中介绍的任意一种负一屏加载方法的步骤。
本实施例还提供一种终端，请参见图10示出的终端的硬件结构示意图：
终端100包括处理器101、存储器102以及用于连接处理器101与存储器102的通信总线103，其中存储器102可以为前述存储有负一屏加载程序的存储介质。处理器101可以读取存储器102中存储的负一屏加载程序，进行编译并执行实现实施例一或二中介绍的任意一种负一屏加载方法的步骤：
处理器101将负一屏代码和负一屏资源加载到虚拟机，该负一屏代码与桌面容器代码独立；然后处理器101创建包括负一屏资源之资源获取途径的负一屏的运行上下文并替换桌面容器的运行上下文，并根据负一屏的运行上下文加载负一屏。
在本实施例的一种示例中，负一屏的运行上下文中还包括第一共享偏好SharedPreferences接口，第一Shared Preferences接口由内容提供器ContentProvider封装形成；在根据负一屏的运行上下文加载负一屏之后，处理器101还会通过第一SharedPreferences接口以及负一屏的第二Shared Preferences接口在负一屏的私有数据区进行数据读写。
在本实施例的一种示例中，在根据负一屏的运行上下文加载负一屏之后，处理器101还会调用用户界面View事件分发机制中的关键事件调度dispatchKey Event向负一屏分发事件，负一屏事件的事件与系统原有各事件的事件属性信息中存在至少一个信息不同，事件属性信息包括事件类型action信息及信息码code信息。
终端100实现实施例一或二中负一屏加载方法的细节可以参见前述实施例的介绍，这里不再赘述。
这里将结合图11示出的终端100所在的通信网络系统架构图对终端100所在的通信网络系统进行简单介绍：该通信网络系统为通用移动通信技术的LTE系统，该LTE系统包括依次通讯连接的UE(User Equipment，用户设备)201，E-UTRAN(Evolved UMTSTerrestrial Radio Access Network，演进式UMTS陆地无线接入网)202，EPC(EvolvedPacket Core，演进式分组核心网)203和运营商的IP业务204。
具体地，UE201可以是上述终端100，此处不再赘述。
E-UTRAN202包括eNodeB2021和其它eNodeB2022等。其中，eNodeB2021可以通过回程(backhaul)(例如X2接口)与其它eNodeB2022连接，eNodeB2021连接到EPC203，eNodeB2021可以提供UE201到EPC203的接入。
EPC203可以包括MME(Mobility Management Entity，移动性管理实体)2031，HSS(Home Subscriber Server，归属用户服务器)2032，其它MME2033，SGW(Serving Gate Way，服务网关)2034，PGW(PDN Gate Way，分组数据网络网关)2035和PCRF(Policy andCharging Rules Function，政策和资费功能实体)2036等。其中，MME2031是处理UE201和EPC203之间信令的控制节点，提供承载和连接管理。HSS2032用于提供一些寄存器来管理诸如归属位置寄存器(图中未示)之类的功能，并且保存有一些有关服务特征、数据速率等用户专用的信息。所有用户数据都可以通过SGW2034进行发送，PGW2035可以提供UE 201的IP地址分配以及其它功能，PCRF2036是业务数据流和IP承载资源的策略与计费控制策略决策点，它为策略与计费执行功能单元(图中未示)选择及提供可用的策略和计费控制决策。
IP业务204可以包括因特网、内联网、IMS(IP Multimedia Subsystem，IP多媒体子系统)或其它IP业务等。
虽然上述以LTE系统为例进行了介绍，但本领域技术人员应当知晓，本发明不仅仅适用于LTE系统，也可以适用于其他无线通信系统，例如GSM、CDMA2000、WCDMA、TD-SCDMA以及未来新的网络系统等，此处不做限定。
本实施例中终端先将负一屏代码和负一屏资源加载到虚拟机，然后创建负一屏的运行上下文来替换桌面容器的运行上下文，并根据负一屏的运行上下文加载出负一屏。由于负一屏的运行上下文中包括负一屏资源的资源获取途径，因此，在虚拟机运行负一屏代码时，可以获取负一屏对应的资源，从而在负一屏代码与桌面容器代码独立的情况下，实现将负一屏显示在桌面容器的效果，完成负一屏的加载。在保证负一屏正常加载的基础上，减小了负一屏业务逻辑与桌面容器业务逻辑的耦合度，降低了负一屏与桌面容器版本维护成本，有利于了负一屏与桌面容器各自的版本更迭。
显然，本领域的技术人员应该明白，上文中所公开方法中的全部或某些步骤、系统、装置中的功能模块/单元可以被实施为软件(可以用计算装置可执行的程序代码来实现)、固件、硬件及其适当的组合。在硬件实施方式中，在以上描述中提及的功能模块/单元之间的划分不一定对应于物理组件的划分；例如，一个物理组件可以具有多个功能，或者一个功能或步骤可以由若干物理组件合作执行。某些物理组件或所有物理组件可以被实施为由处理器，如中央处理器、数字信号处理器或微处理器执行的软件，或者被实施为硬件，或者被实施为集成电路，如专用集成电路。这样的软件可以分布在计算机可读介质上，由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，计算机可读介质可以包括计算机存储介质(或非暂时性介质)和通信介质(或暂时性介质)。如本领域普通技术人员公知的，术语计算机存储介质包括在用于存储信息(诸如计算机可读指令、数据结构、程序模块或其他数据)的任何方法或技术中实施的易失性和非易失性、可移除和不可移除介质。计算机存储介质包括但不限于RAM,ROM,EEPROM、闪存或其他存储器技术、CD-ROM，数字多功能盘(DVD)或其他光盘存储、磁盒、磁带、磁盘存储或其他磁存储装置、或者可以用于存储期望的信息并且可以被计算机访问的任何其他的介质。此外，本领域普通技术人员公知的是，通信介质通常包含计算机可读指令、数据结构、程序模块或者诸如载波或其他传输机制之类的调制数据信号中的其他数据，并且可包括任何信息递送介质。所以，本发明不限制于任何特定的硬件和软件结合。
以上内容是结合具体的实施方式对本发明实施例所作的进一步详细说明，不能认定本发明的具体实施只局限于这些说明。对于本发明所属技术领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干简单推演或替换，都应当视为属于本发明的保护范围。

Claims (10)

1.一种负一屏加载方法，其特征在于，该方法包括：
将负一屏代码和负一屏资源分别加载到虚拟机，所述负一屏代码与桌面容器代码独立；
创建负一屏的运行上下文并替换桌面容器的运行上下文，所述负一屏的运行上下文中包括所述负一屏资源的资源获取途径；
根据所述负一屏的运行上下文加载所述负一屏。
2.如权利要求1所述的负一屏加载方法，其特征在于，所述将负一屏代码加载到虚拟机包括：
采用Dex类加载器加载所述负一屏的可执行dex文件；
反射加载所述负一屏的根布局。
3.如权利要求1所述的负一屏加载方法，其特征在于，所述将负一屏资源加载到虚拟机包括：
构建资源管理器AssetManager；
通过所述AssetManager构建资源Resource对象；
根据所述Resource对象加载所述负一屏资源到所述虚拟机。
4.如权利要求1-3任一项所述的负一屏加载方法，其特征在于，所述根据所述负一屏的运行上下文加载所述负一屏之后，还包括：
调用用户界面View事件分发机制中的关键事件调度dispatchKeyEvent向所述负一屏分发事件，所述负一屏事件的事件与系统原有各事件的事件属性信息中存在至少一个信息不同，所述事件属性信息包括事件类型action信息及信息码code信息。
5.如权利要求4所述的负一屏加载方法，其特征在于，所述负一屏事件的事件属性信息为负数，所述系统原有各事件的事件属性信息为非负数。
6.如权利要求1-3任一项所述的负一屏加载方法，其特征在于，所述负一屏的运行上下文中还包括第一共享偏好Shared Preferences接口，所述第一Shared Preferences接口由内容提供器Content Provider封装形成；
所述根据所述负一屏的运行上下文加载所述负一屏之后，还包括：
通过所述第一Shared Preferences接口以及所述负一屏的第二Shared Preferences接口在所述负一屏的私有数据区进行数据读写。
7.如权利要求6所述的负一屏加载方法，其特征在于，所述通过所述第一SharedPreferences接口以及所述负一屏的第二Shared Preferences接口在所述负一屏的私有数据区进行数据读写包括以下数据读取流程以及数据写入流程：
数据读取流程：
通过所述第一Shared Preferences接口接收桌面容器发送的针对第一目标数据的读取请求；
通过所述第二Shared Preferences接口根据所述读取请求从所述私有数据区中读取所述第一目标数据；
通过所述第一Shared Preferences接口将所述第二Shared Preferences接口读取的所述第一目标数据发送给所述桌面容器；
数据写入流程：
通过所述第一Shared Preferences接口接收桌面容器发送的写入请求，所述写入请求中携带有待存储的第二目标数据；
控制所述第二Shared Preferences接口将所述第二目标数据写入到所述私有数据区。
8.一种负一屏加载装置，其特征在于，包括：
代码资源加载模块，用于将负一屏代码和负一屏资源分别加载到虚拟机，所述负一屏代码与桌面容器代码独立；
运行环境创建模块，用于创建负一屏的运行上下文并替换桌面容器的运行上下文，所述负一屏的运行上下文中包括所述负一屏资源的资源获取途径；
负一屏加载模块，用于根据所述负一屏的运行上下文加载所述负一屏。
9.一种终端，其特征在于，所述终端包括处理器、存储器及通信总线；
所述通信总线用于实现处理器和存储器之间的连接通信；
所述处理器用于执行存储器中存储的一个或者多个程序，以实现如权利要求1至7中任一项所述的负一屏加载方法的步骤。
10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有一个或者多个程序，所述一个或者多个程序可被一个或者多个处理器执行，以实现如权利要求1至7中任一项所述的负一屏加载方法的步骤。
CN201810856248.6A 2018-07-31 2018-07-31 一种负一屏加载方法、装置、终端及计算机可读存储介质 Pending CN110780871A (zh)

Priority Applications (3)

Application Number Priority Date Filing Date Title
CN201810856248.6A CN110780871A (zh) 2018-07-31 2018-07-31 一种负一屏加载方法、装置、终端及计算机可读存储介质
US17/261,169 US11966795B2 (en) 2018-07-31 2019-07-31 Method and device for loading minus-one screen, terminal, and computer readable storage medium
PCT/CN2019/098638 WO2020024989A1 (zh) 2018-07-31 2019-07-31 负一屏加载方法、装置、终端及计算机可读存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201810856248.6A CN110780871A (zh) 2018-07-31 2018-07-31 一种负一屏加载方法、装置、终端及计算机可读存储介质

Publications (1)

Publication Number Publication Date
CN110780871A true CN110780871A (zh) 2020-02-11

Family

ID=69231003

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201810856248.6A Pending CN110780871A (zh) 2018-07-31 2018-07-31 一种负一屏加载方法、装置、终端及计算机可读存储介质

Country Status (3)

Country Link
US (1) US11966795B2 (zh)
CN (1) CN110780871A (zh)
WO (1) WO2020024989A1 (zh)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110231922A (zh) * 2019-05-23 2019-09-13 珠海格力电器股份有限公司 一种移动终端显示控制方法及移动终端
CN111813476A (zh) * 2020-06-30 2020-10-23 中天掌金(北京)科技有限公司 一种基于安卓负一屏的手机银行应用方法
CN113900740A (zh) * 2021-11-01 2022-01-07 青岛海信移动通信技术股份有限公司 加载多项列表数据的方法及装置
CN114090100A (zh) * 2020-08-04 2022-02-25 北京珠穆朗玛移动通信有限公司 一种动态加载widget内容的方法及相关装置
CN115061604A (zh) * 2022-08-01 2022-09-16 聚好看科技股份有限公司 一种终端设备及负一屏界面的显示方法

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9678773B1 (en) 2014-09-30 2017-06-13 Amazon Technologies, Inc. Low latency computational capacity provisioning
CN105979059A (zh) * 2015-08-06 2016-09-28 乐视移动智能信息技术（北京）有限公司 一种壁纸切换方法及装置
US20170105041A1 (en) * 2015-10-13 2017-04-13 Le Holdings (Beijing) Co., Ltd. Method and device of interactive function card of smart television
CN105955618B (zh) * 2016-04-29 2019-07-05 北京小米移动软件有限公司 信息显示方法及装置
CN106557319A (zh) 2016-11-17 2017-04-05 腾讯科技（深圳）有限公司 负一屏加载对象的方法和装置
US10699003B2 (en) * 2017-01-23 2020-06-30 Hysolate Ltd. Virtual air-gapped endpoint, and methods thereof
CN107193441B (zh) 2017-05-26 2020-07-10 北京小米移动软件有限公司 桌面挂件预览方法及装置
CN107315531A (zh) 2017-07-17 2017-11-03 深圳铂睿智恒科技有限公司 智能终端应用的控制方法及系统

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110231922A (zh) * 2019-05-23 2019-09-13 珠海格力电器股份有限公司 一种移动终端显示控制方法及移动终端
CN110231922B (zh) * 2019-05-23 2021-01-22 珠海格力电器股份有限公司 一种移动终端显示控制方法及移动终端
CN111813476A (zh) * 2020-06-30 2020-10-23 中天掌金(北京)科技有限公司 一种基于安卓负一屏的手机银行应用方法
CN111813476B (zh) * 2020-06-30 2024-04-05 中天掌金(北京)科技有限公司 一种基于安卓负一屏的手机银行应用方法
CN114090100A (zh) * 2020-08-04 2022-02-25 北京珠穆朗玛移动通信有限公司 一种动态加载widget内容的方法及相关装置
CN113900740A (zh) * 2021-11-01 2022-01-07 青岛海信移动通信技术股份有限公司 加载多项列表数据的方法及装置
CN115061604A (zh) * 2022-08-01 2022-09-16 聚好看科技股份有限公司 一种终端设备及负一屏界面的显示方法
CN115061604B (zh) * 2022-08-01 2023-09-29 聚好看科技股份有限公司 一种终端设备及负一屏界面的显示方法

Also Published As

Publication number Publication date
WO2020024989A1 (zh) 2020-02-06
US11966795B2 (en) 2024-04-23
US20210279083A1 (en) 2021-09-09

Similar Documents

Publication Publication Date Title
CN110780871A (zh) 一种负一屏加载方法、装置、终端及计算机可读存储介质
US11314568B2 (en) Message processing method and apparatus, storage medium, and computer device
US11868785B2 (en) Application program page processing method and device
JP6915091B2 (ja) アプリケーション処理方法、装置および記憶媒体
US20170161032A1 (en) Running applications using pre-generated components
CN103970563B (zh) 动态加载安卓类的方法
CN109474522B (zh) 业务路由的方法、装置及存储介质
CN112445579B (zh) 零终端数据处理系统及其文件复制方法、装置
CN109445841B (zh) 接口文档管理方法、装置、服务器及存储介质
JP7106001B2 (ja) サブアプリケーション開発方法、装置、コンピュータ機器、並びにコンピュータプログラム
CN107818023B (zh) 基于线程的消息处理方法、智能设备及存储介质
CN110019464B (zh) 页面处理方法及装置
EP4209904A1 (en) Cloud resource management method and apparatus, and computer device and storage medium
CN106815037B (zh) 应用功能的执行方法及装置
CN113032111B (zh) 应用程序的迁移方法、装置、系统和计算机可读存储介质
CN113784194A (zh) 一种视频播放器的嵌入方法和装置
CN109413507B (zh) 弹幕库与直播间引用关系的处理方法、装置、终端和介质
CN111158777A (zh) 组件调用方法、装置及计算机可读存储介质
CN114237684A (zh) 组件管理系统、方法、装置、电子设备及存储介质
US20110029856A1 (en) Extensible Web Context in Web Containers
CN108804236B (zh) 一种aidl文件的共享方法及系统
CN113220296A (zh) 安卓系统交互方法及装置
CN112711728B (zh) 页面布局框架、页面加载方法、装置、设备及存储介质
CN113835596A (zh) 图标处理方法、装置及设备
CN108874476B (zh) 一种禁止广告展示的方法及系统

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination