Memory expansion method and related equipment

Abstract

The invention discloses a memory expansion method and related equipment. According to the method, the electronic equipment can create a first zygote virtual machine and a second zygote virtual machine. The memory size of the Java memory space of the first zygote virtual machine is greater than the default memory size, and the memory size of the Java memory space of the second zygote virtual machine is the default memory size. And if the specific application cold start is triggered, the electronic equipment can copy the virtual machine corresponding to the application based on the first zygote virtual machine. The memory of the Java memory space in the virtual machine corresponding to the application is the same as the memory of the Java memory space in the first zygote virtual machine, and the memory of the Java memory space and the memory of the Java memory space in the first zygote virtual machine are both larger than the default memory size. By means of the method, the electronic device can achieve memory expansion of the Java memory space under the condition that the system stability is guaranteed, and therefore the problems of jamming and the like caused by too large memory occupation are avoided.

Description

Technical Field

[0001] The present application relates to the field of terminal technology, and in particular to a memory expansion method and related equipment. Background Art

[0002] Since an application uses too much memory, it may cause the system to crash or become unstable, an application occupying a large amount of memory may cause other applications to fail to operate normally, and the hardware resources of electronic devices are relatively limited. In order to ensure system stability, fair resource allocation, and limited by the hardware resources of the device, the operating system will limit the memory usage of the application. For example, in the Android operating system, the maximum Java memory available to the application is 512 megabytes (MB). In the case of limited memory of the above-mentioned application, if there are usage specification problems in the process of calling interfaces or controls in each module of the application, the application business is complex and the development cycle is tight, memory leaks may occur, and if the application uses a multi-threaded asynchronous framework, some objects may be delayed in release. Both memory leaks and delayed object release may cause high application memory usage and insufficient available memory. Once the Java memory available to the application is insufficient, the application will trigger garbage collection (GC) for Block type. In this case, the application will suspend other tasks, causing serious jams and serious performance problems.

[0003] Therefore, how to expand the Java memory available to applications while ensuring system stability is a problem that needs to be solved urgently. Summary of the invention

[0004] The present application provides a memory expansion method and related equipment. According to the memory expansion method, an electronic device can create two zygote processes and two corresponding zygote virtual machines. The memory (i.e., Java memory) size of the Java memory space in one zygote virtual machine is greater than the second value, and the memory size of the Java memory space in the other zygote virtual machine is the second value. For a specific application cold start scenario, the electronic device can copy the virtual machine corresponding to the specific application based on the zygote virtual machine with a larger Java memory, so that the Java memory available to the specific application is expanded and larger than the second value.

[0005] In a first aspect, the present application provides a memory expansion method. The memory expansion method can be applied to an electronic device. The electronic device is created with a first zygote virtual machine and a second zygote virtual machine. The memory size of the Java memory space in the first zygote virtual machine is a first value, and the memory size of the Java memory space in the second zygote virtual machine is a second value. The first value is greater than the second value. According to the memory expansion method, the electronic device can receive a first instruction from a user to cold start a first application. In response to the first instruction, when the first application meets a preset condition, the electronic device can copy the first zygote virtual machine to obtain the first virtual machine. The first virtual machine is a virtual machine instance corresponding to the first application process. The first application process is a process corresponding to the first application. The memory size of the Java memory space in the first virtual machine is a first value.

[0006] In the scheme provided in the present application, the electronic device can create two zygote processes, namely the first zygote process and the second zygote process. The virtual machine instances corresponding to the first zygote process and the second zygote process are the first zygote virtual machine and the second zygote virtual machine, respectively. The electronic device can apply for a virtual address larger than the default memory size in the process of creating the Java memory space in the first zygote virtual machine to perform memory expansion, and apply for a virtual address corresponding to the default memory size in the process of creating the Java memory space in the second zygote virtual machine, and no memory expansion is performed. In this way, for a part of applications with extended memory requirements, the electronic device can obtain the virtual machine corresponding to the application according to the first zygote virtual machine copy, so that the application can use a Java memory larger than the default memory size. For other applications that do not have extended memory requirements, the electronic device can obtain the virtual machine corresponding to the application according to the second zygote virtual machine copy, so that the application can use the Java memory of the default memory size. In this way, the electronic device can implement memory expansion of the Java memory space for specific applications while ensuring system stability, thereby avoiding problems such as jamming caused by GC when the memory occupancy is too large.

[0007] It is understood that the zygote virtual machine is a virtual machine instance corresponding to the zygote process. The first virtual machine is a virtual machine instance corresponding to the process corresponding to the first application. It is understood that the memory size of the Java memory space is the Java memory size.

[0008] In some embodiments of the present application, the first zygote process may be zygote process_1, the second zygote process may be zygote process_2, the first zygote virtual machine may be zygote virtual machine_1, and the second zygote virtual machine may be zygote virtual machine_2.

[0009] In some embodiments of the present application, the first application may be application_1. The first virtual machine may be application_1 virtual machine.

[0010] In some embodiments of the present application, the first instruction may be the instruction in step S103 (eg Figure 8 ), which may be the instruction in step S204 (such as Fig. 9 ), or it can be an instruction in S701 (such as Fig.16 shown).

[0011] It is understandable that the units of the first value and the second value are the units of the memory of the Java memory space. It is understandable that the unit of the memory of the Java memory space (i.e., Java memory) can be MB. Of course, the unit of Java memory can also be other. In the case where the unit of Java memory changes, the first value and the second value will also change. For example, in the case where the unit of Java memory is MB, the first value can be 768 and the second value can be 512. Since 768MB=0.75GB and 512MB=0.5GB, then, in the case where the unit of Java memory is GB, the first value is converted to 0.75 and the second value is converted to 0.5. It should be noted that the units of Java memory corresponding to the first value and the second value can be set according to actual needs. For example, the units of Java memory corresponding to the first value and the second value are uniformly set to MB.

[0012] The default memory size involved in the present application may be the default memory size of the Java memory space. The default memory size of the Java memory space refers to the maximum available Java memory originally used by the Java memory space. The default memory size carries units. For example, the default memory size may be 512MB. It is understandable that the difference between the default memory size and the second value is that the default memory size carries units, while the second value does not carry units. For example, the second value may be 512, which means that the default memory size is 512MB.

[0013] In some embodiments of the present application, the virtual address corresponding to the Java memory space can be understood as: the virtual address segment corresponding to the Java memory space, and the memory size corresponding to the virtual address segment is related to the memory size of the Java memory space. In the present application, the virtual address segment corresponding to the Java memory space can be understood as the virtual address segment that can be used by the Java memory space. In the case where the virtual address segment corresponding to the Java memory space is the virtual address currently used by the Java memory space, the memory size corresponding to the virtual address segment is the current memory size of the Java memory space. In the case where the virtual address segment corresponding to the Java memory space is not all the virtual address currently used by the Java memory space, the memory size corresponding to the virtual address segment currently used by the Java memory space is the current memory size of the Java memory space.

[0014] In combination with the first aspect, in a possible implementation, after the electronic device receives a first instruction from a user to cold start the first application, the method may further include: in response to the first instruction, when the first application does not meet a preset condition, the electronic device copies a second zygote virtual machine to obtain a second virtual machine. The second virtual machine is a virtual machine instance corresponding to the first application process. The memory size of the Java memory space in the second virtual machine is a second value.

[0015] In the solution provided by the present application, the electronic device does not need to perform memory expansion for every cold-start application, but only performs memory expansion for applications that require memory expansion (for example, applications that meet preset conditions), and does not perform memory expansion for other applications. This method can avoid excessive memory usage of the operating system due to memory expansion for every cold-start application, thereby ensuring system stability.

[0016] In combination with the first aspect, in a possible implementation, the first zygote virtual machine is a virtual machine instance corresponding to the first zygote process, and the second zygote virtual machine is a virtual machine instance corresponding to the second zygote process. Before the electronic device receives a first instruction from a user to cold start the first application, the method may also include: the electronic device receives a second instruction from a user to start the electronic device; in response to the second instruction, the electronic device may create a first zygote process and a first zygote virtual machine, and create a second zygote process and a second zygote virtual machine; the electronic device may incubate a system service SystemServer process based on the second zygote process.

[0017] In the solution provided by the present application, after the electronic device creates the first zygote process and the second zygote process, the SystemServer process can be hatched based on the second zygote process. The SystemServer process is a system process, and the electronic device does not need to expand its memory.

[0018] In conjunction with the first aspect, in a possible implementation, the electronic device receives a first instruction from a user to cold start a first application, which may specifically include: the electronic device receives the first instruction by initiating a process. After the electronic device receives the first instruction from the user to cold start the first application, the method may also include: in response to the first instruction, the electronic device may notify a SystemServer process in the electronic device to start the first application by initiating a process; the electronic device may determine whether the first application meets a preset condition through the SystemServer process.

[0019] It can be understood that the SystemServer process determines whether the first application meets the preset conditions. The SystemServer process is responsible for starting and managing the entire application framework layer. The SystemServer process is the entry point used by the operating system to start the service. In the solution provided in the present application, the electronic device can determine whether the first application meets the preset conditions through the SystemServer process, so that the corresponding zygote process can be directly notified through the SystemServer process to fork the application process. There is no need to perform the above judgment through other modules, and then instruct the SystemServer process to notify the corresponding zygote process to fork the application process, which simplifies the process.

[0020] In combination with the first aspect, in a possible implementation method, when the first application meets the preset conditions, the electronic device copies the first zygote virtual machine to obtain the first virtual machine, which may specifically include: when the electronic device determines through the SystemServer process that the first application meets the preset conditions, the electronic device may notify the first zygote process in the electronic device through the SystemServer process to incubate the first application process; in the process of incubating the first application process through the first zygote process, the electronic device copies the first virtual machine from the first zygote virtual machine.

[0021] In the solution provided in the present application, when the first application meets the preset conditions, the electronic device can directly notify the first zygote process in the electronic device to incubate the first application process through the SystemServer process. The SystemServer process can directly notify the first zygote process to incubate the first application process through the established corresponding Socket channel without the need for transfer through other modules, thereby simplifying the process.

[0022] In combination with the first aspect, in a possible implementation method, when the first application does not meet the preset conditions, the electronic device copies a second zygote virtual machine to obtain a second virtual machine, which may specifically include: when the electronic device determines through the SystemServer process that the first application does not meet the preset conditions, the electronic device may notify the second zygote process in the electronic device through the SystemServer process to incubate the first application process; in the process of incubating the first application process through the second zygote process, the electronic device copies the second zygote virtual machine to obtain the second virtual machine.

[0023] In the solution provided in the present application, when the first application does not meet the preset conditions, the electronic device can directly notify the second zygote process in the electronic device to incubate the first application process through the SystemServer process. The SystemServer process can directly notify the second zygote process to incubate the first application process through the established corresponding Socket channel, without the need for transfer through other modules, thereby simplifying the process.

[0024] In combination with the first aspect, in a possible implementation, the virtual address corresponding to the Java memory space in the first zygote virtual machine is a first virtual address segment. The memory size corresponding to the first virtual address segment is a first value. The virtual address corresponding to the Java memory space in the second zygote virtual machine is a second virtual address segment. The memory size corresponding to the second virtual address segment is a second value. The method may also include: in the process of the electronic device creating the first zygote virtual machine, the electronic device may determine that the memory size of the Java memory space in the first zygote virtual machine is the first value, and, for the Java memory space in the first zygote virtual machine, the electronic device may apply for the first virtual address segment and map the first virtual address segment to the physical address; in the process of the electronic device creating the second zygote virtual machine, the electronic device may determine that the memory size of the Java memory space in the second zygote virtual machine is the second value, and, for the Java memory space in the second zygote virtual machine, the electronic device may apply for the second virtual address segment and map the second virtual address segment to the physical address.

[0025] In the solution provided by the present application, the electronic device can apply for a virtual address corresponding to a memory larger than the default memory size in the process of creating a Java memory space in the first zygote virtual machine, and the other virtual machines obtained by subsequently copying the first zygote virtual machine can use the virtual address corresponding to the larger memory applied for, that is, the Java memory that can be used by the other virtual machines is larger than the default memory size. However, the electronic device can still apply for a virtual address corresponding to the default memory size in the process of creating a Java memory space in the second zygote virtual machine, and the other virtual machines obtained by subsequently copying the second zygote virtual machine can use the virtual address corresponding to the default memory size. In this way, the electronic device can provide two maximum available Java memories, namely, Java memory of the default memory size and Java memory larger than the default memory size. The electronic device can select the maximum available Java memory corresponding to different applications according to preset conditions, so as to realize memory expansion for specific applications (for example, applications that meet preset conditions), that is, the Java memory that can be used by other virtual machines is larger than the default memory size, which can avoid problems such as jamming caused by GC when the memory occupancy is too large.

[0026] In combination with the first aspect, in a possible implementation, the electronic device may apply for a first virtual address segment, and map the first virtual address segment to a physical address, which may specifically include: the electronic device may apply for an anonymous page corresponding to a first numerical value. The anonymous page corresponding to the first numerical value may include the first virtual address segment. The anonymous page may be used to represent a virtual address segment in a process virtual address space that has a mapping relationship with a physical address. The electronic device applies for a second virtual address segment, and maps the second virtual address segment to a physical address, which may specifically include: the electronic device may apply for an anonymous page corresponding to a second numerical value. The anonymous page corresponding to the second numerical value may include the second virtual address segment.

[0027] In the solution provided by the present application, for electronic devices whose operating system is an Android system, when the electronic device creates a zygote process, the creation of a Java memory space can be achieved by applying for an anonymous page. Specifically, when the electronic device creates a first zygote virtual machine, it can apply for an anonymous page corresponding to a first value, thereby creating a Java memory space with a memory size of the first value. Similarly, when the electronic device creates a second zygote virtual machine, it can apply for an anonymous page corresponding to a second value, thereby creating a Java memory space with a memory size of the second value.

[0028] In some embodiments of the present application, the anonymous page corresponding to the first value may refer to: when the memory size of the Java memory space is the first value, the anonymous page corresponding to the Java memory space. For example, the anonymous page corresponding to 768MB. The anonymous page corresponding to the second value may refer to: when the memory size of the Java memory space is the second value, the anonymous page corresponding to the Java memory space, that is, the anonymous page corresponding to the default memory size of the Java memory space. For example, the anonymous page corresponding to 512MB.

[0029] In combination with the first aspect, in a possible implementation method, the first application satisfies preset conditions, specifically including: in the historical records of memory usage after several cold starts of the first application, the number of first-category historical records is greater than the number of first-category historical records; the first-category historical records may include: historical records of occupied memory of the Java memory space in the first application virtual machine being greater than a first threshold.

[0030] In the solution provided in the present application, the electronic device can determine the high-load applications based on the historical records of the Java memory usage of the applications, and perform memory expansion for the high-load applications.

[0031] In some embodiments of the present application, the historical records of memory usage after the first application is cold started several times may include: the historical records of Java memory usage for the first application after the first application is cold started S times.

[0032] In combination with the first aspect, in a possible implementation manner, the first application satisfies a preset condition, specifically including: the first application is an application in a preset list.

[0033] In the solution provided by the present application, the electronic device can perform memory expansion on the applications in the preset list. The specific setting method of the preset list can be referred to below and will not be described in detail here.

[0034] In a second aspect, the present application provides a memory expansion method. The memory expansion method can be applied to an electronic device. The electronic device is created with a first zygote virtual machine and a second zygote virtual machine. The memory size of the Java memory space in the first zygote virtual machine is a first value, and the memory size of the Java memory space in the second zygote virtual machine is a second value. The first value is greater than the second value. The memory expansion method may include: the electronic device receives a first instruction from a user to cold start a first application, and in response to the first instruction, the electronic device copies the first zygote virtual machine to obtain a first virtual machine; the electronic device receives a second instruction from a user to cold start a second application process, and in response to the second instruction, the electronic device copies the second zygote virtual machine to obtain a third virtual machine. Among them, the first virtual machine is a virtual machine instance corresponding to the first application process. The first application process is a process corresponding to the first application. The memory size of the Java memory space in the first virtual machine is a first value. The third virtual machine is a virtual machine instance corresponding to the second application process. The second application process is a process corresponding to the second application. The memory size of the Java memory space in the third virtual machine is a second value.

[0035] In the solution provided in the present application, an electronic device can create two zygote processes and corresponding virtual machine instances, namely a first zygote process and a second zygote process, as well as a first zygote virtual machine and a second zygote virtual machine. The electronic device can apply for a virtual address larger than the default memory size in the process of creating the Java memory space in the first zygote virtual machine to perform memory expansion, and apply for a virtual address corresponding to the default memory size in the process of creating the Java memory space in the second zygote virtual machine, without performing memory expansion. In this way, for some applications, the electronic device can obtain the virtual machine corresponding to the application based on the copy of the first zygote virtual machine, so that the application can use a memory larger than the default memory size. For other applications, the electronic device can obtain the virtual machine corresponding to the application based on the copy of the second zygote virtual machine, so that the application can use the Java memory of the default memory size. In this way, the electronic device can implement memory expansion of the Java memory space for some applications while ensuring system stability, thereby avoiding problems such as jamming caused by GC when the memory occupancy is too large.

[0036] In some embodiments of the present application, the second application may be a system application. The second application process may be a system process. For example, the second application process may be a SystemServer process.

[0037] In conjunction with the second aspect, in a possible implementation manner, the first application meets a preset condition, and the second application does not meet the preset condition.

[0038] In conjunction with the second aspect, in a possible implementation, after the electronic device receives a first instruction from a user to cold start a first application, the method further includes: the electronic device notifies a SystemServer process in the electronic device to start the first application in response to the first instruction, and determines whether the first application meets a preset condition through the SystemServer process. After the electronic device receives a second instruction from a user to cold start a second application, the method further includes: the electronic device notifies a SystemServer process in the electronic device to start the second application in response to the second instruction, and determines whether the second application meets the preset condition through the SystemServer process.

[0039] In a third aspect, the present application provides an electronic device, comprising: one or more processors, and one or more memories; the one or more processors are coupled to the one or more memories, the one or more memories are used to store computer program code, the computer program code includes computer instructions, and the one or more processors call the computer instructions to enable the electronic device to perform the method described in the first aspect or any one of the implementations of the first aspect.

[0040] In a fourth aspect, the present application provides an electronic device, comprising: one or more processors, and one or more memories; the one or more processors are coupled to the one or more memories, the one or more memories are used to store computer program code, the computer program code includes computer instructions, and the one or more processors call the computer instructions to enable the electronic device to perform the method described in the second aspect or any one of the implementations of the second aspect.

[0041] In a fifth aspect, the present application provides a computer storage medium comprising computer instructions. When the computer instructions are executed on an electronic device, the electronic device executes the method described in the first aspect or any one of the implementations of the first aspect.

[0042] In a sixth aspect, the present application provides a computer storage medium comprising computer instructions. When the computer instructions are executed on an electronic device, the electronic device executes the method described in the second aspect or any one of the implementations of the second aspect.

[0043] In the seventh aspect, an embodiment of the present application provides a chip, which can be applied to an electronic device. The chip includes one or more processors, and the processor is used to call computer instructions to enable the electronic device to execute the method described in the first aspect or any one of the implementations of the first aspect.

[0044] In an eighth aspect, an embodiment of the present application provides a chip, which can be applied to an electronic device. The chip includes one or more processors, and the processor is used to call computer instructions to enable the electronic device to execute the method described in the second aspect or any one of the implementations of the second aspect.

[0045] In a ninth aspect, an embodiment of the present application provides a computer program product comprising instructions, which, when executed on an electronic device, enables the electronic device to execute the method described in the first aspect or any one of the implementations of the first aspect.

[0046] In the tenth aspect, an embodiment of the present application provides a computer program product comprising instructions, which, when executed on an electronic device, enables the electronic device to execute the method described in the second aspect or any one of the implementations of the second aspect.

[0047] It can be understood that the electronic device provided in the third aspect, the computer storage medium provided in the fifth aspect, the chip provided in the seventh aspect, and the computer program product provided in the ninth aspect are all used to execute the method described in the first aspect or any one of the implementations of the first aspect. Therefore, the beneficial effects that can be achieved can refer to the beneficial effects of any possible implementation of the first aspect, which will not be repeated here. The electronic device provided in the fourth aspect, the computer storage medium provided in the sixth aspect, the chip provided in the eighth aspect, and the computer program product provided in the tenth aspect are all used to execute the method described in the second aspect or any one of the implementations of the second aspect. Therefore, the beneficial effects that can be achieved can refer to the beneficial effects of any possible implementation of the second aspect, which will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0048] Figure 1 A schematic diagram of the incubation principle of a zygote process provided in an embodiment of the present application;

[0049] Figure 2 A schematic diagram of the software structure of an electronic device provided in an embodiment of the present application;

[0050] Figure 3 A schematic diagram of the incubation principle of another zygote process provided in an embodiment of the present application;

[0051] Figure 4A and Figure 4B A schematic diagram of a virtual machine provided in an embodiment of the present application;

[0052] Figure 5 A schematic diagram of a runtime data area provided in an embodiment of the present application;

[0053] Fig. 6A and Figure 6B Schematic diagram of different zygote virtual machines provided in embodiments of the present application;

[0054] Figure 7 Schematic diagram of the principles of two incubation methods provided in the embodiments of the present application;

[0055] Figure 8 A flowchart of a memory expansion method provided in an embodiment of the present application;

[0056] Fig. 9 A flowchart of another memory expansion method provided in an embodiment of the present application;

[0057] Fig.10 A flowchart of creating a zygote process and a SystemServer process provided in an embodiment of the present application;

[0058] Fig.11 A schematic diagram of a specific implementation method for creating a zygote process provided in an embodiment of the present application;

[0059] Fig.12 A flowchart of creating a zygote process and its corresponding virtual machine provided in an embodiment of the present application;

[0060] Fig.13 A flowchart of another method of creating a zygote process and its corresponding virtual machine provided in an embodiment of the present application;

[0061] Fig.14A A flowchart of creating a zygote virtual machine_1 provided in an embodiment of the present application;

[0062] Fig. 14B A flowchart of creating a zygote virtual machine_2 provided in an embodiment of the present application;

[0063] Fig.15 A schematic diagram of a new process provided in an embodiment of the present application;

[0064] Fig.16 A flowchart of starting an application and creating a corresponding virtual machine provided in an embodiment of the present application;

[0065] Fig.17 A schematic diagram of the hardware structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0066] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. In the description of the embodiments of the present application, unless otherwise specified, " / " means or, for example, A / B can mean A or B; "and / or" in the text is only a description of the association relationship of the associated objects, indicating that there can be three relationships, for example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone. In addition, in the description of the embodiments of the present application, "multiple" means two or more than two.

[0067] It should be understood that the terms "first", "second", etc. in the specification, claims and drawings of the present application are used to distinguish different objects, rather than to describe a specific order. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions. For example, a process, method, system, product or device that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units that are not listed, or may optionally include other steps or units that are inherent to these processes, methods, products or devices.

[0068] Reference to "embodiments" in this application means that a particular feature, structure, or characteristic described in conjunction with the embodiments may be included in at least one embodiment of the present application. The appearance of the phrase in various locations in the specification does not necessarily refer to the same embodiment, nor is it an independent or alternative embodiment that is mutually exclusive with other embodiments. It is explicitly and implicitly understood by those skilled in the art that the embodiments described in this application may be combined with other embodiments.

[0069] When using electronic devices such as mobile phones and computers, Figure 1 As shown, when an application in an electronic device is cold started, the zygote process in the electronic device can incubate (fork) the process corresponding to the application (i.e. Figure 1 The application process shown in the figure) and the virtual machine instance corresponding to the zygote process (i.e. Figure 1 The zygote virtual machine shown in the figure) copies the virtual machine instances corresponding to these applications (i.e. Figure 1Application virtual machine shown). Since the application virtual machine inherits the spatial layout of the zygote virtual machine, after the application in the electronic device is cold started, its available Java memory is limited. For example, for an electronic device using the Android operating system (which can be referred to as the Android system), the maximum available Java memory of the application in the electronic device is limited (for example, the default value of the maximum Java memory can be 512MB). It can be understood that Java memory refers to the memory provided to Java objects for use. The reason why the Java memory available to the application is limited is that excessive use of memory by the application may cause the system to crash or become unstable. The system needs to limit the memory usage of the application to ensure the stability of the system. The system can limit the memory available to each application to avoid the situation where some applications occupy a large amount of memory and cause other applications to fail to run normally. The hardware resources of the electronic device are relatively limited. The system needs to limit the memory of the application to ensure that all applications can run normally on the device.

[0070] However, when the application's memory is limited, the application may frequently run out of available memory. For example, there are usage specification issues when the application modules call interfaces or controls, and the application business is complex and the development cycle is tight, which may lead to memory leaks. Memory leaks refer to the fact that the dynamically allocated heap memory in the program is not released or cannot be released by the program for some reason. When memory is limited, memory leaks will further lead to high memory usage and insufficient available memory in the application. For another example, some applications use a multi-threaded asynchronous framework, which may cause delayed release of some objects. When memory is limited, delayed release of some objects may cause high memory usage and insufficient available memory in the application. Once the application's available memory is insufficient, the application will trigger a Block type GC, resulting in severe freezes and serious performance issues.

[0071] It can be understood that Block type GC means that when the application is short of memory and needs to apply for memory, the thread that needs to apply for memory in the application will suspend running and wait until the GC runs to the end before the thread that needs to apply for memory can continue to run.

[0072] The embodiment of the present application provides a memory expansion method and related equipment. According to the memory expansion method, an electronic device can create two zygote processes, namely zygote process_1 and zygote process_2. The virtual machine instances corresponding to zygote process_1 and zygote process_2 are zygote virtual machine_1 and zygote virtual machine_2 respectively. The memory size of the Java memory space of zygote virtual machine_1 is greater than the default memory size, and the memory size of the Java memory space of zygote virtual machine_2 is the default memory size. When creating zygote virtual machine_1, the electronic device can apply for a virtual address corresponding to a larger memory for the Java memory space, and when creating zygote virtual machine_2, the electronic device can apply for a virtual address corresponding to the default memory size for the Java memory space. In the case of triggering a cold start of a specific application, the electronic device can incubate the process of the specific application through zygote process_1, and copy the virtual machine corresponding to the specific application based on zygote virtual machine_1. Among them, the memory size of the Java memory space in the virtual machine corresponding to the specific application is the same as the memory size of the Java memory space in the zygote virtual machine_1, both of which are expanded memory sizes, that is, both are greater than the default memory size. It can be understood that Java memory space refers to the memory space provided for Java objects. In this way, electronic devices can achieve memory expansion of Java memory space while ensuring system stability, thereby avoiding problems such as jamming caused by GC when the memory usage is too large.

[0073] The following first introduces the software structure of the electronic device involved in this application.

[0074] See also Figure 2 , Figure 2 A schematic diagram of the software structure of an electronic device provided in an embodiment of the present application.

[0075] like Figure 2 As shown, the software framework of the electronic device involved in the present application may include an application layer, an application framework layer (framework, FWK), a system library, a runtime, a hardware abstraction layer (HAL) and a kernel layer (kernel).

[0076] The application layer may include a series of application packages. For example, application_1, calendar, gallery, call, Bluetooth, video, music, short message, WLAN and other applications (also referred to as applications). Application_1 may be a system application or a third-party application, which is not limited in this application. For example, application_1 may be a short video application, a live broadcast application, or a news application.

[0077] The application framework layer provides an application programming interface (API) and a programming framework for applications in the application layer. The application framework layer includes some predefined functions. The application framework layer can include a series of system services. System services are modular components that focus on specific functions. The functions provided by the application framework API can communicate with system services to access the underlying hardware.

[0078] The application framework layer may include a zygote process. The zygote process is a very important daemon service in the Android system. Other processes can be hatched (forked) through the zygote process.

[0079] In the present application, an electronic device can create two zygote processes. These two zygote processes can fork other processes. For ease of description, the present application records the two zygote processes created by the electronic device as zygote process_1 and zygote process_2. Among them, the memory size of the memory space corresponding to zygote process_1 is greater than the default memory size, and the memory size of the memory space corresponding to zygote process_2 is the default memory size. It can be understood that the memory space mentioned here may include Java memory space. In this case, the memory size of the memory space refers to the size of the Java memory, and the default memory size refers to the default memory size corresponding to the Java memory space, that is, the default Java memory.

[0080] For ease of description, this application records the memory size of the Java memory space corresponding to zygote process_1 as the first value, and the memory size of the Java memory space corresponding to zygote process_2 as the second value. The unit of the Java memory corresponding to the first value and the second value involved in the following text is MB.

[0081] It is understandable that the memory space corresponding to the zygote process may refer to the memory space of the virtual machine instance corresponding to the zygote process (hereinafter referred to as the zygote virtual machine). The description of the virtual machine instance corresponding to zygote process_1 and zygote process_2 can be referred to below, which will not be elaborated here.

[0082] The application framework layer may also include a system service (SystemServer) process. The SystemServer process is the first process forked by the zygote process_2. The virtual machine instance corresponding to the SystemServer process is copied from the virtual machine instance corresponding to the zygote process_2, so the virtual machine instance corresponding to the SystemServer process inherits the memory space layout of the virtual machine instance corresponding to the zygote process_2.

[0083] The SystemServer process is responsible for starting and managing the entire application framework layer. After the SystemServer process is created, it can mainly handle the following: (1) Initialize some system settings, virtual machine configuration, etc.; (2) Start the Binder thread pool so that Binder cross-process communication can be performed with other processes; (3) Create a system service manager (SystemServiceManager), which is used to create, start and manage the life cycle of system services; (4) Create the main thread Looper and enter a loop to wait for messages; (5) Start various system services, such as Activity Manager Service (AMS), Power Manager Service (Power Manager Service), Package Manager Service (PMS), Window Manager Service (WMS) and Input Manager Service (IMS).

[0084] The application framework layer may also include a killing module and a task stack recovery module. Among them, the killing module can be used to release the memory occupied in the application. In some embodiments of the present application, the killing module can register the application back-off event. In this way, the killing module can monitor whether the application is backed to the background. Once the killing module monitors that the application is backed to the background, the killing module can release the memory occupied in the application. It is understandable that the killing module can also monitor other imperceptible scenarios other than the application backing to the background, and the present application does not limit this. For example, the other imperceptible scenarios may also include: the electronic device does not perceive the user operation acting on the application for a period of time (for example, 5 minutes). The task stack recovery module can be used to restore the interface displayed by the application before being killed. It is understandable that the task stack recovery module can restore the interface displayed by the application before being killed to the background. That is, the process of the application restoring the corresponding interface may not be perceived by the user. In some embodiments of the present application, the task stack recovery module can determine whether to pull up and restore the corresponding interface of the killed application according to the priority decision. It is understandable that the priority refers to the priority of the killed application. In some embodiments of the present application, when the priority of the killed application is high, the task stack recovery module can re-start and restore the corresponding interface of the application. It is understandable that the relevant setting rules of the priority can refer to the relevant technical documents, which will not be described in detail here.

[0085] The application framework layer may also include a window manager, a content provider, a view system, a phone manager, a resource manager, a notification manager, etc. The specific meanings thereof may be referred to in the relevant technical documents and will not be described in detail here.

[0086] Runtime is responsible for the scheduling and management of the system. Runtime includes a core library and a virtual machine. Among them, the core library contains two parts: one part is the function function that the programming language (for example, the java language) needs to call, and the other part is the core library of the system. The application layer and the application framework layer run in the virtual machine. The virtual machine executes the programming files (for example, java files) of the application layer and the application framework layer as binary files. The virtual machine is used to perform object life cycle management, stack management, thread management, security and exception management, and garbage collection and other functions. It can be understood that the virtual machine can include virtual machine instances corresponding to several processes. For example, the virtual machine instance corresponding to zygote process_1 (referred to as zygote virtual machine_1 in this application), the virtual machine instance corresponding to zygote process_2 (referred to as zygote virtual machine_2 in this application) and the virtual machine instance corresponding to the application_1 process (referred to as application_1 virtual machine in this application), etc.

[0087] Applications in the Android system are written in Java and run in separate virtual machines. If each application needs to run and initialize a virtual machine separately when it starts, the system performance will be greatly reduced. Therefore, the Android system first creates a zygote virtual machine, and then hatches other virtual machine processes through it, and then shares the virtual machine memory and framework layer resources, which greatly improves the startup and running speed of the application. It can be understood that the zygote process will create a corresponding virtual machine instance, namely the zygote virtual machine, when it starts. Therefore, the application process and SystemServer process created in the form of fork can obtain an instance copy of a virtual machine internally. This means that the initial spatial layout of the virtual machine corresponding to other processes obtained by forking the zygote process inherits the spatial layout of the zygote virtual machine. In simple terms, it can also be understood that the electronic device copies the zygote virtual machine to obtain the virtual machine corresponding to other processes.

[0088] Specifically, see Figure 3 , zygote process_1 corresponds to zygote virtual machine_1, and zygote process_2 corresponds to zygote virtual machine_2. It can be understood that zygote virtual machine_1 is the virtual machine instance corresponding to zygote process_1, and zygote virtual machine_2 is the virtual machine instance corresponding to zygote process_2. zygote process_1 can fork application processes. It is worth noting that the application process created by zygote process_1 through fork can obtain a virtual machine instance copied from zygote virtual machine_1. Similarly, zygote process_2 can also fork application processes. It is worth noting that the application process created by zygote process_1 through fork can obtain a virtual machine instance copied from zygote virtual machine_1. It should also be noted that zygote process_2 can also fork to obtain the SystemServer process.

[0089] It is understandable that each application runs in its corresponding process (i.e., application process). Each application process corresponds to its own virtual machine instance. For ease of description, this application refers to the virtual machine instance corresponding to the application process as the application virtual machine. In simple terms, it can be understood that the application runs in a virtual machine (e.g., Dalvik / ART virtual machine). For example, application_1 runs in the application_1 process, and the virtual machine instance corresponding to the application_1 process is the application_1 virtual machine. It can also be simply understood that the virtual machine instance corresponding to application_1 is the application_1 virtual machine.

[0090] It can be understood that if the application process is obtained by forking zygote process_1, the corresponding application virtual machine inherits the spatial layout of zygote virtual machine_1. This means that the memory size of the memory space in the corresponding application virtual machine is the same as the memory size of the memory space in zygote virtual machine_1, and both are larger than the default memory size. Similarly, if the application process is obtained by forking zygote process_2, the corresponding application virtual machine inherits the spatial layout of zygote virtual machine_2. This means that the memory size of the memory space in the corresponding application virtual machine is the same as the memory size of the memory space in zygote virtual machine_2, and both are the default memory size.

[0091] It should be noted that the electronic device can determine whether the application process is obtained by zygote process_1 fork or zygote process_2 fork by judging whether the application meets the preset conditions. It is understandable that the relevant description of the preset conditions can be referred to below and will not be elaborated here.

[0092] It is understandable that the specific description of the application_1 virtual machine, the zygote virtual machine_1 and the zygote virtual machine_2 can be found below and will not be elaborated here.

[0093] It can be understood that the Dalvik virtual machine is the Android virtual machine used before Android 5.0, and the ART virtual machine is the Android virtual machine used throughout Android 5.0.

[0094] The runtime may also include a process control module. The process control module may be used to control the process. For example, a virtual machine instance corresponding to zygote process_1 (i.e., zygote virtual machine_1), a virtual machine instance corresponding to zygote process_2 (i.e., zygote virtual machine_2), and a virtual machine instance corresponding to the application (e.g., application_1 virtual machine) may be created.

[0095] The system library may include multiple functional modules, such as the surface manager, media libraries, 3D graphics processing library (e.g., OpenGL ES), and 2D graphics engine (e.g., SGL). The specific meanings and functions of these functional modules can be found in the relevant technical documents and will not be described in detail here.

[0096] The Hardware Abstraction Layer (HAL) is an interface layer between the operating system kernel and the upper-level software, and its purpose is to abstract the hardware. The hardware abstraction layer is an abstract interface driven by the device kernel, which is used to implement the application programming interface that provides access to the underlying device to the higher-level Java API framework. HAL can provide a standard interface to display the device hardware functions to the higher-level Java API framework. HAL contains multiple library modules, such as camera HAL, audio HAL, etc. Each library module implements an interface for a specific type of hardware component. When the system framework layer API requires access to the hardware of a portable device, the operating system will load the library module for the hardware component.

[0097] The kernel layer is the foundation of the Android system. The kernel layer is responsible for hardware drivers, network, power, system security, memory management and other functions. The kernel layer is an intermediate layer between hardware and software, and its role is to pass application requests to the hardware. The kernel layer can include camera drivers, display drivers, camera drivers, audio drivers and sensor drivers.

[0098] It should be noted that the application provides Figure 2 The software structure diagram of the electronic device shown is only an example and does not limit the specific module division in different layers of the Android system. For details, please refer to the introduction of the Android system software structure in conventional technology. In addition, the memory expansion method provided by this application can also be implemented based on other operating systems, and this application will not give examples one by one.

[0099] The following is a detailed introduction to virtual machines and their corresponding memory spaces.

[0100] See also Figure 4A , Figure 4A A schematic diagram of a virtual machine provided in an embodiment of the present application.

[0101] like Figure 4A As shown, a virtual machine may include a Runtime module and a Runtime data area. The Runtime module may be used to manage the memory space in the virtual machine (e.g., the Runtime data area). The Runtime data area may be used to store class file metadata, objects and arrays, as well as method parameter local variables, etc. The Runtime data area may include several Spaces, and the functions of the several Spaces may be different. For example, Figure 4A As shown, the runtime data area may include a Java memory space. The Java memory space refers to the memory space provided for Java objects. The memory corresponding to the Java memory space is the Java memory. It can be understood that Figure 4BAs shown, for the Android system, the Java memory space can be a region space (RegionSpace). Of course, for other operating systems, the Java memory space can also be other modules, and this application does not limit this. It can be understood that a number of 256 kilobyte (KB) regions (regions, which can also be understood as memory blocks) constitute a RegionSpace.

[0102] In some embodiments of the present application, the Runtime module can control several Spaces in the runtime data area to apply for virtual addresses, and establish a mapping relationship between the virtual addresses and the physical addresses. Specifically, in a possible implementation, several Spaces in the runtime data area can call the address management module to apply for virtual addresses. It can be understood that the address management module can be used to implement the mapping relationship between the virtual address and the physical address corresponding to the memory of the Java memory space (for example, RegionSpace). It should be noted that the virtual address involved in this application can be understood as a virtual memory address, and the physical address can be understood as a physical memory address (i.e., RAM memory address). Virtual memory refers to a piece of logical memory virtualized using disk space. Physical memory refers to the address space range that can be expressed by real physical memory (i.e., RAM memory).

[0103] It is understandable that the full name of RAM is Random Access Memory. RAM is also called main memory, which is the internal memory that directly exchanges data with the central processing unit (CPU). It can be read and written at any time (except when refreshed), and the speed is very fast. It is usually used as a temporary data storage medium for operating systems or other running programs. When RAM is working, information can be written (stored) or read (retrieved) from any specified address at any time.

[0104] It should be noted that the runtime data area may include not only the Java memory space (eg, RegionSpace) but also other Spaces. Figure 5 As shown, the runtime data area may include RegionSpace, LargeObjectSpace (large object space), ZygoteSpace (incubator space), ImageSpace (image file space) and jit code cache (just-in-time compiled code cache area), etc. The specific meanings and functions of these memory spaces can be referred to in relevant technical documents, which will not be elaborated here.

[0105] It can be understood that the runtime data area can also control other modules such as the stack and method area. The stack is a memory instruction area used to store basic data types, instruction codes, and constants. The method area is similar to the runtime data area. It is a memory area shared by each thread and can be used to store type information, constants, static variables, and code cache compiled by the just-in-time compiler that have been loaded by the virtual machine.

[0106] It is understandable that the memory allocated in the runtime data area is managed by the GC mechanism of the virtual machine. It is understandable that the relevant description of GC can refer to the above and related technical documents, and will not be repeated here.

[0107] It is understandable that the Runtime module may also include an execution engine, a native library interface, a native method library, and a Java thread, etc. This application does not limit the specific structure of the Runtime module.

[0108] It is understandable that the virtual machine mentioned in this application may be a Java Virtual Machine (JVM).

[0109] The following introduces zygote virtual machine_1, zygote virtual machine_2 and their hatching process.

[0110] Understandable, such as Fig. 6A As shown, the present application records the Runtime module in the zygote virtual machine_1 as Runtime module_1, the runtime data area in the zygote virtual machine_1 as Runtime data area_1, and the Java memory space in the zygote virtual machine_1 as RegionSpace_1. Similarly, Figure 6B As shown, this application records the Runtime module in zygote virtual machine_2 as Runtime module_2, the runtime data area in zygote virtual machine_2 as runtime data area_2, and the Java memory space in zygote virtual machine_2 as RegionSpace_2. According to the above, the memory size of RegionSpace_1 is the first value, the memory size of RegionSpace_2 is the second value, and the memory size of RegionSpace_1 is larger than the memory size of RegionSpace_2. The memory size of RegionSpace_2 is the default memory size corresponding to RegionSpace.

[0111] According to the above, the zygote process can create other processes through fork. The electronic device may include zygote process_1 and zygote process_2, and their corresponding virtual machine instances, namely zygote virtual machine_1 and zygote virtual machine_2. For ease of description, this application records the creation of other processes by zygote process_1 through fork as the first fork method, and the creation of other processes by zygote process_2 through fork as the second fork method.

[0112] It is understandable that during the fork process, other processes (for example, application processes) can obtain a copy of an instance of a virtual machine from the zygote process. Taking the application process as an example, if the electronic device uses the first fork method to obtain the application process, the application process can obtain the virtual machine instance copied from the virtual machine instance corresponding to the zygote process_1 (i.e., zygote virtual machine_1). In other words, the electronic device can obtain the application virtual machine by copying the zygote virtual machine_1. Similarly, if the electronic device uses the second fork method to obtain the application process, the application process can obtain the virtual machine instance copied from the virtual machine instance corresponding to the zygote process_2 (i.e., zygote virtual machine_2). In other words, the electronic device can obtain the application virtual machine by copying the zygote virtual machine_2.

[0113] For example, Figure 7 As shown, the electronic device can use the first fork method or the second fork method to obtain the process corresponding to application_1 (i.e., application_1 process), so that the virtual machine instance corresponding to the application_1 process (i.e., application_1 virtual machine) can be copied (or replicated) from the virtual machine instance corresponding to zygote process_1 (i.e., zygote virtual machine_1) or the virtual machine instance corresponding to zygote process_2 (i.e., zygote virtual machine_2). For ease of description, this application records the Runtime module in the application_1 virtual machine as Runtime module_3, the runtime data area in the application_1 virtual machine as runtime data area_3, and the Java memory space in the application_1 virtual machine as RegionSpace_3.

[0114] Specifically, if the electronic device adopts the first fork method to obtain the application_1 process, the application_1 virtual machine can be copied from the zygote virtual machine_1. In this case, the application_1 virtual machine is the same as the zygote virtual machine_1. That is to say, the Runtime module_3 is the same as the Runtime module_1, the runtime data area_3 is the same as the runtime data area_1, and the RegionSpace_3 is the same as the RegionSpace_1. It is worth noting that RegionSpace_3 is the same as RegionSpace_1, which can specifically include: the memory size of RegionSpace_3 is the same as the memory size of RegionSpace_1. This means that the memory size of RegionSpace_3 is the first value, which is larger than the default memory size. For example, the memory size of RegionSpace_3 can be 768MB. Similarly, if the electronic device adopts the second fork method to obtain the application_1 process, the application_1 virtual machine can be copied from the zygote virtual machine_2. In this case, the application_1 virtual machine is the same as the zygote virtual machine_2. That is to say, Runtime module_3 is the same as Runtime module_2, runtime data area_3 is the same as runtime data area_2, and RegionSpace_3 is the same as RegionSpace_2. It is worth noting that RegionSpace_3 is the same as RegionSpace_2, which can specifically include: the memory size of RegionSpace_3 is the same as the memory size of RegionSpace_2. This means that the memory size of RegionSpace_3 is the second value, that is, the default memory size. For example, the memory size of RegionSpace_3 can be 512MB.

[0115] According to the above, in some embodiments of the present application, if application_1 meets the preset condition, the electronic device can use the first fork method to obtain the application_1 process, and if application_1 does not meet the preset condition, the electronic device can use the second fork method to obtain the application_1 process. It can be understood that the relevant description of the preset condition can be referred to below and will not be described in detail here.

[0116] In some embodiments of the present application, after the application_1 virtual machine is created, application_1 can set the application_1 virtual machine according to actual needs (for example, change the memory space layout in the application_1 virtual machine), and the present application does not impose any restrictions on this.

[0117] It is understandable that zygote process_1 and zygote process_2 can also fork other processes (for example, processes corresponding to other applications such as text messages, music, and videos), and this application will not give examples one by one.

[0118] It is understandable that in the Android system, the Java memory space in the zygote virtual machine can be RegionSpace, however, in other operating systems, the Java memory space in the zygote virtual machine may not be RegionSpace, but other modules, and this application does not impose any restrictions on this.

[0119] A memory expansion method provided by an embodiment of the present application is introduced below.

[0120] See also Figure 8 , Figure 8 A flowchart of a memory expansion method provided in an embodiment of the present application. The method may include but is not limited to the following steps:

[0121] S101: The electronic device receives an instruction to start the electronic device.

[0122] The user can trigger the electronic device to start by long pressing the power button, etc. Correspondingly, the electronic device can receive the instruction to start the electronic device.

[0123] S102: In response to the instruction to start the electronic device received by the electronic device, the electronic device starts to create zygote virtual machine_1 and zygote virtual machine_2. In the process of creating zygote virtual machine_1, the electronic device creates a Java memory space based on the first value. In the process of creating zygote virtual machine_2, the electronic device creates a Java memory space based on the second value. The first value is greater than the second value.

[0124] In response to the instruction to start the electronic device received by the electronic device, the electronic device can create zygote process_1 and zygote process_2. It is understandable that after the electronic device creates the zygote process, it can create a virtual machine instance corresponding to the zygote process. In other words, after the electronic device creates zygote process_1, it can start to create zygote virtual machine_1. Similarly, after the electronic device creates zygote process_2, it can start to create zygote virtual machine_2. It is understandable that this application does not limit the order in which the electronic device creates zygote virtual machine_1 and zygote virtual machine_2.

[0125] It can be understood that the memory size of the Java memory space in the created zygote virtual machine_1 is a first value, and the memory size of the Java memory space in the created zygote virtual machine_2 is a second value, wherein the first value is greater than the second value.

[0126] It is understandable that the first numerical value can be set according to actual needs, and the present application does not limit its specific value. For example, the first numerical value can be 768. The unit of the Java memory corresponding to the first numerical value can be MB. In this case, the memory of the Java memory space created based on the first numerical value is 768MB. In some embodiments of the present application, the first numerical value is not greater than the preset memory threshold. It is understandable that the preset memory threshold can be set according to actual needs, and the present application does not limit this. For example, the preset memory threshold can be 768. For another example, the preset memory threshold can be 750.

[0127] According to the above, the second value is the default memory size of the Java memory space. In some embodiments of the present application, the second value is 512. The unit of the Java memory corresponding to the second value may be MB. In this case, the memory size of the Java memory space created based on the second value is 512MB.

[0128] S103: The electronic device receives an instruction to cold-start application_1.

[0129] The user can cold start application_1 by touch (e.g., click, slide, etc.), sound, etc. For example, the user can click the application icon corresponding to application_1 (hereinafter referred to as application_1 icon), and accordingly, the electronic device can receive an instruction to cold start application_1.

[0130] It is understandable that when an application is started, there is no process of the application in the background of the electronic device. At this time, the system will recreate a new process and assign it to the application. This startup method is called a cold start (the application process does not exist in the background).

[0131] S104: In response to the instruction of cold starting application_1 received by the electronic device, if application_1 meets the preset condition, the electronic device copies the application_1 virtual machine based on zygote virtual machine_1. The memory size of the Java memory space in the application_1 virtual machine copied by zygote virtual machine_1 is a first value.

[0132] In response to the instruction of cold-starting application_1 received by the electronic device, the electronic device can determine whether application_1 meets the preset conditions. If application_1 meets the preset conditions, the electronic device can obtain the application_1 process based on the zygote process_1fork, and correspondingly, obtain the application_1 virtual machine based on the zygote virtual machine_1 copy. In this case, the initial memory space layout of the application_1 virtual machine is consistent with the memory space layout in the created zygote virtual machine_1, that is, the initial memory size of the Java memory space in the application_1 virtual machine is the first value.

[0133] In some embodiments of the present application, application_1 satisfies a preset condition, which may specifically include: application_1 is an application in a preset list.

[0134] In some embodiments of the present application, application_1 satisfies a preset condition, which may specifically include: the category of application_1 is a preset category. Exemplarily, the applications of the preset category may include any one or more of the following: social applications, game applications, video applications, and news applications. It is understandable that the applications of the preset category may also include other applications, and the present application does not specifically limit this.

[0135] It is understandable that the preset list / preset category can be set according to actual needs, and this application does not impose any restrictions on this.

[0136] In some embodiments of the present application, the preset list can be set based on the historical memory usage of each application. For example, the preset list may include: for the memory usage after a cold start, the number of applications whose memory usage exceeds b% reaches c%*a. It is understandable that the memory usage rate can be the percentage of the occupied Java memory to the maximum available Java memory. It is understandable that a, b and c can be set according to actual needs, and the present application does not limit this. For example, a can be 5, b can be 90, and c can be 80. Similarly, the preset categories can be set based on the historical memory usage of applications in each category. For details, please refer to the above method of setting the preset list according to the historical memory usage of each application.

[0137] In some embodiments of the present application, the preset list can be set based on the historical memory leakage of each application. For example, the preset list may include: for memory leakage after a cold start, the number of memory leaks reaches c%*a. For another example, any application in the preset list meets the following conditions: during the operation after X cold starts, the number of memory leaks reaches Y. It can be understood that X and Y are positive integers, and Y is not greater than X. Similarly, the preset categories can be set based on the historical memory leakage of applications in each category. For details, please refer to the above method of setting the preset list according to the historical memory leakage of each application.

[0138] In some embodiments of the present application, application_1 satisfies a preset condition, which may specifically include: in the historical records of Java memory usage of application_1 after cold starting application_1 S times, the number of first-category historical records is greater than the number of first-category historical records. In one possible implementation, the first-category historical records may include: historical records of occupied memory of Java memory space in the application_1 virtual machine being greater than threshold_1. In another possible implementation, the first-category historical records may include: historical records of ratio of occupied memory of Java memory space in the application_1 virtual machine to maximum available Java memory (e.g., the default memory size of Java memory space) being greater than ratio_1.

[0139] It is understood that S is a positive integer. S can be set according to actual needs, and this application does not limit this. For example, S can be 10.

[0140] It is understandable that the threshold_1 and the ratio_1 can be set according to actual needs, and the present application does not limit this. In some embodiments of the present application, the threshold_1 can be b% of the second value. For example, the threshold_1 can be 400. In some embodiments of the present application, the ratio_1 can be 0.8.

[0141] It is understood that the first historical record number can be set according to actual needs, and the present application does not limit this. For example, the first historical record number can be 5 times. In some embodiments of the present application, the ratio of the first historical record number to S can be greater than ratio_2. It is understood that ratio_2 can be set according to actual needs, and the present application does not limit this. For example, ratio_2 can be 0.8. For another example, ratio_2 can be 0.9.

[0142] In some embodiments of the present application, application_1 satisfies a preset condition, which may specifically include: in the historical records of Java memory usage of application_1 after cold starting application_1 S times, the ratio of the number of first-category historical records to S is greater than ratio_2.

[0143] In some embodiments of the present application, application_1 satisfies a preset condition, which may specifically include: for the Java memory occupancy after cold starting application_1 a times, the number of times that the Java memory occupancy rate of application_1 exceeds b% is greater than c%*a.

[0144] In some embodiments of the present application, application_1 satisfies a preset condition, which may specifically include: for memory leakage after cold starting application_1 a times, the number of memory leakages of application_1 reaches c%*a.

[0145] In some embodiments of the present application, the electronic device determines whether application_1 meets the preset condition, which may specifically include: the unoccupied memory of the operating system of the electronic device is greater than threshold_2. It is understandable that threshold_2 can be set according to actual needs, and the present application does not limit this. For example, threshold_2 can be 6 gigabytes (GB).

[0146] In some embodiments of the present application, the electronic device determines whether application_1 meets the preset condition, which may specifically include: the ratio of the unoccupied memory of the operating system of the electronic device to the total memory of the operating system is greater than threshold_3. It is understood that the total memory of the operating system is not greater than the RAM memory of the electronic device. It is understood that threshold_3 can be set according to actual needs, and the present application does not limit this. For example, threshold_3 can be 0.2.

[0147] Of course, the electronic device may also determine whether application_1 meets the preset conditions in other ways, and this application does not limit this.

[0148] It is understandable that when application_1 meets the preset conditions, application_1 will not actively apply for the virtual address segment applied for by the electronic device when creating the zygote virtual machine_1, thereby avoiding conflicts caused by partial or complete overlap between the virtual address segment actively applied for by application_1 and the virtual address segment applied for when creating the zygote virtual machine_1, affecting system stability.

[0149] S105: In response to the instruction of cold starting application_1 received by the electronic device, if application_1 does not meet the preset condition, the electronic device copies the application_2 virtual machine based on zygote virtual machine_2. The memory size of the Java memory space in the application_1 virtual machine copied by zygote virtual machine_2 is a second value.

[0150] In response to the instruction of cold-starting application_1 received by the electronic device, the electronic device can determine whether application_1 meets the preset conditions. If application_1 does not meet the preset conditions, the electronic device can obtain the application_1 process based on the zygote process_2fork, and correspondingly, obtain the application_1 virtual machine based on the zygote virtual machine_2 copy. In this case, the initial memory space layout of the application_1 virtual machine is consistent with the memory space layout in the created zygote virtual machine_2, that is, the initial memory size of the Java memory space in the application_1 virtual machine is the second value.

[0151] The following takes the Java memory space as RegionSpace as an example, combined with Figure 2 The software structure of the electronic device shown further introduces the memory expansion method provided by the present application (such as Fig. 9 shown).

[0152] See also Fig. 9 , Fig. 9 A flowchart of another memory expansion method provided in an embodiment of the present application. The method may include but is not limited to the following steps:

[0153] S201: The electronic device receives an instruction to start the electronic device.

[0154] S202: In response to the instruction to start the electronic device received by the electronic device, the electronic device creates zygote process_1 and zygote process_2, and starts to create zygote virtual machine_1 and zygote virtual machine_2. The memory size of RegionSpace_1 in the created zygote virtual machine_1 is the first value. The memory size of RegionSpace_2 in the created zygote virtual machine_2 is the second value.

[0155] In some embodiments of the present application, the Java memory space may be a RegionSpace. In this case, the second value refers to the default memory size of the RegionSpace.

[0156] It can be understood that the specific implementation of step S201-step S202 can refer to step S101-step S102, and this application will not repeat them here.

[0157] S203: The electronic device incubates the SystemServer process based on the zygote process_2.

[0158] After the electronic device creates zygote process_2, the SystemServer process can be forked from zygote process_2. The specific implementation method can be found below and will not be described in detail here.

[0159] S204: The electronic device receives an instruction to cold-start application_1 by initiating a process.

[0160] The user can cold start application_1 by touch (for example, click, slide, etc.), sound, etc. Correspondingly, the electronic device can receive the instruction of cold starting application_1 by initiating a process. The initiating process refers to the process that triggers the zygote process to create a new process.

[0161] In some embodiments of the present application, the initiating process may be a desktop process (i.e., a Launcher process). During the startup process, the Launcher will request to return the application information that has been installed in the system, and encapsulate this information into a list of shortcut icons displayed on the system screen, so that the user can start the corresponding application by clicking on these shortcut icons. In layman's terms, the Launcher can be understood as the desktop of the Android system.

[0162] Of course, the initiating process may also be other processes, and this application does not impose any specific restrictions on this. For example, the initiating process may also be a process corresponding to other applications, a system user interface (systemUI) process, a negative one screen process, and the like.

[0163] S205: The electronic device notifies the SystemServer process to cold-start application_1 by initiating a process.

[0164] After the electronic device receives the instruction to cold-start Application_1 through the initiating process, it can also notify the SystemServer process in the electronic device to cold-start Application_1 through the initiating process. It is understandable that the electronic device can notify the SystemServer process to cold-start Application_1 by sending a corresponding message to the SystemServer process through the initiating process.

[0165] S206: The electronic device determines whether Application_1 meets preset conditions through the SystemServer process.

[0166] After the electronic device notifies the SystemServer process to cold-start Application_1 through the initiation process, it can determine whether Application_1 meets the preset conditions through the SystemServer process. If Application_1 meets the preset conditions, the electronic device can execute steps S207-S208; if Application_1 does not meet the preset conditions, the electronic device can execute steps S209-S210.

[0167] It is understandable that the relevant description of the preset conditions can be found above, and this application will not go into details here.

[0168] S207: If application_1 meets the preset conditions, the electronic device instructs zygote process_1 to incubate application_1 process through the SystemServer process.

[0169] If the electronic device determines through the SystemServer process that application_1 meets the preset conditions, the electronic device can instruct zygote process_1 to fork application_1 process through the SystemServer process. The specific implementation method can be referred to below and will not be elaborated here.

[0170] S208: During the process of incubating the application_1 process by the zygote process_1, the electronic device obtains the application_1 virtual machine based on the copy of the zygote virtual machine_1.

[0171] When the electronic device obtains the application_1 process through zygote process_1fork, it can also create a virtual machine instance corresponding to the application_1 process, that is, obtain the application_1 virtual machine based on the copy of zygote virtual machine_1. In this case, the memory size of RegionSpace (i.e., RegionSpace_3) in the application_1 virtual machine is the first value.

[0172] S209: If application_1 does not meet the preset conditions, the electronic device instructs zygote process_2 to incubate application_1 process through the SystemServer process.

[0173] If the electronic device determines through the SystemServer process that application_1 does not meet the preset conditions, the electronic device can instruct zygote process_2 to fork the application_1 process through the SystemServer process. The specific implementation method can be referred to below and will not be elaborated here.

[0174] S210: During the process of incubating the application_1 process by the zygote process_2, the electronic device obtains the application_1 virtual machine based on the copy of the zygote virtual machine_2.

[0175] When the electronic device obtains the application_1 process through zygote process_2fork, it can also create a virtual machine instance corresponding to the application_1 process, that is, obtain the application_1 virtual machine based on the copy of zygote virtual machine_2. In this case, the memory size of RegionSpace (i.e., RegionSpace_3) in the application_1 virtual machine is the second value.

[0176] A specific implementation of the above embodiment is introduced below from two aspects.

[0177] A first aspect: the electronic device creates zygote process_1 and zygote process_2, and corresponding zygote virtual machines_1 and zygote virtual machines_2.

[0178] 1. The electronic device creates zygote process_1 and zygote process_2

[0179] See also Fig.10 , Fig.10 A flowchart of creating a zygote process and a SystemServer process is provided in an embodiment of the present application. Fig.10The content shown can be understood as a specific implementation of the above steps S201 to S203. It can be understood that the process of creating the zygote process and the SystemServer process may include but is not limited to the following steps:

[0180] S301: The electronic device detects a user operation on a power button, and in response to the user operation, the electronic device starts a bootloader.

[0181] When the electronic device is in a powered-off state, the user can press the power button of the electronic device to turn it on. At this time, the electronic device will first run the bootloader program (bootloader) solidified in the read-only memory (ROM).

[0182] It can be understood that the bootloader is a boot program before starting the Android system, which mainly checks the random access memory (RAM), initializes parameters, and other functions. The electronic device can initialize the hardware (e.g., memory, central processing unit, etc.) in the electronic device through the bootloader and load it into the RAM, thereby establishing a memory space mapping and preparing for loading the Linux kernel.

[0183] S302: The electronic device loads and starts the Linux kernel.

[0184] After the electronic device starts the bootloader and is ready to load the Linux kernel, the electronic device can load and start the Linux kernel, that is, the Linux kernel in the electronic device will perform initialization of the entire system and load the root file system after completion.

[0185] S303: The electronic device starts the init process and parses the init.rc file.

[0186] After the Linux kernel in the electronic device is loaded, it will be called from the kernel layer to the user space layer, and the init process will be started first. The init process is the first process of the system. During the startup of the init process, the electronic device will parse the most important init.rc file. According to the description of the init.rc file, the system will create files and directories, grant permissions, initialize properties, and start important daemons of the Android system.

[0187] S304: The electronic device creates two zygote processes and a SystemServer process, wherein a Java memory size corresponding to one zygote process created by the electronic device is a first value, and a Java memory size corresponding to another zygote process is a second value.

[0188] During the parsing of the init.rc file, the electronic device will create two zygote processes with different Java memories, namely zygote process_1 and zygote process_2. Among them, the size of the Java memory corresponding to zygote process_1 is the first value, and the size of the Java memory corresponding to zygote process_2 is the second value. After the electronic device creates zygote process_2, it can create a SystemServer process based on zygote process_2, that is, obtain the SystemServer process through zygote process_2fork. After the startup of zygote process_1 and zygote process_2 is completed, they will also become daemon processes, responsible for responding to requests to start Android application packages (Android application package, APK).

[0189] Combine the following Fig.11 Starting from the init process started by the electronic device, the process of creating zygote process_1 and zygote process_2 is specifically introduced.

[0190] like Fig.11 As shown, when the electronic device starts the init process in the user space, it can execute the main function, that is, the main() function, by parsing the main function source file (main.cpp), thereby performing the duties of the init process. It can be understood that the extension .cpp file is a C++ source code file, such as main.cpp is a file that implements the main() function of a C++ program. The main() function is the entry point of the application. Its main functions are to create an application, create a window, display a window, run the application, and start the message loop and event processing of the application. In other words, the main() function that can be implemented by main.cpp is the entry point of the init process.

[0191] The process of an electronic device parsing main.cpp and executing the main() function may include: the first stage (FirstStageMain stage), the relevant settings of the Security Enhanced Linux (SELinux, hereinafter referred to as selinux) system (SetupSelinux stage), and the second stage (SecondStageMain stage). The main tasks of the FirstStageMain stage include creating a file system directory and mounting the relevant file system, as well as shielding the standard input and output / initializing the kernel log (log) system. The FirstStageMain stage is mainly implemented by parsing the first stage main function source file (first_stage_main.cpp). The main task of the SetupSelinux stage is to complete the relevant settings of selinux. The SetupSelinux stage is mainly implemented by parsing the security enhanced system source file (selinux.cpp). The main tasks of the SecondStageMain phase include: creating process session keys and initializing the attribute system, performing the second phase of selinux and restoring some file security contexts, creating a new extensible input / output (IO) event processing mechanism (epoll) and initializing the child process termination signal processing function, starting the server with matching attributes, parsing files such as init.rc, creating action statements (action) and service statements (service) in rc files, and starting other processes (for example, zygote process_1 and zygote process_2). The SecondStageMain phase is mainly implemented by parsing the initial source file (init.cpp), the activity management source file (action_manager.cpp) and the application main function source file (app_main.cpp).

[0192] Specifically, Fig.11As shown, after the electronic device parses main.cpp and starts to execute the main() function, it can enter the FirstStageMain stage. In the FirstStageMain stage, the electronic device can execute the first stage main function, that is, the FirstStageMain() function, by parsing first_stage_main.cpp. After the electronic device executes the FirstStageMain() function and completes the tasks of the FirstStageMain stage, it can call the main() function again to enter the SetupSelinux stage. In the SetupSelinux stage, the electronic device can execute the setup selinux function, that is, the SetupSelinux() function (also known as the SetupSelinux method), by parsing selinux.cpp, and specifically can load selinux rules, set selinux logs, and complete selinux related work. After the electronic device executes the SetupSelinux function and completes the tasks of the SetupSelinux stage, it can call the main() function again to enter the SecondStageMain stage. In the SecondStageMain stage, the electronic device can execute the second stage main function, that is, the SecondStageMain() function, by parsing source files such as init.cpp, action_manager.cpp, and app_main.cpp. After starting to execute the SecondStageMain() function, the electronic device can load and parse the init.rc file through init.cpp, obtain the action manager (ActionManager) instance through action_manager.cpp, add the action and trigger (Trigger) to the corresponding queue of ActionManager, loop read the commands and execute the commands in init.rc until the commands in the queue are executed, and create zygote process_1 and zygote process_2 through app_main.cpp.

[0193] It can be understood that the FirstStageMain() function is mainly used to initialize the hardware and drivers of the boot loader, including the following three items: (1) Load the first stage boot image of the Android system (for example, boot.img) into the memory; (2) Set the initial memory layout and startup parameters; (3) Jump to the second stage main function SecondStageMain() function to continue the second stage. The SecondStageMain() function is mainly used to initialize the global environment and system properties, including the following four items: (1) Load and start zygote process_1 and zygote process_2, which serve as incubators for all applications in the Android system; (2) Start the SystemServer process, which is responsible for managing system services; (3) Start and load applications and system components; (4) Finally enter the system's main event loop, waiting for user interaction and processing system events.

[0194] It can be understood that the electronic device can execute the load script LoadBootScripts() function by parsing init.cpp to load and parse the init.rc file (i.e. Fig.11 Script function shown). It can be understood that the init.rc file contains the binary executable file corresponding to the zygote process, as well as relevant configuration parameters such as process name, priority, address, etc. The relevant configuration parameters include relevant configuration parameters corresponding to zygote process_1 and zygote process_2. In this way, the electronic device can create zygote process_1 based on the binary executable file corresponding to the zygote process and the relevant configuration parameters corresponding to zygote process_1 in the process of parsing the init.rc file, and create zygote process_2 based on the binary executable file corresponding to the zygote process and the relevant configuration parameters corresponding to zygote process_2. The electronic device can also execute the trigger queue event function, i.e., the QueueEventTrigger() function, by parsing action_manager.cpp to add the Trigger to the corresponding queue of the ActionManager. The electronic device can also execute the ExcuteOneCmmand() function by parsing action_manager.cpp, i.e., execute a command function to loop read commands and execute the commands in init.rc until the commands in the queue are executed. The electronic device may also parse app_main.cpp and execute the main() function implemented by app_main.cpp to create zygote process_1 and zygote process_2.

[0195] 2. The electronic device creates zygote virtual machine_1 and zygote virtual machine_2

[0196] The following takes any one of the zygote processes, zygote process_1 and zygote process_2, as an example to briefly introduce the process of creating the zygote process and its corresponding virtual machine.

[0197] See also Fig.12 , Fig.12 A flowchart of creating a zygote process and its corresponding virtual machine is provided in an embodiment of the present application. The process of creating a zygote process and its corresponding virtual machine may include but is not limited to the following steps:

[0198] S401: The electronic device creates a zygote process.

[0199] The electronic device may create a zygote process according to the relevant configuration parameters obtained by parsing the init.rc file. It is understandable that the zygote process created by the electronic device mentioned in step S401 may be zygote process_1 or zygote process_2.

[0200] S402: The electronic device determines whether the currently created zygote process is a zygote process that requires memory expansion.

[0201] After the electronic device creates a zygote process, it can determine whether the zygote process is a zygote process that requires memory expansion. If the zygote process currently created by the electronic device is a zygote process that requires memory expansion, the currently created zygote process is zygote process_1. In this case, the electronic device can continue to execute step S403. However, if the zygote process currently created by the electronic device is not a zygote process that requires memory expansion, the currently created zygote process is zygote process_2. In this case, the electronic device can continue to execute steps S404 and S405.

[0202] In some embodiments of the present application, the electronic device determines whether the currently created zygote process is a zygote process that requires memory expansion, which may specifically include: the electronic device may determine whether the name of the currently created zygote process is the same as the preset name (i.e., the name of the zygote process that requires memory expansion). If the name of the currently created zygote process is the same as the name of the zygote process that requires memory expansion, the electronic device may determine that the currently created zygote process is a zygote process that requires memory expansion, however, if the name of the currently created zygote process is not the same as the name of the zygote process that requires memory expansion, the electronic device may determine that the currently created zygote process is not a zygote process that requires memory expansion.

[0203] Exemplarily, the name of the zygote process that does not require memory expansion may be zygote, and the name of the zygote process that requires memory expansion may be zygote_heap_expansion. If the name of the currently created zygote process recorded in the init.rc file is zygote, the electronic device may determine that the currently created zygote process is not a zygote process that requires memory expansion, however, if the name of the currently created zygote process recorded in the init.rc file is zygote_heap_expansion, the electronic device may determine that the currently created zygote process is a zygote process that requires memory expansion.

[0204] In some embodiments of the present application, the electronic device can also determine whether the currently created zygote process is a zygote process that needs to expand memory based on the identifier of the currently created zygote process and the identifier of the zygote process that needs to expand memory. Specifically, the electronic device can determine whether the identifier of the currently created zygote process is the same as the preset identifier (i.e., the identifier of the zygote process that needs to expand memory). If the identifier of the currently created zygote process is the same as the identifier of the zygote process that needs to expand memory, the electronic device can determine that the currently created zygote process is a zygote process that needs to expand memory. However, if the identifier of the currently created zygote process is not the same as the identifier of the zygote process that needs to expand memory, the electronic device can determine that the currently created zygote process is not a zygote process that needs to expand memory.

[0205] It is understandable that the identifier of the zygote process can be represented by words, numbers, characters, etc., and this application does not impose specific restrictions on this. For example, the identifier of the zygote process that needs to expand the memory can be zygote_1, and the identifier of the zygote process that does not need to expand the memory can be zygote_2. For another example, the identifier of the zygote process that needs to expand the memory can be 1, and the identifier of the zygote process that does not need to expand the memory can be 2.

[0206] Of course, the electronic device can also determine whether the currently created zygote process is a zygote process that requires memory expansion in other ways, and this application does not impose any restrictions on this.

[0207] S403: The electronic device creates a virtual machine corresponding to the currently created zygote process based on the first value.

[0208] If the electronic device determines that the currently created zygote process is a zygote process that needs to expand memory, that is, the currently created zygote process is zygote process_1, then the electronic device can create a virtual machine corresponding to the currently created zygote process based on the first value, that is, zygote virtual machine_1. It can be understood that the specific process of the electronic device creating zygote virtual machine_1 based on the first value can be referred to below and will not be described in detail here.

[0209] S404: The electronic device creates a virtual machine corresponding to the currently created zygote process based on the second value.

[0210] If the electronic device determines that the currently created zygote process is not a zygote process that requires memory expansion, that is, the currently created zygote process is zygote process_2, then the electronic device can create a virtual machine corresponding to the currently created zygote process based on the second value, that is, zygote virtual machine_2. It can be understood that the specific process of the electronic device creating zygote virtual machine_2 based on the second value can be referred to below, and will not be described in detail here.

[0211] S405: The electronic device creates a SystemServer process by forking based on the currently created zygote process.

[0212] After the electronic device determines that the currently created zygote process is not a zygote process that requires memory expansion, that is, the currently created zygote process is zygote process_2, and creates zygote virtual machine_2 based on the second value, the electronic device can fork the SystemServer process from zygote process_2.

[0213] It is worth noting that the electronic device can create a process that requires memory expansion (i.e., zygote process_1) and a zygote process that does not require memory expansion (i.e., zygote process_2) according to the different configuration parameters obtained by parsing. This means that in this application, the electronic device can execute twice as shown in Fig.12 It is understood that the present application does not impose any specific restrictions on the order in which the electronic device creates zygote process_1 and zygote process_2.

[0214] The following takes the creation of zygote process_2 as an example to specifically introduce the process of an electronic device creating zygote process_1, zygote process_2, and their corresponding virtual machines.

[0215] See also Fig.13 , Fig.13 A flowchart of creating two zygote processes and their corresponding virtual machines is provided in an embodiment of the present application. The process of creating two zygote processes and their corresponding virtual machines may include but is not limited to the following steps:

[0216] S501: The electronic device creates a zygote process_2.

[0217] It is understandable that the init.rc file may first record the command for creating zygote process_2 and the relevant setting parameters corresponding to zygote process_2. In this way, when the electronic device parses the init.rc file, it may first execute the command for creating zygote process_2, that is, create zygote process_2 based on the relevant setting parameters corresponding to zygote process_2.

[0218] Specifically, in the process of parsing the init.rc file, the electronic device can parse the rc file about zygote, that is, the init.zygote.rc file, and then the electronic device can first create the zygote process_2 according to the parameters in init.zygote.rc, and create the Android runtime environment object (that is, AppRuntime), and call its start method, that is, the AppRuntime.start() method. It can be understood that AppRuntime is a class defined in app_process.cpp, inherited from the system's AndroidRuntime, and is mainly used to create and initialize a virtual machine.

[0219] S502: The electronic device creates a zygote virtual machine_2. In the process of creating the zygote virtual machine_2, the electronic device determines that the name of the zygote process_2 is not a preset name, and then the electronic device creates a Java memory space of the zygote virtual machine_2 based on the second value.

[0220] After the electronic device creates zygote process_2, it can create its corresponding virtual machine, namely zygote virtual machine_2. In the process of creating zygote virtual machine_2, the electronic device can first determine that the name of zygote process_2 is not a preset name (for example, zygote_heap_expansion), then the electronic device can determine that zygote process_2 does not need to expand memory, and can create the Java memory space of zygote virtual machine_2 based on the second value.

[0221] It is understandable that the electronic device may include two sets of zygote virtual machine startup parameters, and the two sets of zygote virtual machine startup parameters correspond to zygote virtual machine_1 and zygote virtual machine_2 respectively.

[0222] Specifically, after the electronic device creates the zygote process_2 and calls the AppRuntime.start() method, the electronic device can execute the startVM() method. When the electronic device executes the startVM() method, it can parse the startup parameters of the zygote virtual machine_2 and call JNI_CreateJavaVM to create the zygote virtual machine_2. The startup parameters of the zygote virtual machine_2 may include the memory setting parameters of the RegionSpace (i.e., RegionSpace_2) in the zygote virtual machine_2. It can be understood that the memory size represented by the memory setting parameter is the second value. In this way, the memory size of RegionSpace_2 in the zygote virtual machine_2 created by the electronic device calling JNI_CreateJavaVM is the second value.

[0223] It is understandable that after the electronic device calls JNI_CreateJavaVM, the Runtime object (i.e., Runtime module) can be created by the Runtime::create method. The Runtime object is responsible for providing the runtime environment of the virtual machine. Then, the electronic device can initialize the virtual machine by the Runtime::init method, that is, create a virtual machine based on the virtual machine startup parameters. In the process of initializing the virtual machine, the electronic device can create a heap object by the new gc::heap() method, that is, create a runtime data area. In some embodiments of the present application, after the electronic device creates the heap object by the new gc::heap() method, it can be determined whether the name of the zygote process is a preset name. The electronic device can use the corresponding memory setting parameters to set the memory size of the Java memory space (e.g., RegionSpace) in the virtual machine based on the judgment result. According to step S502, after the electronic device creates the heap object by the new gc::heap() method, it can be determined that the name of the zygote process_2 is not a preset name. The electronic device can use the default memory size (e.g., 512MB) to set the memory size of RegionSpace_2 in the zygote virtual machine_2.

[0224] It can be understood that after the electronic device creates the zygote process_2 and calls the AppRuntime.start() method, it can also execute the startReg() method to register the JNI method, and call the ZygoteInit.main() method through the JNI method. After the electronic device calls the ZygoteInit.main() method, it can also execute new ZygoteServer to create a socket channel for the zygote process_2. As a communication server, the zygote process_2 can be used to respond to client requests. In addition, after the electronic device calls the ZygoteInit.main() method, it can also execute the preload() method to preload common classes, color resources (drawable and color resources), graphics processing libraries (openGL), shared libraries, and web views (WebView) to improve the efficiency of application startup.

[0225] S503: The electronic device determines that the name of the zygote process_2 is not a preset name, and then the electronic device hatches the SystemServer process based on the zygote process_2.

[0226] After the electronic device creates zygote process_2 and zygote virtual machine_1, it can be determined that the name of zygote process_2 is not the preset name. In this case, the electronic device can call the startSystemServer() method to create a SystemServer process by forking, that is, to obtain the SystemServer process based on zygote process_2fork.

[0227] S504: The electronic device places the zygote process_2 in a loop to wait for receiving a request to create a new process.

[0228] After the electronic device creates the SystemServer process, it can execute the runSelectLoop() method to make the zygote process_2 enter a loop, and the zygote process_2 can wait to receive a request to create a new process. When the zygote process_2 receives the request to create a new process, the zygote process_2 can immediately wake up and perform the corresponding work.

[0229] S505: The electronic device creates a zygote process_1.

[0230] It can be understood that after the command for creating zygote process_2 recorded in the init.rc file, the command for creating zygote process_1 and the relevant setting parameters corresponding to zygote process_1 can also be recorded. In this way, when the electronic device parses the init.rc file, it can first execute the command for creating zygote process_2 (as shown in step S501), and then execute the command for creating zygote process_1, that is, create zygote process_1 based on the relevant setting parameters corresponding to zygote process_1.

[0231] Specifically, in the process of parsing the init.rc file, the electronic device can parse the init.zygote.rc file, and then the electronic device can first create the zygote process_2 according to the parameters in init.zygote.rc, execute the steps shown in the above steps S501-step S504, and then create the zygote process_1 according to the parameters in init.zygote.rc. Similar to step S501, after the electronic device creates the zygote process_1, it can create AppRuntime and call its start method, that is, AppRuntime.start() method.

[0232] S506: The electronic device creates a zygote virtual machine_1. In the process of creating the zygote virtual machine_1, the electronic device determines that the name of the zygote process_1 is a preset name, and then the electronic device creates a Java memory space of the zygote virtual machine_1 based on the first value.

[0233] After the electronic device creates the zygote process_1, it can create its corresponding virtual machine, namely, the zygote virtual machine_1. In the process of creating the zygote virtual machine_1, the electronic device can first determine that the name of the zygote process_1 is a preset name (for example, zygote_heap_expansion), then the electronic device can determine that the zygote process_1 needs to expand the memory, and create the Java memory space of the zygote virtual machine_1 based on the first value. It can be understood that according to the above, the first value is greater than the second value.

[0234] Specifically, after the electronic device creates the zygote process_1 and calls the AppRuntime.start() method, the electronic device can execute the startVM() method. When the electronic device executes the startVM() method, it can parse the startup parameters of the zygote virtual machine_1 and call JNI_CreateJavaVM to create the zygote virtual machine_1. The startup parameters of the zygote virtual machine_1 may include the memory setting parameters of the RegionSpace (i.e., RegionSpace_1) in the zygote virtual machine_1. It can be understood that the memory size represented by the memory setting parameters may be larger than the default memory size. In this way, the memory size of RegionSpace_1 in the zygote virtual machine_1 created by the electronic device calling JNI_CreateJavaVM will be larger than the default memory size.

[0235] Similar to step S502, after the electronic device calls JNI_CreateJavaVM, it can create a Runtime object (i.e., Runtime module) through the Runtime::create method. The Runtime object is responsible for providing the runtime environment of the virtual machine. Then, the electronic device can initialize the virtual machine through the Runtime::init method, that is, create a virtual machine based on the virtual machine startup parameters. In the process of initializing the virtual machine, the electronic device can create a heap object through the new gc::heap() method, that is, create a runtime data area. After the electronic device creates a heap object through the new gc::heap() method, it can be determined that the name of the zygote process_1 is a preset name. The electronic device can use a first numerical value (for example, 768) to set the memory size of RegionSpace_1 in the zygote virtual machine_1.

[0236] Similar to step S502, after the electronic device creates the zygote process_1 and calls the AppRuntime.start() method, it can also execute the startReg() method to register the JNI method, and call the ZygoteInit.main() method through the JNI method. After the electronic device calls the ZygoteInit.main() method, it can also execute new ZygoteServer to create a socket channel for the zygote process_1. As a communication server, the zygote process_1 can be used to respond to client requests. It can be understood that the related operations after the electronic device calls the ZygoteInit.main() method can refer to step S502, and this application will not repeat them here.

[0237] S507: The electronic device determines that the name of zygote process_1 is a preset name. Then, the electronic device does not need to hatch the SystemServer process based on the currently created zygote process, but puts zygote process_1 in a loop to wait for receiving a request to create a new process.

[0238] It is understandable that the electronic device can determine that the name of zygote process_1 is a preset name. In this case, the electronic device does not need to call the startSystemServer() method to obtain the SystemServer process based on zygote process_1, but executes the runSelectLoop() method to make zygote process_1 enter a loop, and zygote process_1 can wait to receive a request to create a new process. When zygote process_1 receives a request to create a new process, zygote process_1 can wake up immediately and perform corresponding work.

[0239] It should be noted that in some embodiments of the present application, as shown in step S506 and step S507, in the process of creating a virtual machine corresponding to the zygote process, the electronic device needs to determine whether the name of the zygote process is a preset name, and after completing the creation of the virtual machine corresponding to the zygote process, the electronic device needs to determine again whether the name of the zygote process is the preset name. If the name of the zygote process is the preset name, the electronic device does not need to call the startSystemServer() method. If the name of the zygote process is not the preset name, the electronic device needs to call the startSystemServer() method. In some other embodiments of the present application, such as Fig.12As shown, the electronic device only needs to perform the above-mentioned step of determining whether the name of the zygote process is a preset name once. After obtaining the judgment result, the electronic device can create a virtual machine based on the corresponding virtual machine startup parameters, and determine whether it is necessary to fork to obtain the SystemServer process. That is to say, when the electronic device determines that the name of the zygote process is a preset name, the electronic device can create zygote virtual machine_1 based on the virtual machine startup parameters corresponding to zygote process_1, and when the electronic device determines that the name of the zygote process is not a preset name, the electronic device can create zygote virtual machine_2 based on the virtual machine startup parameters corresponding to zygote process_2, and call the startSystemServer() method to fork the SystemServer process based on zygote process_2.

[0240] The following specifically describes the process of creating corresponding virtual machines after the electronic device creates zygote process_1 and zygote process_2.

[0241] 1. Start the electronic device, create and start the zygote virtual machine_1 (such as Fig.14A (shown)

[0242] See also Fig.14A , Fig.14A A flowchart of creating a zygote virtual machine_1 is provided in an embodiment of the present application. The process of creating a zygote virtual machine_1 may include but is not limited to the following steps:

[0243] S601: The process control module receives an instruction to start the electronic device.

[0244] It is understandable that the electronic device can detect the user operation of starting the electronic device (for example, the user operation acting on the power button of the electronic device shown in step S301). Specifically, the user can long press the power button on the electronic device, and the process control module in the electronic device can receive the instruction to start the electronic device. It is understandable that before the process control module receives the instruction to start the electronic device, the electronic device can execute steps S301-step S303, and create zygote process_1 (as shown in step S401 and step S505). During the process of the electronic device executing steps S403 and S506, the process control module in the electronic device can receive the instruction to start the electronic device.

[0245] In some embodiments of the present application, the process control module may be an Android runtime environment object created for the electronic device.

[0246] S602: The process control module creates a zygote virtual machine_1. The zygote virtual machine_1 includes a Runtime module_1, an address management module_1 and a runtime data area_1. The runtime data area_1 includes a RegionSpace_1.

[0247] After the electronic device receives the instruction to start the electronic device, in response to the instruction to start the electronic device, the electronic device can create a zygote process_1 and a zygote virtual machine_1. Specifically, after the process control module in the electronic device receives the instruction to start the electronic device, it can create a zygote virtual machine_1. It can be understood that the zygote virtual machine_1 is a virtual machine instance corresponding to the zygote process_1. The zygote virtual machine_1 includes a Runtime module_1, an address management module_1 and a runtime data area_1. The runtime data area_1 includes RegionSpace_1. The relevant description of the zygote virtual machine_1 can be found above and will not be elaborated here.

[0248] S603: The process control module starts the zygote virtual machine_1.

[0249] After the electronic device creates the zygote virtual machine_1, the zygote virtual machine_1 can be started. Specifically, after the zygote virtual machine_1 is created, the process control module can start the zygote virtual machine_1.

[0250] When the electronic device executes step S602, it may specifically execute the following steps:

[0251] S6021: The process control module creates the Runtime module_1.

[0252] After the process control module receives the instruction to start the electronic device, in response to the instruction to start the electronic device, it can create a zygote process_1 and start to create a zygote virtual machine_1. Specifically, the process control module can first create a Runtime module_1. The relevant description of the Runtime module_1 can be referred to above and will not be elaborated here.

[0253] In some embodiments of the present application, the Runtime module_1 may create a Runtime object through the Runtime::create method after creating the zygote process_1 for the electronic device. For details, please refer to step S506, which will not be repeated in this application.

[0254] S6022: Runtime module_1 creates runtime data area_1.

[0255] After the process control module creates the Runtime module_1, the Runtime module_1 can create the runtime data area_1. The description of the runtime data area_1 can be found above and will not be elaborated here.

[0256] In some embodiments of the present application, the runtime data area_1 may be a heap object created by the electronic device through the new gc::heap() method.

[0257] It is understandable that after the Runtime module_1 creates the runtime data area_1, the runtime data area_1 can perform a layout of the memory space. That is, the electronic device can perform a layout of the runtime data area_1. The specific implementation of the layout of the runtime data area_1 can include steps S6023-S6028.

[0258] In some embodiments of the present application, the electronic device performs the layout of the runtime data area_1, which may specifically include: the electronic device may specifically set the memory size of each space (for example, RegionSpace_1) in the heap object in the zygote virtual machine_1 based on the virtual machine startup parameters corresponding to the zygote virtual machine_1.

[0259] S6023: The runtime data area_1 determines that the memory size corresponding to the RegionSpace_1 in the runtime data area_1 is a first value.

[0260] After the Runtime module_1 creates the runtime data area_1, the runtime data area_1 can determine the memory size corresponding to each Space in the runtime data area_1. Specifically, the runtime data area_1 can determine that the memory size corresponding to RegionSpace_1 is the first value. It can also be understood that the runtime data area_1 can determine that the initial memory size corresponding to RegionSpace_1 is the first value. The first value is greater than the second value. In this case, the second value refers to the second value corresponding to RegionSpace. It can be understood that RegionSpace_1 is a piece of memory space in the runtime data area_1, and its detailed description can be referred to above.

[0261] Of course, the runtime data area_1 can also determine the memory size corresponding to other Spaces (for example, ImageSpace, etc.) in the runtime data area_1. For its specific implementation, please refer to relevant technical documents and will not be described in detail here.

[0262] In some embodiments of the present application, the runtime data area_1 can determine the memory size corresponding to each Space in the runtime data area_1 by reading a related configuration file (for example, a configuration file corresponding to the virtual machine startup parameters corresponding to the zygote virtual machine_1). It can be understood that the configuration file records the memory size corresponding to each Space in the runtime data area_1. In this way, the runtime data area_1 can be laid out according to the memory size corresponding to each Space recorded in the configuration file.

[0263] It can be understood that the configuration file can record the initial memory size corresponding to the zygote process that needs to expand memory (for example, the zygote process with the same name as the preset name) as the first value, that is, the initial memory size corresponding to RegionSpace_1 is the first value, and record the initial memory size corresponding to the zygote process that does not need to expand memory (for example, the zygote process with a name different from the preset name) as the second value, that is, the default memory size corresponding to RegionSpace.

[0264] For example, the first value may be 768, and the second value may be 512.

[0265] Of course, the first value may also be set to other values ​​greater than the second value, and this application does not impose any limitation on this.

[0266] S6024: During runtime, data region_1 creates RegionSpace_1 based on the first value.

[0267] After the runtime data area_1 determines that the memory size corresponding to RegionSpace_1 is the first value, a memory space can be allocated in the runtime data area_1 as RegionSpace_1. In this case, RegionSpace_1 has not yet been created. In the subsequent process, the runtime data area_1 can control RegionSpace_1 to call the address management module_1 to apply for the virtual address corresponding to the first value, establish a mapping between the virtual address and the physical address, and divide the region, thereby realizing the creation of RegionSpace_1.

[0268] S6025: RegionSpace_1 calls address management module_1 to apply for an anonymous page corresponding to the first value. The anonymous page is used to represent a virtual address in the process virtual address space that has a mapping relationship with the physical address.

[0269] After the runtime data region_1 creates RegionSpace_1, RegionSpace_1 can call the address management module_1 to apply for the anonymous page corresponding to the first value. That is, RegionSpace_1 can call the relevant interface and / or relevant function through the address management module_1 to apply for the virtual address corresponding to the first value (also called the virtual address segment corresponding to the first value), and establish a mapping relationship between the virtual address corresponding to the first value and the physical address.

[0270] It is understandable that the heap, stack and data segment in the process virtual address space are generally called anonymous pages. Anonymous pages refer to pages without file backgrounds. They do not exist in the form of files, so they cannot be exchanged with disk files.

[0271] In some embodiments of the present application, RegionSpace_1 calls the address management module_1 to apply for the anonymous page corresponding to the first numerical value, which may specifically include: RegionSpace_1 calls the mmap interface (or mmap function) in the address management module_1 to apply for the anonymous page corresponding to the first numerical value. That is, RegionSpace_1 can call mmap through the address management module_1 to apply for the virtual address corresponding to the first numerical value, and establish a mapping relationship between the virtual address and the physical address corresponding to the first numerical value. It can be understood that mmap refers to Memory Mapped. mmap can be used to map a file or other object into memory. In other words, mmap can specifically implement the mapping of virtual addresses to physical addresses (for example, the mapping between the virtual address segment corresponding to the first numerical value and the real physical address).

[0272] Exemplarily, the first value may be 768. The virtual address segment corresponding to the first value (for example, the address segment of the anonymous page corresponding to the first value) is 75a00000-d5a00000. RegionSpace_1 may call address management module_1 to map 75a00000-d5a00000 to a physical address. After the mapping is completed, the memory size of RegionSpace_1 is the memory corresponding to 75a00000-d5a00000, that is, 768MB (the Java memory size corresponding to the first value).

[0273] S6026: Address management module_1 returns the relevant information of the anonymous page corresponding to the first value to RegionSpace_1. The relevant information of the anonymous page corresponding to the first value is the relevant information of the virtual address corresponding to the first value.

[0274] After RegionSpace_1 calls the address management module_1 and successfully applies for the anonymous page corresponding to the first value, the address management module_1 can return the relevant information of the anonymous page corresponding to the first value to RegionSpace_1. In other words, after RegionSpace_1 calls the address management module_1 to apply for the virtual address corresponding to the first value and successfully establishes the mapping relationship between the virtual address corresponding to the first value and the physical address, the address management module_1 can return the relevant information of the virtual address corresponding to the first value to RegionSpace_1. It can be understood that the virtual address corresponding to the first value can be understood as the virtual address corresponding to RegionSpace_1.

[0275] In some embodiments of the present application, the relevant information of the anonymous page corresponding to the first value may include the first address of the anonymous page corresponding to the first value (ie, the first address of the virtual address segment corresponding to the first value).

[0276] In some embodiments of the present application, the relevant information of the anonymous page corresponding to the first value may include the tail address of the anonymous page corresponding to the first value (ie, the tail address of the virtual address segment corresponding to the first value).

[0277] In some embodiments of the present application, the relevant information of the anonymous page corresponding to the first value may include the first address of the anonymous page corresponding to the first value and the last address of the anonymous page corresponding to the first value.

[0278] Exemplarily, the first address of the anonymous page (i.e., the first address of the virtual address segment corresponding to the first value) may be 75d80000, and the last address of the anonymous page (i.e., the last address of the virtual address segment corresponding to the first value) may be d5d80000. In this case, the virtual address segment corresponding to the first value is 75d80000-d5d80000.

[0279] S6027: RegionSpace_1 divides the regions in RegionSpace_1 based on the relevant information of the anonymous page corresponding to the first value.

[0280] After RegionSpace_1 receives the relevant information of the anonymous page corresponding to the first numerical value returned by the address management module_1, it can divide the region in RegionSpace_1 based on the relevant information of the anonymous page corresponding to the first numerical value, and determine the relevant information of the region. In the case where the relevant information of the anonymous page corresponding to the first numerical value includes the first address of the anonymous page corresponding to the first numerical value, RegionSpace_1 can determine the virtual address segment corresponding to the first numerical value based on the first address of the anonymous page and the first numerical value, and divide the virtual address segment corresponding to the first numerical value into address segments of 256KB in size. It can be understood that each address segment of 256KB in size is a region. Similarly, in the case where the relevant information of the anonymous page corresponding to the first numerical value includes the tail address of the anonymous page corresponding to the first numerical value, RegionSpace_1 can determine the virtual address segment corresponding to the first numerical value based on the tail address of the anonymous page and the first numerical value, and divide the virtual address segment corresponding to the first numerical value into address segments of 256KB in size. When the relevant information of the anonymous page corresponding to the first value includes both the first address and the last address of the anonymous page corresponding to the first value, RegionSpace_1 no longer needs to determine the virtual address segment corresponding to the first value based on the first value, but can obtain the virtual address segment corresponding to the first value based on the first address and the last address of the anonymous page corresponding to the first value, and then the address segment of the anonymous page can be divided into address segments of 256KB in size.

[0281] S6028: During runtime, data area_1 obtains and records relevant information of the regions in RegionSpace_1 from RegionSpace_1.

[0282] After RegionSpace_1 divides the regions, Data Area_1 can obtain and record the relevant information of the regions divided by RegionSpace_1 from RegionSpace_1 during runtime. It can be understood that the relevant information of the regions can include the address segments corresponding to the regions, and can also include the status and type of the regions. Of course, the relevant information of the regions can also include other contents (for example, the types of storage objects in the regions), which is not limited in this application.

[0283] It is understandable that the runtime data area_1 can also determine the memory corresponding to other Spaces, and create corresponding Spaces based on the memory. This application does not limit the order in which the runtime data area_1 creates each Space. It is understandable that after the Space in the runtime data area_1 is created, the layout of the runtime data area_1 is completed. In some embodiments of the present application, after the runtime data area_1 obtains and records the relevant information of the region in RegionSpace_1 from RegionSpace_1, the Runtime module_1 can determine that the layout of the runtime data area_1 is completed.

[0284] 2. Start the electronic device, create and start the zygote virtual machine_2 (such as Fig. 14B (shown)

[0285] See also Fig. 14B , Fig. 14B A flowchart of creating a zygote virtual machine 2 is provided in an embodiment of the present application. The process of creating a zygote virtual machine 2 may include but is not limited to the following steps:

[0286] S601: The process control module receives an instruction to start the electronic device.

[0287] It is understandable that the specific implementation method of step S601 can be referred to above, and this application will not go into details here.

[0288] S604: The process control module creates a zygote virtual machine_2. The zygote virtual machine_2 includes a Runtime module_2, an address management module_2 and a runtime data area_2. The runtime data area_2 includes a RegionSpace_2.

[0289] Similar to step S604, after the electronic device receives the instruction to start the electronic device, in response to the instruction to start the electronic device, the electronic device can create a zygote process_2 and a zygote virtual machine_2. Specifically, after the process control module in the electronic device receives the instruction to start the electronic device, it can create a zygote virtual machine_2. It can be understood that the zygote virtual machine_2 is a virtual machine instance corresponding to the zygote process_2. The zygote virtual machine_2 includes a Runtime module_2, an address management module_2 and a runtime data area_2. The runtime data area_2 includes RegionSpace_2. The relevant description of the zygote virtual machine_2 can be referred to above and will not be elaborated here.

[0290] S605: The process control module starts the zygote virtual machine_2.

[0291] After the electronic device creates the zygote virtual machine_2, the zygote virtual machine_2 can be started. Specifically, after the zygote virtual machine_1 is created, the process control module can start the zygote virtual machine_2.

[0292] It should be noted that the electronic device may first create zygote process_1 and zygote virtual machine_1, and then create zygote process_2 and zygote virtual machine_2. The electronic device may also first create zygote process_2 and zygote virtual machine_2, and then create zygote process_1 and zygote virtual machine_1. In other words, the present application does not limit the order in which the electronic device executes step S603 and step S604.

[0293] When the electronic device executes step S604, it may specifically execute the following steps:

[0294] S6041: The process control module creates the Runtime module_2.

[0295] After the process control module receives the instruction to start the electronic device, in response to the instruction to start the electronic device, it can create a zygote process_2 and start creating a zygote virtual machine_2. Specifically, the process control module can first create a Runtime module_2. The relevant description of the Runtime module_2 can be referred to above and will not be expanded here.

[0296] In some embodiments of the present application, the Runtime module_2 may create a Runtime object through the Runtime::create method after creating the zygote process_2 for the electronic device. For details, please refer to step S502, which will not be repeated in this application.

[0297] S6042: Runtime module_2 creates runtime data area_2.

[0298] After the process control module creates the Runtime module_2, the Runtime module_2 can create the runtime data area_2. The description of the runtime data area_2 can be found above and will not be elaborated here.

[0299] In some embodiments of the present application, the runtime data area_2 may be a heap object created by the electronic device through the new gc::heap() method.

[0300] It is understandable that after the Runtime module_2 creates the runtime data area_2, the runtime data area_2 can perform a layout of the memory space. That is, the electronic device can perform a layout of the runtime data area_2. The specific implementation of the layout of the runtime data area_2 can include steps S6043-S6048.

[0301] In some embodiments of the present application, the electronic device performs the layout of the runtime data area_2, which may specifically include: the electronic device may specifically set the memory size of each space (for example, RegionSpace_2) in the heap object in the zygote virtual machine_2 based on the virtual machine startup parameters corresponding to the zygote virtual machine_2.

[0302] S6043: The runtime data area_2 determines that the memory size corresponding to the RegionSpace_2 in the runtime data area_2 is the second value.

[0303] After the Runtime module_1 creates the runtime data area_2, the runtime data area_2 can determine the memory size corresponding to each Space in the runtime data area_2. Specifically, the runtime data area_2 can determine that the memory size corresponding to RegionSpace_2 is the second value. It can also be understood that the runtime data area_2 can determine that the initial memory size corresponding to RegionSpace_2 is the second value, that is, the second value corresponding to RegionSpace. It can be understood that RegionSpace_2 is a piece of memory space in the runtime data area_2, and its detailed description can be referred to above.

[0304] Of course, the runtime data area_2 can also determine the memory size corresponding to other Spaces (for example, ImageSpace, etc.) in the runtime data area_2. For its specific implementation, please refer to relevant technical documents and will not be described in detail here.

[0305] In some embodiments of the present application, the runtime data area_2 can determine the memory size corresponding to each Space in the runtime data area_2 by reading a related configuration file (for example, a configuration file corresponding to the virtual machine startup parameters corresponding to the zygote virtual machine_2). It can be understood that the configuration file records the memory corresponding to each Space in the runtime data area_2. In this way, the runtime data area_2 can be laid out according to the memory corresponding to each Space recorded in the configuration file.

[0306] It is understandable that the configuration file may record that the initial memory size corresponding to a zygote process that does not require memory expansion (for example, a zygote process whose name is different from the preset name) is the second value, that is, the initial memory size corresponding to RegionSpace_1 is the second value.

[0307] S6044: During runtime, data region_2 creates RegionSpace_2 based on the second value.

[0308] After the runtime data area_2 determines that the memory size corresponding to RegionSpace_2 is the second value corresponding to RegionSpace, a memory space can be allocated in the runtime data area_2 as RegionSpace_2. In this case, RegionSpace_2 has not yet been created. In the subsequent process, the runtime data area_2 can control RegionSpace_2 to call the address management module_2 to apply for the virtual address corresponding to the second value, and establish a mapping between the virtual address and the physical address, and divide the region, thereby realizing the creation of RegionSpace_2.

[0309] S6045: RegionSpace_2 calls address management module_2 to apply for the anonymous page corresponding to the second value.

[0310] After the runtime data area_2 creates RegionSpace_2, RegionSpace_2 can call the address management module_2 to apply for the anonymous page corresponding to the second value, that is, the anonymous page corresponding to the second value corresponding to RegionSpace. In other words, RegionSpace_2 can call the relevant interface and / or relevant function through the address management module_2 to apply for the virtual address corresponding to the second value (also called the virtual address segment corresponding to the second value), and establish a mapping relationship between the virtual address corresponding to the second value and the physical address.

[0311] Similar to step S6025, RegionSpace_2 can call the mmap function in the address management module_2 to apply for the anonymous page corresponding to the second value. In other words, RegionSpace_2 can call mmap through the address management module_2 to apply for the virtual address corresponding to the second value and establish a mapping relationship between the virtual address corresponding to the second value and the physical address.

[0312] Exemplarily, the second value may be 512. The virtual address segment corresponding to the second value (for example, the address segment of the anonymous page corresponding to the second value) is 75d80000-b5d80000. RegionSpace_2 may call address management module_2 to map 75d80000-b5d80000 to a physical address. After the mapping is completed, the memory size of RegionSpace_2 is the memory corresponding to 75d80000-b5d80000, that is, 512MB (the Java memory size corresponding to the second value).

[0313] S6046: Address management module_2 returns the relevant information of the anonymous page corresponding to the second value to RegionSpace_2. The relevant information of the anonymous page corresponding to the second value is the relevant information of the virtual address corresponding to the second value.

[0314] After RegionSpace_2 calls address management module_2 to successfully apply for the anonymous page corresponding to the second value, address management module_2 can return relevant information of the anonymous page corresponding to the second value to RegionSpace_2. The specific implementation method can refer to step S6026, and this application will not repeat it here.

[0315] S6047: RegionSpace_2 divides the regions in RegionSpace_2 based on the relevant information of the anonymous page corresponding to the second value.

[0316] S6048: During runtime, data area_2 obtains and records relevant information of the regions in RegionSpace_2 from RegionSpace_2.

[0317] It can be understood that the specific implementation method of step S6047-step S6048 can refer to step S6027-step S6028, and this application will not repeat them here.

[0318] It is understandable that the runtime data area_2 can also determine the memory corresponding to other Spaces, and create corresponding Spaces based on the memory. This application does not limit the order in which the runtime data area_2 creates each Space. It is understandable that after the Space in the runtime data area_2 is created, the layout of the runtime data area_2 is completed. In some embodiments of the present application, after the runtime data area_2 obtains and records the relevant information of the region in RegionSpace_2 from RegionSpace_2, the Runtime module_2 can determine that the layout of the runtime data area_2 is completed.

[0319] Second aspect: after triggering the new process, the electronic device selects a zygote process fork from zygote process_1 and zygote process_2 to obtain the process and corresponding virtual machine corresponding to the new process.

[0320] See also Fig.15 , Fig.15 A schematic diagram of a new process provided in an embodiment of the present application.

[0321] like Fig.15As shown, the user can trigger a new process, and accordingly, the electronic device can detect the user operation that triggers the new process. In response to the user operation, the initiating process in the electronic device can notify the SystemServer process in the electronic device to create a new process through the Binder communication method. After the SystemServer process receives the notification of the initiating process, it can determine whether to select the first fork method to create a new process or the second fork method to create a new process. If the SystemServer process selects the first fork method to create a new process, the SystemServer process can notify the zygote process_1 to fork the new process through the Socket communication method, and copy the zygote virtual machine_1, so as to obtain the virtual machine corresponding to the new process. In this case, the Socket communication method is used between the new process and the zygote process_1. If the SystemServer process selects the second fork method to create a new process, the SystemServer process can notify the zygote process_2 to fork the new process through the Socket communication method, and copy the zygote virtual machine_2, so as to obtain the virtual machine corresponding to the new process. In this case, the Socket communication method is used between the new process and the zygote process_2.

[0322] It can be understood that Binder communication is an interprocess communication (IPC) mechanism. Socket communication is also a type of interprocess communication. Two programs on the network exchange data through a two-way communication connection, and one end of this connection is called a socket. The specific meaning and function of Binder communication and Socket communication can be referred to the relevant technical documents, and this application will not elaborate on this.

[0323] The following is a specific implementation method for the SystemServer process to determine the fork method.

[0324] In some embodiments of the present application, the SystemServer process may include a fork mode selection module, a zygote process_1 parameter preparation module, and a zygote process_2 parameter preparation module. Among them, the fork mode selection module is used to determine whether the electronic device adopts the first fork mode to create a new process or the second fork mode to create a new process. The zygote process_1 parameter preparation module is used to prepare the parameters required when the zygote process_1 forks a new process. The zygote process_2 parameter preparation module is used to prepare the parameters required when the zygote process_2 forks a new process.

[0325] In some embodiments of the present application, the fork mode selection module can be a process list class (ProcessList.java), the zygote process_1 parameter preparation module can be a zygote process class (ZygoteProcess.java), and the zygote process_2 parameter preparation module can be a heap expansion zygote process class (HeapExpansionZygoteProcess.java).

[0326] See also Fig.16 , Fig.16 A flowchart of starting an application and creating a corresponding virtual machine is provided in an embodiment of the present application. The process of starting an application and creating a corresponding virtual machine may include but is not limited to the following steps:

[0327] S701: The initiating process receives an instruction to cold start application 1.

[0328] The user can trigger the electronic device to cold start application_1. Accordingly, the initiating process in the electronic device can receive the instruction to cold start application_1. In some embodiments of the present application, the user can trigger the electronic device to cold start application_1 by clicking the application_1 icon. In this case, the initiating process is the Launcher process. The Launcher process can receive the instruction to cold start application_1. It is understandable that the relevant description of the initiating process can be referred to above, and this application will not repeat it here.

[0329] S702: The initiating process notifies the fork mode selection module in the SystemServer process to cold-start application_1.

[0330] After receiving the instruction to cold-start Application_1, the initiating process in the electronic device may notify the SystemServer process in the electronic device to cold-start Application_1. In some embodiments of the present application, the initiating process may specifically notify the fork mode selection module in the SystemServer process to cold-start Application_1.

[0331] S703: The fork mode selection module in the SystemServer process determines whether Application_1 meets the preset conditions.

[0332] After the initiating process notifies the SystemServer process to cold-start application_1, the fork mode selection module in the SystemServer process can determine whether application_1 meets the preset conditions. It can be understood that the relevant description of the preset conditions can be referred to above, and this application will not repeat them here.

[0333] S704: When application_1 meets the preset conditions, the fork mode selection module in the SystemServer process notifies the zygote process_1 parameter preparation module in the SystemServer process to obtain the relevant parameters required for zygote process_1 to fork.

[0334] In some embodiments of the present application, when application_1 meets the preset conditions, the fork mode selection module in the SystemServer process can call Process.java by calling the hostingRecord.usesHeapExpansionZygote() method, and then call the Process.HeapExpansionStart method through Process.java to notify the zygote process_1 parameter preparation module to obtain the relevant parameters required for the zygote process_1 to fork.

[0335] S705: The zygote process_1 parameter preparation module in the SystemServer process obtains relevant parameters required for the zygote process_1 to fork.

[0336] After the fork mode selection module notifies the zygote process_1 parameter preparation module to obtain the relevant parameters required for the zygote process_1 to fork, the zygote process_1 parameter preparation module can prepare the relevant parameters and necessary conditions required for the zygote process_1 to fork. In some embodiments of the present application, the relevant parameters and necessary conditions required for the zygote process_1 process fork may include any one or more of: startup commands and parameters, environment variables (e.g., CLASSPATH), file descriptors, security contexts, Binder handles, and other system properties and settings. Among them, the startup commands and parameters may include various command line parameters required to start the SystemServer process. CLASSPATH is used to specify the class path of the system service. The security context may include a user identifier (User Identifier, UID) and a group identifier (Group Identifier, GID).

[0337] S706: The zygote process_1 parameter preparation module in the SystemServer process sends the zygote process_1 the relevant parameters required for the zygote process_1 to fork.

[0338] It can be understood that after obtaining the relevant parameters required for the zygote process_1 process fork, the zygote process_1 parameter preparation module can send the relevant parameters required for the zygote process_1 to fork to the zygote process_1 through the Socket channel between the SystemServer process and the zygote process_1.

[0339] In some embodiments of the present application, the zygote process_1 parameter preparation module can send the relevant parameters required for the zygote process_1 to fork to the zygote process_1 by calling the openZygoteSocketIfNeeded method.

[0340] S707: The zygote process_1 forks the application_1 process and the application_1 virtual machine based on the relevant parameters required by the zygote process_1 to fork.

[0341] The zygote process_1 can fork the application_1 process based on the relevant parameters required by the zygote process_1 to fork, and the application_1 virtual machine can be copied by the zygote virtual machine_1. It can be understood that the copy process can refer to Figure 7 And the above related descriptions are not repeated in this application.

[0342] S708: When application_1 does not meet the preset conditions, the fork mode selection module in the SystemServer process notifies the zygote process_2 parameter preparation module in the SystemServer process to obtain the relevant parameters required for zygote process_2 to fork.

[0343] In some embodiments of the present application, when application_1 does not meet the preset conditions, the fork mode selection module in the SystemServer process can call Process.java by calling the hostingRecord.usesZygote() method, and then call the Process.Start method through Process.java to notify the zygote process_2 parameter preparation module to obtain the relevant parameters required for the zygote process_2 to fork.

[0344] S709: The zygote process_2 parameter preparation module in the SystemServer process obtains the relevant parameters required for the zygote process_2 to fork.

[0345] It is understandable that the specific implementation method of step S709 can refer to step S705, and this application will not go into details here.

[0346] S710: The zygote process_2 parameter preparation module in the SystemServer process sends the relevant parameters required for zygote process_2 to fork to zygote process_2.

[0347] Similar to step S706, after obtaining the relevant parameters required for the zygote process_2 process fork, the zygote process_2 parameter preparation module can send the relevant parameters required for the zygote process_2 to fork to the zygote process_2 through the Socket channel between the SystemServer process and the zygote process_2. In some embodiments of the present application, the zygote process_2 parameter preparation module can send the relevant parameters required for the zygote process_2 to fork to the zygote process_2 by calling the openZygoteSocketIfNeeded method.

[0348] S711: The zygote process_2 forks the application_1 process and the application_1 virtual machine based on the relevant parameters required by the zygote process_2 to fork.

[0349] The zygote process_2 can fork the application_1 process based on the relevant parameters required by the zygote process_2 to fork, and the application_1 virtual machine is copied by the zygote virtual machine_2. It can be understood that the copy process can refer to Figure 7 And the above related descriptions are not repeated in this application.

[0350] The hardware structure of the electronic device involved in the embodiments of the present application is introduced below.

[0351] See also Fig.17 , Fig.17 A schematic diagram of the hardware structure of an electronic device provided in an embodiment of the present application.

[0352] like Fig.17As shown, the electronic device may include: a processor, an external memory interface, an internal memory, a Universal Serial Bus (USB) interface, a charging management module, a power management module, a battery, an antenna 1, an antenna 2, a mobile communication module, a wireless communication module, a sensor module, a button, a motor, an indicator, a camera, a display screen, and a Subscriber Identity Module (SIM) card slot, etc. Among them, the audio module may include a speaker, a receiver, a microphone, an earphone interface, etc., and the sensor module may include a pressure sensor, a gyroscope sensor, an air pressure sensor, a magnetic sensor, an acceleration sensor, a distance sensor, a proximity light sensor, a fingerprint sensor, a temperature sensor, a touch sensor, an ambient light sensor, a bone conduction sensor, etc.

[0353] It is to be understood that the structure illustrated in the embodiments of the present application does not constitute a specific limitation on the electronic device. It is to be understood that the illustrated components can be implemented in hardware, software, or a combination of software and hardware. In some embodiments of the present application, the electronic device may include more components than illustrated. Exemplarily, the electronic device may include other types of sensors. In some other embodiments of the present application, the electronic device may include fewer components than illustrated, or combine certain components, or split certain components, or arrange the components differently. The interface connection relationship between the modules illustrated in the embodiments of the present application is only a schematic illustration and does not constitute a structural limitation on the electronic device.

[0354] The processor may include one or more processing units, for example, the processor may include an application processor (AP), a modem processor, a graphics processor (GPU), an image signal processor (ISP), a controller, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural-network processing unit (NPU), etc. A memory may also be provided in the processor for storing instructions and data.

[0355] Electronic devices achieve display functions through GPU, display, and application processor.

[0356] The GPU is a microprocessor for image processing, connected to the display screen and the application processor. The GPU is used to perform mathematical and geometric calculations for graphics rendering. The processor may include one or more GPUs, which execute program instructions to generate or change display information. The display screen is used to display images, videos, etc. In some embodiments, the electronic device may include one or more display screens.

[0357] The camera is used to capture static images or videos. The ISP is used to process the data fed back by the camera. Light is transmitted to the camera's photosensitive element through the lens, and the light signal is converted into an electrical signal. The camera's photosensitive element transmits the electrical signal to the ISP for processing and converts it into an image visible to the naked eye. An electronic device may include one or more cameras.

[0358] The internal memory may include one or more RAMs and one or more non-volatile memories (NVMs). The random access memory can be directly read and written by the processor, and can be used to store executable programs (e.g., machine instructions) of the operating system or other running programs, and can also be used to store user and application data, etc. The non-volatile memory can also store executable programs and store user and application data, etc., and can be loaded into the random access memory in advance for direct reading and writing by the processor.

[0359] In the embodiment of the present application, the code for implementing the memory expansion method described in the embodiment of the present application can be stored in a non-volatile memory. When running the camera application, the electronic device can load the executable code stored in the non-volatile memory into the random access memory.

[0360] The external memory interface can be used to connect to an external non-volatile memory to expand the storage capacity of the electronic device.

[0361] Electronic devices can implement audio functions through audio modules, speakers, receivers, microphones, headphone jacks, and application processors.

[0362] The audio module is used to convert digital audio information into analog audio signal output, and also used to convert analog audio input into digital audio signal. The speaker, also known as the "horn", is used to convert audio electrical signals into sound signals. The receiver, also known as the "earpiece", is used to convert audio electrical signals into sound signals. The microphone, also known as the "microphone" or "microphone", is used to convert sound signals into electrical signals. The headphone jack is used to connect wired headphones.

[0363] In an embodiment of the present application, when the speech-to-text function is turned on, the electronic device can enable a microphone to collect sound signals and convert the sound signals into corresponding text.

[0364] A touch sensor is also called a "touch control device". The touch sensor can be set on a display screen. The touch sensor and the display screen form a touch screen, also called a "touch control screen". The touch sensor is used to detect touch operations acting on or near it. The touch sensor can pass the detected touch operation to an application processor to determine the type of touch event. Visual output related to the touch operation can be provided through the display screen. In other embodiments, the touch sensor can also be set on the surface of the electronic device, which is different from the position of the display screen.

[0365] The above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, a person skilled in the art should understand that the technical solutions described in the aforementioned embodiments may still be modified, or some of the technical features may be replaced by equivalents. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the scope of the technical solutions of the embodiments of the present application.

Claims

1. A memory expansion method, characterized in that: Applied to an electronic device; the electronic device is provided with a first zygote virtual machine and a second zygote virtual machine; the memory size of the Java memory space in the first zygote virtual machine is a first value; the memory size of the Java memory space in the second zygote virtual machine is a second value; The first value is greater than the second value; and the method comprises: The electronic device receives a first instruction from a user to cold start a first application; In response to the first instruction, when the first application meets a preset condition, the electronic device copies the first zygote virtual machine to obtain a first virtual machine; the first virtual machine is a virtual machine instance corresponding to a first application process; the first application process is a process corresponding to the first application; the memory size of the Java memory space in the first virtual machine is the first value.

2. The method according to claim 1, characterized in that After the electronic device receives a first instruction from a user to cold start the first application, the method further includes: In response to the first instruction, when the first application does not meet the preset condition, the electronic device copies the second zygote virtual machine to obtain a second virtual machine; the second virtual machine is a virtual machine instance corresponding to the first application process; the memory size of the Java memory space in the second virtual machine is the second value.

3. The method according to claim 2, characterized in that The first zygote virtual machine is a virtual machine instance corresponding to the first zygote process, and the second zygote virtual machine is a virtual machine instance corresponding to the second zygote process; Before the electronic device receives a first instruction from a user to cold start the first application, the method further includes: The electronic device receives a second instruction from a user to start the electronic device; In response to the second instruction, the electronic device creates the first zygote process and the first zygote virtual machine, and creates the second zygote process and the second zygote virtual machine; The electronic device incubates a system service SystemServer process based on the second zygote process.

4. The method according to claim 3, characterized in that The electronic device receiving a first instruction from a user to cold start a first application specifically includes: the electronic device receiving the first instruction by initiating a process; After the electronic device receives a first instruction from a user to cold start a first application, the method further includes: in response to the first instruction, the electronic device notifies the SystemServer process in the electronic device through the initiating process to start the first application; and the electronic device determines whether the first application meets the preset condition through the SystemServer process.

5. The method according to claim 4, characterized in that When the first application satisfies a preset condition, the electronic device copies the first zygote virtual machine to obtain a first virtual machine, specifically including: When the electronic device determines through the SystemServer process that the first application satisfies the preset condition, the electronic device notifies the first zygote process in the electronic device through the SystemServer process to incubate the first application process; When the electronic device incubates the first application process through the first zygote process, the first virtual machine is copied by the first zygote virtual machine.

6. The method according to claim 4 or 5, characterized in that When the first application does not meet the preset condition, the electronic device copies the second zygote virtual machine to obtain the second virtual machine, specifically including: When the electronic device determines through the SystemServer process that the first application does not meet the preset condition, the electronic device notifies the second zygote process in the electronic device through the SystemServer process to incubate the first application process; When the electronic device incubates the first application process through the second zygote process, the second virtual machine is copied by the second zygote virtual machine.

7. The method according to any one of claims 1 to 6, characterized in that The virtual address corresponding to the Java memory space in the first zygote virtual machine is the first virtual address segment; the memory size corresponding to the first virtual address segment is the first value; the virtual address corresponding to the Java memory space in the second zygote virtual machine is the second virtual address segment; The memory size corresponding to the second virtual address segment is the second value; the method further includes: In the process of the electronic device creating the first zygote virtual machine, the electronic device determines that the memory size of the Java memory space in the first zygote virtual machine is the first value, and, for the Java memory space in the first zygote virtual machine, the electronic device applies for the first virtual address segment and maps the first virtual address segment to a physical address; During the process of the electronic device creating the second zygote virtual machine, the electronic device determines that the memory size of the Java memory space in the second zygote virtual machine is the second value, and, for the Java memory space in the second zygote virtual machine, the electronic device applies for the second virtual address segment and maps the second virtual address segment to a physical address.

8. The method according to claim 7, characterized in that The electronic device applies for the first virtual address segment, and maps the first virtual address segment to a physical address, specifically comprising: the electronic device applies for an anonymous page corresponding to the first value; the anonymous page corresponding to the first value includes the first virtual address segment; the anonymous page is used to represent a virtual address segment in a process virtual address space that has a mapping relationship with a physical address; The electronic device applies for the second virtual address segment and maps the second virtual address segment to the physical address, specifically including: the electronic device applies for an anonymous page corresponding to the second value; the anonymous page corresponding to the second value includes the second virtual address segment.

9. The method according to any one of claims 1 to 8, characterized in that The first application meets preset conditions, specifically including: in the historical records of memory usage after multiple cold starts of the first application, the number of first-category historical records is greater than the number of first-category historical records; the first-category historical records include: historical records of occupied memory of the Java memory space in the first application virtual machine being greater than a first threshold.

10. The method according to any one of claims 1 to 8, characterized in that The first application meets a preset condition, which specifically includes: the first application is an application in a preset list.

11. An electronic device comprising one or more memories and one or more processors, characterized in that: The memory is used to store a computer program; the processor is used to call the computer program so that the electronic device executes the method according to any one of claims 1 to 10.

12. A computer storage medium, characterized in that: include: Computer instructions; when the computer instructions are executed on an electronic device, the electronic device executes the method according to any one of claims 1 to 10.

Images