Memory management method and electronic device

Abstract

This application provides a memory management method and electronic device for wearable devices. When a first application in the wearable device starts, multiple memory regions are pre-allocated for the first application based on first configuration information. Each memory region corresponds to a preset capacity, and each memory region contains multiple memory blocks, with the memory capacity of each memory block equal to the preset capacity. During the operation of the first application, when requesting memory, a suitable memory block is matched from the multiple memory regions, and the address information of that memory block is returned. The capacity of the memory block is greater than or equal to the required memory capacity and is in an idle state. Thus, by planning and managing memory in advance, memory address information can be returned extremely quickly when the first application requests memory. Especially in scenarios where device hardware resources are limited and the first application frequently requests memory within a short period, this significantly reduces the time consumed by memory allocation and improves application operating efficiency.

Description

Technical Field

[0001] This application relates to the field of wearable devices, and more particularly to a memory management method and an electronic device. Background Technology

[0002] With the advancement and development of technology, and people's pursuit of convenience and multifunctionality, the applications of wearable devices are becoming increasingly diverse, and their functions are becoming more and more powerful.

[0003] Application operation involves memory management. Currently, due to the limited hardware resources of wearable devices, memory management methods with relatively low resource consumption are generally adopted, such as the optimal fit algorithm. This algorithm uses a linked list to manage memory space. When the application requests memory, it selects the most suitable memory node from the linked list and returns the corresponding memory address.

[0004] However, in wearable devices, when an application frequently requests memory in a short period of time, the process may consume a lot of time, resulting in performance degradation. Summary of the Invention

[0005] This application provides a memory allocation method and electronic device applicable to the field of wearable devices. By pre-allocating memory regions for the application based on configuration information upon application startup, each memory region corresponds to a preset capacity and contains multiple memory blocks, each with a memory capacity equal to the preset capacity. When an application in the wearable device requests memory, it directly searches for a suitable memory block within the memory region and returns the memory address. This method effectively accelerates memory allocation and deallocation, thereby improving application performance.

[0006] In a first aspect, embodiments of this application propose a memory management method applied to wearable devices, the method comprising:

[0007] In response to the startup of the first application, a number of memory regions with preset capacities are allocated to the first application. Each memory region includes multiple memory blocks of the same capacity, and the capacity of the memory blocks in the memory region is equal to the preset capacity.

[0008] In response to a first request from a first application, a first memory region is determined among multiple memory regions, and a first memory block is determined among multiple memory blocks within the first memory region;

[0009] Return the address information of the first memory block to the first application so that the first memory block can be allocated to the first application.

[0010] In this implementation, during the initial operation of the first application, memory requests and releases will continuously occur, potentially multiple times within a short period. This method pre-allocates multiple memory regions with preset capacities, and within each region, sets up multiple memory blocks of the same size as the preset capacity. When the first application requests memory, it selects a memory region from the allocated regions whose preset capacity is greater than or equal to the requested memory capacity as the first memory region. Then, within the first memory region, it further selects a free memory block as the first memory block and returns its memory address to the first application. Thus, even if the first application frequently requests memory within a short period, the pre-allocated memory regions and the high efficiency of the first memory block significantly shorten the time consumed by memory requests, improving the application's operating efficiency.

[0011] In one possible implementation, in response to the startup of the first application, multiple memory regions of preset capacity are allocated to the first application, including:

[0012] In response to the launch of the first application, the first configuration information corresponding to the first application is obtained, which includes the allocation quantity associated with each of the various preset capacities;

[0013] Based on the first configuration information corresponding to the first application, a memory area corresponding to a variety of preset capacities is allocated to the first application, and the number of memory blocks contained in the memory area corresponding to any preset capacity is equal to the allocation quantity.

[0014] This implementation describes how, upon startup of the first application, the wearable device can pre-allocate memory regions for it based on first configuration information. This first configuration information includes the preset capacity of different memory regions and the number of memory blocks associated with each preset capacity. This first configuration information can be obtained by considering the memory allocation and deallocation activities of the first application during its operation. In other words, when pre-allocating memory regions for the first application, the wearable device considers the preset capacity of the requested memory regions and the number of memory blocks within each region. The goal is to ensure that the allocated memory regions can satisfy the memory requests of the first application as much as possible, handling frequent memory requests within a short period, while also minimizing excessive memory resource consumption and waste.

[0015] In one possible implementation, the above method also includes:

[0016] Generate first configuration information based on the memory usage information of the first application during its operation;

[0017] The memory usage information includes multiple memory allocation messages and multiple memory release messages. The memory allocation message includes the capacity of the memory block allocated by the first application and the time of allocation. The memory release message includes the capacity of the memory block released by the first application and the time of release.

[0018] In one possible implementation, first configuration information is generated based on the memory usage information of the first application during runtime, including:

[0019] For any one of the pre-set intervals, based on the memory usage information of the first application during its operation, determine the amount of memory occupied by the first application at multiple moments during its operation. The amount of memory occupied is the number of memory blocks in the first interval whose capacity is occupied by the first application.

[0020] Determine the maximum value among the occupancy quantities at multiple times to obtain the target quantity corresponding to the first interval;

[0021] The first configuration information is generated based on the target quantity corresponding to each of the multiple intervals.

[0022] This implementation describes the process of generating the first configuration information. First, during the execution of the first application, its memory usage information is recorded. This information may include the time of memory allocation and deallocation, as well as the corresponding capacity. Then, a range of memory capacity can be determined based on the actual situation, such as 0B~8B, 8B~16B, 16B~32B, etc., where B represents Byte, and the same applies below. For any given memory capacity range, statistics are performed on the recorded memory usage information; this range can also be called the first interval. First, the memory usage information is filtered based on whether the memory capacity information falls within the first interval, and the corresponding records are extracted. Then, based on the allocation and deallocation at each time point, the memory usage at each time point is statistically analyzed, that is, how many memory blocks within the first interval are still occupied by the first application at each time point. Finally, a maximum value is determined from the memory block usage counts obtained from multiple time points, and this maximum value is used as the target quantity for the first interval.

[0023] This method first combines the memory usage during the actual operation of the first application to obtain initial configuration information, and then allocates multiple memory areas for the first application upon startup based on this initial configuration information. It's understandable that the number and timing of memory allocation and deallocation will not be exactly the same each time the first application runs, but there will be some general similarities. Therefore, the initial configuration information obtained in this way can accurately reflect the peak usage of the first application under different memory capacity ranges during operation, effectively addressing the issue of a large number of memory requests in a short period. Simultaneously, this also significantly improves the hit rate, which refers to the proportion of memory allocation or deallocation requests from the first application that are handled by the memory management module. A higher hit rate results in less overall time spent on memory allocation and deallocation, leading to better application performance.

[0024] In one possible implementation, first configuration information is generated based on the target quantities corresponding to each of the multiple intervals, including:

[0025] For any first interval among multiple intervals, determine the preset capacity corresponding to the first interval, where the maximum value of the first interval is equal to the preset capacity;

[0026] The number of memory blocks associated with the preset capacity corresponding to the first interval is determined to be equal to the target number corresponding to the first interval, so as to generate the first configuration information.

[0027] This implementation describes how the maximum value of the first interval is used as the preset capacity of the corresponding memory region. Simultaneously, the target number of the first interval, obtained based on the memory usage information of the first application, is used as the number of memory blocks in the corresponding memory region. Since the target number is the maximum value of memory blocks occupied at various times, when the first application encounters similar frequent memory requests during subsequent operation, it can generally be ensured that it can obtain sufficient free memory blocks from the pre-allocated memory region. This avoids wasting valuable memory resources in wearable devices and maximizes the chances that the first application can always quickly request free memory.

[0028] In one possible implementation, in response to a first request from a first application, determining a first memory region among multiple memory regions includes:

[0029] In response to a first request from a first application, obtain the first requested capacity included in the first request;

[0030] If the first application capacity is less than a preset threshold, a first memory region is determined among multiple memory regions, wherein the first memory region is the memory region with the smallest difference between the corresponding preset capacity and the first application capacity among the multiple memory regions.

[0031] In one possible implementation, determining the first memory block among multiple memory blocks in the first memory region includes:

[0032] Among the multiple memory blocks in the first memory area, the memory block that is in a free state is identified as the first memory block.

[0033] This implementation describes the process of determining the first memory block from multiple memory regions when the first application requests memory. First, the memory region is determined based on the memory capacity included in the memory request, where the memory request can also be called the first request, and the corresponding memory capacity can be called the first requested capacity. Among the multiple memory regions, the one with a preset capacity greater than or equal to the first requested capacity, and with the smallest difference between the preset capacity and the first requested capacity, is selected as the first memory region. Then, within the first memory region, a memory block that is in a free state is selected as the first memory block, and its memory address is returned.

[0034] This method, combined with the aforementioned first configuration information, enables memory management to proceed as expected throughout the entire operation of the first application. The first configuration information sets different memory capacity ranges and corresponding target quantities. For example, a memory region with a preset capacity of 8B can hold memory objects ranging from 0B to 8B in size; a memory region with a preset capacity of 16B can also hold memory objects ranging from 0B to 16B, but this method will prioritize storing memory objects in the 8B to 16B range. In other words, a 7B object, although it can be stored in either the preset 8B or 16B memory region, will be preferentially stored in the smaller preset capacity region. This is mainly because the first configuration information itself is obtained based on statistical analysis of memory ranges, and memory management in this manner also helps reduce memory fragmentation.

[0035] In one possible implementation, the above method also includes:

[0036] In response to a second request from the first application, the first memory block is marked as free, wherein the first memory block marked as free belongs to the first memory region.

[0037] This implementation demonstrates that the memory area not only requests memory allocation from the first application but also handles memory release requests, which can also be referred to as second requests. When processing second requests, the memory block corresponding to the memory address in the second request is not directly returned to the wearable device's operating system. Instead, it remains in the memory area, and the corresponding memory block is reset to an idle state. This allows memory blocks in the memory area to be reused as needed. For example, when the first application requests and occupies a memory block and then releases it, it can still use that memory block when requesting a similar size memory block later. This improves overall memory utilization efficiency, eliminating the need to prepare new idle memory blocks for each memory request.

[0038] In one possible implementation, the above method also includes:

[0039] In response to the closure of the first application, the memory area allocated to the first application is released.

[0040] This implementation means that the memory allocated to the first application during its startup will be released as soon as the first application finishes running. This avoids consuming valuable memory space in the wearable device and doesn't affect the operation of other applications, while also reducing unnecessary power consumption to some extent.

[0041] In a second aspect, embodiments of this application provide an electronic device, including a processor and a memory, wherein the memory is used to store code instructions and the processor is used to execute the code instructions to perform the methods described in the first aspect or any possible implementation thereof.

[0042] Thirdly, embodiments of this application provide a computer-readable storage medium storing a computer program or instructions that, when executed on a computer, cause the computer to perform the methods described in the first aspect or any possible implementation thereof.

[0043] Fourthly, embodiments of this application provide a computer program product including a computer program, which, when run on a computer, causes the computer to perform the methods described in the first aspect or any possible implementation of the first aspect.

[0044] Fifthly, this application provides a chip or chip system including at least one processor and a communication interface. The communication interface and the at least one processor are interconnected via a circuit. The at least one processor is used to run computer programs or instructions to perform the methods described in the first aspect or any possible implementation thereof. The communication interface in the chip can be an input / output interface, pins, or circuits, etc.

[0045] In one possible implementation, the chip or chip system described above in this application further includes at least one memory storing instructions. The memory can be an internal storage unit of the chip, such as a register or cache, or it can be a storage unit of the chip itself (e.g., read-only memory, random access memory, etc.).

[0046] It should be understood that the second to fifth aspects of this application correspond to the technical solutions of the first aspect of this application, and the beneficial effects achieved by each aspect and the corresponding feasible implementation are similar, and will not be repeated here. Attached Figure Description

[0047] Figure 1 A schematic diagram of memory allocation provided for embodiments of this application;

[0048] Figure 2 A schematic diagram illustrating the implementation of linked list-based memory management in an embodiment of this application;

[0049] Figure 3 A schematic diagram illustrating the memory allocation implementation of the Best Fit algorithm provided in this application embodiment;

[0050] Figure 4 This application provides a schematic diagram of the memory release implementation of the Best Fit algorithm in an embodiment of the present application. Figure 1 ;

[0051] Figure 5 This application provides a schematic diagram of the memory release implementation of the Best Fit algorithm in an embodiment of the present application. Figure 2 ;

[0052] Figure 6 A schematic diagram of a wearable device application interface provided in an embodiment of this application;

[0053] Figure 7 This is a schematic diagram of the JS software architecture provided in the embodiments of this application;

[0054] Figure 8 A flowchart illustrating the operation of the application provided in this embodiment of the application;

[0055] Figure 9A schematic diagram illustrating the implementation of memory allocation during application runtime, provided in an embodiment of this application;

[0056] Figure 10 This is a schematic diagram of the hardware architecture of a wearable device provided in an embodiment of this application;

[0057] Figure 11 This is a schematic diagram of the software architecture of a wearable device provided in an embodiment of this application;

[0058] Figure 12 Flowchart of the memory management method provided in the embodiments of this application Figure 1 ;

[0059] Figure 13 Schematic diagram of memory management architecture provided for embodiments of this application Figure 1 ;

[0060] Figure 14 A schematic diagram illustrating the implementation of memory regions and memory blocks provided in embodiments of this application;

[0061] Figure 15 Flowchart of the memory management method provided in the embodiments of this application Figure 2 ;

[0062] Figure 16 Schematic diagram of memory management architecture provided for embodiments of this application Figure 2 ;

[0063] Figure 17 A schematic diagram illustrating the implementation of a memory management configuration file provided in an embodiment of this application;

[0064] Figure 18 A schematic diagram illustrating the implementation of memory allocation in an embodiment of this application;

[0065] Figure 19 A schematic diagram illustrating the implementation of memory allocation and deallocation in an embodiment of this application;

[0066] Figure 20 Flowchart of the memory management method provided in the embodiments of this application Figure 3 ;

[0067] Figure 21 A schematic diagram of the memory log of the application execution process provided in the embodiments of this application;

[0068] Figure 22 This is a schematic diagram illustrating the implementation of peak memory usage statistics during application operation, provided in an embodiment of this application.

[0069] Figure 23 A schematic diagram illustrating the change in memory usage over time during application operation, provided in an embodiment of this application.

[0070] Figure 24 Flowchart of the memory management method provided in the embodiments of this application Figure 4 ;

[0071] Figure 25 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0072] To facilitate a clear description of the technical solutions in the embodiments of this application, some terms and technologies involved in the embodiments of this application will be briefly introduced below:

[0073] 1. JavaScript

[0074] JavaScript is a widely used high-level programming language, originally designed for web development to enhance user interaction with web pages. With technological advancements, JavaScript has evolved into a full-stack language, widely used not only on the browser side but also on the server side.

[0075] JavaScript offers several advantages for building applications, including: 1. Cross-platform compatibility: JavaScript code can run on various platforms, including operating systems such as Windows, macOS, and Linux, as well as various mobile devices and servers; 2. Dynamic typing: JavaScript is a weakly typed or dynamically typed programming language, eliminating the need for developers to declare data types in advance, making code writing more flexible and faster; 3. Object-oriented programming: It supports a prototype-based object model, simplifying object-oriented programming; 4. Abundant libraries and frameworks: A vast ecosystem of tools that greatly accelerates the development process.

[0076] 2. JerryScript

[0077] JerryScript is a lightweight JavaScript interpreter designed specifically for resource-constrained devices such as wearables, microcontrollers, and other embedded systems. It makes it possible to execute JavaScript code in these environments with limited computing power and memory.

[0078] Its main features include: small size, the compiled JerryScript library is very small; low resource consumption, JerryScript is optimized to use as little CPU and RAM resources as possible; good compatibility, supporting most of the features of the standard specification; and modularity, JerryScript's high modularity allows users to include or exclude specific features as needed to further reduce the size.

[0079] 3. Memory Management

[0080] Memory management refers to how the operating system allocates, manages, and releases memory resources in a computer or other electronic device to ensure that programs can run efficiently and that multiple programs can safely share limited physical memory. Good memory management is crucial for improving system performance because it directly affects multitasking capabilities, response speed, and overall system stability.

[0081] Memory management involves several key concepts, including memory allocation and memory reclamation. For memory allocation, a program needs a certain amount of memory during runtime to store code, data, stack, and other information, requiring the allocation of appropriate memory space. For memory reclamation, when a program no longer needs certain memory blocks, these blocks are reclaimed so that other programs or other parts of the same program can reuse them.

[0082] 4. Memory fragmentation

[0083] Memory fragmentation refers to the phenomenon in memory management where available memory space is divided into many small blocks due to the discontinuous allocation and release of memory by programs. These small blocks are free when viewed individually, but are too small to satisfy new memory allocation requests.

[0084] One common type of memory fragmentation is external fragmentation. External fragmentation occurs at the operating system level in memory management. When multiple programs allocate and release memory blocks of different sizes, small, scattered free areas may be left behind. Although the total free memory may be sufficient, these free blocks are isolated from each other and of inappropriate size, making them unsuitable for merging to satisfy a larger new allocation request. This results in the system being unable to effectively utilize the potentially large amount of total free memory.

[0085] 5. BestFit Algorithm

[0086] Best Fit is a memory allocation algorithm that selects the partition from the available free partitions that is closest to the requested size when allocating memory. Specifically, when a process requests a certain amount of memory, Best Fit searches the list of all free partitions for the partition that best fits the requested size, i.e., the smallest partition that can accommodate the requested size.

[0087] Best Fit aims to minimize external fragmentation because it always tries to reserve large blocks of free space for potentially large-scale memory requests in the future. However, Best Fit may need to traverse the entire list of free partitions to find the most suitable one, which can lead to slower allocation speeds. In other words, Best Fit is a memory allocation algorithm that prioritizes memory efficiency at the expense of some allocation speed. When designing operating systems or memory managers, it is necessary to weigh the pros and cons of different algorithms based on the specific needs of the application.

[0088] 6. Time complexity

[0089] Time complexity is a concept in algorithm analysis used to describe the relationship between the running time of an algorithm and the size of the data. It measures how quickly the time required to execute an algorithm increases as the amount of data increases. Time complexity is usually represented using Big O notation, such as O(n), O(log n), or O(1), representing different types of efficiency and performance characteristics.

[0090] Time complexity is a crucial tool in computer science for analyzing and comparing the efficiency of algorithms. It is not determined by timing, but rather by counting the number of basic operations in the algorithm, such as comparisons and additions, retaining only the portion that becomes dominant as the data size increases. Understanding time complexity helps developers predict the scalability and performance bottlenecks of algorithms and make improvements accordingly.

[0091] 7. Stack space / Heap space

[0092] In computer science, stack space and heap space are two data structures or regions used for memory management, with different characteristics and uses. The stack is a Last-In-First-Out (LIFO) data structure. It is typically used to store local variables, parameters, return addresses, and other information during function calls. When a function is called, a new stack frame is created and pushed onto the top of the stack; when the function finishes execution, this stack frame is popped from the top of the stack. Stack management is handled automatically by the compiler, making its operations highly efficient. The size of the stack is usually predetermined and finite.

[0093] The heap is a dynamically allocated memory region without a fixed structure. Programmers can request and release memory blocks on the heap through interfaces provided by the programming language. Heap memory can be shared between different parts of the program, and its lifecycle is not determined by function calls but can be explicitly controlled by the programmer. Because it requires more management work, heap operations are generally slower than stack operations.

[0094] 8. Other terms

[0095] In the embodiments of this application, terms such as "first" and "second" are used to distinguish identical or similar items with substantially the same function and purpose. For example, "first chip" and "second chip" are used only to distinguish different chips and do not limit their order of execution. Those skilled in the art will understand that terms such as "first" and "second" do not limit the quantity or execution order, and that "first" and "second" do not necessarily imply that they are different.

[0096] It should be noted that, in the embodiments of this application, the terms "exemplary" or "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or design scheme described as "exemplary" or "for example" in this application should not be construed as being more preferred or advantageous than other embodiments or design schemes. Specifically, the use of terms such as "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0097] In this application embodiment, "at least one" refers to one or more, and "more than one" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can represent: a, b, c, ab, a--c, bc, or abc, where a, b, and c can be single or multiple.

[0098] 9. Wearable devices

[0099] In this application, wearable devices refer to electronic devices designed to be worn on the body. They typically integrate microcomputer technology, sensors, and other hardware, enabling them to perform various functions, such as tracking health data, receiving notifications, and playing music. These devices are often paired with smartphones or other computing devices, but can also operate independently.

[0100] Common wearable devices include smartwatches and smart bracelets, which can display the time, receive call and message notifications, and are often equipped with heart rate monitors, GPS, and other functions, and can also track users' exercise and sleep quality.

[0101] Wearable devices also include smart glasses, which may be used for navigation, taking photos or making video calls; ear-worn devices, in addition to basic audio playback, may also have noise reduction and health monitoring functions, such as detecting body temperature.

[0102] Wearable devices can also be clothing and accessories, such as smart garments, shoes, or other accessories with built-in sensors, which can be used to monitor physical condition or improve athletic performance.

[0103] Based on the above introduction, the relevant technologies involved in this application will be further described in detail below.

[0104] Wearable devices are becoming increasingly popular, with smart bracelets and smartwatches being typical examples and gradually becoming an indispensable part of modern life. They not only include traditional timekeeping functions but also bring unprecedented convenience to health management, information access, and daily life and work.

[0105] For example, in health management, wearable devices integrate various sensors to track users' daily activities, such as steps, distance, and calories burned, and can monitor heart rate, sleep patterns, and even stress levels. Through long-term data accumulation and analysis, users can receive personalized health advice and even receive early warnings of potential health risks. When an abnormal heart rhythm is detected, a smartwatch may alert the user to seek medical help. This instant feedback helps people manage their health more proactively.

[0106] In terms of information access, smartwatches offer a fast and convenient channel for receiving notifications. Whether it's text messages, emails, or social media updates, all important information can be seen at a glance on your wrist. Some wearable devices also support voice assistant functions, allowing users to complete tasks such as checking the weather, setting alarms, or navigating routes through simple voice commands, greatly improving efficiency. In addition, payment functions have also been integrated into some devices, allowing users to easily complete transactions without taking out their phones.

[0107] Furthermore, from the perspective of daily life and work, features such as calendar synchronization and reminders make smart bracelets and watches excellent personal assistants. For busy professionals, being able to receive meeting notifications or schedule changes immediately is crucial. As technology advances, wearable devices will continue to evolve, providing users with more diverse and thoughtful services, becoming a bridge connecting the digital world and real life.

[0108] Meanwhile, the widespread adoption of wearable devices such as smartwatches and smart bracelets has spurred a rich ecosystem of third-party applications. These applications greatly expand the functionality of these devices and meet users' diverse daily needs. Below are some examples of different types of third-party applications with brief explanations:

[0109] 1. Health and Fitness Apps: This is a common category of apps, offering everything from basic heart rate monitoring to complex activity tracking services. For example, some apps can record specific data for various sports such as running, cycling, and swimming, and provide personalized training plans based on the user's activity level. There are also dedicated apps that help users monitor their diet, hydration, and mental health.

[0110] 2. Messaging and Communication Apps: These apps enhance the device's information delivery capabilities. Besides basic SMS and phone call notifications, they include notifications for social media updates, emails, and other instant messaging tools. Some advanced apps also support replying to messages directly on the watch or sending commands via voice assistant, ensuring users don't miss any important information.

[0111] 3. Payment and Financial Services: With the rise of mobile payments, many smartwatches now integrate NFC (Near Field Communication) chips, allowing users to make contactless payments using built-in wallet apps. Additionally, there are apps for financial management that can help users track budgets, manage bills, and even invest in their portfolios.

[0112] 4. Travel and Navigation Apps: When exploring or commuting daily, navigation apps provide users with real-time route guidance. They are typically integrated with map services, not only planning the best routes but also providing practical information such as public transportation schedules and walking guides.

[0113] With the support of the aforementioned third-party applications, smartwatches and smart bracelets are not just technological accessories, but have become indispensable multifunctional partners in people's lives, continuously improving our lifestyles.

[0114] As the number of third-party applications on wearable devices increases and their functionality is enhanced, memory management naturally becomes a consideration. The following is a brief introduction to the relevant technologies with reference to the accompanying diagram.

[0115] like Figure 1 As shown, a simple memory allocation architecture is illustrated. Figure 1 There is a memory space, let's assume its size is 128MB. The operating system and various applications in wearable devices all require corresponding memory allocations. The processor interacts with this memory space through registers or caches to ensure the applications can function correctly. As an example, Figure 1In the displayed memory space, the operating system occupies 22MB, process one occupies 10MB, process two occupies 24MB, process three occupies 15MB, and there is an additional 27MB of virtual memory. In addition, there are some free memory areas in the memory space that are not occupied by processes. For example, free memory area one is located between the memory areas of process one and process two, and its size is 12MB; free memory area two is located between the memory areas of process two and process three, and its size is 15MB. Understandably, in some memory management methods, free memory is not always effectively utilized. For example, in some cases, the total capacity of multiple free memory blocks may be sufficient to meet the memory requirements of an application process, but because relatively simple memory management methods do not support combining non-contiguous free memory, these multiple free memory blocks are actually unusable, thus forming what is known as memory fragmentation.

[0116] In wearable devices, due to limited hardware resources, both computing and memory resources are limited and precious. Therefore, the memory management methods used in ordinary home computers or servers are rarely complex. Instead, relatively simple memory management methods with low resource consumption are used.

[0117] like Figure 2 As shown, a linked list-like data structure can be used to manage memory space. Figure 2 The left side is still a memory space, in which multiple application processes are distributed, and there are free memory areas between the application processes. Figure 2 The right side of the list is a singly linked list with a start node and an end node at the beginning and end of the list, respectively. Within the list are multiple nodes, each corresponding to a free memory region. For example, node A corresponds to free memory region one, node B to free memory region two, and node C to free memory region three. Each node can contain information such as the size of its corresponding free memory region and its starting memory address. When a new application process requests memory allocation, it can use this linked list to find a suitable memory space and return the corresponding memory address information.

[0118] In memory management methods based on linked list-like data structures, a commonly used approach is the Best Fit algorithm, also known as the optimal fit algorithm. The following will combine... Figures 3 to 5 A brief explanation of its principles is provided.

[0119] Figure 3 The content shown illustrates how the Best Fit algorithm processes memory allocation instructions. Firstly, as... Figure 3As shown in (a) of the diagram, a doubly linked list data structure is illustrated, with the start and end nodes omitted. The list contains four nodes: node A (3MB memory, address range 278-309), node B (5MB memory, address range 457-510), node C (10MB memory, address range 105-205), and node D (26MB memory, address range 702-963). It's important to understand that the memory sizes and address ranges shown in the diagram are merely examples to illustrate the Best Fit algorithm's process and do not fully correspond to actual device conditions; therefore, they will not be elaborated upon further. It's also worth noting that the nodes in the linked list are sorted according to their corresponding memory capacities, increasing from left to right. In some implementations, the Best Fit algorithm sorts the nodes in the linked list by their corresponding memory capacities to more quickly return the address information of the best-fit memory region when responding to memory request instructions.

[0120] For example, if an application wants to request 8MB of memory, it can start from the left side of the linked list and check each node to see if it meets the required size. Since node A has a memory capacity of 3MB, which is less than 8MB, it does not meet the requirement. The process continues to check the next node... Figure 3 (b). Similarly, we can see Figure 3 Node B in (b) also does not meet the requirement of providing at least 8MB of memory space, so we continue checking the next node, corresponding to... Figure 3 (c). Since the memory capacity corresponding to node C is 10MB, which is greater than the 8MB memory required by the memory request, the address of the memory space corresponding to node C can be returned to the application. In some implementations, instead of directly allocating 10MB of memory space to the application, 8MB is still allocated on demand, and the information of node C is adjusted, including the remaining 2MB of memory capacity and the corresponding memory address information.

[0121] After allocating the memory space for node C to the application, node C can be deleted. At the same time, the linked list needs to adjust and maintain its own data structure. For example... Figure 3 As shown in (d), after node C is removed, node B needs to be connected to node D.

[0122] The above combination Figure 3The Best Fit algorithm briefly explains how it allocates memory. In summary, when faced with a new memory request, it always selects the smallest available memory region that meets the requirement. This reduces memory fragmentation and increases memory allocation efficiency. Furthermore, for ease of understanding, the method described above checks from left to right when responding to memory requests and finding the best-fit node. However, this approach has a relatively low time complexity of O(n), where n can be understood as the number of nodes in the linked list. When the nodes in the linked list are already sorted by memory capacity, a method such as binary search can be used to find the best-fit node, reducing the time complexity to O(log n). As the number of nodes increases, the algorithm's efficiency is significantly improved.

[0123] Understandably, a complete memory management method should not only include memory allocation but also memory release processes. The following section will discuss this in conjunction with... Figure 4 and Figure 5 Please provide an explanation. For example... Figure 4 As shown, suppose there was originally a linked list including node A, with a memory capacity of 3MB and an address range of 278-309; node B, with a memory capacity of 5MB and an address range of 457-510; and node D, with a memory capacity of 26MB and an address range of 702-963. Now, the application process releases a memory region with a capacity of 10MB and an address range of 105-205. When Best Fit adds a new node to the linked list data structure, because it wants to maintain the overall sorted state by node memory capacity, it cannot simply add the new node to the beginning or end of the linked list. Figure 4 In this example, the new node C has a memory capacity of 10MB, so it should be located between nodes B and C when sorted by size. Similarly, this process still requires some computational power, generally with a time complexity of O(logn).

[0124] Furthermore, in more complex cases, the memory release process may be as follows: Figure 5 As shown. In Figure 5In this example, suppose an application releases 10 bytes of memory with address range 356-456. The linked list contains three nodes: node A (3MB, address range 278-309), node B (5MB, address range 457-510), and node D (12MB, address range 702-823). First, the system checks if the released memory space forms a contiguous block with the memory spaces of the nodes in the linked list. For example, if the address range 356-456 of the released memory space forms a contiguous block with the address range 457-510 of node B, then node B's information can be modified without adding a new node. Next, node B's information is modified to have a memory capacity of 15MB and address range 356-510. Finally, since node B's information has changed, the system checks if the overall memory capacity of the linked list remains ordered; therefore, node B's position needs to be adjusted. For example, connect node A and node D, and then connect node D and node B.

[0125] As can be seen from the above explanation, the Best Fit algorithm itself is relatively simple and consumes few resources, so it is often used in some wearable devices.

[0126] However, wearable devices may encounter some issues when running with the memory management methods described above. To better illustrate these issues, we will first explain them using some practical scenarios.

[0127] With the development of technology, wearable devices are becoming increasingly versatile and powerful. For example... Figure 6 As shown, in Figure 6 Image (a) shows an application interface for a smart bracelet, which can include various types of applications, such as SMS, video, communication, and news. Users can interact with and use these applications; for example, clicking on the communication application will display... Figure 6 The image shown in (b). Figure 6 In section (b), there is a contact list, with each row representing a contact friend, including their profile picture and latest information. After viewing the contact list, users can further click on a specific friend to communicate.

[0128] Applications like these can be rapidly developed for wearable devices using JerryScript. JerryScript shares similarities with JavaScript, both being object-oriented high-level programming languages. The JerryScript engine can be seen as a lightweight JavaScript engine, specifically optimized to reduce its system resource requirements, designed for resource-constrained devices such as wearable devices and Internet of Things (IoT) devices. Its goal is to run JavaScript code in a low-power, low-memory environment; JerryScript will be referred to as JS below. This is combined with... Figure 7 A brief description of its architecture in wearable devices.

[0129] like Figure 7 As shown, from top to bottom, the architecture includes the application layer, the JS application framework layer, the OS framework layer, and the OS kernel layer. The application layer contains third-party applications, pre-built applications, etc. The JS application framework, also known as the JS engine, is a software component responsible for interpreting or compiling and executing JS code, including JS data binding, the JS runtime, and the JS framework (C++). The JS runtime provides the necessary runtime environment for the application, and the JS framework contains various open-source or developer-customized libraries for application use. The structural pattern used by the JS engine can be called MVVM, an architectural pattern that separates data and UI through Model, View, and ViewModel, emphasizing data binding and decoupling.

[0130] In this framework, the Model represents the application's data model or business logic, responsible for handling data access, processing, and manipulation. It typically includes data structures, database operations, and network requests. The Model does not directly interact with the UI layer; it only exposes interfaces for the ViewModel layer to call, allowing the ViewModel to obtain the necessary data. The View is the visual part of the user interface, responsible for displaying data and interacting with the user. The ViewModel acts as a bridge between the Model and the View, responsible for retrieving data from the Model and transforming it into a form usable by the View. The ViewModel does not directly manipulate the View; instead, it binds data to the View through a data binding mechanism, ensuring that changes in data are automatically reflected in the View, achieving two-way data binding. Data binding is one of the core features of the MVVM framework. It synchronously connects the data of the View and ViewModel, keeping them synchronized. When data in the ViewModel changes, the data binding automatically updates the parts of the View that are bound to that data, and vice versa.

[0131] For applications written in JavaScript, their execution process can be as follows: Figure 8 As shown, the steps are parsing, compiling, and execution, in sequence. First, when a JS file is loaded, the JS engine parses the code. At this stage, the engine transforms the source code into an Abstract Syntax Tree (AST), a data structure representing the program's structure. If a syntax error is encountered during this process, it immediately throws an error and stops execution. Next is compilation. Modern JS engines can use Just-In-Time (JIT) compilation technology to compile the code while parsing. The JIT compiler converts the AST into bytecode or directly generates machine code. This step can optimize code performance at runtime because the compiler can adjust the compilation method based on actual runtime conditions. Finally, once the code is compiled, the JS engine begins executing it. Because JS is a single-threaded language, it only has one call stack and one task queue by default, so the code is generally executed synchronously in sequence.

[0132] Because JavaScript is an interpreted language, earlier JavaScript engines required interpreting code line by line. This means that in many cases, the exact amount of memory needed couldn't be determined at the start of the application; memory allocation had to be done sequentially as needed during runtime. With technological advancements, modern JavaScript engines have incorporated just-in-time (JIT) compilation and other optimization techniques, meaning JavaScript code doesn't always run in a purely interpreted manner. However, in terms of memory allocation and deallocation efficiency, it still lags significantly behind statically typed languages ​​like C++.

[0133] Therefore, JavaScript applications involve a large amount of memory allocation during runtime. The following section will discuss this further. Figure 9 Let's illustrate with an example. For example... Figure 9As shown, the left side displays a relatively simple JavaScript code snippet. The first line declares an integer variable `num` with the value 42, the second line declares a string variable `str` with the value "Hello", and the third line adds the two variables together to obtain a new string variable `result`. The right side shows the memory allocation involved in the application's execution. The memory space can be divided into stack space and heap space. The stack space can directly store primitive type variables; for example, memory block 901 corresponds to the integer variable `num` declared in the first line. For non-primitive type variables, such as the string variable `str` in the second line, they are generally not directly stored in the stack space. Instead, a pointer is stored in memory block 902, pointing to memory block 904, where the actual value "Hello" is stored. When adding the two variables, since the data type of variable `num` is integer, it needs to be converted to string type first, corresponding to memory block 905 in the heap space, which stores the converted value "42". Finally, "Hello" and "42" are concatenated and stored in memory block 906 to obtain "Hello 42".

[0134] Based on the above scenario description, it's understandable that JavaScript can help developers achieve faster development and iteration of third-party applications, which helps users experience more complete and powerful applications. However, as the examples provided above show, even a short program involves several memory allocations. Therefore, a large application will involve many more memory allocations during runtime. In some cases, applications may even experience a large number of memory allocations in a short period. For example, loading the contact list in a communication application might involve hundreds of memory allocations, and the JavaScript engine's virtual machine scheduling process could involve tens of thousands of memory allocations. Typically, these large memory allocations correspond to relatively small memory spaces, such as a few bytes or tens of bytes. The problem is that if a large number of small memory allocations occur in a short period, it can significantly impact the running efficiency of third-party applications in some wearable devices.

[0135] Understandably, typical home computers or servers employ relatively complex memory management methods, and due to their ample hardware resources, they generally handle large amounts of memory requests within a short period without issues. However, in wearable devices, when using a memory management algorithm similar to the Best Fit algorithm described earlier, memory allocation and deallocation can become extremely time-consuming. For example, each memory allocation requires finding the most suitable node in the linked list corresponding to the Best Fit algorithm. Each memory deallocation may involve inserting new nodes into the linked list, adjusting existing nodes, or reordering node positions. While these memory allocation and deallocation processes theoretically have a time complexity of O(log n), a large number of memory allocation and deallocation requests within a short period can still consume a significant amount of time. Since the normal operation of applications depends on memory allocation and deallocation, when the memory management method struggles to handle a large number of memory requests in a short time, the application will become sluggish, which will obviously affect the user experience.

[0136] Based on this, the embodiments of this application propose the following technical concept: For third-party applications in wearable devices, record their runtime memory allocation and release information. Then, based on this memory usage information, generate configuration information. When the application starts subsequently, pre-allocate multiple memory regions according to this configuration information, each memory region corresponding to a preset capacity. Each memory region contains multiple memory blocks of the same size, and the capacity of each memory block is equal to the aforementioned preset capacity. It can be understood that each memory region can be used to store objects whose memory capacity falls within a certain range. Thus, when responding to a memory allocation request from an application, determine a suitable memory region based on the required allocated memory capacity, and then select an idle memory block within that memory region, returning the corresponding memory address information.

[0137] In this way, the target memory block can be determined very quickly each time a memory request is processed, significantly improving the efficiency of memory allocation. Even if a large number of memory requests occur in a short period of time, they can be handled well, preventing the memory management process from becoming a factor that degrades application performance.

[0138] The technical solution provided in this application can be applied to wearable devices. Below is a brief introduction to wearable devices.

[0139] For example, Figure 10This is a schematic diagram of the hardware structure of a wearable device provided in an embodiment of this application. The wearable device may include a processor 1010, a mobile communication module 1020, a wireless communication module 1030, a display screen 1040, a charging management module 1050, a power management module 1051, a battery 1052, an internal memory 1060, a memory management module 1080, and an audio module 1070, etc.

[0140] It is understood that the structures illustrated in the embodiments of this application do not constitute a specific limitation on the wearable device. In other embodiments of this application, the wearable device may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0141] The processor 1010 may include one or more processing units. These processing units may be independent devices or integrated within one or more processors. The processor 1010 may also include memory for storing instructions and data. In one implementation, for example, the processor 1010 may perform related data processing tasks to implement the embodiments described below.

[0142] The wireless communication function of the wearable device can be implemented through an antenna, a mobile communication module 1020, a wireless communication module 1030, a modem, and a baseband processor. A charging management module 1050 is used to receive charging input from a charger. A power management module 1051 is used to connect to a battery 1052, and the charging management module 1050 is connected to the processor 1010.

[0143] Wearable devices utilize a GPU, a display screen 1040, and an application processor to achieve display functionality. The GPU is a microprocessor for image processing, connecting the display screen 1040 and the application processor. The GPU performs mathematical and geometric calculations and is used for graphics rendering. For example, the interface display implementations described in the above embodiments can be performed by the GPU, the display screen 1040, and the application processor.

[0144] Wearable devices can achieve audio functions through an audio module 1070, speakers, receivers, and application processors, such as music playback and recording.

[0145] In this embodiment, the wearable device may further include a memory management module 1080. The memory management module 1080 can cooperate with the processor 1010 to implement memory management methods within the wearable device. Alternatively, in some implementations, the memory management module 1080 can be part of the processor 1010, or its functions can be implemented by the processor 1010. The memory management module 1080 can work with the operating system to handle memory allocation and release requests from applications within the wearable device.

[0146] For example, the system of the wearable device in this application embodiment can be a lightweight Internet of Things Operating System (LiteOS), or the software system of the wearable device in this application embodiment can also be an Android system. For example, the software architecture of the wearable device can be described using the layered architecture of the LiteOS system as an example. This application embodiment does not specifically limit the software system of the wearable device.

[0147] The software system of wearable devices can adopt a layered architecture, event-driven architecture, microkernel architecture, microservice architecture, or cloud architecture, etc. This application uses a layered architecture system as an example to illustrate the software structure of a wearable device.

[0148] For example, taking a smartwatch as a wearable device, Figure 11 This is a schematic diagram of the software structure of a smartwatch provided in an embodiment of this application.

[0149] like Figure 11 As shown, the layered architecture divides the software into several layers, each with a clear role and function. Layers communicate with each other through software interfaces. In some embodiments, the software architecture of a smartwatch can be divided into five layers, from top to bottom: Application (APP) layer, System Service (Framework) layer, Algorithm layer, Hardware Abstraction layer (HAL), and Kernel layer.

[0150] This application layer can include a series of applications. For example, these applications could include: watch face applications, activity tracking applications, calling applications, secure payment applications, and workout applications.

[0151] The application layer also includes memory management functionality, which can be used to provide third-party applications with the memory management methods described in this application embodiment. For example, in some implementations, third-party applications can apply for and register with this memory management functionality to use the memory management methods provided in this application embodiment during runtime.

[0152] The system service layer provides system support for applications in the application layer. For example, the system service layer may include modules such as step counting, heart rate monitoring, calorie tracking, and heart health services.

[0153] This algorithm layer provides algorithmic support for the system service layer. For example, this algorithm layer may include: heart rate algorithm, dimming algorithm, sleep algorithm, security algorithm, and wearability algorithm, etc.

[0154] In the Hardware Abstraction Layer (HAL), all hardware-related operations required by the upper layers of the system need to call the relevant Application Programming Interface (API) of the HAL. Each hardware device's software architecture layer specifies certain functionalities, which the HAL layer can use to implement.

[0155] This hardware abstraction layer may include interfaces for C++ libraries, storage interfaces, display interfaces, touch interfaces, Bluetooth interfaces, and Global Positioning System (GPS) interfaces.

[0156] The kernel layer can be the layer between hardware and software. The kernel refers to system software that provides functions such as a hardware abstraction layer, disk and file system control, and multitasking. The kernel is the core of an operating system and its most fundamental part. It is responsible for managing system processes, memory, device drivers, file and network systems, and determines the system's performance and stability. It is part of the software that provides secure access to computer hardware for numerous applications; this access is limited, and the kernel determines when a program can operate on a particular part of the hardware and for how long. This kernel layer can be the operating system kernel (OS kernel).

[0157] Based on the above, the methods provided in the embodiments of this application will be described below with reference to the accompanying drawings.

[0158] First, combine Figures 12 to 14 This application describes a memory management method provided in an embodiment. Figure 12 Flowchart of the memory management method provided in the embodiments of this application Figure 1 , Figure 13 Schematic diagram of memory management architecture provided for embodiments of this application Figure 1 , Figure 14 This is a schematic diagram illustrating the implementation of memory regions and memory blocks provided in an embodiment of this application.

[0159] Before explaining the methodology, let's first combine... Figure 13Briefly describe the overall architecture. For example... Figure 13 As shown, a wearable device can include three parts: a third-party application, a memory management module, and memory space. The third-party application can also be referred to as the first application. The first application can interact with the memory management module, and the memory management module can interact with the memory space. Furthermore, after the memory management module completes the memory allocation for the first application, the first application can also operate and process the corresponding memory area.

[0160] The following is for reference. Figure 12 The steps of the memory management method in this article are explained in detail:

[0161] S1201. In response to the startup of the first application, allocate memory areas of various preset capacities to the first application.

[0162] In some implementations, the first application can associate with or register with the memory management module. When the first application starts, it can proactively send information to the memory management module to indicate its startup status. Alternatively, the memory management module can proactively monitor whether the first application has started.

[0163] When the first application starts, the memory management module allocates multiple memory regions in batches. Each memory region has its own preset capacity, such as 8B, 16B, 32B, etc., where B stands for Byte, or one byte. Each memory region contains multiple memory blocks of the same size, and the capacity of each memory block is equal to the preset capacity of the corresponding memory region. Understandably, because multiple memory regions are allocated in batches when the first application starts, the execution efficiency is very fast.

[0164] like Figure 14 The diagram illustrates the structure of a memory region and its memory blocks. In the memory space, the memory region allocated by the memory management module for the first application can be called a pre-defined memory region, which is isolated from other memory spaces to a certain extent. This pre-defined memory region contains multiple memory regions, such as memory region A, memory region B, memory region C, and memory region D. The number and size of memory blocks contained in different memory regions may vary; memory region A contains 8-byte memory blocks, memory region B contains 16-byte memory blocks, and so on. Furthermore, in some implementations, the memory blocks within each memory region are arranged according to a certain pattern, exhibiting good locality, which improves execution efficiency during actual operations.

[0165] S1202, In response to a first request from a first application, a first memory region is determined among multiple memory regions, and a first memory block is determined among multiple memory blocks in the first memory region.

[0166] During the operation of the first application, a large amount of memory allocation is involved in everything from rendering the interface and interacting with the user to processing data. Here, the memory allocation requests of the first application are also referred to as the first request.

[0167] In response to the first request, the memory management module will select one memory region from multiple memory regions as the first memory region. In principle, the default capacity of the first memory region should be greater than or equal to the memory allocation requested in the first request. For example, if the first application needs to allocate 10 bytes of memory, it cannot choose a memory region with a default capacity of 8 bytes; instead, it can choose a memory region with a default capacity of 16 bytes or 32 bytes, otherwise, it will not be able to accommodate the 10-byte object.

[0168] Furthermore, it is necessary to determine the first memory block within the defined first memory region. Understandably, the first memory block needs to be a free memory block, meaning it is not occupied by other objects of the first application, or by other applications.

[0169] It should be noted that the process of determining the first memory region and the first memory block described above is very rapid. Unlike the Best Fit algorithm in wearable devices introduced earlier, which requires maintaining a linked list data structure during memory management, the memory management method provided in this application does not involve any changes in the data structure of the memory region and memory block during memory allocation, making it more efficient. Furthermore, more comparisons regarding memory management efficiency will be detailed below.

[0170] S1203. Return the address information of the first memory block to the first application, so as to allocate the first memory block to the first application.

[0171] Once the first memory block is determined, its address information can be returned to the first application, thus allocating the memory block for the application's first request. In some implementations, the returned address information may include the start and end addresses of the first memory block, or it may include the start address and memory capacity of the first memory block.

[0172] Based on the above description, the memory management method will be further summarized below. In this embodiment, when the first application starts, the memory management module allocates multiple memory regions, each containing multiple memory blocks of the same size, while the size of the memory blocks corresponding to different memory regions is different. When the first application needs to request memory, the memory management module can select a suitable memory region from the multiple memory regions as the first memory region based on the memory capacity in the memory request, and then select an idle memory block in the first memory region as the first memory block. The address information of the first memory block is then returned to the first application, completing the memory request process.

[0173] In this process, multiple memory regions are pre-allocated in batches. When processing memory requests, it's only necessary to determine the memory region based on the request information and then identify free memory blocks within that region. Compared to other memory management methods, such as the Best Fit method mentioned above, this process is more efficient and can handle a large number of memory requests within a short period. Furthermore, the locality of memory due to the fixed-size and regularly arranged memory blocks within the memory regions, along with the invariance of the memory region data structure during memory management, further enhances the efficiency of memory request execution and shortens the process time. This allows for rapid processing even when a large number of memory requests occur in a short period. In addition, setting different preset capacities for different memory regions, rather than a uniform size, allows for reasonable selection based on the actual amount of memory requested, avoiding waste of memory resources.

[0174] Based on the above embodiments, the following will combine... Figures 15 to 19 The memory management method provided in the embodiments of this application will be described in detail. Figure 15 Flowchart of the memory management method provided in the embodiments of this application Figure 2 , Figure 16 Schematic diagram of memory management architecture provided for embodiments of this application Figure 2 , Figure 17 This is a schematic diagram illustrating the implementation of the memory management configuration file provided in an embodiment of this application. Figure 18 This is a schematic diagram illustrating the implementation of memory allocation in an embodiment of this application. Figure 19 This is a schematic diagram illustrating the implementation of memory allocation and deallocation in an embodiment of this application.

[0175] like Figure 16The diagram illustrates the architectural relationships between the modules involved in the embodiments of this application. The first application in the wearable device can interact with the memory management module, which in turn can interact with the operating system of the wearable device and operate and manage the corresponding memory space. Understandably, the operating system of the wearable device can also control and operate the memory space, and after the first application allocates memory, it can also operate on the corresponding memory area. This architectural diagram is only used to illustrate the simple interrelationships between modules, omitting some parts irrelevant to explaining the memory management method provided in the embodiments of this application, and does not represent the complete actual architecture, which will not be elaborated upon here.

[0176] refer to Figure 15 The steps in the process are as follows:

[0177] S1501. In response to the startup of the first application, obtain the first configuration information corresponding to the first application.

[0178] In this embodiment, different applications in the wearable device can correspond to different configuration information. The first configuration information corresponding to the first application can be used to instruct the memory management module how to allocate memory areas for the first application.

[0179] In some implementations, the initial configuration information can be stored as a file in the wearable device's data space. One application corresponds to one file, and the file name can be mapped one-to-one with the application. For example, the file name could be the application name, or it could be an ID bound to the application. This way, when the first application starts, the memory management model can quickly locate the configuration file in the corresponding data space and read the configuration information from it.

[0180] In other implementations, configuration information for multiple applications can be recorded in a single file. For example... Figure 17 As shown, Figure 17 The table displays configuration information, with columns named from left to right as ID, application name, capacity 8B, capacity 16B, and capacity 1024B, etc. ID can be understood as the application's unique identifier. Capacity 8B indicates the number of memory blocks to be allocated in a pre-defined 8B memory area. Similarly, the same applies to capacities of 16B, 1024B, etc. For example, application A with ID 1 needs 100 memory blocks in a pre-defined 8B memory area, 400 memory blocks in a pre-defined 16B memory area, and 50 memory blocks in a pre-defined 1024B memory area. When the first application starts, the memory management module can... Figure 17 In the configuration information table shown, locate the row where the application is located and read the relevant information as the first configuration information.

[0181] For more details on this step, please refer to the previous embodiments. Figure 12 The details of S1201 will not be elaborated here.

[0182] S1502. Based on the first configuration information corresponding to the first application, allocate memory areas with various preset capacities to the first application.

[0183] After obtaining the first configuration information of the first application, the memory management module will allocate the corresponding memory space to the first application based on the relevant information recorded in the first configuration information, including the number of memory areas, the preset capacity of each memory area, and the number of corresponding memory blocks.

[0184] In some implementations, the memory management module allocates memory space for each memory region specified in the first configuration information. First, the memory management module calculates the total amount of memory space that needs to be allocated based on the first configuration information. For example, if the first configuration information specifies a memory region with a pre-defined capacity of 8 bytes and corresponds to 100 memory blocks, then theoretically at least 800 bytes of memory space are needed. Furthermore, it can consider managing additional memory capacity needed for this memory region; assuming each memory block requires an extra 1 byte of memory, then the memory region with a pre-defined capacity of 8 bytes would ultimately require 900 bytes of memory space. Similarly, if the first configuration information specifies a memory region with a pre-defined capacity of 16 bytes and corresponds to 20 memory blocks, then it might ultimately require more than 320 bytes of memory space, such as 340 bytes.

[0185] After determining the required memory space based on the initial configuration information, the memory management module can request the corresponding memory space from the wearable device's operating system. In some implementations, the memory management module can request memory space from the operating system separately for different memory regions, i.e., requesting multiple times to allocate a contiguous block of memory each time. In other implementations, assuming the total memory capacity required across multiple memory regions is relatively small, the module can also request memory space directly from the operating system all at once. These implementations, because they involve batch requesting memory space from the operating system, are very fast.

[0186] S1503. In response to the first request of the first application, obtain the first requested capacity included in the first request.

[0187] In this embodiment, in response to the first memory request from the first application, the memory management module obtains the first requested capacity from the first request. This first requested capacity is the size of the memory space that the first application wants to request. For example, in the first request, the first requested capacity can be 7KB, 23B, etc. The first requested capacity can be used to provide indication information for the subsequent memory management module to determine the target memory area among multiple memory areas.

[0188] The relevant technologies and methods for obtaining the capacity of the first application in the first request are within the scope of existing technology and will not be elaborated here.

[0189] S1504. If the first application capacity is less than or equal to a preset threshold, determine the first memory region among multiple memory regions.

[0190] The preset settings in this step can be understood as the maximum preset capacity corresponding to multiple memory areas, that is, the maximum memory capacity of the memory block in the memory area. For example, considering that the memory space of wearable devices is generally limited, in some implementations, the preset threshold can be set to 1024B, that is, the size of the largest memory block among the multiple memory areas is 1024B.

[0191] If the initial requested size is less than or equal to a preset threshold, then there is an opportunity to allocate a memory block that meets the initial requested size from among the multiple memory regions allocated to the first application. (See reference here.) Figure 18 The corresponding process is explained. Figure 18 In step (a), a suitable memory region is selected from multiple memory regions based on the initial requested capacity, and this region is chosen as the first memory region. Assuming a memory space of 30 bytes is needed, the default capacities of memory regions A and B are 8 bytes and 16 bytes respectively, both less than the requested 30 bytes. Among the memory regions with default capacities greater than 30 bytes, namely memory regions C and D, memory region C's default capacity of 32 bytes is closer to the initial requested capacity of 30 bytes. To avoid wasting memory space, memory region C is chosen as the first memory region.

[0192] The above method can also be described in another way: each memory region corresponds to a preset capacity and a range of acceptable memory requests, with the preset capacity equal to the maximum value within that range. For example, a memory region with a preset capacity of 8 bytes has a memory capacity range of 0-8 bytes. A memory region with a preset capacity of 16 bytes has a memory capacity range of 8-16 bytes, and so on. Thus, when faced with the first request in a first request, the memory region's capacity range can be directly matched.

[0193] In some implementations, other, more complex methods for selecting memory regions can also be used. For example, still using... Figure 18 Taking (a) as an example, each memory region contains information beyond its own preset capacity, including overall status information, namely whether there are any free memory blocks in the current memory region. Assuming that all memory blocks in memory region C are currently occupied, then naturally no further allocation is possible. Therefore, if there are still free memory blocks in memory region D, then memory region D can be considered for allocating the corresponding memory block for the first request, making memory region D the first memory region.

[0194] S1505. Among the multiple memory blocks in the first memory area, determine the memory block that is in an idle state as the first memory block.

[0195] After determining the first memory region, it is also necessary to determine the first memory block. For example... Figure 18 As shown in (b), each memory block in each memory region can be either occupied by an application or free. In memory region C, the first memory block from top to bottom is occupied, and the second memory block is free. Therefore, the second memory block can be used as the first memory block, and the corresponding memory address information can be returned to the first application. The memory address information can include the start address and end address of the memory block.

[0196] Furthermore, after determining the first memory block, the memory management module will return its address information to the first application. For more details, please refer to the previous embodiments. Figure 12 The details of S1203 will not be elaborated here.

[0197] S1506. In response to the second request from the first application, the first memory block is marked as free.

[0198] Understandably, a complete memory management method needs to handle not only memory allocation requests but also memory release requests. During the execution of the first application, when the program corresponding to a certain block of memory finishes running, it needs to be released. The memory management module responds to the memory release request from the first application by processing the corresponding memory block and remarking it as free. This memory release request can also be referred to as the second request.

[0199] In some implementations, the second request includes the address information of the memory block to be freed. For example, it may include the start and end addresses of the memory block, or the start address and size of the memory block. Using the information in the second request, the memory management module can locate the corresponding memory region and its internal memory blocks, and then set them to an idle state.

[0200] The method for determining memory regions and memory blocks described in the embodiments of this application can also be called the Slab algorithm. In the Slab algorithm, a memory region can be called a Slab. To further understand how this method can better handle the large number of memory requests made by applications in wearable devices within a short period of time, the following will be combined with... Figure 19 Let me explain in detail.

[0201] like Figure 19 As shown, in some implementations, the structure of a memory region can be similar to Figure 19 The structure shown in (a) is as follows. On the right side of the memory area in the diagram, there are multiple memory blocks arranged in a regular, closely spaced pattern, belonging to the memory block space within the memory area. On the left side of the memory area, there may also be an information array, the size of which is equal to the number of memory blocks in the memory area. For example, if there are 5 memory blocks in the memory area, then the size of the information array is also 5. The numbers 0-4 at the top of the information array represent the address indices of the information array. The values ​​in the information array are initially also 0-4, consistent with the corresponding address indices. In addition, there is a flag variable, which defaults to 0 and points to the value at address index 0.

[0202] Assuming the first application requests three memory blocks in this memory area in succession, then it can be done as follows: Figure 19 As shown in (b), the address information of memory blocks 1, 2, and 3 in the memory region is returned to the first application. At this time, these three memory blocks are in an occupied state. Simultaneously, the flag variable changes to 3, pointing to the value at address index 3. The above changes can be explained sequentially from a single memory allocation. Initially, all memory blocks in the entire memory region are in a free state. At this time, the flag variable points to the value at address index 0, which is also 0. When responding to a memory allocation and needing to determine the first memory block from this memory region, the memory block corresponding to the value pointed to by the flag variable, i.e., memory block 0, can be used as the first memory block, and its address information is returned. At the same time, the flag variable is incremented by one and shifted right to point to the value at address index 0. When another memory block needs to be allocated, similarly, the memory block corresponding to the value pointed to by the flag variable can be used as the first memory block. Since the value pointed to by the flag variable is 1, the address information of memory block 1 is returned. And so on, to obtain... Figure 19 The situation shown in (b).

[0203] After allocating three memory blocks from this memory area to the first application, assuming the first application now releases memory block 2, then we can see as follows: Figure 19The screen shown in (c) illustrates this. Memory block 1 in the memory area is currently free. The marker variable is decremented by one, moved to the left to point to the value at address index 2, and its value is changed to 1, corresponding to memory block 1. Further, assuming we continue to request memory blocks from this memory area, we can first return the address information of memory block 1 (address index 2, value 1) based on the marker variable. Then, the marker variable is moved to the right, returning the address information of memory block 3 (address index 3, value 3). Finally, the marker variable is moved to the right and points to the value at address index 4.

[0204] Here's a summary of one type of Slab algorithm described above. In this algorithm, a memory region contains not only multiple memory blocks but also information for managing those blocks. For example, the values ​​0-4 in the information array correspond to memory blocks 0-4, respectively. The value pointed to by the marker variable and the value to its right can all be considered currently free memory blocks. Whenever a free memory block needs to be identified from the memory region and its address returned, the memory block corresponding to the value pointed to by the marker variable can be directly designated as the first memory block, and the marker variable can be shifted to the right. When freeing a memory block, the marker variable can be shifted to the left, and the value it points to can be modified to correspond to the value of the freed memory block.

[0205] In other words, when allocating and freeing memory blocks in the memory area, only the marker variable and the information array need to be adjusted each time. Specifically, the marker variable is shifted to the right when memory is allocated, and shifted to the left and its corresponding value is modified when memory is freed, without involving further changes. The data structure of the entire memory area is fixed, and the process of determining the memory block is quick. In terms of time complexity, it can theoretically reach O(1), which is a constant-level complexity. Compared with the O(log n) complexity of the Best Fit algorithm mentioned earlier, since the time for a single memory allocation or release is much shorter, it can also handle the situation of a large number of memory allocations or releases in a short period of time in wearable devices very well.

[0206] S1507. In response to the closure of the first application, the memory area allocated to the first application is released.

[0207] When the first application is closed, it can send corresponding instructions to the memory management module, or the memory management module can directly monitor whether the first application is closed. After the user finishes using the first application and closes it, the memory management module will return the memory space allocated to the wearable device's operating system in S1501 to the operating system, without affecting the normal operation of other applications.

[0208] In summary, the memory management method provided in this application allocates multiple memory regions to the first application based on the first configuration information when the application starts. Each memory region contains multiple memory blocks of the same size. When the first application requests memory, the memory management module determines the memory region within the corresponding capacity range according to the requested memory size, and then further selects a memory block that is in an idle state from that memory region and returns the memory address.

[0209] In this process, firstly, multiple memory regions are allocated based on the first configuration information, which is determined by the memory usage information during the actual operation of the first application. This ensures that the allocated memory regions and their memory blocks can meet the memory requirements of the first application during operation. Therefore, it generally avoids situations where the first application wants to request a memory block with a capacity less than a preset threshold but cannot find a suitable memory block among the multiple memory regions.

[0210] Then, since the memory blocks in the memory area are of the same size and arranged in a regular pattern, and combined with some specific algorithms, such as the memory block determination method mentioned above, the memory block allocation and release process can be completed in O(1) time complexity. This ensures high efficiency in the face of frequent memory allocation and release in wearable devices. In this way, applications in wearable devices will not run slowly or lag due to long memory allocation and release processes, thus significantly improving the user experience.

[0211] Based on the above embodiments, the following will further combine... Figures 20 to 23 Another memory management method provided in the embodiments of this application will be described in detail. Figure 20 Flowchart of the memory management method provided in the embodiments of this application Figure 3 , Figure 21 This is a schematic diagram of the memory log of the application execution process provided in the embodiments of this application. Figure 22 This is a schematic diagram illustrating the implementation of peak memory usage statistics during application operation, as provided in an embodiment of this application. Figure 23 This is a schematic diagram showing the change in memory usage over time during the operation of an application provided in this embodiment.

[0212] The above embodiments mainly described how to construct multiple memory regions and the process of handling memory allocation or release requests from the first application. In this application embodiment, the focus will be on the process of obtaining the first configuration information. The memory management method provided in this application embodiment can be part of or supplement to the above embodiments, or it can be executed independently.

[0213] refer to Figure 20The steps in the process are as follows:

[0214] S2001. Obtain memory usage information of the first application during its operation.

[0215] During the operation of the first application, it will continuously perform multiple memory requests and memory releases. This related information can be called memory usage information, which can be recorded in a log file in some form.

[0216] like Figure 21 The image shows a log file displaying memory usage information. This log file contains multiple fields, including a timestamp, instruction type, parameter 1, and parameter 2. Each record in the log corresponds to a memory allocation or deallocation action of the first application. The timestamp indicates the time of the action, accurate to milliseconds. The instruction type, also known as the request type, indicates whether the action was a memory allocation or deallocation. Parameters 1 and 2 can be further used to describe relevant information about the memory allocation or deallocation. Figure 21 In the command, parameter 1 can be used to represent the size of the memory allocated or freed in the current operation, while parameter 2 can represent the address information of the memory block allocated or freed in the current operation. For example, according to a record in the log file, it can be known that the operation occurred at 08:12:04.050, the instruction type was memory allocation, the allocated memory size was 7B, and the final returned memory block address was address a.

[0217] It should be noted that, Figure 21 The log file shown for representing memory usage information is for example and reference only, and is not limited to these fields and their formats. For example, timestamps can use other formats, and in some implementations, timestamps may not be included; it is sufficient to record in chronological order to clearly indicate the sequence of memory allocation or deallocation. Furthermore, the address information in parameter 2 can also be omitted and is not necessarily required. In short, it is understandable that memory usage information during the execution of the first application can be recorded in some form for subsequent generation of the first configuration information.

[0218] Furthermore, the log file recording the memory usage information of the first application can begin recording from the moment the first application is launched until the first application is closed. Then, when the first application is launched again, the memory management method described in the above embodiments can be executed.

[0219] In some implementations, application memory usage information can be obtained by the wearable device developers. Due to their expertise, the log file only needs to be logged once. In other words, developers pre-record the memory usage of multiple applications, eliminating the need for recording during actual user interaction.

[0220] In some implementations, the memory usage information of an application is recorded only when a user actually uses it. Considering the potential differences in user habits, it's possible to record multiple uses by a user and combine them to represent that user's application memory usage. For example, a user might close an application shortly after opening it; using only a single instance of memory usage information could lead to inaccuracies.

[0221] In other implementations, application memory usage information can be re-recorded periodically or irregularly and updated accordingly. For example, memory usage information for an application can be re-recorded every month. Alternatively, it can be re-recorded the next time the application is used after an update. This allows the application's memory usage information to remain updated over a long period, better adapting to specific applications and users.

[0222] S2002. For any one of the pre-set intervals, based on memory usage information, determine the amount of memory occupied at each of the multiple moments during the operation.

[0223] Once the application's memory usage information is obtained, it can be used to divide the memory into multiple intervals, which are intervals of memory capacity. Examples include 0B-8B, 8B-16B, and 16B-32B. The number of intervals and their specific ranges can be determined based on the actual memory usage information or the hardware conditions of the wearable device. For example, considering that wearable devices have limited memory space and that frequent memory allocation or deallocation is typically concentrated in small memory blocks, a maximum capacity threshold can be pre-defined, such as 1024B, and the range of the intervals cannot exceed this threshold.

[0224] After identifying multiple intervals, it is necessary to statistically analyze the information for each interval in conjunction with memory usage information. For example, for the 8B-16B interval, the records in the memory usage information that correspond to memory block capacities within this interval during memory allocation or deallocation can be separated. Then, the number of memory blocks occupied by the application within the 8B-16B interval can be statistically analyzed at each moment, or at each memory allocation or deallocation action.

[0225] For ease of understanding, here we combine Figure 22To elaborate. For example Figure 22 The table shown is for the first interval, for example, 8B-16B. This table contains multiple fields: time series, timestamp, instruction type, cumulative allocation, cumulative release, and current occupancy. The time series, timestamp, and instruction type can be found in the previous text. Figure 21 The meanings of the related memory values ​​are basically the same, so they will not be repeated here. The "Cumulative Requested Memory" field means how many times memory has been requested in each timing interval within the 8B-16B range as the application runs. Similarly, the "Cumulative Released Memory" field means how many times memory has been released in each timing interval within the 8B-16B range as the application runs. The "Currently Occupied Memory" field means how many memory blocks the application has occupied at various timing intervals within the 8B-16B range. The calculation of the "Currently Occupied Memory" column can be done by starting from the first row and incrementing by one when requesting memory and decrementing by one when releasing memory. Alternatively, it can be obtained directly by subtracting the "Cumulative Released Memory" column value from the "Cumulative Requested Memory" column value.

[0226] S2003. Determine the maximum value among the occupancy quantities corresponding to each of the multiple time points to obtain the target quantity corresponding to the first interval.

[0227] from Figure 22 As can be seen, the values ​​in the "Cumulative Applications" and "Cumulative Releases" columns gradually increase as the application runs, while the value in the "Current Occupied" column fluctuates. Figure 22 In the sequence, the line corresponding to timing 11, which is timestamp 08:12:10.510, with instruction type "allocation", cumulative allocation count of 8, and cumulative release count of 3, shows the current maximum value of 5, which can also be called the peak value of memory block usage.

[0228] This peak value is used as the target number for the first interval, which represents the maximum number of memory blocks that can be occupied within the first interval during the continuous allocation and release of memory by the first application. This target number can be used to instruct the memory management module on how to allocate memory regions and memory blocks within them for the first application.

[0229] To illustrate the relevant content more intuitively, a reference curve is used. Figure 23 .like Figure 23 As shown, the horizontal axis of the coordinate system represents time, which can be understood as the time the application runs after startup. The vertical axis represents the number of memory blocks used, that is, the number of memory blocks occupied by the first application at various times within the first interval. The peak value of the highest point of the entire curve is taken as the target number.

[0230] S2004. For any one of the multiple intervals, determine the preset capacity corresponding to the first interval.

[0231] In this embodiment, the preset capacity of each memory region corresponds one-to-one with the range of memory capacity. For example, if the range of a memory capacity is 0B-8B, then the corresponding preset capacity is 8B, and so on, if the range of a memory capacity is 8B-16B, then the corresponding preset capacity is 16B.

[0232] S2005. Determine the number of memory blocks associated with the preset capacity corresponding to the first interval, which is equal to the target number corresponding to the first interval, so as to generate the first configuration information.

[0233] After the above steps, a configuration information corresponding to the first interval can be obtained, which can be called the first configuration information. The first configuration information includes which preset memory regions need to be allocated when the first application starts, and how many memory blocks need to be set in each memory region. Since the first configuration information is obtained based on the actual memory usage information of the first application during runtime, including the peak number of memory blocks occupied within each memory capacity interval, allocating multiple memory regions to the first application according to this first configuration information can meet the memory usage requirements of the first application during normal operation.

[0234] In some implementations, considering that the frequency of memory allocation and deallocation varies at different stages during the application's operation after startup, the initial configuration information can be adjusted and improved. For example, some applications may only experience a large number of small memory block allocations and deallocations for a short period after startup, while the frequency stabilizes during subsequent continuous operation. Therefore, the initial configuration information can be divided into multiple stages based on the actual application's memory usage information, setting different numbers of memory blocks in different stages. For example, for some applications, the peak number of memory blocks used during the initial startup period can be used as the number of memory blocks in the memory area. After a period of time, the number of memory blocks in the memory area can be reduced in some way. This satisfies the application's memory usage needs, solves the efficiency problem caused by a large number of small memory block allocations and deallocations in a short period, and further conserves valuable memory resources in wearable devices.

[0235] After generating the initial configuration information, it can be stored in the data space of the wearable device in a certain way. For more details, please refer to the previous embodiments. Figure 15 The S1501 will not be discussed further here.

[0236] The following is a summary based on the above explanation: This application embodiment describes how to generate first configuration information that provides instructions for the memory management module to request and allocate multiple memory regions. After the first application starts, its memory usage information is recorded. Then, multiple memory capacity intervals are divided. For each interval, statistics are performed based on the memory usage information to obtain the number of memory blocks occupied by the first application at each time point within that interval. Finally, the maximum value of the number of memory blocks occupied at each time point for each interval is taken as the target number and included in the first configuration information to indicate the number of memory blocks in each memory region.

[0237] The initial configuration information obtained in this way accurately reflects the extreme memory usage requirements of the first application during operation. Allocating corresponding memory regions and blocks to the first application according to this initial configuration information ensures that when the first application needs to request a small memory block, it can always find a suitable free memory block from multiple memory regions and return its memory address. This significantly improves the hit rate and frequency of memory requests. A hit here means that the release of a memory request from the first application can return a memory block address from the multiple memory regions allocated according to the initial configuration information. For example, if 95 out of 100 memory requests from the first application can be allocated a memory block from the aforementioned multiple memory regions, then the hit rate is 95%.

[0238] Understandably, an increase in the number of hits and the hit rate means that more memory allocation and deallocation processes will use the memory management method provided in this application's embodiments. Since the memory management method provided in this application's embodiments has high execution efficiency, it can significantly shorten the overall time spent on memory allocation and deallocation, thereby enhancing the performance of the first application.

[0239] Next, based on the content described in the above embodiments, and in conjunction with... Figure 24 Another memory management method provided in the embodiments of this application will be described in detail. Figure 24 Flowchart of the memory management method provided in the embodiments of this application Figure 4 .

[0240] In this embodiment, the provided memory management method will be described from an overall perspective, with memory allocation and memory release explained separately.

[0241] First refer to Figure 24 The content shown in (a) illustrates the steps involved in allocating memory:

[0242] S2401, request memory.

[0243] This step corresponds to the previous embodiment. Figure 15 In step S1503, the memory management module responds to the memory request from the first application and begins executing the steps related to memory allocation. Further details can be found in the previous embodiments and will not be repeated here.

[0244] S2402. Determine if the application requirements are met. If they are met, proceed to S2403; otherwise, proceed to S2405.

[0245] In this step, after receiving the first application's request for memory, the memory management module will combine the memory capacity information contained in the request with the current status of multiple memory areas to determine whether it can return the address information of the appropriate memory block to the first application.

[0246] In some implementations, the memory capacity in the requested memory is first compared with the preset capacity of the memory area, which is the maximum capacity it can hold for objects. If the requested memory capacity is greater than the preset capacity, it indicates that this memory request is a large memory request, and step S2405 is executed.

[0247] Furthermore, assuming the requested memory capacity is less than or equal to the preset capacity, the corresponding memory region is determined based on the requested memory capacity, which falls within the range of that memory region. Then, it is determined whether there are any free memory blocks in that memory region. If there are no free memory blocks at this time, i.e., they are all occupied, then a jump can be made and S2405 can be executed; otherwise, S2403 can be executed.

[0248] S2403, Select memory block.

[0249] After determining that a memory block can be selected from the memory area, the memory block can be determined in the manner described in the previous embodiment. For related information, please refer to... Figure 15 The contents of S1504 and S1505 will not be repeated here.

[0250] S2404, Return memory address.

[0251] If the memory management module allocates memory blocks for the first application, it can select a free memory block from the memory area and then return the corresponding address information to the first application. Alternatively, if the operating system handles this, it returns the address information of the memory block to the first application. For related details, please refer to the previous embodiments. Figure 12 The S1203 and related technologies will not be elaborated here.

[0252] S2405, the operating system processes it.

[0253] When the memory management module determines that the memory capacity required in a memory request cannot be met in multiple memory areas, it will forward the request to the wearable device's operating system for processing.

[0254] It should be noted that the memory management method proposed in this application embodiment can also be considered as a memory management method based on the wearable device operating system. When the first application starts, the memory management module first requests memory space of the corresponding memory capacity from the wearable device's operating system according to the first configuration information. The memory capacity of this memory space can at least accommodate the aforementioned multiple memory areas and multiple memory blocks therein, and may also include other information used to maintain memory areas and memory blocks. The memory management module may request memory from the operating system multiple times or request memory from the operating system all at once, depending on the situation. After the operating system allocates multiple memory areas corresponding to the first application to the memory management module, this part of the memory space can be regarded as occupied by the memory management module for operation and processing by the memory management module, while the remaining memory space on the wearable device is still managed by the operating system.

[0255] In some implementations, the operating system of the wearable device can adopt, or partially adopt, the Best Fit or similar memory management methods described above. That is, the operating system's memory management method can serve as a fallback or guarantee for the memory management method provided in this application's embodiments. When faced with large memory requests, since they exceed a preset threshold, the operating system can allocate the memory. Such memory requests are generally not too frequent, thus not causing significant performance bottlenecks. Alternatively, in some extreme cases, if the application's memory request frequency increases significantly in a short period during subsequent use, exceeding the quantity specified in the first configuration information, the operating system can also handle the excess memory requests without affecting the normal operation of the application.

[0256] Correspondingly, see the reference below. Figure 24 The content shown in (b) illustrates the steps for releasing memory:

[0257] S2406, Release memory.

[0258] This step can be referenced from the previous embodiments. Figure 15 The details regarding S1506 will not be elaborated upon here.

[0259] S2407. Determine whether it falls within the scope of management.

[0260] Understandably, during the initial application execution, for example, when a function finishes running, some of its associated memory will be released. The memory release request will protect information about the memory block being released, such as its address information. Responding to the memory release request, the memory management module obtains the address information of the memory block and determines whether its address segment belongs to one of the allocated memory regions. If the memory block belongs to one of the allocated memory regions by the memory management module, then step S2408 is executed; otherwise, it indicates that the memory block was allocated by the operating system and should be handled by the operating system, thus stepping S2410.

[0261] S2408, Perform release processing.

[0262] In this step, after determining that the first application falls within the management scope of the memory management module, the corresponding memory block is released. The specific process can be found in the previous embodiment. Figure 15 The details related to S1506 will not be elaborated here.

[0263] S2409, Release complete.

[0264] Finally, the memory block returned by the first application is released. If the memory block belongs to the memory space managed by the memory management module, it will remain. If the memory block was originally allocated to the first application by the operating system, it will be handled according to the operating system of the wearable device.

[0265] S2410, the operating system processes it.

[0266] Similar to S2405 mentioned above, assuming the wearable device's operating system uses Best Fit's memory management method, the linked list can be adjusted according to actual needs when releasing memory. This includes adding new nodes to the linked list or modifying existing node information. For details, please refer to relevant technologies; they will not be elaborated upon here.

[0267] To summarize the above: In this embodiment, the memory allocation and deallocation processes of the first application are described from an overall perspective. During memory allocation, the memory management module first determines whether the memory allocation request can be met. If not, the operating system handles the request. Similarly, during memory deallocation, the memory management module first determines whether the memory block to be released belongs to one of the multiple memory areas allocated to the first application. If not, the operating system handles the deallocation. It is understandable that in cases of a large number of memory allocations or deallocations within a short period, most involve small memory capacities, so the majority are handled by the memory management module, achieving a memory hit. The remaining small portion of memory allocations and deallocations are handled by the operating system. Since this part occurs less frequently, it does not create a significant performance bottleneck. Thus, combining the memory management method proposed in this embodiment with the operating system of the wearable device itself makes the entire method more complete and sufficient to handle various memory allocation or deallocation requests during application operation.

[0268] It should be noted that the module names involved in the embodiments of this application can all be defined as other names, as long as they can achieve the function of each module, and no specific restrictions are placed on the module names.

[0269] The memory management method of the present application embodiments has been described above. The apparatus for executing the above method provided in the present application embodiments is described below. Those skilled in the art will understand that the methods and apparatus can be combined and referenced with each other, and the related apparatus provided in the present application embodiments can execute the steps in the above memory management method.

[0270] The memory management method provided in this application can be applied to electronic devices with information processing functions. Electronic devices include wearable devices; the specific device form of wearable devices can be referred to the above-mentioned descriptions, and will not be repeated here.

[0271] In one implementation, this application provides an electronic device. Figure 25 This is a schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application.

[0272] like Figure 25 As shown, the electronic device 2500 includes: a processor 2501 and a memory 2502; the memory 2502 stores computer execution instructions; the processor 2501 executes the computer execution instructions stored in the memory 2502, causing the electronic device 2500 to perform the above-described method.

[0273] When the memory 2502 is set up independently, the electronic device also includes a bus 2503 for connecting the memory 2502 and the processor 2501.

[0274] This application provides a chip. The chip includes a processor, which is used to call a computer program in memory to execute the technical solutions in the above embodiments. Its implementation principle and technical effects are similar to those in the related embodiments described above, and will not be repeated here.

[0275] This application also provides a computer-readable storage medium. The computer-readable storage medium stores a computer program. When the computer program is executed by a processor, it implements the methods described above. The methods described in the above embodiments can be implemented wholly or partially by software, hardware, firmware, or any combination thereof. If implemented in software, the functionality can be stored as one or more instructions or code on or transmitted over the computer-readable medium. The computer-readable medium can include computer storage media and communication media, and can also include any medium that can transfer a computer program from one place to another. The storage medium can be any target medium accessible by a computer.

[0276] In one possible implementation, a computer-readable medium may include RAM, ROM, compact disc read-only memory (CD-ROM) or other optical disc storage, disk storage or other magnetic storage devices, or any other medium targeted to carry or to store the required program code in the form of instructions or data structures, and accessible by a computer. Furthermore, any connection is appropriately referred to as a computer-readable medium. For example, if software is transmitted from a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave, then coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of medium. As used herein, disks and optical discs include optical discs, laser discs, optical discs, Digital Versatile Discs (DVDs), floppy disks, and Blu-ray discs, where disks typically reproduce data magnetically, while optical discs optically reproduce data using lasers. Combinations of the above should also be included within the scope of computer-readable media.

[0277] This application provides a computer program product, which includes a computer program that, when run, causes a computer to perform the above-described method.

[0278] This application describes embodiments of methods, apparatus (systems), and computer program products according to embodiments of this application with reference to flowchart illustrations and / or block diagrams. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processing unit of a general-purpose computer, special-purpose computer, embedded processor, or other programmable device to produce a machine, such that the instructions, which execute via the processing unit of the computer or other programmable data processing device, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0279] The above specific embodiments further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above are merely specific embodiments of the present invention and are not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made on the basis of the technical solution of the present invention should be included within the scope of protection of the present invention.

Claims

1. A memory management method, characterized in that, Applied to wearable devices, the method includes: In response to the launch of the first application, based on the first application's first configuration information, a memory region corresponding to various preset capacities is allocated to the first application. Each memory region includes a flag variable, an information array, and multiple memory blocks of the same capacity. The capacity of each memory block in the memory region is equal to the preset capacity. The size of the information array is the same as the number of memory blocks. The address index of the information array is used to indicate the corresponding memory block, and the value of the information array is used to indicate the address index of the next free memory block. The flag variable points to the address index of the first available free memory block in the information array. The first configuration information is determined based on the capacity of memory blocks requested by the first application during its operation, the time of request, the capacity of memory blocks released, and the time of release. In response to a first request from the first application, a first memory region is determined among the plurality of memory regions, and a first memory block is determined among the plurality of memory blocks in the first memory region; Return the address information of the first memory block to the first application, so as to allocate the first memory block to the first application; In response to the closure of the first application, the memory area allocated to the first application is released; Wherein, determining the first memory block among the plurality of memory blocks in the first memory region includes: The first available free memory block corresponding to the address index of the information array pointed to by the flag variable is taken as the first memory block, and the flag variable is shifted to the right to point to the address index of the next free memory block in the information array; It also includes: in response to releasing the first memory block, shifting the marker variable to the left, and updating the value of the memory block corresponding to the address index pointed to by the left-shifted marker variable in the information array to the address index corresponding to the first memory block.

2. The method according to claim 1, characterized in that, In response to the launch of the first application, the allocation of multiple preset memory regions, each with its own corresponding capacity, to the first application includes: In response to the launch of the first application, the first configuration information corresponding to the first application is obtained, and the first configuration information includes the allocation quantity associated with each of the multiple preset capacities; Based on the first configuration information corresponding to the first application, memory regions corresponding to the various preset capacities are allocated to the first application, and the number of memory blocks contained in any of the preset capacities is equal to the allocated quantity.

3. The method according to claim 2, characterized in that, The method further includes: The first configuration information is generated based on the memory usage information of the first application during its operation. The memory usage information includes multiple memory request messages and multiple memory release messages. The memory request message includes the capacity of the memory block requested by the first application and the time of the request. The memory release message includes the capacity of the memory block released by the first application and the time of the release.

4. The method according to claim 3, characterized in that, The step of generating the first configuration information based on the memory usage information of the first application during its operation includes: For any one of the pre-set intervals, based on the memory usage information of the first application during its operation, determine the amount of memory occupied by the first application at each of the multiple moments during its operation. The amount of memory occupied is the number of memory blocks whose capacity is occupied by the first application and belongs to the first interval. The maximum value is determined from the occupancy quantities corresponding to each of the multiple time points to obtain the target quantity corresponding to the first interval; The first configuration information is generated based on the target quantity corresponding to each of the multiple intervals.

5. The method according to claim 4, characterized in that, The step of generating the first configuration information based on the target quantity corresponding to each of the multiple intervals includes: For any one of the plurality of intervals, determine the preset capacity corresponding to the first interval, wherein the maximum value of the first interval is equal to the preset capacity; The number of memory blocks associated with the preset capacity corresponding to the first interval is determined to be equal to the target number corresponding to the first interval, so as to generate the first configuration information.

6. The method according to any one of claims 1-5, characterized in that, The step of determining a first memory region among the plurality of memory regions in response to a first request from the first application includes: In response to a first request from the first application, obtain the first requested capacity included in the first request; If the first application capacity is less than or equal to a preset threshold, a first memory region is determined among the plurality of memory regions, wherein the first memory region is the memory region with the smallest difference between the corresponding preset capacity and the first application capacity among the plurality of memory regions.

7. An electronic device, characterized in that, The electronic device includes: one or more processors and memory; The memory is coupled to the one or more processors, the memory being used to store computer program code, the computer program code including computer instructions, the one or more processors invoking the computer instructions to cause the electronic device to perform the method as described in any one of claims 1 to 6.

8. A chip system, characterized in that, The chip system is applied to an electronic device, the chip system including one or more processors, the one or more processors being used to invoke computer instructions to cause the electronic device to perform the method as described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes computer instructions that, when executed on an electronic device, cause the electronic device to perform the method as described in any one of claims 1 to 6.

10. A computer program product, characterized in that, The computer program product includes computer program code that, when run on an electronic device, causes the electronic device to perform the method as described in any one of claims 1 to 6.

Images