Display method and electronic device

Abstract

Embodiments of the present application provide a display method and an electronic device, and relate to the technical field of electronics, and are used to reduce display lag of the electronic device. The specific scheme is as follows: a first interface of a first application is displayed, a second interface is displayed in response to a first operation on the first interface; wherein, before the second interface is displayed after the first operation is received, a second application is initialized, and a first file required in the second application initialization process is locked in the memory of the electronic device.

Description

Technical Field

[0001] This application relates to the field of electronic technology, and more particularly to a display method and an electronic device. Background Technology

[0002] With the development of electronic devices, more and more applications are installed on them. Generally, the memory of electronic devices is used to temporarily store files needed for application operation. However, the memory of electronic devices is limited. Therefore, during operation, electronic devices often need to perform memory reclamation on files of applications that meet the reclamation criteria (such as infrequent use) to release the memory they occupy.

[0003] However, if some or all of the files required for an application to run are not stored in memory, the application needs to read the relevant data from external storage if it needs to access these files. Reading data from external storage takes a long time, which affects the normal operation of the application and degrades the user experience. Summary of the Invention

[0004] This application provides a display method and an electronic device to ensure the normal operation of the electronic device and reduce display stuttering and frame drops.

[0005] To achieve the above objectives, the embodiments of this application adopt the following technical solutions:

[0006] Firstly, embodiments of this application provide a display method applied to an electronic device. During the operation of an application on the electronic device, it can receive an operation triggering the application to switch from the current interface to another interface. In response to this operation, the electronic device can display the other interface, or it can display the corresponding animation effects during the switch from the current interface to another interface. The process of displaying the animation effects can be a process of rapidly and continuously displaying multiple image frames. However, while the electronic device is composing other interfaces or image frames, it may also need to initialize other applications simultaneously. The initialization process for other applications may require the electronic device to access files related to the initialization of those applications. These files may be stored in memory or in the external storage of the electronic device. Furthermore, accessing files stored in external storage takes longer than accessing files stored in memory. If this initialization process is time-consuming, the electronic device will be unable to compose image frames for other interfaces or animation effects in a timely manner, resulting in display stuttering or frame drops.

[0007] In some embodiments, when the electronic device displays a first interface of a first application, in response to an operation (referred to as a first operation) switching the first interface from the current interface to another interface, a second interface is displayed. This second interface may be a different interface from the first interface, or it may be an image frame of a motion effect corresponding to the process of switching from the first interface to another interface.

[0008] Understandably, after receiving the first operation but before displaying the second interface, if the electronic device initializes a second application different from the first application, it needs to access the first file required during the second application's initialization process. If the first file is not locked in the electronic device's memory, the electronic device may not be able to find the first file in memory when accessing it from memory, and in this case, it needs to read the first file from external storage into memory first. However, if the first file is locked in the electronic device's memory, the electronic device can directly access the first file from memory without needing to read it from external storage.

[0009] In the above embodiments, since the first file is locked in the memory of the electronic device, the initialization time of the second application is shortened, the impact of the initialization of the second application on the synthesis time of the second interface is reduced, thereby ensuring the normal operation of the application, avoiding display lag or frame drops on the electronic device, and improving the user experience.

[0010] In some embodiments, the memory of an electronic device is divided into many small units, which may be called page frames. Each page frame can store a portion of data; for example, application code or configuration files may exist in memory as multiple page frames. Furthermore, when the electronic device runs multiple applications, the data in memory is constantly accessed and updated. At this time, due to the limited storage space of memory, the electronic device can reclaim page frames corresponding to data that is not currently needed, in order to free up memory space for page frames corresponding to new data.

[0011] The first file is stored in the electronic device's memory, existing as a first page frame, which can be one or more page frames. Each page frame corresponding to the first page frame is configured with a locking flag, such as the flag in the `mlock` function. The memory management system will not reclaim page frames with locking flags. In this way, the data corresponding to the first file will remain in the electronic device's memory, and the electronic device can access the first file from memory at any time.

[0012] In the above embodiments, since the first file is locked in memory, when an application needs to access the first file, it can access it directly from memory without having to read it from external storage. Therefore, the access speed of the first file can be significantly improved, and the loading time for the initialization of the second application can be reduced.

[0013] In some embodiments, before displaying the first interface of the first application, the first file of the second application can be read from external storage into memory when the electronic device is first powered on. After the first file is loaded into memory, the electronic device locks it, meaning that the first file will not be reclaimed by the memory management system during subsequent use, ensuring that the first file can be accessed in memory at any time.

[0014] In the above embodiment, the first file is locked in memory upon initial power-on, that is, before the user begins to use the device. Thus, when the second application initializes for the first time, since the first file required for its initialization has already been loaded into and locked in memory, the electronic device can directly read the file from memory without needing to read it from external storage. This significantly reduces the time spent accessing the file, thereby speeding up the initialization of the second application.

[0015] In some embodiments, in order to store the first file in memory, the electronic device needs to first read the first file from external storage into internal storage and store it as a first page frame. Furthermore, the first file can be locked in memory by configuring a locking flag for the first page frame. The locking flag is used to instruct the memory management system to prevent the page frame from being reclaimed. When the memory management system reclaims page frames stored in memory, if it detects a page frame with a locking flag, it will skip that page frame and will not remove or overwrite its contents.

[0016] In the above embodiments, when the electronic device is powered on for the first time, the first file is read from external storage into memory in advance, and a locking flag is configured for the first page frame corresponding to the first file to ensure that the first file will not be reclaimed. When the electronic device needs to access the first file after powering on, it can access it directly from memory without having to read it from external storage again.

[0017] In some embodiments, before reading the first file from external storage into memory, it is necessary to obtain basic information about the first file, including its file path and file size. The file path can be the specific location of the first file in external storage, while the file size is the amount of storage space occupied by the first file. Before reading the data corresponding to the first file from external storage into memory, it is necessary to create blank page frames to store the data of the first file.

[0018] Next, the first file is located in external storage based on its file path. Once located, an amount of data equal to the file size of the first file is read from that file path, and this data is mapped into the previously created blank page frame. At this point, the first page frame is obtained based on the blank page frame containing the mapped data.

[0019] In the above embodiments, by obtaining the file path and file size, creating blank page frames, and mapping file data into the page frames, efficient and accurate file reading and memory management are achieved, improving file reading efficiency and ensuring that critical files can be accessed quickly when needed, thereby improving the overall performance of the device.

[0020] In some embodiments, the first file of the second application may be, in addition to the initialization files configured for the second application before the first boot, also be the updated version of the files required for the second application's initialization. Before displaying the first interface of the first application, if a compilation optimization condition is detected as being triggered, the second file required for the initialization of the second application needs to be compiled and optimized to obtain the updated first file after compilation optimization. For example, the second file may be the dex file of the second application, and the first file may be the odex file obtained after compiling and optimizing the dex file of the second application. The compilation optimization condition can be considered met when the second application is installed, the code execution frequency of the second application exceeds a preset frequency value, or the operating system of the electronic device is updated, and the application's files are then compiled and optimized. Generally, the first file obtained through compilation optimization is more efficient at runtime than the second file before compilation optimization.

[0021] In the above embodiments, the updated files after compilation and optimization are also locked in memory. When the electronic device needs to access these updated files, it can directly retrieve the updated files from memory, ensuring that the first file can be accessed quickly and saving the initialization time of the second application.

[0022] In some embodiments, before displaying the first interface of the first application, the electronic device can read the first file, compiled and optimized for the second file, from external storage into memory and store it as a first page frame. Furthermore, the first file can be locked in memory by configuring a locking flag for the first page frame. The locking flag instructs the memory management system to prevent the page frame from being reclaimed. When the memory management system reclaims page frames stored in memory, if it detects a page frame with a locking flag, it will skip that page frame and will not remove or overwrite its contents.

[0023] In the above embodiments, the first file obtained after compilation and optimization by the electronic device is read from external storage into memory, and a locking flag is configured on the first page frame corresponding to the first file to ensure that the first file will not be reclaimed. Thus, when the electronic device needs to access the first file, it can directly access the updated, compiled and optimized first file from memory, without needing to read it from external storage.

[0024] In some embodiments, before locking the first file, a third file stored in memory also needs to be processed. If the above compilation optimization is the first compilation optimization, the third file may be a file required for the initialization of the second application, locked during the first boot. If the above compilation optimization is not the first compilation optimization, the third file may be a file obtained after the previous compilation optimization. In this case, the page frame identifier of the second page frame containing the third file is obtained. The page frame identifier may be the page frame of the second page frame where the third file is stored in memory. Based on the page frame identifier, the second page frame corresponding to the third file can be found, thereby deleting the locking flag of the second page frame and allowing it to be reclaimed by the memory management system.

[0025] In the above embodiment, by deleting the lock mark of the second page frame corresponding to the third file, the second page frame with the deleted lock mark can be reclaimed by the memory management system, thus preventing the old version file before this compilation optimization from continuing to occupy memory space.

[0026] In some embodiments, the electronic device may contain corresponding configuration information that specifies pre-defined application files that need to be locked in memory. These applications may be those that frequently initialize in the background of the electronic device, and the files that need to be locked can be files that the electronic device needs to access during the initialization of these applications. The second application may be recorded in the configuration information as its application identifier, such as its package name. The files that the second application needs to lock may be first files required for its initialization, where the first file may be one or more files. The file identifier of the first file may be its file extension.

[0027] In the above embodiments, by pre-specifying the files required for application initialization that need to be locked in memory in the configuration information, and using application identifiers and file identifiers to record the files corresponding to these applications, the startup of the applications recorded in the configuration information is optimized.

[0028] In some embodiments, the first file is one or more of the APK file, DEX file, or ODEX file of the second application. For example, the first file may be the APK file, DEX file, or ODEX file of the second application, or it may be the DEX file of the second application, or it may be the DEX file or ODEX file of the second application.

[0029] In a second aspect, embodiments of this application provide an electronic device, including a processor and a memory, wherein the memory is used to store code instructions; and the processor is used to execute the code instructions, causing the electronic device to perform the methods described in the first aspect and any of its implementations.

[0030] Thirdly, embodiments of this application provide a computer-readable storage medium storing instructions that, when executed, cause a computer to perform the method described in the first aspect and any of its implementations.

[0031] Fourthly, embodiments of this application provide a computer program product, including a computer program that, when run, causes a computer to perform the methods described in the first aspect and any of its implementations.

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

[0033] Figure 1 This application provides a schematic diagram of a scenario for calling a WebView plugin.

[0034] Figure 2 This is one of the schematic diagrams illustrating thread operation in an electronic device according to an embodiment of this application;

[0035] Figure 3 This application provides a schematic diagram of a scenario for calling the Fast Engine plugin.

[0036] Figure 4 This is a second schematic diagram illustrating thread operation in an electronic device, provided as an embodiment of this application.

[0037] Figure 5 A schematic diagram of the architecture of an operating system in an electronic device provided in an embodiment of this application;

[0038] Figure 6 This is one of the flowcharts illustrating a display method provided in an embodiment of this application;

[0039] Figure 7 A second schematic flowchart illustrating a display method provided in an embodiment of this application;

[0040] Figure 8 This is the third schematic diagram illustrating thread operation in an electronic device, as provided in this application embodiment.

[0041] Figure 9This is the fourth schematic diagram of thread operation in an electronic device provided in this application embodiment. Detailed Implementation

[0042] The technical solutions of the embodiments of this application will be clearly described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this application. Other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are all within the protection scope of this application.

[0043] To better understand the technical solution of this application, the technical terms involved in this application will be explained first.

[0044] A process is an instance of an application running on an electronic device, based on a set of data. It is a process defined by the operating system (e.g., the operating system). The basic unit for resource allocation and scheduling in an electronic device is the operating system. Applications in electronic devices run on the operating system as one or more processes to perform corresponding functions. A process can contain multiple threads. A thread is the smallest unit that the operating system of an electronic device can schedule; each thread can execute different control flows.

[0045] Thread blocking typically refers to a timeout event where the execution time of a thread exceeds a preset value. For example, thread A needs the execution result of thread B as an input parameter to continue execution. If thread A does not receive the execution result from thread B, it will pause execution. Thus, if thread A does not receive the execution result from thread B for an extended period, thread A will become blocked, affecting the normal operation of the application.

[0046] Memory, also known as internal storage or main memory, refers to the data storage space obtained through physical memory modules. This space is used to temporarily store data processed by the Central Processing Unit (CPU) and data exchanged between memory and external storage. Memory provides temporary storage space for the operating system and various applications running on the electronic device. The operating system divides memory into fixed-size page frames, which serve as the smallest unit for storing data (such as file content and program code) in memory; for example, each page frame is 4KB in size.

[0047] External storage, also known as secondary storage, refers to storage in electronic devices other than main memory and CPU cache. This type of storage retains data even after the electronic device is powered off. Examples include hard disks and solid-state drives (SSDs).

[0048] A file system is the way an operating system organizes files and their related data in external storage. By dividing different types of data into multiple files and grouping these files, the file system organizes and manages data in external storage, enabling efficient storage, retrieval, and access of data. In a file system, each file has a unique file path, which identifies the file's specific location in external storage. The file path allows you to locate the corresponding file in external storage.

[0049] For example, during application runtime, when a thread of the application needs to access a file, the thread sends a request to the kernel-level virtual file system (VFS) to read the file. The VFS can check whether the page frame corresponding to the file is cached in memory. If the page frame is cached in memory, the VFS can directly read the page frame from memory. After reading the page frame from memory, the VFS can map the page frame to the virtual memory space of the process where the thread resides. The thread can then access the page frame through its address in the virtual memory space, thus accessing the file. If the page frame is not cached in memory and a page fault occurs, the application thread needs to read the file from external storage. The process of reading the file from external storage can include: the VFS sending a read request to the external storage file system for the missing page (such as the page frame corresponding to the file mentioned above); the file system then requests the data of the missing page from external storage through the block device and the input / output scheduler. After finding the data of the missing page from external storage, the VFS can map the data of the missing page to the corresponding page frame in memory, completing the reading of the missing page. After reading the data of the missing page, a mapping is established between the missing page and the virtual memory space of the process where the thread resides. The thread can then access the page frame corresponding to that file through the established mapping, thereby enabling access to the file.

[0050] Understandably, electronic devices have limited memory capacity. To prevent excessive memory usage and subsequent lag, memory reclamation mechanisms typically delete page frames from memory to free up space and reduce unnecessary memory consumption. Therefore, applications often need to read files from external storage. If the file to be read is large, it can cause prolonged file reading times for application threads, leading to thread blocking and impacting application performance.

[0051] For example, such as Figure 1As shown, in response to a user's operation on the application icon 102 of application 1 on the desktop 101, the electronic device can display the application interface 103 of application 1. For example, the application interface 103 includes multiple display bars corresponding to articles, such as the display bar 104 corresponding to article 1.

[0052] In response to a user clicking the display bar 104, the electronic device can display a loading screen 105. The loading screen 105 may include the basic framework of the application interface of application 1, serving as a display transition during the loading of article 1 by the electronic device. After the electronic device has finished loading article 1, it can display a details screen 106. The details screen 106 includes the detailed content of article 1.

[0053] In a possible embodiment, the electronic device can load the details of article 1 via a WebView plugin to synthesize the details interface 106. Exemplarily, the WebView plugin is a built-in browser of the electronic device used to display external web pages within the device's applications. That is, during application runtime, external web pages can be displayed directly by the WebView plugin as the application's built-in browser without needing to open an external browser. For example, if a user opens article 1 in application 1, they can obtain the external web page link 1 for article 1. The WebView plugin then downloads the data of article 1 (such as the aforementioned details) based on the external web page link 1 and displays this data in application 1.

[0054] For example, before an electronic device can use the WebView plugin, the WebView plugin needs to be initialized. Initializing the WebView plugin involves reading the WebView plugin's dex file. The dex file is a file containing the application's source code, which indicates the application's runtime logic. The WebView plugin's dex file, in turn, contains the WebView plugin's source code, which indicates the WebView plugin's runtime logic.

[0055] For example, in the process of composing the details interface 106 corresponding to article 1, the threads involved may include the UI thread, the rendering thread, and the SurfaceFlinger thread. Figure 2As shown, in response to user interaction, the WebView plugin is initialized by the UI thread. During the initialization process, if a page fault occurs due to the WebView plugin's dex file not being cached in memory, the UI thread needs to read the WebView plugin's dex file from external storage. After the UI thread reads the WebView plugin's dex file from external storage, the WebView plugin can be run to load the details of article 1. It is understandable that the rendering thread and the SurfaceFlinger thread need to wait for the UI thread to download the details of article 1 via the WebView plugin, and for the UI thread to draw the page image corresponding to article 1 based on the webpage content. After the UI thread draws the page image corresponding to article 1, the rendering thread renders the page image drawn by the UI thread to obtain the rendered image. Then, the SurfaceFlinger thread uses the rendered image for compositing to obtain the details interface 106 for article 1.

[0056] In a possible implementation, if the WebView plugin's dex file is too large, the time it takes for the UI thread to read the WebView plugin's dex file from external storage will increase, for example, Figure 2 The time T1 spent by the UI thread reading the WebView plugin's dex file increases. This will cause thread blocking in the rendering thread and the SurfaceFlinger thread, resulting in an increase in the time T2 spent compositing the details screen 106, causing the loading screen 105 to remain in the user's view for a longer period of time, thus affecting the user experience.

[0057] For example, the actual type of application 1 is not limited in the embodiments of this application.

[0058] For example, an electronic device may be in a locked, black-screen state. Figure 3 As shown, the electronic device can display a lock screen interface 201 after receiving a user's screen wake-up operation. The lock screen interface 201 includes an unlock control 202. In response to the user's operation on the unlock control 202, such as a touch operation on the unlock control 202, the electronic device can collect the user's biometric information, such as fingerprint information. If the collected biometric information is successfully verified, the electronic device unlocks and displays the desktop 101.

[0059] For example, during the process of unlocking an electronic device and switching from the lock screen 201 to the desktop 101, an animation effect corresponding to unlocking (referred to as unlock animation) needs to be displayed to reduce the abruptness of the screen transition. Here, an image frame can be a single frame, the smallest unit of the electronic device's animation, such as the aforementioned unlock animation display process. An image frame can be understood as a still image, and rapidly displaying multiple image frames can bring a dynamic visual effect.

[0060] For example, the aforementioned unlock animation can be composed by a desktop application. The threads involved in composing the unlock animation in a desktop application may include the UI thread, the rendering thread, and the SurfaceFlinger thread.

[0061] In a possible implementation, before or during the rendering of the unlock animation by the desktop application, the UI thread reads the odex file of another application in response to its initialization request. The odex file can be a compiled and optimized dex file; compared to a standard dex file, executing an odex file results in faster application startup and higher running efficiency. For example, a description of compilation optimization is provided in the following embodiments, and will not be repeated here.

[0062] Taking the initialization of the QuickEngine plugin during the rendering of the unlock animation in a desktop application as an example, the UI thread performs this initialization. The QuickEngine plugin can be used to load card effects from the desktop. Before using the QuickEngine plugin on an electronic device, it needs to be initialized, which includes reading the plugin's odex file. For example... Figure 4As shown, in response to the user unlocking the device, the desktop application begins drawing the unlock animation. After the UI thread completes the drawing of image frame 1 of the unlock animation, the rendering thread renders image frame 1 based on the drawing results from the UI thread. Then, the SurfaceFlinger thread uses the rendering results to composite image frame 1 for display. Next, in response to the initialization request for the Fast Engine plugin, the UI thread reads the Fast Engine plugin's odex file. If a page fault occurs and the Fast Engine plugin's odex file is not cached in memory, the UI thread reads the Fast Engine plugin's odex file from external storage. During this process, the UI thread is occupied and cannot continue drawing the image frames of the unlock animation. At this time, the rendering thread and the SurfaceFlinger thread wait for the UI thread to complete reading the Fast Engine plugin's odex file. After the UI thread completes reading the Fast Engine plugin's odex file, it continues drawing the next image frame of the unlock animation, such as image frame 2. After the UI thread completes drawing image frame 2, the rendering thread renders image frame 2 based on the drawing results from the UI thread. Then, the SurfaceFlinger thread uses the rendering results to synthesize image frame 2.

[0063] In a possible implementation, if the odex file of the fast engine plugin is too large, the time it takes for the UI thread to read the odex file from external storage will increase, e.g. Figure 4 The time T3 spent by the UI thread reading the odex file of the fast engine plugin increases. This will cause the UI thread to be unable to render the next frame of the unlock animation in time, such as frame 2 above. This will cause the rendering thread and the SurfaceFlinger thread to be blocked, resulting in an increase in the time T4 spent compositing frame 2. As a result, the unlock animation will drop frames during display, affecting the user experience.

[0064] Based on this, this application provides a display method applied to an electronic device. This method manages the electronic device's memory by retaining page frames of application-related files in memory and preventing the deletion of these page frames. Thus, when the electronic device subsequently uses these files, it can directly access the page frames corresponding to the files in memory without reading the files from external storage, reducing thread blocking, ensuring the normal operation of the application, preventing display stuttering or frame drops, and improving the user experience.

[0065] For example, the electronic device in this application embodiment may be a mobile phone, tablet computer, desktop computer, laptop computer, handheld computer, notebook computer, ultra-mobile personal computer (UMPC), netbook, as well as wearable device, personal digital assistant (PDA), augmented reality (AR) / virtual reality (VR) device, etc., which can install applications. This application embodiment does not impose any special restrictions on the specific form of the electronic device.

[0066] Figure 5 This is a software structure block diagram of an electronic device according to an embodiment of this application.

[0067] A layered architecture divides software into several layers, each with a clear role and function. Layers communicate with each other through software interfaces. In some embodiments, [the following is omitted as the text is incomplete and likely refers to a specific implementation or feature]. The system is divided into five layers, from top to bottom: application layer, application framework layer, system library, kernel layer, and hardware layer.

[0068] The application layer can include a series of application packages. For example... Figure 5 As shown, the application package may include the application to be locked. The application to be locked may be a large APK file, DEX file, or ODEX file that the operating system frequently needs to access. In some embodiments, it is necessary to read a portion of the application's files into memory to obtain the corresponding page frames, and prevent these corresponding page frames from being reclaimed from memory. The application to be locked may, for example, be application 2, application 3, application 4, a WebView plugin, or a fast engine plugin, as described in this embodiment. The application package may also include applications such as phone, messaging, calendar, and gallery.

[0069] The application framework layer provides application programming interfaces (APIs) and a programming framework for applications in the application layer. The application framework layer includes some predefined functions.

[0070] like Figure 5 As shown, the application framework layer may include a window manager, content provider, view system, phone manager, resource manager, build optimization module, and file locking module, etc.

[0071] In some embodiments, the compilation optimization module can be a submodule (such as DexoptHelper) within the PackageManagerService (PMS). The compilation optimization module can optimize the application's code during compilation. Compilation optimization can be a process of analyzing, transforming, and improving the application's code to enhance its runtime performance, resource utilization efficiency, and startup time, among other related metrics. For example, for... For system applications, the main target of compilation optimization is the code in the application's dex file. For example, a compiler can translate the code in the dex file into binary code that the electronic device can directly recognize. Based on the translated binary code, a corresponding odex file is generated, completing the compilation optimization.

[0072] Compared to dex files, odex files occupy more storage space, but the binary code in odex files is executed much faster when an electronic device runs an application. An application's APK file (also known as an installation package file) only includes a dex file; the odex file is not included in the APK. Before the application's odex file is generated, the electronic device cannot execute the application using machine code because it lacks the odex file; it can only execute it using interpreted code. For example, odex files can be generated after the application is installed, or after the electronic device has used the application for a period of time. If the application's odex file is generated after installation, then for applications already installed on the electronic device before the factory defaults, the corresponding odex file already exists before the electronic device is first powered on.

[0073] In addition to optimizing application code, such as dex files, as mentioned above, the compilation optimization module can also include: identifying applications that need compilation optimization during application installation, updates, or operating system startup; and recording the compilation optimization status of each application (such as whether the application's dex file has been compiled optimized, or the optimized version of the application's dex file).

[0074] In some embodiments, the file locking module may be a submodule of the resource management service (resourceManagerService) responsible for managing system resource allocation and scheduling. The functions of the file locking module include: issuing locking commands to files in the file system, which trigger the reading of files into memory and prevent the corresponding page frames of the files in memory from being reclaimed; receiving the compilation optimization status of the application sent by the compilation optimization module; and loading and running the configuration table. The configuration table (also known as fileConfig.xml) may be used to define the configuration rules of the file locking module, indicating the files that need to be locked. For example, the configuration table can be described in the following embodiments, which will not be repeated here.

[0075] The window manager manages windowed applications. The content provider stores and retrieves data, making that data accessible to applications. The view system includes visual controls, such as controls for displaying text and images. The view system can be used to build applications. The phone manager provides communication functionality for electronic devices. The resource manager provides various resources for applications.

[0076] System libraries can include multiple functional modules. For example: surface manager, media libraries, 3D graphics libraries (e.g., OpenGL ES), 2D graphics engines (e.g., SGL), SurfaceFlinger, etc.

[0077] The Surface Manager manages the display subsystem and provides fusion of 2D and 3D layers for multiple applications. The Media Library supports playback and recording of various common audio and video formats, as well as still image files. The Media Library supports multiple audio and video encoding formats. The 3D Graphics Library implements 3D graphics drawing, image rendering, compositing, and layer processing. The 2D Graphics Engine is the drawing engine for 2D graphics.

[0078] SurfaceFlinger is an image compositor used to control the compositing of windows, merging multiple windows into a single image.

[0079] The kernel layer is the layer between hardware and software. The kernel layer contains at least the display driver. It may also include: camera drivers, audio drivers, sensor drivers, etc. (not shown in the diagram).

[0080] In this embodiment, the kernel layer further includes a virtual file system, a page cache, a memory management module, and a file system. Upper-layer applications can access data in internal and external memory through the virtual file systems of the framework layer and the kernel layer.

[0081] As described above, application files can be stored in memory for quick access. The page cache is a cached area in memory used to store the page frames corresponding to files, allowing the operating system to quickly respond to a process's file read requests and avoid reading data from external storage every time. For example, when a thread requests to read file 1, the virtual file system can first check if a corresponding page frame for file 1 exists in the memory's page cache. Exemplarily, this can be done by checking the file's inode (also known as the file's index node). The inode includes information such as the file's size, permissions, and data block locations. If the page frame for file 1 is in the memory's page cache, the virtual file system can directly read it from memory. After reading the page frame, the virtual file system maps it to the virtual memory space of the process running the thread and creates a corresponding page table entry. This entry records the mapping between the virtual memory address of file 1 in the virtual memory space and its physical memory address in memory. The thread can then access the page frame for file 1 using its address in the virtual memory space, thus reading file 1. If the page frame corresponding to file 1 is not cached in the memory page cache, a page fault is triggered, and the data for file 1 is read from secondary storage. The explanation of page faults is given in the above embodiment and will not be repeated here.

[0082] The memory management module is used to allocate and manage the memory resources of electronic devices. This includes efficiently and quickly allocating memory resources, and releasing and reclaiming memory resources when appropriate. The file system, also known as the file management system, is used to organize and allocate space on file storage devices (such as external storage devices), and is responsible for storing, protecting, and retrieving files.

[0083] The hardware layer can include device hardware, such as displays and cameras (not shown in the figure) in electronic devices.

[0084] Understandably, through the above display method, the electronic device can display the first interface of the first application, such as desktop 101 or lock screen 201. After receiving a first operation on the first interface (such as clicking the application icon 102 of application 1 on desktop 101, or touching the unlock control 202 on lock screen 201), the electronic device can display a second interface, such as application interface 103, or a frame of an unlock animation. After receiving the first operation but before displaying the second interface, a second application may need to be initialized, such as a WebView plugin or a fast engine plugin. At this time, before displaying the first interface of the first application, the first file required for the initialization process of the second application needs to be locked in the memory of the electronic device. The triggering method for locking the first file in the memory of the electronic device can include: triggering after the electronic device is first powered on, or triggering after compilation optimization by the compilation optimization module.

[0085] The following example, taking the scenario of an electronic device being powered on for the first time, details the steps for locking the first file in the electronic device's memory. Specifically, upon initial power-on, the electronic device can read the file to be locked in memory from its external storage into its main memory and lock the corresponding page frame in memory. Here, the application of the aforementioned file can be the second application in this application, and the file to be locked in memory can be the first file of that second application. Specifically, as... Figure 6 As shown, the process of locking the first file in the memory of the electronic device upon its first power-on can include the following steps: S101-S111. In S101-S111, the description is based on the example of target application a being the second application and the file to be locked a being the first file.

[0086] S101, The file locking module detects that the electronic device is powered on for the first time.

[0087] For example, locking the file 'a' to be locked in the electronic device's memory when it is first powered on ensures that the application's related files already exist in memory before the application actually runs, such as in the memory's page cache. This way, when a thread needs to access these files, it can retrieve them directly from the memory's page cache.

[0088] Understandably, the initialization operations performed when an electronic device is powered on for the first time are usually different from those performed on subsequent power-ups. For example, upon first power-up, the operating system of an electronic device performs initialization operations such as hardware detection, creating system configuration files, and setting default parameters. On subsequent power-ups, the operating system typically skips these initialization steps and directly starts services. Therefore, when an electronic device powers on, the file locking module can confirm whether the device is being powered on for the first time by detecting whether the operating system has performed the initialization operations specific to first power-up. For example, let's take the initialization operations specific to first power-up, including hardware detection, as an example. When the electronic device powers on, the file locking module can detect whether the operating system has performed a hardware detection operation. If a hardware detection operation has been performed, it confirms that the electronic device is being powered on for the first time. If a hardware detection operation has not been performed, it confirms that the electronic device is not being powered on for the first time. If it is confirmed that the electronic device is being powered on for the first time, the following steps can be executed. If it is confirmed that the electronic device is not being powered on for the first time, the current process ends.

[0089] Upon initial power-on, the electronic device can load configuration information. This configuration information may include the application identifier of target application a (such as the package name of target application a) and the file identifier of the file a to be locked for target application a. For example, the configuration information can be a configuration table, allowing the electronic device to find the file identifier of the file a to be locked corresponding to the package name of target application a as indicated in the configuration table. The file a to be locked is read from external storage into memory, obtaining the first page frame containing the file a to be locked in memory, and a locking flag is configured on the first page frame. Specifically, the steps of the above process may include the following S102-S111.

[0090] S102, the file locking module loads the configuration table, which includes the package names of multiple target applications a, and the file identifier of the file a to be locked corresponding to each package name.

[0091] As described above, a configuration table can be used to define configuration rules for a file locking module, indicating the files it needs to lock. For example, for applications with large APK, DEX, or ODEX files that the operating system frequently needs to access, such an application can be designated as target application 'a', and its package name can be configured in the configuration table. For larger files within target application 'a', these can be designated as the files that target application 'a' needs to lock, and their file identifiers can be configured in the configuration table. Therefore, the configuration table is used to indicate the files that each target application 'a' needs to lock. For example, the files that target application 'a' needs to lock can be one or more of APK, DEX, or ODEX files; different target applications 'a' can need to lock files of the same or different types.

[0092] In possible embodiments, target application a may be an application pre-installed on the electronic device at the factory. Target application a may also be an application installed by the user during use of the electronic device. Target application a may be a system application or a third-party application.

[0093] In the configuration table, the files that each target application 'a' needs to lock can be represented by the file identifier of that file. For example, the file extension can be used as the file identifier, such as .apk, .dex, or .odex. For example, the files that each target application 'a' needs to lock, included in the configuration table, can also be referred to as the files to be locked, 'a'.

[0094] Understandably, the configuration table can be pre-configured in the electronic device, such as in the file locking module of the electronic device. The configuration table can be a table file. As an example, the configuration table can include the package names of multiple target applications 'a', and the file identifier of at least one file 'a' to be locked corresponding to each package name. Here, the package name is a unique identifier for the application in the operating system. For example, target applications 'a' may include: WebView plugin, Fast Engine plugin, application 2, application 3, and application 4. The package name of the WebView plugin could be com.google.android.webview. The package names of other target applications 'a' are similar and will not be illustrated further. An example configuration table can be shown in Table 1 below.

[0095] Table 1

[0096]

[0097] Based on Table 1, for the WebView plugin, the file to be locked, 'a', can include the WebView plugin's DEX file. For the Fast Engine plugin, the file to be locked, 'a', can include the Fast Engine plugin's ODEX file. For Application 2, the file to be locked, 'a', can include both the Application 2's APK and DEX files. For Application 3, the file to be locked, 'a', can include the Application 3's ODEX file. For Application 4, the file to be locked, 'a', can include the Application 4's APK, DEX, and ODEX files.

[0098] After confirming that the file to be locked is file a, the electronic device can obtain the file path and file size of file a, create a blank page frame in memory, locate the file a in external storage according to the file path, and map data of equal size to the file a to the blank page frame to obtain the corresponding page frame. The page frame obtained by the mapping can be the first page frame in this application. Specifically, the steps of the above process can include the following S103-S107.

[0099] S103, the file locking module sends a request to the application package management service. The request is used to request the file path and file size of the file a to be locked.

[0100] Understandably, the request information may include the package name of the target application 'a' and the file identifier of the file 'a' to be locked. After receiving the request information, the application package management service can query the file path and file size of the file 'a' to be locked based on the package name and file identifier carried in the request information.

[0101] In some embodiments, the application package management service can query the installation path of the application corresponding to the package name, and then identify the file path of the file to be locked, 'a', within the application's installation path. For example, for a WebView plugin, the installation path of the WebView plugin can be queried based on its package name. Using the file identifier (such as the file extension .dex) of the WebView plugin's file to be locked, the file path corresponding to the WebView plugin's dex file can be found within that installation path, such as data / dalvik-cache / arm64 / product@app@WebViewGoogle@WebViewGoogle.apk@classes.dex.

[0102] The file path of a file is unique within the operating system, and this path can be used to identify the file in the file system. The file system maintains metadata for all files (such as file size, creation time, modification time, etc.). The application package management service can initiate a query request to the file system via the file path to obtain the metadata of the file to be locked, 'a', and extract the file size of 'a' from the metadata, such as in bytes. The file size of 'a' represents the actual storage space occupied by 'a'.

[0103] S104, The application package management service sends the file path and file size of the file to be locked, a, to the file locking module.

[0104] After the application package management service obtains the file path and size of the file to be locked ('a') based on the received request information, it can send these details to the file locking module. For example, the application package management service can send the file path (data / dalvik-cache / arm64 / product@app@WebViewGoogle@WebViewGoogle.apk@classes.dex) and file size of the WebView plugin's dex file to the file locking module.

[0105] S105, the file locking module generates a read instruction based on the file path and file size of the file to be locked, and the read instruction is used to instruct the file system to read data of the same size as the file into memory according to the file path.

[0106] S106, the file locking module sends a read command to the file system.

[0107] S107, in response to the read command, the file system reads data of equal size to the file into memory according to the file path, and obtains the corresponding page frame and the page frame identifier.

[0108] Understandably, reading refers to the operation of retrieving data from external storage or other storage media and storing it in memory. Specifically, the file system can read data equal to the file size into memory according to the file path; this process is also known as memory-mapped files. After the file system completes the memory-mapped file operation, the contents of the file to be locked, 'a', will exist in the page cache of memory in the form of page frames. A file mapped into memory often corresponds to one or more page frames, each with a unique page frame identifier, such as a page frame number. The operating system uses these page frame identifiers to manage the use and reclamation of page frames in memory.

[0109] For example, for a WebView plugin's dex file, the file system can read data of the same size as the dex file into memory based on its file path. This completes the process of reading the dex file into memory, mapping it to n page frames. Furthermore, it determines the page frame number for each of these n page frames.

[0110] S108, the file system sends the page frame identifier of the page frame to the file locking module.

[0111] S109, the file locking module generates a locking instruction based on the page frame identifier of the page frame. The locking instruction is used to indicate that the page frame corresponding to the page frame identifier is locked in memory.

[0112] S110, the file locking module sends a locking command to the locking interface.

[0113] Understandably, the locking interface, also known as mlock, can be run in the kernel as a system call function to force some page frames to remain resident in memory, preventing them from being reclaimed or swapped out to disk by the operating system.

[0114] S111, the locking interface responds to the locking command by adding a locking flag to the page frame corresponding to the page frame identifier. The locking flag is used to indicate that page frames should not be recycled.

[0115] Understandably, the locking interface can add a corresponding locking flag to the page frame corresponding to the page frame identifier in the locking instruction. This locking flag can also be called `vm_locked`. For page frames with this locking flag, the memory management module will be prohibited from reclaiming or swapping them out.

[0116] By locking time-consuming files that applications need to read from external storage in memory after the electronic device is first powered on, the system ensures that application threads can access these files from memory when the application runs for the first time. This avoids thread blocking caused by waiting for files to be read from external storage, thus ensuring fast application startup and normal operation. Furthermore, locking files in memory reduces the frequency of file reads from external storage, lowering power consumption and extending the device's lifespan.

[0117] As described in the preceding embodiments, after the electronic device is powered on for the first time, the electronic device can execute S101-S111 to lock the file that needs to be locked for the target application a indicated in the configuration table in memory. That is, the step of locking the first file in the memory of the electronic device is triggered after the electronic device is powered on for the first time. For the target application a indicated in the configuration table, there are some applications whose files that need to be locked may be updated due to compilation optimization. Therefore, for these applications, in addition to locking the files that need to be locked in memory after the electronic device is powered on for the first time, the updated files obtained after compilation optimization can also be locked in memory after the files that need to be locked are compiled optimized. That is, the step of locking the first file in the memory of the electronic device is also triggered after the compilation optimization is completed. For example, when target application 'a' is a fast engine plugin, after the electronic device is first powered on, steps S101-S111 are executed to lock the files that need to be locked in the fast engine plugin in memory. When the files that need to be locked in the fast engine plugin are optimized during compilation, the step of locking the first file in the memory of the electronic device is triggered again, locking the updated file obtained after the compilation optimization of the fast engine plugin in memory. As another example, when target application 'a' is a WebView plugin, the WebView plugin can trigger steps S101-S111 only after the electronic device is first powered on, without participating in the step of locking the first file in the memory of the electronic device triggered after compilation optimization.

[0118] The following example, using a scenario of compiling and optimizing an electronic device, details the steps provided in this application to lock a first file in the memory of the electronic device. Specifically, when a compilation optimization condition is triggered, the electronic device can compile and optimize a file of a second application, read the optimized file from the external storage of the electronic device into its memory, and lock the corresponding page frame in memory. The optimized file can be the second file of the second application in this application, and the optimized file can be the first file of the second application in this application. Figure 7 As shown, the process of locking the first file in the memory of the electronic device triggered by the compilation optimization of the aforementioned electronic device may include the following steps: S201-S218. In S201-S218, the description is based on the example of target application b being the second application and the file to be locked b being the first file.

[0119] S201, The compilation optimization module detected that the compilation optimization condition was triggered and determined the target application b that needs to be compiled and optimized this time.

[0120] For example, locking the file 'b' in the electronic device's memory when a compilation optimization condition is detected as being triggered ensures that if an application, such as target application 'b', updates some files, the electronic device can promptly lock the updated files in memory. This way, when threads access these updated files, they can directly retrieve the updated files from the memory's page cache.

[0121] For example, the conditions that trigger compilation optimization may include one or more of the following:

[0122] Scenario 1: Application installation;

[0123] Scenario 2: The application's code execution frequency reaches a certain preset value;

[0124] Scenario 3: Operating system updates for electronic devices, etc.

[0125] In scenario 1 above, target application b is the currently installed application; there can be one or more currently installed applications. In scenario 2 above, target application b is an application whose current code execution frequency reaches a preset value; there can be one or more applications whose current code execution frequency reaches the preset value. In scenario 3 above, target application b is an application that the updated operating system indicates requires compilation optimization, such as system applications or third-party applications that need to be compatible with the updated operating system; there can be one or more applications that the updated operating system indicates require compilation optimization.

[0126] In some embodiments, if a compilation optimization condition is detected, the target application b that needs to be compiled and optimized is identified. If the target application b that needs to be compiled and optimized is identified, the following steps can be performed. If no compilation optimization condition is detected, the compilation optimization condition can be detected again.

[0127] S202, The compilation optimization module performs compilation optimization on the target application b.

[0128] For example, the process of performing compilation optimization on target application b may include: translating the application's source code in the dex file of target application b into binary code that can be directly recognized by the electronic device, and storing this binary code in external storage as an odex file. The odex file and the dex file have different file paths in the external storage. For example, the odex file occupies more storage space than the dex file.

[0129] S203, the compilation optimization module sends compilation optimization information to the file locking module, including the package name of the target application b.

[0130] Understandably, compilation optimization conditions may be triggered multiple times. Each time a compilation optimization condition is triggered, the compilation optimization module will initiate a round of compilation optimization for the corresponding target application b. Furthermore, because there are various compilation optimization conditions, the application requiring compilation optimization may be different each time, or it may be the same.

[0131] The following example uses the scenario of this compilation optimization being the nth round of compilation optimization. S204-S218 describes the locking process for certain files of the target application b after the nth compilation optimization. Specifically, the compilation optimization module obtains the compilation optimization information for the nth round based on the package name of the target application b participating in the nth compilation optimization and sends it to the file locking module. For example, after each compilation optimization ends, the process in S204-S218 is triggered after the compilation optimization module sends the compilation optimization information to the file locking module.

[0132] After this compilation optimization, the electronic device can confirm whether the configuration information contains the application identifier of the application participating in this compilation optimization. For example, if the configuration information is detected, such as the configuration table showing that target application b participated in this compilation optimization, the electronic device can look up the file identifier of the file b to be locked corresponding to the package name of target application b indicated in the configuration table. The file b to be locked is read from external storage into memory, obtaining the first page frame where the file b to be locked is located in memory, and a locking flag is configured on the first page frame. Specifically, the steps of the above process may include the following S204-S218.

[0133] S204, The file locking module determines whether a target package name exists in the configuration table. The target package name is the same as the package name carried in the compilation optimization information among the application package names contained in the configuration table.

[0134] Understandably, we can check if the package name carried in the compilation optimization information exists in the configuration table to confirm whether the target application b indicated in the compilation optimization information is the application that needs file locking as indicated in the configuration table. If it exists, then we confirm that the target package name exists in the configuration table. For example, the configuration table includes the package names of the Fast Engine plugin, application 3, and application 4, and the compilation optimization information includes the package names of the Fast Engine plugin and application 4. If we find that the package names of the Fast Engine plugin and application 4 exist in both the compilation optimization information and the configuration table, we confirm that the Fast Engine plugin and application 4 indicated in the compilation optimization information are the applications that need file locking as indicated in the configuration table, and we confirm that the package names of the Fast Engine plugin and application 4 are the target package names.

[0135] In a possible implementation, if the target package name does not exist in the configuration table, the process ends.

[0136] After confirming that target application b has participated in this compilation optimization, the electronic device can obtain the file of target application b locked in memory when the electronic device is first powered on, or the file obtained after the previous compilation optimization of the target application b's dex file (also referred to as the second file) before the current compilation optimization conditions are triggered. The locking marker is then removed from the page frame corresponding to the obtained file in memory. The obtained file of target application b can be the third file of the second application in this application, and the page frame corresponding to the third file can be the second page frame in this application. Specifically, the steps of the above process may include the following S205-S209.

[0137] S205, if the file locking module determines that the target package name exists in the configuration table, it confirms the file identifier of the file b to be locked corresponding to the target package name, as well as the page frame of the file b to be locked last time.

[0138] For example, the file locking module can record the page frame identifier (e.g., page frame number) of the page frame corresponding to the file locked in memory after each file locking operation. That is, the file locking module records the page frame identifier of the page frame corresponding to file b in memory when it was last locked in memory. For instance, if the target package name indicates a fast engine plugin, and the configuration table indicates the file identifier of the odex file corresponding to the package name of the fast engine plugin, and the files that the fast engine plugin needs to lock include its odex file, then the file locking module can obtain the page frame identifier of the page frame corresponding to the odex file of the fast engine plugin in memory when it was last locked in memory.

[0139] S206, the file locking module generates an unlock instruction based on the page frame identifier of the page frame that the file b to be locked was previously locked in memory. The unlock instruction is used to instruct the locking interface to unlock the page frame that the file b to be locked was previously locked in memory.

[0140] S207, the file locking module sends an unlock command to the locking interface.

[0141] S208, the locking interface responds to the unlock command by deleting the lock mark from the page frame of the file b to be locked that was previously locked in memory.

[0142] Understandably, the locking interface can use the page frame identifiers included in the unlock instruction to identify the page frames that were previously locked in memory for the file b to be locked, and then remove the locking markers from these page frames. In this way, the page frames with their locking markers removed can be reclaimed by the memory management module, preventing older versions of the file from continuing to occupy memory space before this compilation optimization.

[0143] S209, the locking interface sends unlocking information to the file locking module. The unlocking information is used to indicate that the unlocking command has been completed.

[0144] S210, the file locking module sends a request to the application package management service. The request is used to request the file path and file size of the file b to be locked.

[0145] For example, the file path corresponding to the odex file of the Quick Engine plugin can be found in the installation path by using the file identifier (such as the file extension .odex) of the file to be locked in the Quick Engine plugin, such as data / app / ~~zgmMM_L70uQoEzgf_n3gZg== / com.hihonor.quickengine-szOsKh8279GGHwSHr-r0Xw== / oat / arm64 / base.odex.

[0146] S211, The application package management service sends the file path and file size of the file to be locked, b, to the file locking module.

[0147] S212, the file locking module generates a read instruction based on the file path and file size of the file b to be locked. The read instruction is used to instruct the file system to read data of the same size as the file into memory according to the file path.

[0148] S213, the file locking module sends a read command to the file system.

[0149] S214, in response to the read command, the file system reads data of equal size to the file into memory according to the file path, and obtains the corresponding page frame and the page frame identifier.

[0150] S215, the file system sends the page frame identifier of the page frame to the file locking module.

[0151] S216, the file locking module generates a locking instruction based on the page frame identifier of the page frame. The locking instruction is used to indicate that the page frame corresponding to the page frame identifier is locked in memory.

[0152] S217, the file locking module sends a locking command to the locking interface.

[0153] S218, the locking interface responds to the locking command by adding a locking flag to the page frame corresponding to the page frame identifier. The locking flag is used to indicate that page frames should not be recycled.

[0154] For example, the implementation details of S210-S218 can be found in the detailed description of the corresponding content in S103-S110 of the foregoing embodiments, and will not be repeated here in the embodiments of this application.

[0155] Understandably, the memory management module will prevent page frames marked with a lock from being reclaimed or swapped out. This ensures that the files in memory are the latest version of the application, allowing application threads to access them promptly. Furthermore, optimized application files are typically large, and reading them from external storage is time-consuming. Locking these files in memory saves reading time, preventing thread blocking due to excessively large optimized files and ensuring the normal operation of the application.

[0156] The following example, using the initialization of the WebView plugin, illustrates the effect of the above display method.

[0157] For example, the above display method can be used to lock the WebView plugin's dex file in memory after the electronic device is first powered on. By mapping the WebView plugin's dex file to the memory's page cache and locking it, it can be ensured that when the WebView plugin is initialized, the thread can always access the WebView plugin's dex file from memory, and the WebView plugin's dex file will not be reclaimed or swapped out to external storage by the operating system.

[0158] In such Figure 1In the scenario shown, the electronic device needs to load the details of article 1 via the WebView plugin to create the details interface 106. Before using the WebView plugin on the electronic device, the WebView plugin needs to be initialized, which includes reading the WebView plugin's dex file.

[0159] For example, in the process of composing the details interface 106 corresponding to article 1, the threads involved may include the UI thread, the rendering thread, and the SurfaceFlinger thread. Figure 8 As shown, the WebView plugin is initialized by the UI thread in response to user actions.

[0160] During the initialization of the WebView plugin, the UI thread needs to read the WebView plugin's dex file. At this time, the UI thread can send a request to the kernel-level virtual file system to read the WebView plugin's dex file. The virtual file system uses the inode of the WebView plugin's dex file to find the corresponding page frame in the memory's page cache. For example, the inode of the WebView plugin's dex file includes the page frame number of the corresponding page frame in memory; the page frame number in the inode can be used to find the corresponding page frame in the page cache.

[0161] After the UI thread reads the WebView plugin's dex file from the page cache in memory, the WebView plugin can be run to load the details of article 1. The rendering thread and SurfaceFlinger thread wait for the UI thread to download the details of article 1 through the WebView plugin and to draw the page image corresponding to article 1 based on the webpage content. After the UI thread draws the page image corresponding to article 1, the rendering thread renders the page image drawn by the UI thread to obtain the rendered image. The SurfaceFlinger thread uses the rendered image to composite the results, obtaining the details interface 106 for article 1.

[0162] Understandably, memory access speed is much faster than external storage access speed. Memory access latency ranges from tens to hundreds of nanoseconds, while external storage access latency ranges from a few milliseconds to tens of milliseconds. Therefore, for a WebView plugin's dex file, the time to read the file from memory will be significantly less than the time to read it from external storage. Thus, compared to... Figure 2 The time T1 taken for the UI thread to read the WebView plugin's dex file from external storage. Figure 8The time T5 spent by the UI thread reading the WebView plugin's dex file from external storage is reduced. This means the rendering thread and SurfaceFlinger thread don't have to wait as long, decreasing the time T6 spent compositing the details screen 106, ensuring fast loading of the details screen 106, and improving the user experience.

[0163] The following example, using the initialization of the Fast Engine plugin, illustrates the effect of the above display method.

[0164] For example, the above-described display method can be used to lock the odex file of the fast engine plugin in memory after the compilation optimization module performs compilation optimization. By mapping the odex file of the fast engine plugin to the page cache in memory and locking it, it can be ensured that when the fast engine plugin is initialized, the thread can always access the odex file of the fast engine plugin from memory, and the odex file of the fast engine plugin will not be reclaimed or swapped out to external storage by the operating system.

[0165] In such Figure 3 In the scenario shown, as the electronic device unlocks and switches from the lock screen 201 to the desktop 101, an unlocking animation needs to be displayed.

[0166] For example, when a desktop application composites the image frames for an unlock animation, the threads involved may include the UI thread, the rendering thread, and the SurfaceFlinger thread. During the process of rendering the unlock animation in the desktop application, the UI thread also needs to initialize the Fast Engine plugin, which includes reading the Fast Engine plugin's odex file. For example... Figure 8 As shown, in response to the user unlocking the device, the desktop application begins drawing the unlock animation. After the UI thread of the desktop application completes the drawing of image frame 1 of the unlock animation, the rendering thread renders image frame 1 based on the drawing results of the UI thread. Then, the SurfaceFlinger thread uses the rendering results to composite image frame 1 for display. Next, in response to the initialization request for the Fast Engine plugin, the UI thread of the desktop application reads the odex file of the Fast Engine plugin. At this time, the UI thread can send a request to the kernel-level virtual file system to read the odex file of the Fast Engine plugin. The virtual file system uses the inode of the Fast Engine plugin's odex file to find the page frame corresponding to the odex file in memory. For example, the inode of the Fast Engine plugin's odex file includes the page frame number of the corresponding page frame in memory, and the page frame corresponding to the odex file can be found through the page frame number in the inode.

[0167] Next, after the UI thread completes the initialization of the Fast Engine plugin, the rendering thread and the SurfaceFlinger thread continue to draw the next frame of the unlock animation, such as frame 2. After the UI thread completes the drawing of frame 2, the rendering thread renders frame 2 based on the UI thread's drawing results, and the SurfaceFlinger thread uses the rendering results to composite frame 2.

[0168] Understandably, for the odex file of the fast engine plugin, the time to read the file from memory will be much shorter than the time to read it from external storage. Thus, compared to... Figure 4 The time T3 spent by the UI thread reading the odex file of the fast engine plugin from external storage. Figure 9 The time T7 spent by the UI thread reading the odex file of the Fast Engine plugin from memory is reduced. This significantly reduces the time for the UI thread to initialize the Fast Engine plugin, allowing the UI thread to complete the drawing of image frame 2 in a timely manner. The rendering thread and SurfaceFlinger thread do not need to wait for a long time, reducing the time T8 spent compositing image frame 2. This avoids frame drops during the unlock animation display and improves the user experience.

[0169] This application also provides an electronic device that may include a memory and one or more processors. The memory and processors are coupled. The memory stores computer program code, which includes computer instructions. When the processor executes the computer instructions, it causes the electronic device to perform the steps described in the above embodiments. Of course, the electronic device includes, but is not limited to, the memory and one or more processors described above.

[0170] The processor may include one or more processing units, such as an application processor (AP), a modem processor, a graphics processing unit (GPU), an image signal processor (ISP), a controller, memory, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural network processing unit (NPU). Different processing units may be independent devices or integrated within the same processor.

[0171] The controller is the nerve center and command center of the electronic device. Based on the instruction opcode and timing signals, the controller generates operation control signals to control the fetching and execution of instructions.

[0172] Electronic devices utilize GPUs, displays, and application processors to achieve their display functions. A GPU is a microprocessor for image processing, connecting the display and the application processor. GPUs perform mathematical and geometric calculations and are used for graphics rendering. A processor may include one or more GPUs, which execute program instructions to generate or modify display information.

[0173] The display screen is used to display images, graphical user interfaces (GUIs), or videos. Display screen 194 includes a display panel. The display panel may be a liquid crystal display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode (AMOLED), a flexible light-emitting diode (FLED), a minimized display, a microLED, a micro-OLED, a quantum dot light-emitting diode (QLED), etc. In some embodiments, the electronic device may include one or N displays, where N is a positive integer greater than 1.

[0174] The processor may also include memory for storing instructions and data. In some embodiments, the memory in the processor is a cache memory. This memory can hold instructions or data that the processor has just used or that are used repeatedly. If the processor needs to use the instruction or data again, it can retrieve it directly from memory. This avoids repeated accesses, reduces processor wait time, and thus improves system efficiency.

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

[0176] The I2C interface is a bidirectional synchronous serial bus that includes a serial data line (SDA) and a serial clock line (SCL). In some embodiments, the processor may include multiple I2C buses.

[0177] In some embodiments, as described above, those skilled in the art will clearly understand that, for the sake of convenience and brevity, the division of the functional modules described above is merely an example. In practical applications, the functions described above can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. The specific working process of the system, device, and unit described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0178] This application also provides a chip system that can be applied to the electronic devices described in the foregoing embodiments. The chip system includes at least one processor and at least one interface circuit. The processor may be the processor in the aforementioned electronic device. The processor and the interface circuit are interconnected via wiring. The processor can receive and execute computer instructions from the memory of the aforementioned electronic device through the interface circuit. When the computer instructions are executed by the processor, the electronic device can perform the various steps in the foregoing embodiments. Of course, the chip system may also include other discrete devices, and this application does not specifically limit this.

[0179] In the embodiments of this application, the functional units can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0180] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, essentially, or the parts that contribute to the prior art, or all or part of the technical solutions, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as flash memory, portable hard disk, read-only memory, random access memory, magnetic disk, or optical disk.

[0181] The above description is merely a specific implementation of the embodiments of this application, but the protection scope of the embodiments of this application is not limited thereto. Any changes or substitutions within the technical scope disclosed in the embodiments of this application should be covered within the protection scope of the embodiments of this application. Therefore, the protection scope of the embodiments of this application should be determined by the protection scope of the claims.

Claims

1. A display method, characterized in that, Applied to electronic devices, the method includes: Display the first interface of the first application; In response to a first operation on the first interface, a second interface is displayed; Specifically, before displaying the second interface after receiving the first operation, the second application is initialized, and the first file required for the initialization of the second application is locked in the memory of the electronic device.

2. The method according to claim 1, characterized in that, The electronic device stores the first file in its memory. The first page frame containing the first file is configured with a lock flag, which is used to indicate that the first page frame is prohibited from being reclaimed.

3. The method according to claim 1 or 2, characterized in that, Before displaying the first interface of the first application, the method further includes: In response to the first power-on of the electronic device, the first file of the second application is read from the external storage of the electronic device into the memory; The first file is locked in the memory.

4. The method according to claim 3, characterized in that, After the first file is read from the external storage into the memory, it is stored in the memory in the form of page frames, and the page frame containing the first file is the first page frame; Locking the first file in the memory includes: Configure a lock flag for the first page frame.

5. The method according to claim 4, characterized in that, Before reading the first file of the second application from the external storage of the electronic device into the memory, the method further includes: Get the file path and file size of the first file; The step of reading the first file of the second application from the external storage of the electronic device into the memory includes: Create a blank page frame; The first file is located in the external storage according to the file path, and data of the same size as the file is mapped to the blank page frame to obtain the first page frame.

6. The method according to claim 1 or 2, characterized in that, Before displaying the first interface of the first application, the method further includes: In response to the triggering of compilation optimization conditions, the second file of the second application is compiled and optimized to generate the first file; wherein, the compilation optimization conditions include at least one of the following: the second application is installed, the execution frequency of the code of the second application exceeds a preset frequency value, and the operating system of the electronic device is updated.

7. The method according to claim 6, characterized in that, The method further includes: The first file is read from the external storage of the electronic device into the memory. After the first file is read into the memory, it is stored in the memory in the form of page frames. The page frame in which the first file is located is the first page frame. Configure a lock flag for the first page frame.

8. The method according to claim 7, characterized in that, The method further includes: Obtain the page frame identifier of the second page frame where the third file is located; wherein, the third file is the file of the second application locked in the memory when the electronic device is first powered on, or, the third file is the file obtained after the last compilation optimization of the second file before the current compilation optimization condition is triggered; Based on the page frame identifier, remove the lock mark of the second page frame.

9. The method according to any one of claims 1-8, characterized in that, The second application is an application whose application identifier is included in the configuration information of the electronic device; the first file is a file whose file identifier is included in the configuration information of the second application. The configuration information is used to indicate the files of applications in the electronic device that need to be locked in the memory.

10. The method according to any one of claims 1-9, characterized in that, The first file is one or more of the apk file, dex file, or odex file of the second application.

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

12. A computer-readable storage medium comprising instructions, characterized in that, When the instructions are executed on an electronic device, the electronic device causes the electronic device to perform the method as described in any one of claims 1-10.

13. A computer program product, characterized in that, The computer program product includes a computer program or instructions that, when executed on an electronic device, cause the electronic device to perform the method as described in any one of claims 1-10.

Images