IO order-aware mobile device app launch acceleration method and device

Abstract

The application discloses a kind of based on IO sequence perception's mobile device App startup acceleration method and equipment, belong to APP optimization technical field, comprising: startup data management step: access the data page of each App during startup in mobile device is repeatedly accessed, and according to read IO sequence record to the target table TT of App corresponding;The part data page marked in the front of target table TT is marked as the key startup data page of corresponding App, and the remaining data page is marked as the ordinary startup data page of corresponding App;Startup prediction step: predict the target App of mobile device soon to be started;Two-stage pre-reading step: before the target App starts, the key startup data page of target App is pre-read to memory;During the target App startup, the ordinary startup data page of target App is pre-read to memory according to read IO sequence, and startup acceleration is completed.The application can effectively accelerate App startup with small memory overhead.

Description

Technical Field

[0001] This invention belongs to the field of APP optimization technology, and more specifically, relates to a method and device for accelerating the startup of mobile device APP based on IO sequence awareness. Background Technology

[0002] By offering a wealth of features, mobile devices are increasingly integrated into users' daily work, study, and life. User interaction with a phone typically begins with app launch, making fast app launch a crucial guarantee of a good user experience. Furthermore, users are accustomed to frequently launching apps, leading to unbearable long app launch delays. Therefore, accelerating app launch is essential for improving user experience.

[0003] During app startup, the app startup process generates a large number of random small read I / Os. The latency of reading data from flash memory is approximately 1000 times that of reading from memory. When the data that the app startup process needs to access is not in memory, a page fault is triggered, and the app startup process must wait for the read I / O to complete, causing excessively long app startup latency. This problem is exacerbated when direct memory reclamation occurs or the data is waiting for scheduling in the I / O queue. When the data page that the app startup process needs to access is already in memory, the app startup process does not need to wait for the read I / O to complete. The data accessed during app startup is relatively fixed, and app startup can be accelerated by pre-reading this part of the data.

[0004] Currently, there are two popular prefetching schemes: one is Prefetching Before the App Launch (PBAL), which preloads the data needed for the app's startup process before the app launches; the other is Prefetching During the App Launch (PDAL), which accelerates app launch by prefetching during the app launch period. For PBAL, POA identifies user usage patterns through app usage logs, predicts the target app the user will use, and pre-launches that app before it launches. Similarly, FALCON predicts apps based on their usage context and preloads the disk data the app will access before its launch. PBAL can minimize app launch latency caused by I / O, but its performance depends on the accuracy of the prediction algorithm. If the prediction is incorrect, the hundreds of megabytes of prefetched data will not be accessed, which not only reduces memory utilization but also introduces additional launch latency for other apps. Currently, the most advanced app prediction algorithms still have an accuracy rate below 70%. Therefore, while PBAL can effectively accelerate app launch, it significantly reduces memory usage. For PDAL, FAST collects block layer requests at the block device layer and prefetches these requests during app startup; ASAP tracks repeatedly accessed pages at the virtual file system layer and prefetches these pages concurrently through multi-threading during app startup. PDAL only prefetches data that the app is currently accessing, resulting in higher memory utilization. However, the current PDAL solution is unaware of read I / O order. If data accessed by the app first is at the end of the prefetch queue, when that data is accessed, the prefetch thread has not yet read it into memory, resulting in an access-prefetch order reversal problem, rendering prefetching ineffective and limiting its effect on accelerating app startup.

[0005] In summary, the current method of accelerating app startup through pre-reading presents a conflict between memory usage efficiency and acceleration effect. Summary of the Invention

[0006] In response to the shortcomings and improvement needs of existing technologies, this invention provides a method and device for accelerating mobile device app startup based on IO sequence awareness, with the aim of effectively accelerating app startup with minimal memory overhead.

[0007] To achieve the above objectives, according to one aspect of the present invention, a method for accelerating mobile device app launch based on I / O sequence awareness is provided, comprising: Startup data management steps: Obtain the data pages that are repeatedly accessed during the startup of each App on the mobile device, and record them in the target table TT corresponding to the App according to the read IO order; mark the data pages at the beginning of the target table TT as the key startup data pages of the corresponding App, and mark the remaining data pages as ordinary startup data pages of the corresponding App; k It is a positive integer; Launch prediction step: Predict the target app that will launch on the mobile device; The two-stage pre-reading process involves: before the target app starts, the critical startup data pages of the target app are pre-read into memory; during the startup of the target app, the ordinary startup data pages of the target app are pre-read into memory according to the read I / O order, thus accelerating the startup process.

[0008] Furthermore, in the data management startup step, the data pages repeatedly accessed during the startup of each App on the mobile device are obtained and recorded in the target table TT corresponding to the App according to the read IO order. This includes: constructing a candidate table CT and a target table TT for each App, and for any App, constructing its target table TT in the following manner: Launch the app offline multiple times consecutively, and record the data pages accessed during each app launch and the corresponding access time in the offline launch log; Analyze the data pages that are repeatedly accessed during multiple app launches in the offline startup logs, and record them in the corresponding candidate table CT according to the order of access. When the app is launched online, the data pages accessed during the app launch and the corresponding access times are recorded in the online launch log; The data pages simultaneously recorded in the online startup log and the candidate table CT are recorded into the target table TT in the order of read IO, thus completing the construction of the target table TT.

[0009] Furthermore, the mobile device app startup acceleration method based on I / O sequence awareness provided by the present invention also includes: Data pages recorded in the online startup log but not in the candidate table CT are identified as active pages. The active pages are then inserted into the candidate table CT in the order of read I / O to update the candidate table CT.

[0010] Furthermore, the mobile device app startup acceleration method based on I / O sequence awareness provided by the present invention also includes: The target table TT will be continuously linked to the corresponding App. n Data pages that were not accessed during the first online startup were identified as inactive pages and removed from the target table TT in order to update the target table TT. in, n It is a positive integer.

[0011] Furthermore, the mobile device app startup acceleration method based on I / O sequence awareness provided by the present invention also includes: Merge the IOs that meet the preset conditions in the candidate table CT and the target table TT; The preset conditions are: accessing data pages in the same file, and the access addresses are similar or overlapping; similar access addresses mean that the difference between the access addresses does not exceed a preset threshold.

[0012] Furthermore, both the candidate table CT and the target table TT were divided into multiple time windows with equal time intervals; In each target table TT, the data pages marked as key startup data pages are the first few pages in that target table TT. k Data pages within a time window; Furthermore, in the two-stage pre-reading step, the pre-reading of the normal startup data page is implemented concurrently by multiple read threads; each read thread is allocated one time window at a time.

[0013] Furthermore, in the prediction step, the target app that will be launched on the mobile device is predicted, including: Get the most recently used devices on the mobile device m For each app, obtain the app's historical usage sequence; m It is a positive integer greater than 1; Input the historical usage sequence of the App into the trained App prediction model, and the App prediction model will output the target App that will be launched on the mobile device. The app prediction model consists of a Word2Vector model, an LSTM model, a fully connected layer, and a Softmax layer connected in sequence.

[0014] Furthermore, the mobile device App startup acceleration method based on IO sequence awareness provided by the present invention further includes: after a preset time interval, retraining the App prediction model based on user App usage logs to update the App prediction model.

[0015] According to another aspect of the present invention, a mobile device App launch acceleration device based on I / O sequence awareness is provided, including a computer-readable storage medium and a processor; Computer-readable storage media are used to store computer programs; The processor is used to read a computer program from a computer-readable storage medium and execute the above-described I / O sequence-aware mobile device App launch acceleration device provided by the present invention.

[0016] According to another aspect of the present invention, a mobile device is also provided, which is equipped with the above-described IO sequence-aware mobile device App launch acceleration device provided by the present invention.

[0017] In summary, the above-described technical solutions conceived in this invention can achieve the following beneficial effects: (1) This invention manages repeatedly accessed data pages during App startup based on read IO order, achieving IO order awareness. The data pages accessed first based on the read IO order are marked as the critical startup data pages of the corresponding App, while the remaining data pages are marked as ordinary startup data pages, thus achieving critical data identification. Simultaneously, a two-stage pre-reading method is used based on App prediction results. Specifically, before predicting the launch of the target App, only the more critical startup data pages are read, minimizing memory usage even if the App prediction is incorrect. During the target App startup, the remaining ordinary startup data pages are pre-read according to the read IO order, ensuring that the first accessed data pages are pre-read into memory, avoiding access-pre-read order reversal, and effectively accelerating App startup on mobile devices. In summary, this invention, based on IO order awareness and critical data identification, combined with a two-stage pre-reading method, can effectively accelerate App startup with less memory.

[0018] (2) In a preferred embodiment of the present invention, a CT-TT dual-page table mechanism is used to track repeatedly accessed data pages during App startup. Specifically, a candidate table CT and a target table TT are created for each App. The candidate table CT is used to record all repeatedly accessed data pages during App startup based on offline and online startup logs. The target table TT, based on the candidate table CT and combined with online startup logs, records the data pages most likely to be accessed during App startup in the current scenario. Furthermore, the recording order of data pages in both the candidate table CT and the target table TT is consistent with the read IO order. Through this CT-TT dual-page table mechanism, the present invention can more accurately identify and manage repeatedly accessed data pages during App startup in sequence, further improving the acceleration effect.

[0019] (3) In a preferred embodiment of the present invention, the identified active pages (data pages recorded in the online startup log but not in the candidate table CT) are inserted into the candidate table CT in the order of read IO. The active pages are caused by the updates to the App cache files and log files as the user uses the app. According to the temporal locality of data access, they may be accessed again in the subsequent App startup process. The present invention inserts the active pages into the candidate table CT in the order of read IO, which can effectively improve the hit rate of pre-read data.

[0020] (4) In a preferred embodiment of the present invention, the identified inactive pages (the consecutive pages in the target table TT in the corresponding App) will be... n Data pages that were not accessed during the initial online launch are deleted from the target table TT. Inactive pages are unlikely to be accessed in subsequent app launches. Deleting these data pages from the target table TT avoids loading them into memory, thereby improving the accuracy of prefetching and memory utilization.

[0021] (5) In the preferred embodiment of the present invention, read I / Os that access data pages in the same file in the candidate table CT and the target table TT and whose access addresses are similar or overlapping are merged, which effectively reduces the number of read I / Os and avoids reading too much data into memory, thereby further accelerating the pre-reading speed.

[0022] (6) In the preferred embodiment of the present invention, managing the data pages in the candidate table CT and the target table TT according to the time window can reduce the startup data management overhead and improve the startup data management efficiency. Furthermore, based on the time window, the pre-reading of ordinary startup data pages by using a multi-process concurrent method can further accelerate the pre-reading.

[0023] (7) In the preferred embodiment of the present invention, predicting the target App to be launched based on the historical usage information of the App can effectively utilize the strong correlation between the target App and its previous historical usage sequence of the App, and effectively ensure the accuracy of the prediction. Furthermore, the prediction model used in the present invention specifically includes a Word2Vector model, an LSTM model, a fully connected layer and a Softmax layer connected in sequence. The Word2Vector model in the model maps the description information of each App in the input historical usage sequence of the App into a vector, and then inputs the vector sequence corresponding to the historical usage sequence of the App into the LSTM model to complete the prediction. Based on this model, each App can be regarded as a word in a document and mapped by the Word2Vector model. Thus, the context in the App sequence can be fully utilized in the App prediction process, rich App semantic information can be preserved, the prediction accuracy of launching the App can be effectively improved, and the App launch acceleration effect can be effectively improved.

[0024] (8) In a preferred embodiment of the present invention, the App prediction model is retrained periodically based on the user’s App usage logs, thereby accurately identifying the user’s App usage habits and further improving the accuracy of App prediction. Attached Figure Description

[0025] Figure 1 A schematic diagram of a mobile device App startup acceleration method based on I / O sequence awareness provided in an embodiment of the present invention; Figure 2This is a schematic diagram of two-stage pre-read management provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of startup data management provided in an embodiment of the present invention; Figure 4 This is a schematic diagram of the App prediction model provided in an embodiment of the present invention. Detailed Implementation

[0026] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention. Furthermore, the technical features involved in the various embodiments of this invention described below can be combined with each other as long as they do not conflict with each other.

[0027] In this invention, the terms "first," "second," etc. (if present) in the invention and the accompanying drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0028] To effectively accelerate app startup with minimal memory overhead, this invention provides a mobile device app startup acceleration method and device based on I / O sequence awareness. The overall approach involves tracking repeatedly accessed data pages during app startup on the mobile device based on read I / O sequence, identifying the first accessed data page as a critical startup data page, and the remaining data pages as ordinary startup data pages. For the predicted target app about to launch, a two-stage pre-read management scheme is employed. Before the target app launches, only a small number of critical data pages are pre-read into memory, effectively mitigating the memory utilization decrease caused by prediction errors. During the actual startup phase of the target app, ordinary startup data pages are pre-read into memory according to the read I / O sequence, ensuring that the data pages accessed first are pre-read into memory first, effectively improving the acceleration effect. Furthermore, the prediction method for the target app is further improved to increase prediction accuracy and further enhance memory utilization.

[0029] Before explaining the technical solution of the present invention in detail, the relevant technical terms are briefly introduced as follows.

[0030] Launch data page: Data pages that are repeatedly accessed during app launch; Data pages that are accessed multiple times during app launches will be tracked as repeatedly accessed launch data pages and pre-fetched during app launch acceleration; Key Startup Data Page: The first data accessed during the App startup process is the most critical data during the entire App startup process. This part of the data has a small amount of data and the access is sudden. In this invention, the data pages that are accessed first during the App startup process are defined as key startup data pages. Normal startup data pages: Data pages accessed after the critical startup data pages; compared to the critical startup data pages, this part of the data pages has a larger amount of data and the access is relatively smooth.

[0031] The following is an example.

[0032] Example 1: A method for accelerating app startup on mobile devices based on I / O sequence awareness, such as... Figure 1 As shown, it includes: Startup data management steps: Obtain the data pages that are repeatedly accessed during the startup of each App on the mobile device, and record them in the target table TT corresponding to the App according to the read IO order; mark the data pages at the beginning of the target table TT as the key startup data pages of the corresponding App, and mark the remaining data pages as ordinary startup data pages of the corresponding App; k It is a positive integer; Launch prediction step: Predict the target app that will launch on the mobile device; The two-stage pre-reading process involves: before the target app starts, the critical startup data pages of the target app are pre-read into memory; during the startup of the target app, the ordinary startup data pages of the target app are pre-read into memory according to the read I / O order, thus accelerating the startup process.

[0033] This embodiment manages repeatedly accessed data pages during App startup based on read I / O order, achieving I / O order awareness. The data pages accessed first based on the read I / O order are marked as critical startup data pages for the corresponding App, while the remaining data pages are marked as ordinary startup data pages, thus achieving critical data identification. Building upon I / O order awareness and critical data identification, a two-stage pre-reading method is proposed for the predicted target App about to launch: Before the target App launches, only a small amount of its corresponding critical data is pre-read into memory. This ensures that the target App can launch quickly if the prediction is correct, and also mitigates the decrease in memory utilization caused by prediction errors. When the target App launches, ordinary data pages are pre-read into memory according to the read I / O order, ensuring that the pre-reading order of data pages is consistent with the access order, avoiding the problem of access-pre-reading order reversal, and effectively accelerating App startup.

[0034] Figure 2 The diagram shows a two-stage startup process, including the first stage of pre-reading key data pages before the app starts, and the second stage of pre-reading ordinary startup data pages during the app startup process.

[0035] The first phase involves pre-reading key startup data based on App prediction. After receiving the App prediction results, the pre-reading management module reads the target App's startup data page information from the startup data management system. Before the user uses the target App, a small number of important but critical data pages (pages within the first three time windows in the target table TT) are pre-read into memory, such as... Figure 2 As shown. Compared to PBAL, by pre-reading a small number of important key data pages, the number of page missing exceptions during app startup is effectively reduced with minimal memory overhead.

[0036] The second phase involves I / O sequence-aware pre-fetching of normal startup data. Upon detecting the target app's startup, pre-fetching of normal startup data pages (data pages recorded after three time windows in the target table TT) is immediately triggered. These pages are pre-fetched into memory before being accessed, according to their access time order (i.e., time window order). Pre-fetching employs a multi-threaded concurrent approach, with one thread allocating one time window at a time to accelerate the pre-fetching process. Compared to traditional PDAL, this pre-fetching scheme is aware of the data page access order, pre-fetching pages accessed earlier, thus resolving the problem of access-pre-fetch order reversal, effectively reducing the number of page misses during app startup, and significantly accelerating app startup.

[0037] In practical applications, the pages repeatedly accessed during app startup on mobile devices include file pages and anonymous pages. File pages, such as installation package files (.bak, .vdex, .odex) and dependency library files (.so), do not change much during app startup. App cache files and database files (.db) change gradually over time. In addition, anonymous pages are closely related to the app's running state.

[0038] Based on the above characteristics, in order to accurately identify and manage repeatedly accessed data pages during App startup, this invention performs offline processing to statistically analyze static startup pages before App usage. For data pages with significant changes, an online statistical method is used. Accordingly, a CT-TT dual-page table mechanism is proposed to achieve sequential management of repeatedly accessed startup data pages. Specifically, this includes: constructing a candidate table CT and a target table TT for each App; and for any App, constructing its target table TT as follows: The App is launched offline multiple times, and the data pages accessed during each App launch and the corresponding access time are recorded in the offline launch log. Optionally, in this embodiment, the number of consecutive offline launches is 10. The data pages that are repeatedly accessed in multiple App launches in the offline launch log are counted and recorded in the corresponding candidate table CT according to the order of access; Optionally, in this embodiment, data pages that are repeatedly accessed in at least 8 launches are recorded. When the app is launched online, the data pages accessed during the app launch and the corresponding access times are recorded in the online launch log; The data pages simultaneously recorded in the online startup log and the candidate table CT are recorded into the target table TT in the order of read IO, thus completing the construction of the target table TT.

[0039] Based on the above operations, during multiple app launches, all repeatedly accessed data pages will be recorded in the candidate table CT. The data pages most likely to be accessed during app launch in the current scenario, identified by combining the app's online usage records, will be recorded in the target table TT. The recording order of data pages in the two tables will be consistent with the read IO order (i.e., the access order of data pages).

[0040] Optionally, in this embodiment, the data structures of both the candidate table CT and the target table TT are hash arrays. It is easy to understand that, due to the access characteristics of file pages and anonymous pages, in the candidate table CT and the target table TT, each item corresponding to a file page is (ino, IO list), where ino is the file number used to identify different files, and the IO list records the IOs occurring on file ino. The IO list is organized in chronological order using a linked list, where each item (index, len) in the linked list identifies an IO, where index is the offset address of the file's internal page (i.e., the starting address of the IO), and len is the IO size (i.e., the number of pages to be accessed). In the candidate table CT and the target table TT, each item corresponding to an anonymous page is (pid, vaddr) used to represent the anonymous page accessed from the swap partition during the App's startup, where pid is the process ID of the App, and vaddr is the virtual address of the anonymous page belonging to that process. Offline startup logs and online startup logs can be generated in the following ways: After the app is installed or updated, the target app is launched multiple times consecutively when the mobile device is idle to collect read I / O during the app startup process offline. The filemap_fault / do_generic_file_read functions are used to record mmap / non-mmap read I / O (index, len, time), and the do_page_fault function is used to record anonymous page read I / O (pid, vaddr, time), where time is the time interval between when the data page is accessed and when the app starts. By recording the read I / O in chronological order, the access time corresponding to the accessed data page can be recorded, thus generating an offline startup log. Similarly, when a user uses the App, the above function can be used to collect read I / O during App startup online. By recording the read I / O in chronological order, the access time corresponding to the accessed data page can be recorded, thus generating an offline startup log.

[0041] It should be noted that the above-described method for constructing the target table TT is only a preferred embodiment of the present invention and should not be construed as the sole limitation of the present invention. Other methods that can more accurately track the data pages read during App startup and record them according to the corresponding read IO order can also be used to construct the target table TT. For example, in some embodiments, the candidate table CT constructed in the above steps can be directly used as the target table TT. More examples will not be listed here.

[0042] As the app is used continuously, the data pages it accesses during startup may change dynamically. To adapt to this dynamic change, this embodiment further proposes a method for updating candidate table CT and candidate table TT. The updating of candidate table CT specifically includes: Data pages recorded in the online startup log but not in the candidate table CT are identified as active pages. The active pages are then inserted into the candidate table CT in the order of read I / O to update the candidate table CT.

[0043] The active page, which is a data page recorded in the online startup log but not in the candidate table CT, is caused by updates to the App cache file and log file as the user uses the app. Due to the temporal locality of data access, it may be accessed again during subsequent App startups. In this embodiment, the active page is also inserted into the candidate table CT in the order of read IO through the above update method, which can effectively improve the hit rate of pre-read data.

[0044] The update of the target table TT specifically includes: The target table TT will be continuously linked to the corresponding App. n Data pages that were not accessed during the first online startup were identified as inactive pages and removed from the target table TT in order to update the target table TT. in, n It is a positive integer.

[0045] Inactive pages are data pages in the target table TT that have not been accessed during the n consecutive online launches of the corresponding app. They are unlikely to be accessed in subsequent app launches. Deleting these data pages from the target table TT avoids loading them into memory, thereby improving the accuracy of pre-fetching and memory utilization. A positive integer is used to identify inactive pages. n The specific value can be determined based on the actual access characteristics of the App. Optionally, in this embodiment, n =2.

[0046] To further accelerate the pre-reading speed, this embodiment further includes: Merge the IOs that meet the preset conditions in the candidate table CT and the target table TT; The preset conditions are: accessing data pages in the same file, and the access addresses are similar or overlapping; similar access addresses mean that the difference between the access addresses does not exceed a preset threshold; since more than 90% of read requests on mobile devices are between 11KB and 64KB in size, in this embodiment, the threshold for judging whether the IO access addresses are similar is specifically set to 64KB.

[0047] By combining I / O operations, this embodiment can effectively reduce the number of read I / O operations and avoid reading too much data into memory, thereby further accelerating the pre-read speed.

[0048] Through the above IO merging operation, this embodiment can merge random IO in candidate table CT and target table TT into sequential IO. Since the processing speed of sequential IO is better than that of random IO, the subsequent pre-read time can be further improved.

[0049] To reduce startup data management overhead and improve startup data management efficiency, this embodiment manages the candidate table CT and target table TT based on a time window (TW). Specifically, both the candidate table CT and the target table TT are divided into multiple time windows with equal time intervals. Considering that most App startup latency is 500-1000ms, if the time window size is too large (>50ms), the I / O order cannot be effectively identified; if the time window is too small (<5ms), the probability of merging random I / O within the time window is low, thus increasing pre-read latency and reducing pre-read efficiency. Optionally, in this example, the time interval is set to 10ms. In each target table TT, the data pages marked as key startup data pages are the first few pages in that target table TT. k Data pages within a time window; k The specific value can be determined according to the characteristics of data access during the App startup process. Experiments have shown that most App's key startup data pages are distributed in the first 10ms-30ms of App startup. Accordingly, in order to accurately identify the key startup data pages, in this embodiment, k =3; Furthermore, in the two-stage pre-reading process, the pre-reading of the normal startup data page is implemented concurrently by multiple read threads; each read thread is allocated a time window at a time; this multi-threaded concurrent pre-reading method can further improve the pre-reading speed.

[0050] In practical applications, objects in the candidate table CT and the target table TT can be identified by the tw_ino member, which indicates their time window. When inserting the active page into the candidate table CT, it can be inserted into the corresponding time window.

[0051] Figure 3The above example illustrates the startup of data page management, including the initialization of candidate table CT, the updating of candidate table CT, the insertion of active pages into target table TT, and the eviction of inactive pages from target table TT.

[0052] like Figure 3 The process As shown, the candidate table CT is initialized during the offline phase. After the user installs or updates the App, the data page management is activated to delete the old CT and create a new CT for the App. When the mobile device is idle, the App is launched multiple times in succession, and the read I / O during the App startup is collected. The file pages that are accessed repeatedly are recorded in the CT. Typically, a number of times is set to identify data pages that are accessed repeatedly during the startup phase. For example, in 10 consecutive offline startups, data pages that are accessed in more than 8 startups will be identified as data pages that are accessed repeatedly.

[0053] The update of candidate table CT is as follows Figure 3 The process As shown, file page C1 accessed in time period T1 and file page C4 accessed in time period T3 are not in CT, indicating that these pages are not repeatedly accessed pages. They are inserted into CT according to their access time as candidates to be pre-read.

[0054] Inserting the target table TT activity page as follows Figure 3 The process As shown, pages that are accessed repeatedly are inserted into TT as target pages to be prefetched. For example, in the startup 2 log, pages (A1, A21, A3, A4, C1) that are accessed in the T1 time period are also recorded in CT, which means that these pages are accessed repeatedly and should be prefetched. The corresponding TT time window T1 is inserted according to the time when the page is accessed, so that the repeatedly accessed file pages can be collected in time, improving the prefetch hit rate and obtaining the sequential characteristics of the accessed pages.

[0055] Evicting inactive pages from the target table TT, such as Figure 3 The process As shown, if a page recorded in TT is not accessed in two consecutive launches, it means that the page is an inactive page and is unlikely to be accessed in subsequent App launches. Therefore, after the App launches, these inactive pages are deleted from TT to avoid reading pages that will not be accessed into memory and improve the accuracy of prefetching.

[0056] Considering that the prediction accuracy of the target App will affect the acceleration effect of subsequent pre-reading, and the existing prediction rate of the target App is still below 70%, in order to further improve the acceleration effect of App startup, this embodiment further improves the prediction method of the target App to improve the prediction accuracy.

[0057] On mobile devices, the target app about to be launched is strongly correlated with its previous app usage history. For example, if a user places an order on Taobao and then pays with Alipay, it's highly likely they will use Alipay after using Taobao. Similarly, if a user receives a WeChat message while browsing short videos on Douyin, switches to WeChat to view the message, and then switches back to Douyin to continue watching short videos, it's highly likely they will use Douyin again within a certain period. Based on this analysis, this embodiment selects app historical usage information as a feature of the prediction model. Therefore, the app prediction problem can be described as: P=h(A m ) Where A m For the most recent m A sequence of historical usage data of an app {a0, a1, ..., a m-1}, where a i Indicates the i-th App used, a i It belongs to A, where A is a given set of Apps; h() represents the prediction model; P is the probability that each App will be used, and the App with the highest probability is the App most likely to be accessed.

[0058] Currently, many app prediction methods employ Markov chains or Bayesian methods. Markov chains can accurately identify the correlation between adjacent app usages, but they assume the target app is only related to the previously used app, ignoring the influence of historical app sequences on the target app. Bayesian methods can identify contextual information, but they assume each app usage record is unrelated and cannot identify relationships between app usage records. LSTM, due to its unique network structure, can store information and solve the gradient vanishing problem, and is often used for time series prediction. Therefore, this embodiment uses an LSTM model to construct a prediction model for app usage prediction.

[0059] Different apps exhibit certain correlations. For example, "Phone" and "Contacts" are strongly related apps, while Pinduoduo and Taobao are similar apps. With millions of apps in the market, a fast and efficient solution for mapping them is needed. Traditional one-hot encoding is simple and fast, but it cannot identify relationships between multiple apps. Based on this consideration, as a preferred implementation, this embodiment treats each app as a word in a document. Before actual prediction, Word2Vector is used for app mapping to fully utilize the context in the app sequence and preserve rich semantic information. In natural language processing, Word2Vector can be trained quickly on dictionaries of millions and datasets of hundreds of millions of words, and it effectively reflects the correlations between words. Ultimately, each app description will be mapped to a word vector.

[0060] Based on the above analysis, the App prediction model established in this embodiment takes the historical usage sequence of the App as input and outputs the matching of the target A that is about to be launched; the App prediction model is as follows: Figure 4 As shown, it includes a Word2Vector model, an LSTM model, a fully connected layer, and a Softmax layer connected in sequence; App historical usage sequence {a0,a1,…,a m-1 After inputting the App prediction model, the Word2Vector model will input {a0,a1,…,a} m-1 Each App in} is mapped to a d-dimensional vector, resulting in a vector sequence {v0, v1, ..., v}. m-1}, the vector sequence {v0,v1,…,v} m-1 The input is an LSTM, the output of which is the input of a fully connected layer. Finally, the probability of each app being launched or switched to the foreground is obtained through the softmax activation function.

[0061] As an optional implementation, this embodiment specifically uses the public dataset LASpp for model training. Before prediction, the dataset is preprocessed to extract historical app usage records and merge duplicate records. The training set and test set are divided in a 7:3 ratio. After training and testing based on the public dataset, a general app prediction model can be obtained.

[0062] Specifically, in the launch prediction step of this embodiment, predicting the target App that is about to launch on the mobile device includes: Get the most recently used devices on the mobile device m For each app, obtain the app's historical usage sequence; m The number of apps in the historical usage sequence is a positive integer greater than 1. mDifferent experiments were conducted. m The prediction accuracy corresponds to the value of m. When m < 5, the prediction accuracy increases as m increases. m When =5, m The increase in m has little impact on prediction accuracy. Therefore, as a preferred implementation, in this embodiment, m=5. The historical usage sequence of the App is input into the pre-trained App prediction model, and the App prediction model outputs the target App that will be launched on the mobile device.

[0063] In practical applications, the historical usage sequence of an app can be obtained by collecting user logs of the app. Specifically, the activities of app startup and switching to the foreground can be monitored at the application layer. That is, the app startup information can be obtained through Activity.startActivity(), and the information of the app that has switched to the foreground can be obtained through ActivityManager.getRunningAppProcesses(). The app startup and switching records are saved in the log file and persisted.

[0064] This embodiment, through improvements to the prediction model structure, can fully utilize the context in the App sequence during App prediction, retain rich App semantic information, effectively improve the prediction accuracy of App launch, and enhance App launch acceleration. It should be noted that the above App prediction method is only a preferred embodiment of the present invention and should not be construed as the sole limitation of the present invention. Other existing App prediction methods, such as those mentioned in CN107451694A and CN111258593A, can also be used in this invention.

[0065] To accurately identify users' app usage habits and further improve the accuracy of app prediction, this embodiment will periodically retrain the app prediction model based on users' app usage logs; accordingly, this embodiment further includes: after a preset time interval, retraining the app prediction model based on users' app usage logs to update the app prediction model; Based on the app usage habits of most users, in this embodiment, the update cycle of the app prediction model is set to one week, and the update time is 4:00 AM during the idle period of the mobile phone.

[0066] Overall, this embodiment, based on IO sequence awareness and key data identification, combined with a two-stage pre-reading method, can effectively accelerate App startup with less memory; it more accurately identifies and manages repeatedly accessed data pages during App startup in sequence through the CT-TT double-page table mechanism; and based on the improved App prediction model, it further improves the prediction accuracy of the target App, effectively enhancing the App startup acceleration effect.

[0067] Example 2: An I / O sequence-aware mobile device app launch acceleration device, comprising a computer-readable storage medium and a processor; Computer-readable storage media are used to store computer programs; The processor is used to read the computer program in the computer-readable storage medium and execute the mobile device App startup acceleration method based on IO sequence awareness provided in Embodiment 1 above.

[0068] Example 3: A mobile device that has installed the IO sequence-aware mobile device app launch acceleration device provided in Embodiment 2 above.

[0069] Those skilled in the art will readily understand that the above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for accelerating app startup on mobile devices based on I / O sequence awareness, characterized in that, include: Startup data management steps: Obtain the data pages that are repeatedly accessed during the startup of each App in the mobile device, and record them in the target table TT corresponding to the App according to the read IO order; mark the data pages at the beginning of the target table TT as the key startup data pages of the corresponding App, and mark the remaining data pages as the ordinary startup data pages of the corresponding App; Startup prediction step: Predict the target app that will be launched on the mobile device; The two-stage pre-reading process involves: before the target app starts, pre-reading the target app's critical startup data pages into memory; during the target app's startup, pre-reading the target app's ordinary startup data pages into memory according to the read I / O order, thus accelerating the startup process. The startup data management step involves acquiring the data pages repeatedly accessed during the startup of each App on the mobile device and recording them in the target table TT corresponding to the App according to the read IO order. This includes: constructing a candidate table CT and a target table TT for each App, and for any App, constructing its target table TT in the following manner: Launch the app offline multiple times consecutively, and record the data pages accessed during each app launch and the corresponding access time in the offline launch log; The data pages that were repeatedly accessed during multiple App launches in the offline startup log are counted and recorded in the corresponding candidate table CT according to the order of access. When the app is launched online, the data pages accessed during the app launch and the corresponding access times are recorded in the online launch log; The data pages simultaneously recorded in the online startup log and the candidate table CT are recorded into the target table TT in the order of read IO, thus completing the construction of the target table TT.

2. The mobile device App startup acceleration method based on IO sequence awareness as described in claim 1, characterized in that, Also includes: Data pages recorded in the online startup log but not in the candidate table CT are identified as active pages. The active pages are then inserted into the candidate table CT in the order of read I / O to update the candidate table CT.

3. The mobile device App startup acceleration method based on IO sequence awareness as described in claim 1, characterized in that, Also includes: The target table TT will be continuously linked to the corresponding App. n Data pages that were not accessed during the first online startup were identified as inactive pages and removed from the target table TT in order to update the target table TT. in, n It is a positive integer.

4. The mobile device App startup acceleration method based on I / O sequence awareness as described in any one of claims 1 to 3, characterized in that, Also includes: Merge the IOs that meet the preset conditions in the candidate table CT and the target table TT; The preset condition is that data pages in the same file are accessed, and the access addresses are similar or overlapping. Similar access addresses mean that the access addresses are within the same preset threshold.

5. The mobile device app startup acceleration method based on I / O sequence awareness as described in any one of claims 1 to 3, characterized in that, Both the candidate table CT and the target table TT are divided into multiple time windows with equal time intervals. In each target table TT, the data pages marked as key startup data pages are the first few pages in that target table TT. k Data pages within a time window; Furthermore, in the two-stage pre-reading steps, the pre-reading of the normal startup data page is implemented concurrently by multiple read threads; each read thread is allocated one time window at a time.

6. The mobile device App startup acceleration method based on I / O sequence awareness as described in any one of claims 1 to 3, characterized in that, The launch prediction step, which predicts the target app that will soon launch on the mobile device, includes: Obtain the most recently used device in the mobile device m For each app, obtain the app's historical usage sequence; m It is a positive integer greater than 1; The historical usage sequence of the App is input into the trained App prediction model, and the App prediction model outputs the target App that will be launched on the mobile device. The App prediction model consists of a Word2Vector model, an LSTM model, a fully connected layer, and a Softmax layer connected in sequence.

7. The mobile device App startup acceleration method based on I / O sequence awareness as described in claim 6, characterized in that, Also includes: After a preset time interval, the App prediction model is retrained based on user App usage logs to update the App prediction model.

8. A mobile device app launch acceleration device based on I / O sequence awareness, characterized in that, Includes computer-readable storage media and processors; The computer-readable storage medium is used to store computer programs; The processor is used to read the computer program in the computer-readable storage medium and execute the mobile device App launch acceleration device based on I / O sequence awareness as described in any one of claims 1 to 7.

9. A mobile device, characterized in that, It is equipped with the mobile device App launch acceleration device based on IO sequence awareness as described in claim 8.

Images