A negative one screen loading method, device, terminal and computer readable storage medium

Abstract

The embodiment of the present invention provides a method, device, terminal and computer-readable storage medium for loading a negative screen, which strips off the originally mixed negative screen code and desktop container code, making the two independent. When loading the negative screen, the negative screen code and the negative screen resources are first loaded into the virtual machine respectively, and then the running context of the negative screen is created to replace the running context of the desktop container, and the negative screen is loaded according to the running context of the negative screen. Since the running context of the negative screen includes the resource acquisition path of the negative screen resources, when the virtual machine runs the negative screen code, the resources corresponding to the negative screen can be obtained, thereby completing the loading of the negative screen when the negative screen code and the desktop container code are independent. While ensuring the normal loading of the negative screen, the coupling degree between the negative screen business logic and the desktop container business logic is reduced, the maintenance cost of the negative screen and the desktop container version is reduced, and it is beneficial to the version upgrade of the negative screen and the desktop container.

Description

Technical Field

[0001] The present invention relates to the field of terminal technology, and in particular to a negative one-screen loading method, device, terminal and computer-readable storage medium. Background Art

[0002] As the entrance to all applications in the user's mobile phone, the mobile desktop is one of the most basic, important and frequently used applications in some mobile phone systems. As the "facade" of the operating system, major mobile phone manufacturers have also designed their own unique mobile desktops according to their own product styles, striving to provide users with simpler and more practical functions, more beautiful interfaces, and more convenient services.

[0003] However, since the Launcher desktop displays all applications in the form of a grid, the display method is very simple and cannot provide users with more abundant and diverse other services. On this basis, Google proposed the concept of "negative one screen", that is, adding a screen to the leftmost end of the original desktop screen. Since the original first screen is numbered "0" in the code implementation, the number of the screen added to the left of the first screen is "-1", so it is called the negative one screen. Since the negative one screen has its own special advantages, such as simple entry, rich content styles that can be presented, it can provide users with many convenient operations, and can also access third-party services to achieve software revenue. Therefore, various mobile phone manufacturers and operating system desktops on the market will develop their own negative one screens, and they are also constantly optimizing and improving them, aiming to provide users with convenient and practical functions.

[0004] However, the code of the negative one screen and the code of the Launcher desktop container are currently mixed together, and the business logic of the two is also coupled together, which makes the version maintenance cost of the negative one screen and the desktop container high, and is very unfavorable for the version upgrade of the negative one screen and the desktop container. Summary of the invention

[0005] The embodiments of the present invention provide a negative one screen loading method, device, terminal and computer-readable storage medium, which mainly solve the technical problem that the code of the negative one screen and the code of the desktop container in the related technology are mixed, the business logic coupling is high, and it is not conducive to the version upgrade of the two.

[0006] In order to solve the above technical problems, an embodiment of the present invention provides a negative one screen loading method, comprising:

[0007] The negative one screen code and negative one screen resources are loaded into the virtual machine respectively. The negative one screen code is independent of the desktop container code.

[0008] Create a negative one screen running context and replace the running context of the desktop container, the negative one screen running context includes a resource acquisition path for negative one screen resources;

[0009] Load the negative one screen according to the negative one screen's running context.

[0010] The embodiment of the present invention further provides a negative one-screen loading device, comprising:

[0011] A code resource loading module is used to load the negative one screen code and the negative one screen resource into the virtual machine respectively. The negative one screen code is independent of the desktop container code.

[0012] A running environment creation module, used to create a negative one screen running context and replace the running context of the desktop container, wherein the negative one screen running context includes a resource acquisition path for negative one screen resources;

[0013] The negative one screen loading module is used to load the negative one screen according to the running context of the negative one screen.

[0014] An embodiment of the present invention further provides a terminal, the terminal comprising a processor, a memory and a communication bus;

[0015] The communication bus is used to realize the connection and communication between the processor and the memory;

[0016] The processor is used to execute one or more programs stored in the memory to implement the steps of the negative one-screen loading method as described above.

[0017] An embodiment of the present invention further provides a computer-readable storage medium, characterized in that the computer-readable storage medium stores one or more programs, and the one or more programs can be executed by one or more processors to implement the steps of the negative one-screen loading method as described above.

[0018] The beneficial effects of the present invention are:

[0019] According to the negative one screen loading method, device, terminal and computer-readable storage medium provided by the embodiment of the present invention, the negative one screen code and desktop container code that were originally mixed together are stripped off, making the two independent. When loading the negative one screen, the negative one screen code and negative one screen resources are first loaded into the virtual machine, and then the negative one screen running context is created to replace the desktop container running context, and the negative one screen is loaded according to the negative one screen running context. Since the negative one screen running context includes the resource acquisition path of the negative one screen resources, when the virtual machine runs the negative one screen code, the resources corresponding to the negative one screen can be obtained, so that when the negative one screen code and the desktop container code are independent, the effect of displaying the negative one screen on the desktop container is achieved, and the loading of the negative one screen is completed. On the basis of ensuring the normal loading of the negative one screen, the coupling degree between the negative one screen business logic and the desktop container business logic is reduced, the maintenance cost of the negative one screen and the desktop container version is reduced, and it is beneficial to the version upgrade of the negative one screen and the desktop container.

[0020] In addition, since the negative one screen needs to request more default permissions, and Google's test has greater restrictions on the default permissions requested by the desktop, the negative one screen and the desktop container business logic are independent in the embodiment of the present invention. Therefore, the default permissions requested by the negative one screen can be made independent of the desktop, and the acquisition of default permissions is not restricted by Google testing, so that the desired default permissions can be easily obtained.

[0021] Other features and corresponding beneficial effects of the present invention are described in the latter part of the specification, and it should be understood that at least part of the beneficial effects become obvious from the description in the specification of the present invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] Figure 1 A flow chart of the negative one screen loading method provided in the first embodiment of the present invention;

[0023] Figure 2 A schematic diagram of the structure of a common screen provided in the first embodiment of the present invention;

[0024] Figure 3 A schematic diagram of the structure of a negative one screen provided in the first embodiment of the present invention;

[0025] Figure 4 A flow chart of reading data in the negative one screen private data area provided in the first embodiment of the present invention;

[0026] Figure 5 A flow chart of writing data into the negative one screen private data area provided in the first embodiment of the present invention;

[0027] Figure 6 A flow chart of the negative one screen loading method provided in the second embodiment of the present invention;

[0028] Figure 7 A schematic diagram of the structure of the negative one screen loading device provided in the third embodiment of the present invention;

[0029] Figure 8 It is another structural schematic diagram of the negative one screen loading device provided in the third embodiment of the present invention;

[0030] Fig. 9 It is another structural schematic diagram of the negative one screen loading device provided in the third embodiment of the present invention;

[0031] Fig.10 A schematic diagram of the structure of a terminal provided in Embodiment 4 of the present invention;

[0032] Fig.11 for Fig.10 A system architecture diagram of the communication network system in which the terminal is located. DETAILED DESCRIPTION

[0033] In order to make the purpose, technical solution and advantages of the present invention more clearly understood, the following is a further detailed description of the embodiments of the present invention through specific implementation methods combined with the accompanying drawings. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not used to limit the present invention.

[0034] Embodiment 1:

[0035] In order to solve the problem in the related art that the negative one screen code and the desktop container code are mixed together, resulting in the coupling of the business logic of the negative one screen with the business logic of the desktop container, the negative one screen cannot be upgraded separately, and the version maintenance cost of the negative one screen is high, this embodiment provides a negative one screen loading method, see Figure 1 The flowchart of the negative one screen loading method is shown:

[0036] Step S102: Loading the negative one screen code and the negative one screen resource into the virtual machine respectively.

[0037] In this embodiment, the negative one screen code and the desktop container code are independent, and the two are not mixed together: the desktop container has its own installation package, such as Apk (AndroidPackage, Android installation package), and similarly, the negative one screen also has its own independent installation package. In this embodiment, the negative one screen is loaded into the desktop container so that the user can enter the negative one screen normally by touching the first screen, and the code-independent negative one screen can provide business services to the user just like the negative one screen in the related technology. Here, the negative one screen can be regarded as a plug-in of the desktop container, and the plug-in negative one screen will eventually run in the desktop container. Taking the Launcher desktop as an example, the structure of the Launcher desktop is briefly introduced below. Please refer to Figure 2 and Figure 3 :

[0038] After the introduction of the negative one screen, the Launcher desktop is divided into the negative one screen and the normal screen. It can be understood that the number of normal screens can be more than one. Figure 2 The structure diagram of the ordinary screen 20 is shown, and the ordinary screen 20 includes a workspace 21, a hotseat 22, and a navigation point 23. The Workspace 21 is a component that can be slid left and right. In the ordinary screen 20, it is a container for application icons, and the application icons can be dragged inside the Workspace 21. The navigation point 23 is used to indicate which ordinary screen is currently located. The Hotseat 22 is used to store some very commonly used application icons. In the case of two or more ordinary screens, when the user controls the Workspace 21 to slide left and right, the Hotseat 22 in the ordinary screen 20 will not move with the movement of the Workspace 21.

[0039] Figure 3 The structure diagram of the negative first screen 30 is shown, and the negative first screen 30 includes a desktop container 31 and a negative first screen root layout 32, and the negative first screen root layout 32 runs in the desktop container 31. The display layout of the negative first screen 30 is no longer limited by the display layout style of the ordinary screen 20: for example, the negative first screen 30 can support up and down sliding, and compared with the display content of the ordinary screen 20, the negative first screen 30 can present more content to the user. Moreover, the content displayed by the negative first screen 30 is not limited to various application icons. For example, the negative first screen 30 can access third-party services to achieve software revenue.

[0040] In order to load the negative one screen, it is necessary to load the code in the plug-in installation package, that is, the negative one screen code, into the virtual machine. It can be understood that loading the negative one screen code into the virtual machine is actually loading the class file in the negative one screen code into the Java virtual machine. In the Android compilation system, the class file is further processed to turn it into a dex file. The dex file is an executable file on the Android platform, which is equivalent to the exe file on the Windows platform. Each Apk installation package contains a dex file, which contains all the source code of the installation package. Therefore, loading the code in the plug-in installation package is actually loading the dex file in the plug-in installation package.

[0041] When loading a class, a ClassLoader can be used. To load a dex file, a DexClassLoader can be used. DexClassLoader is a class inherited from ClassLoader. Therefore, in this embodiment, the terminal can use DexClassLoader to load the dex file of the negative one screen. Specifically, DexClassLoader loads the dex file from the installation package of the negative one screen.

[0042] After DexClassLoader loads the dex file of the negative one screen into the virtual machine, it actually loads the class corresponding to the negative one screen into the virtual machine. In this case, the terminal virtual machine can load the root layout of the negative one screen by reflection loading: the virtual machine finds the method to load the root layout of the negative one screen from the loaded class, and then loads the root layout of the negative one screen according to this method.

[0043] After loading the negative one screen code into the virtual machine, the negative one screen resources also need to be loaded into the virtual machine. Negative one screen resources (Resource) include text, pictures, entries, etc. In the Android system, the getResource method can be used to obtain the corresponding Resource object, and the various parameters required to create the Resource object need to be passed in through the Asset Manager (Resource Manager). Therefore, in this embodiment, in order to load the negative one screen resources, the terminal can first build an AssetManager, then build a Resource object through the Asset Manager, and then load the negative one screen resources into the virtual machine according to the Resource object.

[0044] Step S104: Create a negative one screen execution context and replace the execution context of the desktop container.

[0045] Although the terminal can load the code and resources of the negative one screen into the virtual machine through S102, because the DexClassLoader loads the dex file in the negative one screen Apk into the desktop container process, the Context (running context) of the desktop container is passed in when the negative one screen root layout is reflected and loaded. Therefore, in this case, the negative one screen code runs in the process of the desktop container, which is actually in the running environment of the desktop container. When acquiring resources, the negative one screen can only obtain the resources of the desktop container. Its various resources (such as pictures, layouts, entries, etc.) cannot be found in the resources of the desktop container.

[0046] Therefore, in order to ensure that the negative one screen can obtain its own resources when it is running, in this embodiment, after the terminal loads the negative one screen resources into the virtual machine, it is also necessary to process the Context representing the negative one screen operating environment: the terminal creates a Context belonging to the negative one screen, such as the terminal customizes Mcontext, Mcontext inherits from ContextWrapper (running context wrapper), which serves as the Context of the negative one screen, which includes the resource acquisition path of the negative one screen resources.

[0047] Step S106: loading the negative one screen according to the running context of the negative one screen.

[0048] After the terminal creates the Context of the negative one screen, the negative one screen can be loaded according to the Context. It can be understood that loading the negative one screen according to the running context of the negative one screen is actually to run the negative one screen code according to the running context of the negative one screen, and reference the negative one screen resources during the code running process to present the negative one screen to the user. In other words, the virtual machine runs the negative one screen code in the running environment corresponding to the running context of the negative one screen, and references the negative one screen resources to provide the negative one screen service to the user. At this time, the negative one screen runs in the running environment belonging to the negative one screen, and can obtain its own resources, rather than running in the running environment of the desktop container and can only obtain the resources of the desktop container.

[0049] Through the above process, the loading of the negative screen can be realized. However, since the negative screen and the desktop container belong to different processes, there is no direct communication between the two, which makes it impossible for the desktop container to notify the negative screen of events such as the user sliding in and the user sliding out of the negative screen. It is understandable that if the negative screen can understand when the user slides in, it can update the content when the user slides in, so as to provide the user with the latest and most real-time business services. At the same time, if the negative screen understands when the user slides out, it can release memory in time and end certain monitoring, thereby avoiding resource occupation and waste. Therefore, if the negative screen cannot communicate with the desktop container, the negative screen may only be able to perform content updates and resource release at regular intervals, and cannot provide users with high-quality business services, which can easily lead to a poor user experience. Therefore, in order to let the negative screen understand the user's sliding in, sliding out and other events, this embodiment provides a communication method:

[0050] The terminal can call the dispatch Key Event (key event dispatch) in the View (user interface) event distribution mechanism to realize the communication between the desktop container and the negative one screen: when the desktop container detects an event for the negative one screen, it can call the dispatch Key Event to distribute the event to the negative one screen. It can be understood that the dispatch Key Event is not only used to distribute events to the negative one screen, but also to distribute events belonging to the ordinary screen (also known as system events) to the desktop container. Therefore, when the dispatch Key Event is used to distribute events, it is necessary to distinguish whether the event to be distributed belongs to the ordinary screen or the negative one screen.

[0051] In this embodiment, the terminal can distinguish whether the current event to be distributed belongs to the negative one screen or the original system event through the event attribute information. The event attribute information includes the event type (action) and the information code (code), wherein the action includes the key press event, the key pop-up event, etc.; and the code is used to indicate which key the event is for. In order to distinguish the negative one screen event from the original system event, the parent view in the desktop container can ensure that the event attribute information of the two is different before distributing the event. In this way, when dispatch KeyEvent performs event distribution, it can be determined whether the current event belongs to the negative one screen based on the event attribute information. It can be understood that as long as there is one piece of information in the event attribute information of the negative one screen event that is different from the event attribute information of the system event, the purpose of distinction can be achieved. Of course, in some examples of this embodiment, the action and code of the negative one screen event can be different from the action and code of each system event.

[0052] Since the event type and information code of the system event are usually positive or non-negative, in some examples of this embodiment, in order to facilitate the distinction, at least one of the information in the event attribute information of the negative one screen event can be set to a negative number. In this way, when the dispatch Key Event determines that the event attribute information of the event to be dispatched currently includes a negative number, it can be directly determined that the event is a negative one screen event. For example, in an example of this embodiment, the action and code of the negative one screen event are both negative numbers, while the action and code of the system event are both positive numbers.

[0053] In this embodiment, the code of the negative one screen runs in the desktop container process, so it is impossible to directly read and write data from the private data area of ​​the negative one screen. In some related solutions, AIDL (Android Interface Definition Language) and Service are used to complete cross-process communication in this case, but this solution has the following defects:

[0054] 1) During the operation of the negative screen, the service needs to be kept alive. In other words, when the negative screen needs to read and write data with the service, it needs to first determine whether the service is in a running state. If the service is in a running state, data can be read normally; otherwise, the service must be started before data can be read and written. In other words, this data read and write demand cannot be responded to normally.

[0055] 2) When loading the negative one screen root layout, the data saved in the negative one screen private data area may be needed. If the Service is not started when loading the negative one screen root layout, the negative one screen cannot be loaded. In this case, the loading process of the negative one screen will be interrupted, which will cause the loading time of the negative one screen to be longer.

[0056] 3) Since this solution of reading and writing data from the private data area of ​​the negative one screen is based on Service and AIDL, when there is a need to read and write data, it is necessary to extend the corresponding interface to AIDL, and the interface must also be implemented in the Service. In this way, if the third-party aar (Android Archive, Android binary archive file) package wants to read data, it also needs to provide an interface for it through callback, which will make the logic complex and highly coupled.

[0057] In order to avoid the above problems, this embodiment also provides another solution for reading and writing data in the private data area of ​​the negative one screen:

[0058] The terminal uses Content Provider to encapsulate and form a first SharedPreferences interface, and uses the first SharedPreferences interface to replace the Shared Preferences interface in the Context (i.e., the Context of the desktop container) reflected and passed in when loading the root layout of the negative one screen. In other words, the running context Mcontext of the negative one screen can also include the first SharedPreferences interface. For the negative one screen, it can have two SharedPreferences interfaces, one is the first SharedPreferences interface encapsulated by Content Provider mentioned above; the other is the real SharedPreferences interface, which is referred to as the second SharedPreferences interface here. After the negative one screen is loaded, the data reading and writing in the private data area of ​​the negative one screen can be realized through the first Shared Preferences interface and the second Shared Preferences interface of the negative one screen.

[0059] First, we will briefly introduce the process of reading data from the private data area of ​​the negative one screen. Figure 4 :

[0060] Step S402: receiving a read request for first target data sent by a desktop container through a first Shared Preferences interface.

[0061] When the desktop container needs to read data from the private data area of ​​the negative one screen, a read request for the first target data can be sent to the negative one screen through the first SharedPreferences interface. It can be understood that the read request can include information for indicating the first target data to be read.

[0062] Step S404: reading the first target data from the private data area according to the read request through the second Shared Preferences interface.

[0063] After receiving the read request from the desktop container through the first Shared Preferences interface, the negative first screen may use the second Shared Preferences interface to read the first target data from the private data area according to the read request.

[0064] Step S406: sending the first target data read by the second Shared Preferences interface to the desktop container through the first Shared Preferences interface.

[0065] After the second Shared Preferences interface reads the first target data from the private data area of ​​the negative one screen, the read first target data can be sent to the desktop container again through the first Shared Preferences interface.

[0066] Combine the following Figure 5 The data writing flow chart shown introduces the process of writing data into the negative one screen private data area:

[0067] Step S502: receiving a write request sent by the desktop container through the first Shared Preferences interface.

[0068] When the desktop container needs to write the second target data into the private data area of ​​the negative one screen, the desktop container may send a write request to the negative one screen through the first Shared Preferences interface, wherein the write request includes at least the second target data to be written.

[0069] S504: Control the second Shared Preferences interface to write the second target data into the private data area.

[0070] After the negative first screen receives the write request sent by the desktop container through the first Shared Preferences interface, the write request can be parsed to obtain the second target data, and then the negative first screen writes the second target data into the private data area through the second Shared Preferences interface.

[0071] from Figure 4 The data reading process and Figure 5 It can be seen from the data writing process shown that the first SharedPreferences interface is equivalent to a bridge for cross-process communication between the desktop container and the negative one screen, while the second SharedPreferences interface is mainly used to realize the communication between the negative one screen and the private data area. For a third party, it can directly call the first Shared Preferences interface to realize the reading and writing of data in the negative one screen private data area, and will not perceive the cross-process communication between the desktop container and the negative one screen, thus reducing the coupling with the third party.

[0072] The negative one screen loading method provided in this embodiment, when the negative one screen code is separated from the desktop container code, by loading the negative one screen code and the negative one screen resources into the virtual machine, creating a negative one screen running context pointing to the negative one screen resources, and replacing the desktop container running context with the negative one screen running context, so that the negative one screen can run in its own running environment and reference its own resources. Thus, the negative one screen is loaded in the desktop container process while reducing the coupling between the negative one screen and the desktop container. Moreover, through the dispatchKey Event in the view event distribution mechanism, the negative one screen can be notified of events such as the user sliding into the negative one screen and sliding out of the negative one screen, so that the negative one screen can provide users with better services. At the same time, through the mutual cooperation of the first Shared Preferences interface and the second Shared Preferences interface, the third party can realize the reading and writing of data to the private data area of ​​the negative one screen without perceiving the cross-process communication, avoiding various problems caused by the reading and writing of data with the help of AIDL and Service.

[0073] In addition, since the negative one screen code is independent of the desktop container code, the default permissions required by the negative one screen will no longer be attributed to the default permissions required by the desktop container, which makes it easier for the negative one screen to pass Google's testing when requesting default permissions.

[0074] Second embodiment:

[0075] In order to make those skilled in the art more aware of the advantages and details of the negative one screen loading solution provided by the present invention, this embodiment will continue to introduce the negative one screen loading method based on the first embodiment. Figure 6 :

[0076] Step S602: Use DexClassLoader to load the dex file in the negative one screen Apk into the virtual machine.

[0077] DexClassLoader can use the following constructor to load the dex file corresponding to the negative one screen:

[0078] DexClassLoader(String dexPath,String optimizedDirectory,StringlibraryPath,ClassLoader parent);

[0079] Among them, dexPath is the path of the decompressed Apk, which usually cannot be empty; optimizedDirectory is the storage path of the decompressed dex file, which usually cannot be empty, and it is recommended to use the private path of the application for this path; libraryPath is the path where the so (shared object) library is stored; parent is the parent loader, which is generally the class loader of the current context used by context.getClassLoader().

[0080] In this embodiment, DexClassLoader loads the dex file from the negative one screen Apk to the virtual machine, but in fact DexClassLoader can not only load classes in the form of dex files from Apk, but also load classes from jar (JavaArchive, Java archive file) files.

[0081] S604: searching for a class corresponding to loading the negative one screen root layout from the loaded dex file.

[0082] Since the dex file in the negative one screen Apk includes each class of the negative one screen, after the terminal uses DexClassLoader to load each class corresponding to the negative one screen into the virtual machine, the class corresponding to loading the root layout of the negative one screen can be found from these classes, and the class can represent the method of loading the root layout of the negative one screen.

[0083] Step S606: reflectively load the negative one screen root layout according to the found class.

[0084] After finding the class corresponding to loading the negative one screen root layout, it is equivalent to finding the method to load the negative one screen root layout, so the terminal can load the negative one screen root layout according to the found class. The specific method is:

[0085] ClassLoader.loadClass(String name).getMethod(String name,Class<?>...parameterTypes).invoke(Object obj,Object...args);

[0086] Step S608: Build Asset Manager.

[0087] After loading the negative one screen code, that is, the negative one screen dex file into the virtual machine, the terminal needs to load the negative one screen resource into the virtual machine. In order to load the negative one screen resource, the terminal needs to build AssetManager first. Here is an example of building AssetManager:

[0088] AssetManager assetManager=AssetManager.class.newInstance();

[0089] Method addAssetPath=

[0090] assetManager.getClass().getDeclaredMethod("addAssetPath",String.class);

[0091] addAssetPath.invoke(assetManager,path);

[0092] S610: Construct a Resource object according to the constructed Asset Manager.

[0093] After creating the Asset Manager, the terminal can construct a Resource object based on the constructed Asset Manager. The constructor can refer to the following:

[0094] Resources(AssetManager assets,DisplayMetrics metrics,Configurationconfig);

[0095] Step S612: construct a first Shared Preferences interface.

[0096] In order to realize cross-process communication between the Launcher desktop container and the negative one screen, and facilitate the Launcher desktop container to read and write data to the private data area of ​​the negative one screen, in this embodiment, the terminal also needs to construct a first SharedPreferences interface. When constructing the first SharedPreferences interface, the terminal can use ContentProvider to encapsulate the first SharedPreferences interface. In an example of this embodiment, the method of reading data from the private data area of ​​the negative one screen with the help of ContentProvider is as follows:

[0097] private Object getValue(String prefName,String key,int type);

[0098] Step S614: Create an Mcontext including the above Resource object and the first Shared Preferences interface.

[0099] It is understandable that when the terminal reflects and loads the root layout of the negative first screen according to the found class, it will reflect the context passed into the Launcher desktop. However, this Context does not belong to the negative first screen. In the operating environment corresponding to the Context, the negative first screen cannot run normally. For example, the negative first screen cannot reference its own resources, and it is also unable to implement the data reading and writing process for the private data area of ​​the negative first screen. Therefore, in this embodiment, after constructing the Resource object and the first Shared Preferences interface, the terminal needs to customize and create an MContext belonging to the negative first screen. The MContext inherits from ContextWrapper, and the construction method is as follows:

[0100] MContext(Context paramContext,ClassLoader paramClassLoader,StringparamPath);

[0101] The MContext includes the Resource object previously constructed by the terminal and the first SharedPreferences interface.

[0102] Step S616: Load the negative one screen according to MContext.

[0103] After constructing the MContext of the negative first screen, the terminal can load the negative first screen according to the MContext. In this case, since the terminal uses the Resource object corresponding to the negative first screen to replace the Resource object in the original desktop container Context, when the negative first screen uses the getResource function to reference resources, it obtains its own resources instead of the desktop container's resources.

[0104] On the other hand, since the Mcontext of the negative one screen includes the first Shared Preferences interface, the Launcher desktop container can realize cross-process communication with the negative one screen through the first Shared Preferences interface. The Launcher desktop container can transmit a read request for the first target data to the negative one screen through the first Shared Preferences interface and receive the first target data sent by the negative one screen; or the Launcher desktop container can transmit a write request including the second target data to the negative one screen through the first Shared Preferences interface.

[0105] When the Shared Preferences interface sends a read request to the negative one screen, the getValue function can be called. The getValue function includes several types such as getString (a function for reading string data), getInt (a function for reading integer data), and getLong (a function for reading long integer data). Correspondingly, the functions for writing data include several types such as putString, putInt, and putLong. However, since the first Shared Preferences interface in this embodiment is implemented through ContentProvider, and ContentProvider carries the return data through Bundle, in order to unify the data, when the negative one screen transmits the first target data through the first Shared Preferences interface, all data types are converted to String type. After the desktop container receives the first target data, the data type conversion is performed on the received first target data.

[0106] In this embodiment, since the View of the negative one screen is in the parent View of the Launcher desktop, when the desktop container needs to notify the negative one screen of an event, the dispatchKeyEvent method of the View event distribution mechanism can be used to pass the event to the negative one screen. In order to prevent the negative one screen event from conflicting with the original system events, in this embodiment, it can be agreed between the negative one screen and the Launcher desktop container that the action and code of the negative one screen event are both negative numbers. Before dispatchKeyEvent distributes the event, the parent View in the Launcher desktop needs to re-encode the event type and information code of the current event to be distributed: if the event to be distributed belongs to the negative one screen, ensure that the action and code of the event are negative numbers. When the negative one screen receives the event, it can parse it and perform corresponding operations based on the parsing results.

[0107] The negative one screen loading method provided in the embodiment of the present invention, after loading the negative one screen code, i.e., the dex file of the negative one screen into the virtual machine, constructs the Resource object corresponding to the negative one screen resource and the first Shared Preferences interface, and obtains the Mcontext belonging to the negative one screen based on the constructed Resource object and the first Shared Preferences interface, thereby loading the negative one screen in the running environment corresponding to the Mcontext, so that the negative one screen can run normally in the desktop container process when the code is independent of the desktop container code, and does not affect the negative one screen's reference to resources and use of private data areas. The negative one screen loading method provided in this embodiment reduces the business logic coupling between the negative one screen and the desktop container while ensuring the basic functions of the negative one screen, so that the version updates of the two are independent, and the cost of version maintenance at all levels is reduced.

[0108] Embodiment three:

[0109] This embodiment provides a negative one screen loading device, see Figure 7 The schematic diagram of the structure of the negative screen loading device is shown:

[0110] The negative one screen loading device 70 includes a code resource loading module 702, a running environment creation module 704 and a negative one screen loading module 706, wherein the code resource loading module 702 is used to load the negative one screen code that is independent of the desktop container code into the virtual machine, and is also used to load the negative one screen resources into the virtual machine. The running environment creation module 704 is used to create a running context of the negative one screen including a resource acquisition path of the negative one screen resources, and use the running context of the negative one screen to replace the running context of the desktop container. The negative one screen loading module 706 is used to load the negative one screen according to the running context of the negative one screen.

[0111] In this embodiment, the negative one screen code and the desktop container code are independent and the two are not mixed together: the desktop container has its own installation package, and similarly, the negative one screen also has its own independent installation package. In this embodiment, the negative one screen is loaded into the desktop container so that the user can normally enter the negative one screen by touching the first screen, and the code-independent negative one screen can provide business services to the user just like the negative one screen in the related technology. Here, the negative one screen can be regarded as a plug-in of the desktop container, and the plug-in negative one screen will eventually run in the desktop container. Taking the Launcher desktop as an example, the structure of the Launcher desktop is briefly introduced below. Please refer to Figure 2 and Figure 3 :

[0112] After the introduction of the negative one screen, the Launcher desktop is divided into the negative one screen and the normal screen. It can be understood that the number of normal screens can be more than one. Figure 2 The structure diagram of the ordinary screen 20 is shown, and the ordinary screen 20 includes a Workspace 21, a Hotseat 22, and a navigation point 23. The Workspace 21 is a component that can be slid left and right. In the ordinary screen 20, it is a container for application icons, and the application icons can be dragged inside the Workspace 21. The navigation point 23 is used to indicate which ordinary screen is currently in. The Hotseat 22 is used to store some very commonly used application icons. In the case of including two or more ordinary screens, when the user controls the Workspace 21 to slide left and right, the Hotseat 22 in the ordinary screen 20 will not move with the movement of the Workspace 21.

[0113] Figure 3 The structure diagram of the negative first screen 30 is shown, and the negative first screen 30 includes a desktop container 31 and a negative first screen root layout 32, and the negative first screen root layout 32 runs in the desktop container 31. The display layout of the negative first screen 30 is no longer limited by the display layout style of the ordinary screen 20: for example, the negative first screen 30 can support up and down sliding, and compared with the display content of the ordinary screen 20, the negative first screen 30 can present more content to the user. Moreover, the content displayed by the negative first screen 30 is not limited to various application icons. For example, the negative first screen 30 can access third-party services to achieve software revenue.

[0114] In order to realize the loading of negative one screen, the code resource loading module 702 needs to load the code in the plug-in installation package, that is, the negative one screen code, into the virtual machine. It can be understood that the code resource loading module 702 loads the negative one screen code into the virtual machine, which is actually loading the class file in the negative one screen code into the Java virtual machine. In the Android compilation system, the class file is further processed to turn it into a dex file. The dex file is an executable file on the Android platform, which is equivalent to the exe file in the Windows platform. Each Apk installation package has a dex file, which contains all the source code of the installation package. Therefore, the code resource loading module 702 loads the code in the plug-in installation package, which is actually loading the dex file in this plug-in installation package.

[0115] When loading a class, the code resource loading module 702 can use ClassLoader. To load a dex file, DexClassLoader can be used. DexClassLoader is a class that inherits from ClassLoader. Therefore, in this embodiment, the code resource loading module 702 can use DexClassLoader to load the dex file of the negative one screen. Specifically, the code resource loading module 702 loads the dex file from the installation package of the negative one screen through DexClassLoader.

[0116] After DexClassLoader loads the dex file of the negative one screen into the virtual machine, it actually loads the class corresponding to the negative one screen into the virtual machine. In this case, the code resource loading module 702 can load the root layout of the negative one screen by reflection loading: the code resource loading module 702 finds the method to load the root layout of the negative one screen from the loaded class, and then loads the root layout of the negative one screen according to this method.

[0117] After loading the negative one screen code into the virtual machine, the code resource loading module 702 also needs to load the negative one screen resources into the virtual machine. Negative one screen resources include text, pictures, entries, etc. In the Android system, the getResource method can be used to obtain the corresponding Resource object, and the various parameters required to create the Resource object need to be passed in through the Asset Manager. Therefore, in this embodiment, in order to load the negative one screen resources, the code resource loading module 702 can first build the Asset Manager, then build the Resource object through the AssetManager, and then load the negative one screen resources into the virtual machine according to the Resource object.

[0118] Through the processing of the code resource loading module 702, the code and resources of the negative one screen can be loaded into the virtual machine. However, since the dex file in the negative one screen installation package Apk is loaded into the desktop container process in DexClassLoader, the context of the desktop container is passed in when the negative one screen root layout is reflected and loaded. Therefore, in this case, the negative one screen code runs in the process of the desktop container, which is actually in the operating environment of the desktop container. When acquiring resources, the negative one screen can only obtain the resources of the desktop container. Its various resources (such as pictures, layouts, entries, etc.) cannot be found in the resources of the desktop container.

[0119] Therefore, in order to ensure that the negative one screen can obtain its own resources when running, in this embodiment, after the code resource loading module 702 loads the negative one screen resources into the virtual machine, the operating environment creation module 704 also needs to process the Context representing the negative one screen operating environment: the operating environment creation module 704 creates a Context belonging to the negative one screen, for example, the operating environment creation module 704 customizes Mcontext, and Mcontext inherits from ContextWrapper, which serves as the Context of the negative one screen, which includes the resource acquisition path of the negative one screen resources.

[0120] After the running environment creation module 704 creates the Context of the negative one screen, the negative one screen loading module 706 can load the negative one screen according to the Context. It can be understood that the negative one screen loading module 706 loads the negative one screen according to the running context of the negative one screen, which actually runs the negative one screen code according to the running context of the negative one screen, and references the negative one screen resources during the code running process to present the negative one screen to the user. In other words, the negative one screen loading module 706 runs the negative one screen code in the running environment corresponding to the negative one screen running context, and references the negative one screen resources to provide the negative one screen service to the user. At this time, the negative one screen runs in the running environment belonging to the negative one screen, and can obtain its own resources, rather than running in the running environment of the desktop container and can only obtain the resources of the desktop container.

[0121] Through the above process, the loading of the negative one screen can be realized. However, since the negative one screen and the desktop container belong to different processes, there is no direct communication between the two, which makes it impossible for the desktop container to notify the negative one screen of events such as the user sliding in and the user sliding out of the negative one screen. It is understandable that if the negative one screen can understand when the user slides in, it can update the content when the user slides in, so as to provide the user with the latest and most real-time business services. At the same time, if the negative one screen understands when the user slides out, it can release the memory in time and end certain monitoring, thereby avoiding resource occupation and waste. Therefore, if the negative one screen cannot communicate with the desktop container, the negative one screen may only be able to perform content updates and resource release at regular intervals, and cannot provide users with high-quality business services, which can easily lead to a poor user experience. Therefore, in order to let the negative one screen understand the user's sliding in, sliding out and other events, this embodiment provides a solution:

[0122] See also Figure 8 A schematic diagram of the structure of the negative one screen loading device in an example of the present embodiment is shown: in this example, the negative one screen loading device 80 includes not only a code resource loading module 802, an operating environment creation module 804 and a negative one screen loading module 806, but also an event distribution module 808. The event distribution module 808 can call the dispatch Key Event in the View event distribution mechanism to realize the communication between the desktop container and the negative one screen: when the desktop container detects an event for the negative one screen, the event distribution module 808 can call the dispatch Key Event to distribute the event to the negative one screen. It can be understood that the dispatch KeyEvent is not only used to distribute events to the negative one screen, but also to distribute events belonging to the ordinary screen (also known as system events) to the desktop container. Therefore, when the dispatch Key Event performs event distribution, it is necessary to distinguish whether the event to be distributed currently belongs to the ordinary screen or the negative one screen.

[0123] In this embodiment, the event distribution module 808 can distinguish whether the current event to be distributed belongs to the negative one screen or the original system event through the event attribute information. The event attribute information includes action and code, wherein the action includes a key press event, a key pop-up event, etc.; and the code is used to indicate which key the event is for. In order to distinguish the negative one screen event from the original system event, the parent view in the desktop container ensures that the event attribute information of the two is different before distributing the event. In this way, when the event distribution module 808 controls the dispatch Key Event to distribute the event, the dispatch Key Event can determine whether the current event belongs to the negative one screen based on the event attribute information. It can be understood that as long as there is one piece of information in the event attribute information of the negative one screen event that is different from the event attribute information of the system event, the purpose of distinction can be achieved. Of course, in some examples of this embodiment, the action and code of the negative one screen event can be different from the action and code of each system event.

[0124] Since the event type and information code of the system event are usually positive or non-negative, in some examples of this embodiment, in order to facilitate the distinction, at least one of the information in the event attribute information of the negative one screen event can be set to a negative number. In this way, when the dispatch Key Event determines that the event attribute information of the event to be dispatched currently includes a negative number, it can be directly determined that the event is a negative one screen event. For example, in an example of this embodiment, the action and code of the negative one screen event are both negative numbers, while the action and code of the system event are both positive numbers.

[0125] In this embodiment, the code of the negative one screen runs in the desktop container process, so it is impossible to directly read and write data from the private data area of ​​the negative one screen. In some related solutions, AIDL and Service are used to complete cross-process communication for this situation, but this solution has the following defects:

[0126] 1) During the operation of the negative screen, the service needs to be kept alive. In other words, when the negative screen needs to read and write data with the service, it needs to first determine whether the service is in a running state. If the service is in a running state, data can be read normally; otherwise, the service must be started before data can be read and written. In other words, this data read and write demand cannot be responded to normally.

[0127] 2) When loading the negative one screen root layout, the data saved in the negative one screen private data area may be needed. If the Service is not started when loading the negative one screen root layout, the negative one screen cannot be loaded. In this case, the loading process of the negative one screen will be interrupted, which will cause the loading time of the negative one screen to be longer.

[0128] 3) Since this solution of reading and writing data from the private data area of ​​the negative one screen is based on Service and AIDL, when there is a need to read and write data, it is necessary to extend the corresponding interface to AIDL, and the interface must also be implemented in the Service. In this way, if the third-party aar (Android Archive, Android binary archive file) package wants to read data, it also needs to provide an interface for it through callback, which will make the logic complex and highly coupled.

[0129] In order to avoid the above problems, this embodiment also provides a negative one screen loading device, see Fig. 9 :

[0130] The negative one screen loading device 90 includes a code resource loading module 902, a running environment creation module 904 and a negative one screen loading module 906. In addition, the negative one screen loading device 90 also includes a data reading and writing module 908. The data reading and writing module 908 uses Content Provider to encapsulate and form a first SharedPreferences interface, and uses the first SharedPreferences interface to replace the Shared Preferences interface in the Context (i.e., the Context of the desktop container) reflected and passed in when loading the root layout of the negative one screen. In other words, the first SharedPreferences interface can also be included in the running context Mcontext of the negative one screen. For the negative one screen, it can have two SharedPreferences interfaces, one of which is the first SharedPreferences interface encapsulated by Content Provider as mentioned above; the other is the real SharedPreferences interface, which is referred to as the second SharedPreferences interface here. After the negative one screen is loaded, the data reading and writing module 908 can read and write data in the private data area of ​​the negative one screen through the first Shared Preferences interface and the second Shared Preferences interface of the negative one screen.

[0131] When the desktop container has a need to read data from the private data area of ​​the negative one screen, the data read-write module 908 can control the desktop container to send a read request for the first target data to the negative one screen through the first Shared Preferences interface. It can be understood that the read request can include information for indicating the first target data to be read. After the negative one screen receives the read request from the desktop container through the first Shared Preferences interface, the data read-write module 908 can control the negative one screen to use the second Shared Preferences interface to read the first target data from the private data area according to the read request. After the second Shared Preferences interface reads the first target data from the private data area of ​​the negative one screen, the data read-write module 908 can send the read first target data to the desktop container again through the first Shared Preferences interface.

[0132] When the desktop container needs to write the second target data into the private data area of ​​the negative one screen, the data read-write module 908 can control the desktop container to send a write request to the negative one screen through the first Shared Preferences interface, and the write request at least includes the second target data to be written. After the negative one screen receives the write request sent by the desktop container through the first Shared Preferences interface, the data read-write module 908 can parse the write request to obtain the second target data, and then control the negative one screen to write the second target data into the private data area through the second Shared Preferences interface.

[0133] According to the above introduction, the first Shared Preferences interface is equivalent to a bridge for cross-process communication between the desktop container and the negative one screen, while the second Shared Preferences interface is mainly used to realize the communication between the negative one screen and the private data area. For a third party, it can directly call the first Shared Preferences interface to realize the reading and writing of data in the negative one screen private data area, and will not perceive the cross-process communication between the desktop container and the negative one screen, thus reducing the coupling with the third party.

[0134] In this embodiment, the negative one screen loading device can be deployed on a terminal, such as a mobile phone with an Android system, a tablet computer, and a smart wearable device, etc. It can be understood that the negative one screen loading device can include an event distribution module and a data reading and writing module at the same time. The functions of the code resource loading module, the operating environment creation module, the negative one screen loading module, the event distribution module, and the data reading and writing module can all be implemented by the processor of the terminal.

[0135] The negative one screen loading device provided in this embodiment, when the negative one screen code is separated from the desktop container code, loads the negative one screen code and the negative one screen resources into the virtual machine, creates a negative one screen running context pointing to the negative one screen resources, and replaces the desktop container running context with the negative one screen running context, so that the negative one screen can run in its own running environment and reference its own resources. Thus, the loading of the negative one screen in the desktop container process is realized while reducing the coupling between the negative one screen and the desktop container. Moreover, through the dispatchKey Event in the view event distribution mechanism, the negative one screen can be notified of events such as the user sliding into the negative one screen and sliding out of the negative one screen, so that the negative one screen can provide users with better services. At the same time, through the mutual cooperation of the first Shared Preferences interface and the second Shared Preferences interface, the third party can realize the reading and writing of data to the private data area of ​​the negative one screen without perceiving the cross-process communication, avoiding various problems caused by the reading and writing of data with the help of AIDL and Service.

[0136] In addition, since the negative one screen code is independent of the desktop container code, the default permissions required by the negative one screen will no longer be attributed to the default permissions required by the desktop container, which makes it easier for the negative one screen to pass Google's testing when requesting default permissions.

[0137] Embodiment 4:

[0138] This embodiment provides a computer-readable storage medium and a terminal. First, the storage medium is described:

[0139] The computer-readable storage medium may store one or more computer programs that can be read, compiled and executed by one or more processors. In the present embodiment, the computer-readable storage medium may store a negative-one-screen loading program, which can be executed by one or more processors to implement the steps of any one of the negative-one-screen loading methods introduced in the aforementioned embodiment one or embodiment two.

[0140] This embodiment also provides a terminal, see Fig.10 The hardware structure diagram of the terminal is shown as follows:

[0141] The terminal 100 includes a processor 101, a memory 102, and a communication bus 103 for connecting the processor 101 and the memory 102, wherein the memory 102 may be the aforementioned storage medium storing the negative one screen loading program. The processor 101 may read the negative one screen loading program stored in the memory 102, compile and execute the steps of implementing any one of the negative one screen loading methods described in the first or second embodiment:

[0142] The processor 101 loads the negative one screen code and the negative one screen resources into the virtual machine, where the negative one screen code is independent of the desktop container code; then the processor 101 creates a negative one screen running context including a resource acquisition path for the negative one screen resources and replaces the running context of the desktop container, and loads the negative one screen according to the negative one screen running context.

[0143] In an example of this embodiment, the running context of the negative one screen also includes a first shared preference SharedPreferences interface, and the first Shared Preferences interface is encapsulated by the content provider ContentProvider; after loading the negative one screen according to the running context of the negative one screen, the processor 101 will also read and write data in the private data area of ​​the negative one screen through the first SharedPreferences interface and the second Shared Preferences interface of the negative one screen.

[0144] In an example of the present embodiment, after loading the negative one screen according to the running context of the negative one screen, the processor 101 will also call the key event dispatch dispatchKey Event in the user interface View event distribution mechanism to distribute events to the negative one screen. The event of the negative one screen event is different from the event attribute information of the original events of the system in at least one information. The event attribute information includes event type action information and information code code information.

[0145] The details of the negative one-screen loading method implemented by the terminal 100 in the first or second embodiment can be found in the introduction of the aforementioned embodiment, which will not be repeated here.

[0146] Here we will combine Fig.11 The communication network system architecture diagram where the terminal 100 is located briefly introduces the communication network system where the terminal 100 is located: the communication network system is an LTE system of universal mobile communication technology, and the LTE system includes UE (User Equipment) 201, E-UTRAN (Evolved UMTS Terrestrial Radio Access Network) 202, EPC (Evolved Packet Core) 203 and the operator's IP service 204, which are connected in sequence.

[0147] Specifically, UE201 may be the above-mentioned terminal 100, which will not be described in detail here.

[0148] E-UTRAN 202 includes eNodeB 2021 and other eNodeBs 2022 , etc. Among them, eNodeB 2021 can be connected to other eNodeBs 2022 through a backhaul (eg, an X2 interface), and eNodeB 2021 is connected to EPC 203 , and eNodeB 2021 can provide UE 201 with access to EPC 203 .

[0149] EPC203 may include MME (Mobility Management Entity) 2031, HSS (Home Subscriber Server) 2032, other MMEs 2033, SGW (Serving Gate Way) 2034, PGW (PDN Gate Way) 2035 and PCRF (Policy and Charging Rules Function) 2036, etc. Among them, MME2031 is a control node that processes signaling between UE201 and EPC203, and provides bearer and connection management. HSS2032 is used to provide some registers to manage functions such as home location register (not shown in the figure), and save some user-specific information such as service features and data rates. All user data can be sent through SGW2034, PGW2035 can provide IP address allocation and other functions for UE 201, PCRF2036 is the policy and charging control policy decision point for service data flow and IP bearer resources, which selects and provides available policy and charging control decisions for the policy and charging execution function unit (not shown in the figure).

[0150] The IP service 204 may include the Internet, an intranet, an IMS (IP Multimedia Subsystem) or other IP services.

[0151] Although the above introduction takes the LTE system as an example, those skilled in the art should know that the present invention is not only applicable to the LTE system, but also to other wireless communication systems, such as GSM, CDMA2000, WCDMA, TD-SCDMA and future new network systems, etc., which are not limited here.

[0152] In this embodiment, the terminal first loads the negative one screen code and the negative one screen resources into the virtual machine, then creates a running context of the negative one screen to replace the running context of the desktop container, and loads the negative one screen according to the running context of the negative one screen. Since the running context of the negative one screen includes the resource acquisition path of the negative one screen resources, when the virtual machine runs the negative one screen code, the resources corresponding to the negative one screen can be obtained, so that when the negative one screen code and the desktop container code are independent, the effect of displaying the negative one screen on the desktop container is achieved, and the loading of the negative one screen is completed. On the basis of ensuring the normal loading of the negative one screen, the coupling degree between the negative one screen business logic and the desktop container business logic is reduced, the maintenance cost of the negative one screen and the desktop container versions is reduced, and it is beneficial to the version upgrade of the negative one screen and the desktop container.

[0153] Obviously, those skilled in the art should understand that all or some steps, systems, and functional modules / units in the above disclosed methods can be implemented as software (which can be implemented with program code executable by a computing device), firmware, hardware, and appropriate combinations thereof. In hardware implementations, the division between the functional modules / units mentioned in the above description does not necessarily correspond to the division of physical components; for example, a physical component can have multiple functions, or a function or step can be performed by several physical components in cooperation. Some physical components or all physical components can be implemented as software executed by a processor, such as a central processing unit, a digital signal processor, or a microprocessor, or implemented as hardware, or implemented as an integrated circuit, such as an application-specific integrated circuit. Such software can be distributed on a computer-readable medium, executed by a computing device, and in some cases, the steps shown or described can be performed in a different order than herein, and the computer-readable medium can include a computer storage medium (or a non-transitory medium) and a communication medium (or a transient medium). As is well known to those of ordinary skill in the art, the term computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storing information (such as computer readable instructions, data structures, program modules or other data). Computer storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tapes, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information and can be accessed by a computer. In addition, it is well known to those of ordinary skill in the art that communication media typically contain computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transmission mechanism, and may include any information delivery medium. Therefore, the present invention is not limited to any particular combination of hardware and software.

[0154] The above contents are further detailed descriptions of the embodiments of the present invention in combination with specific implementation methods, and it cannot be determined that the specific implementation of the present invention is limited to these descriptions. For ordinary technicians in the technical field to which the present invention belongs, several simple deductions or substitutions can be made without departing from the concept of the present invention, which should be regarded as falling within the protection scope of the present invention.

Claims

1. A negative one screen loading method, characterized in that: The method includes: Loading the negative one screen code and the negative one screen resource into the virtual machine respectively, wherein the negative one screen code is independent of the desktop container code; Creating a negative one screen running context and replacing the running context of the desktop container, wherein the negative one screen running context includes a resource acquisition path for the negative one screen resources; The negative one screen is loaded according to the running context of the negative one screen.

2. The negative one screen loading method as claimed in claim 1, characterized in that: The loading of the negative one screen code into the virtual machine comprises: Using the Dex class loader to load the executable dex file of the negative one screen; Reflection loads the root layout of the negative one screen.

3. The negative one screen loading method as claimed in claim 1, characterized in that: The loading of the negative one screen resource into the virtual machine comprises: Construct the resource manager AssetManager; Construct a resource Resource object through the AssetManager; The negative one screen resource is loaded into the virtual machine according to the Resource object.

4. The negative one screen loading method according to any one of claims 1 to 3, characterized in that: After the negative one screen is loaded according to the running context of the negative one screen, the method further includes: The key event dispatch dispatchKeyEvent in the user interface View event distribution mechanism is called to distribute events to the negative one screen. The event of the negative one screen event is different from the event attribute information of the original events of the system in at least one information. The event attribute information includes event type action information and information code code information.

5. The negative one screen loading method as claimed in claim 4, characterized in that: The event attribute information of the negative one screen event is a negative number, and the event attribute information of the original events of the system is a non-negative number.

6. The negative one screen loading method according to any one of claims 1 to 3, characterized in that: The negative one screen running context also includes a first shared preference Shared Preferences interface, wherein the first Shared Preferences interface is formed by encapsulating a content provider Content Provider; After the negative one screen is loaded according to the running context of the negative one screen, the method further includes: Data is read and written in the private data area of ​​the negative one screen through the first Shared Preferences interface and the second Shared Preferences interface of the negative one screen.

7. The negative one screen loading method as claimed in claim 6, characterized in that: The reading and writing of data in the private data area of ​​the negative first screen through the first Shared Preferences interface and the second Shared Preferences interface of the negative first screen includes the following data reading process and data writing process: Data reading process: receiving, through the first Shared Preferences interface, a read request for first target data sent by the desktop container; Reading the first target data from the private data area according to the read request through the second Shared Preferences interface; Sending the first target data read by the second Shared Preferences interface to the desktop container through the first Shared Preferences interface; Data writing process: receiving a write request sent by the desktop container through the first Shared Preferences interface, wherein the write request carries the second target data to be stored; Control the second Shared Preferences interface to write the second target data into the private data area.

8. A negative screen loading device, characterized in that: include: A code resource loading module, used to load the negative one screen code and the negative one screen resource into the virtual machine respectively, wherein the negative one screen code is independent of the desktop container code; An operating environment creation module, used to create an operating context of the negative one screen and replace the operating context of the desktop container, wherein the operating context of the negative one screen includes a resource acquisition path of the negative one screen resources; The negative one screen loading module is used to load the negative one screen according to the running context of the negative one screen.

9. A terminal, characterized in that: The terminal includes a processor, a memory and a communication bus; The communication bus is used to realize the connection and communication between the processor and the memory; The processor is used to execute one or more programs stored in the memory to implement the steps of the negative-one-screen loading method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores one or more programs, and the one or more programs can be executed by one or more processors to implement the steps of the negative-one-screen loading method according to any one of claims 1 to 7.

Images