Data loading method, electronic device and storage medium

Abstract

The present application provides a data loading method, an electronic device and a storage medium, and relates to the field of terminal technology. When starting or running the first application, due to the system having load occupying resources, the second thread may not be able to load the target data in time because it cannot be scheduled in time, so that the first thread cannot read the target data in time. The present application scheme does not adopt the system default loading process, that is, the target data required for starting the first application is not loaded through the second thread, but in some scenarios, the first thread replaces the second thread to perform the data loading task, speeding up the data loading progress, and in other scenarios, by raising the scheduling priority of the second thread, the data loading task is processed first, thereby realizing the rapid startup of the application. The present application scheme can avoid the problem of slow application startup or slow response caused by the inability of a certain thread to be scheduled in time and unable to load data in time when the application is started or running, thereby blocking another thread.

Description

Technical Field

[0001] The present application relates to the field of terminal technology, and in particular to a data loading method, an electronic device and a storage medium. Background Art

[0002] SharedPreferences is a lightweight data storage method provided by the Android system. For example, when the application is running, the application can write the configuration data of some user settings (such as video playback progress, whether to automatically update, and other settings) to the memory associated with the SharedPreferences object, and then write it from the memory to the hard disk. When the application is started again, the UI thread of the application calls the SharedPreferences child thread to load the configuration data previously stored on the hard disk into the memory, and then the UI thread reads the configuration data from the memory to start or respond to the application.

[0003] However, the default scheduling priority value of the SharedPreferences child thread is 120. When the system load is high, it cannot be scheduled in time, causing the UI thread to wait in the awaitLoadedLocked function for the SharedPreferences child thread to load the data before it can read the data and run. This causes performance issues such as slow application startup and slow application response. Summary of the invention

[0004] The present application provides a data loading method, an electronic device and a storage medium. In the scenario where an application is started when the system is under load, the system default loading process may not be used, and the thread that loads the target data required for starting the application may be replaced, thereby speeding up the data loading progress and improving the application startup speed.

[0005] In a first aspect, the present application provides a data loading method, the method comprising: at a first time point, starting a first application; after the first time point, creating a first thread and a second thread of the first application; at a second time point, starting to load target data through the first thread; after the second time point, destroying the second thread; after loading the target data, at a third time point, displaying the main interface of the first application; wherein, between the first time point and the third time point, the second application is running in the background.

[0006] It should be noted that the present application solution can be applied to the scenario of starting the first application when the second application is running in the background, that is, the scenario of starting a certain application when the system is under load. In the scenario of starting the first application when the system is under load, according to the Android default policy, the system defaults to the second thread (such as the child thread) to load the target data required for starting the first application, and the first thread (such as the main thread) needs to wait for the data to be loaded before reading the target data. However, the second thread cannot be scheduled in time and cannot load the data in time, thus blocking the first thread, which will cause the problem of slow application startup or slow application response.

[0007] By the data loading method provided by the embodiment of the present application, in the scenario of starting the first application when the system is under load, after creating the first thread and the second thread of the first application, since the system has other loads and needs to schedule resources, the second thread may not be able to load the target data in time due to the inability to be scheduled in time, so that the first thread cannot read the target data in time. In this case, the present application scheme does not adopt the system default loading process, that is, the target data required for the first application to start or run is not loaded through the second thread, but is adjusted to load the target data through the first thread to speed up the data loading progress. In this way, the first thread actively completes the data loading task without waiting for the second thread to complete. After quickly completing the data loading, the first thread directly obtains the target data, thereby realizing the rapid startup of the first application. The present application scheme avoids the problem that the second thread cannot load data in time due to the inability to be scheduled in time when the system is under load, thereby blocking the first thread, causing the application to start slowly or the application to respond slowly.

[0008] In some possible implementations, the scheduling priority of the second thread is lower than the scheduling priority of the first thread. In this way, the data loading task can be completed by replacing the second thread with a low scheduling priority with the first thread with a high scheduling priority, thereby accelerating the data loading progress and realizing the quick startup of the first application.

[0009] In some other possible implementations, the method also includes: after exiting the first application and the second application, starting the first application at a fourth time point; after the fourth time point, creating the first thread and the second thread of the first application; at a fifth time point, starting to load the target data through the second thread; after loading the target data, at a sixth time point, displaying the main interface of the first application; wherein, after the sixth time point, the second thread is destroyed; and between the fourth time point and the sixth time point, the second application is not running in the background.

[0010] Through the above scheme of the present application, in the scenario where the first application is started when the second application is not running in the background, after creating the first thread and the second thread of the first application, due to the low load or no load of the system, the second thread can be scheduled in time, and the target data required for starting the first application can be loaded in time, and the first thread can also read the target data in time accordingly. In this case, the system default loading process can be adopted, that is, the second thread (such as the child thread) loads the target data, and after the loading is completed, the first thread (such as the main thread) reads the target data, and then the first application is started and the main interface of the first application is displayed. Therefore, the scheme of the present application can avoid the problem that the second thread of the application cannot be scheduled in time and cannot load data in time, thus blocking the first thread, causing the application to start slowly or respond slowly.

[0011] In some further possible implementations, the method further includes: at a seventh time point, starting to launch the first application; after the seventh time point, creating the first thread and the second thread of the first application; at an eighth time point, starting to load the target data through the second thread; after loading the target data, at a ninth time point, displaying the main interface of the first application; wherein, between the eighth time point and the ninth time point, the scheduling priority of the second thread is increased; and after the ninth time point, the second thread is destroyed.

[0012] It should be noted that in the Android default policy, the second thread has a default scheduling priority. In the scenario where the first application is started when the system is under load, the system defaults to the second thread loading the target data and the first thread reading the target data after the data is loaded. However, the second thread cannot be scheduled in time and cannot load data in time due to its low scheduling priority, thus blocking the first thread and causing slow application startup or slow application response.

[0013] Through the above-mentioned scheme of the present application, in the scenario of starting the first application, after creating the first thread and the second thread of the first application, because the system has other loads that need to schedule resources, it may happen that the second thread cannot be scheduled in time and cannot load the target data in time, so that the first thread cannot read the target data in time. In this case, the scheme of the present application does not adopt the system default loading process, that is, the second thread is no longer scheduled according to the default scheduling priority, but the scheduling priority of the second thread is increased, so that the second thread is quickly scheduled to load the target data required for starting the first application, speeding up the data loading progress, thereby reducing the waiting time of the first thread. After quickly completing the data loading, the first thread directly obtains the target data, thereby realizing the rapid startup of the first application. The scheme of the present application avoids the problem that when the system is loaded, the second thread cannot load the data in time because it cannot be scheduled in time, thereby blocking the first thread, causing the application to start slowly or respond slowly.

[0014] In some possible implementations, the first thread is a user interface UI thread (ie, a main thread), the second thread is a SharedPreferences subthread, and the target data is application configuration data stored in a SharedPreferences storage manner.

[0015] It should be noted that SharedPreferences is a lightweight data storage method provided by the Android system. Data is saved in an XML file in the form of key-value pairs to form SharedPreferences data. Each application may have many such XML files. When an application installed in an electronic device reads or writes SharedPreferences data, it needs to load / parse the XML file into memory first. The system loads it by creating a new SharedPreferences child thread (priority 120).

[0016] It should also be noted that when the system load is high, the SharedPreferences child thread often cannot be scheduled in time due to its low priority. When the UI thread requests to read or write data, the SharedPreferences child thread has not started loading or has not finished loading, and the UI thread waits for a long time for the SharedPreferences child thread to finish loading. In other words, when the SharedPreferences child thread has not started loading or has not finished loading, if the application UI thread or other child threads read data, then the application UI thread or other child threads need to wait until the SharedPreferences child thread completes the data loading task before they can read the data. The SharedPreferences child thread blocks the execution of the application's UI thread or other child threads because it cannot be scheduled in time, which may cause performance issues such as slow startup and slow response, thus affecting the user experience.

[0017] The present application scheme utilizes the high priority and fast execution of the UI thread to speed up the execution of the data loading task, thereby avoiding the SharedPreference child thread from blocking the UI thread due to its low priority and inability to be scheduled in time.

[0018] Scenario 1: When the UI thread requests to read data, the SharedPreferences child thread has not started loading data (it may be that the child thread has not been created yet, or it may be that the child thread has been created but has not yet executed the data loading task). The corresponding processing strategy for this scenario is: the UI thread no longer waits for the SharedPreferences child thread to complete the data loading task as in the Android default strategy, but instead loads the data by the UI thread. After the UI thread completes the data loading task, the UI thread reads the data.

[0019] Scenario 2: When the UI thread requests to read data, the SharedPreferences child thread is already loading data. The corresponding processing strategy for this scenario is: Because the loading task cannot be split, in this case the UI thread adjusts the scheduling priority of the SharedPreferences child thread to speed up the data loading task. After the SharedPreferences child thread completes the data loading task, the UI thread reads the data.

[0020] In the embodiment of the present application, the SetThreadPriority() function can be called to increase the priority of the SharedPreference child thread according to actual needs.

[0021] Scenario 3: When the UI thread requests to read data, the SharedPreferences child thread has already completed data loading. The corresponding processing strategy for this scenario is: the UI thread directly reads data.

[0022] Compared with the Android default strategy, the UI thread side of the present application solution can execute corresponding processing strategies for different data loading states. For example, the UI thread increases the scheduling priority of the SharedPreferences child thread so that the data loading task is processed first. For another example, the UI thread with a high scheduling priority replaces the SharedPreferences child thread to execute the data loading task so that the data loading task is processed first. This can avoid the problem of slow application startup caused by the UI thread waiting for the child thread for a long time.

[0023] In some possible implementations, after creating the first thread of the first application, the method further includes: requesting to read the target data through the first thread.

[0024] Through the scheme of the present application, when the first thread requests to read the target data, the data loading process can be triggered. In the scheme of the present application, in some scenarios (such as low system load), the second thread can load the target data according to the default scheduling priority, in other scenarios (such as high system load, loading state), the second thread can load the target data according to the increased scheduling priority, and in some other scenarios (such as high system load, loading has not started), the first thread can start loading the target data, speeding up the data loading progress, thereby realizing the rapid startup of the first application.

[0025] In some possible implementations, starting to load the target data through the first thread at the second time point includes any of the following implementations:

[0026] Implementation method 1: at a second time point, when loading of the target data has not started, loading of the target data through the first thread starts.

[0027] It should be noted that when the UI thread requests to read data, the SharedPreferences child thread has not started loading data (it may be that the child thread has not been created, or it may be that the child thread has been created but has not yet executed the data loading task). In this case, the UI thread no longer waits for the SharedPreferences child thread to complete the data loading task as in the Android default strategy, but the UI thread loads the data. After the UI thread completes the data loading task, the UI thread reads the data. This allows the first application to be quickly started.

[0028] Implementation method 2: At a second time point, when the target data has not started to be loaded and the first application is a foreground application, the target data is started to be loaded through the first thread.

[0029] Through the above scheme, when the target data has not been loaded and the first application is the foreground application, in order to avoid the foreground application from freezing, the priority of the SharedPreferences child thread can be increased. In this way, the SharedPreferences child thread can be scheduled to perform the data loading task according to the increased priority. After receiving the notification of data loading completion sent by the SharedPreferences child thread, the UI thread of the foreground application can read the data, and the first application can be quickly started.

[0030] In some possible implementations, loading the target data includes: loading the target data from a hard disk into a memory, so that the UI thread can read data required for starting or running the first application from the memory.

[0031] In some possible implementations, after loading the target data, displaying the main interface of the first application at a third time point includes: after loading the target data from the hard disk to the memory, reading the target data from the memory through the first thread; and displaying the main interface of the first application based on the target data at the third time point. In this way, after loading the target data required for starting or running the first application from the hard disk to the memory, the UI thread reads the data from the memory to complete the quick startup and operation of the first application.

[0032] In some possible implementations, the method further includes: calling a first read function to obtain a first variable value from a SharedPreferences object.

[0033] The first read function may be an interface function such as sp.getInt, sp.getString, sp.getBoolean, etc. For ease of description, the following description takes the first read function as the sp.getInt function as an example.

[0034] In some possible implementations, the method further includes: determining, based on a first variable value, that loading of the target data has not started; wherein different first variable values ​​represent different loading states, and the different loading states include: a loading not started state, a loading being done state, and a loading completed state.

[0035] The first variable value may be the mLoaded variable value.

[0036] It should be noted that the default mLoaded variable in the Android default strategy is a Boolean type, which can only indicate whether the SharedPreferences data loading is complete, that is, the mLoaded variable includes two values, one indicating completion and the other indicating incompleteness. When the UI thread (or other child thread) requests to read data, the mLoaded variable value will be obtained. When the data loading status mLoaded is true, the UI thread (or other child thread) reads the data. When mLoaded is false, the UI thread (or other child thread) needs to wait for the SharedPreferences child thread to complete the data loading before obtaining the data. Such a simple processing logic can easily cause the UI thread to wait for a long time, resulting in slow application startup.

[0037] The embodiment of the present application redesigns the value of the mLoaded variable. The three data loading states of "not started loading", "loading", and "loaded" in the embodiment of the present application. In the present application scheme, the awaitLoadedLocked function can be called to analyze and judge the mLoaded value to determine the data loading state. Different processing strategies are adopted for different data loading states to achieve the purpose of giving priority to the execution of data loading tasks. The present application scheme provides the following three processing strategies:

[0038] The first scenario processing strategy: When the mLoaded variable value indicates the "loaded" state, it means that the SharedPreferences child thread has loaded the application configuration data stored in the hard disk into the memory. In this case, the UI thread directly obtains the application configuration data from the memory.

[0039] Second scenario processing strategy: When the mLoaded variable value indicates the "loading data" state, it means that the SharedPreferences child thread is loading the application configuration data stored in the hard disk into the memory and has not yet finished loading. In this case, the UI thread increases the scheduling priority of the SharedPreferences child thread so that the SharedPreferences child thread is scheduled first, so that the data loading task is executed first.

[0040] The third scenario processing strategy: When the mLoaded variable value indicates the "not started loading" state, it means that the SharedPreferences child thread has not started to load the application configuration data stored in the hard disk into the memory. In this case, the data loading task will be replaced by the UI thread instead of the SharedPreferences child thread. Since the scheduling priority of the UI thread is higher than the scheduling priority of the SharedPreferences child thread, the data loading task is adjusted to be executed by the UI thread, so that the data loading task can be executed first.

[0041] In some possible implementations, loading the target data through the first thread includes: updating a first variable value through the first thread, wherein the updated first variable value indicates a loading status; calling a loadFromDisk function through the first thread to load the target data; and after the target data is loaded, updating the first variable value through the first thread, wherein the updated first variable value indicates a loading completion status.

[0042] Through the above solution, when the data loading task is executed through the UI thread, the UI thread updates the mLoaded variable value to avoid the SharedPreferences child thread from repeatedly loading data. After the UI thread completes the data loading task, the UI thread updates the mLoaded variable value to indicate that the data loading is complete.

[0043] In some possible implementations, before calling the read function to obtain the first variable value from the SharedPreferences object, the method further includes: the first thread calling the getSharePreferences function to obtain the SharedPreferences object from the memory; if the SharedPreferences object does not exist in the memory, creating the SharedPreferences object in the memory. The second thread is created when the SharedPreferences object is created.

[0044] It should be noted that the application UI thread obtains the SharedPreferences object by calling the getSharedPreferences() function. If the SharedPreferences object already exists in the memory at this time, it is directly obtained; if the SharedPreferences object does not exist in the memory at this time, the SharedPreferences object is instantiated, and mLoaded is initialized to LOAD_STATE_INIT in the SharedPreferences constructor. Then a SharedPreferences child thread is created to load the SharedPreferences data associated with the SharedPreferences object, which is an XML file.

[0045] In some possible implementations, the method further includes: after the target data is loaded, sending a notification message of completion of loading the target data to a third thread of the first application through the first thread. The third thread may be another subthread of the first application except the first thread and the second thread.

[0046] In some possible implementations, the method further includes: the third thread requests to read the target data; when it is determined that the target data has not started to be loaded or is being loaded, waiting to receive a notification message indicating that the loading is complete and then reading the target data; when it is determined that the target data has been loaded, reading the target data.

[0047] In the present application solution, since the UI thread raises the scheduling priority of the SharedPreferences child thread so that the data loading task is processed first, or the UI thread with a high scheduling priority replaces the SharedPreferences child thread to execute the data loading task so that the data loading task is processed first, the waiting time for other child threads of the application to load data is shortened, thereby avoiding the problem of slow application startup caused by other child threads of the application waiting for a long time. This greatly improves the application startup speed.

[0048] In some possible implementations, destroying the second thread after the second time point includes: after the second time point, determining that the target data is being loaded, and destroying the second thread.

[0049] In the default Android policy, the second thread can be destroyed only after the target data is loaded. The present application scheme uses the first thread to replace the second thread to execute the data loading task, thereby speeding up the data loading progress. Therefore, the second thread can be destroyed after it is determined that the target data is being loaded.

[0050] In some possible implementations, after starting to load the target data through the second thread at the eighth time point, the method further includes: requesting to read the target data through the first thread; and when it is determined that the target data is being loaded, raising the scheduling priority of the second thread through the first thread.

[0051] It should be noted that when the UI thread requests to read data, the SharedPreferences child thread is already loading data. Because the loading task cannot be split, the UI thread adjusts the scheduling priority of the SharedPreferences child thread to speed up the data loading task. After the SharedPreferences child thread completes the data loading task, the UI thread reads the data.

[0052] In some possible implementations, at the eighth time point, starting to load the target data through the second thread includes: at the eighth time point, determining that the target data has not started to be loaded, updating the first variable value through the second thread, and the updated first variable value indicates a loading state; calling the loadFromDisk function through the second thread to load the target data; after the target data is loaded, updating the first variable value through the second thread, and the updated first variable value indicates a loading completion state.

[0053] Through the above scheme, when the SharedPreferences child thread performs the data loading task, the SharedPreferences child thread immediately updates the mLoaded variable value to avoid the UI thread from repeatedly loading data. After the SharedPreferences child thread completes the data loading task, the SharedPreferences child thread immediately updates the mLoaded variable value to indicate that the data loading is complete.

[0054] In some possible implementations, before starting the first application, the method further includes: in response to a user's setting operation on the first application, storing target data corresponding to the first application in a memory based on a SharedPreferences object, and then writing the target data from the memory to a hard disk; and in response to a user operation, closing the first application.

[0055] In some possible implementations, starting the first application includes: displaying a first interface (eg, a desktop), and starting the first application in response to a user clicking an application icon.

[0056] The present application solution can be applied to various application startup scenarios, and can also be applied to response scenarios of interaction with users after the application is started. The present application solution can improve the application startup speed, and can also improve the application response speed.

[0057] It should be noted that the descriptions of the first time point, the second time point, ..., the ninth time point, etc. in this application are named in chronological order, for example, the second time point is later than the first time point, and the third time point is later than the second time point.

[0058] In a second aspect, the present application provides a data loading device, the device comprising a unit for executing the method in the first aspect. The device may correspond to executing the method described in the first aspect, and the relevant description of the unit in the device can refer to the description of the first aspect, which will not be repeated here for the sake of brevity.

[0059] The method described in the first aspect above can be implemented by hardware, or by hardware executing corresponding software. The hardware or software includes one or more modules or units corresponding to the above functions. For example, a processing module or unit, a display module or unit, etc.

[0060] In a third aspect, the present application provides an electronic device, comprising a processor, a computer program or instructions stored in the processor and a memory, wherein the processor is configured to execute the computer program or instructions so that the method in the first aspect is executed.

[0061] In a fourth aspect, the present application provides a computer-readable storage medium on which a computer program (also referred to as instructions or codes) for implementing the method in the first aspect is stored. For example, when the computer program is executed by a computer, the computer can execute the method in the first aspect.

[0062] In a fifth aspect, the present application provides a chip, including a processor. The processor is used to read and execute a computer program stored in a memory to perform the method in the first aspect and any possible implementation thereof. Optionally, the chip also includes a memory, and the memory is connected to the processor via a circuit or wire.

[0063] In a sixth aspect, the present application provides a chip system, including a processor. The processor is used to read and execute a computer program stored in a memory to perform the method in the first aspect and any possible implementation thereof. Optionally, the chip system also includes a memory, and the memory is connected to the processor via a circuit or wire.

[0064] In a seventh aspect, the present application provides a computer program product, which includes a computer program (also referred to as instructions or codes). When the computer program is executed by an electronic device, the electronic device implements the method in the first aspect.

[0065] It can be understood that the beneficial effects of the second to seventh aspects mentioned above can be found in the relevant description of the first aspect mentioned above, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0066] Figure 1 A schematic diagram of an application scenario interface for setting application functions of an electronic device according to user operations is shown.

[0067] Figure 2 Shows Figure 1 Schematic diagram of the specific implementation process of the data writing process and the data reading process in the scenario shown.

[0068] Figure 3 The schematic diagram shows the principle of slow application startup problem in an application startup scenario.

[0069] Figure 4 A schematic diagram of a scenario interface in which an electronic device launches an application in response to a user operation is shown.

[0070] Figure 5 A schematic diagram of the hardware structure of an electronic device provided in an embodiment of the present application is shown.

[0071] Figure 6 It is a software structure block diagram of the electronic device according to an embodiment of the present application.

[0072] Fig. 7AThe flowchart of the scenario in which the UI thread of the application in the Android default strategy requests to read data after the child thread has loaded the data is shown.

[0073] Figure 7B The flowchart of the scenario in which the UI thread of the application in the Android default strategy requests to obtain data while the child thread is loading data is shown.

[0074] Figure 7C The flowchart of the scenario in which the UI thread of the application in the Android default strategy requests to obtain data when the child thread has not started to load data is shown.

[0075] Fig.7D The figure shows a flow chart of how other sub-threads applied in the Android default strategy interact with the SharedPreferences sub-thread to obtain data.

[0076] Figure 8 It is a flow chart of the application UI thread side of the data loading method provided in an embodiment of the present application.

[0077] Fig. 9 It is a flowchart of the SharedPreferences sub-thread side of the data loading method provided in an embodiment of the present application.

[0078] Fig.10 It is a flowchart of the application of other sub-threads of the data loading method provided in an embodiment of the present application.

[0079] Fig.11 It is a schematic diagram of the interactive process of the data loading method provided in the embodiment of the present application.

[0080] Fig.12 The embodiment of the present application is shown based on Fig.11 The process shown provides another exemplary flowchart of the data loading method.

[0081] Fig.13 It is a flowchart of the interaction between the SharedPreferences sub-thread side and other sub-threads of the data loading method provided in an embodiment of the present application. DETAILED DESCRIPTION

[0082] The embodiments of the present application are further described in detail below in combination with specific embodiments and with reference to the accompanying drawings.

[0083] To facilitate understanding of the embodiments of the present application, some terms used in the embodiments of the present application are explained below to facilitate understanding by those skilled in the art.

[0084] (1) Data writing: During the operation of an electronic device, the electronic device first writes data into the memory, and then writes the data from the memory to the hard disk (or disk).

[0085] (2) Data reading: First, the data stored on the hard disk is read into the memory of the electronic device (such as the memory cache), and then the data is read from the memory.

[0086] (3) Database: For data processing scenarios with large amounts of data, electronic devices usually use databases for data storage. For example, the amount of data in a contact directory is relatively large, so electronic devices usually use databases to store the contact directory.

[0087] (4) SharedPreferences: SharedPreferences is a lightweight storage class on the Android platform that is used to save some common configuration parameters (called application configuration data) of an application (APP). For example, if the application configuration data is the Activity state, when the Activity is paused, this activity state can be saved to SharedPreferences; when the Activity is reloaded, the system calls back the onSaveInstanceState method and reads the application configuration data from SharedPreferences. In actual implementation, SharedPreferences provides a storage interface for Java's regular Long, Int, String and other data types.

[0088] For lightweight data processing scenarios, if a database is used for data storage, it will take up a lot of system resources. The current solution is to apply SharedPreferences to lightweight data processing scenarios. For example, when a user enters personal account information on the login interface and logs in successfully, the electronic device can save the user's personal account information in SharedPreference, so that when the user logs in next time, the electronic device can automatically fill in the user's personal account information directly on the login interface. This lightweight data processing scenario usually uses SharedPreference to complete application data storage.

[0089] (5) Scheduling priority: In order to schedule resources for each thread in order, the system presets different scheduling priorities for different threads. For example, the scheduling priority of the application UI thread is usually higher than the scheduling priority of the application sub-thread. That is, the application UI thread is executed first, and then the application sub-thread is executed. For another example, different scheduling priorities can be set for each sub-thread of the application. That is, the sub-thread with a higher priority is executed first, and then the sub-thread with a lower priority is executed.

[0090] In some embodiments, a numerical value may be used to represent the scheduling priority. For example, the numerical value range may be [1, 139]. The smaller the numerical value, the higher the priority; the larger the numerical value, the lower the priority. Among them, the priority corresponding to 100 to 139 is relatively low. For non-real-time threads, the priority setting range is usually [100, 139]; the priority corresponding to 1 to 99 is relatively high. For real-time threads, the priority setting range is usually [1, 99].

[0091] For example, the priority value corresponding to the top-level application UI thread is usually set to 110, and the priority value corresponding to the application child thread is usually set to 120.

[0092] Currently, when an electronic device runs an application, the electronic device can store some application configuration data (including user behavior data) locally on the electronic device through SharedPreferences. The electronic device needs to read this data when running the application, and the electronic device can load data, display content, and other processes according to the application configuration data.

[0093] For example, user behavior data may include whether the user has checked the option to automatically update applications, or whether the user has checked message notifications. For another example, when some game applications provide a variety of optional frame rates, the user selects one of the frame rates. Correspondingly, the user behavior data includes which frame rate the user has selected. For another example, when downloading a file through an application, if the application exits, the electronic device will record the progress of the file download. Accordingly, the user behavior data includes the progress of the file download so that the application can continue to download according to the progress of the file download when the application is started next time. It should be noted that some data processing scenarios are listed here by way of example. It can be understood that in actual implementation, processing data for other possible scenarios can also be stored through SharedPreferences, and this application does not limit this.

[0094] Figure 1 The following is a schematic diagram showing an application scenario interface for setting application functions of an electronic device according to user operations. Figure 1 As shown in (a) and (b) in FIG. 1 , the electronic device displays a notification main interface 11. When the user clicks on a notification option 12 in the notification main interface 11, the electronic device will jump to a notification setting interface 13, which displays an application notification setting button. Figure 1 As shown in (b) and (c) in the figure, the reading APP is in a notification-disabled state. When the user clicks the setting button 14 of the reading APP, the electronic device enables the message notification permission of the reading APP.

[0095] exist Figure 1In the application configuration scenario shown, the reading app has enabled the message notification permission, which is a type of application configuration data belonging to the reading app. The electronic device can use SharedPreferences to store the application configuration data. This process is a data writing process, that is, writing the application configuration data to the memory (cache area) and then writing it from the memory to the hard disk.

[0096] In some embodiments, when the reading APP is closed and then restarted (i.e., the application is restarted), the electronic device can obtain the application configuration data of the reading APP, and then complete the parameter initialization and startup of the reading APP based on the application configuration data. This process is a data reading process, that is, loading the application configuration data stored in the hard disk into the memory, and then reading the application configuration data from the memory.

[0097] Figure 2 Shows Figure 1 The specific implementation flow diagram of the data writing process and the data reading process in the scenario shown is as follows. The electronic device includes programs such as system services and applications, and the application threads include user interface (UI) threads and SharedPreferences sub-threads.

[0098] like Figure 2 As shown, the data writing process includes S101 to S104.

[0099] S101. An application A (such as a reading APP) is running.

[0100] Among them, the UI thread is the main thread of application A, and the SharedPreferences sub-thread is the sub-thread of application A.

[0101] S102-S103, the application UI thread receives the user configuration operation. In response to the user configuration operation, the application UI thread writes the application configuration data into the memory based on the SharedPreferences object, and then writes the application configuration data from the memory into the hard disk.

[0102] S104: After application A is closed, all threads of application A are destroyed.

[0103] like Figure 2 As shown, the data reading process includes S105 to S113.

[0104] S105-S107, the system service receives the user's operation of triggering the application startup. In response to the user operation, the system service executes the application startup process, and creates a UI thread during the execution of the application startup process.

[0105] S108-S109, the system service calls the UI thread to create a SharedPreferences object. In the process of creating the SharedPreferences object, a SharedPreferences child thread is created.

[0106] S110-S111, the UI thread calls the SharedPreferences child thread to load the application configuration data stored in the hard disk into the memory. After the loading is completed, the SharedPreferences child thread returns a notification of data loading completion to the UI thread.

[0107] S112. At a first moment, the UI thread requests to read application configuration data.

[0108] S113. At a second moment (later than the first moment), the UI thread reads application configuration data from the memory based on the SharedPreferences object.

[0109] In some embodiments, if at the first moment, the SharedPreferences sub-thread has loaded the application configuration data stored in the hard disk into the memory, the UI thread can directly read the application configuration data from the memory.

[0110] In other embodiments, if the SharedPreferences child thread has not started loading or is loading data at the first moment, the UI thread needs to wait until the SharedPreferences child thread finishes loading data before obtaining the data.

[0111] Figure 3 The schematic diagram shows the principle of causing the slow application startup problem in the application startup scenario. Figure 3 As shown in the figure, in the application startup scenario, the UI thread of the application will call the SharedPreferences child thread to read the application configuration data from the hard disk. However, since the scheduling priority of the SharedPreferences child thread is low, the waiting time for scheduling is long. Although the scheduling priority of the UI thread is high, it needs to wait for the SharedPreferences child thread to load the application configuration data from the hard disk into the memory before obtaining the data from the memory. In other words, the SharedPreferences child thread is not scheduled for a long time, resulting in the UI thread being unable to obtain the application configuration data in time, and the application cannot be started quickly, so there is a problem of slow application startup.

[0112] Figure 4The schematic diagram of the scene interface of an electronic device starting an application in response to a user operation is shown. Exemplarily, the application startup process includes receiving the user's operation of clicking the application icon, the window animation changes, the display of the application startup window, and the display of the application main interface. After the user clicks the application icon, the application startup needs to be completed based on the application configuration data. The UI thread needs to wait for the SharedPreferences sub-thread to complete the data loading before it can obtain the data. However, the SharedPreferences sub-thread is not scheduled for a long time due to its low scheduling priority, which makes it impossible for the UI thread to obtain the application configuration data in time, resulting in the application being unable to start quickly. Therefore, from the device perspective, according to this application startup method, the electronic device cannot load the application configuration data in time, cannot jump to the application main interface in time, and there is a problem of slow application startup; from the user's perspective, after the user clicks the application icon, the user waits for a long time for the application to start, which seriously affects the user experience.

[0113] In view of the above problems, the embodiment of the present application provides a data loading method and an electronic device. In the scenario of starting the first application when the system is loaded, after creating the first thread (such as the UI thread) and the second thread (such as the SharedPreferences subthread) of the first application, because the system has other loads and needs to schedule resources, the second thread may not be able to load the target data in time because it cannot be scheduled in time, so that the first thread cannot read the target data in time. In this case, the present application scheme does not adopt the system default loading process, that is, the target data required for starting or running the first application is not loaded through the second thread, but is adjusted to load the target data through the first thread to speed up the data loading progress. In this way, the first thread actively completes the data loading task without waiting for the second thread to complete. After quickly completing the data loading, the first thread directly obtains the target data, thereby realizing the rapid startup of the first application. The present application scheme avoids the problem that the second thread cannot load data in time when the system is loaded because it cannot be scheduled in time, thereby blocking the first thread, causing slow application startup or slow application response.

[0114] The embodiment of the present application also provides a data loading method and an electronic device. In the scenario of starting the first application, after creating the first thread (such as the UI thread) and the second thread (such as the SharedPreferences subthread) of the first application, because the system has other loads that require scheduling resources, the second thread may not be scheduled in time and cannot load the target data in time, so that the first thread cannot read the target data in time. In this case, the present application solution does not adopt the system default loading process, that is, the second thread is no longer scheduled according to the default scheduling priority, but the scheduling priority of the second thread is increased, so that the second thread is quickly scheduled to load the target data required for starting the first application, speeding up the data loading progress, thereby reducing the waiting time of the first thread. After quickly completing the data loading, the first thread directly obtains the target data, thereby realizing the rapid startup of the first application. The present application solution avoids the problem that the second thread cannot load data in time when the system is loaded because it cannot be scheduled in time, thereby blocking the first thread, causing slow application startup or slow application response.

[0115] In order to better understand the embodiments of the present application, the embodiments of the present application are briefly described below.

[0116] In the present application, different processing strategies are adopted for different data loading states to achieve the purpose of giving priority to the execution of data loading tasks. The present application provides the following three processing strategies:

[0117] The first processing strategy: the data loading status is "loaded", that is, the SharedPreferences child thread has loaded the application configuration data stored in the hard disk into the memory. The corresponding processing strategy is: the UI thread directly obtains the application configuration data from the memory.

[0118] The second processing strategy: the data loading status is "loading data", that is, the SharedPreferences child thread is loading the application configuration data stored in the hard disk into the memory, and the loading is not complete. The corresponding processing strategy is: the UI thread increases the scheduling priority of the SharedPreferences child thread, so that the SharedPreferences child thread is scheduled first, so that the data loading task is executed first.

[0119] The third processing strategy: the data loading status is "not started loading", that is, the SharedPreferences child thread has not started to load the application configuration data stored in the hard disk into the memory. The corresponding processing strategy is: replace the data loading task performed by the SharedPreferences child thread with the data loading task performed by the UI thread. Since the scheduling priority of the UI thread is higher than the scheduling priority of the SharedPreferences child thread, adjusting the data loading task to be performed by the UI thread can achieve the purpose of giving priority to the data loading task.

[0120] The second and third processing strategies are important improvements of the solution of the present application. The specific process of using different processing strategies for different data loading states will be described in detail below.

[0121] The process of loading application configuration data from the hard disk to the memory in the embodiment of the present application is called a data loading task.

[0122] Through this application plan, Figure 4 In the application startup scenario shown, after the user clicks the application icon of the reading APP, the present application solution adopts different processing strategies for different data loading states, so that the data loading task is executed first. In this way, the UI thread of the reading APP can quickly obtain the application configuration data, and then complete the application parameter initialization based on the application configuration data, so that the application can be started quickly. Through this application solution, the application startup speed can be improved and the user experience can be improved.

[0123] It should be noted that the embodiment of the present application takes the application startup scenario and the problem of slow application startup as an example for illustrative explanation. In actual implementation, in the application running scenario, due to the slow loading of application configuration data, there is a problem of slow application response. The present application solution can also solve the problem of slow application response in the application running scenario.

[0124] For example, during the running of the application, if the application requests to read the application configuration data, the UI thread of the application can call the awaitLoadedLocked function to analyze and judge the mLoaded value to determine the data loading status, and for example, the UI thread increases the scheduling priority of the SharedPreferences child thread so that the data loading task is processed first. For another example, the UI thread with a high scheduling priority replaces the SharedPreferences child thread to perform the data loading task, so that the data loading task is processed first. This can avoid the problem of slow application response caused by the UI thread waiting for the child thread for a long time.

[0125] It should also be noted that the embodiment of the present application is illustratively described using the data loading scenario when reading data. In actual implementation, in the application running scenario, the present application scheme is not limited to the data loading scenario when reading data, but can also be applied to the data loading scenario when writing data, that is, the present application scheme can be applied to the data loading scenario when reading and writing data.

[0126] Hereinafter, the electronic device to which the data loading method provided in the embodiment of the present application is applied is described in conjunction with the accompanying drawings. For example, the electronic device in the embodiment of the present application may be a mobile phone, a tablet computer, an ultra-mobile personal computer (UMPC), a netbook, a cellular phone, a personal digital assistant (PDA), a wearable device (such as a smart watch, a smart bracelet), and the like, and the embodiment of the present application does not impose any special restrictions on the specific form of the electronic device.

[0127] Figure 5 FIG. 1 is a schematic diagram showing the hardware structure of an electronic device provided in an embodiment of the present application. For example, taking a mobile phone as an example, Figure 5 As shown, the electronic device may include: a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver (i.e., an earpiece) 170B, a microphone 170C, an earphone interface 170D, a sensor module 180, a button 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a subscriber identification module (SIM) card interface 195, etc.

[0128] It should be noted that the interface connection relationship between the modules illustrated in this embodiment is only an illustrative description and does not constitute a structural limitation on the electronic device. In other embodiments, the electronic device may also adopt different interface connection methods in the above embodiments, or a combination of multiple interface connection methods.

[0129] The processor 110 may include one or more processing units, for example, the processor 110 may include an application processor (AP), a modem processor, a graphics processor (GPU), an image signal processor (ISP), a controller, a memory, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural-network processing unit (NPU), etc. Among them, different processing units may be independent devices or integrated into one or more processors. The controller may be the nerve center and command center of the electronic device. The controller may generate an operation control signal according to the instruction opcode and the timing signal to complete the control of fetching and executing instructions.

[0130] The processor 110 may also be provided with a memory for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. The memory may store instructions or data that the processor 110 has just used or cyclically used. If the processor 110 needs to use the instruction or data again, it may be directly called from the memory. This avoids repeated access, reduces the waiting time of the processor 110, and thus improves the efficiency of the system.

[0131] In an embodiment of the present application, the electronic device can execute through the processor 110: at a first time point, start starting a first application; after the first time point, create a first thread and a second thread of the first application; at a second time point, start loading target data through the first thread; after the second time point, destroy the second thread; after loading the target data, at a third time point, display the main interface of the first application through the display screen 194; wherein, between the first time point and the third time point, the second application is running in the background.

[0132] The internal memory 121 can be used to store computer executable program codes, and the executable program codes include instructions. The internal memory 121 may include a program storage area and a data storage area. Among them, the program storage area may store an operating system, an application required for at least one function (such as controlling the electronic device to switch the working state, etc.). The data storage area may store data created during the use of the electronic device (such as working state information, switching time information), etc. In addition, the internal memory 121 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, a universal flash storage (UFS), etc. The processor 110 executes various functional applications and data processing of the electronic device by running instructions stored in the internal memory 121 and / or instructions stored in a memory provided in the processor. For example, in an embodiment of the present application, the processor 110 may execute instructions for implementing data loading stored in the internal memory 121.

[0133] The electronic device can realize the display function through a GPU, a display screen 194, and an application processor. The GPU is a microprocessor for image processing, which connects the display screen 194 and the application processor. The GPU is used to perform mathematical and geometric calculations for graphics rendering. The processor 110 may include one or more GPUs, which execute program instructions to generate or change display information. The display screen 194 is used to display images, videos, etc. The display screen 194 may include a touch screen and a touch sensor.

[0134] In the embodiment of the present application, the display screen 194 can display the desktop and display the application icon on the desktop. When the touch sensor detects a touch operation on the touch screen (for example, the user clicks on the application icon), the touch sensor sends the touch data of the touch screen to the application processor AP. The AP controls the software module to execute the application startup process according to the touch data, and controls the display screen 194 to display the application main interface after the application is started.

[0135] The above is a specific description of the embodiment of the present application using the electronic device 100 as an example. It should be understood that the structure illustrated in the embodiment of the present application does not constitute a specific limitation on the electronic device 100. The electronic device 100 may have more or fewer components than those shown in the figure, may combine two or more components, or may have different component configurations. The various components shown in the figure may be implemented in hardware, software, or a combination of hardware and software including one or more signal processing and / or application specific integrated circuits.

[0136] In addition, an operating system is running on the above hardware. The operating system of the operating system layer can be any one or more computer operating systems that implement business processing through processes, such as Linux operating system, Unix operating system, Android operating system, iOS operating system or Windows operating system, etc. Applications can be installed and run on the operating system.

[0137] The operating system of the electronic device 100 may adopt a layered architecture, an event-driven architecture, a micro-core architecture, a micro-service architecture, or a cloud architecture. The embodiment of the present application takes the Android system of the layered architecture as an example to exemplify the software structure of the electronic device 100.

[0138] Figure 6 It is a software structure block diagram of the electronic device 100 according to an embodiment of the present application.

[0139] The layered architecture divides the software into several layers, each with a clear role and division of labor. The layers communicate with each other through software interfaces. In some embodiments, Android TM The system is divided into five layers, from top to bottom: application layer, application framework layer, Android runtime and system library layer, hardware abstraction layer (HAL) and kernel layer.

[0140] The application layer may include a series of application packages. For example, the application layer may include game APP, video APP, application market APP, notification message APP and other applications.

[0141] For example, in an embodiment of the present application, when an electronic device runs a game APP, the electronic device can use SharedPreferences to store some user behavior data or configuration data of the game APP, such as configuration data about the frame rate selected by the user.

[0142] For example, in an embodiment of the present application, when an electronic device runs a video APP, the electronic device can use SharedPreferences to store some user behavior data or configuration data of the video APP, such as video playback progress.

[0143] For example, in an embodiment of the present application, when an electronic device runs an application market APP, the electronic device can use SharedPreferences to store some user behavior data or configuration data of the video APP, such as whether the user has checked the automatic application update option.

[0144] For another example, when downloading a file through an application, if the application exits, the electronic device can use SharedPreferences to store the file download progress so that the application can continue downloading according to the file download progress when the application is started next time.

[0145] For example, in an embodiment of the present application, when an electronic device runs a notification message APP, the electronic device can use SharedPreferences to store some user behavior data or configuration data of the video APP, such as whether the user has checked the message notification.

[0146] In the embodiment of the present application, the application layer may also include a context awareness module, a business logic processing module, a business presentation module, etc. The context awareness module, the business logic processing module, and the business presentation module may be independent APPs, or may be integrated in different APPs, or may be integrated in the same APP, which is not limited in the present application.

[0147] Among them, the context awareness module runs permanently or in a low-power form, and has the ability to perceive external facts or environments. The context awareness module can detect related events and obtain the status of events from other applications in the application layer or the application framework layer or the system layer or the kernel layer through the application programming interface (API), such as detecting Bluetooth connections, network connections, monitoring user text messages, custom timers, etc. In the embodiment of the present application, the main function of the context awareness module is to monitor whether there is an application startup trigger event. The context awareness module can notify the business logic processing module of the monitored application startup trigger event.

[0148] The business logic processing module (such as a computing engine) has business logic processing capabilities, and is used to perform data processing or logic judgment according to the application startup trigger event monitored by the context perception module and the preset logic algorithm, and execute the application startup process. For example, create the UI thread and SharedPreferences sub-thread of the application, and the SharedPreferences sub-thread can perform the data loading task according to the default program, that is, load the application configuration data from the hard disk to the memory; or the UI thread can increase the scheduling priority of the SharedPreferences sub-thread so that the data loading task is executed first; or the UI thread with a high scheduling priority can replace the SharedPreferences sub-thread with a low scheduling priority to perform the data loading task, so that the data loading task is executed first. After completing the data loading task, the UI thread reads the application configuration data from the memory, and completes the application parameter initialization and startup based on the application configuration data. The business logic processing module sends the display content to the business presentation module, and the display content includes the main interface of the application. In some embodiments, the display content may also include window animation changes and / or application startup windows.

[0149] The business presentation module is used to display the application main interface on the screen of the electronic device according to the instruction of the business logic processing module.

[0150] The application framework layer provides an application programming interface (API) and a programming framework for the applications in the application layer. The application framework layer includes some predefined functions. The application framework layer may include system services, SharedPreferences services, etc., and the embodiments of the present application do not impose any restrictions on this.

[0151] The system service is used to create the application's UI thread and SharedPreferences child thread after receiving the application startup trigger event, call the UI thread to obtain the application configuration data, and then complete the application parameter initialization and startup based on the application configuration data.

[0152] The SharedPreferences service is used to create SharedPreferences child threads and manage data loading tasks for SharedPreferences child threads.

[0153] The Android runtime is responsible for scheduling and management of the Android system. The Android runtime includes a core library and a virtual machine. The core library consists of two parts: one is the function that the Java language needs to call, and the other is the Android core library. The application layer and the application framework layer run in the virtual machine. The virtual machine executes the Java files of the application layer and the application framework layer as binary files. The virtual machine is used to perform object life cycle management, stack management, thread management, security and exception management, and garbage collection.

[0154] The system library can include multiple functional modules. For example: surface manager, media libraries, 3D graphics processing library (for example: openGL ES), 2D graphics engine (for example: SGL), etc. The surface manager is used to manage the display subsystem and provides the fusion of 2D and 3D layers for multiple applications. The system library layer can provide native services and link libraries for hardware operations for the upper layer.

[0155] The HAL layer is a package of the Linux kernel driver, providing an interface to the upper layer and shielding the implementation details of the low-level hardware. For example, the HAL layer may include display HAL, sensor HAL, etc.

[0156] The kernel layer is the layer between hardware and software. The kernel layer includes at least display driver and sensor driver.

[0157] For the sake of convenience, the figure also shows a hardware layer that interacts with the above software structure. For example, the hardware layer may include hardware such as a display screen and a touch sensor.

[0158] It should be noted that although the embodiment of the present application is based on Android TM The system is used as an example, but the basic principle is also applicable to iOS-based TM or Windows TM Electronic devices with other operating systems.

[0159] The execution subject of the data loading method provided in the embodiment of the present application can be the above-mentioned electronic device, or it can be a functional module and / or functional entity in the electronic device that can implement the data loading method, and the present application scheme can be implemented by hardware and / or software, which can be determined according to actual use requirements, and the embodiment of the present application is not limited. Below, taking an electronic device as an example, the data loading method provided in the embodiment of the present application is exemplarily described in conjunction with the accompanying drawings.

[0160] The following will be combined with the accompanying drawings to illustrate the embodiments of the present application through the following multiple exemplary embodiments. The methods in the following embodiments can be implemented in an electronic device with the above hardware structure and software architecture. The hardware structure diagram of the electronic device can be as follows: Figure 5 As shown, the software structure diagram of the electronic device can be as follows Figure 6 For the sake of convenience, the embodiments of the present application all take the electronic device as a mobile phone as an example.

[0161] First, the data writing and data reading processes implemented by SharedPreferences involved in this application solution are introduced.

[0162] SharedPreferences is a lightweight data storage method provided by the Android system. Data is saved in XML files in the form of key-value pairs to form SharedPreferences data. Each application may have many such XML files. When an application installed in an electronic device reads or writes SharedPreferences data, it needs to load / parse the XML file into memory first. The system loads it by creating a new SharedPreferences child thread (priority 120).

[0163] During the running of the application, the application can write the configuration data of some user settings (for example, video playback progress, whether to automatically update, and other settings) into the SharedPreferences object, that is, into the memory, and then SharedPreferences writes the configuration data from the memory to the hard disk.

[0164] When the application is started again, the system service SystemServer creates the application process, such as creating the application's UI thread and SharedPreferences child thread. Then, the application's UI thread calls the SharedPreferences child thread to read previously stored data from the hard disk to the memory. The application's UI thread first creates a SharedPreferences object. In the process of creating the object, it creates a SharedPreferences child thread, and uses this child thread to load some data corresponding to SharedPreferences. Since the SharedPreferences child thread has a low priority (priority 120), it will not be scheduled, but the UI thread must wait for the SharedPreferences child thread to load the data before it can read the data and run. In addition, other application threads with higher priorities and other application subthreads with higher priorities will be scheduled first, resulting in the application's SharedPreferences not being scheduled for a long time.

[0165] Therefore, the problem with the current Android SharedPreferences storage method is that because the SharedPreferences child thread has a low priority, it cannot be scheduled in time when the system load is high, resulting in performance problems caused by the UI thread being blocked by the SharedPreferences child thread.

[0166] The following example illustrates the code implementation of data writing and data reading based on SharedPreferences.

[0167] For example, taking the application market APP as an example, the setting item of "automatically update applications" provides the following three options for users to choose: "First option, turn on (WLAN and mobile network); second option, WLAN only; third option, turn off".

[0168] For example, when the user selects “WLAN only”, the electronic device may store the user selection result (application configuration data) regarding “automatically update applications” through the SharedPreferences data storage method, that is, write.

[0169] For the data writing of the "Automatically Update Application" setting scenario, you can use SharedPreferences to store the application configuration data in auto_update.xml. First, store auto_update.xml in memory, and then write it from memory to the hard disk. This application provides sample code for data writing based on SharedPreferences:

[0170] SharedPreference sp=getSharedPreferences("auto_update", Context.MODE_PRIVATE); / / About automatic update application, get SharedPreferences object

[0171] … / / The process of creating a SharedPreferences object

[0172] Editor editor = sp.edit(); / / Get the editor object through the edit() function

[0173] editor.putInt("select", 1); / / Store key-value pairs through editor objects

[0174] editor.commit(); / / Submit data through the commit() function

[0175] Among them, SharedPreferences uses a key-value pair storage method to store data in an XML file. Here, the value corresponding to "WLAN only" is 1, and the key is select. Select and 1 constitute a key-value pair.

[0176] For data reading in the "auto update application" setting scenario, you can use SharedPreferences to read the data auto_update.xml from the hard disk to the memory, and then read the data auto_update.xml from the memory. This application provides sample code for data reading based on SharedPreferences:

[0177] SharedPreference sp=getSharedPreferences("auto_update", Context.MODE_PRIVATE); / / Get the SharedPreferences object created for "auto-update application"

[0178] … / / After obtaining the SharedPreference object, the APP may read the data immediately or after a while

[0179] int select = sp.getInt("select", 0); / / Read data; select is the key and 0 is the default return value

[0180] It should be noted that when reading data through SharedPreferences, you need to first obtain the SharedPreferences object. When obtaining the SharedPreferences object for the first time, you need to create the SharedPreferences object first, and in the process of creating the SharedPreferences object, you can create a SharedPreferences child thread to load the required data. For example, still taking the "auto-update application" setting scenario as an example, the "auto-update setting data auto_update.xml" is loaded into the memory through the SharedPreferences child thread.

[0181] It should also be noted that after the application UI thread obtains the SharedPreference object, the application UI thread may read the data immediately or after a while. This is because it takes a certain amount of time for the SharedPreference child thread to complete the data loading task. After the data loading task is completed, the application UI thread can read the data directly; if the data loading task is not completed, the application UI thread needs to wait until the data loading task is completed before reading the data.

[0182] It should be noted that when other child threads of the application read and write data through SharedPreferences, they also need to wait until the SharedPreferences child thread has loaded the data before performing the read and write operations.

[0183] It should be noted that the time (time consumption) required for the SharedPreferences child thread to load data depends on the system load. For example, when the system load is high, it takes tens of milliseconds.

[0184] In some embodiments, the default priority of the SharedPreferences child thread is 120. When the system load is high, the SharedPreferences child thread often fails to be scheduled in time. The reason is that when the UI thread reads data through the SharedPreferences object, if the SharedPreferences child thread has not finished loading, the UI thread needs to wait for the SharedPreferences child thread to finish loading before reading the data.

[0185] Based on the above data reading process, the following describes in detail the four data reading scenarios involved in this application solution:

[0186] (1) The UI thread reads data after the SharedPreferences child thread has finished loading data. That is, when the application UI thread reads and writes data, the SharedPreferences child thread has already finished loading the data. Specifically, when the application UI thread wants to read an integer data, the SharedPreferences child thread has already finished loading the data at the time of reading. At this time, the UI thread does not need to wait and can directly obtain the required data.

[0187] (2) The UI thread reads data while the SharedPreferences child thread is loading data. That is, when the application UI thread reads and writes data items, the SharedPreferences child thread is loading data. Specifically, the application UI thread wants to read an integer data, and at the time of reading, the SharedPreferences child thread is loading data. At this time, the UI thread needs to wait for the SharedPreferences child thread to finish loading data before it can obtain the required data.

[0188] (3) The UI thread reads data before the SharedPreferenced child thread starts loading data. That is, when the application UI thread reads and writes data items, the SharedPreferences child thread has not started loading data. Specifically, the application UI thread wants to read an integer data, but the SharedPreferenced child thread has not started loading data at the time of reading. At this time, the UI thread needs to wait for the SharedPreferenced child thread to finish loading data before it can obtain the required data.

[0189] (4) Other application threads read data. That is, other application threads read and write data items. In addition to the application UI thread, other application threads may also request to read the data of the SharedPreferences object.

[0190] Below through FIG. 7A to FIG. 7D Schematic diagrams illustrating the flow of four data reading scenarios before improvement.

[0191] Scenario 1: The UI thread reads data after data loading

[0192] Fig. 7A The figure shows a flow chart of a scenario in which the UI thread of an application in the Android default strategy requests to read data after the child thread has loaded the data. Fig. 7A As shown, the process includes A1 to A8.

[0193] A1-A2, the UI thread of the application calls the sp=getSharedPreferences() function to obtain the SharedPreferences object. When obtaining the object for the first time, it is necessary to create a SharedPreferences object, and create a SharedPreferences child thread during the process of creating the SharedPreferences object.

[0194] A3-A5, the SharedPreferences child thread calls the LoadFromDisk() function to load data from the hard disk to the SharedPreferences object in memory, and updates the data loading status mLoaded = true after the loading is complete. The SharedPreferences child thread sends a notification (notifyAll) to the UI thread, which is used to indicate that the data loading is complete and mLoaded = true.

[0195] A6-A8, After the SharedPreferences child thread finishes loading the data, the UI thread calls the sp.getInt() function to request the memory data. The UI thread determines whether mLoaded is true. If the UI thread determines that mLoaded is true, the UI thread obtains the memory data corresponding to the SharedPreferences object.

[0196] pass Fig. 7A From the scenario shown, it can be seen that after the SharedPreferences child thread loads the data, the UI thread can directly obtain the memory data.

[0197] Scenario 2: The UI thread reads data while the SharedPreferenced child thread is loading data

[0198] Figure 7B The figure shows a flow chart of a scenario in which the UI thread of an application in the Android default strategy requests to obtain data while the child thread is loading data. Figure 7B As shown, the process includes B1 to B9. The implementation process of B1 to B3 is the same as the implementation process of A1 to A3 above, and this application will not repeat them.

[0199] B4-B6, when the SharedPreferences child thread is loading data, the UI thread calls the sp.getInt() function to request to obtain the memory data. The UI thread determines whether mLoaded is true. If the UI thread determines that mLoaded is not true, the UI thread waits, that is, waits to receive the notification sent by the SharedPreferences child thread.

[0200] B7-B9, after the SharedPreferences child thread has finished loading the data, it updates the data loading status mLoaded = true. The SharedPreferences child thread sends a notification (notifyAll) to the UI thread, which is used to indicate that the data loading is complete and mLoaded = true. If the UI thread receives a notification that the data loading is complete during the waiting process, the UI thread obtains the memory data corresponding to the SharedPreferences object.

[0201] pass Figure 7B From the scenario shown, it can be seen that when the SharedPreferences child thread is loading data, if the UI thread requests to obtain memory data, the UI thread needs to wait for the SharedPreferences child thread to finish loading the data.

[0202] Scenario 3: The UI thread reads data before the SharedPreferenced child thread starts loading data

[0203] Figure 7C The figure shows a flow chart of a scenario in which the UI thread of an application in the Android default strategy requests to obtain data when the child thread has not started to load data. Figure 7C As shown, the process includes C1 to C9. The implementation process of C1 to C2 is the same as the implementation process of A1 to A2, and this application will not repeat them.

[0204] C3-C5, before the SharedPreferences child thread starts loading data, the UI thread calls the sp.getInt() function to request memory data. The UI thread determines whether mLoaded is true. If the UI thread determines that mLoaded is not true, the UI thread waits, that is, waits to receive the notification sent by the SharedPreferences child thread.

[0205] C6-C9, the SharedPreferences child thread starts loading data, for example, calling the LoadFromDisk() function to load data from the hard disk to the SharedPreferences object in memory, and updates the data loading status mLoaded = true after loading is complete. The SharedPreferences child thread sends a notification (notifyAll) to the UI thread, which is used to indicate that the data loading is complete and mLoaded = true. After the UI thread receives the notification that the data loading is complete, the UI thread obtains the memory data corresponding to the SharedPreferences object.

[0206] pass Figure 7C From the scenario shown, it can be seen that when the SharedPreferences child thread has not started loading data, if the UI thread requests to obtain memory data, the UI thread needs to wait for the SharedPreferences child thread to finish loading the data.

[0207] In the above three application scenarios, after the SharedPreferences child thread has finished loading the data, the UI thread can directly obtain the memory data without waiting. When the SharedPreferences child thread is loading data, or when the SharedPreferences child thread has not started loading data, the UI thread request needs to wait for the child thread to complete the data loading before obtaining the memory data. However, since the scheduling priority of the SharedPreferences child thread is low, the SharedPreferences child thread waits for a long time to be scheduled. Accordingly, the UI thread needs to wait for a long time to obtain the memory data to complete the application startup process, resulting in slow application startup.

[0208] Scenario 4: Using other child threads to read data

[0209] The above three application scenarios illustrate that the UI thread interacts with the SharedPreferences child thread to obtain data, and the UI thread needs to wait for the SharedPreferences child thread to complete the data loading task; in addition, when executing the application startup process, other child threads in addition to the SharedPreferences child thread will be created. Other child threads will also interact with the SharedPreferences child thread to obtain data. Other child threads also need to wait for the SharedPreferences child thread to complete the data loading task, resulting in slow application startup.

[0210] For example, Fig.7D The figure shows a flow chart of how other sub-threads applied in the Android default strategy interact with the SharedPreferences sub-thread to obtain data. Fig.7D As shown, the process includes D1 to D12, and the process includes two parts: the other sub-thread 1 of the application requests to obtain data when the SharedPreferences sub-thread has not started to load data or is loading data, and the other sub-thread 2 of the application requests to obtain data when the SharedPreferences sub-thread has finished loading. Among them, the implementation process of D1 to D9 is the same as the implementation process of B1 to B9 mentioned above, or the same as the implementation process of C1 to C9 mentioned above, which will not be repeated here. Among them, the implementation process of D10 to D12 is the same as the implementation process of A6 to A8 mentioned above, which will not be repeated here.

[0211] That is to say, when the SharedPreferences child thread has not started loading or has not finished loading, if the application UI thread or other child threads read data, then the application UI thread or other child threads need to wait until the SharedPreferences child thread completes the data loading task before reading the data. The SharedPreferences child thread cannot be scheduled in time and blocks the application UI thread or other child threads, which may cause performance problems such as slow startup and slow response, thus affecting the user experience.

[0212] The data loading method provided in the embodiment of the present application comprehensively considers the above four application scenarios and provides different processing strategies for different data loading states, with the purpose of reducing the waiting time for data loading and improving the application startup speed. The data loading method provided in the embodiment of the present application is described in detail below in conjunction with specific embodiments.

[0213] Improved process on the application UI thread side

[0214] Figure 8 1 is a flow chart of the application UI thread side of the data loading method provided in the embodiment of the present application. Figure 8 As shown, the method includes the following steps S201-S207.

[0215] S201. The application UI thread calls the sp.getInt() function to request memory data.

[0216] S202. The application UI thread obtains the data loading status of the SharedPreferences child thread.

[0217] The data loading state represents various possible states of loading data from the hard disk to the memory.

[0218] In an embodiment of the present application, the application UI thread first identifies the current data loading status, "not started loading", "loading", "loaded", and then executes the corresponding processing strategies as follows for different data loading statuses.

[0219] (1) Processing strategy corresponding to the "not started loading" state (S203-S205): When the data loading state indicates "not started loading", the application UI thread performs data loading. After the application UI thread completes loading the data, the application UI thread reads the data.

[0220] It should be noted that in the Android default policy, the data loading task is completed by the SharedPreferences child thread; compared with the Android default policy, the improvement of the present application solution is that when "loading has not started", the application UI thread takes on the data loading task, and controls the SharedPreferences child thread not to perform the data loading task. That is, the data loading by the SharedPreferences child thread is adjusted to the data loading by the application UI thread. The specific implementation method of the adjustment task will be described in detail below.

[0221] The technical effect is: since the scheduling priority of the application UI thread is higher than the scheduling priority of the SharedPreferences child thread, when "loading has not started", the application UI thread quickly completes data loading and obtains data to complete the application startup process without waiting for the SharedPreferences child thread, which greatly improves the application startup speed.

[0222] (2) Processing strategy corresponding to the "loading" state (S206-207 and S205). When the data loading state indicates "loading", the application UI thread adjusts the scheduling priority of the SharedPreferences child thread. The application UI thread waits for the SharedPreferences child thread to finish loading. After the SharedPreferences child thread finishes loading the data, the application UI thread reads the data.

[0223] It should be noted that in the Android default policy, the SharedPreferences child thread has a fixed scheduling priority. The system will schedule resources for the SharedPreferences child thread according to the fixed scheduling priority, and the SharedPreferences child thread will complete the task of loading data. Since the scheduling priority of the SharedPreferences child thread is relatively low (for example, the priority value is 120), the SharedPreferences child thread may not be scheduled for a long time because other high-priority loads occupy the scheduling resources.

[0224] Compared with the Android default strategy, the improvement of the present application solution is that: when "loading", the scheduling priority of the SharedPreferences child thread is increased so that the data loading task is processed first, so as to avoid the problem that the UI thread waits for the child thread for a long time and causes the application to start slowly. The specific implementation method of adjusting the priority will be described in detail below.

[0225] The technical effect is: since the scheduling priority of the application UI thread is higher than the scheduling priority of the SharedPreferences child thread, when "loading has not started", the application UI thread quickly completes data loading and obtains data to complete the application startup process without waiting for the SharedPreferences child thread, which greatly improves the application startup speed.

[0226] (3) Processing strategy corresponding to the “loaded” status (S205): When the data loading status indicates “loaded”, the application UI thread directly reads the data.

[0227] It should be noted that the processing logic of the Android default strategy is: when the data loading state mLoaded is true, the UI thread reads the data, and when mLoaded is not true, the UI thread waits for the SharedPreferences child thread to complete the data loading. Such a simple processing logic can easily cause the UI thread to wait for a long time, resulting in slow application startup.

[0228] Compared with the Android default strategy, the UI thread side of the present application solution can execute corresponding processing strategies for different data loading states. For example, the UI thread increases the scheduling priority of the SharedPreferences child thread so that the data loading task is processed first. For another example, the UI thread with a high scheduling priority replaces the SharedPreferences child thread to execute the data loading task so that the data loading task is processed first. This can avoid the problem of slow application startup caused by the UI thread waiting for the child thread for a long time.

[0229] Improved process for applying SharedPreferences child thread side

[0230] Fig. 9 1 is a flow chart of the application SharedPreferences sub-thread side of the data loading method provided in the embodiment of the present application. Fig. 9 As shown, the method includes the following steps S301-S305.

[0231] S301, the SharedPreferences sub-thread receives a request to read data.

[0232] S302, the SharedPreferences sub-thread obtains the data loading status.

[0233] In the embodiment of the present application, the data loading status includes a "loading not started" status, a "loading" status and a "loading completed" status.

[0234] It should be noted that this application has made improvements on both the UI thread side and the SharedPreferences sub-thread side. For example, the UI thread raises the scheduling priority of the SharedPreferences sub-thread so that the data loading task is processed first. Another example is that the UI thread with a high scheduling priority replaces the SharedPreferences sub-thread to execute the data loading task so that the data loading task is processed first. For specific improvements on the SharedPreferences sub-thread side, see the following steps.

[0235] (1) Processing strategy corresponding to the "Not started loading" state (S303-S305). When the data loading state is "Not started loading", the SharedPreferences child thread starts to execute the data loading task, that is, loading data from the hard disk to the SharedPreferences object in the memory. After completing the data loading task, the SharedPreferences child thread sends a message to the UI thread that the data loading is complete. The SharedPreferences child thread is destroyed.

[0236] It should be noted that in the Android default policy, after receiving a data read request, the SharedPreferences child thread executes the data loading task according to the default scheduling priority. After the improvement of the present application solution, when the loading has not started, the SharedPreferences child thread can execute the data loading task according to the increased scheduling priority.

[0237] (2) Processing strategy corresponding to the "loading" state (S305): When the data loading state is the "loading" state, the SharedPreferences child thread is destroyed.

[0238] It should be noted that, after the improvement of the present application solution, when the data loading status is "loading", it indicates that the UI thread with a high scheduling priority has replaced the SharedPreferences child thread to perform the data loading task. In other words, the SharedPreferences child thread does not need to perform the data loading task, so it can be destroyed.

[0239] (3) Processing strategy corresponding to the "loaded" state (S305): When the data loading state is the "loaded" state, the SharedPreferences child thread is destroyed.

[0240] It should be noted that when the data loading status is "loaded", it indicates that the data loading task has been completed. The task may be completed by the SharedPreferences child thread or the UI thread.

[0241] The following compares this application solution with the Android default policy to illustrate the improvements of this application:

[0242] In the Android default policy, the system defaults to the SharedPreferences child thread to perform data loading tasks. That is, when the SharedPreferences child thread receives a data read request, the SharedPreferences child thread will directly start to perform the data loading task. Compared with the Android default policy, the present application scheme adds step S302 (obtaining the data loading status) and adds steps to perform different actions in different data loading states.

[0243] The Android default strategy will not obtain the data loading status as in the present application, nor will the SharedPreferences child thread perform the data loading task according to the increased scheduling priority when the loading has not started, nor will it perform the destruction action in the "loading" state as in the present application.

[0244] Apply the improved process on other sub-threads

[0245] Fig.10 1 is a flow chart of the application of other sub-threads of the data loading method provided in the embodiment of the present application. Fig.10 As shown, the method includes the following steps S401-S404.

[0246] S401. Apply other child threads to call sp.getInt() function to initiate a data read request.

[0247] S402: Use other sub-threads to obtain data loading status.

[0248] In an embodiment of the present application, other sub-threads are used to identify the current data loading status, "loading not started", "loading", "loading completed", and then corresponding processing strategies are executed as follows for different data loading statuses.

[0249] (1) Processing strategy corresponding to the "loaded" status: When the data loading status indicates "loaded", other child threads are used to directly read the data.

[0250] (2) Processing strategy corresponding to the "not started loading" state or the "loading" state (S403-S404): When the data loading state indicates "not started loading" or "loading", other child threads are applied to wait for the data loading to be completed.

[0251] It should be noted that, in the embodiment of the present application, the data loading task may be executed by the SharedPreferences child thread (the priority remains unchanged or is increased), or it may be executed by the UI thread.

[0252] Before the improvement, when the data loading status mLoaded is true, other sub-threads of the application read the data, and when mLoaded is not true, other sub-threads of the application wait for the SharedPreferences sub-thread to complete the data loading. Such simple processing logic easily causes other sub-threads of the application to wait for a long time, resulting in slow application startup.

[0253] After the improvement, in the solution of this application, because the UI thread raises the scheduling priority of the SharedPreferences child thread so that the data loading task is processed first, or the UI thread with a high scheduling priority replaces the SharedPreferences child thread to perform the data loading task so that the data loading task is processed first, the waiting time for data loading of other application child threads is shortened, thereby avoiding the problem of slow application startup caused by other application child threads waiting for a long time. This greatly improves the application startup speed.

[0254] The embodiment of the present application redesigns the mLoaded variable value. The mLoaded variable value in the embodiment of the present application can indicate data loading states such as "loading not started", "loading", and "loading completed".

[0255] It should be noted that the mLoaded variable designed by default in Android is a Boolean type, which can only indicate whether the SharedPreferenced data loading is completed, that is, the mLoaded variable includes two values, one value indicating completion and the other indicating incompleteness. For example, the following Table 1 shows the mLoaded variable values ​​and their corresponding meanings in the Android default policy.

[0256] Table 1

[0257]

[0258] Referring to Table 1, we can see that when the UI thread (or other child thread) requests to read data, the mLoaded variable value will be obtained. When the data loading status mLoaded is true, the UI thread (or other child thread) reads the data. When mLoaded is false, the UI thread (or other child thread) needs to wait for the SharedPreferences child thread to complete data loading before obtaining the data. Such a simple processing logic can easily cause the UI thread to wait for a long time, resulting in slow application startup. It should be noted that in the Android default policy, the SharedPreferences child thread does not obtain the mLoaded variable value.

[0259] The improvement of the present application solution includes: transforming the mLoaded variable value into a three-state integer variable. The following Table 2 shows the mLoaded variable value and the corresponding meaning in the present application solution.

[0260] Table 2

[0261]

[0262] Table 3 below shows the execution actions of the UI thread at different mLoaded in the solution of the present application.

[0263] Table 3

[0264]

[0265] Different from the Android default strategy, in this application solution, when the application UI thread requests to obtain SharedPreferenced data, the UI thread will obtain the mLoaded variable value. When the mLoaded variable value is "LOAD_STATE_INIT=0", the UI thread actively performs the data loading task; when the mLoaded variable value is "LOAD_STATE_DOING=1", the UI thread increases the priority of the SharedPreferenced child thread, and then the UI thread waits for the SharedPreferenced child thread to complete data loading before obtaining the SharedPreferenced data; when the mLoaded variable value is "LOAD_STATE_DONE=2", the UI thread directly reads the SharedPreferenced data.

[0266] Table 4 below shows the execution actions of the SharedPreferenced sub-thread at different mLoaded in the solution of the present application.

[0267] Table 4

[0268]

[0269] Different from the Android default strategy, in this application solution, when the SharedPreferences child thread receives a data read request, the SharedPreferences child thread will obtain the mLoaded variable value. When the mLoaded variable value is "LOAD_STATE_INIT=0", the SharedPreferences child thread executes the data loading task; when the mLoaded variable value is "LOAD_STATE_DOING=1" or "LOAD_STATE_DONE=2", the SharedPreferences child thread destruction task is executed.

[0270] Table 5 below shows the execution actions of other sub-threads applied at different mLoaded in the solution of the present application.

[0271] Table 5

[0272]

[0273] Different from the Android default strategy, in this application solution, when other sub-threads of the application request to obtain SharedPreferenced data, other sub-threads of the application will obtain the value of the mLoaded variable. When the value of the mLoaded variable is "LOAD_STATE_INIT=0" or "LOAD_STATE_DOING=1", other sub-threads of the application wait for the data to be loaded before obtaining the SharedPreferenced data; when the value of the mLoaded variable is "LOAD_STATE_DONE=2", other sub-threads of the application read the SharedPreferenced data.

[0274] Interaction process between the UI thread and the SharedPreferences sub-thread

[0275] The above describes the data loading method provided by the embodiment of the present application from the UI thread side and the SharedPreferences sub-thread side respectively. In order to better understand the present application scheme, the following is combined with Fig.11 The possible implementation of the data loading method provided in the embodiment of the present application is explained from the perspective of interaction between the two sides.

[0276] Fig.11 Schematic diagram of the interactive process of the data loading method provided in the embodiment of the present application. Fig.11 As shown, the method includes the following steps S501-S522.

[0277] First of all, it should be noted that in the following embodiments, it is assumed that the default scheduling priority value of the UI thread is 110, and the default scheduling priority value of the SharedPreferences child thread is 120. The higher the priority value, the lower the priority; the lower the priority value, the higher the priority.

[0278] S501-S503, the UI thread of the application calls the sp=getSharedPreferences() function to obtain the SharedPreferences object. When obtaining the object for the first time, the UI thread creates the SharedPreferences object, initializes mLoaded to LOAD_STATE_INIT, and creates a SharedPreferences child thread during the process of creating the SharedPreferences object.

[0279] It should be noted that the application UI thread obtains the SharedPreferences object by calling the getSharedPreferences() function. If the SharedPreferences object already exists in the memory at this time, it is directly obtained; if the SharedPreferences object does not exist in the memory at this time, the SharedPreferences object is instantiated, and mLoaded is initialized to LOAD_STATE_INIT in the SharedPreferences constructor. Then a SharedPreferences child thread is created to load the SharedPreferences data associated with the SharedPreferences object, which is an XML file.

[0280] The following first describes the specific improvement actions on the SharedPreferences child thread side provided by the embodiment of the present application. Fig. 9 S303-S305 can be implemented through the following S504-S511.

[0281] S504: After creating the SharedPreferences child thread, start executing the run function.

[0282] S505. Record the thread ID (denoted as TID) of the SharedPreferences child thread.

[0283] It should be noted that after the SharedPreferences child thread is created, the SharedPreferences child thread run entry function will be executed, at which time the thread number TID of the SharedPreferences child thread is obtained and the thread number TID is saved in the SharedPreferences object.

[0284] S506: Obtain the mLoaded value and determine the mLoaded value.

[0285] It should be noted that the SharedPreferences child thread determines the value of the mLoaded variable and executes the data loading task according to the value of the mLoaded variable; or exits without executing the data loading task.

[0286] S507-S510, when the value of mLoaded is LOAD_STATE_INIT, set (update) the value of mLoaded to LOAD_STATE_DOING (i.e., loading in progress). Call the loadFromDisk() function to execute the data loading task. After the data loading task is completed, set (update) the value of mLoaded to LOAD_STATE_DONE (i.e., loading completed), and notify the UI thread that the data loading is completed.

[0287] If the value of the mLoaded variable is LOAD_STATE_INIT, then mLoaded is set to LOAD_STATE_DOING. The purpose is to modify the value of the mLoaded variable to mark the current state of loading data and prevent the UI thread from loading again. The SharedPreferences child thread starts loading data. After the data is loaded, mLoaded is set to LOAD_STATE_DONE. The purpose is to modify the value of the mLoaded variable to mark the current state of data loading completion. Then the SharedPreferences child thread calls the notifyAll() function to notify other waiting threads to obtain data.

[0288] Among them, executing the data loading task refers to loading the data corresponding to the SharedPreferences object stored in the hard disk into the storage area corresponding to the SharedPreferences object in the memory.

[0289] S511, when the value of mLoaded is other than LOAD_STATE_INIT, destroy the SharedPreferences child thread. Among them, other states except LOAD_STATE_INIT are LOAD_STATE_DOING (i.e., loading in progress) or LOAD_STATE_DONE (i.e., loading completed).

[0290] It should be noted that if the SharedPreferences child thread determines that the mLoaded variable is not LOAD_STATE_INIT, it means that the data has been loaded or the UI thread is executing the data loading task. At this time, the SharedPreferences child thread exits (destroys) and there is no need to execute the data loading task.

[0291] The specific improvement actions on the UI thread side provided by the embodiment of the present application are described below. Figure 8 S203-S207 can be implemented through the following S512-S522.

[0292] S512. Call the sp.getInt() function to obtain the mLoaded value from the SharedPreferences object.

[0293] Among them, the mLoaded value can be an integer value.

[0294] S513. Call the awaitLoadedLocked function to analyze and determine the mLoaded value.

[0295] Among them, different mLoaded values ​​represent different data loading states and correspondingly perform different actions.

[0296] S514. When the value of mLoaded is LOAD_STATE_DONE (i.e., loading is complete), the UI thread directly obtains the memory data corresponding to the SharedPreferences object.

[0297] In the embodiment of the present application, when the application UI thread reads the requested data item, the SharedPreference child thread has already loaded the data. In this case, Fig.11 In the branch process where mLoaded is LOAD_STATE_DONE, no additional processing is required and data can be obtained directly.

[0298] S515-S522, when the value of mLoaded is LOAD_STATE_DOING (i.e., loading), the UI thread obtains the thread number TID of the saved SharedPreferences child thread and increases the scheduling priority corresponding to the TID. The UI thread waits for the SharedPreferences child thread to complete the data loading task. After receiving the notification that the data loading is complete, the UI thread obtains the data.

[0299] In the embodiment of the present application, when the application UI thread requests to read a data item, the SharedPreference child thread is loading data. In this case, Fig.11 In the branch process where mLoaded is LOAD_STATE_DOING, the scheduling priority of the sharedPreference child thread is adjusted to prevent the SharedPreference child thread from blocking the UI thread due to its low priority and inability to be scheduled in time.

[0300] In the embodiment of the present application, the SetThreadPriority() function can be called to increase the priority of the SharedPreference child thread according to actual needs.

[0301] In some embodiments, the priority of the SharedPreferences sub-thread is adjusted to be consistent with the priority of the UI thread. For example, if the priority value of the UI thread is 110, the priority value of the SharedPreferences sub-thread is adjusted to 110.

[0302] In some embodiments, the SharedPreferences sub-thread is adjusted to a real-time priority. For example, the priority value of the SharedPreferences sub-thread may be adjusted to 98 or below 97.

[0303] In some embodiments, the scheduling priority of the SharedPreferences child thread is VIPized, for example, a priority processing mark can be added to the SharedPreferences child thread. In actual implementation, the thread with the priority processing mark will be scheduled with priority.

[0304] In some embodiments, the priority value of the SharedPreference child thread is lowered to a preset value (eg, 100).

[0305] S518-S522, when the value of mLoaded is LOAD_STATE_INIT (i.e., loading has not started), the UI thread sets mLoaded to LOAD_STATE_DOING (i.e., loading is in progress). The UI thread calls the loadFromDisk() function to perform the data loading task. After completing the data loading task, the UI thread sets mLoaded to LOAD_STATE_DONE (i.e., loading is complete). The UI thread notifies each child thread that data loading is complete. After completing the data loading task, the UI thread obtains the data.

[0306] In the embodiment of the present application, when the application UI thread requests to read a data item, the SharedPreferences child thread has not yet started to load the data. In this case, Fig.11 In the branch process where mLoaded is LOAD_STATE_INIT, the application UI thread does not wait for the SharedPreferences child thread, but the UI thread actively performs the data loading task.

[0307] It should be noted that the default priority of the frequently used application UI thread of the Android system is 110 or lower (for example, 100, 98, or 97), and the scheduling priority of the application UI thread is higher than the scheduling priority of the SharedPreferences child thread (for example, 120). Therefore, using a high-priority UI thread instead of a low-priority SharedPreferences child thread to load SharedPreferenced data can improve the processing progress of the data loading task.

[0308] The present application scheme utilizes the high scheduling priority of the application UI thread to implement the priority execution of the SharedPreferences data loading task, thereby reducing the waiting time. Specifically, when the UI thread reads and writes data, if the SharedPreferences child thread has not started loading data, the UI thread will load the data instead of waiting for the SharedPreferences child thread to load. After the UI thread loads the data, the SharedPreferences child thread does not need to load again. When the UI thread reads and writes data, if the SharedPreferences child thread is already loading data, then adjust the scheduling priority of the SharedPreferences child thread to avoid blocking the UI thread due to the low priority of the SharedPreferences child thread. When the UI thread reads and writes data, if the SharedPreferences child thread has finished loading the data, then the UI thread directly reads and writes the data. When other child threads of the application are reading and writing SharedPreferences data, the default SharedPreferences read and write method is used.

[0309] Fig.12 The embodiment of the present application is shown based on Fig.11 Another exemplary flow chart of the data loading method provided by the process shown in FIG. Fig.11 compared to, Fig.12 The logic for determining whether the current application is the foreground application has been added. Specifically, in an embodiment of the present application, in a scenario where an application requests to obtain data, it can be determined whether the current application is the foreground application. When the current application is the foreground application, the data loading method provided in the embodiment of the present application is adopted, and the data loading task is performed by a high-priority UI thread to speed up data loading, or the data loading task is performed by a child thread and the scheduling priority of the child thread is increased to be scheduled first, so as to avoid long waiting times for the UI thread. When the current application is not a foreground application, the data loading task is completed using the Android default process, that is, the data loading task is performed by a SharedPreferences child thread and the scheduling priority of the SharedPreferences child thread remains unchanged. See the description below for details.

[0310] S601: A first application requests to obtain data.

[0311] S602: The UI thread of the first application calls the sp=getSharedPreferences() function to obtain a SharedPreferences object.

[0312] S603: The UI thread of the first application calls the sp.getInt() function to obtain the mLoaded value from the SharedPreferences object.

[0313] In the embodiment of the present application, when the UI thread of the application reads and writes data in the SharedPreferences object, the UI thread can call the getInt() function interface provided by SharedPreferences to read an integer value, such as the value of the mLoaded variable.

[0314] S604. The UI thread may call the awaitLoadedLocked function to analyze and determine the value of the mLoaded variable.

[0315] S605-S610: When mLoaded is LOAD_STATE_INIT, determine whether the first application is a foreground application. When the first application is a foreground application, the UI thread with a higher priority replaces the SharedPreferences sub-thread with a lower priority to perform the data loading task.

[0316] For example, the implementation code can be expressed as:

[0317] If(mloaded=LOAD_STATE_INIT){ / / The mloaded variable value indicates that data is being loaded

[0318] if(isUiThread()&&foreground application){ / / Judge whether the current application requesting data is the foreground application

[0319] loadFromDiskEx();} / / The data loading task is performed by the UI thread of the current application

[0320] }

[0321] Among them, mLoaded is LOAD_STATE_INIT and the first application is the foreground application, which indicates that the foreground application requests to obtain data and the SharedPreferences child thread has not started to load data. In this case, in order to avoid the foreground application from freezing, the UI thread of the foreground application first sets mLoaded to LOAD_STATE_DOING to mark that the data is loading and prevent the SharedPreferences child thread from loading again. Then the UI thread of the foreground application starts to load data. After the data is loaded, the UI thread of the foreground application sets mLoaded to LOAD_STATE_DONE to mark that the data has been loaded. Then the UI thread of the foreground application calls the notifyAll() function to notify other waiting threads that the data has been loaded. Then the UI thread of the foreground application reads the data, and the first application obtains the data.

[0322] It should be noted that, when mLoaded is LOAD_STATE_INIT and the first application is not a foreground application, the data loading task is completed using the Android default process, that is, the SharedPreferences child thread is scheduled according to the default scheduling priority to perform the data loading task.

[0323] S611-S614, when mLoaded is LOAD_STATE_DOING, determine whether the first application is a foreground application. When the first application is a foreground application, increase the scheduling priority of the SharedPreferences child thread, and the SharedPreferences child thread is scheduled according to the increased scheduling priority to execute the data loading task.

[0324] For example, the implementation code can be expressed as:

[0325] If(mloaded=LOAD_STATE_DOING){ / / mloaded variable value indicates that data is being loaded

[0326] if(isUiThread()&&foreground application){ / / Judge whether the current application requesting data is the foreground application

[0327] SetThreadPriority();} / / Raise the scheduling priority of the SharedPreferences child thread

[0328] }

[0329] Among them, mLoaded is LOAD_STATE_DOING and the first application is the foreground application, which indicates that the foreground application requests to obtain data and the SharedPreferences child thread is loading data. In this case, in order to avoid the foreground application from freezing, the priority of the SharedPreferences child thread can be increased. In this way, the SharedPreferences child thread can be scheduled according to the increased priority to perform the data loading task. Then, the UI thread of the foreground application waits. After receiving the notification that the data loading is complete sent by the SharedPreferences child thread, the UI thread of the foreground application can obtain the data, and thus the first application obtains the data.

[0330] It should be noted that, when mLoaded is LOAD_STATE_INIT and the first application is not a foreground application, the data loading task is completed using the Android default process, that is, the data loading task is performed by the SharedPreferences subthread.

[0331] S615. When mLoaded is LOAD_STATE_DONE, it indicates that the data has been loaded. At this time, there is no need to determine whether the current application is the foreground application. The UI thread exits the awaitLoadedLocked function, and the first application directly obtains the data.

[0332] Interaction process in scenarios where other sub-threads are used to read data

[0333] The above embodiment illustrates a possible implementation method of the interaction between the UI thread side and the SharedPreferences sub-thread side in the present application solution. The following describes a possible implementation method of the interaction between other sub-threads and the SharedPreferences sub-thread side in a scenario where other sub-threads of the application read data.

[0334] Fig.13 Schematic diagram of the interaction between the SharedPreferences sub-thread side and other sub-threads of the data loading method provided in the embodiment of the present application. Fig.13 As shown, the method includes the following steps S701-S716.

[0335] First of all, it should be noted that in the following embodiments, it is assumed that the default scheduling priority values ​​of the SharedPreferences sub-thread and other sub-threads are both 120. The higher the priority value, the lower the priority; the lower the priority value, the higher the priority.

[0336] S701-S703, other child threads call sp=getSharedPreferences() function to obtain SharedPreferences object. When obtaining the object for the first time, a SharedPreferences object is created, mLoaded is initialized to LOAD_STATE_INIT, and a SharedPreferences child thread is created during the process of creating the SharedPreferences object.

[0337] The description of S704 - S711 is similar to the detailed description of S504 - S511 described above.

[0338] Specifically, on the SharedPreferences child thread side, after the SharedPreferences child thread is created, the SharedPreferences child thread will execute the run entry function, at which time the thread number TID of the SharedPreferences child thread is obtained, and the thread number TID is saved to the SharedPreferences object, that is, the TID is associated with the SharedPreferences object and stored together. The SharedPreferences child thread then determines the data loading state corresponding to the mLoaded variable value. If the mLoaded variable value is LOAD_STATE_INIT, the SharedPreferences child thread sets mLoaded to LOAD_STATE_DOING to mark that data loading has begun to prevent the UI thread from loading again. The SharedPreferences child thread then starts loading data, and after the data is loaded, it sets mLoaded to LOAD_STATE_DONE to mark that data loading has been completed, and then the SharedPreferences child thread sends a notification of data loading completion to other waiting threads.

[0339] The following describes the specific improvement actions on the application side of other sub-threads provided by the embodiment of the present application. Fig.10 S402-S404 can be implemented through the following S712-S716.

[0340] S712. Call the sp.getInt() function to obtain the mLoaded value from the SharedPreferences object.

[0341] It should be noted that when applying other child threads to obtain the SharedPreferences object, if the object already exists in the memory, it is directly obtained; if the object does not exist in the memory, a SharedPreferences object is created. When creating the SharedPreferences object, mLoaded is initialized to LOAD_STATE_INIT, and a SharedPreferences child thread is created to load data.

[0342] S713. Call the awaitLoadedLocked function to analyze and determine the value of the mLoaded variable.

[0343] Among them, different mLoaded variable values ​​represent different data loading states and correspond to different execution actions.

[0344] S714. When the value of mLoaded is LOAD_STATE_DONE (i.e., loading is complete), other child threads of the application directly obtain the memory data corresponding to the SharedPreferences object.

[0345] S715. When the value of mLoaded is LOAD_STATE_DOING (i.e., loading in progress) or LOAD_STATE_INIT (i.e., loading has not started) or other states, other application child threads wait for the SharedPreferences child thread or the UI thread to complete the data loading task.

[0346] S716. After receiving the notification that data loading is complete, other child threads of the application obtain the memory data corresponding to the SharedPreferences object.

[0347] In the embodiment of the present application, on the side of other application sub-threads, if mLoaded is LOAD_STATE_DONE, then other application sub-threads directly read data; if mLoaded is not LOAD_STATE_DONE, then other application sub-threads wait until receiving a notification that data loading is complete before reading data.

[0348] It should be noted that the present application scheme does not simply increase the priority of the SharedPreferences child thread to avoid the SharedPreference child thread blocking the UI thread due to its low priority and inability to be scheduled in time. When the UI thread requests to read data, if the SharedPreferences child thread is loading data, the UI thread adjusts the priority of the SharedPreferences child thread so that the child thread is scheduled faster to quickly complete the data loading task; when the UI thread requests to read data, if the SharedPreferences child thread has not started loading data, then the UI thread directly loads the data by taking advantage of the relatively high priority of the UI thread itself, so that the program runs more smoothly.

[0349] It should be noted that when the UI thread requests to read data, the SharedPreferences child thread has not started loading data. At this time, the application solution is to load the data by the UI thread instead of directly raising the priority of the SharedPreferences child thread. The reason is:

[0350] On the one hand, when the UI thread requests to read data, the SharedPreferences child thread may not have been created yet, and the UI thread cannot obtain the thread number of the SharedPreferences child thread, so the priority cannot be set.

[0351] On the other hand, the application does not have permission to set real-time priority, so if you want to set the SharedPreferences child thread to real-time priority, the system needs to set it, and the application needs to notify the system through binder communication or other inter-process communication methods when to start raising the priority of the SharedPreferences child thread.

[0352] That is to say, when the UI thread requests to read data, it may not be possible to directly increase the priority of the SharedPreferences child thread before the SharedPreferences child thread starts loading data. In addition, setting the priority of the SharedPreferences child thread at this time requires the help of system permissions and communication interactions.

[0353] Through the solution of this application, when the UI thread requests to read data, the data loading task is executed through the UI thread before the SharedPreferences child thread starts loading data, and the above problem does not exist.

[0354] It should be noted that, in the above-mentioned figures, the process shown by the thin lines represents the basic implementation process of the present application scheme, and the process shown by the thick lines is used to reflect the steps related to the technical improvements involved in the present application scheme.

[0355] The various embodiments described herein may be independent solutions or may be combined according to internal logic, and all of these solutions fall within the protection scope of this application.

[0356] The above mainly describes the solution provided by the embodiment of the present application from the perspective of method steps. It is understandable that, in order to achieve the above functions, the electronic device implementing the method includes a hardware structure and / or software module corresponding to the execution of each function. Those skilled in the art should be aware that, in combination with the units and algorithm steps of each example described in the embodiments disclosed herein, the present application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a function is executed in the form of hardware or computer software driving hardware depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of protection of the present application.

[0357] The present application also provides a chip, which is coupled to a memory and is used to read and execute computer programs or instructions stored in the memory to execute the methods in the above embodiments.

[0358] The present application also provides an electronic device, which includes a chip, and the chip is used to read and execute a computer program or instruction stored in a memory, so that the method in each embodiment is executed.

[0359] This embodiment also provides a computer-readable storage medium, in which computer instructions are stored. When the computer instructions are executed on an electronic device, the electronic device executes the above-mentioned related method steps to implement the data loading method in the above-mentioned embodiment.

[0360] This embodiment also provides a computer program product, wherein the computer-readable storage medium stores program codes. When the computer program product is run on a computer, the computer executes the above-mentioned related steps to implement the data loading method in the above-mentioned embodiment.

[0361] Among them, the electronic device, computer-readable storage medium, computer program product or chip provided in this embodiment are all used to execute the corresponding methods provided above. Therefore, the beneficial effects that can be achieved can refer to the beneficial effects in the corresponding methods provided above and will not be repeated here.

[0362] In the several embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of modules or units is only a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another device, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0363] The term "and / or" in this article is a description of the association relationship of associated objects, indicating that there can be three relationships. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone. The symbol " / " in this article indicates that the associated objects are in an or relationship, for example, A / B means A or B.

[0364] The terms "first" and "second" in the specification and claims herein are used to distinguish different objects rather than to describe a specific order of objects. In the description of the embodiments of the present application, unless otherwise specified, the meaning of "multiple" refers to two or more than two, for example, multiple processing units refer to two or more processing units, etc.; multiple elements refer to two or more elements, etc.

[0365] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

Claims

1. A data loading method, characterized in that: include: At a first time point, start launching a first application; After the first time point, a first thread and a second thread of the first application are created, wherein the first thread is a user interface UI thread of the first application; and the second thread is a SharedPreferences subthread; After the second thread is created and before a second time point, requesting to obtain data through the first application, wherein the requested data is application configuration data stored in a SharedPreferences storage manner; At the second time point, different data loading states are determined based on the first variable value, and different first variable values ​​represent different data loading states; When it is determined that the second thread has completed loading the data, the first thread directly obtains the loaded data from the memory; If it is determined that the second thread is loading data, raising the scheduling priority of the second thread through the first thread; if it is determined that the second thread has not started loading data, starting to load data through the first thread; after the data loading is completed, updating the value of the first variable; After the second time point, destroying the second thread; After the data is loaded, at a third time point, a main interface of the first application is displayed; Among them, between the first time point and the third time point, the second application is run in the background; the second time point is later than the first time point, and the third time point is later than the second time point.

2. The method according to claim 1, characterized in that The method further comprises: After exiting the first application and the second application, starting to launch the first application at a fourth time point; After the fourth time point, creating the first thread and the second thread of the first application; At a fifth time point, starting to load data through the second thread; After the data is loaded, at a sixth time point, a main interface of the first application is displayed; After the sixth time point, the second thread is destroyed; between the fourth time point and the sixth time point, the second application is not running in the background.

3. The method according to claim 1, characterized in that: The method further comprises: At a seventh time point, starting the first application; After the seventh time point, creating the first thread and the second thread of the first application; At an eighth time point, starting to load data through the second thread; At a tenth time point, requesting to obtain data through the first thread, and if it is determined that the second thread is loading data, raising the scheduling priority of the second thread through the first thread; After the data is loaded, at a ninth time point, the main interface of the first application is displayed; Wherein, after the ninth time point, the second thread is destroyed; the tenth time point is later than the eighth time point, and the ninth time point is later than the tenth time point.

4. The method according to any one of claims 1 to 3, characterized in that The scheduling priority of the second thread is lower than the scheduling priority of the first thread.

5. The method according to any one of claims 1 to 3, characterized in that The acquiring of data through the first application request includes: The data loaded by the second thread is read through a request by the first thread.

6. The method according to claim 1, characterized in that The step of starting to load data through the first thread when it is determined that the second thread has not started to load data includes: When data loading has not started and the first application is a foreground application, data loading starts through the first thread.

7. The method according to any one of claims 1 to 3, characterized in that The loading data includes: Load data from hard disk into memory.

8. The method according to claim 7, characterized in that After the data is loaded, at a third time point, displaying the main interface of the first application includes: After loading the data from the hard disk into the memory, reading the data from the memory through the first thread; At the third time point, a main interface of the first application is displayed based on the read data.

9. The method according to claim 1, characterized in that: The different loading states include: loading not started state, loading in progress state, loading completed state; Wherein, when it is determined that the second thread has completed loading data, the first thread directly obtains the loaded data from the memory; when it is determined that the second thread is loading data, the scheduling priority of the second thread is increased through the first thread; when it is determined that the second thread has not started loading data, the data is started to be loaded through the first thread, including: When the first variable value is a first value and the first value indicates a loading completion state, the first thread directly obtains the loaded data from the memory; When the value of the first variable is a second value and the second value indicates a loading state, raising the scheduling priority of the second thread through the first thread, and loading data through the second thread at the raised scheduling priority; When the first variable value is a third value and the third value indicates that loading is not started, data loading through the first thread starts.

10. The method according to claim 9, characterized in that The loading of data through the first thread includes: The first thread calls the loadFromDisk function to load data.

11. The method according to claim 10, characterized in that The method further comprises: After the data loading is completed, a notification message of the completion of the data loading is sent to the third thread of the first application through the first thread.

12. The method according to claim 11, characterized in that The method further comprises: The third thread requests to read data; When it is determined that the data has not started to be loaded or is being loaded, the data is read after receiving a notification message indicating that the loading is complete; When it is determined that the data loading is complete, the loaded data is read.

13. The method according to any one of claims 1 to 3, characterized in that After the second time point, destroying the second thread includes: After the second time point, it is determined that the first thread is loading data, and the second thread is destroyed.

14. The method according to claim 3, characterized in that The step of starting to load data through the second thread at the eighth time point includes: At the eighth time point, it is determined that data loading has not started, and the first variable value is updated by the second thread, and the updated first variable value indicates a loading state; Calling the loadFromDisk function through the second thread to load data; After the data loading is completed, the first variable value is updated through the second thread, and the updated first variable value indicates the loading completion status.

15. The method according to any one of claims 1 to 3, characterized in that Before starting the first application, the method further includes: In response to a user setting operation on the first application, storing data corresponding to the first application in a memory based on a SharedPreferences object, and then writing the data from the memory to a hard disk; In response to a user operation, the first application is closed.

16. The method according to claim 9, characterized in that Before determining the data loading state based on the first variable value, the method further includes: A first read function is called to obtain the first variable value from the SharedPreferences object.

17. The method according to claim 16, characterized in that Before calling the first read function to obtain the first variable value from the SharedPreferences object, the method further includes: The first thread calls the getSharePreferences function to obtain the SharedPreferences object from the memory; If the SharedPreferences object does not exist in the memory, create the SharedPreferences object in the memory.

18. The method according to claim 17, characterized in that The method further comprises: The second thread is created when the SharedPreferences object is created.

19. An electronic device, characterized in that: The electronic device includes: one or more processors, and a memory; The memory is coupled to the one or more processors, and the memory is used to store computer program codes, wherein the computer program codes include computer instructions, and the one or more processors call the computer instructions to enable the electronic device to perform the method according to any one of claims 1 to 18.

20. A chip system, characterized in that: The chip system is applied to an electronic device, and the chip system includes one or more processors, and the one or more processors are used to call computer instructions so that the electronic device executes the method as described in any one of claims 1 to 18.

21. A computer-readable storage medium, characterized in that: The computer-readable storage medium comprises instructions, which, when executed on an electronic device, cause the electronic device to perform the method as claimed in any one of claims 1 to 18.

Images