Memory management method and device, electronic equipment, chip and medium

Abstract

The invention provides a memory management method and device, electronic equipment, a chip and a medium, and relates to the technical field of computer software. The memory management method comprises the following steps: acquiring a first file of an application programming interface of a shared object algorithm library from first storage equipment, wherein the application programming interface comprises an interface function called by the shared object algorithm library in an operating system; dynamically loading a first performance function of a shared object algorithm library in the second storage device to the first storage device based on the first file; and executing a function corresponding to the first performance function. Through the technical scheme provided by the invention, the problem of insufficient running memory space caused by too high memory occupation in the embedded equipment is solved, and the occupation amount of the running memory during running is reduced.

Description

Technical Field

[0001] The present disclosure relates to the field of computer software technology, and in particular to a memory management method, device, electronic device, chip and medium. Background Art

[0002] With the development of embedded devices, especially in the field of smart wearable products, the chips used often include a sensor hub processor (SP) subsystem, which is mainly responsible for low-power services such as sensor data processing. Wearable products are limited by factors such as size, cost, and power consumption. The SP side often has only a very small running memory, that is, random access memory (RAM). For example, smart watches are usually around 1MB. With the development of technology and the increasing demand of consumers, smart wearable products have developed from only one or two sensors at the beginning to more than ten sensors now. Along with this, the types and number of sensor processing algorithms have increased rapidly, making it difficult for the RAM on the SP side to provide sufficient storage space. Summary of the invention

[0003] The present invention provides a memory management method, device, electronic device, chip and medium to solve the problem of excessive memory usage in embedded devices, resulting in insufficient running memory space. By dynamically calling different functional functions of an algorithm library in a read-only memory (ROM) when running in RAM, the memory usage of the algorithm library is optimized and the running memory usage when the functional functions are running is reduced.

[0004] The first aspect of the present disclosure proposes a memory management method, which includes: obtaining a first file of an application programming interface of a shared object algorithm library from a first storage device, the application programming interface including an interface function called by the shared object algorithm library in an operating system; based on the first file, dynamically loading a first functional function of the shared object algorithm library in a second storage device to the first storage device; and executing a function corresponding to the first functional function.

[0005] In one embodiment of the present disclosure, based on the first file, dynamically loading the first function function of the shared object algorithm library in the second storage device to the first storage device includes: copying the first function function in the shared object algorithm library in the second storage device to the dynamic loading area of ​​the first storage device to form a copy of the first function function; obtaining a second file of the first function function in the second storage device, the second file including the function name and function storage address of the first function function; and determining, based on the first function function copy and the second file, that at least one application programming interface of the first function function is stored as a whole in the first file.

[0006] In one embodiment of the present disclosure, obtaining a second file of a first function function of a shared object algorithm library in a second storage device includes: determining a second function function in the shared object algorithm library that is called by the first function function; and recording the function names and function storage addresses of the first function function and the second function function in the second file.

[0007] In one embodiment of the present disclosure, determining, based on a first function function copy and a second file, that at least one application programming interface of a first function function is stored as a whole in the first function function file includes: determining, based on a function name of the first function function copy recorded in the second file, a first calling relationship of the application programming interface of the first function function; obtaining a first storage address of the first function function copy; obtaining a second storage address of the application programming interface of the first function function; and determining, based on the first calling relationship, the first storage address, and the second storage address, the overall storage of the first function function.

[0008] In one embodiment of the present disclosure, determining the overall storage of the first function function in the first file based on the first calling relationship, the first storage address, and the second storage address includes: using the second storage address of each application programming interface in the first calling relationship to obtain the function body storage of the copy of the first function function; and storing the first storage address and the function body as the overall storage of the first function function.

[0009] In one embodiment of the present disclosure, executing the function corresponding to the first function function includes: executing the first function function stored in the first function function overall storage.

[0010] In an embodiment of the present disclosure, after executing the function corresponding to the first function function, it also includes: releasing the storage space for storing the entire first function function.

[0011] In one embodiment of the present disclosure, the first functional function includes: a constructor, a destructor and a second file.

[0012] In one embodiment of the present disclosure, dynamically loading the first function of the shared object algorithm library in the second storage device to the first storage device also includes: temporarily storing the shared object algorithm library from the second storage device to a third storage device; and when executing the function corresponding to the first function function, loading the first function function from the third storage device to the first storage device.

[0013] The second aspect of the present disclosure proposes a memory management device, which includes: an acquisition module, used to acquire a first file of an application programming interface of a shared object algorithm library from a first storage device, the application programming interface including an interface function called by the shared object algorithm library in the operating system; a dynamic loading module, used to dynamically load a first functional function of the shared object algorithm library in the second storage device to the first storage device based on the first file; and an execution module, used to execute a function corresponding to the first functional function.

[0014] The third aspect embodiment of the present disclosure proposes an electronic device, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute any one of the methods in the first aspect embodiment of the present disclosure.

[0015] The fourth aspect embodiment of the present disclosure proposes a non-transitory computer-readable storage medium storing computer instructions, which are used to enable a computer to execute the method in the first aspect embodiment of the present disclosure.

[0016] The fifth aspect embodiment of the present disclosure proposes a chip, comprising at least one processor and a communication interface; the communication interface is used to receive signals input into the chip or signals output from the chip, the processor communicates with the communication interface and implements any one of the methods in the first aspect embodiment of the present disclosure through logic circuits or execution code instructions.

[0017] In summary, according to the memory management method proposed in the present disclosure, the first file of the application programming interface (Application Programming Interface, API) of the shared object (ShareObject, SO) algorithm library is obtained from the first storage device, and the API includes the interface functions called by the shared object algorithm library in the operating system, and the interface functions of the operating system layer on which the SO algorithm library relies to implement its functions are obtained, which provides a basis for optimizing memory usage. Based on the first file, the first functional function of the shared object algorithm library in the second storage device is dynamically loaded to the first storage device, and the dynamic loading of different functional functions in the shared object algorithm library in the running memory according to the scenario is realized. The function corresponding to the first functional function is executed, the operation of the first functional function is completed, the space occupied by the running memory is reduced, and the amount of running memory occupied by the device during runtime is reduced.

[0018] It is to be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] The drawings herein are incorporated into and constitute a part of the specification, illustrate embodiments consistent with the present disclosure, and together with the description are used to explain the principles of the present disclosure, and do not constitute improper limitations on the present disclosure.

[0020] Figure 1 A schematic diagram of a memory management method in the related art;

[0021] Figure 2 A flowchart of a memory management method according to an embodiment of the present disclosure;

[0022] Figure 3 It is a flowchart of an embodiment of the present disclosure for dynamically loading a first function of a shared object algorithm library in a second storage device to a first storage device based on a first file;

[0023] Figure 4 A flowchart of an embodiment of the present disclosure for obtaining a second file of a first function function of a shared object algorithm library in a second storage device;

[0024] Figure 5 A flowchart of an embodiment of the present disclosure for determining, based on a first function function copy and a second file, that at least one application programming interface of a first function function is stored as a whole in a first function function in a first file;

[0025] Figure 6 A flowchart of an embodiment of the present disclosure for determining the overall storage of a first function in a first file according to a first calling relationship, a first storage address, and a second storage address;

[0026] Figure 7 A flowchart of executing a function corresponding to a first function function according to an embodiment of the present disclosure;

[0027] Figure 8 It is a flow chart after executing the function corresponding to the first function function according to an embodiment of the present disclosure;

[0028] Fig. 9 A schematic diagram of a first functional function structure of an embodiment of the present disclosure;

[0029] Fig.10 A flowchart of dynamically loading a first function of a shared object algorithm library in a second storage device to a first storage device according to an embodiment of the present disclosure;

[0030] Fig.11 A schematic diagram of a memory management method in an embodiment of the present disclosure;

[0031] Fig.12 A schematic diagram of a dynamic loading memory in an embodiment of the present disclosure;

[0032] Fig.13 A schematic diagram of the hardware structure of a dynamic loading memory according to an embodiment of the present disclosure;

[0033] Fig.14 A schematic diagram of a smart watch application memory management according to an embodiment of the present disclosure;

[0034] Fig.15 A schematic diagram of memory usage in different scenarios according to an embodiment of the present disclosure;

[0035] Fig.16 A schematic diagram of the structure of a memory management device according to an embodiment of the present disclosure;

[0036] Fig.17 is a block diagram of an electronic device for implementing the memory management method disclosed herein according to an exemplary embodiment;

[0037] Fig.18 It is a schematic diagram of the structure of the chip of the embodiment of the present disclosure. DETAILED DESCRIPTION

[0038] Embodiments of the present disclosure are described in detail below, and examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals throughout identify the same or similar originals or elements having the same or similar functions. The embodiments described below with reference to the accompanying drawings are exemplary and are intended to be used to explain the present disclosure, and should not be construed as limiting the present disclosure.

[0039] With the development of embedded devices, especially in the field of smart wearable products, the chips used often include SP subsystems, which are mainly responsible for low-power services such as sensor data processing. Wearable products are limited by factors such as size, cost, and power consumption. The SP side often has only a very small running memory, that is, random access memory RAM. For example, smart watches usually have about 1MB of RAM.

[0040] Figure 1 Schematic diagram of memory management method in related art. As shown in the figure, during the SP working process, RAM stores system code, all algorithms from algorithm 1 to algorithm N in the algorithm library, and other storage contents. Since the RAM has a fixed capacity when it leaves the factory, when the SP is working, all algorithms in the entire algorithm library in ROM are loaded into RAM, resulting in most of the RAM capacity being occupied by the algorithm part, and insufficient memory space available for allocation of specific algorithm functions during operation.

[0041] This question involves two types of memory, RAM and ROM. RAM refers to running memory, which can be directly accessed by the CPU and has very fast read and write speeds, but cannot be stored when the power is off. RAM is divided into dynamic DRAM and static RAM. Dynamic RAM has a slower read and write speed and needs to be refreshed regularly, such as the memory stick of a mobile phone or computer; static SRAM has a fast read and write speed, such as the first-level cache and the second-level cache. ROM usually refers to storage memory that can be stored when the power is off, such as SD cards, Flash, NandFlash, NorFlash, and EMMC. Since RAM does not have the ability to store when the power is off, applications are generally stored in ROM, and the access speed of RAM is much higher than that of ROM. The application's files are stored in ROM, and when triggered by the user or called by the system, they are copied from ROM to RAM to run the application.

[0042] The SO algorithm library dynamic loading function in this disclosure is based on the Vela real-time operating system (Real-Time Operating System, RTOS) implementation, similar to the Linux SO dynamic loading function, which is a mechanism that allows programs to load and unload shared libraries (such as .so files) at runtime. This mechanism can improve the flexibility and maintainability of the program, because different programs can share these libraries, and when the library is updated, all programs using these libraries can automatically use the new version of the library. Among them, the dynamic loading of SO is implemented by the following steps:

[0043] 1. Configure the dynamic linker (dynamic loader): In Linux systems, the dynamic linker is usually set to " / lib / ld-linux.so.X" (where X is the version number). You can change the path of the dynamic linker by modifying the / etc / ld.so.conf file.

[0044] 2. Install dynamic libraries: You can install dynamic libraries by static installation or dynamic installation. Static installation is to copy the library files to the / lib directory or / usr / lib directory, while dynamic installation is to use a package manager (such as dpkg) or create a .so file and place it in the correct location (usually / usr / lib or / lib).

[0045] 3. Use dynamic loading in a program: You can use the dlopen function to open a shared library, the dlsym function to get the symbols (such as functions or variables) in the library, and then use the dlclose function to close the shared library. Dynamic loading requires explicit calls to these functions in the program to work. In addition, dynamic loading also involves some memory management and reference counting issues. For example, when a program loads a shared library, the reference count increases, and when it is unloaded, the reference count decreases. When the reference count decreases to 0, the system automatically unloads the shared library.

[0046] Compared with the Linux system's SO dynamic loading, Vela RTOS's SO loading function is a lightweight implementation version.

[0047] As smart wearable products develop with the development of technology and the increasing demand of consumers, the number of sensors carried by wearable devices has increased from only one or two in the beginning to more than ten sensors now. As a result, the types and number of sensor processing algorithms in the VelaRTOS SO algorithm library have increased rapidly, making it difficult for the RAM on the SP side to provide sufficient storage space.

[0048] The present disclosure aims to solve the problem of insufficient running memory space caused by excessive memory usage in embedded devices, by loading, executing and releasing the SO algorithm library in ROM in RAM according to different calling scenarios, so as to reduce the amount of running memory RAM occupied during runtime.

[0049] The method proposed in the present disclosure is applied to memory management tasks, especially to memory management of embedded devices. Its application has a wide range of scenarios and is usually used to implement various health monitoring, sports tracking, smart reminders and other functions. It is widely used in the field of wearable devices, such as smart watches, smart bracelets, smart glasses, virtual reality (VR) or augmented reality (AR) head displays, and children's watches. The application scenarios are not limited in the embodiments of the present disclosure.

[0050] The memory management method provided by the present application is described in detail below with reference to the accompanying drawings.

[0051] Figure 2 FIG. 1 is a flow chart of a memory management method according to an embodiment of the present disclosure. Figure 2 In the illustrated embodiment, the memory management method includes:

[0052] Step 201: Acquire a first file of an application programming interface of a shared object algorithm library from a first storage device, where the application programming interface includes an interface function called by the shared object algorithm library in an operating system.

[0053] In this embodiment, the first storage device is the operating memory RAM of the embedded device, the shared object (SO) algorithm library is a set of algorithm files for implementing various functions in the embedded device, and the application programming interface (API) is an interface function called by the operating system to implement the algorithm function in the SO algorithm library. The first file is a record table of the API interface functions called by the SO algorithm library. The record table records the API of the system used by the SO algorithm library in RAM, or opens a list of recorded APIs, which can be in the form of a text file, a table file, a database file, etc. The file form of the first file is not specifically limited here.

[0054] Step 202: Based on the first file, dynamically load the first function of the shared object algorithm library in the second storage device to the first storage device.

[0055] In this embodiment, the second storage device is a read-only storage memory ROM, and the first function function is an implementation function of any algorithm function in the SO algorithm library. After obtaining the first file of the system API called by the SO algorithm library through the above step 201, after searching the API sequence related to the first function function in the first file, the memory of the API sequence is determined, so as to load the first function function of the SO algorithm library in ROM into RAM.

[0056] Step 203, executing the function corresponding to the first function.

[0057] After loading the memory of the API sequence of the first function function into RAM, the first function function is executed to implement the function corresponding to the function, and it is released after execution, thereby reducing the RAM occupancy, so as to dynamically load the function function of the SO algorithm library used in the next scenario into the memory space.

[0058] In summary, according to the memory management method proposed in the present disclosure, the first file of the API of the SO algorithm library is obtained from the ROM, and the interface function of the operating system layer on which the SO algorithm library relies to implement its functions is obtained, which provides a basis for optimizing memory usage. Based on the first file, the first function function of the shared object algorithm library in the second storage device is dynamically loaded to the first storage device, and the dynamic loading of different function functions in the shared object algorithm library in the running memory according to the scene is realized. The function corresponding to the first function function is executed, and the operation of the first function function is completed, which reduces the space occupied by the running memory and reduces the amount of running memory occupied by the device during operation.

[0059] Figure 3 The present invention is a flowchart of an embodiment of the present invention for dynamically loading a first function of a shared object algorithm library in a second storage device to a first storage device based on a first file. Figure 3 Yes Figure 2Step 202 is further described based on Figure 3 The embodiment shown comprises the following steps:

[0060] Step 301: copy a first function function in a shared object algorithm library in a second storage device to a dynamic loading area in a first storage device to form a first function function copy.

[0061] In this embodiment, the first function copy is a copy of the first function, which is stored in the dynamic loading area of ​​the first storage device RAM. In the scenario where the function corresponding to the first function is used, the first function in the SO algorithm library will be copied from the ROM to the RAM so that the system can execute the function at any time.

[0062] Step 302: Obtain a second file of the first function in a second storage device, wherein the second file includes a function name and a function storage address of the first function.

[0063] In this implementation, the second file is a file in the ROM that stores the name of the first function function in the SO algorithm library and the memory address information. The file format can be a text file, a table file, a database file, etc. The file format of the second file is not specifically limited here. In order to realize the dynamic loading of the first function function, the embedded device needs to determine the name and address of the first function function, or it also needs to determine the name and address of the related function function (other function functions that have a calling relationship with the first function function) in the SO algorithm library called by the first function function.

[0064] Step 303: Determine, based on the first function function copy and the second file, that at least one application programming interface of the first function function is stored as a whole in the first function function in the first file.

[0065] In this embodiment, the first function function is stored as a whole as the entire storage occupied by all APIs in the first function function. The first function function may include only one API, or may include multiple APIs to implement its function, and in practice usually includes many APIs. Based on the first function function copy of the first function function copied to the RAM, and the second file recording the function name, function storage address and call relationship of the first function function in the SO algorithm library, the memory of at least one API used by the first function function in the first file is determined.

[0066] In this embodiment, the first function of the SO algorithm library in the ROM is dynamically loaded into the RAM through the memory information of the API recorded in the first file, and the memory of the API used by the first function function is determined. The dynamic loading of the memory of the first function function is realized. Among them, in order to realize the dynamic loading of the memory of the first function function, it is necessary to determine the detailed information of the first function function of the SO algorithm library in the ROM.

[0067] Figure 4 The present invention is a flowchart of an embodiment of the present invention for obtaining a second file of a first function function of a shared object algorithm library in a second storage device. Figure 4 Yes Figure 3 Step 302 is specifically described, and includes the following steps:

[0068] Step 401: determine a second function called by a first function in a shared object algorithm library.

[0069] In this embodiment, the second function is another function called by the first function in the SO algorithm library. The code of the first function can be used to determine that the second function in the SO algorithm library has been called.

[0070] Step 402: Record the function names and function storage addresses of the first function and the second function in the second file.

[0071] In this embodiment, after the second function function is obtained by sorting the first function function, the function names and function storage addresses of the first function function and the second function function are recorded in the second file.

[0072] Through the method of this embodiment, the calling relationship of the first function in the SO algorithm library and the information of the called second function are determined and recorded in the second file, providing a basis for the dynamic allocation of memory in the RAM, which facilitates the determination of the memory usage of the first function.

[0073] Figure 5 This is a flowchart of an embodiment of the present disclosure, which determines, based on a first function function copy and a second file, how at least one application programming interface of a first function function is stored as a whole in a first function function in a first file. Figure 5 Yes Figure 3 Step 303 is specifically described, based on Figure 5 The embodiment shown comprises the following steps:

[0074] Step 501: Determine a first calling relationship of an application programming interface of a first function function according to a function name of a first function function copy recorded in a second file.

[0075] In this embodiment, the function name of the copy of the first function function is recorded in the second file. The function storage address is found in the second file through the function name, and the first calling relationship is obtained according to the calling relationship of the API called by the code of the first function function during compilation.

[0076] Step 502, obtaining a first storage address of a first functional function copy.

[0077] In this embodiment, the first storage address is the memory address of the copy of the first functional function in the RAM. By obtaining the first storage address, the memory address position of the function corresponding to the first functional function implemented in the current RAM can be determined.

[0078] Step 503: Obtain a second storage address of the application programming interface of the first function.

[0079] In this embodiment, the memory addresses of all APIs called by the first function are taken as the second storage addresses.

[0080] Step 504, determining the overall storage of the first function according to the first calling relationship, the first storage address and the second storage address.

[0081] In this embodiment, the first storage address is used to mark the corresponding memory position of the function implemented by the first function function in the RAM, and the second storage address is used to determine the memory addresses of all APIs called by the first function function. Based on the first storage address, the memory position of the function corresponding to the first function function is marked, and the memory addresses of all APIs in the second storage address are combined using the first calling relationship to obtain the overall storage of the first function function. Among them, the method for determining the overall storage of the first function function can be obtained through the following embodiments.

[0082] Figure 6 This is a flowchart of an embodiment of the present disclosure for determining the overall storage of a first function in a first file according to a first calling relationship, a first storage address, and a second storage address. Figure 6 right Figure 5 The specific description of step 504 is based on the following Figure 6 The embodiment shown comprises the following steps:

[0083] Step 601, using the second storage address of each application programming interface in the first calling relationship to obtain the function body storage of the first function copy.

[0084] In this embodiment, the first calling relationship is the calling relationship between the first function obtained by the SO algorithm library during compilation and the API it calls, which can be determined by the memory address and memory size of each API interface function. The function body memory is the memory used by all APIs called in the first function copy.

[0085] Step 602, storing the first storage address and the function body as a first functional function as a whole.

[0086] In this embodiment, the first storage address is a storage address, and the function body memory is a plurality of memory addresses and their sizes. The first storage address and the function body memory are integrated to store the first functional function as a whole.

[0087] After obtaining the first functional function as a whole storage of the first functional function, the first functional function in the storage may be further executed.

[0088] Figure 7 This is a flowchart of executing the function corresponding to the first functional function according to an embodiment of the present disclosure. Figure 7 Yes Figure 2 Step 203 further illustrates that based on Figure 7 The embodiment shown comprises the following steps:

[0089] Step 701, execute the first function stored in the first function overall storage.

[0090] In this embodiment, according to all the memories used by the first function function in the determined RAM, the function corresponding to the first function function is realized by the device's use of the first function function's overall storage. Thus, the execution of the first function function is completed, and the overall storage of the first function function is used. Instead of loading multiple algorithms in the SO algorithm library into the RAM at the same time. Avoiding the operating speed drop of the embedded device caused by excessive loading of the SO algorithm library in the RAM. After the overall storage of the first function function is used up, it is also necessary to automatically release it.

[0091] Figure 8 This is a flow chart after executing the function corresponding to the first function function according to an embodiment of the present disclosure. Figure 8 Yes Figure 7 After step 701 is executed, the description is based on Figure 8 The embodiment shown comprises the following steps:

[0092] Step 801, releasing the storage space for storing the entire first function.

[0093] In this embodiment, after the first function function uses the first function function as a whole, it is automatically released, thereby providing conditions for loading and running other function functions in the SO algorithm library. The automatic memory release mechanism benefits from the definition of the function function.

[0094] Fig. 9 FIG. 1 is a schematic diagram of a first functional function structure of an embodiment of the present disclosure. Fig. 9 In the illustrated embodiment, the first functional function includes: a constructor, a destructor and a second file.

[0095] In this embodiment, the constructor completes the initialization of the first function function variable; the destructor completes the release of the memory used by the first function function variable; the second file records the function name, function storage address and other information of the first function function and the second function function called by it in the SO algorithm library.

[0096] In one implementation of this embodiment, the first function in the SO algorithm library is defined as three parts: initialization function, destructor, and SO module symbol table. For the initialization function, the prototype of the initialization function of the first function of each SO algorithm library is the same as the following definition.

[0097] int module_initialize(struct mod_info_s*modinfo);

[0098] The destructor needs to be defined according to the following prototype (the function name can be customized from the implementation point of view), which is brought back to the Host OS in RAM by the modinfo instance returned by the initialization function module_initialize(). The destructor of each algorithm needs to be responsible for releasing the Host OS resources of the algorithm, such as dynamically allocated memory.

[0099] int module_uninitialize(void*arg);

[0100] For the second file, use struct symtab_s to define the symbol array that needs to be exported to the Host OS. The following code shows that the SO algorithm library exports 1 function and 1 global variable. The array will be brought back to the Host OS through the modinfo instance returned by the initialization function module_initialize().

[0101] Through the symbol table on the Host OS side, the SO algorithm library can call functions and variables on the Host OS side. During the compilation of the SO algorithm library, these symbols are generated by the script in the following unified symbol information format as the second file of the first function.

[0102] In one implementation of this embodiment, the linking process of the SO algorithm library uses the -r option. During the linking process, the cross-compilation tool chain will store all referenced external symbols in the dynamic link symbol table of SO and the type is UNDEFINE. The process of executing dlopen()->dlbind() on the Host OS side will identify these unlinked symbols for SO. The Host OS can then use the table in the above figure to query the running address of the symbol to be linked, and then make an absolute address correction to the address of the symbol referenced by SO. In the above, the SO algorithm library calls the API interface on the Host OS side, which is the responsibility of SO and the provided script.

[0103] Fig.10The present invention is a flowchart of dynamically loading a first function of a shared object algorithm library in a second storage device to a first storage device according to an embodiment of the present disclosure. Fig.10 Yes Figure 2 Further description of step 202, based on Fig.10 The embodiment shown comprises the following steps:

[0104] Step 1001: temporarily store the shared object algorithm library from the second storage device to the third storage device.

[0105] In this embodiment, the third storage device is a memory with a read / write speed higher than that of the second storage device and lower than that of the first storage device. The third storage device is used as a bridge for data transmission between the first storage device and the second storage device, and the SO algorithm library or part of the algorithms of the SO algorithm library can be temporarily stored in the third storage device.

[0106] In one implementation of this embodiment, the first storage device is a NOR flash memory (NorFlash Memory) or an embedded multimedia card (Embedded Multi Media Card, EMMC), the second storage device is a static random access memory (Static Random Access Memory, SRAM), and the third storage device is a pseudo static random access memory (PseudoStatic Random Access Memory, PSRAM).

[0107] Step 1002: when executing the function corresponding to the first function function, load the first function function from the third storage device to the first storage device.

[0108] In this embodiment, to execute the function corresponding to the first function function, it is necessary to load the first function function from the third storage device into the first storage device.

[0109] In one implementation of this embodiment, the SO algorithm library is stored in the NOR flash memory and has a copy in the PSRAM. When the function of the first function function in the SO algorithm library is used, the first function function is copied from the PSRAM to the SRAM.

[0110] Fig.11 FIG. 1 is a schematic diagram of a memory management method in an embodiment of the present disclosure. Fig.11In the embodiment shown, the storage device on the application processor (AP) side stores a shared object algorithm library consisting of multiple algorithms such as dynamic loading algorithm 1, dynamic loading algorithm 2, and dynamic loading algorithm 3. The Sensorhub sensor hub RAM includes multiple sections such as the system code area, the resident algorithm area, and the algorithm dynamic loading area. When the RAM is powered on, the algorithm dynamic loading area loads the dynamic loading algorithms 1 to 3 in the AP side storage device into the algorithm dynamic loading area respectively, so that the system can execute a single algorithm to realize its corresponding function. Figure 1 Compared with the memory management method in the related art shown in the figure, the occupation of the SP side RAM is reduced.

[0111] In this embodiment, the RAM space is sufficient and partially redundant at the beginning of a chip design, but as the product iteration functions increase, the RAM space is no longer sufficient, and a software solution needs to be designed to solve the problem of insufficient RAM space. The present disclosure dynamically loads the algorithm code into RAM as needed to run, sorts out the usage scenarios of all algorithms, divides the algorithms into two parts: long-term operation and fixed-point operation, sorts out the simultaneous operation and non-simultaneous operation, adjusts the timing of loading each algorithm into RAM, and increases the complexity of the software in exchange for chip memory space.

[0112] Fig.12 Schematic diagram of a dynamic loading memory in an embodiment of the present disclosure. In this embodiment, the SO module (sotest) is stored in the file system of the ROM. The dynamic loading function is realized through the following steps.

[0113] Step ①, register the Host symbol table in the main function of Host OS, and the symbols in the Host symbol table are all APIs or variables called by SO module on Host OS side.

[0114] Step ②, load the SO module from the ROM file system into the Host OS. This process completes the memory allocation and copies each section of the SO module to the RAM memory.

[0115] Link the pointer function b1 from the SO module and determine the call of the pointer function b1 to the function in the host symbol table. This process includes steps 3 and 4, and the pointer function includes the address of the function.

[0116] Step ③, the Host OS side links the pointer function b1, which is obtained by referring to the SO symbol table in the SO module.

[0117] Step ④, the SO module references the function a1 in the Host OS, and the Host OS can find the function storage address of the function a1 through the Host symbol table.

[0118] Step ⑤: Execute the pointer function b1 in the SO module on the Host OS side, that is, call the function a1 to implement its function.

[0119] Step ⑥, uninstall the SO module.

[0120] Fig.13 FIG. 1 is a schematic diagram of a hardware structure of a dynamic loading memory in an embodiment of the present disclosure. In this embodiment, Fig.12 The process of dynamically loading the code corresponding to the function of the embodiment shown in the figure into the memory during compilation is as follows: during compilation, the SPImage is divided into two parts. The first part, namely the Host OS, contains the SP startup code and the algorithm code running in the static scenario. This part is loaded into the SRAM for execution when the AP starts the system; the second part is the algorithm code (SO module) that needs to be loaded and executed by the Runtime during runtime. The SO module of the second part can be temporarily stored in the PSRAM. When the specified algorithm needs to be run, the SO module where the algorithm is located is dynamically loaded from the PSRAM to the SensorHub system, namely, the SRAM for execution.

[0121] There are three options for storing the second part:

[0122] In one implementation of this embodiment, it is stored in NorFlash and directly loaded from NorFlash when used.

[0123] In one implementation of this embodiment, it is stored in EMMC and directly loaded from EMMC when used.

[0124] In one implementation of this embodiment, the data is first read from NorFlash or EMMC to PSRAM for temporary storage, and then loaded from PSRAM when used.

[0125] The principle followed in selecting the storage method is that the comprehensive power consumption of the storage medium reading process is low (power consumption per unit time multiplied by the reading time); NorFlash has lower power consumption per unit time than EMMC and PSRAM, but has a slower reading speed (longer reading time);.

[0126] for Fig.12The code corresponding to the functions shown in the embodiment is run. The first part (Part1) of the basic code of the sensor senosr is loaded by the AP into the SensorHub SRAM and starts running; the AP reads the dynamic loading algorithm 1 (runtime1.so), dynamic loading algorithm 2 (runtime2.so) and dynamic loading algorithm N (runtimeN.so) of the dynamic loading part (Part2) from the EMMC into the PSRAM for temporary storage; during the operation of the SP, when the algorithm of a certain SO module is needed, first copy the specified SO module from the PSRAM to the file system of the PSRAM, then call dlopen() to load the SO module into the SRAM of the SP, and then run the algorithm. The algorithm is removed using dlclose() when it is not needed to run.

[0127] Fig.14 FIG. 1 is a schematic diagram of a smart watch application memory management according to an embodiment of the present disclosure. Fig.14 In the illustrated embodiment, the API of the algorithm code can be used in multiple algorithm projects, and the usage scenarios of different algorithm projects are different, and the timing and duration of keeping it open are also different. Among them, the algorithm code code is divided into two parts, the algorithm code of the sports part, about 360KB; the algorithm code of the health part, about 290KB. The algorithm code in the sports part can be applied to many algorithm projects, such as the function implemented by the 60KB swimming algorithm code is used in a specific scene, the function corresponding to the 15KB pedometer algorithm code will remain open, the function implemented by the 25KB GPS code is used in a specific scene, the function of the 60KB automatic motion recognition algorithm code will remain open, and the function of the 40KB pressure algorithm code will be opened in a specific scene or at a specific time (timing). The size (size) and switch of the algorithm code in other algorithm projects are similar. Similarly, the algorithm code in the health part can also be applied to many algorithm projects, for example, the function implemented by the 50KB heart rate algorithm is always open, and the function implemented by the 50KB blood oxygen algorithm is opened in a specific scene or at a specific time (timing), and the use of the algorithm in the health part in other different algorithm projects is similar.

[0128] Fig.15 FIG. 1 is a schematic diagram of memory usage in different scenarios of an embodiment of the present disclosure. Fig.15In the illustrated embodiment, in the scene defined as basic, algorithms related to heart rate, calories, automatic motion recognition, and wrist lifting are included. When the smart watch is in the basic scene, the memory usage is only 170KB; in the scene defined as sleep, algorithms related to sleep apnea, sleep staging, atrial fibrillation, heart rate, and wrist lifting are included. When the smart watch is in the sleep scene, the memory usage is 260KB; in the scene defined as exercise, algorithms related to mountaineering, GPS, heart rate, calories, and wrist lifting are included, and the memory usage is 230KB; in the scene defined as health, algorithms related to blood sugar, heart rate, and wrist lifting are included. When the smart watch is in the health scene, the memory usage is 240KB. Obviously, the RAM space required for all algorithms is 360KB for the exercise part algorithm plus 290KB for the health part algorithm, that is, the RAM space required for all algorithms is 650KB. However, by dividing the usage scenarios of the algorithms through the memory management method disclosed in the present invention, the maximum RAM required by the algorithm at any time is 260KB, which can reduce the RAM space usage by 60%.

[0129] The memory management method proposed in the present disclosure obtains the first file of the API of the SO algorithm library from the first storage device. The API includes the interface function called by the shared object algorithm library in the operating system, and obtains the interface function of the operating system layer on which the SO algorithm library relies to implement its function, which provides a basis for optimizing memory usage. Based on the first file, the first function function of the shared object algorithm library in the second storage device is dynamically loaded to the first storage device, realizing the dynamic loading of different function functions in the shared object algorithm library in the running memory according to the scenario. The function corresponding to the first function function is executed, the operation of the first function function is completed, the space occupied by the running memory is reduced, and the amount of running memory occupied by the device during operation is reduced.

[0130] Corresponding to the methods provided in the above-mentioned embodiments, the present disclosure also provides a memory management device. Since the device provided in the embodiment of the present disclosure corresponds to the methods provided in the above-mentioned embodiments, the implementation method of the method is also applicable to the device provided in this embodiment and will not be described in detail in this embodiment.

[0131] Fig.16 FIG. 1 is a schematic diagram of a memory management device 1600 according to an embodiment of the present disclosure. The device is applied to embedded devices, such as Fig.16 As shown, the memory management device includes:

[0132] An acquisition module 1610 is used to acquire a first file of an application programming interface of a shared object algorithm library from a first storage device, where the application programming interface includes an interface function called by the shared object algorithm library in an operating system;

[0133] A dynamic loading module 1620, configured to dynamically load the first function of the shared object algorithm library in the second storage device to the first storage device based on the first file;

[0134] The execution module 1630 is used to execute the function corresponding to the first function.

[0135] In some embodiments, the dynamic loading module 1620 is used to:

[0136] Copying the first function function in the shared object algorithm library in the second storage device to the dynamic loading area of ​​the first storage device to form a copy of the first function function;

[0137] Acquire a second file of the first function in a second storage device, wherein the second file includes a function name and a function storage address of the first function;

[0138] According to the first function function copy and the second file, at least one application programming interface of the first function function is determined to be stored in its entirety in the first function function in the first file.

[0139] In some embodiments, the dynamic loading module 1620 obtains the second file of the first function of the shared object algorithm library in the second storage device in the following manner:

[0140] Determine a second function in a shared object algorithm library that is called by the first function;

[0141] The function names and function storage addresses of the first function and the second function are recorded in the second file.

[0142] In some embodiments, the dynamic loading module 1620 determines that at least one application programming interface of the first function function is stored as a whole in the first function function in the first file according to the first function function copy and the second file in the following manner:

[0143] Determine a first calling relationship of an application programming interface of the first function function according to a function name of the first function function copy recorded in the second file;

[0144] Obtaining a first storage address of a first function copy;

[0145] Acquire a second storage address of an application programming interface of the first function;

[0146] The overall storage of the first function is determined according to the first calling relationship, the first storage address and the second storage address.

[0147] In some embodiments, the dynamic loading module 1620 determines the overall storage of the first function in the first file according to the first calling relationship, the first storage address and the second storage address in the following manner:

[0148] Obtaining the function body memory of the first function copy by using the second storage address of each application programming interface in the first calling relationship;

[0149] The first storage address and the function body memory are stored as a whole as the first functional function.

[0150] In some embodiments, the execution module 1630 is used to:

[0151] The first function stored in the first function overall storage is executed.

[0152] In some embodiments, the execution module 1630 is further configured to:

[0153] Release the storage space for the first function as a whole.

[0154] In some embodiments, the first functional function includes: a constructor, a destructor, and a second file.

[0155] In some embodiments, the dynamic loading module 1620 is further used to:

[0156] temporarily storing the shared object algorithm library from the second storage device to the third storage device;

[0157] When the function corresponding to the first function function is executed, the first function function is loaded from the third storage device to the first storage device.

[0158] In summary, through the memory management device, the first file of the application programming interface of the shared object algorithm library is obtained from the first storage device, and the application programming interface includes the interface function called by the shared object algorithm library in the operating system; based on the first file, the first function function of the shared object algorithm library in the second storage device is dynamically loaded to the first storage device; and the function corresponding to the first function function is executed. This device solves the problem of excessive memory usage in embedded devices, resulting in insufficient running memory space, and reduces the amount of running memory occupied during operation.

[0159] In the embodiments provided in the present application, the methods and devices provided in the embodiments of the present application are introduced. In order to implement the functions in the methods provided in the embodiments of the present application, the electronic device may include a hardware structure and a software module, and implement the functions in the form of a hardware structure, a software module, or a hardware structure plus a software module. A function of the functions may be executed in the form of a hardware structure, a software module, or a hardware structure plus a software module.

[0160] Fig.17 is a block diagram of an electronic device 1700 for implementing the above-mentioned memory management method according to an exemplary embodiment.

[0161] For example, the electronic device 1700 may be a mobile phone, a computer, a messaging device, a game console, a tablet device, a medical device, a fitness device, a personal digital assistant, etc.

[0162] Reference Fig.17 , the electronic device 1700 may include one or more of the following components: a processing component 1702 , a memory 1704 , a power component 1706 , a multimedia component 1708 , an audio component 1710 , an input / output (I / O) interface 1712 , a sensor component 1714 , and a communication component 1716 .

[0163] The processing component 1702 generally controls the overall operation of the electronic device 1700, such as operations associated with display, phone calls, data communications, camera operations, and recording operations. The processing component 1702 may include one or more processors 1720 to execute instructions to complete all or part of the steps of the above-mentioned method. In addition, the processing component 1702 may include one or more modules to facilitate the interaction between the processing component 1702 and other components. For example, the processing component 1702 may include a multimedia module to facilitate the interaction between the multimedia component 1708 and the processing component 1702.

[0164] The memory 1704 is configured to store various types of data to support operations on the electronic device 600. Examples of such data include instructions for any application or method operating on the electronic device 1700, contact data, phone book data, messages, pictures, videos, etc. The memory 1704 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk or optical disk.

[0165] The power supply component 1706 provides power to the various components of the electronic device 1700. The power supply component 1706 may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to the electronic device 1700.

[0166] The multimedia component 1708 includes a screen that provides an output interface between the electronic device 1700 and the user. In some embodiments, the screen may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen may be implemented as a touch screen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touch, slide, and gestures on the touch panel. The touch sensor may not only sense the boundaries of the touch or slide action, but also detect the duration and pressure associated with the touch or slide operation. In some embodiments, the multimedia component 1708 includes a front camera and / or a rear camera. When the electronic device 1700 is in an operating mode, such as a shooting mode or a video mode, the front camera and / or the rear camera may receive external multimedia data. Each front camera and rear camera may be a fixed optical lens system or have a focal length and optical zoom capability.

[0167] The audio component 1710 is configured to output and / or input audio signals. For example, the audio component 1710 includes a microphone (MIC), and when the electronic device 1700 is in an operation mode, such as a call mode, a recording mode, and a speech recognition mode, the microphone is configured to receive an external audio signal. The received audio signal can be further stored in the memory 1704 or sent via the communication component 1716. In some embodiments, the audio component 1710 also includes a speaker for outputting audio signals.

[0168] I / O interface 1712 provides an interface between processing component 1702 and peripheral interface modules, such as keyboards, click wheels, buttons, etc. These buttons may include, but are not limited to, a home button, a volume button, a start button, and a lock button.

[0169] The sensor assembly 1714 includes one or more sensors for providing various aspects of status assessment for the electronic device 1700. For example, the sensor assembly 1714 can detect the open / closed state of the electronic device 1700, the relative positioning of components, such as the display and keypad of the electronic device 1700, and the sensor assembly 1714 can also detect the position change of the electronic device 1700 or a component of the electronic device 1700, the presence or absence of user contact with the electronic device 1700, the orientation or acceleration / deceleration of the electronic device 1700, and the temperature change of the electronic device 1700. The sensor assembly 1714 may include a proximity sensor configured to detect the presence of a nearby object without any physical contact. The sensor assembly 1714 may also include an optical sensor, such as a CMOS or CCD image sensor, for use in imaging applications. In some embodiments, the sensor assembly 1714 may also include an accelerometer, a gyroscope sensor, a magnetic sensor, a pressure sensor, or a temperature sensor.

[0170] The communication component 1716 is configured to facilitate wired or wireless communication between the electronic device 1700 and other devices. The electronic device 1700 can access a wireless network based on a communication standard, such as WiFi, 2G or 3G, 4G LTE, 5G NR (NewRadio) or a combination thereof. In an exemplary embodiment, the communication component 1716 receives a broadcast signal or broadcast-related information from an external broadcast management system via a broadcast channel. In an exemplary embodiment, the communication component 1716 also includes a near field communication (NFC) module to facilitate short-range communication. For example, the NFC module can be implemented based on radio frequency identification (RFID) technology, infrared data association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology and other technologies.

[0171] In an exemplary embodiment, the electronic device 1700 may be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to perform the above methods.

[0172] In an exemplary embodiment, a non-transitory computer-readable storage medium including instructions is also provided, such as a memory 1704 including instructions, and the instructions can be executed by a processor 1720 of an electronic device 1700 to perform the above method. For example, the non-transitory computer-readable storage medium can be a ROM, a random access memory (RAM), a CD-ROM, a magnetic tape, a floppy disk, an optical data storage device, etc.

[0173] The embodiments of the present disclosure further provide a non-transitory computer-readable storage medium storing computer instructions, wherein the computer instructions are used to enable a computer to execute the memory management method described in the above embodiments of the present disclosure.

[0174] Fig.18 is a schematic diagram of the structure of a chip 1800 for implementing the above-mentioned memory management method according to an exemplary embodiment.

[0175] Reference Fig.18 , the chip 1800 includes at least one communication interface 1801 and a processor 1802; the communication interface 1801 is used to receive a signal input to the chip 1800 or a signal output from the chip 1800, and the processor 1802 communicates with the communication interface 1801 and implements the memory management method described in the above embodiment through a logic circuit or executing code instructions.

[0176] It should be noted that the terms "first", "second", etc. in the specification and claims of the present disclosure and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchanged where appropriate, so that the embodiments of the present disclosure described herein can be implemented in an order other than those illustrated or described herein. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present disclosure. Instead, they are merely examples of devices and methods consistent with some aspects of the present disclosure as detailed in the appended claims.

[0177] In the description of this specification, the description with reference to the terms "one embodiment", "some embodiments", "illustrative embodiments", "examples", "specific examples" or "some examples" etc. means that the specific features, structures, materials or characteristics described in conjunction with the embodiments or examples are included in at least one embodiment or example of the present disclosure. In this specification, the schematic representations of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described may be combined in any one or more embodiments or examples in a suitable manner.

[0178] Any process or method description in a flowchart or otherwise described herein may be understood to represent a module, segment or portion of code that includes one or more executable instructions for implementing the steps of a specific logical function or process, and the scope of the preferred embodiments of the present disclosure includes alternative implementations in which functions may not be performed in the order shown or discussed, including performing functions in a substantially simultaneous manner or in the reverse order depending on the functions involved, which should be understood by those skilled in the art to which the embodiments of the present disclosure belong.

[0179] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as an ordered list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by an instruction execution system, device or apparatus (such as a computer-based system, a system including a processing module, or other system that can fetch instructions from an instruction execution system, device or apparatus and execute instructions), or in combination with these instruction execution systems, devices or apparatuses. For the purposes of this specification, "computer-readable medium" can be any device that can contain, store, communicate, propagate or transmit a program for use by an instruction execution system, device or apparatus, or in combination with these instruction execution systems, devices or apparatuses. More specific examples of computer-readable media (a non-exhaustive list) include the following: an electrical connection with one or more wires (control method), a portable computer disk box (magnetic device), a random access memory (RAM), a read-only memory (ROM), an erasable and programmable read-only memory (EPROM or flash memory), a fiber optic device, and a portable compact disk read-only memory (CDROM). In addition, the computer-readable medium may even be paper or other suitable medium on which the program is printed, since the program may be obtained electronically, for example, by optically scanning the paper or other medium and then editing, interpreting or otherwise processing in a suitable manner if necessary, and then stored in a computer memory.

[0180] It should be understood that the various parts of the embodiments of the present disclosure can be implemented by hardware, software, firmware or a combination thereof. In the above embodiments, multiple steps or methods can be implemented by software or firmware stored in a memory and executed by a suitable instruction execution system. For example, if implemented by hardware, as in another embodiment, it can be implemented by any one of the following technologies known in the art or their combination: a discrete logic circuit having a logic gate circuit for implementing a logic function for a data signal, a dedicated integrated circuit having a suitable combination of logic gate circuits, a programmable gate array (PGA), a field programmable gate array (FPGA), etc.

[0181] A person skilled in the art may understand that all or part of the steps in the method for implementing the above-mentioned embodiment may be completed by instructing related hardware through a program, and the program may be stored in a computer-readable storage medium, which, when executed, includes one or a combination of the steps of the method embodiment.

[0182] In addition, each functional unit in each embodiment of the present disclosure may be integrated into a processing module, or each unit may exist physically separately, or two or more units may be integrated into one module. The above-mentioned integrated module may be implemented in the form of hardware or in the form of a software functional module. If the integrated module is implemented in the form of a software functional module and sold or used as an independent product, it may also be stored in a computer-readable storage medium. The above-mentioned storage medium may be a read-only memory, a disk or an optical disk, etc.

[0183] Although the embodiments of the present disclosure have been shown and described above, it is to be understood that the above embodiments are exemplary and are not to be construed as limitations of the present disclosure. A person skilled in the art may make changes, modifications, substitutions and variations to the above embodiments within the scope of the present disclosure.

Claims

1. A memory management method, characterized in that: The method comprises: Acquire a first file of an application programming interface of a shared object algorithm library from a first storage device, wherein the application programming interface includes an interface function called by the shared object algorithm library in an operating system; Based on the first file, dynamically load the first function of the shared object algorithm library in the second storage device to the first storage device; Execute the function corresponding to the first function function.

2. The method according to claim 1, characterized in that The dynamically loading the first function of the shared object algorithm library in the second storage device to the first storage device based on the first file includes: Copying the first function function in the shared object algorithm library in the second storage device to the dynamic loading area of ​​the first storage device to form a first function function copy; Acquire a second file of the first function in the second storage device, where the second file includes a function name and a function storage address of the first function; According to the first function function copy and the second file, it is determined that at least one application programming interface of the first function function is stored as a whole in the first function function in the first file.

3. The method according to claim 2, characterized in that The step of obtaining the second file of the first function function of the shared object algorithm library in the second storage device comprises: Determine a second function in the shared object algorithm library that is called by the first function; The function names and function storage addresses of the first function and the second function are recorded in the second file.

4. The method according to claim 2, characterized in that: The step of determining, based on the first function function copy and the second file, that at least one application programming interface of the first function function is stored as a whole in the first function function in the first file comprises: Determine a first calling relationship of an application programming interface of the first function function according to a function name of the first function function copy recorded in the second file; Obtaining a first storage address of the first function copy; Acquire a second storage address of an application programming interface of the first function; The overall storage of the first function is determined according to the first calling relationship, the first storage address and the second storage address.

5. The method according to claim 4, characterized in that The determining, according to the first calling relationship, the first storage address, and the second storage address, that the first function function in the first file is stored as a whole comprises: Obtaining the function body storage of the first function copy by using the second storage address of each application programming interface in the first calling relationship; The first storage address and the function body are stored as the first functional function as a whole.

6. The method according to claim 2, characterized in that The function corresponding to executing the first function includes: Execute the first function stored in the first function overall storage.

7. The method according to claim 2, characterized in that After executing the function corresponding to the first function, the following further comprises: Release the storage space for storing the first function as a whole.

8. The method according to any one of claims 2 to 7, characterized in that: The first functional function includes: a constructor, a destructor and the second file.

9. The method according to any one of claims 1 to 5, characterized in that: The dynamically loading the first function of the shared object algorithm library in the second storage device to the first storage device further comprises: temporarily storing the shared object algorithm library from the second storage device to a third storage device; When executing the function corresponding to the first function function, the first function function is loaded from the third storage device to the first storage device.

10. A memory management device, characterized in that: The device comprises: An acquisition module, configured to acquire a first file of an application programming interface of a shared object algorithm library from a first storage device, wherein the application programming interface includes an interface function called by the shared object algorithm library in an operating system; A dynamic loading module, used for dynamically loading the first function of the shared object algorithm library in the second storage device to the first storage device based on the first file; An execution module is used to execute the function corresponding to the first function.

11. An electronic device, characterized in that: include: at least one processor; as well as a memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the method according to any one of claims 1 to 9.

12. A non-transitory computer-readable storage medium storing computer instructions, characterized in that: The computer instructions are used to cause the computer to execute the method according to any one of claims 1-9.

13. A chip, characterized in that: It includes at least one processor and a communication interface; the communication interface is used to receive a signal input to the chip or a signal output from the chip, and the processor communicates with the communication interface and implements the method according to any one of claims 1-9 through a logic circuit or executing code instructions.

Images