A method and system for improving response speed of an intelligent earphone integrating a multifunctional scheduling file

Abstract

The application discloses a kind of intelligent earphone response speed promotion method and system of integrated multifunctional scheduling file.The method comprises the following steps of: constructing intelligent earphone pre-scheduling library, loading shared object file according to priority strategy based on hardware call information in historical operation;When intelligent earphone enters use state, pre-load the file in pre-scheduling library to cache space;When executing function, if cache hits, then directly call corresponding shared object file to drive hardware, otherwise normally load;And according to execution result, pre-scheduling library and cache are updated online.The application significantly reduces the delay of intelligent earphone function call by pre-loading and caching mechanism, and improves response speed and user experience.

Description

Technical Field

[0001] This invention relates to the field of smart wearable devices and human-computer interaction technology, and in particular to a method and system for improving the response speed of smart headphones that integrates multi-functional scheduling files. Background Technology

[0002] As a core category of wearable devices, smart headphones play an increasingly important role in smart devices. In particular, the emergence of large language models has enabled a qualitative leap in the technology of voice control of smart devices, greatly enhancing the status of smart headphones as the core device of voice assistants among all smart devices. Users can control mobile terminals to perform various operations solely through smart headphones. Their functions are becoming increasingly rich, covering audio playback, environmental noise reduction, ambient sound pass-through, voice assistant, making and hanging up calls, intelligent navigation, real-time translation, and health monitoring, among others. Because of this, users have extremely high requirements for the interactive response speed of smart headphones, expecting them to achieve a seamless experience of "touch and play, speak and respond".

[0003] Research has revealed that existing response speed optimization methods are typically applied in application scenarios, including preloading related files, such as providing general system-level caching and preloading mechanisms (e.g., Zygote preloading, file system caching). However, these mechanisms are general and not optimized for a specific peripheral like smart headphones. Furthermore, such optimization methods are usually based on file popularity to determine whether a target file is suitable for preloading. In the context of smart headphone technology, the above methods are not applicable. First, smart headphones are hardware devices. As the core of a mobile assistant, their function is to call other software and hardware programs to execute corresponding functions. Currently, the interaction efficiency between smart headphones and mobile terminals is limited by their system architecture, and they differ fundamentally from simple applications in function and logic. How to optimize the response speed specifically for smart headphones needs further research. Second, the greatest potential latency in the process of smart headphones controlling mobile phones lies in the process of calling various hardware devices. The process of calling hardware devices involves a series of steps from top to bottom, including the application layer, framework layer, HAL layer, and hardware layer. How to optimize the response speed of the process of calling various hardware devices needs further research. Third, the preloading methods for different files vary significantly. Which preloading mechanism to adopt for the smart headphone technology scenario needs further research.

[0004] Therefore, there is an urgent need for a response speed optimization solution that can be deeply integrated into the usage scenarios of smart headphones, so as to completely eliminate response latency and improve user experience.

[0005] The information disclosed in the background section of this invention is intended only to enhance the understanding of the general background of this invention, and should not be construed as an admission or in any way implying that such information constitutes prior art known to those skilled in the art. Summary of the Invention

[0006] This invention proposes a method and system for improving the response speed of smart headphones by integrating multi-functional scheduling files. It can significantly reduce the latency of smart headphone function calls through preloading and intelligent caching mechanisms.

[0007] In a first aspect, the present invention provides a method for improving the response speed of a smart headset by integrating a multi-functional scheduling file, the method comprising the following steps:

[0008] S100, a smart earphone pre-scheduling library is built in the system; the system monitors and extracts hardware call information in the historical operation of the smart earphone, and adds the file identifier of the shared object file corresponding to the hardware call information that meets the first preset condition to the pre-scheduling library according to the priority scheduling strategy;

[0009] S110, in response to the smart earphone entering the usage state, constructs a scheduling file cache space, traverses the smart earphone pre-scheduling library, and if the shared object file corresponding to the file identifier is not loaded, it is preloaded into the scheduling file cache space;

[0010] S120, in response to the smart earphone executing a first function, the first function corresponding to a hardware function call, if the shared object file corresponding to the hardware call information of the hardware function call is hit in the scheduling file cache space, then the shared object file in the scheduling file cache space is directly called to drive the hardware module corresponding to the first function to work; otherwise, the shared object file corresponding to the hardware call information of the hardware function call is normally loaded from the file system to the system memory, and the loaded shared object file is called; the hardware module corresponding to the first function is driven to perform work based on the called shared object file.

[0011] S130, based on the hardware call information corresponding to the first function being executed, perform an online update operation of the pre-scheduled library based on the priority scheduling strategy; if the online update operation causes a change in the pre-scheduled library, then update the scheduling file cache space accordingly.

[0012] Preferably, step S100 includes: (1) in each smart earphone charging cycle, extracting hardware call information in the smart earphone operation, determining the call frequency and call duration of each hardware function call, and determining the call value based on the weighted sum of the call frequency and call duration; in a preset N charging cycle, sorting the hardware call types based on the average call value; (2) selecting a preset number of hardware call types that are ranked first as target hardware call types; for each target hardware call type, determining the shared object file combination involved in each hardware call of the target hardware call type; (3) counting the loading frequency of each shared object file in the shared object file combination and sorting it, and determining the file identifier of the shared object file corresponding to the hardware call information that meets the first preset condition, as well as the priority of the shared object file, based on the sorting result; (4) updating the pre-scheduled library according to the priority scheduling strategy.

[0013] Preferably, the first function in step S120 is the target hardware call type determined in step (2); or it is a type other than the target hardware call type determined in step (2). When it is a type other than the target hardware call type determined in step (2), the shared object file is a composite function library file that provides upward support or a service library file that provides general functions.

[0014] Preferably, the instruction for the first function is passed to the system service, and a proxy service module PreloadManagerService is pre-embedded in the system service. This proxy service module maintains the mapping table of the "scheduling file cache space" constructed in step S110, and provides at least the judgment interface isLibraryPreloaded(String) to the outside world. It is used to determine whether the target shared object file is in the scheduling file cache space. If it is, the shared object file handle is directly obtained; if not, it falls back to the original loading path. The judgment only includes one Binder IPC call and one mapping query.

[0015] Preferably, if a change is detected in the pre-scheduled library, and the scheduling file cache space is not full, a new change entry is added to the scheduling file cache space according to the change, instead of directly replacing the change entry, to prevent unpredictable problems caused by forced deletion. If the scheduling file cache space is full, the lowest priority shared object file in the scheduling file cache space is replaced with a new shared object file, and a low-priority shared object file unloading operation is performed. The low-priority shared object file unloading operation refers to mapping the low-priority shared object file from the scheduling file cache space to the regular system memory space and downgrading it to prevent unpredictable problems caused by forced deletion. After the low-priority shared object file is mapped to the regular system memory space, it is managed based on the system's built-in memory management strategy.

[0016] Secondly, the present invention provides a smart headphone response speed improvement system that integrates a multi-functional scheduling file, comprising:

[0017] The first building module is configured to build a smart earphone pre-scheduling library in the system; the system monitors and extracts hardware call information from the historical operations of the smart earphone, and adds the file identifiers of the shared object files corresponding to the hardware call information that meets the first preset conditions to the pre-scheduling library according to the priority scheduling strategy;

[0018] The second building module is configured to respond to the smart earphone entering the usage state by building a scheduling file cache space, traversing the smart earphone pre-schedule library, and if the shared object file corresponding to the file identifier is not loaded, it is preloaded into the scheduling file cache space.

[0019] The hardware function call module is configured to respond to the smart earphone executing a first function, which corresponds to a hardware function call. If the shared object file corresponding to the hardware call information of the hardware function call is hit in the scheduling file cache space, the shared object file in the scheduling file cache space is directly called to drive the hardware module corresponding to the first function to work; otherwise, the shared object file corresponding to the hardware call information of the hardware function call is normally loaded from the file system to the system memory, and the loaded shared object file is called; the hardware module corresponding to the first function is driven to perform work based on the called shared object file.

[0020] The online update module is configured to perform an online update operation on the pre-scheduled library based on the hardware call information corresponding to the first function being executed, according to the priority scheduling strategy; if the online update operation results in a change to the pre-scheduled library, the corresponding scheduling file cache space is updated.

[0021] Preferably, the first construction module specifically includes: a call information extraction unit, a call value calculation unit, a sorting unit, a target type determination unit, a file combination analysis unit, a priority determination unit, and a library update unit.

[0022] Preferably, the first function processed by the hardware function call module is the target hardware call type determined by the target type determination unit; or it is a type other than the target hardware call type.

[0023] Preferably, the system further includes: a proxy service module, which is embedded in the system service, configured to maintain a mapping table for the scheduling file cache space, and provides at least an external judgment interface isLibraryPreloaded(String).

[0024] Preferably, the online update module is specifically configured to execute corresponding addition, replacement, and degradation processing strategies based on changes in the pre-scheduled library and the capacity of the scheduling file cache space.

[0025] The above solution achieves at least the following technical effects: (1) Significantly reduces response latency and improves user experience: By constructing a pre-scheduled library and a scheduling file cache space, frequently used shared object files are pre-loaded into the cache. When a user triggers a function, if the cache hits, it can be called directly, avoiding the traditional time-consuming process of dynamically loading library files from the file system, thereby significantly reducing the response latency of smart headphone function execution and improving the smoothness of operation and user experience. (2) Realizes intelligent preloading and resource optimization management: Based on historical hardware call information (such as call frequency and duration), the priority strategy of the pre-scheduled library is dynamically constructed and updated to accurately predict and preload the most likely resources to be called. By designing a robust cache update and degradation mechanism (such as degradation processing when adding change items or replacing low-priority files instead of direct deletion), the system crash or functional abnormality that may be caused by the forced uninstallation or replacement of library files is effectively avoided, ensuring the stability and reliability of smart headphones during long-term operation and dynamic updates. Attached Figure Description

[0026] The above and other objects, features and advantages of the present invention will become more apparent from the more detailed description of exemplary embodiments of the invention in conjunction with the accompanying drawings.

[0027] Figure 1 This is a flowchart of a method for improving the response speed of smart headphones by integrating multi-functional scheduling files according to an embodiment of the present invention.

[0028] Figure 2 This is a structural block diagram of an intelligent headphone response speed improvement system that integrates multi-functional scheduling files according to an embodiment of the present invention. Detailed Implementation

[0029] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0030] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a particular order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented, for example, in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “corresponding to,” and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0031] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0032] Figure 1 The diagram illustrates the four main steps of the core method of this invention: pre-scheduled library construction (S100), cache preloading (S110), function execution and scheduling (S120), and online update (S130). The diagram clearly depicts the complete process from system initialization and resource preloading to function execution and adaptive optimization.

[0033] Firstly, such as Figure 1 As shown, this disclosure provides a method and system for improving the response speed of smart headphones by integrating multi-functional scheduling files. The method includes the following steps:

[0034] S100, a smart earphone pre-scheduling library is built in the system; the system monitors and extracts hardware call information in the historical operation of the smart earphone, and adds the file identifier of the shared object file corresponding to the hardware call information that meets the first preset condition to the pre-scheduling library according to the priority scheduling strategy;

[0035] Within the Android system's framework and kernel driver layers, there exists a Hardware Abstraction Layer (HAL) that provides a standard interface for calling hardware drivers whose specific implementations are hidden. This HAL provides a standard interface to the framework layer. When the system needs to access certain hardware, such as requesting to play music, a system service (e.g., AudioFlinger) receives the request, searches for and retrieves the corresponding HAL service through the service manager. The HAL service is implemented using shared object files (SOs). If the corresponding shared object file for the found HAL hardware abstraction layer is not loaded, the system dynamically loads it into the memory space of the HAL service process. Typically, shared object files are loaded on demand, only when needed. For smart headsets, the loading pattern of shared object files is dynamically fixed. For example, if a user is accustomed to using smart headsets to answer calls, then when the smart headset is connected to a mobile terminal, the system is highly likely to call the shared object files related to call-related hardware, such as libril.so (there may be multiple files). Similarly, if a user is accustomed to using smart headsets to play music, then when the smart headset is connected to a mobile terminal, the system is highly likely to call the shared object files related to audio playback hardware (such as decoding, mixing, and drivers). Therefore, in this embodiment of the application, during the initialization phase, a smart headphone pre-scheduling library is built in the system. This pre-scheduling library stores file identifiers of hardware SO library files that are called in accordance with user habits.

[0036] In a preferred embodiment, the size of the pre-scheduled library is set to be adapted to the parameters of the mobile terminal device, and the data in the pre-scheduled library is scheduled and managed according to the priority scheduling strategy. The steps of adding the file identifier to the pre-scheduled library according to the priority scheduling strategy are as follows: (1) In each smart earphone charging cycle (the time period between the end of the last charging and the current charging), extract the hardware call information in the smart earphone operation, determine the call frequency and call duration of each hardware function call, and determine the call value based on the weighted sum of the call frequency and call duration; in the preset N charging cycles, sort the hardware call types based on the average call value; (2) Select the preset number of hardware call types that are ranked first as the target hardware call types; for each target hardware call type, determine the shared object file combination involved in each hardware call of the target hardware call type; (3) Count the loading frequency of each shared object file in the shared object file combination and sort it, and determine the file identifier of the shared object file corresponding to the hardware call information that meets the first preset condition, as well as the priority of the shared object file, based on the sorting result; (4) Update the pre-scheduled library according to the priority scheduling strategy.

[0037] In the above embodiments, step (1) uses the "charging cycle" as a habit learning window, assuming that a user's charging cycle represents a complete usage scenario (such as "a day's commute" or "a long work session"), which can better capture the user's daily habits of using smart headphones. At the same time, the concept of "call value" is introduced: it not only considers the number of calls, but also the duration of each call. For example, a user may only make one call a day through smart headphones (low frequency), but the call duration is relatively long. Through weighted summation, the "importance" or "benefit potential" of the call function can be displayed. For steps (2) and (3), a hardware function call may only involve one core shared object file, but usually, it will depend on multiple non-core shared object files at the same time. These non-core shared object files are, for example, composite function libraries or general service libraries, which provide dependency or support services to the upper level. Moreover, a hardware function call may involve the joint processing of multiple non-core hardware. At this time, a hardware function call will load multiple shared object files for joint processing. Therefore, in step (2), the hardware call types are sorted first, and then in step (3), the loading frequency of the shared object files involved in each hardware call type with the highest hardware call type is sorted. Through the above double sorting steps, the shared object files are deduplicated and integrated, realizing the mapping from user habits (functional level) to file-level sorting, and determining the global priority of the shared object files. For step (4), the final result calculated in the previous steps (e.g., a list containing SO file paths and priorities) is written into the pre-scheduled library. Preferably, the pre-scheduled library can be a configuration file or a data table. In order to improve the reading speed, the pre-scheduled library is first loaded into the cache during actual work. As user habits change (for example, if a user has recently started playing games more frequently, game audio and microphone functions become important), the system will automatically update this library after the next charging cycle analysis to keep it always adapted to the user's latest habits.

[0038] In a preferred embodiment, building the smart headset pre-scheduling library in the system includes: setting an initial set of file identifiers for shared object files in the pre-scheduling library. Setting the initial set of file identifiers provides a cold start basis for the speed optimization process. In a preferred embodiment, when the device starts up for the first time, an optimized initial pre-scheduling library configuration file of the same system version and device model is downloaded from a secure cloud server.

[0039] S110, in response to the smart earphone entering the usage state, constructs a scheduling file cache space, traverses the smart earphone pre-scheduling library, and if the shared object file corresponding to the file identifier is not loaded, it is preloaded into the scheduling file cache space;

[0040] The smart earphones can enter a usage state in various ways, such as when they successfully connect to a mobile terminal via wireless signal, when the user removes the earphones from the charging case or puts them in, or when switching audio routes on the phone. The purpose is to reflect the user's intent. Once in usage mode, a dedicated, managed area is allocated in memory. Based on the traversal results of the pre-scheduled library, a shared object file pre-loaded by the smart earphones is stored. In one embodiment, the scheduling file cache space is separated from the system's general memory space and managed independently; in another embodiment, the scheduling file cache space and the system's general memory space work together. In the specific implementation, it is ensured that the content of the scheduling file cache space and the system's general memory space is not duplicated. The file cache space has a higher priority than the system's general memory space. First, the file cache space is checked for availability, then the target file is retrieved from memory. If it does not exist in memory, it is reloaded from the file system.

[0041] In a preferred embodiment, the core operation of preloading is to execute a system call similar to `preload(library_path, cache_path)`, loading the files at the disk path `library_path` into the newly allocated `cache_path` "scheduling file cache space". This proactively and in advance deploys the required shared object files, preparing for a rapid response to subsequent calls. In this preferred embodiment, the loading process is completed in the background to prevent conflicts with user operations; during loading, the highest priority shared object files are loaded first to ensure they are cache-ready as quickly as possible. In this preferred embodiment, the size of the scheduling file cache space is maintained at an appropriate level and can be automatically adjusted based on the mobile terminal's performance; this cache space can be a portion of the memory space.

[0042] S120, in response to the smart earphone executing a first function, the first function corresponding to a hardware function call; if the shared object file corresponding to the hardware call information of the hardware function call is hit in the scheduling file cache space, the shared object file in the scheduling file cache space is directly called to drive the hardware module corresponding to the first function to work; otherwise, the shared object file corresponding to the hardware call information of the hardware function call is normally loaded from the file system to the system memory, and the loaded shared object file is called; the hardware module corresponding to the first function is driven to perform work based on the called shared object file.

[0043] In one embodiment, the first function can be the target hardware call type determined in step (2) of step S100, such as common operations like "playing music", "turning on noise reduction", and "answering a phone call". This type of operation has a high hit rate. At the same time, different hardware call types may have the same loading requirements for shared object files, such as composite function libraries or general service libraries that provide upward support. Therefore, the first function can also be a hardware call type other than the target hardware call type. This type of operation has a relatively low hit rate, but the system overhead is within a controllable range due to the extremely fast query speed.

[0044] In terms of technical implementation, the instructions for the first function are passed to the system service, such as the AudioFlinger framework. However, the system service itself does not know whether the cache has been hit or which path the instructions will be routed to. In a preferred embodiment, a proxy service module PreloadManagerService is pre-embedded in the system service. This proxy service module maintains the mapping table of the "scheduling file cache space" built in S110 and provides at least the judgment interface booleanisLibraryPreloaded(String libraryIdentifier) ​​to determine whether the target shared object file has been hit in the scheduling file cache space. If it has, its handle is obtained directly; otherwise, it falls back to the original loading path.

[0045] The key implementation details for this section are provided below, along with some key code snippets:

[0046] / / 1. Obtain PreloadManagerService

[0047] sp <ibinder>binder = defaultServiceManager() -> getService(String16 ("preload_manager"));

[0048] sp <ipreloadmanager>preloadMgr = interface_cast <ipreloadmanager>(binder);

[0049] if (preloadMgr != nullptr) {

[0050] / / 2. Key query: Check if the target HAL library has been preloaded.

[0051] PreloadLibraryHandle preloadHandle = preloadMgr ->isLibraryPreloaded (String16 (halLibraryName.c_str()));

[0052] if (preloadHandle != nullptr) {

[0053] / / 3. Cache HIT branch

[0054] ALOGI("Using preloaded HAL library: %s",halLibraryName.c_str());

[0055] / / Convert the native layer handle pointer back

[0056] void* preloadedLibHandle = (void*)preloadHandle.nativeHandle;

[0057] / / 4. Use the preloaded handle to obtain the HAL module

[0058] This is typically accomplished using standard HAL interface functions such as getAudioPrimaryDevice.

[0059] audio_hw_device_t* dev;

[0060] int status = getAudioPrimaryDevice(preloadedLibHandle, &dev);

[0061] if (status == 0) {

[0062] return handle; / / Success, returned ahead of schedule!

[0063] } else {

[0064] ALOGW("Preloaded library found but initializationfailed, falling back.");

[0065] / / Initialization failed, continue with the normal loading path

[0066] }

[0067] / / else, if it's a cache miss, do nothing and continue execution.

[0068] }

[0069] In the above embodiments, all preloaded states are managed by a global service, PreloadManagerService, and maintained by a high-efficiency ArrayMap. The query speed is extremely fast (O(1)), and the performance overhead is negligible. The judgment logic is inserted at the beginning of the original loading path. Regardless of whether the query hits or not, the function can be guaranteed to execute normally. If it hits, it speeds up; if it misses, it gracefully degrades to the traditional path, ensuring the absolute robustness of the system. The entire judgment mechanism only involves one Binder IPC call and one Map query. Compared with the time spent loading an SO library from the original storage space (which involves a large number of I / O operations and symbol resolution), as long as the hit rate is not extremely low, this overhead has almost no impact, and the overall performance can be significantly improved.

[0070] In a preferred embodiment, during a hardware function call, if all shared object files are hit in the scheduling file cache space, the hardware module corresponding to the first function is driven to perform work based on the called shared object files; if some shared object files are hit in the scheduling file cache space, the remaining shared object files are loaded normally from the file system into the system memory, the loaded shared object files are called, and the hardware module corresponding to the first function is driven to perform work based on all called shared object files.

[0071] S130, based on the hardware call information corresponding to the first function being executed, perform an online update operation of the pre-scheduling library based on the priority scheduling policy; if the online update operation causes a change in the pre-scheduling library, then update the scheduling file cache space accordingly.

[0072] In the closed-loop feedback phase of the solution, it is ensured that the system is not static, but can learn from each user interaction and dynamically adjust the preloading strategy according to the actual usage, becoming more accurate and faster with use.

[0073] In a preferred embodiment, step S130 is executed periodically based on a time window. After each hardware function call is completed, hardware call information needs to be recorded to form a call log, including: the unique identifier of the function, the time when the call occurred, and if the status is MISS, which shared object files were ultimately loaded in this call, the time taken for this call, etc. Based on the above hardware call information, the average call value and the shared object file loading frequency calculation samples from step S110 are supplemented, and the average call value, shared object file loading frequency, sorting results, and priorities are recalculated. The new results calculated in the previous step (the new Top-K) are persisted to the configuration file of the pre-scheduled library. If the file changes, the scheduling file cache space is updated synchronously to immediately take effect the changes in the pre-scheduled library.

[0074] In a preferred embodiment, if a change is detected in the pre-scheduled library, and the scheduling file cache space is not full, a new change entry is added to the scheduling file cache space based on the change, instead of directly replacing the change entry, to prevent unpredictable problems caused by forced deletion. If the scheduling file cache space is full, the lowest priority shared object file in the scheduling file cache space is replaced with a new shared object file, and a low-priority shared object file unloading operation is performed. The low-priority shared object file unloading operation refers to mapping the low-priority shared object file from the scheduling file cache space to the regular system memory space for downgrading, preventing unpredictable problems caused by forced deletion. After the low-priority shared object file is mapped to the regular system memory space, it is managed based on the system's built-in memory management strategy.

[0075] Example 2: Figure 2 Showing with Figure 1 The system architecture corresponding to this method includes four core modules: the first construction module, the second construction module, the hardware function call module, and the online update module. This diagram illustrates the connections and data interaction relationships between the various modules within the system. Figure 2 As shown, this disclosure provides a smart headphone response speed improvement system that integrates a multi-functional scheduling file, including:

[0076] The first building module is configured to build a smart earphone pre-scheduling library in the system; the system monitors and extracts hardware call information from the historical operations of the smart earphone, and adds the file identifiers of the shared object files corresponding to the hardware call information that meets the first preset conditions to the pre-scheduling library according to the priority scheduling strategy;

[0077] The second building module is configured to respond to the smart earphone entering the usage state by building a scheduling file cache space, traversing the smart earphone pre-schedule library, and if the shared object file corresponding to the file identifier is not loaded, it is preloaded into the scheduling file cache space.

[0078] The hardware function call module is configured to respond to the smart earphone executing a first function, which corresponds to a hardware function call. If the shared object file corresponding to the hardware call information of the hardware function call is hit in the scheduling file cache space, the shared object file in the scheduling file cache space is directly called to drive the hardware module corresponding to the first function to work; otherwise, the shared object file corresponding to the hardware call information of the hardware function call is normally loaded from the file system to the system memory, and the loaded shared object file is called; the hardware module corresponding to the first function is driven to perform work based on the called shared object file.

[0079] The online update module is configured to perform an online update operation on the pre-scheduled library based on the hardware call information corresponding to the first function being executed, according to the priority scheduling strategy; if the online update operation results in a change to the pre-scheduled library, the corresponding scheduling file cache space is updated.

[0080] In a preferred embodiment, the first building module specifically includes:

[0081] The call information extraction unit is configured to extract hardware call information from the operation of the smart earphones during each smart earphone charging cycle;

[0082] The call value calculation unit is configured to determine the call frequency and call duration of each hardware function call, and to determine the call value based on a weighted sum of the call frequency and call duration.

[0083] The sorting unit is configured to sort the hardware call types based on the average call value over a preset N charging cycles.

[0084] The target type determination unit is configured to select a preset number of hardware call types that are ranked first as the target hardware call types.

[0085] The file combination analysis unit is configured to determine the combination of shared object files involved in each hardware call of each target hardware call type for each target hardware call type.

[0086] The priority determination unit is configured to count the loading frequency of each shared object file in the shared object file combination and sort them, and determine the file identifier of the shared object file corresponding to the hardware call information that meets the first preset condition, as well as the priority of the shared object file based on the sorting result.

[0087] The library update unit is configured to update the pre-scheduled library according to the priority scheduling policy.

[0088] In a preferred embodiment, the first function processed by the hardware function call module is the target hardware call type determined by the target type determination unit; or it is a type other than the target hardware call type. When it is a type other than the target hardware call type, the shared object file is a composite function library file that provides upward support or a service library file that provides general functions.

[0089] In a preferred embodiment, the system further includes: a proxy service module, pre-embedded in the system service, configured to maintain a mapping table for the scheduling file cache space, and at least providing an external judgment interface isLibraryPreloaded(String), which is used to determine whether the target shared object file is in the scheduling file cache space. If it is, the shared object file handle is directly obtained; if not, the original loading path is returned. The judgment only includes one Binder IPC call and one mapping query.

[0090] In a preferred embodiment, the online update module is specifically configured to: if a change is detected in the pre-scheduled library, and if the scheduling file cache space is not full, add a new change item to the scheduling file cache space according to the change; if the scheduling file cache space is full, replace the lowest priority shared object file in the scheduling file cache space with a new shared object file, and perform a low-priority shared object file unloading operation; the low-priority shared object file unloading operation refers to mapping the low-priority shared object file from the scheduling file cache space to the regular system memory space and downgrading it; after the low-priority shared object file is mapped to the regular system memory space, it is managed based on the system's built-in memory management strategy.

[0091] The above solution achieves at least the following technical effects: (1) Significantly reduces response latency and improves user experience: By constructing a pre-scheduled library and a scheduling file cache space, frequently used shared object files are pre-loaded into the cache. When a user triggers a function, if the cache hits, it can be called directly, avoiding the traditional time-consuming process of dynamically loading library files from the file system, thereby significantly reducing the response latency of smart headphone function execution and improving the smoothness of operation and user experience. (2) Realizes intelligent preloading and resource optimization management: Based on historical hardware call information (such as call frequency and duration), the priority strategy of the pre-scheduled library is dynamically constructed and updated to accurately predict and preload the most likely resources to be called. By designing a robust cache update and degradation mechanism (such as degradation processing when adding change items or replacing low-priority files instead of direct deletion), the system crash or functional abnormality that may be caused by the forced uninstallation or replacement of library files is effectively avoided, ensuring the stability and reliability of smart headphones during long-term operation and dynamic updates.

[0092] According to one embodiment, a program product, such as a machine-readable medium, is provided. The machine-readable medium may have instructions (i.e., the elements implemented in software as described above), which, when executed by a machine, cause the machine to perform the above-described combinations of the various embodiments of this specification. Figure 1 The various operations and functions described. Specifically, a system or apparatus equipped with a readable storage medium storing software program code that implements the functions of any of the embodiments described above, and enabling the computer or processor of the system or apparatus to read and execute the instructions stored in the readable storage medium.

[0093] In this case, the program code read from the readable medium itself can perform the functions of any of the above embodiments, and therefore the machine-readable code and the readable storage medium storing the machine-readable code constitute a part of this specification.

[0094] Examples of readable storage media include floppy disks, hard disks, magneto-optical disks, optical disks (such as CD-ROM, CD-R, CD-RW, DVD-ROM, DVD-RAM, DVD-RW, DVD-RW), magnetic tapes, non-volatile memory cards, and ROMs. Alternatively, program code can be downloaded from a server computer or the cloud via a communication network.

[0095] Those skilled in the art will understand that the various embodiments disclosed above can be modified and varied without departing from the spirit of the invention. Therefore, the scope of protection of this specification should be defined by the appended claims.

[0096] It should be noted that not all steps and units in the above process and system structure diagrams are mandatory; some steps or units can be omitted according to actual needs. The execution order of each step is not fixed and can be determined as needed. The device structure described in the above embodiments can be a physical structure or a logical structure. That is, some units may be implemented by the same physical client, or some units may be implemented by multiple physical clients, or they may be jointly implemented by certain components in multiple independent devices.

[0097] In the above embodiments, the hardware units or modules can be implemented mechanically or electrically. For example, a hardware unit, module, or processor may include permanent dedicated circuitry or logic (such as a dedicated processor, FPGA, or ASIC) to perform the corresponding operation. The hardware unit or processor may also include programmable logic or circuitry (such as a general-purpose processor or other programmable processor), which can be temporarily configured by software to perform the corresponding operation. The specific implementation method (mechanical, dedicated permanent circuitry, or temporarily configured circuitry) can be determined based on cost and time considerations.

[0098] The specific embodiments described above with reference to the accompanying drawings are exemplary embodiments, but do not represent all embodiments that can be implemented or fall within the scope of the claims. The term "exemplary" as used throughout this specification means "serving as an example, instance, or illustration" and does not imply that it is "preferred" or "advantageous" compared to other embodiments. Specific details are included to provide an understanding of the described techniques. However, these techniques can be practiced without these specific details. In some instances, well-known structures and apparatuses are shown in block diagram form to avoid obscuring the concepts of the described embodiments.

[0099] The foregoing description of this disclosure is provided to enable any person skilled in the art to implement or use this disclosure. Various modifications to this disclosure will be apparent to those skilled in the art, and the general principles applicable herein can be applied to other variations without departing from the scope of this disclosure. Therefore, this disclosure is not limited to the examples and designs described herein, but is consistent with the widest scope of the principles and novel features disclosed herein.< / ipreloadmanager> < / ipreloadmanager> < / ibinder>

Claims

1. A method for improving the response speed of smart headphones by integrating multi-functional scheduling files, the method comprising the steps of: S100, a smart earphone pre-scheduling library is built in the system; the system monitors and extracts hardware call information in the historical operation of the smart earphone, and adds the file identifier of the shared object file corresponding to the hardware call information that meets the first preset condition to the pre-scheduling library according to the priority scheduling strategy; S110, in response to the smart earphone entering the usage state, construct a scheduling file cache space, traverse the smart earphone pre-schedule library, if the shared object file corresponding to the file identifier in it is not loaded, then preload it into the scheduling file cache space; the preloading into the scheduling file cache space is: executing a system call to load the file of disk path library_path into the newly opened cache_path scheduling file cache space; S120, in response to the smart earphone executing a first function, the first function corresponding to a hardware function call, if the shared object file corresponding to the hardware call information of the hardware function call is hit in the scheduling file cache space, then the shared object file in the scheduling file cache space is directly called to drive the hardware module corresponding to the first function to work; otherwise, the shared object file corresponding to the hardware call information of the hardware function call is normally loaded from the file system to the system memory, and the loaded shared object file is called; the hardware module corresponding to the first function is driven to perform work based on the called shared object file. S130, based on the hardware call information corresponding to the first function being executed, perform an online update operation of the pre-scheduled library based on the priority scheduling strategy; If the online update operation results in a change to the pre-scheduled library, the corresponding scheduling file cache space will be updated. Step S100 includes: (1) In each smart earphone charging cycle, extracting hardware call information in the smart earphone operation, determining the call frequency and call duration of each hardware function call, and determining the call value based on the weighted sum of the call frequency and call duration; in a preset N charging cycle, sorting the hardware call types based on the average call value; (2) Selecting a preset number of hardware call types that are ranked first as target hardware call types; for each target hardware call type, determining the shared object file combination involved in each hardware call of the target hardware call type; (3) Statistically calculating and sorting the loading frequency of each shared object file in the shared object file combination, and determining the file identifier of the shared object file corresponding to the hardware call information that meets the first preset condition, and the priority of the shared object file based on the sorting result; (4) Updating the pre-scheduled library according to the priority scheduling strategy.

2. The method as described in claim 1, wherein the first function in step S120 is the target hardware call type determined in step (2); or is a type other than the target hardware call type determined in step (2). When it is a type other than the target hardware call type determined in step (2), the shared object file is a composite function library file for upward support or a service library file for providing general functions.

3. The method as described in claim 1, characterized in that: The instruction for the first function is passed to the system service. The system service pre-embeds a proxy service module PreloadManagerService. This proxy service module maintains the mapping table of the "scheduling file cache space" constructed in step S110 and provides at least the judgment interface isLibraryPreloaded(String) to determine whether the target shared object file is in the scheduling file cache space. If it is, the shared object file handle is directly obtained; if not, it falls back to the original loading path. The judgment only includes one Binder IPC call and one mapping query.

4. The method as described in claim 1, characterized in that: If a change is detected in the pre-scheduled library, and the scheduling file cache space is not full, a new change entry is added to the scheduling file cache space based on the change, instead of directly replacing the change entry, to prevent unpredictable problems caused by forced deletion. If the scheduling file cache space is full, the lowest priority shared object file in the scheduling file cache space is replaced with a new shared object file, and a low-priority shared object file unloading operation is performed. The low-priority shared object file unloading operation refers to mapping the low-priority shared object file from the scheduling file cache space to the regular system memory space and downgrading it to prevent unpredictable problems caused by forced deletion. After the low-priority shared object file is mapped to the regular system memory space, it is managed based on the system's built-in memory management strategy.

5. A smart headphone response speed improvement system integrating multi-functional scheduling files, characterized in that, The system includes: The first building module is configured to build a smart earphone pre-scheduling library in the system; the system monitors and extracts hardware call information from the historical operations of the smart earphone, and adds the file identifiers of the shared object files corresponding to the hardware call information that meets the first preset conditions to the pre-scheduling library according to the priority scheduling strategy; The second construction module is configured to respond to the smart earphone entering the usage state by constructing a scheduling file cache space, traversing the smart earphone pre-scheduled library, and if the shared object file corresponding to the file identifier is not loaded, preloading it into the scheduling file cache space; the preloading into the scheduling file cache space is: executing a system call to load the file at disk path library_path into the newly allocated cache_path scheduling file cache space; The hardware function call module is configured to respond to the smart earphone executing a first function, which corresponds to a hardware function call. If the shared object file corresponding to the hardware call information of the hardware function call is hit in the scheduling file cache space, the shared object file in the scheduling file cache space is directly called to drive the hardware module corresponding to the first function to work; otherwise, the shared object file corresponding to the hardware call information of the hardware function call is normally loaded from the file system to the system memory, and the loaded shared object file is called; the hardware module corresponding to the first function is driven to perform work based on the called shared object file. The online update module is configured to perform an online update operation on the pre-scheduled library based on the hardware call information corresponding to the first function being executed, according to the priority scheduling strategy; if the online update operation causes a change in the pre-scheduled library, the corresponding scheduling file cache space is updated. The first construction module specifically includes: The call information extraction unit is configured to extract hardware call information from the operation of the smart earphones during each smart earphone charging cycle; The call value calculation unit is configured to determine the call frequency and call duration of each hardware function call, and to determine the call value based on a weighted sum of the call frequency and call duration. The sorting unit is configured to sort the hardware call types based on the average call value over a preset N charging cycles. The target type determination unit is configured to select a preset number of hardware call types that are ranked first as the target hardware call types. The file combination analysis unit is configured to determine the combination of shared object files involved in each hardware call of each target hardware call type for each target hardware call type. The priority determination unit is configured to count the loading frequency of each shared object file in the shared object file combination and sort them, and determine the file identifier of the shared object file corresponding to the hardware call information that meets the first preset condition, as well as the priority of the shared object file based on the sorting result. The library update unit is configured to update the pre-scheduled library according to the priority scheduling policy.

6. The system as described in claim 5, characterized in that, The first function processed by the hardware function call module is the target hardware call type determined by the target type determination unit; or it is a type other than the target hardware call type. When it is a type other than the target hardware call type, the shared object file is a composite function library file that provides upward support or a service library file that provides general functions.

7. The system as described in claim 5, characterized in that, The system also includes: The proxy service module, pre-embedded in the system service, is configured to maintain the mapping table of the scheduling file cache space and provides at least one judgment interface isLibraryPreloaded(String) to determine whether the target shared object file is in the scheduling file cache space. If it is, the shared object file handle is directly obtained; otherwise, the original loading path is returned. The judgment only includes one Binder IPC call and one mapping query.

8. The system as described in claim 5, characterized in that, The online update module is specifically configured to: if a change is detected in the pre-scheduled library, and if the scheduling file cache space is not full, add a new change item to the scheduling file cache space according to the change; if the scheduling file cache space is full, replace the lowest priority shared object file in the scheduling file cache space with a new shared object file, and perform a low-priority shared object file unloading operation; the low-priority shared object file unloading operation refers to mapping the low-priority shared object file from the scheduling file cache space to the regular system memory space and downgrading it. After a low-priority shared object file is mapped into the regular system memory space, it is managed based on the system's built-in memory management strategy.

Images