Information processing method, device and equipment and computer readable storage medium

Abstract

The invention relates to the technical field of terminals, and provides an information processing method, device and equipment and a computer readable storage medium, and the method comprises the steps: responding to an input operation of a user, when a to-be-unloaded module has a dynamic loading mode in loading modes, and the loaded state of the to-be-unloaded module is a dynamic loading state, loading the to-be-unloaded module in the dynamic loading mode; unloading the namespace corresponding to the to-be-unloaded module; in the process of unloading the namespace, a first reference relationship between a first data structure corresponding to the to-be-unloaded module and a module manager is modified into a weak reference relationship, the namespace is generated based on the first data structure, and the first data structure represents a source code of the to-be-unloaded module; under the condition that the first reference relation is modified into the weak reference relation, the first data structure is unloaded. Based on the technical scheme, the to-be-unloaded module can be unloaded, the to-be-unloaded module is prevented from residing in a memory, and the performance of the application program is improved.

Description

Technical Field

[0001] The present application relates to the field of terminals, and in particular to an information processing method, apparatus, device and computer-readable storage medium. Background Art

[0002] European Computer Manufacturers Association (ECMA) ScriptModules is a standard module system for JavaScript; in the ECMA JavaScript standard module system, a module is a JavaScript file. Based on the ECMA language specification, a SourceTextModule data structure is generated after the module is loaded for the first time and saved in the memory of the electronic device, so that the SourceTextModule of the module can be directly obtained from the memory when the module is loaded again next time; in the development process of actual applications (Application, APP), there are some modules, such as loaded modules with large memory usage, which are resident in the memory and reduce the performance of the application. Summary of the invention

[0003] The present application provides an information processing method, apparatus, device and computer-readable storage medium, which can realize uninstallation of a module to be uninstalled, avoid the module to be uninstalled from being resident in the memory, and improve the performance of the application.

[0004] In a first aspect, an information processing method is provided, the method comprising: in response to a user input operation, when a module to be uninstalled is loaded in a dynamic loading mode and the loaded state of the module to be uninstalled is a dynamic loading state, unloading a namespace corresponding to the module to be uninstalled; in the process of unloading the namespace, modifying a first reference relationship between a first data structure corresponding to the module to be uninstalled and a module manager to a weak reference relationship, wherein the namespace is generated based on a first data structure, and the first data structure represents a source code of the module to be uninstalled; when the first reference relationship has been modified to a weak reference relationship, unloading the first data structure, realizing the unloading of the module to be uninstalled, avoiding the module to be uninstalled from being resident in the memory, and improving the performance of the application.

[0005] In a possible implementation, the module to be uninstalled is determined in response to an input operation of a user.

[0006] Based on the above solution, the user can know which module is uninstalled, so that when an exception occurs during the operation of the application, the problem can be located and traced in time, thereby improving the reliability of the application operation.

[0007] In a possible implementation, the module to be uninstalled may be a module with the largest memory usage among multiple loaded JavaScript modules.

[0008] In a possible implementation, the module to be unloaded may be a module whose memory usage is greater than a memory usage threshold among multiple loaded JavaScript modules.

[0009] In a possible implementation, the module to be unloaded may be a module whose memory usage is greater than a memory usage threshold and whose usage frequency is less than a usage frequency threshold among multiple loaded JavaScript modules.

[0010] In one possible implementation, unloading the namespace corresponding to the module to be uninstalled can be achieved in the following manner: modifying the second reference relationship between the namespace and the first data structure to a weak reference relationship; when the second reference relationship has been modified to a weak reference relationship and the life cycle of the namespace has ended, unloading (recycling) the namespace through a garbage collector.

[0011] In one possible implementation, during the process of uninstalling the namespace, the first reference relationship between the first data structure corresponding to the module to be uninstalled and the module manager is modified to a weak reference relationship, which can be achieved in the following way: during the process of uninstalling the namespace, the callback function corresponding to the module to be uninstalled is triggered by the first object in the namespace to modify the first reference relationship between the first data structure and the module manager to a weak reference relationship, and the first object is an object used to trigger the uninstallation of the data structure.

[0012] Based on the above scheme, in the process of uninstalling a namespace, the callback function corresponding to the module to be uninstalled is triggered through the first object in the namespace to modify the first reference relationship between the first data structure and the module manager to a weak reference relationship, so that the first data structure is no longer strongly referenced by the module manager, so that the first data structure can be uninstalled when the life cycle of the first data structure ends. In this way, the uninstallation of the module to be uninstalled is realized, which avoids the resident memory of the module to be uninstalled from occupying a large amount of memory space during the application development process, thereby improving the performance of the application.

[0013] In one possible implementation, during the process of uninstalling the namespace, a callback function corresponding to the module to be uninstalled is triggered through the first object in the namespace to modify the first reference relationship between the first data structure and the module manager to a weak reference relationship. This can be achieved in the following way: during the process of uninstalling the namespace, a callback function is triggered through the first object in the namespace; through the callback function, the first target reference count of the module to be uninstalled is determined; through the callback function, when the first target reference count is 0, the first reference relationship between the first data structure and the module manager is modified to a weak reference relationship.

[0014] Based on the above scheme, when the first target reference count is 0, it is determined that the life cycle of the first data structure corresponding to the module to be uninstalled has ended. At this time, the first reference relationship between the first data structure and the module manager can be modified to a weak reference relationship, so that the first data structure is no longer strongly referenced by the module manager. After that, the first data structure can be uninstalled through the garbage collector, thereby realizing the uninstallation of the module to be uninstalled.

[0015] In a possible implementation, determining the first target reference count of the module to be uninstalled through a callback function can be implemented in the following manner: determining the reference count of the module to be uninstalled based on the second object in the first data structure for recording the reference count of the module through the callback function; performing a subtraction operation on the reference count and the target value through the callback function to obtain the first target reference count. The value of the second object in the first data structure is used to indicate the reference count of the module to be uninstalled; and the value of the third object in the first data structure is used to indicate the loaded state of the module to be uninstalled.

[0016] In a possible implementation, the first data structure is unloaded (reclaimed) by a garbage collector.

[0017] In a possible implementation, the loaded state of the module to be uninstalled is obtained in the following manner: based on a third object in the first data structure for recording the loaded state of the module, the loaded state of the module to be uninstalled is determined.

[0018] Based on the above solution, the value of the third object in the first data structure can be read to obtain the loaded state of the module to be uninstalled, thereby improving the efficiency of obtaining the loaded state of the module to be uninstalled.

[0019] In a possible implementation, the second target reference count of the target module on which the module to be uninstalled depends is determined through a callback function, and then the second data structure corresponding to the target module with a second target reference count of 0 can be uninstalled through a garbage collector.

[0020] Based on the above scheme, the callback function of the module to be uninstalled can be used to not only uninstall the first data structure corresponding to the module to be uninstalled, but also uninstall the second data structure corresponding to the target module with a second target reference count of 0 in the module on which the module to be uninstalled depends, thereby clearing more memory space and further improving the performance of the application.

[0021] In one possible implementation, the callback function is used to determine the second target reference count of the target module on which the module to be unloaded depends, and then the second data structure corresponding to the target module whose second target reference count is 0 can be unloaded through the garbage collector. This can be achieved in the following way: through the callback function, the third reference relationship between the second data structure corresponding to the target module whose second target reference count is 0 and the module manager is modified to a weak reference relationship; when the third reference relationship has been modified to a weak reference relationship, the second data structure is unloaded through the garbage collector, and the second data structure represents the source code of the target module whose second target reference count is 0.

[0022] In one possible implementation, loading the module to be unloaded in a dynamic loading manner is achieved in the following manner: in response to a processing instruction of a loader module for dynamically loading the module to be unloaded, if there is no third data structure corresponding to the module to be unloaded in the memory, a third data structure is generated based on the module to be unloaded, and the third data structure has a second object for recording the number of references to the module and a third object for recording the loading status of the module; the value of the second object in the third data structure is modified and the value of the third object in the third data structure is modified to obtain a first data structure; a namespace is generated based on the first data structure, and the namespace is provided to the loader module, wherein the namespace carries a first object for triggering the unloading data structure.

[0023] In one possible implementation, loading the module to be unloaded in a dynamic loading manner is implemented in the following manner: in response to a processing instruction of a loader module for dynamically loading the module to be unloaded, if there is a third data structure corresponding to the module to be unloaded in the memory, the third data structure is obtained from the memory, the third data structure having a second object for recording the number of references to the module and a third object for recording the loaded state of the module; if there is no identifier of the module to be unloaded in the module identifier set and the loaded state of the module to be unloaded is a dynamic loading state, the value of the second object in the third data structure is modified to obtain a first data structure; a namespace is generated based on the first data structure, and the namespace is provided to the loader module, wherein the namespace carries a first object for triggering the unloading data structure.

[0024] After modifying the parameters in the third data structure (such as the value of the second object or the value of the third object), the first data structure is obtained, and the third data structure in the memory is replaced by the first data structure to update the third data structure.

[0025] In a possible implementation, the identifier of the module to be uninstalled is added to a module identifier set.

[0026] Based on the above scheme, the identifier of the module to be uninstalled is added to the module identifier set, so as to determine whether to modify the reference count of the module to be uninstalled when the module to be uninstalled is loaded again later, so as to update the reference count of the module to be uninstalled in time. Thereafter, when responding to the user's input operation, the first target reference count of the module to be uninstalled can be determined according to the reference count of the module to be uninstalled, so as to determine whether the module to be uninstalled can be uninstalled based on the first target reference count, thereby improving the reliability of uninstalling the module to be uninstalled.

[0027] In one possible implementation, when the module identification set contains the identifier of the module to be uninstalled, or the loaded state of the module to be uninstalled is a static loaded state, a namespace is generated based on the third data structure, and the namespace is provided to the loader module, and the first data structure includes the third data structure.

[0028] Based on the above scheme, if the module identification set contains the identification of the module to be unloaded or the loading state of the module to be unloaded is a static loading state, the number of references to the module to be unloaded is not updated, that is, the third data structure of the module to be unloaded is not updated.

[0029] In a second aspect, an information processing device is provided, which includes: an unloading unit for unloading a namespace corresponding to a module to be unloaded in response to a user's input operation, when the module to be unloaded is loaded in a dynamic loading mode and the loaded state of the module to be unloaded is a dynamic loading state; a modification unit for modifying a first reference relationship between a first data structure corresponding to the module to be unloaded and a module manager to a weak reference relationship during the process of unloading the namespace, the namespace being generated based on the first data structure, and the first data structure representing the source code of the module to be unloaded; the unloading unit is also used to unload the first data structure when the first reference relationship has been modified to a weak reference relationship.

[0030] In one possible implementation, the unloading unit is specifically used to perform the following steps: modifying the second reference relationship between the namespace and the first data structure to a weak reference relationship; when the second reference relationship has been modified to a weak reference relationship and the life cycle of the namespace has ended, unloading the namespace through a garbage collector.

[0031] In one possible implementation, the modification unit is specifically used to perform the following steps: in the process of uninstalling the namespace, triggering the callback function corresponding to the module to be uninstalled through the first object in the namespace to modify the first reference relationship between the first data structure and the module manager to a weak reference relationship, and the first object is an object used to trigger the uninstallation of the data structure.

[0032] In a possible implementation, the modification unit is specifically used to perform the following steps: in the process of uninstalling the namespace, triggering a callback function through the first object in the namespace; determining the first target reference count of the module to be uninstalled through the callback function; and modifying the first reference relationship between the first data structure and the module manager to a weak reference relationship through the callback function when the first target reference count is 0.

[0033] In a possible implementation, the modification unit is specifically used to perform the following steps: through a callback function, based on a second object in a first data structure used to record the number of references to the module, determine the number of references of the module to be uninstalled; through the callback function, subtract the number of references and the target value to obtain a first target number of references.

[0034] In a possible implementation manner, the unloading unit is specifically configured to perform the following steps: unloading the first data structure through a garbage collector.

[0035] In a possible implementation, the unloading unit is also used to perform the following steps: determining the second target reference count of the target module on which the module to be unloaded depends through a callback function, the target module being a module whose loading state is a dynamic loading state among the modules on which the module to be unloaded depends; modifying the third reference relationship between the second data structure corresponding to the target module whose second target reference count is 0 and the module manager to a weak reference relationship through a callback function; when the third reference relationship has been modified to a weak reference relationship, unloading the second data structure through a garbage collector, the second data structure representing the source code of the target module whose second target reference count is 0.

[0036] In one possible implementation, the information processing device also includes a loading unit, which is used to perform the following steps: in response to a processing instruction of the loader module for dynamically loading the module to be unloaded, if there is no third data structure corresponding to the module to be unloaded in the memory, generate a third data structure based on the module to be unloaded, the third data structure having a second object for recording the number of references to the module and a third object for recording the loading status of the module; modify the value of the second object in the third data structure and modify the value of the third object in the third data structure to obtain a first data structure; generate a namespace based on the first data structure, and provide the namespace to the loader module, wherein the namespace carries a first object for triggering the unloading data structure.

[0037] In one possible implementation, the loading unit is used to perform the following steps: in response to a processing instruction of a loading module for dynamically loading a module to be unloaded, if there is a third data structure corresponding to the module to be unloaded in the memory, obtain the third data structure from the memory, the third data structure having a second object for recording the number of references to the module and a third object for recording the loaded state of the module; if there is no identifier of the module to be unloaded in the module identifier set and the loaded state of the module to be unloaded is a dynamically loaded state, modify the value of the second object in the third data structure to obtain a first data structure; generate a namespace based on the first data structure, and provide the namespace to the loading module, wherein the namespace carries a first object for triggering the unloading data structure.

[0038] In a possible implementation, the loading unit is further configured to perform the following steps: adding the identifier of the module to be unloaded to the module identifier set.

[0039] In a possible implementation, the loading unit is also used to perform the following steps: when the module identification set has the identifier of the module to be unloaded, or the loaded state of the module to be unloaded is a static loading state, a namespace is generated based on the third data structure, and the namespace is provided to the loading module, and the first data structure includes the third data structure.

[0040] According to a third aspect, an electronic device is provided, which includes one or more processors and a memory, wherein the memory is coupled to the one or more processors, the memory is 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 execute: in response to a user's input operation, when the module to be uninstalled is loaded in a dynamic loading mode and the loaded state of the module to be uninstalled is a dynamic loading state, unloading a namespace corresponding to the module to be uninstalled; in the process of uninstalling the namespace, modifying a first reference relationship between a first data structure corresponding to the module to be uninstalled and a module manager to a weak reference relationship, the namespace is generated based on a first data structure, and the first data structure represents the source code of the module to be uninstalled; when the first reference relationship has been modified to a weak reference relationship, uninstalling the first data structure.

[0041] In one possible implementation, one or more processors call computer instructions to cause the electronic device to execute: modifying the second reference relationship between the namespace and the first data structure to a weak reference relationship; and unloading the namespace through a garbage collector when the second reference relationship has been modified to a weak reference relationship and the life cycle of the namespace has ended.

[0042] In one possible implementation, one or more processors call computer instructions to cause the electronic device to execute: in the process of uninstalling a namespace, triggering a callback function corresponding to the module to be uninstalled through a first object in the namespace to modify the first reference relationship between the first data structure and the module manager to a weak reference relationship, and the first object is an object used to trigger the uninstallation of the data structure.

[0043] In one possible implementation, one or more processors call computer instructions to cause the electronic device to execute: in the process of uninstalling a namespace, triggering a callback function through a first object in the namespace; determining, through the callback function, the first target reference count of the module to be uninstalled; and, through the callback function, modifying the first reference relationship between the first data structure and the module manager to a weak reference relationship when the first target reference count is 0.

[0044] In one possible implementation, one or more processors call computer instructions to cause the electronic device to execute: through a callback function, based on a second object in a first data structure used to record the number of references to the module, determine the number of references of the module to be uninstalled; through the callback function, subtract the number of references and the target value to obtain a first target number of references.

[0045] In a possible implementation, one or more processors invoke computer instructions to cause the electronic device to execute: unloading the first data structure through a garbage collector.

[0046] In a possible implementation, one or more processors call computer instructions to enable the electronic device to execute: based on a third object in the first data structure for recording the loaded state of the module, determine the loaded state of the module to be uninstalled.

[0047] In one possible implementation, one or more processors call computer instructions to cause the electronic device to execute: determining, through a callback function, the second target reference count of a target module on which the module to be unloaded depends, the target module being a module whose loading state is a dynamic loading state among the modules on which the module to be unloaded depends; modifying, through a callback function, the third reference relationship between a second data structure corresponding to the target module whose second target reference count is 0 and the module manager to a weak reference relationship; and unloading, through a garbage collector, the second data structure representing the source code of the target module whose second target reference count is 0 when the third reference relationship has been modified to a weak reference relationship.

[0048] In one possible implementation, one or more processors call computer instructions to cause an electronic device to execute: in response to a processing instruction of a loader module for dynamically loading a module to be unloaded, generating a third data structure based on the module to be unloaded, if there is no third data structure corresponding to the module to be unloaded in the memory, the third data structure having a second object for recording the number of references to the module and a third object for recording the loading status of the module; modifying the value of the second object in the third data structure and modifying the value of the third object in the third data structure to obtain a first data structure; generating a namespace based on the first data structure, and providing the namespace to the loader module, wherein the namespace carries a first object for triggering the unloading data structure.

[0049] In one possible implementation, one or more processors call computer instructions to cause an electronic device to execute: in response to a processing instruction of a loader module for dynamically loading a module to be unloaded, if there is a third data structure corresponding to the module to be unloaded in the memory, obtain the third data structure from the memory, the third data structure having a second object for recording the number of references to the module and a third object for recording the loaded state of the module; if there is no identifier of the module to be unloaded in the module identifier set and the loaded state of the module to be unloaded is a dynamically loaded state, modify the value of the second object in the third data structure to obtain a first data structure; generate a namespace based on the first data structure, and provide the namespace to the loader module, wherein the namespace carries a first object for triggering the unloading data structure.

[0050] In a possible implementation, one or more processors invoke computer instructions to cause the electronic device to execute: adding the identifier of the module to be uninstalled to the module identifier set.

[0051] In one possible implementation, one or more processors call computer instructions to cause an electronic device to execute: when a module identification set contains an identifier of a module to be uninstalled, or the loaded state of the module to be uninstalled is a static loaded state, a namespace is generated based on a third data structure, and the namespace is provided to a loader module, and the first data structure includes the third data structure.

[0052] In a fourth aspect, a chip is provided. The chip is applied to an electronic device. The chip includes one or more processors. The processor is used to call computer instructions to enable the electronic device to execute the first aspect or any one of the information processing methods in the first aspect.

[0053] In a fifth aspect, a computer-readable storage medium is provided, wherein the computer-readable storage medium stores a computer program code. When the computer program code is executed by an electronic device, the electronic device executes the first aspect or any one of the information processing methods in the first aspect.

[0054] In a sixth aspect, a computer program product is provided, the computer program product comprising: a computer program code, when the computer program code is executed by an electronic device, the electronic device executes the first aspect or any one of the information processing methods in the first aspect.

[0055] In an embodiment of the present application, in response to a user's input operation, when a dynamic loading mode is included in the loading mode of the module to be uninstalled and the loaded state of the module to be uninstalled is a dynamic loading state, the namespace corresponding to the module to be uninstalled is uninstalled; in the process of uninstalling the namespace, the first reference relationship between the first data structure corresponding to the module to be uninstalled and the module manager is modified to a weak reference relationship, the namespace is generated based on the first data structure, and the first data structure represents the source code of the module to be uninstalled; when the first reference relationship has been modified to a weak reference relationship, the first data structure is uninstalled; after the module to be uninstalled is loaded, it exists in the memory in the form of the first data structure, and the unloading of the first data structure is realized through the solution of the present application, that is, the uninstallation of the module to be uninstalled is realized, the module to be uninstalled is avoided from being resident in the memory, the performance of the application is improved, and the problem of the module to be uninstalled being resident in the memory during the development of the application in the related technology is solved, which reduces the performance of the application. BRIEF DESCRIPTION OF THE DRAWINGS

[0056] Figure 1 is a structural schematic diagram of an electronic device provided in an embodiment of the present application;

[0057] Figure 2 is a software structure block diagram of the electronic device 100 according to an embodiment of the present application;

[0058] Figure 3 A flowchart of an information processing method provided in an embodiment of the present application;

[0059] Figure 4 A schematic diagram of loading a JavaScript module in an information processing method provided in an embodiment of the present application;

[0060] Figure 5 A flowchart of another information processing method provided in an embodiment of the present application;

[0061] Figure 6 It is a schematic diagram of GC traversing dynamically loaded JavaScript modules in the related art;

[0062] Figure 7 A schematic diagram of uninstalling a module "src / index" in an information processing method provided in an embodiment of the present application;

[0063] Figure 8A flowchart of another information processing method provided in an embodiment of the present application;

[0064] Fig. 9 A schematic diagram of another loading JavaScript module in an information processing method provided in an embodiment of the present application;

[0065] Fig.10 A schematic diagram of modifying the number of references of a JavaScript module in an information processing method provided in an embodiment of the present application;

[0066] Fig.11 A schematic diagram of determining the first target reference count of an uninstalled module in an information processing method provided in an embodiment of the present application;

[0067] Fig.12 A schematic diagram of another method of loading a JavaScript module in an information processing method provided in an embodiment of the present application;

[0068] Fig.13 A schematic diagram of adding a first object, a second object, a third object and a module identification set in an information processing method provided in an embodiment of the present application;

[0069] Fig.14 is a schematic diagram of the structure of an information processing device provided by an embodiment of the present application;

[0070] Fig.15 It is a structural schematic diagram of an electronic device provided in another embodiment of the present application. DETAILED DESCRIPTION

[0071] The technical solutions in the embodiments of the present application will be described below in conjunction with the drawings in the embodiments of the present application.

[0072] 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 this article is only a description of the association relationship of associated objects, indicating that there can be three relationships; for example, A and / or B can mean: A exists alone, or A and B exist at the same time, or B exists alone. In addition, in the description of the embodiments of the present application, "multiple" means two or more than two.

[0073] In the following, the terms "first", "second", and "third" are used for descriptive purposes only and are not to be understood as indicating or implying relative importance or implicitly indicating the number of the indicated technical features. Thus, a feature defined as "first", "second", and "third" may explicitly or implicitly include one or more of the features.

[0074] An embodiment of the present application provides an electronic device, which is used to execute the information processing method provided by the present application. In some embodiments of the present application, the electronic device can be a mobile phone, a tablet computer, a wearable device, a vehicle-mounted device, an augmented reality (AR) / virtual reality (VR) device, a laptop computer, an ultra-mobile personal computer (UMPC), a netbook, a personal digital assistant (PDA), etc., or can be other devices or apparatuses capable of performing information processing. The embodiments of the present application do not impose any restrictions on the specific type of the electronic device.

[0075] For example, Figure 1 It is a structural schematic diagram of an electronic device provided in an embodiment of the present application.

[0076] like Figure 1 As shown, the electronic device 100 may include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, an earphone interface 170D, a sensor module 180, a button 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a subscriber identification module (SIM) card interface 195, etc. The sensor module 180 may include a pressure sensor 180A, a gyroscope sensor 180B, an air pressure sensor 180C, a magnetic sensor 180D, an acceleration sensor 180E, a distance sensor 180F, a proximity light sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, a touch sensor 180K, an ambient light sensor 180L, a bone conduction sensor 180M, etc.

[0077] It is to be understood that the structure illustrated in the embodiment of the present application does not constitute a specific limitation on the electronic device 100. In other embodiments of the present application, the electronic device 100 may include more or fewer components than shown in the figure, or combine some components, or split some components, or arrange the components differently. The components shown in the figure may be implemented in hardware, software, or a combination of software and hardware.

[0078] The processor 110 may include one or more processing units, for example, the processor 110 may include an application processor (AP), a modem processor, a graphics processor (GPU), an image signal processor (ISP), a controller, a memory, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural-network processing unit (NPU), etc. Different processing units may be independent devices or integrated into one or more processors.

[0079] The controller may be the nerve center and command center of the electronic device 100. The controller may generate an operation control signal according to the instruction operation code and the timing signal to complete the control of fetching and executing instructions.

[0080] The processor 110 may also be provided with a memory for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. The memory may store instructions or data that the processor 110 has just used or cyclically used. If the processor 110 needs to use the instruction or data again, it may be directly called from the memory. This avoids repeated access, reduces the waiting time of the processor 110, and thus improves the efficiency of the system.

[0081] In some embodiments, the processor 110 may include one or more interfaces. The interface may include an inter-integrated circuit (I2C) interface, an inter-integrated circuit sound (I2S) interface, a pulse code modulation (PCM) interface, a universal asynchronous receiver / transmitter (UART) interface, a mobile industry processor interface (MIPI), a general-purpose input / output (GPIO) interface, a subscriber identity module (SIM) interface, and / or a universal serial bus (USB) interface, etc.

[0082] The I2C interface is a bidirectional synchronous serial bus, including a serial data line (SDA) and a serial clock line (SCL). In some embodiments, the processor 110 may include multiple groups of I2C buses. The processor 110 may be coupled to the touch sensor 180K, the charger, the flash, the camera 193, etc. through different I2C bus interfaces. For example: the processor 110 may be coupled to the touch sensor 180K through the I2C interface, so that the processor 110 communicates with the touch sensor 180K through the I2C bus interface, thereby realizing the touch function of the electronic device 100.

[0083] The I2S interface can be used for audio communication. In some embodiments, the processor 110 can include multiple I2S buses. The processor 110 can be coupled to the audio module 170 via the I2S bus to achieve communication between the processor 110 and the audio module 170. In some embodiments, the audio module 170 can transmit an audio signal to the wireless communication module 160 via the I2S interface to achieve the function of answering a call through a Bluetooth headset.

[0084] The PCM interface can also be used for audio communication, sampling, quantizing and encoding analog signals. In some embodiments, the audio module 170 and the wireless communication module 160 can be coupled via a PCM bus interface. In some embodiments, the audio module 170 can also transmit audio signals to the wireless communication module 160 via the PCM interface to implement the function of answering calls via a Bluetooth headset. Both the I2S interface and the PCM interface can be used for audio communication.

[0085] The UART interface is a universal serial data bus for asynchronous communication. The bus can be a bidirectional communication bus. It converts the data to be transmitted between serial communication and parallel communication. In some embodiments, the UART interface is generally used to connect the processor 110 and the wireless communication module 160. For example, the processor 110 communicates with the Bluetooth module in the wireless communication module 160 through the UART interface to implement the Bluetooth function.

[0086] In some embodiments, the audio module 170 can transmit audio signals to the wireless communication module 160 through the UART interface to achieve the function of playing music through Bluetooth headphones.

[0087] The MIPI interface can be used to connect the processor 110 with peripheral devices such as the display screen 194 and the camera 193. The MIPI interface includes a camera serial interface (CSI), a display serial interface (DSI), etc. In some embodiments, the processor 110 and the camera 193 communicate via the CSI interface to implement the shooting function of the electronic device 100. The processor 110 and the display screen 194 communicate via the DSI interface to implement the display function of the electronic device 100.

[0088] The GPIO interface can be configured by software. The GPIO interface can be configured as a control signal or as a data signal. In some embodiments, the GPIO interface can be used to connect the processor 110 with the camera 193, the display 194, the wireless communication module 160, the audio module 170, the sensor module 180, etc. The GPIO interface can also be configured as an I2C interface, an I2S interface, a UART interface, a MIPI interface, etc.

[0089] It is understandable that the interface connection relationship between the modules illustrated in the embodiment of the present application is only a schematic illustration and does not constitute a structural limitation on the electronic device 100. In other embodiments of the present application, the electronic device 100 may also adopt different interface connection methods in the above embodiments, or a combination of multiple interface connection methods.

[0090] The wireless communication function of the electronic device 100 can be implemented through the antenna 1, the antenna 2, the mobile communication module 150, the wireless communication module 160, the modem processor and the baseband processor.

[0091] Antenna 1 and antenna 2 are used to transmit and receive electromagnetic wave signals. Figure 1 The structures of antenna 1 and antenna 2 in the electronic device 100 are only examples. Each antenna in the electronic device 100 can be used to cover a single or multiple communication frequency bands. Different antennas can also be reused to improve the utilization of the antennas. For example, antenna 1 can be reused as a diversity antenna for a wireless local area network. In some other embodiments, the antenna can be used in combination with a tuning switch.

[0092] The electronic device 100 implements the display function through a GPU, a display screen 194, and an application processor. The GPU is a microprocessor for image processing, which connects the display screen 194 and the application processor. The GPU is used to perform mathematical and geometric calculations for graphics rendering. The processor 110 may include one or more GPUs that execute program instructions to generate or change display information.

[0093] The display screen 194 is used to display images, videos, etc. The display screen 194 includes a display panel. The display panel can be a liquid crystal display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode or an active-matrix organic light-emitting diode (AMOLED), a flexible light-emitting diode (FLED), Miniled, MicroLed, Micro-oLed, a quantum dot light-emitting diode (QLED), etc. In some embodiments, the electronic device 100 may include 1 or N display screens 194, where N is a positive integer greater than 1.

[0094] The electronic device 100 can realize the shooting function through ISP, camera 193, video codec, GPU, display screen 194 and application processor.

[0095] ISP is used to process the data fed back by camera 193. For example, when taking a photo, the shutter is opened, and the light is transmitted to the camera photosensitive element through the lens. The light signal is converted into an electrical signal, and the camera photosensitive element transmits the electrical signal to ISP for processing and converts it into an image visible to the naked eye. ISP can also perform algorithm optimization on the noise, brightness, and skin color of the image. ISP can also optimize the exposure, color temperature and other parameters of the shooting scene. In some embodiments, ISP can be set in camera 193.

[0096] The camera 193 is used to capture still images or videos. The object generates an optical image through the lens and projects it onto the photosensitive element. The photosensitive element can be a charge coupled device (CCD) or a complementary metal-oxide-semiconductor (CMOS) phototransistor. The photosensitive element converts the light signal into an electrical signal, and then passes the electrical signal to the ISP to be converted into a digital image signal. The ISP outputs the digital image signal to the DSP for processing. The DSP converts the digital image signal into an image signal in a standard RGB, YUV or other format. In some embodiments, the electronic device 100 may include 1 or N cameras 193, where N is a positive integer greater than 1.

[0097] The digital signal processor is used to process digital signals, and can process not only digital image signals but also other digital signals. For example, when the electronic device 100 is selecting a frequency point, the digital signal processor is used to perform Fourier transform on the frequency point energy.

[0098] Video codecs are used to compress or decompress digital videos. The electronic device 100 may support one or more video codecs. Thus, the electronic device 100 may play or record videos in a variety of coding formats, such as moving picture experts group (MPEG) 1, MPEG2, MPEG3, MPEG4, etc.

[0099] NPU is a neural network computing processor. By drawing on the structure of biological neural networks, such as the transmission mode between neurons in the human brain, it can quickly process input information and can also continuously self-learn. Through NPU, applications such as intelligent cognition of the electronic device 100 can be realized, such as: image recognition, face recognition, voice recognition, text understanding, etc.

[0100] The external memory interface 120 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the electronic device 100. The external memory card communicates with the processor 110 through the external memory interface 120 to implement a data storage function, such as storing music, video and other files in the external memory card.

[0101] The pressure sensor 180A is used to sense the pressure signal and can convert the pressure signal into an electrical signal. In some embodiments, the pressure sensor 180A can be set on the display screen 194. There are many types of pressure sensors 180A, such as resistive pressure sensors, inductive pressure sensors, capacitive pressure sensors, etc. The capacitive pressure sensor can be a parallel plate including at least two conductive materials. When a force acts on the pressure sensor 180A, the capacitance between the electrodes changes. The electronic device 100 determines the intensity of the pressure according to the change in capacitance. When a touch operation acts on the display screen 194, the electronic device 100 detects the touch operation intensity according to the pressure sensor 180A. The electronic device 100 can also calculate the touch position according to the detection signal of the pressure sensor 180A. In some embodiments, touch operations acting on the same touch position but with different touch operation intensities can correspond to different operation instructions. For example: when a touch operation with a touch operation intensity less than the first pressure threshold acts on the short message application icon, an instruction to view the short message is executed. When a touch operation with a touch operation intensity greater than or equal to the first pressure threshold acts on the short message application icon, an instruction to create a new short message is executed.

[0102] The proximity light sensor 180G may include, for example, a light emitting diode (LED) and a light detector, such as a photodiode. The light emitting diode may be an infrared light emitting diode. The electronic device 100 emits infrared light outward through the light emitting diode. The electronic device 100 uses a photodiode to detect infrared reflected light from nearby objects. When sufficient reflected light is detected, it can be determined that there is an object near the electronic device 100. When insufficient reflected light is detected, the electronic device 100 can determine that there is no object near the electronic device 100. The electronic device 100 can use the proximity light sensor 180G to detect that the user holds the electronic device 100 close to the ear to talk, so as to automatically turn off the screen to save power. The proximity light sensor 180G can also be used in leather case mode and pocket mode to automatically unlock and lock the screen.

[0103] The ambient light sensor 180L is used to sense the ambient light brightness. The electronic device 100 can adaptively adjust the brightness of the display screen 194 according to the perceived ambient light brightness. The ambient light sensor 180L can also be used to automatically adjust the white balance when taking pictures. The ambient light sensor 180L can also cooperate with the proximity light sensor 180G to detect whether the electronic device 100 is in a pocket to prevent accidental touches.

[0104] The fingerprint sensor 180H is used to collect fingerprints. The electronic device 100 can use the collected fingerprint characteristics to implement fingerprint unlocking, access application locks, fingerprint photography, fingerprint call answering, etc.

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

[0106] The key 190 includes a power key, a volume key, etc. The key 190 may be a mechanical key or a touch key. The electronic device 100 may receive key input and generate key signal input related to user settings and function control of the electronic device 100.

[0107] The software system of the electronic device 100 may adopt a layered architecture, an event-driven architecture, a micro-core architecture, a micro-service architecture, or a cloud architecture. The embodiment of the present application takes the Android system of the layered architecture as an example to exemplify the software structure of the electronic device 100.

[0108] Figure 2It is a software structure block diagram of the electronic device 100 according to an embodiment of the present application.

[0109] It should be understood that the layered architecture can divide the software into several layers, each layer has a clear role and division of labor; the layers can communicate with each other through software interfaces.

[0110] like Figure 2 As shown, the Android system can be divided into four layers: from top to bottom, they are application layer, application framework layer, Android runtime and system library, and kernel layer. The application layer can include a series of application packages.

[0111] like Figure 2 As shown, the application package may include camera, gallery, calendar, call, map, navigation, WLAN, Bluetooth, music, video, short message and other applications.

[0112] The application framework layer provides an application programming interface (API) and a programming framework for the applications in the application layer. The application framework layer includes some predefined functions.

[0113] like Figure 2 As shown, the application framework layer may include a window manager, a content provider, a view system, a phone manager, a resource manager, a notification manager, and the like.

[0114] The window manager is used to manage window programs. The window manager can obtain the display screen size, determine whether there is a status bar, lock the screen, capture the screen, etc.

[0115] Content providers are used to store and retrieve data and make it accessible to applications. The data can include videos, images, audio, calls made and received, browsing history and bookmarks, phone books, etc.

[0116] The view system includes visual controls, such as controls for displaying text, controls for displaying images, etc. The view system can be used to build applications. A display interface can be composed of one or more views. For example, a display interface including a text notification icon can include a view for displaying text and a view for displaying images.

[0117] The phone manager is used to provide communication functions of the electronic device 100, such as management of call status (including connecting, hanging up, etc.).

[0118] The resource manager provides various resources for applications, such as localized strings, icons, images, layout files, video files, and so on.

[0119] The notification manager enables applications to display notification information in the status bar. It can be used to convey notification-type messages and can disappear automatically after a short stay without user interaction. For example, the notification manager is used to notify download completion, message reminders, etc. The notification manager can also be a notification that appears in the system top status bar in the form of a chart or scroll bar text, such as notifications of applications running in the background, or a notification that appears on the screen in the form of a dialog window. For example, a text message is displayed in the status bar, a prompt sound is emitted, the terminal device vibrates, the indicator light flashes, etc.

[0120] Android runtime includes core libraries and virtual machines. Android runtime is responsible for scheduling and management of the Android system.

[0121] The core library consists of two parts: one part is the function that needs to be called by the Java language, and the other part is the Android core library.

[0122] The application layer and the application framework layer run in a virtual machine. The virtual machine executes the Java files of the application layer and the application framework layer as binary files. The virtual machine is used to perform functions such as object life cycle management, stack management, thread management, security and exception management, and garbage collection.

[0123] The system library may include multiple functional modules, such as: surface manager, media library, 3D graphics processing library (such as open graphics library for embedded systems (OpenGL ES)) and 2D graphics engine (such as skia graphics library (SGL)).

[0124] The surface manager is used to manage the display subsystem and provide the fusion of 2D and 3D layers for multiple applications.

[0125] The media library supports playback and recording of multiple audio formats, playback and recording of multiple video formats, and still image files. The media library can support multiple audio and video coding formats, such as: MPEG4, H.264, moving picture experts group audio layer III (MP3), advanced audio coding (AAC), adaptive multi-rate (AMR), joint photographic experts group (JPG) and portable network graphics (PNG).

[0126] The 3D graphics processing library is used to implement 3D graphics drawing, image rendering, compositing, and layer processing.

[0127] A 2D graphics engine is a drawing engine for 2D drawings.

[0128] The kernel layer is the layer between hardware and software. The kernel layer contains at least display driver, camera driver, audio driver, and sensor driver.

[0129] For ease of understanding, the following examples of this application will be Figure 1 and Figure 2 Taking the electronic device shown as an example, the information processing method provided in the embodiment of the present application is specifically explained in combination with the accompanying drawings and application scenarios.

[0130] Currently, the modular compilation method is to build source code using ECMAScript modules rules. ECMAScript (ES for short) is a scripting language standard defined by the ECMA International Organization, which defines the basic specifications and features of the JavaScript language. JavaScript is a programming language based on the ECMAScript standard.

[0131] ECMAScriptModules is the standard module system of JavaScript, referred to as the ES Modules system. A module in the ES Modules system is a simple JavaScript file that contains the keyword "export" or the keyword "import". "Export" is used to export the content declared in the module; "import" is used to import content from other modules. Modules in the ES Modules system can also be called JavaScript modules.

[0132] In the ES Module system, JavaScript files can contain variables, functions, classes, etc., and can interact with other modules through import and export; the ES Module system supports dynamic import and static import. Among them, static import can also be called static loading, which is used to import (load) variables, functions, classes, etc. in other modules. The imported modules and exported variables are determined at compile time; dynamic import can also be called dynamic loading, which refers to asynchronous loading of a JavaScript module, which allows modules to be loaded on demand instead of loading all modules at once when the application starts.

[0133] According to the ECMA specification, there is a module cache table of root-level objects on the virtual machine. The module cache table is globally unique and its life cycle is consistent with the virtual machine. After the JavaScript module is loaded for the first time, a SourceTextModule data structure will be generated, and the address information of the SourceTextModule will be saved in the module cache table, so that the next time the JavaScript module is loaded again, the address information can be directly obtained from the module cache table, and the SourceTextModule corresponding to the JavaScript module can be obtained based on the address information.

[0134] When dynamically loading a JavaScript module, it is necessary to determine whether the memory has the SourceTextModule corresponding to the JavaScript module. Specifically, it can be determined whether the module cache table has the address information corresponding to the JavaScript module. If the module cache table has the address information, it indicates that the memory has the SourceTextModule corresponding to the JavaScript module; if the module cache table does not have the address information, it indicates that the memory does not have the SourceTextModule corresponding to the JavaScript module. Wherein, when the memory has the SourceTextModule corresponding to the JavaScript module, the dynamically loaded export object, namely moduleNamespace, or Namespace for short, is generated according to the SourceTextModule corresponding to the JavaScript module; when the memory does not have the SourceTextModule corresponding to the JavaScript module, that is, when the JavaScript module is loaded for the first time, the JavaScript module is executed to generate the SourceTextModule, and then the dynamically loaded export object moduleNamespace is generated based on the SourceTextModule; wherein, executing the JavaScript module to generate the SourceTextModule specifically parses the source code in the JavaScript module, and converts the parsed source code to obtain the SourceTextModule; wherein, dynamic loading and static loading share the module cache table, and use the same SourceTextModule to store module information.

[0135] The export object Namespace of the dynamically loaded JavaScript module collects the binding relationship between the export variables and SourceTextModule. Namespace is one of the members of SourceTextModule. In the related technology, the life cycle of Namespace is the same as the life cycle of the virtual machine, and the life cycle of Namespace ends when the virtual machine is destroyed. Namespace refers to the collection of variables, functions, and classes defined in a JavaScript module; SourceTextModule represents the source code of the JavaScript module.

[0136] Based on the ECMA specification language, the module unloading function is not yet supported at the language specification level. However, in the development process of actual applications (Application, APP), there are some modules, such as JavaScript modules that have been loaded and occupy a large amount of memory. Since the current language standard level does not support the module unloading mechanism, the JavaScript module resides in the memory, which brings a lot of overhead and burden to the application and reduces the performance of the application.

[0137] Among them, a JavaScript module is a JavaScript file. When a JavaScript file is loaded for the first time and executed in the virtual machine, it will be parsed by the virtual machine and converted into SourceTextModule to represent the code logic and object values ​​in the JavaScript file. In other words, the JavaScript module is represented in the virtual machine as the SourceTextModule data structure. Uninstalling a JavaScript module does not mean uninstalling the JavaScript module itself, but uninstalling the data structure corresponding to the JavaScript module.

[0138] In view of this, the embodiment of the present application provides an information processing method, which is applied to a virtual machine on an electronic device. For example, the virtual machine may be an Ark virtual machine, and of course it may be other types of virtual machines. The embodiment of the present application does not specifically limit the type of virtual machine. For example, Figure 3 As shown, the information processing method can be implemented through S301 to S303, and each step is described below.

[0139] S301. In response to a user input operation, when the module to be uninstalled is loaded in a dynamic loading mode and the loaded state of the module to be uninstalled is a dynamic loading state, uninstall a namespace corresponding to the module to be uninstalled.

[0140] Among them, the user can be the developer of the application.

[0141] In an embodiment of the present application, a memory crawler can be used to determine the memory usage of each of the multiple loaded JavaScript modules and output it, and the user can determine the module to be uninstalled from the multiple loaded JavaScript modules based on the output memory usage of the multiple loaded JavaScript modules. The memory crawler can be called by the electronic device in response to the user's call instruction; of course, it can also be called actively by the electronic device.

[0142] Exemplarily, the user may determine the module with the largest memory usage from multiple loaded JavaScript modules as the module to be unloaded; the user may also determine the module with a memory usage greater than a memory usage threshold from multiple loaded JavaScript modules as the module to be unloaded.

[0143] Of course, the electronic device can also output the memory usage of each loaded JavaScript module and the usage frequency of each loaded JavaScript module, and the user can determine the module to be uninstalled from multiple loaded JavaScript modules based on the memory usage and usage frequency of each loaded JavaScript module. In this way, both the memory usage of the loaded JavaScript modules and the usage frequency of the loaded JavaScript modules are considered to determine the module to be uninstalled from multiple loaded JavaScript modules, thereby improving the accuracy and reliability of the determined module to be uninstalled.

[0144] Exemplarily, the user may determine a module whose memory usage is greater than a memory usage threshold and whose usage frequency is less than a usage frequency threshold from among multiple loaded JavaScript modules, and use the module as a module to be uninstalled.

[0145] In an embodiment of the present application, a user may input instruction information for instructing to uninstall a JavaScript module on a display interface of an electronic device, and the electronic device obtains the module to be uninstalled in response to the user's input operation; wherein the instruction information carries an identifier of the module to be uninstalled. The user may also click a button for triggering uninstallation of a JavaScript module on a module uninstallation interface of the electronic device, and the electronic device obtains the module to be uninstalled in response to the user's click operation on the button.

[0146] Based on the above scheme, the module to be uninstalled is determined according to the user's input operation, so that the user (developer) can perceive which module is uninstalled, so that when there is an exception during the subsequent operation of the application, the problem can be located and traced in time, thereby improving the reliability of the application operation.

[0147] In an embodiment of the present application, for a JavaScript module, the way in which the JavaScript module is loaded includes a static loading mode and / or a dynamic loading mode. The loaded state of the JavaScript module can be a static loading state or a dynamic loading state. When the JavaScript module is loaded for the first time, the loaded state needs to be recorded. When the JavaScript module is loaded again, no matter which loading mode is used, the recorded loaded state will not change.

[0148] The following is a detailed explanation of the loading of multiple JavaScript modules by the virtual machine during execution in the information processing method provided in the embodiment of the present application.

[0149] During the execution of the virtual machine, the static dependency relationship will be traversed, the statically dependent JavaScript module will be loaded first, and the loaded state of the statically dependent JavaScript module will be recorded as the static loaded state, and then the required JavaScript module will be loaded in a dynamic loading manner when the JavaScript module is executed. Among them, if the required JavaScript module has been recorded as a static loaded state before, that is, the required JavaScript module has been statically loaded at the beginning, then the loaded state of the required JavaScript module will not be changed at this time; if the loaded state of the required JavaScript module has not been recorded as a static loaded state before, then the loaded state of the required JavaScript module will be recorded as a dynamic loaded state at this time, and then the modules loaded by the required JavaScript module (i.e. the modules it depends on) except for the modules that have been recorded as static loaded states will be recorded as dynamic loaded states.

[0150] For example, Figure 4 As shown, during the execution of the virtual machine, the static dependency relationship is first traversed to determine the modules that JavaScript module A statically depends on, such as JavaScript module B and JavaScript module C. Then, JavaScript module B and JavaScript module C can be executed first, that is, JavaScript module B and JavaScript module C are loaded in a static loading manner, and the loaded status of JavaScript module B and JavaScript module C is recorded as a static loading status. Then, JavaScript module A is executed again. During the execution of JavaScript module A, JavaScript module E is also loaded in a dynamic loading manner, as shown in FIG. Figure 4 As shown, it can be seen that JavaScript module E has not been loaded by other modules before, so the loading state of JavaScript module E has not been recorded as a static loading state before, and the loading state of JavaScript module E can be recorded as a dynamic loading state. Figure 4As shown, JavaScript module E also uses static loading to load JavaScript module C, JavaScript module F, and JavaScript module G. Since JavaScript module C was previously recorded as a static loading state, the loading state of JavaScript module C is still a static loading state at this time. Although JavaScript module F and JavaScript module G are loaded using static loading, since JavaScript module E is loaded using dynamic loading, JavaScript module E can be used as the entry file for JavaScript module F and JavaScript module G. Therefore, the loading states of JavaScript module F and JavaScript module G are both recorded as dynamic loading states. Later, when JavaScript module F is executed, JavaScript module F also uses dynamic loading to load JavaScript module G. JavaScript module G was previously marked as a dynamic loading state, and the loading state of JavaScript module G is still a dynamic loading state at this time.

[0151] It should be noted that the loading status of each JavaScript module in the aforementioned loading process is recorded in the SourceTextModule corresponding to the JavaScript module. The data structure includes SourceTextModule.

[0152] In an embodiment of the present application, the loaded state of the module to be uninstalled can be obtained from the first data structure corresponding to the module to be uninstalled. The first data structure is a data structure corresponding to the module to be uninstalled generated at the most recent time before the current time. The module cache table stores the address information corresponding to each JavaScript module, and the address information is used to indicate the location where the data structure corresponding to the module to be uninstalled is stored.

[0153] Exemplarily, the first data structure is a SourceTextModule corresponding to the module to be uninstalled that was generated at the most recent time before the current time, and the loading status of the module to be uninstalled can be obtained from the SourceTextModule.

[0154] In the embodiment of the present application, the namespace (Namespace) corresponding to the module to be uninstalled can be uninstalled through a garbage collector (Garbage Collection, GC).

[0155] S302: During the process of uninstalling the namespace, modify the first reference relationship between the first data structure corresponding to the module to be uninstalled and the module manager to a weak reference relationship.

[0156] The namespace is generated based on a first data structure, and the first data structure represents the source code of the module to be uninstalled.

[0157] In an embodiment of the present application, the first reference relationship between the first data structure corresponding to the module to be uninstalled and the module manager is modified to a weak reference relationship, and specifically, the first reference relationship can be modified from a strong reference relationship to a weak reference relationship. In the process of uninstalling the namespace, the number of first target references of the module to be uninstalled can be calculated. When the first target reference number is 0, the first reference relationship between the first data structure corresponding to the module to be uninstalled and the module manager is modified from a strong reference relationship to a weak reference relationship.

[0158] Among them, the module manager can be called ModuleManager, which is used to manage and organize the loading and calling of JavaScript modules to improve the maintainability and reusability of the code. The strong reference relationship between the first data structure corresponding to the module to be uninstalled and the ModuleManager is modified to a weak reference relationship to ensure that the first data structure can be uninstalled and the memory is released, thereby improving the reliability of uninstalling the first data structure.

[0159] For example, when a JavaScript module is loaded for the first time, its source code will be parsed and converted into a SourceText Module, and the JavaScript module will be added to the ModuleManager for management. There can be mutual reference relationships between multiple JavaScript modules, and the ModuleManager will maintain these reference relationships. When you want to uninstall a JavaScript module, if you do not modify the strong reference relationship between the SourceTextModule corresponding to the JavaScript module and the ModuleManager, then even if the first target reference count of the JavaScript module is set to 0, it still cannot be completely released; because the ModuleManager still holds a reference to the JavaScript module, resulting in the SourceText Module corresponding to the JavaScript module cannot be uninstalled.

[0160] Therefore, in order to correctly uninstall the SourceText Module corresponding to the module to be uninstalled and release memory, the first reference relationship between the SourceTextModule corresponding to the module to be uninstalled and the ModuleManager can be modified from a strong reference relationship to a weak reference relationship, so as to uninstall the SourceTextModule later and release memory space.

[0161] S303: When the first reference relationship has been modified to a weak reference relationship, unload the first data structure.

[0162] In an embodiment of the present application, when the first reference relationship between the first data structure corresponding to the module to be uninstalled and the ModuleManager is a weak reference relationship, and the life cycle of the first data structure ends, the first data structure can be uninstalled through the garbage collector, thereby realizing the uninstallation of the module to be uninstalled, releasing the memory occupied by the module to be uninstalled, and improving the performance of the application.

[0163] An information processing method provided by an embodiment of the present application responds to a user's input operation. When a module to be uninstalled has a dynamic loading mode in the loading mode and the loaded state of the module to be uninstalled is a dynamic loading state, a namespace corresponding to the module to be uninstalled is uninstalled; in the process of uninstalling the namespace, a first reference relationship between a first data structure corresponding to the module to be uninstalled and a module manager is modified to a weak reference relationship, the namespace is generated based on the first data structure, and the first data structure represents the source code of the module to be uninstalled; when the first reference relationship has been modified to a weak reference relationship, the first data structure is uninstalled; after the module to be uninstalled is loaded, it exists in the memory in the form of the first data structure. The first data structure is uninstalled by the solution of the present application, that is, the module to be uninstalled is uninstalled, the module to be uninstalled is avoided to be resident in the memory, the performance of the application is improved, and the problem of the module to be uninstalled being resident in the memory during the development of the application in the related technology is solved, which reduces the performance of the application.

[0164] Based on the above embodiments, illustratively, Figure 5 This application provides an information processing method, which is applied to a virtual machine on an electronic device. The method may include S401 to S404, and each step is described below.

[0165] In the above embodiment, S301 can be implemented by S401 and S402:

[0166] S401. In response to a user input operation, when a module to be uninstalled is loaded in a dynamic loading mode and the loaded state of the module to be uninstalled is a dynamic loading state, modify a second reference relationship between a namespace and a first data structure to a weak reference relationship.

[0167] In an embodiment of the present application, the module to be unloaded can be determined in response to the user's input operation. When the module to be unloaded is loaded in a dynamic loading mode and the loaded state of the module to be unloaded is a dynamic loading state, the second reference relationship between the namespace and the first data structure is modified from a strong reference relationship to a weak reference relationship.

[0168] Exemplarily, the user may input an indication message, where the indication message is “MarkModuleCollectable(“G”)”, and the electronic device may determine that the module to be uninstalled is the JavaScript module G in response to the user's input operation.

[0169] In an embodiment of the present application, the module to be uninstalled can be determined in response to the user's input operation, and it can be determined whether the module to be uninstalled is loaded in a dynamic loading mode and whether the loading state of the module to be uninstalled is a dynamic loading state. Among them, it can be determined whether the module to be uninstalled is loaded in a dynamic loading mode by detecting a target keyword in the code corresponding to the application. If the target keyword is detected in the code, it indicates that the module to be uninstalled is loaded in a dynamic loading mode. Among them, the target keyword is used to dynamically load the module to be uninstalled.

[0170] Exemplarily, the module to be uninstalled may be a JavaScript module G, and the target keyword may be import("G").

[0171] There are two situations in which the module to be unloaded is loaded in a dynamic loading mode. In the first situation, the module to be unloaded has been loaded only in a dynamic loading mode; in the second situation, the module to be unloaded has been loaded both in a static loading mode and in a dynamic loading mode.

[0172] The loaded status of the module to be uninstalled can be obtained in the following ways:

[0173] The loaded state of the module to be uninstalled is obtained from the first data structure through the third object in the first data structure for recording the loaded state of the module.

[0174] In the embodiment of the present application, the value of the third object represents the loading state of the module to be unloaded, and the loading state of the module to be unloaded can be determined by reading the value of the third object. Exemplarily, the third object can be LoadingTypes, and the type of the third object is unint16_t.

[0175] In addition, the virtual machine also stores a module identification set, which includes identifications of JavaScript modules that have a dynamic loading mode and are in a dynamic loading state.

[0176] Determining whether the loading mode of the module to be uninstalled is a dynamic loading mode and whether the loading state of the module to be uninstalled is a dynamic loading state can also be achieved by the following methods:

[0177] In an embodiment of the present application, it is possible to detect whether the module identification set contains the identification of the module to be uninstalled. If the module identification set contains the identification of the module to be uninstalled, it is determined that the way in which the module to be uninstalled is loaded includes a dynamic loading mode, and the loading state of the module to be uninstalled is a dynamic loading state.

[0178] Among them, the module identification set can be deregisterModuleList; when a JavaScript module is loaded in a dynamic loading manner, and the loaded state of the JavaScript module has not been recorded as a static loading state before, if there is no identification of the JavaScript module in deregisterModuleList, the identification of the JavaScript module will be added to deregisterModuleList, and then when the JavaScript module loads other modules, the JavaScript module can be used as the entry file of other modules. If there is an identification of the JavaScript module in deregisterModuleList, the identification of the JavaScript module will not be added to deregisterModuleList to avoid duplication of identifications in deregisterModuleList.

[0179] The namespace corresponding to the module to be uninstalled is generated based on the first data structure corresponding to the module to be uninstalled. The namespace corresponding to the module to be uninstalled includes exported variables, functions and classes. The namespace corresponding to the module to be uninstalled can be understood as an attribute of the first data structure.

[0180] Exemplarily, the second reference relationship between the namespace corresponding to the module to be uninstalled and the first data structure corresponding to the module to be uninstalled is modified from a strong reference relationship to a weak reference relationship. Specifically, the first character representing the strong reference relationship between the Namespace corresponding to the module to be uninstalled and the SourceTextModule corresponding to the module to be uninstalled is modified to a second character representing a weak reference relationship.

[0181] It should be noted that the second reference relationship between the namespace corresponding to the module to be uninstalled and the first data structure corresponding to the module to be uninstalled is a strong reference relationship. If the strong reference relationship is not modified to a weak reference relationship, the namespace corresponding to the module to be uninstalled will always be held by the first data structure corresponding to the module to be uninstalled. When the first data structure is traversed by GC, the namespace will also be traversed by GC and will not be reclaimed by GC. By modifying the strong reference relationship between the namespace corresponding to the module to be uninstalled and the first data structure corresponding to the module to be uninstalled to a weak reference relationship, the life cycle of the namespace corresponding to the module to be uninstalled is determined by the scope of the namespace, so that the namespace corresponding to the module to be uninstalled can be reclaimed by GC later.

[0182] S402: When the second reference relationship has been modified to a weak reference relationship and the life cycle of the namespace ends, the namespace is unloaded through a garbage collector.

[0183] The end of the life cycle of the namespace corresponding to the module to be uninstalled refers to the end of the life cycle of the namespace corresponding to the module to be uninstalled in the code (program), which can be specifically understood as the namespace corresponding to the module to be uninstalled is out of scope.

[0184] In an embodiment of the present application, in the case where the second reference relationship between the namespace corresponding to the module to be uninstalled and the first data structure corresponding to the module to be uninstalled is a weak reference relationship, if it is detected that the life cycle of the namespace corresponding to the module to be uninstalled has ended, the namespace can be uninstalled; in the case where the second reference relationship between the namespace corresponding to the module to be uninstalled and the first data structure corresponding to the module to be uninstalled is a weak reference relationship, if the life cycle of the namespace corresponding to the module to be uninstalled has not ended, the namespace corresponding to the module to be uninstalled may not be uninstalled, and then when the life cycle of the namespace corresponding to the module to be uninstalled ends, the namespace corresponding to the module to be uninstalled is uninstalled. In this way, when the life cycle of the namespace corresponding to the module to be uninstalled ends, the namespace is uninstalled, thereby ensuring the stability of the namespace when it is used.

[0185] It should be noted that, in the above embodiment, S302 can be implemented by S403:

[0186] S403: During the process of uninstalling the namespace, a callback function corresponding to the module to be uninstalled is triggered through the first object in the namespace to modify the first reference relationship between the first data structure and the module manager into a weak reference relationship.

[0187] The first object is an object used to trigger the uninstallation of the data structure.

[0188] Exemplarily, the first object may be a Deregister procession; the type of the first object is JSNativePointer. The callback function corresponding to the module to be uninstalled may be finalizeCallback.

[0189] In the embodiment of the present application, the first data structure is invisible to the developer. The second reference relationship between the namespace corresponding to the module to be uninstalled and the first data structure corresponding to the module to be uninstalled can be modified from a strong reference relationship to a weak reference relationship. When the second reference relationship is a weak reference relationship and the life cycle of the namespace corresponding to the module to be uninstalled ends, the namespace corresponding to the module to be uninstalled is recycled by GC. In the process of recycling the namespace corresponding to the module to be uninstalled, when recycling the first object in the namespace, the callback function corresponding to the module to be uninstalled is triggered, so that when the life cycle of the first data structure ends, the callback function changes the first reference relationship between the first data structure and ModuleManager from a strong reference relationship to a weak reference relationship. In this way, the first data structure corresponding to the module to be uninstalled is no longer held by ModuleManager, which facilitates the recycling of the first data structure later, solving the problem that the module to be uninstalled is resident in the memory and cannot be uninstalled.

[0190] The end of the life cycle of the first data structure means that the first data structure is no longer used, and does not represent what kind of scope it actually has in the code. In other words, the judgment condition for determining whether the life cycle of the first data structure corresponding to the module to be uninstalled has ended is different from the condition for determining whether the life cycle of the namespace corresponding to the module to be uninstalled has ended. In an embodiment of the present application, the end of the life cycle of the first data structure can be determined when the number of first target references of the module to be uninstalled is 0.

[0191] The following combination Figure 6 and Figure 7 , taking the first data structure, which is the SoureTextModule corresponding to the module to be uninstalled, as an example, the information processing method provided by the present application is explained exemplarily.

[0192] In related technologies, such as Figure 6 As shown, after the Javaspace module is dynamically loaded through EcmaVM (virtual machine) in the ES Modules system, the path traversed by GC in the ES Modules system is EcmaVM, ModuleManager, SoureTextModule, and Namespace. The Namespace traversed by GC and the SoureTextModule where the Namespace is located are always in a living state and will not be recycled by GC.

[0193] Based on this, in the information processing method provided by this application, the first data structure takes SoureTextModule as an example, such as Figure 7 As shown in the figure, the 4th line of code refers to loading a module in the function of the loader module (i.e., the calling module) by dynamic loading, such as "src / index". The "module" in the 4th line of code is the object exported from "src / index", i.e., the namespace corresponding to "src / index". The "module message", "module.name" and "module.age" in the 5th line of code are the properties of the "module" in the 4th line of code. Figure 7 As shown, the user can enter the indication information "MarkModuleCollectable("module")" in the 8th line, and the "MarkModuleCollectable("module")" is used to indicate the uninstallation of "src / index". The electronic device can respond to the user's input operation and determine that "src / index" is the module to be uninstalled. In the loading method of "src / index", there is a dynamic loading method, and the loaded state of "src / index" is a dynamic loading state. The strong reference relationship between the Namespace corresponding to "src / index" (that is, the module in the 4th line) and the SoureTextModule corresponding to "src / index" is modified to a weak reference relationship. The 10th line of code refers to "function f()" is executed, that is, the life cycle of the function is over, which means that the life cycle of the Namespace corresponding to "src / index" has also ended, and the Namespace corresponding to "src / index" is no longer held by the SourceTextModule corresponding to "src / index", that is, the Namespace corresponding to "src / index" has lost all the relationships that can be traversed by GC, and can be recycled by GC afterwards; the code in line 11 refers to triggering GC to recycle the Namespace corresponding to "src / index", and then in the process of recycling the Namespace corresponding to "src / index", the strong reference relationship between the SourceTextModule corresponding to "src / index" and ModuleManager can be modified to a weak reference relationship, so as to subsequently recycle the SourceTextModule corresponding to "src / index".

[0194] In the above embodiment, S303 can be implemented by S404:

[0195] S404: When the first reference relationship between the first data structure corresponding to the module to be uninstalled and the module manager has been modified to a weak reference relationship, uninstall the first data structure through a garbage collector.

[0196] An information processing method provided by an embodiment of the present application, after a module to be uninstalled is loaded, exists in the memory in the form of a first data structure, and uninstalling the first data structure, that is, uninstalling the module to be uninstalled, avoids the module to be uninstalled from being resident in the memory, improves the performance of the application, and solves the problem in the related technology that the module to be uninstalled is resident in the memory during the development of the application, thereby reducing the performance of the application.

[0197] Based on the above embodiments, illustratively, Figure 8 This application provides an information processing method, which is applied to a virtual machine on an electronic device. The method may include S501 to S506, and each step is described below.

[0198] S501. In response to a user input operation, when a module to be uninstalled is loaded in a dynamic loading mode and the loaded state of the module to be uninstalled is a dynamic loading state, modify a second reference relationship between a namespace and a first data structure to a weak reference relationship.

[0199] It should be noted that the specific implementation process of S501 is the same as the specific implementation process of S401. The specific implementation process of S401 can refer to the specific implementation process of S401, and the embodiments of the present application will not be repeated here.

[0200] S502: When the second reference relationship has been modified to a weak reference relationship and the life cycle of the namespace ends, the namespace is unloaded through a garbage collector.

[0201] It should be noted that the specific implementation process of S502 is the same as the specific implementation process of S402. The specific implementation process of S502 can refer to the specific implementation process of S402, and the embodiments of the present application will not be repeated here.

[0202] In the above embodiment, S403 can be implemented through S503 to S505:

[0203] S503: During the process of uninstalling the namespace, trigger a callback function corresponding to the module to be uninstalled through the first object in the namespace.

[0204] In an embodiment of the present application, in the process of uninstalling the namespace corresponding to the module to be uninstalled, when the first object in the namespace is uninstalled, a callback function corresponding to the module to be uninstalled mounted under the first object is triggered.

[0205] The first object is an object used to trigger the uninstallation of the data structure.

[0206] Exemplarily, the first object is a Deregister procession; the type of the first object is JSNativePointer.

[0207] Exemplarily, the callback function may be "finalizeCallback".

[0208] S504: Determine the first target reference count of the module to be uninstalled through the callback function.

[0209] In an embodiment of the present application, the number of references of the module to be unloaded is obtained through a callback function, and the number of references of the module to be unloaded is processed to obtain a first target number of references; wherein, the number of references of the module to be unloaded is recorded during the loading process of the module to be unloaded.

[0210] Specifically, S504 can be implemented in the following ways:

[0211] The number of references of the module to be uninstalled is determined through the callback function corresponding to the module to be uninstalled based on the second object in the first data structure for recording the number of references of the module, and the number of references and the target value are subtracted to obtain the first target number of references.

[0212] In the embodiment of the present application, in the process of uninstalling the Namespace corresponding to the module to be uninstalled, when uninstalling the first object, the callback function corresponding to the module to be uninstalled is triggered, and through the callback function, the value of the second object in the first data structure is read to obtain the number of references of the module to be uninstalled, and the number of references is reduced by 1 to obtain the first target number of references. The target value is 1.

[0213] Exemplarily, in the process of uninstalling the Namespace corresponding to the module to be uninstalled, when the first object is uninstalled, the callback function corresponding to the module to be uninstalled is triggered, for example, the callback function may be "finalizeCallback", and through "finalizeCallback", the value of the second object in the SourceTextModule corresponding to the module to be uninstalled (for example, the second object may be "Register Counts") is read, and the value of the second object is subtracted by 1 to obtain the first target reference count of the module to be uninstalled.

[0214] S505 . Through the callback function, when the first target reference count is 0, modify the first reference relationship between the first data structure and the module manager to a weak reference relationship.

[0215] In an embodiment of the present application, when the number of first target references is 0, it indicates that the life cycle of the first data structure corresponding to the module to be uninstalled has ended. At this time, the first reference relationship between the first data structure corresponding to the module to be uninstalled and the ModuleManager can be modified from a strong reference relationship to a weak reference relationship through the callback function, so that the first data structure is no longer held by the ModuleManager, so that the first data structure can be uninstalled subsequently.

[0216] S506: Unload the first data structure through a garbage collector.

[0217] Based on the foregoing embodiment, in other embodiments of the present application, the information processing method may further include the following steps:

[0218] Through the callback function, the second target reference count of the target module on which the module to be unloaded depends is determined, and the target module is a module whose loading state is a dynamic loading state among the modules on which the module to be unloaded depends; through the callback function, the third reference relationship between the second data structure corresponding to the target module whose second target reference count is 0 and the module manager is modified to a weak reference relationship; when the third reference relationship has been modified to a weak reference relationship, the second data structure is unloaded through the garbage collector, and the second data structure represents the source code of the target module whose second target reference count is 0.

[0219] In an embodiment of the present application, after the callback function is triggered, the module on which the module to be unloaded depends can be determined through the callback function, and the module with a dynamic loading state is obtained from the modules on which the module to be unloaded depends as the target module, and the second target reference count of the target module is determined.

[0220] Among them, the value of the third object in the data structure corresponding to the module on which the module to be uninstalled depends can be obtained to obtain the loading status of the module on which the module to be uninstalled depends.

[0221] In an embodiment of the present application, for each target module, the value of the second object in the second data structure corresponding to the target module is read through a callback function to obtain the number of references of the target module, and the number of references of the target module and the target value are subtracted to obtain the second target number of references of the target module.

[0222] Exemplarily, the number of references of the target module is N, and the target value is 1, then the second target number of references is N-1, where N is a positive integer greater than 0.

[0223] In an embodiment of the present application, through a callback function, the third reference relationship between the second data structure corresponding to the target module whose second target reference count is 0 and the module manager is modified from a strong reference relationship to a weak reference relationship; and when the third reference relationship is a weak reference relationship, the second data structure corresponding to the target module whose second target reference count is 0 is recovered through GC.

[0224] The modules that the module to be uninstalled depends on can be determined in the following way.

[0225] Exemplarily, a dependency tree corresponding to the module to be uninstalled may be obtained, and the modules on which the module to be uninstalled depends may be determined from the dependency tree; wherein the dependency tree represents the modules on which the module to be uninstalled depends and the loading order of these modules. The root node in the dependency tree represents the module to be uninstalled.

[0226] It should be noted that when the loading state of the module on which the module to be uninstalled depends is a static loading state, it indicates that the module cannot be uninstalled, and no processing is performed on the module.

[0227] The following takes the case where the number of modules to be uninstalled is 2 and the modules to be uninstalled are JavaScript module G and JavaScript module H, respectively, as an example to explain in detail uninstalling JavaScript module G and JavaScript module H, as well as uninstalling modules on which JavaScript module G depends and uninstalling modules on which JavaScript module H depends.

[0228] like Fig. 9 As shown, JavaScript module A first loads JavaScript module B and JavaScript module C in a static loading manner (the loading status of JavaScript module B and JavaScript module C will be recorded as a static loading status), and in the process of executing (running) JavaScript module A, JavaScript module E is loaded in a dynamic loading manner. In the process of executing JavaScript module E, JavaScript module C, JavaScript module F, JavaScript module G and JavaScript module J are loaded in a static loading manner, and JavaScript module G loads JavaScript module I and JavaScript module J in a static manner.

[0229] Among them, since JavaScript module E is loaded in a dynamic loading manner and the loading state of JavaScript module E is a dynamic loading state, JavaScript module E can be used as the entry file of JavaScript module C, JavaScript module F, JavaScript module G, JavaScript module I and JavaScript module J. As long as the previous loading state of JavaScript module C, JavaScript module F, JavaScript module G, JavaScript module I and JavaScript module J has not been recorded as a static loading state, they will all be recorded as a dynamic loading state; but since JavaScript module C has been recorded as a static loading state before, JavaScript module C will still be considered to be in a static loading state at this time, and only the loading states of JavaScript module F, JavaScript module G, JavaScript module J and JavaScript module I will be recorded as dynamic loading states, and the number of references of JavaScript module F, JavaScript module G, JavaScript module J and JavaScript module I will all be recorded as 1.

[0230] During the execution of JavaScript module F, JavaScript module G is also dynamically loaded using a dynamic loading method, and JavaScript module G loads JavaScript module I and JavaScript module J using a static loading method. In other words, the way JavaScript module G is loaded has a dynamic loading method; Fig.10As shown, the number of references of JavaScript module G will be changed from 1 to 2. The loading method of JavaScript module G has a dynamic loading method, and the loaded state of JavaScript module G is a dynamic loading state. JavaScript module G can be used as the entry file of JavaScript module I and JavaScript module J. The number of references of JavaScript module I and JavaScript module J can be changed from 1 to 2. After that, when JavaScript module J is executed, JavaScript module J loads JavaScript module H in a dynamic loading manner, and the loaded state of JavaScript module H is marked as a dynamic loading state, and the number of references of JavaScript module H is recorded as 1. When JavaScript module H is executed, JavaScript module D is statically loaded. JavaScript module H can be used as the entry file of JavaScript module D. JavaScript module D will also be recorded as a dynamic loading state, and the number of references of JavaScript module D will be recorded as 1.

[0231] Among them, the module that JavaScript module H depends on is JavaScript module D, and the modules that JavaScript module G depends on are JavaScript module I and JavaScript module J.

[0232] By the aforementioned Fig. 9 and Fig.10 From the described loading process, it can be seen that the way JavaScript module G and JavaScript module H are loaded both has a dynamic loading method, and the loading status of JavaScript module G and JavaScript module H are both dynamic loading status. Afterwards, the strong reference relationship between the Namespace corresponding to JavaScript module G and the SourceTextModule corresponding to JavaScript module G can be modified to a weak reference relationship. When the life cycle of the Namespace corresponding to JavaScript module G ends, the Namespace corresponding to JavaScript module G is unloaded; and the strong reference relationship between the Namespace corresponding to JavaScript module H and the SourceTextModule corresponding to JavaScript module H is modified to a weak reference relationship. When the life cycle of the Namespace corresponding to JavaScript module H ends, the Namespace corresponding to JavaScript module H is unloaded.

[0233] In the process of unloading the Namespace corresponding to the JavaScript module H, when the first object in the Namespace corresponding to the JavaScript module H is unloaded, the callback function corresponding to the JavaScript module H is triggered, and the reference count of the JavaScript module H and the reference count of the module (JavaScript module D) that the JavaScript module H depends on and is recorded as a dynamically loaded state are obtained through the callback function. The reference count here refers to the reference count recorded by the aforementioned JavaScript module H and JavaScript module D during the loading process. Fig.11 As shown, the number of references to JavaScript module H can be reduced by 1 to obtain the first target reference number of JavaScript module H, and the first target reference number of JavaScript module H is specifically 1-1=0. At this time, the strong reference relationship between the SourceTextModule corresponding to JavaScript module H and ModuleManager can be modified to a weak reference relationship. If the SourceTextModule corresponding to JavaScript module H and ModuleManager are in a weak reference relationship, then the SourceTextModule corresponding to JavaScript module H can be uninstalled. The number of references to JavaScript module D can be reduced by 1 to obtain the second target reference number of JavaScript module H, and the second target reference number is specifically 1-1=0. At this time, the strong reference relationship between the SourceTextModule corresponding to JavaScript module D and ModuleManager can be modified to a weak reference relationship. If the SourceTextModule corresponding to JavaScript module D and ModuleManager are in a weak reference relationship, then the SourceTextModule corresponding to JavaScript module D can be recycled by GC.

[0234] like Fig.11 As shown, in the process of unloading the Namespace corresponding to JavaScript module G, the reference count of JavaScript module G and the reference count of the modules (JavaScript module I and JavaScript module J) that JavaScript module G depends on and are recorded as dynamically loaded are obtained. The reference count here refers to the reference count recorded during the loading process of the aforementioned JavaScript module G, JavaScript module I and JavaScript module J. Fig.11As shown, the number of references to JavaScript module G can be reduced by 1 to obtain the first target reference number of JavaScript module G. The first target reference number is 2-1=1 and is not 0, indicating that JavaScript module G cannot be uninstalled, and a prompt message can be output to prompt the user that JavaScript module G cannot be uninstalled. The number of references to JavaScript module I can be reduced by 1 to obtain the second target reference number of JavaScript module I. The second target reference number of JavaScript module I=2-1=1. At this time, the second target reference number of JavaScript module I is not 0, so JavaScript module I cannot be uninstalled; the number of references to JavaScript module J can be reduced by J to obtain the second target reference number of JavaScript module J. The second target reference number of JavaScript module J=2-1=1. At this time, the second target reference number of JavaScript module J is not 0, so JavaScript module J cannot be uninstalled.

[0235] Based on the foregoing embodiment, in other embodiments of the present application, in response to the user's input operation, when the module to be uninstalled is loaded in a dynamic loading mode and the loaded state of the module to be uninstalled is a dynamic loading state, before uninstalling the namespace corresponding to the module to be uninstalled, loading the module to be uninstalled in a dynamic loading mode can be implemented in the following manner:

[0236] In response to a processing instruction of a loader module for dynamically loading a module to be unloaded, if there is no third data structure corresponding to the module to be unloaded in the memory, a third data structure is generated based on the module to be unloaded, the third data structure having a second object for recording the number of references to the module and a third object for recording the loaded status of the module; the value of the second object in the third data structure is modified and the value of the third object in the third data structure is modified to obtain a first data structure; a namespace is generated based on the first data structure, and the namespace is provided to the loader module, wherein the namespace carries a first object for triggering the unloading data structure.

[0237] The third data structure represents the source code of the module to be uninstalled, and the third data structure is obtained by parsing the source code in the module to be uninstalled and converting the parsed source code.

[0238] In an embodiment of the present application, if there is no third data structure corresponding to the module to be unloaded in the memory of the electronic device, it indicates that the module to be unloaded has never been loaded before, and the module to be unloaded can be loaded in a dynamic loading manner to obtain a third data structure, and the third data structure carries a second object for recording the number of references of the module and a third object for recording the loaded state of the module. Among them, the value of the second object in the third data structure is 0; the value of the third object in the third data structure can be empty. The value of the second object in the third data structure can be modified from 0 to 1, and the value of the third object in the third data structure is set to a value that characterizes the loaded state as a dynamic loading state, to obtain a first data structure, and a namespace is generated based on the first data structure, and the namespace is provided to the loading side module. At this time, the identifier of the module to be unloaded can be added to the module identifier set, and the first data structure can be stored in the memory, and the address information of the first data structure in the memory can be stored in the module cache table, and then when the module to be unloaded is loaded again, the value of the second object in the first data structure is not modified (that is, the number of references of the module to be unloaded is not modified).

[0239] Of course, in response to the processing instruction of the loader module for dynamically loading the module to be unloaded, when there is a third data structure corresponding to the module to be unloaded in the memory of the electronic device, the third data structure is obtained from the memory of the electronic device, and the third data structure has a second object for recording the number of references of the module and a third object for recording the loaded status of the module; when there is no identifier of the module to be unloaded in the module identification set, and the loaded status of the module to be unloaded is a dynamically loaded status, the value of the second object in the third data structure is modified to obtain the first data structure; a namespace is generated based on the first data structure, and the namespace is provided to the loader module, wherein the namespace carries a first object for triggering the unloading data structure.

[0240] In an embodiment of the present application, in response to a processing instruction of a loader module for dynamically loading a module to be unloaded, when the memory of the electronic device has a third data structure corresponding to the module to be unloaded, it indicates that the module to be unloaded has been loaded before, and the third data structure can be obtained from the memory. If there is no identifier of the module to be unloaded in the module identifier set, and the loaded state of the module to be unloaded is a dynamic loading state, it indicates that the module to be unloaded has been loaded as a subnode under a certain entry file using a static loading method (that is, the module to be unloaded has been loaded by a certain entry file), the value of the second object in the third data structure can be modified to obtain the first data structure, and a namespace is generated based on the first data structure, and the namespace is provided to the loader module. Among them, modifying the value of the second object in the third data structure can be adding 1 to the current value of the second object in the third data structure.

[0241] For example, Figure 4 As shown, the module to be uninstalled may be JavaScript module G. Since JavaScript module G has been previously loaded by JavaScript module E in a static loading manner, the memory has a third data structure corresponding to JavaScript module G. The loaded state of JavaScript module G was previously recorded as a dynamic loading state, and the module identification set does not have an identification of JavaScript module G. When JavaScript module F loads JavaScript module G in a dynamic loading manner, the third data structure corresponding to JavaScript module G can be obtained from the memory, and the number of references of JavaScript module G in the third data structure can be modified from 1 to 2 (i.e., the value of the second object in the third data structure can be modified from 1 to 2), to obtain a new data structure, i.e., the first data structure; based on the first data structure, a namespace corresponding to JavaScript module G is generated, and the namespace corresponding to JavaScript module G is provided to JavaScript module F. It should be noted that when JavaScript module G is loaded in a dynamic loading manner again, the number of references of JavaScript module G in the first data structure is no longer modified, i.e., the parameters in the first data structure are no longer modified.

[0242] Of course, in response to the processing instruction of the loader module for dynamically loading the module to be unloaded, when there is a third data structure corresponding to the module to be unloaded in the memory and the module identification set has the identifier of the module to be unloaded, a namespace is generated based on the third data structure and the namespace is provided to the loader module, and the first data structure includes the third data structure.

[0243] In an embodiment of the present application, in response to a processing instruction of a loader module for dynamically loading a module to be unloaded, if there is a third data structure corresponding to the module to be unloaded in the memory, it indicates that the module to be unloaded has been loaded before, and the module identification set has an identifier of the module to be unloaded, it indicates that the module to be unloaded has been loaded before by dynamic loading, and the loaded state of the module to be unloaded is a dynamic loading state. At this time, the number of references of the module to be unloaded in the third data structure is not modified (i.e., the value of the second object in the third data structure is not modified), a namespace is generated based on the third data structure, and the namespace is provided to the loader module. After that, no matter how many times the module to be unloaded is loaded by dynamic loading, the number of references of the module to be unloaded in the third data structure does not change (i.e., the parameters in the third data structure are not modified). Among them, the first data structure corresponding to the module to be unloaded is the third data structure.

[0244] Of course, in response to the processing instruction of the loader module for dynamically loading the module to be unloaded, there is a third data structure corresponding to the module to be unloaded in the memory, and the loaded state of the module to be unloaded is a static loading state, indicating that the module to be unloaded has been loaded by dynamic loading before, and is not executed as a child node of a certain entry file, then a namespace can be generated based on the third data structure, and the namespace can be provided to the loader module, and no matter how many times the module to be unloaded is loaded by dynamic loading, the number of references to the module to be unloaded in the third data structure does not change. Among them, the first data structure corresponding to the module to be unloaded is the third data structure.

[0245] For example, Fig.12 As shown, the module to be unloaded is Java space module C. Java space module A first loads Javaspace module B and Javaspace module C in a static loading mode. Javaspace module B and Javaspace module C are not statically loaded as entry files of Java space module A, so the loading status of Javaspace module B and Javaspace module C will be recorded as static loading status. When Javaspace module B loads Javaspace module C in a dynamic loading mode, since Javaspace module C has been loaded in a static loading mode before, the memory has a third data structure corresponding to Javaspace module C, and the third data structure corresponding to Javaspace module C can be obtained from the memory. Since the loading status of Javaspace module C was previously recorded as a static loading status (Javaspace module C cannot be unloaded), the number of references of Javaspace module C in the third data structure corresponding to Javaspace module C is not modified at this time (that is, the value of the second object in the third data structure corresponding to Javaspace module C is not modified), and the namespace corresponding to Javaspace module C is generated based on the third data structure corresponding to Javaspace module C, and the namespace is provided to Javaspace module B.

[0246] The following combination Fig.13 , a detailed explanation is given of the newly added module identification set, the first object, the second object and the third object in the solution for loading the Javaspace module in the embodiment of the present application.

[0247] like Fig.13As shown, a module identification set (deregisterModulelist) is added to the virtual machine. When any Javaspace module is loaded, when the SourceTextModule corresponding to the Javaspace module is generated, a second object (Register Counts) for recording the number of references to the module and a third object (LoadingTypes) for recording the loading status of the module are added to the SourceTextModule. When the Javaspace module is loaded in a dynamic loading mode, a Namespace carrying a first object (DregisterProcession) is generated based on the SourceTextModule. When the Javaspace module needs to be uninstalled based on the user's input operation, the loading status of the Javaspace module can be determined through the LoadingTypes in the SourceTextModule corresponding to the Javaspace module; when the loading status of the Javaspace module is a dynamic loading status, and the loading mode of the Javaspace module has a dynamic loading mode, the strong reference relationship between the Namespace corresponding to the Javaspace module and the SourceTextModule corresponding to the Javaspace module is modified to a weak reference relationship; if the Namespace corresponding to the Javaspace module and the SourceTextModule corresponding to the Javaspace module have a weak reference relationship, the N corresponding to the Javaspace module is uninstalled. amespace, in the process of unloading the Namespace corresponding to the Javaspace module, when DregisterProcession is unloaded, the callback function corresponding to the Javaspace module mounted under DregisterProcession is triggered, and through the callback function, the value of the second object in the SourceTextModule corresponding to the Javaspace module is read to obtain the number of references of the module to be unloaded, and the number of references to the module to be unloaded is reduced by 1 to obtain the first target reference number. When the first target reference number is 0, the strong reference relationship between the SourceTextModule corresponding to the Javaspace module and the ModuleManager is modified to a weak reference relationship, and then the SourceTextModule corresponding to the Javaspace module can be recycled (unloaded) by GC. In this way, the Javaspace module can be unloaded, which solves the problem that the loaded module cannot be unloaded in the related technology and improves the performance of the application.

[0248] It should be noted that by referencing the second object in the SourceTextModule corresponding to the Javaspace module to record the number of references to the Javaspace module, the integrity of the Javaspace module unloading in complex loading scenarios is guaranteed; when the module variable, namely Namespace, is recycled, the callback function is triggered to unload the SourceTextModule corresponding to the Javaspace module, thereby ensuring the integrity of the unloading.

[0249] An information processing method provided by an embodiment of the present application, after a module to be uninstalled is loaded, exists in the memory in the form of a first data structure, and uninstalling the first data structure, that is, uninstalling the module to be uninstalled, avoids the module to be uninstalled from being resident in the memory, improves the performance of the application, and solves the problem in the related technology that the module to be uninstalled is resident in the memory during the development of the application, thereby reducing the performance of the application.

[0250] The following will be combined Fig.14 The embodiments of the information processing device of the present application are described in detail. It should be understood that the information processing device in the embodiments of the present application can execute the various methods of the embodiments of the present application, that is, the specific working processes of the following various products can refer to the corresponding processes in the aforementioned method embodiments.

[0251] Fig.14 4 is a schematic diagram of the structure of an information processing device 4 provided in an embodiment of the present application. The information processing device 4 includes an unloading unit 41, a modifying unit 42 and a loading unit 43.

[0252] Among them, the unloading unit 41 is used to respond to the user's input operation, and when the module to be unloaded is loaded in a dynamic loading mode and the loaded state of the module to be unloaded is a dynamic loading state, unload the namespace corresponding to the module to be unloaded; the modification unit 42 is also used to modify the first reference relationship between the first data structure corresponding to the module to be unloaded and the module manager to a weak reference relationship during the process of unloading the namespace, the namespace is generated based on the first data structure, and the first data structure represents the source code of the module to be unloaded; the unloading unit 41 is also used to unload the first data structure when the first reference relationship has been modified to a weak reference relationship.

[0253] In a possible implementation, as an embodiment, the unloading unit 41 is specifically used to: modify the second reference relationship between the namespace and the first data structure to a weak reference relationship; when the second reference relationship has been modified to a weak reference relationship and the life cycle of the namespace has ended, unload the namespace through the garbage collector.

[0254] In a possible implementation, the unloading unit 41 is specifically used to: modify the second reference relationship between the namespace and the first data structure to a weak reference relationship; when the second reference relationship has been modified to a weak reference relationship and the life cycle of the namespace has ended, unload the namespace through a garbage collector.

[0255] In one possible implementation, the modification unit 42 is specifically used to: during the process of uninstalling the namespace, trigger the callback function corresponding to the module to be uninstalled through the first object in the namespace to modify the first reference relationship between the first data structure and the module manager to a weak reference relationship, and the first object is an object used to trigger the uninstallation of the data structure.

[0256] In a possible implementation, the modification unit 42 is specifically used to: trigger a callback function through the first object in the namespace during the process of uninstalling the namespace; determine the first target reference count of the module to be uninstalled through the callback function; and modify the first reference relationship between the first data structure and the module manager to a weak reference relationship through the callback function when the first target reference count is 0.

[0257] In a possible implementation, the modification unit 42 is specifically used to: determine the number of references of the module to be uninstalled based on the second object in the first data structure used to record the number of references of the module through a callback function; and perform a subtraction operation on the number of references and the target value through the callback function to obtain a first target number of references.

[0258] In a possible implementation manner, the unloading unit 41 is specifically configured to: unload the first data structure through a garbage collector.

[0259] In a possible implementation, the uninstallation unit 41 is further used to determine the loading state of the module to be uninstalled based on the third object in the first data structure used to record the loading state of the module.

[0260] In a possible implementation, the unloading unit 41 is also used to: determine the second target reference count of the target module on which the module to be unloaded depends through a callback function, the target module being a module whose loading state is a dynamic loading state among the modules on which the module to be unloaded depends; modify the third reference relationship between the second data structure corresponding to the target module whose second target reference count is 0 and the module manager to a weak reference relationship through a callback function; and unload the second data structure through a garbage collector when the third reference relationship has been modified to a weak reference relationship, the second data structure representing the source code of the target module whose second target reference count is 0.

[0261] In one possible implementation, the loading unit 43 is used to: in response to a processing instruction of the loader module for dynamically loading the module to be unloaded, generate a third data structure based on the module to be unloaded when there is no third data structure corresponding to the module to be unloaded in the memory, the third data structure having a second object for recording the number of references to the module and a third object for recording the loading status of the module; modify the value of the second object in the third data structure and modify the value of the third object in the third data structure to obtain a first data structure; generate a namespace based on the first data structure, and provide the namespace to the loader module, wherein the namespace carries a first object for triggering the unloading data structure.

[0262] In one possible implementation, the loading unit 43 is used to: in response to a processing instruction of the loader module for dynamically loading the module to be unloaded, if there is a third data structure corresponding to the module to be unloaded in the memory, obtain the third data structure from the memory, the third data structure having a second object for recording the number of references to the module and a third object for recording the loaded state of the module; if there is no identifier of the module to be unloaded in the module identifier set and the loaded state of the module to be unloaded is a dynamically loaded state, modify the value of the second object in the third data structure to obtain the first data structure; generate a namespace based on the first data structure, and provide the namespace to the loader module, wherein the namespace carries a first object for triggering the unloading data structure.

[0263] In a possible implementation, the loading unit 43 is further configured to add the identifier of the module to be unloaded to the module identifier set.

[0264] In a possible implementation, the loading unit 43 is also used to: when the module identification set contains the identifier of the module to be unloaded, or the loaded state of the module to be unloaded is a static loading state, generate a namespace based on the third data structure and provide the namespace to the loading module, and the first data structure includes the third data structure.

[0265] It should be noted that the above-mentioned information processing device 4 is embodied in the form of a functional unit. The term "unit" here can be implemented in the form of software and / or hardware, and is not specifically limited to this.

[0266] For example, a "unit" may be a software program, a hardware circuit, or a combination of the two that implements the above functions. The hardware circuit may include an application specific integrated circuit (ASIC), an electronic circuit, a processor (such as a shared processor, a dedicated processor, or a group processor, etc.) and a memory for executing one or more software or firmware programs, a combined logic circuit, and / or other suitable components that support the described functions.

[0267] Therefore, the units of each example described in the embodiments of the present application can be implemented by electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of the present application.

[0268] Fig.15 A structural schematic diagram of an electronic device provided by the present application is shown. Fig.15 The dotted line in the figure indicates that the instruction or the program is optional; the electronic device 5 can be used to implement the information processing method described in the above method embodiment.

[0269] The electronic device 5 includes one or more processors 51, which can support the electronic device 5 to implement the information processing method in the method embodiment. The processor 51 can be a general-purpose processor or a special-purpose processor. For example, the processor 51 can be a central processing unit (CPU), a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic devices, such as discrete gates, transistor logic devices or discrete hardware components.

[0270] The processor 51 can be used to control the electronic device 5, execute the software program, and process the data of the software program. The electronic device 5 can also include a communication unit 55 to implement the input (reception) and output (transmission) of signals.

[0271] For example, the electronic device 5 may be a chip, and the communication unit 55 may be an input and / or output circuit of the chip, or the communication unit 55 may be a communication interface of the chip, and the chip may be a component of a terminal device or other electronic devices.

[0272] For another example, the electronic device 5 may be a terminal device, and the communication unit 55 may be a transceiver of the terminal device, or the communication unit 55 may be a transceiver circuit of the terminal device.

[0273] The electronic device 5 may include one or more memories 52 on which a program 54 is stored. The program 54 can be executed by the processor 51 to generate instructions 53, so that the processor 51 executes the information processing method described in the above method embodiment according to the instructions 53.

[0274] Optionally, data may also be stored in the memory 52 .

[0275] Optionally, the processor 51 may also read data stored in the memory 52 . The data may be stored at the same storage address as the program 54 , or may be stored at a different storage address from the program 54 .

[0276] The processor 51 and the memory 52 may be provided separately or integrated together, for example, integrated on a system on chip (SOC) of the terminal device.

[0277] Exemplarily, the memory 52 can be used to store the relevant program 54 of the information processing method provided in the embodiment of the present application, and the processor 51 can be used to call the relevant program 54 of the information processing method stored in the memory 52 when executing the uninstall module, and execute the method of the embodiment of the present application; for example, in response to the user's input operation, when the module to be uninstalled has a dynamic loading mode in the loading mode, and the loaded state of the module to be uninstalled is a dynamic loading state, the namespace corresponding to the module to be uninstalled is uninstalled; in the process of uninstalling the namespace, the first reference relationship between the first data structure corresponding to the module to be uninstalled and the module manager is modified to a weak reference relationship, the namespace is generated based on the first data structure, and the first data structure represents the source code of the module to be uninstalled; when the first reference relationship has been modified to a weak reference relationship, the first data structure is uninstalled.

[0278] The present application also provides a computer program product, which, when executed by the processor 51, implements the information processing method of any method embodiment in the present application.

[0279] The computer program product may be stored in the memory 52 , for example, a program 54 , which is converted into an executable target file that can be executed by the processor 51 after preprocessing, compiling, assembling, linking and other processing processes.

[0280] The present application also provides a computer-readable storage medium on which a computer program is stored, and when the computer program is executed by a computer, the information processing method of any method embodiment of the present application is implemented. The computer program can be a high-level language program or an executable target program.

[0281] The computer-readable storage medium is, for example, a memory 52. ​​The memory 52 may be a volatile memory or a nonvolatile memory, or the memory 52 may include both a volatile memory and a nonvolatile memory. Among them, the nonvolatile memory may be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or a flash memory. The volatile memory may be a random access memory (RAM), which is used as an external cache. By way of example and not limitation, many forms of RAM are available, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM), and direct rambus RAM (DR RAM).

[0282] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working process of the above-described devices and equipment and the technical effects produced can refer to the corresponding processes and technical effects in the aforementioned method embodiments, and will not be repeated here.

[0283] In several embodiments provided in the present application, the disclosed systems, devices and methods can be implemented in other ways. For example, some features of the method embodiments described above can be ignored or not performed. The device embodiments described above are merely schematic, and the division of units is only a logical function division. There may be other division methods in actual implementation, and multiple units or components may be combined or integrated into another system. In addition, the coupling between the units or the coupling between the components may be direct coupling or indirect coupling, and the above coupling includes electrical, mechanical or other forms of connection.

[0284] It should be understood that in the various embodiments of the present application, the size of the serial number of each process does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

[0285] In addition, the terms "system" and "network" are often used interchangeably in this article. The term "and / or" in this article 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, the character " / " in this article generally indicates that the associated objects before and after are in an "or" relationship.

[0286] In short, the above are only preferred embodiments of the technical solution of this application, and are not intended to limit the protection scope of this application. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of this application should be included in the protection scope of this application.

[0287] The above contents are only specific implementation methods of the present application, but the protection scope of the present application is not limited thereto. Any technician familiar with the technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

Claims

1. An information processing method, characterized in that: Applied to electronic equipment, the method comprises: In response to a user input operation, when the module to be uninstalled is loaded in a dynamic loading mode and the loading state of the module to be uninstalled is a dynamic loading state, uninstalling a namespace corresponding to the module to be uninstalled; In the process of uninstalling the namespace, a first reference relationship between a first data structure corresponding to the module to be uninstalled and the module manager is modified to a weak reference relationship, the namespace is generated based on the first data structure, and the first data structure represents the source code of the module to be uninstalled; When the first reference relationship has been modified to a weak reference relationship, the first data structure is unloaded.

2. The method according to claim 1, characterized in that The step of uninstalling the namespace corresponding to the module to be uninstalled includes: Modify the second reference relationship between the namespace and the first data structure into a weak reference relationship; When the second reference relationship has been modified to a weak reference relationship and the life cycle of the namespace ends, the namespace is unloaded through a garbage collector.

3. The method according to claim 1, characterized in that In the process of uninstalling the namespace, modifying the first reference relationship between the first data structure corresponding to the module to be uninstalled and the module manager into a weak reference relationship includes: During the process of uninstalling the namespace, a callback function corresponding to the module to be uninstalled is triggered through a first object in the namespace to modify a first reference relationship between the first data structure and the module manager to a weak reference relationship, wherein the first object is an object used to trigger the uninstallation of the data structure.

4. The method according to claim 3, characterized in that In the process of uninstalling the namespace, triggering a callback function corresponding to the module to be uninstalled through the first object in the namespace to modify the first reference relationship between the first data structure and the module manager to a weak reference relationship, including: During uninstallation of the namespace, triggering the callback function through a first object in the namespace; Determine the first target reference count of the module to be uninstalled through the callback function; Through the callback function, when the first target reference count is 0, the first reference relationship between the first data structure and the module manager is modified to a weak reference relationship.

5. The method according to claim 4, characterized in that Determining the first target reference count of the module to be uninstalled by the callback function includes: Determine the number of references of the module to be uninstalled by the callback function based on the second object in the first data structure for recording the number of references of the module; The callback function is used to perform a subtraction operation on the reference count and the target value to obtain the first target reference count.

6. The method according to any one of claims 1 to 5, characterized in that: The step of unloading the first data structure comprises: The first data structure is unloaded through a garbage collector.

7. The method according to any one of claims 1 to 6, characterized in that: The loaded state of the module to be unloaded is obtained in the following manner: Based on the third object in the first data structure for recording the loaded state of the module, the loaded state of the module to be uninstalled is determined.

8. The method according to claim 3 or 4, characterized in that: The method further comprises: Determine, by means of the callback function, the second target reference count of the target module on which the module to be uninstalled depends, wherein the target module is a module in the module on which the module to be uninstalled depends and whose loading state is a dynamic loading state; By means of the callback function, the third reference relationship between the second data structure corresponding to the target module whose second target reference count is 0 and the module manager is modified to a weak reference relationship; In the case where the third reference relationship has been modified to a weak reference relationship, the second data structure is unloaded by a garbage collector, the second data structure representing the source code of the target module whose second target reference count is 0.

9. The method according to any one of claims 1 to 8, characterized in that: The module to be unloaded is loaded in a dynamic loading manner by the following method: In response to a processing instruction of the loader module for dynamically loading the module to be unloaded, if there is no third data structure corresponding to the module to be unloaded in the memory, a third data structure is generated based on the module to be unloaded, wherein the third data structure has a second object for recording the number of references of the module and a third object for recording the loading status of the module; Modify the value of the second object in the third data structure and modify the value of the third object in the third data structure to obtain the first data structure; The namespace is generated based on the first data structure, and the namespace is provided to the loader module, wherein the namespace carries a first object for triggering the unloading of the data structure.

10. The method according to any one of claims 1 to 8, characterized in that: The module to be unloaded is loaded in a dynamic loading manner by the following method: In response to a processing instruction of a loader module for dynamically loading the module to be unloaded, if a third data structure corresponding to the module to be unloaded is present in a memory, the third data structure is obtained from the memory, wherein the third data structure has a second object for recording the number of references of the module and a third object for recording the loading status of the module; When the module identification set does not contain the identification of the module to be uninstalled and the loaded state of the module to be uninstalled is a dynamic loading state, modify the value of the second object in the third data structure to obtain the first data structure; The namespace is generated based on the first data structure, and the namespace is provided to the loader module, wherein the namespace carries a first object for triggering the unloading of the data structure.

11. The method according to claim 9 or 10, characterized in that: The method further comprises: The identifier of the module to be uninstalled is added to the module identifier set.

12. The method according to claim 10, characterized in that The method further comprises: When the module identification set contains the identification of the module to be unloaded, or the loaded state of the module to be unloaded is a static loaded state, the namespace is generated based on the third data structure, and the namespace is provided to the loader module, and the first data structure includes the third data structure.

13. An information processing device, characterized in that: The device comprises: an uninstallation unit, configured to, in response to a user input operation, uninstall a namespace corresponding to the module to be uninstalled when the module to be uninstalled is loaded in a dynamic loading mode and the loaded state of the module to be uninstalled is a dynamic loading state; a modification unit, configured to modify, during the process of uninstalling the namespace, a first reference relationship between a first data structure corresponding to the module to be uninstalled and the module manager to a weak reference relationship, wherein the namespace is generated based on the first data structure, and the first data structure represents source code of the module to be uninstalled; The unloading unit is further used to unload the first data structure when the first reference relationship has been modified to a weak reference relationship.

14. An electronic device, characterized in that: include: one or more processors and memory; The memory is coupled to the one or more processors, and the memory is used to store computer program codes, wherein the computer program codes include computer instructions, and the one or more processors call the computer instructions to enable the electronic device to execute the information processing method according to any one of claims 1 to 12.

15. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the processor executes the information processing method according to any one of claims 1 to 12.

Images