Wallpaper display method and device, medium and product

Abstract

The invention relates to the technical field of terminals, in particular to a wallpaper display method and device, a medium and a product. According to the method, the electronic equipment can obtain real-time user state information, and at least one scene matched with the real-time user state information is determined from the matching relation between the state information stored in the electronic equipment and the scene. Furthermore, the electronic equipment can determine the target wallpaper from the wallpaper corresponding to each scene in the at least one scene for display. In this way, it can be guaranteed that the wallpaper displayed by the electronic device can be automatically adjusted according to the real-time state of the user, and therefore diversified wallpaper display experience can be provided for the user.

Description

Technical Field

[0001] This application relates to the field of terminal technology, and in particular to a wallpaper display method, device, medium and product. Background Technology

[0002] Electronic devices, such as mobile phones, can display a desktop wallpaper when powered on or a lock screen wallpaper when locked, such as a static or live wallpaper. The static or live wallpaper displayed on an electronic device is generally one preset by the user or the system default wallpaper. Additionally, if the user selects the magazine lock screen function, the electronic device will switch between multiple images while locked; these images may be pre-selected by the user or provided by the system. Therefore, if the user does not modify the wallpaper settings, the wallpaper will always display according to the preset settings and will not automatically provide the user with a diverse wallpaper display experience. Summary of the Invention

[0003] To address the issue that electronic devices do not automatically provide users with diverse wallpaper display experiences, embodiments of this application provide a wallpaper display method, device, medium, and product, including:

[0004] In a first aspect, embodiments of this application provide a wallpaper display method applied to an electronic device, comprising: detecting that the electronic device enters a first display state, and determining that the user scenario in which the electronic device is located forms a first candidate scenario set, and the first candidate scenario set corresponds to a first candidate wallpaper set, the first candidate wallpaper set including multiple wallpapers; displaying a first wallpaper in the first candidate wallpaper set, wherein the first wallpaper is a wallpaper of a first user scenario in the first candidate scenario set, and the display content of the first wallpaper is related to the scenario factors of the first user scenario; detecting that the electronic device enters a second display state from the first display state, and then re-entering the first display state; corresponding to when the electronic device re-enters the first display state, determining that the user scenario in which the electronic device is located also forms a first candidate scenario set, and displaying a second wallpaper in the first candidate wallpaper set, wherein the second wallpaper and the first wallpaper are different wallpapers.

[0005] Based on the above solution, by performing real-time analysis of the scene in which the electronic device is located and displaying corresponding wallpapers for different scenes, a diverse wallpaper display experience can be automatically provided to users.

[0006] It is understandable that in some optional implementations, the first display state is the lock screen state, and the second display state is the desktop state. Alternatively, the first display state may be the lock screen state, and the second display state may be the screen off state. Or, the first display state may be the desktop state, and the second display state may be the screen off state. Finally, the first display state may be the desktop state, and the second display state may be the lock screen state.

[0007] It is understandable that, in some optional implementation methods, user scenarios can include birthday scenarios, holiday scenarios, sunrise / sunset scenarios, music scenarios, sports scenarios, and weather scenarios. Among these, weather scenarios can include sunny scenarios, windy scenarios, and so on.

[0008] In some optional implementations of the first aspect, the second wallpaper is the wallpaper of the first user scenario in the first set of candidate scenarios, and the display content of the second wallpaper is related to the scenario factors of the first user scenario; or the second wallpaper is the wallpaper of the second user scenario in the first set of candidate scenarios, and the display content of the second wallpaper is related to the scenario factors of the second user scenario.

[0009] For example, if the first user scenario is a birthday scene, then the first wallpaper could be birthday video 1, and the second wallpaper could be birthday video 2. Therefore, different wallpapers can be displayed when the electronic device is in the same scenario, thus increasing the diversity of wallpapers provided to the user.

[0010] For example, if the first user scenario is a birthday, the first wallpaper could be "Birthday Video 1"; if the second user scenario is Christmas, the second wallpaper could be "Christmas Video 1". Therefore, different wallpapers can be displayed when the electronic device is in different scenarios, thus increasing the diversity of wallpapers provided to users.

[0011] In some optional implementations of the first aspect, the method further includes: corresponding to when the electronic device re-enters the first display state, determining that the user scenario in which the electronic device is located forms a second set of candidate scenarios, and displaying a third wallpaper from the second set of candidate wallpapers, wherein at least one user scenario in the second set of candidate scenarios is different from that in the first set of candidate scenarios, and the third wallpaper, the second wallpaper, and the first wallpaper are different wallpapers.

[0012] It is understandable that at least one wallpaper in the first set of candidate wallpapers and the second set of candidate wallpapers are different.

[0013] In some optional implementations of the first aspect, corresponding to the second set of candidate scenarios and the first set of candidate scenarios including the first user scenario, the third wallpaper is the wallpaper of the first user scenario in the second set of candidate scenarios, and the display content of the third wallpaper is related to the scenario factors of the first user scenario; or the third wallpaper is the wallpaper of the third user scenario in the second set of candidate scenarios, and the display content of the third wallpaper is related to the scenario factors of the third user scenario.

[0014] For example, if both the first and second candidate scene sets include a first user scene, and the first user scene is a birthday scene, then the first wallpaper could be birthday video 1, and the third wallpaper could be birthday video 3. Therefore, when the electronic device is in the same scene, different wallpapers can be displayed, thus increasing the diversity of wallpapers provided to the user.

[0015] For example, if the user scenarios in the first and second candidate scenario sets are different, and the first user scenario is a birthday scenario, then the first wallpaper could be "Birthday Video 1," and the third user scenario is a music scenario, then the second wallpaper could be "Music Video 1." Therefore, different wallpapers can be provided to display when the electronic device is in different scenarios, thus increasing the diversity of wallpapers offered to users.

[0016] Among some alternative implementations of the first aspect, the method also includes: determining the user scenario in which the electronic device is located based on scenario factors.

[0017] In some specific implementations, the user scenario in which the electronic device is located can be determined by identifying at least one scenario that matches the scene factors stored in the electronic device and the matching relationship between the scenes.

[0018] In some alternative implementations of the first aspect, the scenario factors include at least one of the following: time related to the user scenario, space in which the electronic device is located, the user's emotions regarding the electronic device, and user behavior of the user regarding the electronic device.

[0019] In some alternative implementations of the first aspect, the time related to the user scenario includes at least one of the user's birthday, holidays, solar terms, and travel dates.

[0020] In some optional implementations of the first aspect, scenario factors are obtained in the following ways: obtaining the user's birthday based on information recorded in a memo app; obtaining at least one of a holiday and a solar term based on information recorded in a calendar app; obtaining the travel date based on order information from a ticketing app; obtaining the location of the electronic device based on information recorded in a weather app; obtaining at least one of the user's birthday, holiday, solar term, user's mood, and user behavior based on text information from a social app; obtaining at least one of the user's birthday, user's mood, and user behavior based on chat information from a communication app; and obtaining the user's behavior based on usage information from a fitness app.

[0021] In some alternative implementations of the first aspect, the user's emotions in the electronic device are obtained by: acquiring a facial image of the user captured by an image acquisition device in the electronic device; and determining the user's emotions based on the facial image.

[0022] In some optional implementations of the first aspect, the method further includes: corresponding to the first candidate scene set including multiple candidate user scenes, and the multiple candidate user scenes belonging to multiple scene types, selecting a first user scene from the multiple candidate user scenes based on the number of multiple candidate user scenes and the display priority of the scene type to which each candidate user scene belongs; and using a wallpaper corresponding to the first user scene as the first wallpaper.

[0023] In this embodiment of the application, wallpapers are selected for display based on the number of candidate user scenarios and the display priority of the scenario type to which each candidate user scenario belongs. For example, when the display priority of the scenario type to which the birthday scenario belongs is higher than the display priority of the scenario type to which the Christmas scenario belongs (the birthday video under the birthday scenario has a higher probability of being selected), the birthday video under the birthday scenario is displayed, which can make the displayed wallpaper more in line with the user's customization needs.

[0024] In some optional implementations of the first aspect, the first user scenario is selected from multiple candidate user scenarios based on the number of candidate user scenarios and the display priority of the scenario type to which each candidate user scenario belongs. This includes: determining the interval corresponding to the playback probability of each candidate user scenario based on the number of multiple candidate user scenarios and the display priority of the scenario type to which each candidate user scenario belongs, wherein the higher the display priority of the scenario type to which the candidate user scenario belongs, the larger the interval corresponding to the playback probability of the candidate user scenario belongs to; generating a random number; and determining the candidate user scenario corresponding to the interval to which the random number falls as the first user scenario.

[0025] It is understandable that the number of candidate user scenarios can be considered as the number of scenario matches.

[0026] For example, the candidate user scenarios include four sub-scenarios: a birthday in a specific personal context, Christmas in a holiday-themed context, music in a personal state context, and rain in a natural environment context. That is, a birthday falls on Christmas Day, it's raining outside, and the user is listening to music. Thus, the electronic device can determine the playback probability for the birthday scenario as 50%, the Christmas scenario as 25%, the music scenario as 15%, and the rain scenario as 10%. Therefore, the playback probability interval for the birthday scenario is [1, 50], for the Christmas scenario as [51, 75], for the music scenario as [76, 90], and for the rain scenario as [91, 100]. If the randomly generated number is 52, then the first user scenario can be the Christmas scenario.

[0027] In some optional implementations of the first aspect, using a wallpaper corresponding to the first user scenario as the first wallpaper includes: randomly selecting a wallpaper from multiple candidate wallpapers of the first user scenario in the first candidate wallpaper set as the first wallpaper.

[0028] In this embodiment of the application, when the user scenario in which the electronic device is located forms a first set of candidate scenarios, the diversity of wallpapers provided to the user can be further improved by randomly selecting a wallpaper from multiple candidate wallpapers of the first user scenario in the first set of candidate scenarios for display.

[0029] In some optional implementations of the first aspect, the method further includes: corresponding to the first candidate scenario set including multiple candidate user scenarios, randomly selecting one candidate user scenario from the multiple candidate user scenarios as the first user scenario; and using a wallpaper corresponding to the first user scenario as the first wallpaper.

[0030] In this embodiment of the application, when the user scenarios in which the electronic device is located form a first set of candidate scenarios, the diversity of wallpapers provided to the user can be further improved by randomly selecting a wallpaper corresponding to the user scenario from the first set of candidate scenarios for display.

[0031] In some optional implementations of the first aspect, the method further includes: corresponding to the first candidate scene set including multiple candidate user scenes, selecting a first user scene from the multiple candidate user scenes based on the number of multiple candidate user scenes and the display priority of each candidate user scene; and using a wallpaper corresponding to the first user scene as the first wallpaper.

[0032] For example, the candidate user scenarios include four sub-scenarios: birthday, Christmas, music, and rain. That is, the user's birthday is on Christmas Day, it's raining outside, and the user is listening to music. Thus, the electronic device can determine the playback probability for the birthday scenario as 50%, the Christmas scenario as 25%, the music scenario as 15%, and the rain scenario as 10%. Therefore, the playback probability interval for the birthday scenario is [1, 50], for the Christmas scenario as [51, 75], for the music scenario as [76, 90], and for the rain scenario as [91, 100]. If the randomly generated number is 52, then the first user scenario can be the Christmas scenario.

[0033] In some alternative implementations of the first aspect, the method further includes: randomly selecting a wallpaper from a first set of candidate wallpapers as the first wallpaper.

[0034] In this embodiment of the application, when the user scenario in which the electronic device is located forms a first set of candidate scenarios, the diversity of wallpapers provided to the user can be further improved by randomly selecting a wallpaper from the first set of candidate wallpapers corresponding to the first set of candidate scenarios.

[0035] In some optional implementations of the first aspect, the first display state includes a locked screen state, and the second display state includes one of an unlocked state and a screen-off state; or the first display state includes an unlocked state, and the second display state includes one of a screen-off state and a locked screen state; or the first display state includes a first desktop state, and the second display state includes a second desktop state, wherein the first desktop state and the second desktop state are different desktops, and the desktop includes a central desktop, a first page of the desktop, and a second page of the desktop.

[0036] In some optional implementations of the first aspect, after detecting that the electronic device enters the second display state from the first display state and then re-enters the first display state, the method includes: detecting that the electronic device enters the second display state and the third display state sequentially from the first display state and then re-enters the first display state; wherein the first display state includes a locked screen state, the second display state is an unlocked state, and the third display state is a screen-off state.

[0037] In a second aspect, this application provides an electronic device, comprising: a memory for storing instructions executed by one or more processors of the electronic device, and a processor, which is one of the one or more processors of the electronic device, for executing the wallpaper display method mentioned in the first aspect or any of the first aspects of this application.

[0038] Thirdly, this application provides a readable storage medium storing instructions that, when executed on an electronic device, cause the electronic device to perform the wallpaper display method mentioned in the first aspect or any of the first aspects of this application.

[0039] Fourthly, embodiments of this application provide a computer program product, which includes computer instructions. When executed by an electronic device, the electronic device executes the computer program code of the wallpaper display method mentioned in the first aspect or any one of the first aspects of this application. Attached Figure Description

[0040] Figure 1 A lock screen interface 110 of a mobile phone 100 is shown;

[0041] Figure 2A According to some embodiments of this application, a schematic diagram of a screen-on process is shown;

[0042] Figure 2B According to some embodiments of this application, a schematic diagram of a screen-on interface is shown;

[0043] Figure 2C According to some embodiments of this application, another schematic diagram of a screen-on interface is shown;

[0044] Figure 3A According to some embodiments of this application, a schematic diagram of a screen-off process is shown.

[0045] Figure 3B According to some embodiments of this application, a schematic diagram of a screen-off interface is shown;

[0046] Figure 3C According to some embodiments of this application, another schematic diagram of a screen-off interface is shown;

[0047] Figure 4 According to some embodiments of this application, a schematic diagram of multiple layers overlay is shown;

[0048] Figure 5 According to some embodiments of this application, a flowchart of a wallpaper display method is shown;

[0049] Figure 6A According to some embodiments of this application, a flowchart of another wallpaper display method is shown;

[0050] Figure 6B According to some embodiments of this application, an interactive flow diagram of a wallpaper display method based on a display system is shown;

[0051] Figure 7 According to some embodiments of this application, a unified modeling language class diagram for a state acquisition module is shown;

[0052] Figure 8 According to some embodiments of this application, a comparative schematic diagram of a listening event is shown;

[0053] Figure 9 A schematic diagram of event distribution is shown according to some embodiments of this application;

[0054] Figure 10 According to some embodiments of this application, a schematic diagram of the architecture of a software system for an electronic device is shown;

[0055] Figure 11A According to some embodiments of this application, an interactive schematic diagram of a method for subscribing to music events is shown;

[0056] Figure 11B According to some embodiments of this application, an interactive schematic diagram of a method for querying music events based on an active query approach is shown;

[0057] Figure 11C According to some embodiments of this application, an interactive schematic diagram of a method based on immediate querying of music events is shown;

[0058] Figure 11D According to some embodiments of this application, an interactive schematic diagram of a method for querying music events based on a passive query approach is shown;

[0059] Figure 11E According to some embodiments of this application, an interactive schematic diagram of a method for querying music events based on a periodic query method is shown;

[0060] Figure 12 According to some embodiments of this application, a flowchart of multiple events accessing an event manager is shown;

[0061] Figure 13A According to some embodiments of this application, a schematic diagram of all video mapping information is shown;

[0062] Figure 13B According to some embodiments of this application, a schematic diagram of the mapping relationship between the main scene and sub-scenes to be played is shown;

[0063] Figure 13C According to some embodiments of this application, a schematic diagram of a matched scene and video mapping relationship is shown;

[0064] Figure 14 According to some embodiments of this application, a schematic diagram of a video that satisfies the current scenario is shown;

[0065] Figure 15 According to some embodiments of this application, a schematic diagram of a video that satisfies the current scenario before and after an update is shown;

[0066] Figure 16 According to some embodiments of this application, a flowchart of a video recommendation method is shown;

[0067] Figure 17 According to some embodiments of this application, a flowchart illustrating a method for updating a hash table of matched scene-to-video mapping relationships is shown.

[0068] Figure 18 According to some embodiments of this application, a schematic diagram of the hardware structure of an electronic device is shown;

[0069] Figure 19 According to some embodiments of this application, a block diagram of a software system for an electronic device is shown;

[0070] Figure 20According to some embodiments of this application, a block diagram of a software system for another electronic device is shown;

[0071] Figure 21 According to some embodiments of this application, a flowchart of another wallpaper display method is shown. Detailed Implementation

[0072] The embodiments of this application include, but are not limited to, a wallpaper display method, device, medium, and product.

[0073] It is understood that the wallpaper display method mentioned in the embodiments of this application can be applied to electronic devices. These electronic devices can also be referred to as terminals, user equipment (UE), mobile stations (MS), mobile terminals (MT), etc.

[0074] It can be understood that electronic devices can include smartphones, smart TVs, wearable devices, tablets, computers with wireless transceiver capabilities, virtual reality (VR) terminal devices, augmented reality (AR) terminal devices, wireless terminal devices in industrial control, wireless terminals in self-driving, wireless terminals in transportation safety, wireless terminals in smart cities, wireless terminals in smart homes, smart picture frames, and other devices with image display capabilities. The images can include still images and videos.

[0075] As mentioned earlier, electronic devices can display wallpapers preset by the user or as the device's default wallpaper. Figure 1 The image shows a lock screen interface 110 of a mobile phone 100. This lock screen interface 110 includes a lock screen wallpaper 111, a clock component 112, lock screen icons 113, and a status bar 114. If the user does not modify the lock screen wallpaper settings, the electronic device will continuously display the lock screen wallpaper 111 when entering lock screen mode, and will not automatically provide the user with a diverse lock screen wallpaper display experience.

[0076] It is understood that the wallpaper display method mentioned in the embodiments of this application is applicable to the scenario where an electronic device displays an unlocked wallpaper in an unlocked state, and also applicable to the scenario where an electronic device displays a lock screen wallpaper in a locked state.

[0077] To address the aforementioned problems, this application provides a wallpaper display method. In this method, the electronic device can perform real-time analysis of the scene in which it is located and display corresponding wallpapers for different scenes.

[0078] For example, the scenarios in which electronic devices are used can include: birthday scenarios, holiday scenarios, sunrise scenarios, music scenarios, sports scenarios, sunny day scenarios, windy scenarios, and so on.

[0079] Specifically, in some embodiments, the electronic device can determine the current scene based on the matching relationship between state information and scene, as well as real-time user state information.

[0080] For example, electronic devices can acquire real-time user status information (i.e., the scene factors mentioned above), such as the time related to the user's scene, the space where the electronic device is located, the user's emotions, and the user's behavior. Based on the matching relationship between the status information stored on the electronic device and the scenes, the electronic device can determine at least one scene that matches the real-time user status information. Furthermore, the electronic device can determine the target wallpaper (e.g., the first wallpaper, second wallpaper, or third wallpaper mentioned earlier) from the wallpapers corresponding to each scene within at least one scene and display it. In this way, the wallpaper displayed by the electronic device can be automatically adjusted according to the user's real-time status, thereby providing the user with a diverse wallpaper display experience.

[0081] For example, if real-time user status information indicates that the user's time is a birthday, the electronic device is in a sunrise environment, and the user's behavior is listening to music, then the electronic device can determine that the real-time user status information matches the following scenarios: birthday, sunrise, and music. In this way, the electronic device can select the target wallpaper from multiple wallpapers corresponding to these three scenarios for display.

[0082] The target wallpaper can be any one of multiple wallpapers corresponding to the three scenes of birthday, sunrise, and music, or it can be the wallpaper with the highest playback probability among the multiple wallpapers corresponding to the three scenes of birthday, sunrise, and music. In some implementations, the electronic device can store the display priority of different scene types. Specifically, the higher the display priority of the scene type, the greater the playback probability of the wallpaper corresponding to that scene.

[0083] In some alternative implementations, electronic devices can obtain real-time user status information based on application data from various applications within the device. For example, an electronic device can obtain time-related information such as birthdays and anniversaries based on information recorded in a memo app; it can obtain time-related information such as Christmas based on information recorded in a calendar app; and it can obtain user behavior such as listening to music based on the playback status of a music app.

[0084] The following section introduces the background display method for wallpaper display.

[0085] It is understood that the display states of electronic devices can include screen-off state, screen-off state, screen-locked state, and unlocked state (i.e., desktop state). Among them, the screen-off state can include always-on display (AOD) mode and full-screen AOD mode.

[0086] The following describes the screen-on and screen-off processes of electronic devices when the always-on display function is enabled.

[0087] During the screen-on process of some electronic devices, such as Figure 2A As shown, when an electronic device is in AOD (Awake-On) state, if a user's wake-up operation (such as clicking the power button or double-tapping the screen) is detected, the electronic device can switch from AOD state to lock screen state. Subsequently, if a user's unlock operation is detected, the electronic device can switch from lock screen state to desktop state.

[0088] In some implementations, such as Figure 2B As shown, when the always-on display function of the electronic device is in partial AOD mode, and the electronic device is in partial AOD state (i.e., a local area of ​​the screen displays information at a relatively low brightness while the rest of the screen is off), if a user's wake-up operation (e.g., clicking the power button) is detected, the electronic device can switch from the partial AOD state shown in (a) to the first frame of the lock screen shown in (b), and gradually transition to the last frame of the lock screen shown in (c). Afterwards, if a user's unlock operation is detected, the electronic device can switch from the last frame of the lock screen shown in (c) to the desktop state shown in (d).

[0089] In other implementations, such as Figure 2C As shown, when the always-on display (AOD) function of the electronic device is in full-screen AOD mode, and the electronic device is in full-screen AOD state (i.e., the entire screen area of ​​the electronic device displays information at a relatively low brightness), if a user's wake-up operation (e.g., clicking the power button) is detected, the electronic device can switch from the full-screen AOD state shown in (a) to the first frame of the lock screen state shown in (b), and gradually transition to the last frame of the lock screen state shown in (c). Afterwards, if a user's unlock operation is detected, the electronic device can switch from the last frame of the lock screen state shown in (c) to the desktop state shown in (d).

[0090] During the screen-off process of some electronic devices, such as Figure 3AAs shown, when an electronic device is in desktop mode, if a user's screen lock operation (such as clicking the power button) is detected, the electronic device can first switch from desktop mode to screen lock mode, and then switch from screen lock mode to AOD mode.

[0091] In some implementations, such as Figure 3B As shown, when the always-on display function of an electronic device is in partial AOD mode and the electronic device is in desktop mode, if a user's screen-locking operation (e.g., clicking the power button) is detected, the electronic device can switch from the desktop state shown in (a) to the first frame of the locked screen state shown in (b), and then sequentially switch to the last frame of the locked screen state shown in (c), the screen-off state shown in (d), and the partial AOD state shown in (e). The screen-off state can last from 260ms to 300ms.

[0092] In other implementations, such as Figure 3C As shown, when the always-on display function of the electronic device is in full-screen AOD mode and the electronic device is in desktop mode, if the user's screen lock operation (such as clicking the power button) is detected, the electronic device can switch from the desktop state shown in (a) to the first frame state of the lock screen shown in (b), and then switch sequentially to the last frame state of the lock screen shown in (c) and the full-screen AOD state shown in (d).

[0093] It is understood that when the always-on display function of an electronic device is turned off, the switching process of the display state of the electronic device can be always-on display state - locked screen state - desktop state. This application embodiment will not be described in detail here.

[0094] It is understandable that the content displayed on an electronic device can be the result of multiple layers being overlaid. For example, such as Figure 4 As shown, when an electronic device is in partial AOD (Always-On Display) or full-screen AOD mode, the content displayed by the electronic device is an AOD layer (e.g., Figure 4 ①) Lock screen layer (e.g.) Figure 4 ②) and wallpaper layers (e.g.) Figure 4 The content after superimposing ③) in the middle.

[0095] For example, when an electronic device is in partial AOD (Away From Home) mode, the AOD layer is placed above the lock screen layer, which in turn is placed above the wallpaper layer. Furthermore, the AOD layer includes information such as time and date, and it has a certain degree of transparency. Thus, when the electronic device is in partial AOD mode, the content displayed can include the faintly visible content of the lock screen layer and the wallpaper layer.

[0096] It is understood that electronic devices can display the unlock wallpaper in desktop mode or the lock screen wallpaper in lock screen mode. The wallpaper display method mentioned in the embodiments of this application will be described below.

[0097] like Figure 5 The diagram illustrates a flowchart of a wallpaper display method. This method can be executed by an electronic device, such as the aforementioned mobile phone 100. Specifically, the wallpaper display method may include:

[0098] 501: The electronic device is detected to have entered the first display state, and the user scenario in which the electronic device is located is determined to form a first set of candidate scenarios. The first wallpaper in the first set of candidate wallpapers is displayed.

[0099] It's understandable that the first display state can be either the lock screen state or the desktop state.

[0100] In some optional implementations, the electronic device can determine the user scenario in which the electronic device is located based on scenario factors. These scenario factors may include: time related to the user scenario, the space in which the electronic device is located, the user's emotions, and the user's behavior. Time related to the user scenario may include the user's birthday, holidays, solar terms, travel dates, etc., but this application embodiment does not impose specific limitations on these factors.

[0101] It can be understood that the first set of candidate scenes can correspond to the first set of candidate wallpapers, and the first set of candidate wallpapers can include multiple wallpapers such as the first wallpaper and the second wallpaper. Among them, the first wallpaper can be the wallpaper of the first user scene in the first set of candidate wallpapers, and the display content of the first wallpaper can be related to the scene factors of the first user scene.

[0102] It's understandable that in some ways of acquiring contextual factors, electronic devices can obtain these factors based on application data from various applications within the device. For example, an electronic device can obtain a user's birthday based on information recorded in a memo app; holidays and solar terms based on information recorded in a calendar app; travel dates based on order information from a ticketing app; the location of the electronic device based on information recorded in a weather app; user birthdays, holidays, solar terms, user emotions, and user behaviors based on text information from social apps; user birthdays, user emotions, and user behaviors based on chat information from communication apps; and user behaviors based on usage information from fitness apps.

[0103] For example, if the first user scenario is a birthday, then the first wallpaper could be "Birthday Video 1". Similarly, if the first user scenario is Christmas, then the first wallpaper could be "Christmas Video 1". Therefore, different wallpapers can be displayed when the electronic device is in different scenarios, thus increasing the diversity of wallpapers provided to the user.

[0104] In other ways of acquiring contextual factors, electronic devices can determine a user's emotions based on facial images captured by image acquisition devices (such as cameras).

[0105] In some methods for determining the first wallpaper, the first candidate scene set includes multiple candidate user scenes, and these multiple candidate user scenes belong to multiple scene types. The electronic device can select the first user scene from the multiple candidate user scenes based on the number of multiple candidate user scenes and the display priority of the scene type to which each candidate user scene belongs. Furthermore, the electronic device can use the wallpaper corresponding to the first user scene as the first wallpaper. Specifically, the electronic device can randomly select a wallpaper from the multiple candidate wallpapers of the first user scene in the first candidate wallpaper set as the first wallpaper.

[0106] The process of selecting the first user scenario from multiple candidate user scenarios includes: determining the interval corresponding to the playback probability of each candidate user scenario based on the number of multiple candidate user scenarios and the display priority of the scenario type to which each candidate user scenario belongs, wherein the higher the display priority of the scenario type to which the candidate user scenario belongs, the higher the playback probability of the candidate user scenario; generating a random number; and determining the candidate user scenario corresponding to the interval to which the random number falls as the first user scenario.

[0107] For example, the candidate user scenarios include four sub-scenarios: birthday, Christmas, music, and rain. The display priority of the birthday scenario type is higher than that of the Christmas scenario type, which in turn is higher than that of the music scenario type, which is higher than that of the rain scenario type. Thus, the electronic device can determine that the playback probability for the birthday scenario is 50%, the Christmas scenario is 25%, the music scenario is 15%, and the rain scenario is 10%. Therefore, the playback probability range for the birthday scenario is [1, 50], for the Christmas scenario is [51, 75], for the music scenario is [76, 90], and for the rain scenario is [91, 100]. If the randomly generated number is 52, then the first user scenario can be the Christmas scenario.

[0108] In other methods of determining the first wallpaper, the first candidate scene set includes multiple candidate user scenes. The electronic device can randomly select one candidate user scene from the multiple candidate user scenes as the first user scene, and the electronic device can select a wallpaper corresponding to the first user scene as the first wallpaper. Specifically, the electronic device can randomly select a wallpaper from the multiple candidate wallpapers of the first user scene in the first candidate wallpaper set as the first wallpaper.

[0109] In other methods of determining the first wallpaper, the first candidate scene set includes multiple candidate user scenes. The electronic device can determine the first wallpaper based on the number of candidate user scenes and the display priority of each candidate user scene. Furthermore, the electronic device can select a first user scene from the multiple candidate user scenes and use the wallpaper corresponding to the first user scene as the first wallpaper. Specifically, the electronic device can randomly select a wallpaper from the multiple candidate wallpapers of the first user scene in the first candidate wallpaper set as the first wallpaper.

[0110] The process of selecting the first user scenario from multiple candidate user scenarios includes: determining the interval corresponding to the playback probability of each candidate user scenario based on the number of candidate user scenarios and the display priority of each candidate user scenario, wherein the higher the display priority of the candidate user scenario, the higher the playback probability of the candidate user scenario; generating a random number; and determining the candidate user scenario corresponding to the interval in which the random number falls as the first user scenario.

[0111] For example, the candidate user scenarios include four sub-scenarios: birthday, Christmas, music, and rain. The display priority of the birthday scenario is higher than that of the Christmas scenario, which is higher than the music scenario, which is higher than the rain scenario. Thus, the electronic device can determine that the playback probability for the birthday scenario is 50%, the Christmas scenario is 25%, the music scenario is 15%, and the rain scenario is 10%. Therefore, the playback probability interval for the birthday scenario is [1, 50], for the Christmas scenario it is [51, 75], for the music scenario it is [76, 90], and for the rain scenario it is [91, 100]. If the randomly generated number is 52, then the first user scenario can be the Christmas scenario.

[0112] In other methods of determining the first wallpaper, the electronic device may randomly select a wallpaper from a first set of candidate wallpapers as the first wallpaper.

[0113] 502: After detecting that the electronic device has entered the second display state from the first display state, it enters the first display state again.

[0114] In some alternative implementations, when the first display state is the lock screen state, if the electronic device detects a user's unlocking operation (such as entering a password or fingerprint), the electronic device can switch from the lock screen state to the second display state, i.e., the desktop state. Subsequently, if the electronic device detects a user's lock screen operation (such as clicking the power button), the electronic device can switch back from the second display state to the first display state, i.e., the lock screen state.

[0115] In some alternative implementations, when the first display state is the locked screen state, if the electronic device detects a user's screen-off operation (e.g., clicking the power button), the electronic device can switch from the locked screen state to the second display state, i.e., the screen-off state. Subsequently, if the electronic device detects a user's wake-up operation (e.g., clicking the power button or double-tapping the screen), the electronic device can switch back from the second display state to the first display state, i.e., the locked screen state.

[0116] In some alternative implementations, when the first display state is the desktop state, if the electronic device detects a user's screen-off operation (e.g., clicking the power button), the electronic device can switch from the desktop state to the second display state, i.e., the screen-off state. Subsequently, if the electronic device detects a user's wake-up operation (e.g., clicking the power button or double-tapping the screen), the electronic device can switch back from the second display state to the first display state, i.e., the desktop state.

[0117] In some alternative implementations, when the first display state is the desktop state, if the electronic device detects a user's screen-locking operation (e.g., clicking the power button), the electronic device can switch from the desktop state to the second display state, i.e., the lock screen state. Subsequently, if the electronic device detects a user's unlocking operation (e.g., entering a password or fingerprint), the electronic device can switch back from the second display state to the first display state, i.e., the desktop state.

[0118] In some alternative implementations, when the first display state is the desktop state, if the electronic device detects a user's screen-locking operation (e.g., pressing the power button), the electronic device can switch from the desktop state to the second display state, i.e., the locked screen state. Then, if the electronic device detects a user's screen-off operation (e.g., pressing the power button), the electronic device can switch from the locked screen state to the third display state, i.e., the screen-off state. Next, if the electronic device detects a user's wake-up operation (e.g., pressing the power button or double-tapping the screen), the electronic device can switch from the third display state back to the second display state, i.e., the locked screen state. Finally, if the electronic device detects a user's unlock operation (e.g., entering a password or fingerprint), the electronic device can switch from the second display state back to the first display state, i.e., the desktop state.

[0119] In some alternative implementations, when the first display state is the first desktop state, if the electronic device detects a user's interface switching operation (e.g., long-press and swipe right on the screen), the electronic device can switch from the first desktop state to the second display state, i.e., the second desktop state. Subsequently, if the electronic device detects a user's interface restoration operation (e.g., long-press and swipe left on the screen), the electronic device can switch back from the second desktop state to the first display state, i.e., the first desktop state. The first desktop state and the second desktop state can be different desktops; a desktop can include a central desktop, the first page of a desktop, the second page of a desktop, etc., and this application embodiment does not specifically limit the scope.

[0120] 503: Corresponding to the user scenario in which the electronic device is located, a first set of candidate scenarios is also formed, and a second wallpaper in the first set of candidate wallpapers is displayed, wherein the second wallpaper is different from the first wallpaper.

[0121] In some alternative implementations, the electronic device can determine the user scenario in which the electronic device is located based on scenario factors. For specific determination methods, please refer to 501. To avoid repetition, it will not be elaborated here.

[0122] It is understood that the second wallpaper can be a wallpaper representing the first scene from the first set of candidate wallpapers, and the displayed content of the second wallpaper is related to the scene factors of the first user scene. Alternatively, the second wallpaper can be a wallpaper representing the second user scene from the first set of candidate wallpapers, and the displayed content of the second wallpaper can be related to the scene factors of the second user scene.

[0123] It is understandable that the method for determining the second user scenario can refer to the method for determining the first user scenario in 501. To avoid repetition, it will not be repeated here.

[0124] 504: The second set of candidate scenes is formed corresponding to the user scenario in which the electronic device is located. The third wallpaper in the second set of candidate wallpapers is displayed. The third wallpaper, the second wallpaper and the first wallpaper are different wallpapers.

[0125] In some alternative implementations, the electronic device can determine the user scenario in which the electronic device is located based on scenario factors. For specific determination methods, please refer to 501. To avoid repetition, it will not be elaborated here.

[0126] It can be understood that the second set of candidate scenes can correspond to the second set of candidate wallpapers, and the second set of candidate wallpapers can include multiple wallpapers such as the third wallpaper. The third wallpaper can be the wallpaper for the first user scene within the second set of candidate wallpapers, and the display content of the third wallpaper can be related to the scene factors of the first user scene. Alternatively, the third wallpaper can be the wallpaper for the third user scene within the second set of candidate wallpapers, and the display content of the third wallpaper can be related to the scene factors of the third user scene.

[0127] In this embodiment of the application, by performing real-time analysis of the scene in which the electronic device is located, and displaying different wallpapers for different scenes, it can be ensured that the wallpaper displayed by the electronic device can be automatically adjusted, thereby providing users with a diverse wallpaper display experience.

[0128] As mentioned above, the wallpaper display method described in this application is applicable to scenarios where an electronic device displays an unlock wallpaper in an unlocked state, and also to scenarios where an electronic device displays a lock screen wallpaper in a locked state. For ease of explanation, the following uses an electronic device displaying video as a dynamic wallpaper as an example to introduce the wallpaper display method described in this application.

[0129] like Figure 6A The diagram illustrates another method for displaying wallpapers. This method can be executed by an electronic device, such as the aforementioned mobile phone 100. Specifically, this wallpaper display method may include:

[0130] 601: Screen on.

[0131] In some implementations, electronic devices can detect user actions. For example, when an electronic device is locked, if it detects that the user has pressed the power button or double-clicked the device, it can detect that the user has turned on the screen, which is the wake-up operation mentioned above.

[0132] 602: Obtaining user scenarios.

[0133] It is understandable that after an electronic device detects a user's screen-on operation, it can obtain real-time user status information. This user status information can include at least one of the following: time related to the user's context, the location of the electronic device, the user's emotions, and the user's behavior. Furthermore, the electronic device can determine the current user context based on the correlation between the user status information and the user context, as well as the obtained real-time user status information.

[0134] In some methods of obtaining user status information, electronic devices can obtain user status information based on application data from various applications within the device. For example, an electronic device can obtain dates such as birthdays and anniversaries related to the user's scenario based on information recorded in a memo app; it can obtain dates such as Christmas based on information recorded in a calendar app; it can obtain user behavior related to listening to music based on the playback status of a music app; it can obtain user behavior related to exercising based on the usage status of a fitness app; and it can obtain the location of the electronic device, such as sunny, rainy, foggy, or snowy weather, based on information recorded in a weather app.

[0135] In other ways of obtaining user status information, electronic devices can also obtain user status information related to the user's scenario, such as time, location of the electronic device, user's emotions, and user behavior, based on the text posted by the user in social applications or the chat content in communication applications.

[0136] It is understandable that the user scenario in which an electronic device is located can include multiple user scenarios. For example, if the scenario factors acquired by the electronic device include birthday, Christmas, and listening to music, then the electronic device can determine that the user scenario in which the electronic device is located includes birthday scenario, Christmas scenario, and listening to music scenario.

[0137] 603: Intelligent Scene Analysis and Video Recommendation.

[0138] It is understandable that after determining the user scenario in which the electronic device is located, the electronic device can determine the recommended videos based on the videos corresponding to the user scenario in which the electronic device is located, and obtain video recommendation results.

[0139] 604: Video loading and playback.

[0140] It's understandable that once the recommended videos are determined, they can be used as wallpapers.

[0141] 605: End.

[0142] It is understandable that if the screen of an electronic device is turned off by a user, or if the electronic device is locked for a preset duration, the electronic device can control the device to stop playing video.

[0143] In this embodiment of the application, by performing real-time analysis of the scene in which the electronic device is located, and displaying different wallpapers for different scenes, it can be ensured that the wallpaper displayed by the electronic device can be automatically adjusted, thereby providing users with a diverse wallpaper display experience.

[0144] Understandable. Figure 6A The wallpaper display method mentioned can be applied to a display system. In some alternative implementations, the display system may include a dynamic wallpaper module, a state analysis module, a state acquisition module, and a state source.

[0145] The live wallpaper module, status analysis module, and status acquisition module can be located in the application layer of the electronic device software system. The status source can be located in either the application layer or the framework layer of the electronic device software system.

[0146] The following section, in conjunction with the display system, discusses... Figure 6A The methods for displaying the wallpapers mentioned will be explained in detail. For example... Figure 6B The diagram illustrates the interactive flow of a wallpaper display method based on a display system. The specific flow is as follows:

[0147] 606: The live wallpaper module sends a video retrieval request to the status analysis module.

[0148] In some alternative implementations, when a user's screen-on operation on an electronic device is detected, the live wallpaper module can send a video retrieval request to the status analysis module based on the getVideo() interface.

[0149] 607: The status analysis module sends an information retrieval request to the status acquisition module.

[0150] In some alternative implementations, the status analysis module can respond to video acquisition requests and send a retrieval information request to the status acquisition module via the getScenes() interface. This retrieval information request is used to request user status information.

[0151] 608: The status acquisition module sends a request to the status source to retrieve information.

[0152] In some alternative implementations, the state acquisition module can respond to information retrieval requests and can send such requests to the state source via the getScene() interface. The state source can be an application, such as the memo app, calendar app, music app, weather app, etc. mentioned earlier.

[0153] 609: The status source can return real-time user status information to the status acquisition module.

[0154] It is understandable that the display system can be based on an event-triggered mechanism, whereby the status acquisition module can obtain real-time user status information when the status source meets the event-triggered mechanism. The specific details of the event-triggered mechanism will be described in detail below.

[0155] 610: The status acquisition module returns real-time user status information to the status analysis module.

[0156] In some specific implementations, the status acquisition module can aggregate the real-time user status information returned by all status sources to obtain a real-time user status information set, and then feed the real-time user status information set back to the status analysis module.

[0157] 611: The status analysis module performs status analysis and video recommendation.

[0158] In some specific implementations, the state analysis module can perform intelligent analysis based on real-time user state information sets to determine the user scenario in which the electronic device is located. Then, the electronic device can determine recommended videos based on the videos corresponding to its user scenario, thus obtaining video recommendation results. The process of intelligently analyzing real-time user state information sets to determine the user scenario in which the electronic device is located will be described in detail below.

[0159] 612: The status analysis module returns the video recommendation results to the live wallpaper module.

[0160] 613: The live wallpaper module loads and plays videos.

[0161] The status acquisition module in the display system mentioned above will be described in detail below.

[0162] It's understandable that the status acquisition module can adopt an event-layer design approach. Here, the event layer refers to the logical hierarchy within a software system that generates, transmits, and processes events. An event can be a specific event that occurs within the software system, such as weather events, music playback status changes, motion changes, or work / rest status changes.

[0163] The event layer can include event triggers, event managers, and event listeners. An event trigger can be an object that generates an event, and an event listener can be an object that processes the event. The event manager is responsible for registering, deregistering, and triggering events. When an event trigger generates an event, the event manager distributes the event to all event listeners that have subscribed to it, allowing them to process the event. For example, in this embodiment, the event trigger could be a music application, the event could be a music listening event, and the event listener could be a live wallpaper module.

[0164] In some specific implementations, different events can be abstracted into a unified abstract class. For example... Figure 7 As shown, weather events are abstracted into a weather event implementation class (Class WeaterEventImpl), music playback status change events are abstracted into a music event implementation class (Class MusicEventImpl), location events are abstracted into a location event implementation class (Class LocationEventImpl), and motion change events are abstracted into a motion event implementation class (Class MotionEventImpl), etc. Furthermore, a unified business interface "<" can be set for each event implementation class. <interface>>Event, which defines the methods that the event implementation class using this business interface must implement.

[0165] This improves code reusability, reduces the coupling between event implementation classes and business logic, and facilitates the maintenance of existing capabilities of electronic devices as well as the expansion of new capabilities.

[0166] Furthermore, different event data can be abstracted into a unified abstract data class. Continuing... Figure 7 As shown, weather data is abstracted into a WeatherInfo class, music data into a MusicInfo class, geographic location data into a LocationInfo class, and motion data into a MotionInfo class. Furthermore, a unified data interface, "Class BaseInfo," can be set for each abstract data class to define the methods that the abstract data class using this interface must implement.

[0167] In this way, the event manager provides the ability to register and query events, exposing only the abstract data interface and not the specific implementation details of the event listener, which can improve the security of event listeners.

[0168] In this embodiment of the application, by using an event manager to centrally manage events, the event trigger and the event listener can be decoupled. The event trigger does not need to know which event listeners are listening to the events, which makes it easier to maintain the existing capabilities of the status acquisition module and expand the new capabilities of the status acquisition module.

[0169] Furthermore, by centrally managing the registration, deregistration, and processing of all events using an event manager, the efficiency and consistency of event management can be improved. Batch event distribution using an event manager can enhance the processing efficiency of electronic devices. In addition, developers can easily add, modify, or delete event handling logic; the code within each event is independent and will not affect the code within other events.

[0170] The following section compares the existing event listening methods and provides a detailed introduction to the event layer design philosophy adopted by the state acquisition module.

[0171] In some existing event listening methods, event listeners can subscribe to events through a subscription mechanism. For example, each event listener can subscribe to different events individually. Assuming there are n event listeners and m events, this will result in n×m event listeners. Specifically... Figure 8 As shown, event listener A can subscribe to events generated by event trigger a, and event listener B can also subscribe to events generated by both event trigger a and event trigger b. This leads to an increase in the system resource overhead of the electronic device.

[0172] Therefore, an event manager can be set up in the status acquisition module, allowing event listeners to register the events they wish to subscribe to. When an event trigger generates an event, the event manager can distribute the event to the event listeners based on the registration status. Assuming there are n event listeners and m events, n+m event listenings will occur. This reduces the system resource overhead of electronic devices.

[0173] Combination Figure 8 and Figure 9 As shown, event listener A can register with the event manager to subscribe to events generated by event trigger a and event trigger b, and event listener B can register with the event manager to subscribe to events generated by event trigger a and event trigger b. Thus, when event trigger a generates an event, the event can be distributed to both event listener A and event listener B.

[0174] In some specific implementations, subscribed events may include work / rest status, weather, birthday, exercise, music / videos, cards, travel dates, battery management, etc., and this application embodiment does not impose specific limitations. Among them, weather events may include sunny, cloudy, rainy, snowy, foggy, windy, sunrise, sunset, etc.; exercise events may include outdoor running, indoor running, walking, cycling, etc.; card events may include pre-ride, ride-hailing, subway, express delivery, food delivery, movie, flight, train, etc.

[0175] The status acquisition module will be further introduced below in conjunction with the software system of the electronic device.

[0176] like Figure 10 The diagram illustrates the architecture of a software system for an electronic device. This software system may include a business layer, an abstract event layer, and an event layer.

[0177] The business layer can include multiple event listeners: Wallpaper Service A, Wallpaper Service B, and Wallpaper Service C. The abstract event layer can include an event manager, which is used to register, deregister, and process events 1, 2, and 3. The event layer can include multiple event source caches. When an event occurs, the specific event trigger can be located by querying the event source cache.

[0178] In some specific implementations, event 1 can be a weather event, event 2 can be a music playback status change event, and event 3 can be a work / rest status change event.

[0179] Furthermore, the software system of electronic devices can employ a multi-level caching mechanism, where event listeners, event managers, and event source caches all store event backups. For example, each event listener has a local cache to store event backups for events 1, 2, and 3. The event manager can store event backups for events 1, 2, and 3, and each event source cache can store event backups for events 1, 2, and 3.

[0180] In some embodiments, the event backups in the local cache corresponding to the event listener and the event backups stored in the event source cache are timestamped to ensure the validity of the events.

[0181] In this way, the query operation can be completed in advance in the query chain of first local cache, then event manager, and finally event source cache, without directly accessing the event source cache. This can reduce system resource overhead, improve query speed, and optimize the performance of electronic devices.

[0182] It's understandable that different types of events have different characteristics, such as whether the event supports change callbacks, whether it supports active queries, whether the event query latency meets requirements, and whether the event query is a blocking query, etc. Therefore, event listeners can use different query methods to query different types of events. For example, active queries, immediate queries, passive queries, periodic queries, etc.

[0183] The following section uses music events as an example to introduce various search methods.

[0184] like Figure 11A The diagram illustrates an interactive approach to subscribing to music events. Figure 11A As shown, methods for subscribing to music events include:

[0185] 1101: The event listener sends a request to the event manager to create an event management object.

[0186] It is understandable that event listeners can register by sending a request to the event manager to create an event management object.

[0187] 1102: The event manager returns the event management object to the event listener.

[0188] 1103: The event listener sends a request to the event manager to register a music event.

[0189] Understandably, event listeners can subscribe to music events by sending a request to the event manager to register the music event.

[0190] 1104: The event manager sends a request to the music event implementation class to create an object of the music event implementation class.

[0191] It is understandable that an object of this music event implementation class can be used to register music events with the underlying system.

[0192] 1105: The music event implementation class sends a request to the media session manager to register listeners.

[0193] 1106: The media session manager returns a successful registration to the music event implementation class.

[0194] 1107: The music event implementation class returns a successful registration to the event manager.

[0195] 1108: The event manager sends a request to the music event implementation class to register a listener.

[0196] 1109: The music event implementation class returns a successful registration to the event manager.

[0197] 1110: The event manager returns a successful registration message to the event listener.

[0198] like Figure 11B The diagram illustrates an interactive approach for querying music events based on an active query method.

[0199] Understandably, for events that support active querying, event listeners can initiate queries independently, but do not immediately provide results. While this query method consumes more system resources, it ensures data real-time performance.

[0200] like Figure 11B As shown, methods for querying music events based on active querying include:

[0201] 1111: The event listener sends an active query request to the event manager.

[0202] 1112: The event manager calls the query interface for the corresponding event.

[0203] In some alternative implementations, the event manager can call the music event query interface to send an active query request to the actual music implementation class.

[0204] 1113: The event manager sends an active query request to the music event implementation class.

[0205] 1114: The music event implementation class sends a request to the media session manager to actively query the current music playback status.

[0206] In some alternative implementations, the music event implementation class can respond to an active query request by sending a request to the media session manager to query the current music playback status.

[0207] 1115: The media session manager returns the current music playback status to the music event implementation class.

[0208] 1116: The music event implementation class updates the cache information.

[0209] In some optional implementations, when the current music playback status is "playing", the music event implementation class can update the cached information in the event source cache, for example, the music application that is currently playing the music.

[0210] 1117: The music event implementation class returns a list of media playback statuses to the event manager.

[0211] 1118: The event manager returns events to the event listeners.

[0212] It is understandable that when the music is currently playing, the event manager can return music events to the event listeners.

[0213] 1119: Event listeners update cache information.

[0214] In some alternative implementations, the event listener can receive music events and update the cached information in the local cache.

[0215] like Figure 11C The diagram illustrates an interactive approach based on an immediate query for music events.

[0216] It's understandable that for events that support immediate querying, a multi-level caching mechanism can be used. The event listener can first check if the internal cache meets the requirements, i.e., whether it stores the music event. If the internal cache meets the requirements, it returns directly; otherwise, it queries the event level by level, from the event listener to the media session manager.

[0217] like Figure 11C As shown, methods for querying music events based on the immediate query approach include:

[0218] 1120: The event listener checks whether the cached information meets the requirements; if it does, it returns directly.

[0219] 1121: The event listener sends an immediate query request to the event manager.

[0220] 1122: The event manager calls the query interface for the corresponding event.

[0221] 1123: The event manager sends an immediate query request to the music event implementation class.

[0222] 1124: The music event implementation class checks whether the cached information meets the requirements. If it does, it returns directly.

[0223] 1125: The music event implementation class returns a list of media playback statuses to the event manager.

[0224] 1126: The music event implementation class sends a request to the media session manager to actively query the current music playback status.

[0225] 1127: The media session manager returns the current music playback status to the music event implementation class.

[0226] 1128: The music event implementation class updates the cache information.

[0227] 1129: The music event implementation class returns a list of media playback statuses to the event manager.

[0228] 1130: The event manager returns events to the event listeners.

[0229] 1131: Event listeners update cache information.

[0230] like Figure 11D The diagram illustrates an interactive schematic of a method for querying music events based on a passive query approach.

[0231] For events that support passive querying, the event listener pattern is used. The music event implementation class sends a request to the media session manager to register music event listeners. When the media playback status changes, the event manager automatically updates the cache and distributes the update information to all event listeners that have subscribed to the event, achieving synchronous cache updates.

[0232] like Figure 11D As shown, methods for querying music events based on passive querying include:

[0233] 1132: The media session manager detected a change in media playback status.

[0234] 1133: The media session manager sends a change message carrying data to the music event implementation class.

[0235] 1134: The music event implementation class updates the cache information.

[0236] 1135: The music event implementation class returns a list of media playback statuses to the event manager.

[0237] 1136: The event manager returns events to the event listeners.

[0238] 1137: Event listeners update cache information.

[0239] like Figure 11E The diagram shows an interactive illustration of a method for querying music events based on a periodic query approach.

[0240] For events that support periodic querying, an internally registered timer is provided to periodically query the media session manager for status, proactively update the cache, and feed the latest information back to the event manager, which then distributes it to all event listeners subscribed to the event to ensure the timeliness and accuracy of the information.

[0241] 1138: The music event implementation class sends a request to the timer to register the timer.

[0242] 1139: The timer returns the timer period to the music event implementation class.

[0243] 1140: The music event implementation class sends a request to the media session manager to actively query the current music playback status.

[0244] 1141: The music event implementation class returns the current music playback status.

[0245] 1142: The music event implementation class updates the cache information.

[0246] 1143: The music event implementation class returns a list of media playback statuses to the event manager.

[0247] 1144: The event manager returns events to the event listeners.

[0248] 1145: The event listener updates the cache information.

[0249] The following describes how to access the event manager for each event. For example... Figure 12 The diagram illustrates a process flow for multiple events to access an event manager.

[0250] In some alternative implementations, the event source can report the event to the event manager after it occurs. For example, the event source can report events such as birthdays, work / rest status, cards, travel dates, weather, exercise, music / videos, and battery levels to the event manager using report().

[0251] In some optional implementations, event listeners can subscribe to events such as weather events, music playback status change events, work / rest status change events, card events, and travel date events by creating listeners.

[0252] The following section provides a detailed introduction to the status analysis module in the display system mentioned above.

[0253] It is understandable that in some optional implementation methods, user scenarios may include main user scenarios such as personal specific scenarios, holiday operation scenarios, personal status scenarios, natural environment scenarios, and general default scenarios, as shown in Table 1. These are referred to as main scenarios (MainScene) below.

[0254] Table 1

[0255] MainScene Value illustrate PERSONAL_SCENE 0x0000 Personal specific scenarios CULTURAL_SCENE 0x1000 Holiday operation scenarios LIFESTYLE_SCENE 0x2000 Personal Status Scenarios ENVIRONMENT_SCENE 0x3000 Natural environment scene DEFAULT_SCENE 0x4000 General default scenario

[0256] As shown in Table 1, PERSONAL_SCENE represents a personal-specific scenario with a value of 0x0000. CULTURAL_SCENE represents a holiday operational scenario with a value of 0x1000. LIFESTYLE_SCENE represents a personal status scenario with a value of 0x2000. ENVIRONMENT_SCENE represents a natural environment scenario with a value of 0x3000. DEFAULT_SCENE represents a general default scenario with a value of 0x4000.

[0257] It's understandable that different main scenarios can have different display priorities. For example, in some optional implementations, the display priority of a personal-specific scenario can be higher than that of a holiday operation scenario, which in turn can be higher than that of a personal status scenario, which can be higher than that of a natural environment scenario, which can be higher than that of a general default scenario. In other words, the display priority of these main scenarios can be: Personal-specific scenario > Holiday operation scenario > Personal status scenario > Natural environment scenario > General default scenario.

[0258] In some optional implementations, each main scenario may include at least one sub-user scenario, hereinafter referred to as a sub-scenario. For example, a personal-specific scenario may include sub-scenarios such as birthdays and anniversaries; a holiday operation scenario may include sub-scenarios such as holidays (e.g., Christmas), operational activities, and the four seasons; a personal status scenario may include sub-scenarios such as life services, music, exercise, work, and rest; a natural environment scenario may include sub-scenarios such as weather, sunrise, sunset, sunny days, rain, snow, wind, and smog; and a general default scenario may include general sub-scenarios.

[0259] It is understandable that, due to the different display priorities of different main scenarios, the display priorities of the sub-user scenarios included in different main scenarios also differ. For example, the display priority of sub-scenarios such as birthdays and anniversaries is higher than that of sub-scenarios such as holidays (e.g., Christmas), promotional activities, and the four seasons. The display priority of sub-scenarios such as holidays (e.g., Christmas), promotional activities, and the four seasons is higher than that of sub-scenarios such as life services, music, sports, work, and rest. The display priority of sub-scenarios such as life services, music, sports, work, and rest is higher than that of sub-scenarios such as weather, sunrise, sunset, sunny, rainy, snowy, windy, and smog. The display priority of sub-scenarios such as weather, sunrise, sunset, sunny, rainy, snowy, windy, and smog is higher than that of general sub-scenarios.

[0260] It is understandable that in some other alternative implementation methods, user scenarios may include multiple sub-scenarios such as birthday, holiday, music, exercise, rest, work, sunrise, sunset, sunny day, rain, snow, wind, smog, and default, as shown in Table 3.

[0261] Table 2

[0262] SubScene Value illustrate BIRTHDAY 0x0001 Birthday FESTIVAL 0x1001 festival MUSIC 0x2001 music SPORT 0x2002 sports RESTING 0x2003 rest WORK 0x2004 Work SUNRISE 0x3001 sunrise SUNSET 0x3002 Sunset SUNNY 0x3003 sunny RAIN 0x3004 rain SNOW 0x3005 snow WIND 0x3006 Wind HAZE 0x3007 smog DEFAULT 0x4001 default

[0263] As shown in Table 2, BIRTHDAY represents a birthday scenario with a value of 0x0001. FESTIVAL represents a holiday operation scenario with a value of 0x1001. MUSIC represents a music scenario with a value of 0x2001. SPORT represents a sports scenario with a value of 0x2002. RESTING represents a rest scenario with a value of 0x2003. WORK represents a work scenario with a value of 0x2004, and so on. Further details are omitted in this embodiment.

[0264] It is understandable that in some optional implementations, the display priority of the same sub-scene can be the same. For example, the display priority of the music scene, the sports scene, the rest scene, and the work scene can be the same. That is, the display priority of the above multiple sub-scenes can be: birthday > holiday > music = sports = rest = work > sunrise = sunset = sunny = rainy = snowy = windy = smog > default.

[0265] In other alternative implementations, the display priority of the same sub-scene can also differ. For example, the display priority of the music scene can be higher than that of the sports scene, which can be higher than the rest scene, which can be higher than the work scene. That is, the display priority of the above sub-scenes can be: Birthday > Holiday > Music > Sports > Rest > Work > Sunrise > Sunset > Sunny > Rainy > Snowy > Windy > Smog > Default.

[0266] It is understandable that in some optional implementations, each sub-scene may include multiple videos. When the state analysis module determines that the user's state information matches a specific sub-scene within a main scene, the state analysis module can recommend any one of the videos within that sub-scene to the live wallpaper module. For example, when the user's state information matches a birthday scene within a specific personal context, the state analysis module can recommend any one of Birthday Video 1, Birthday Video 2, or Birthday Video 3 to the live wallpaper module.

[0267] In some alternative implementations, when the state analysis module determines that the user's state information matches multiple sub-scenes under a main scene, the state analysis module can recommend any one of the multiple sub-scenes to the live wallpaper module.

[0268] In some alternative implementations, when the state analysis module determines that the user's state information matches multiple sub-scenes under a main scene, the state analysis module can first determine the playback probability corresponding to each sub-scene, and then recommend a video to the live wallpaper module based on the playback probability corresponding to each sub-scene.

[0269] It is understandable that electronic devices can pre-store the one-to-one correspondence between the number of scene matches and the playback probability, as shown in Table 3.

[0270] Table 3

[0271]

[0272] Specifically, when the number of scene matches is 5, the playback probability for each scene can be 35%-30%-20%-10%-5%; when the number of scene matches is 4, the playback probability for each scene can be 50%-25%-15%-10%; when the number of scene matches is 3, the playback probability for each scene can be 50%-30%-20%; and when the number of scene matches is 2, the playback probability for each scene can be 70%-30%.

[0273] In some optional implementations, the one-to-one correspondence between the number of scene matches and the playback probability shown in Table 3 can represent the one-to-one correspondence between the number of main scene matches and the playback probability. Therefore, when the state analysis module determines that the user's state information matches multiple sub-scenes under multiple main scenes, the state analysis module can first determine the playback probability corresponding to each main scene based on the number of scene matches of the user's state information and the display priority of each main scene. The higher the display priority of the main scene, the greater the playback probability corresponding to that main scene. Then, the playback probability corresponding to each sub-scene is determined based on the playback probability of the video within each main scene.

[0274] For example, the status analysis module identifies three sub-scenarios matching the user's status information: a birthday within a specific personal context, Christmas within a holiday-related context, and music within a personal status context. Specifically, if Christmas is the user's birthday and they are listening to music, the status analysis module can determine that the playback probability for the birthday scenario is 50%, the Christmas scenario is 30%, and the music scenario is 20%.

[0275] It is understandable that when user status information matches multiple sub-scenes under the same main scene, the playback probability corresponding to each sub-scene can be the same. For example, if a user's status information matches both the music scene and the sports scene under the personal status scene, and the playback probability of the personal status scene is N, then the playback probability corresponding to both the music scene and the sports scene is N / 2.

[0276] For example, the state analysis module identifies four sub-scenarios matching the user's state information: birthday (a specific personal scenario), music and rest (a personal state scenario), and rain (a natural environment scenario). Specifically, if the user's birthday falls on a rainy day and they are listening to music, the state analysis module can determine that the playback probability for the birthday scenario is 50%, the music scenario is 15%, the rest scenario is 15%, and the rain scenario is 20%.

[0277] It is understood that when a user's status information matches multiple sub-scenes under the same main scene, the playback probability corresponding to each sub-scene may be different, and this application embodiment does not limit this. For example, when matching four sub-scenes based on the user status information listed above, the status analysis module can determine that the playback probability corresponding to the birthday scene is 50%, the playback probability corresponding to the music scene is 20%, the playback probability corresponding to the rest scene is 10%, and the playback probability corresponding to the rain scene is 20%.

[0278] In other alternative implementations, the one-to-one correspondence between the number of scene matches and the playback probability shown in Table 3 can also represent the one-to-one correspondence between the number of sub-scene matches and the playback probability. Therefore, when the state analysis module determines that user state information matches multiple sub-scenes under multiple main scenes, the state analysis module can determine the playback probability corresponding to each sub-scene based on the number of scene matches of the user state information and the display priority of the main scene to which each sub-scene belongs. The higher the display priority of the main scene to which the sub-scene belongs, the greater the playback probability corresponding to the sub-scene. Then, the playback probability corresponding to each sub-scene is determined based on the playback probability of the video within each main scene.

[0279] For example, the state analysis module identifies four sub-scenarios matching the user's state information: a personal-specific birthday scenario, a holiday-related scenario like Christmas, a personal-state scenario involving music, and a natural-environment scenario like rain. That is, if a user's birthday falls on Christmas Day, it's raining outside, and the user is listening to music, the state analysis module can determine that the playback probability for the birthday scenario is 50%, the Christmas scenario is 25%, the music scenario is 15%, and the rain scenario is 10%.

[0280] It is understandable that the playback probability of each sub-scene under the main scene can also be the same.

[0281] In some specific implementations, after the state analysis module determines the playback probability of each sub-scene, the state analysis module can recommend any video in the sub-scene with the highest playback probability to the dynamic wallpaper module.

[0282] In some other specific implementations, the state analysis module divides the total weight of 100 into multiple intervals according to the playback probability of each sub-scene, and randomly generates a number between 1 and 100. Depending on which interval the number falls into, any video in the corresponding sub-scene is played.

[0283] For example, if the state analysis module determines that the playback probability for the birthday scene is 50%, the Christmas scene is 25%, the music scene is 15%, and the rain scene is 10%, then the playback probability interval for the birthday scene could be [1, 50], the Christmas scene [51, 75], the music scene [76, 90], and the rain scene [91, 100]. If the randomly generated number is 52, the state analysis module can recommend any video from the Christmas scene to the live wallpaper module. If the randomly generated number is 28, the state analysis module can recommend any video from the birthday scene to the live wallpaper module.

[0284] To avoid repetitive playback, in some optional implementations, the videos recommended by the state analysis module to the live wallpaper module follow a "no replay after N times" strategy. Simply put, if a video has already been played, it will not be played again for the next N times.

[0285] The strategy of playing N times without repetition is described below.

[0286] In some alternative implementations, the state analysis module can use a mapping hash table to record the mapping relationships between the main scene, sub-scenes, and video.

[0287] In some optional implementations, the mapping hash table can include an allSceneInfoMap hash table, used to record the mapping relationships between all sub-scenes and videos. This allSceneInfoMap hash table can include a list of sub-scenes and a list of videos.

[0288] like Figure 13A As shown, the sub-scene list can record sub-scenes such as birthday scenes, holiday scenes, music scenes, sunny scenes, and general scenes. The video list can record videos within sub-scenes, for example, videos in the birthday scene: birthday 1, birthday 2; videos in the holiday scene: holiday 1, holiday 2; videos in the music scene: music 1, music 2, etc.; videos in the sunny scene: sunny 1, sunny 2; videos in the general scene: general 1, general 2. This application embodiment does not make specific limitations.

[0289] The mapping hash table can also include a playbackSceneMap hash table, which records the mapping relationship between the main scene and sub-scenes matched by the user's state information. This playbackSceneMap hash table can include a list of main scenes and a list of sub-scenes.

[0290] like Figure 13B As shown, suppose that a user's status information at a certain moment matches a birthday scene under a holiday event scenario, a music scene under a personal status scenario, a sunny scene under a natural environment scenario, and a general scene under a general default scenario. Thus, the main scene list can record holiday event scenarios, personal status scenarios, natural environment scenarios, and general default scenarios. The sub-scene list can record holiday scenes (FESTIVAL) under holiday event scenarios, music scenes (MUSIC) under personal status scenarios, sunny scenes (SUNNY) under natural environment scenarios, and general scenes (NORMAL) under general default scenarios.

[0291] The mapping hash table can also include a playbackVideoMap hash table, which records the mapping relationship between the sub-scenes and videos matched by the user's state information. The playbackVideoMap hash table can include a list of sub-scenes and a list of videos.

[0292] like Figure 13C As shown, assuming that the sub-scenes matched by the user's status information at a certain moment include holiday scenes, music scenes, sunny scenes, and general scenes, then the sub-scene list can record holiday scenes, music scenes, sunny scenes, and general scenes. The video list can record videos within each sub-scene, for example, videos within the holiday scene: Holiday 1, Holiday 2; videos within the music scene: Music 1, Music 2; videos within the sunny scene: Sunny 1, Sunny 2; videos within the general scene: General 1, General 2.

[0293] To avoid duplicate recordings and improve recording efficiency, the state analysis module employs linear space and time complexity structures, achieving O(n) space complexity and O(n) time complexity. For example, in searching for a video, the time complexity of searching for the key is O(1), and the time complexity of searching for the value is O(n). Therefore, the overall space complexity is O(n). Specifically, the extra space required by the algorithm in the state analysis module is linearly related to the size of the input data; that is, the larger the input data size, the linearly larger the extra space required by the algorithm. The running time of the algorithm in the state analysis module can also be linearly related to the size of the input data; that is, the larger the input data size, the linearly larger the running time of the algorithm.

[0294] In some specific implementations, the state analysis module can use a combination of queues and hash tables to record videos that match the user's state information (i.e., videos that fit the current scene). Specifically, the state analysis module can use a played queue to record played videos and a mapping hash table (i.e., a mapping relationship to be played) to record the mapping relationship between sub-scenes and videos. The mapping relationship to be played can include a list of sub-scenes and a list of videos.

[0295] In addition, the status analysis module can use a list of played scenes to record played sub-scenes, or to record both played sub-scenes and played videos. Furthermore, the status analysis module can use a list of priority playback scenes to record newly added sub-scenes, or to record both newly added sub-scenes and newly added videos.

[0296] like Figure 14 As shown, it is assumed that the sub-scenes matched by the user state information at time t include festival scene, music scene, sunny day scene and general scene.

[0297] Specifically, the videos in the festival scene include Festival 1, Festival 2, and Festival 3. The videos in the music scene include Music 1, Music 2, and Music 3. The videos in the sunny day scene include Sunny Day 1, Sunny Day 2, and Sunny Day 3. The videos in the general scene include General 1, General 2, General 3, and General 4.

[0298] Furthermore, assuming that at times t-i1, t-i2, t-i3, t-i4, and t-i5, the state analysis module can recommend videos to the dynamic wallpaper module as Music 3, Sunny Day 3, Holiday 3, General 3, and General 4, respectively. Therefore, for the videos satisfying the current scene at time t, the played queue can record Music 3, Sunny Day 3, Holiday 3, General 3, and General 4. The scene list can record Holiday scene, Music scene, Sunny Day scene, and General scene. The video list can record unplayed videos: videos within the Holiday scene: Holiday 1, Holiday 2; videos within the Music scene: Music 1, Music 2; videos within the Sunny Day scene: Sunny Day 1, Sunny Day 2; videos within the General scene: General 1, General 2.

[0299] Understandably, the status analysis module can update the video that matches the current scenario based on real-time user status information. When adding a sub-scene, the status analysis module needs to add the new scene to the mapping relationship between the main scene and sub-scene to be played, for example, adding a main scene and / or a sub-scene. When removing a sub-scene, the status analysis module needs to remove the discarded main scene and discarded sub-scene from the mapping relationship between the main scene and sub-scene to be played, and remove the discarded sub-scene and the video within the discarded sub-scene from the matched scene-video mapping relationship.

[0300] For example, such as Figure 15 As shown, the user status information at time t+i6 matches a holiday scene, where the videos include Holiday 1 and Holiday 2. The user status information at time t+i6 also matches a sunny day scene, where the videos include Sunny Day 1 and Sunny Day 2. The user status information at time t+i6 also matches a general scene, where the videos include General 1 and General 2.

[0301] Since the sub-scene matched by the user state information at time t+i6 has changed compared to the sub-scene matched by the user state information at time t, the state analysis module can update the video that satisfies the current scene at time t to obtain the video that satisfies the current scene at time t+i6.

[0302] For videos that satisfy the current scenario at time t+i6, the played queue can record Sunny Day 3, Holiday 3, General 3, and General 4. The scenario list can record Holiday Scenario, Sunny Scenario, and General Scenario. The video list can record unplayed videos: videos in the Holiday Scenario: Holiday 1 and Holiday 2; videos in the Sunny Scenario: Sunny Day 1 and Sunny Day 2; videos in the General Scenario: General 1 and General 2.

[0303] It is understandable that after updating the videos that meet the current scenario based on real-time user status information, the status analysis module can recommend videos to the live wallpaper module based on the new scenario priority playback strategy.

[0304] The following section describes the specific implementation method of the status analysis module recommending videos to the live wallpaper module.

[0305] To improve user experience, when the status of an electronic device changes, such as when a user wakes up the device, the status analysis module can intelligently prioritize recommending videos related to the new scene based on the current user status information, that is, videos within the new scene are played first.

[0306] like Figure 16 The diagram illustrates a flowchart of a video recommendation method, which can be executed by a state analysis module. Specifically, the video recommendation method includes:

[0307] 1601: Get the latest set of sub-scenes.

[0308] Each time a user wakes up an electronic device, the state analysis module can obtain the latest user state information and determine the latest set of sub-scenes that match the latest user state information.

[0309] 1602: Compare with the previous set of sub-scenes to obtain the set of newly added sub-scenes and the set of eliminated sub-scenes.

[0310] It is understandable that the previous sub-scene set can refer to the set of sub-scenes matched by the user's state information obtained by the state analysis module when the user last woke up the electronic device.

[0311] In some implementations, after determining the latest set of sub-scenes matching the latest user status information, the status analysis module can compare the latest set of sub-scenes with the previous set of sub-scenes. Sub-scenes present in the latest set but not in the previous set are identified as new sub-scenes, thus obtaining a new set of sub-scenes. Furthermore, the status analysis module can identify sub-scenes not present in the latest set but present in the previous set as discarded sub-scenes, thus obtaining a discarded set of sub-scenes.

[0312] 1603: Remove the set of eliminated sub-scenes from the matched scene-video mapping relationship.

[0313] In some implementations, after determining the set of eliminated sub-scenes, the state analysis module can remove the eliminated sub-scenes from the sub-scene list in the matched scene-to-video mapping hash table, and the state analysis module can remove the videos within the eliminated sub-scenes from the video list in the matched scene-to-video mapping hash table.

[0314] 1604: Remove the set of eliminated sub-scenes from the list of played scenes and the list of priority scenes.

[0315] In some implementations, after determining the set of eliminated sub-scenes, the state analysis module can remove sub-scenes from the played scene list that are not present in the latest sub-scene set but existed in the previous sub-scene set. Furthermore, the state analysis module can remove sub-scenes from the priority playback scene list that are not present in the latest sub-scene set but existed in the previous sub-scene set.

[0316] 1605: Add a new set of sub-scenes to the matched scene and video mapping relationship.

[0317] In some implementations, after determining the new sub-scene set, the state analysis module can add sub-scenes that exist in the latest sub-scene set but were not in the previous sub-scene set to the sub-scene list of the matched scene-video mapping hash table.

[0318] In some implementations, after determining the set of new sub-scenes, the state analysis module can add videos from the new sub-scenes to the video list in the matched scene-video mapping hash table.

[0319] It is understood that the execution order of 1602 to 1605 listed above is only one implementation method listed in the embodiments of this application, and does not limit 1602 to 1605 to be executed only in this execution order. That is, the embodiments of this application do not specifically limit the execution order of 1602 to 1605.

[0320] 1606: Update the sub-scenes in the mapping relationship between the main scene and sub-scenes to be played.

[0321] In some implementations, after determining the set of new sub-scenes and the set of eliminated sub-scenes, the state analysis module can add new sub-scenes and remove eliminated sub-scenes from the sub-scene list in the hash table of the mapping relationship between the main scene and the sub-scenes to be played, so as to update the sub-scenes in the mapping relationship between the main scene and the sub-scenes to be played.

[0322] Furthermore, the state analysis module can compare the main scenes to which all sub-scenes in the latest sub-scene set belong with the main scenes to which all sub-scenes in the previous sub-scene set belong. Next, the state analysis module can remove main scenes from the hash table of the mapping relationship between the main scenes and sub-scenes to be played, removing those that do not exist in the latest sub-scene set but are present in the main scenes of the previous sub-scene set, and adding those that exist in the latest sub-scene set but are not present in the main scenes of the previous sub-scene set. This updates the main scenes in the mapping relationship between the main scenes and sub-scenes to be played.

[0323] 1607: Add the newly added scene from the new scene set as the priority playback scene to the priority playback scene list.

[0324] In some implementations, the priority playback scene list records newly added sub-scenes. Therefore, the state analysis module can add newly added scenes from the new scene set to the priority playback scene list.

[0325] 1608: The priority playback scene list is not empty. If so, a video is randomly selected from the newly added videos in the priority playback scene list; otherwise, a video is selected according to the playback probability.

[0326] In some implementations, when the newly added scene set is empty, the priority playback scene list is also empty. If the priority playback scene list is determined to be empty, the state analysis module can execute step 1609 to select a video based on playback probability. When the newly added scene set is not empty, the priority playback scene list is not empty. If the priority playback scene list is determined to be not empty, the state analysis module can execute step 1613 to randomly select a video from the videos within the newly added scenes in the priority playback scene list.

[0327] 1609: No new scenes are added; triggering is based on playback probability.

[0328] It is understandable that if the priority playback scene list records newly added sub-scenes, and it is determined that the priority playback scene list is empty, the status analysis module can select videos according to the playback probability of each sub-scene in the latest sub-scene set.

[0329] 1610: Based on the known main scenes corresponding to the sub-scenes, select a main scene according to the playback probability relationship table.

[0330] In some implementations, the state analysis module can select a main scene from the main scenes to which all sub-scenes belong, based on the playback probability of each sub-scene in the latest set of sub-scenes.

[0331] For example, the state analysis module can select the main scene to which the sub-scene with the highest playback probability belongs as the main scene.

[0332] For example, the state analysis module can generate random numbers and select the main scene to which the sub-scene corresponding to the interval in which the random number falls as the selected main scene.

[0333] 1611: Select a sub-scene from the list of sub-scenes corresponding to the main scene based on the average playback probability.

[0334] In some implementations, the playback probability of each sub-scene under the main scene can be the same. Therefore, after selecting the main scene, a sub-scene can be randomly selected from the sub-scenes under the main scene.

[0335] 1612: Select a video from the video list corresponding to the sub-scene based on the average playback probability.

[0336] In some implementations, the playback probability of multiple videos included in each sub-scene is the same. Therefore, after selecting a sub-scene, a video can be randomly selected from the multiple videos included in that sub-scene to recommend that video to the live wallpaper module.

[0337] 1613: Retrieve the list header, randomly select a video corresponding to the matched scene and video mapping relationship, and return it.

[0338] It is understandable that, if the priority playback scene list records newly added main scenes, and it is determined that the priority playback scene list is not empty, the status analysis module can randomly select a video corresponding to a scene from the matched scene-video mapping relationship to recommend the video to the live wallpaper module.

[0339] In this embodiment of the application, the diversity and rationality of video recommendations can be determined by the principles of allocating main scenes according to display priority, allocating sub-scenes under the same main scene equally, and allocating videos within the same sub-scene equally.

[0340] It is understandable that after the state analysis module detects that the live wallpaper module has finished playing the recommended video, the state analysis module needs to remove the video from the video list of the matched scene and video mapping hash table and add it to the played queue. This can achieve orderly management of videos.

[0341] In some implementations, if the played queue reaches its capacity limit, the video at the head of the queue needs to be added back to the video list of the matched scene-to-video mapping hash table. This ensures the updating and recycling of the video list, enabling the continuous playback of N videos without repeating the same video.

[0342] The following section describes how the hash table mapping the matched scenes and videos is updated when the played queue reaches its capacity limit.

[0343] like Figure 17 The diagram illustrates a flowchart of a method for updating a hash table representing the matched scene-to-video mapping. This method can be executed by the state analysis module. Specifically, the update method includes:

[0344] 1701: Get the currently playing video.

[0345] In some optional implementations, the currently playing video of the live wallpaper module can be music.

[0346] 1702: Remove the corresponding video from the hash table of matched scene-video mapping relationships.

[0347] In some alternative implementations, for Figure 13C The hash table showing the matched scene-to-video mapping relationship shows that if the state analysis module detects that the currently playing video of the live wallpaper module is music 1, then music 1 can be removed from the video list of the matched scene-to-video mapping relationship hash table.

[0348] 1703: Add the currently playing video to the played queue.

[0349] It's understandable that once the status analysis module detects that the live wallpaper module has finished playing music 1, music 1 can be added to the played queue. For example, for Figure 14 The shown video playback queue for the current scenario can be updated by adding music 1 to the end of the playback queue, resulting in the following playback queue: music 3, sunny day 3, holiday 3, general 3, general 4, and music 1.

[0350] 1704: Determine if the played queue is full or if there are no videos in the video list of the hash table that matches the scene and video mapping relationship.

[0351] In some optional implementations, if the played queue is full, or if there is no video in the video list of the matched scene-to-video mapping hash table, the state analysis module can execute step 1705 to add the video at the head of the played queue to the video list of the matched scene-to-video mapping hash table. If the played queue is not full, or if there is a video in the video list of the matched scene-to-video mapping hash table, the process ends.

[0352] 1705: Retrieve the video at the head of the played queue and add it to the video list of the matched scene-video mapping hash table.

[0353] For example, if the updated played queue records the played videos as follows: Music 3, Sunny Day 3, Holiday 3, General 3, General 4, Music 1, then the status analysis module can add Music 3 to the video list of the matched scene-video mapping hash table. Thus, the updated played queue will include: Sunny Day 3, Holiday 3, General 3, General 4, Music 1.

[0354] It is understood that the wallpaper display method provided in this application embodiment can be applied to electronic devices. The hardware structure of the electronic device to which the wallpaper display method provided in this application embodiment is applicable will be described exemplarily below.

[0355] In some specific implementations, the electronic device can be a mobile phone, tablet, laptop, or other device with image display capabilities, as mentioned above.

[0356] like Figure 18 As shown, the electronic device 1800 may include a processor 1810, an external memory interface 1820, an internal memory 1821, a universal serial bus (USB) interface 1830, a charging management module 1840, a power management module 1841, a battery 1842, antenna 1, antenna 2, a mobile communication module 1850, a wireless communication module 1860, an audio module 1870, a speaker 1870A, a receiver 1870B, a microphone 1870C, a headphone jack 1870D, a sensor module 1880, a pressure sensor 1880A, a button 1890, a motor 1891, an indicator 1892, a camera 1893, a display screen 1894, etc.

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

[0358] Processor 1810 may include one or more processing units, such as application processor (AP), modem processor, graphics processing unit (GPU), image signal processor (ISP), controller, video codec, digital signal processor (DSP), baseband processor, and / or neural network processing unit (NPU). These different processing units may be independent devices or integrated into one or more processors.

[0359] In some alternative implementations, the processor 1810 may execute the wallpaper display method mentioned in the embodiments of this application.

[0360] Specifically, the processor 1810 can perform real-time analysis of the scene in which the electronic device is located and display corresponding wallpapers for different scenes. In this way, the wallpaper displayed by the electronic device can be automatically adjusted, thereby providing users with a diverse wallpaper display experience.

[0361] Electronic devices implement display functions through a GPU, a display screen 1894, and an application processor. The GPU is a microprocessor for image processing, connecting the display screen 1894 and the application processor. The GPU performs mathematical and geometric calculations for graphics rendering. The processor 1810 may include one or more GPUs, which execute program instructions to generate or modify display information.

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

[0363] Electronic devices can achieve image display functions through video codecs, GPUs, displays, and application processors.

[0364] Digital signal processors (DSPs) are used to process digital signals. Besides digital image signals, they can also process other digital signals. For example, when an electronic device is selecting a frequency, a DSP can perform a Fourier transform on the frequency energy.

[0365] Video codecs are used to compress or decompress digital video. Electronic devices can support one or more video codecs. This allows the electronic device to play or record video in various encoded formats, such as Moving Picture Experts Group (MPEG) 1, MPEG2, MPEG3, MPEG4, etc.

[0366] The above describes the possible hardware structures of electronic devices. It is understood that the structures illustrated in the embodiments of this application do not constitute a specific limitation on the electronic device. In other embodiments of this application, the electronic device may include more or fewer components than illustrated, or combine certain components, or split certain components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of both.

[0367] The software architecture of the electronic device to which the wallpaper display method provided in the embodiments of this application is applicable will be described by way of example below.

[0368] It is understood that the software system of electronic devices can have a layered architecture, such as event-driven architecture, microkernel architecture, microservice architecture, cloud architecture, etc. This application uses a layered architecture as an example to exemplify the software architecture of an electronic device.

[0369] Figure 19 This is a block diagram of the software system of an electronic device provided in this application.

[0370] A layered architecture can divide a software system into several layers, each with a clear role and function. Layers communicate with each other through software interfaces. In some embodiments, the software system of an electronic device may include an application layer, a framework layer, a native layer, a hardware abstraction layer (HAL), and a kernel layer (Linux Kernel).

[0371] The application layer can include a package of applications (apps). For example... Figure 19 As shown, the application package may include system user interface (SystemUI), live wallpaper, always-on display (Aod), theme, etc.

[0372] The framework layer can provide application programming interfaces (APIs) and programming frameworks for applications in the application layer.

[0373] Continue as Figure 19 As shown, the framework layer may include WallpaperManager, WallpaperManagerService, PowerManager, Screen SaverService Manager, and so on.

[0374] The wallpaper manager allows applications and users to set the wallpaper on their electronic devices. For example, the wallpaper manager can provide an interface to set the wallpaper on an electronic device and allow applications to query the current wallpaper settings. The wallpaper manager can also provide methods to retrieve wallpapers so that applications can access the current wallpaper information when needed.

[0375] The wallpaper management service is a component of the system service layer, responsible for the actual management and operation of wallpapers. It runs as a system process, handling requests from the wallpaper manager and performing corresponding operations. The wallpaper management service is a hidden system service; ordinary applications cannot directly access it.

[0376] The power manager is responsible for managing the power states and power consumption optimization of electronic devices. For example, the power manager allows applications to request electronic devices to enter sleep or wake-up states. The power manager can also provide APIs to control the power policies of electronic devices, such as adjusting the central processing unit (CPU) frequency, screen brightness, etc., to reduce power consumption. The power manager can also manage wake lock functionality to ensure that electronic devices remain awake when needed.

[0377] In Android, the Screen Saver Service Manager is a system service responsible for managing and controlling the device's Dreams feature. This service, also known as "Daydream," allows users to configure and manage the screen saver mode when the device is idle. The Screen Saver Service Manager can start and stop Daydream mode, which displays animations, images, or other content when the device is idle to prevent screen damage from prolonged inactivity. The Screen Saver Service Manager can also manage the display logic and interactivity of Daydream mode; for example, users can exit Daydream mode by touching or using other methods.

[0378] It's understandable that the Android system can also include a vendor layer. This vendor layer could include wallpaper managers, wallpaper service managers, always-on display service managers (AodManagerService), and so on.

[0379] The native layer can include libraries written in C or C++. Native C / C++ libraries are software libraries written in C or C++ and compiled for a specific platform. Generally, native C / C++ libraries are components of an application; they are written and compiled as part of the application and are directly called. These libraries are typically used to handle complex computational tasks, hardware access tasks, and high-performance tasks.

[0380] The Hardware Abstraction Layer (HAL) isolates upper-layer software from hardware through a unified interface. As a result, upper-layer software does not need to know the specific hardware details, but only needs to call the standard interface provided by the HAL to operate the hardware.

[0381] The Android runtime consists of core libraries and a virtual machine. The Android runtime is responsible for scheduling and managing the Android system.

[0382] The core library consists of two parts: one part is the functionalities that need to be called by the Java language, and the other part is the Android core library.

[0383] The application layer and framework layer run in a virtual machine. The virtual machine executes the Java files of the application layer and framework layer as binary files. The virtual machine is used to perform functions such as object lifecycle management, stack management, thread management, security and exception management, and garbage collection.

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

[0385] The Surface Manager is used to manage the display subsystem and provides the blending of 2D and 3D layers for multiple applications.

[0386] The media library supports playback and recording of various common audio and video formats, as well as still image files. It supports multiple audio and video encoding formats, such as MPEG4, H.264, MP3, AAC, AMR, JPG, and PNG.

[0387] The 3D graphics processing library is used to implement 3D graphics drawing, image rendering, compositing, and layer processing.

[0388] A 2D graphics engine is a graphics engine for 2D drawing.

[0389] The kernel layer is the layer between hardware and software. The kernel layer contains at least the display driver, camera driver, audio driver, and sensor driver.

[0390] The wallpaper display method provided in this application embodiment can be applied to dynamic wallpaper applications in the application layer. For example, the dynamic wallpaper application can be delivered as a compiled binary file (apk), and its functionality can be implemented through underlying system capabilities such as the application framework layer, native C / C++ libraries, system layer, hardware abstraction layer, and kernel layer.

[0391] Figure 20 This is a block diagram of another electronic device software system provided in this application.

[0392] like Figure 20 As shown, the software system may include an application layer, a multi-modal input / wallpaper control module, a video rendering and display control, a framework layer, and an engine.

[0393] The application layer can include a package of applications (apps). For example... Figure 20 As shown, the application package may include wallpapers, partial / full-screen AOD, system user interface (SystemUI), desktop, etc.

[0394] Wallpapers can include video wallpapers, real-time rendered wallpapers, and interactive wallpapers.

[0395] The multi-mode input / wallpaper control module can be used to receive and process input data from different input devices, such as touch data from touchscreens, sensor data, and the folding status of electronic devices.

[0396] Video rendering and display control can be used to render and display wallpapers through media players or fusion computing engines.

[0397] The framework layer can provide application programming interfaces (APIs) and programming frameworks for applications in the application layer.

[0398] Continue as Figure 20 As shown, the framework layer may include an acceleration sensor (a+GSensor) manager, a touch manager, a folding manager, a media player, and a fusion computing engine.

[0399] Accelerometers can be used to detect the acceleration of electronic devices.

[0400] A touch manager can be used to receive touch signals from the screen of an electronic device.

[0401] A fold manager can be used to monitor the folding state of electronic devices. For foldable electronic devices (such as foldable phones, foldable tablets, etc.), the fold manager can detect the folding direction and angle.

[0402] Media players can be used to manage the playback process of media content, such as controlling music playback, pause, fast forward, and rewind.

[0403] The fusion computing engine can be used to implement functions such as texture rendering, physics engine, and scene management. Specifically, the fusion computing engine can efficiently process and render large amounts of texture data. Physics engines typically require a large amount of computation to simulate the mechanical interactions between objects, collision detection, object motion, etc. The fusion computing engine can accelerate complex physics simulation tasks, improving the accuracy and efficiency of the simulation. Scene management involves managing and rendering complex 3D scenes, including object placement, viewpoint management, and lighting calculations. The fusion computing engine can accelerate complex computational tasks in scene management, thereby improving rendering efficiency and real-time performance.

[0404] In the Android system, DreamManagerService is a system service responsible for managing and controlling the device's Dreams function. This service, also known as the "Daydream Screen Saver Service Manager," allows users to configure and manage the screen saver mode when the electronic device is idle. The Screen Saver Service Manager can start and stop Daydream mode, which displays animations, images, or other content when the electronic device is idle to prevent screen damage that may occur from prolonged inactivity. The Screen Saver Service Manager can also manage the display logic and interactivity of Daydream mode; for example, users can exit Daydream mode by touching or using other methods.

[0405] The PowerManagerService manages the power states and optimizes power consumption of electronic devices. For example, the PowerManager allows applications to request electronic devices to enter either a screen-off state or a DOZE (a low-power mode) state. The PowerManager also provides APIs to control the power policies of electronic devices, such as adjusting the central processing unit (CPU) frequency and screen brightness to reduce power consumption. The PowerManager can also manage wake lock functionality, ensuring that electronic devices remain awake when needed.

[0406] The Window Service Manager is used for window management. For example, it manages the creation, display, position, size, hierarchy, and layout parameters of all application windows. The Window Service Manager can also handle user interactions with windows, such as clicking, swiping, and dragging, as well as window responses and reactions. It can also control window display on the screen, including cascading multiple application windows, full-screen display, and split-screen display. Furthermore, it can handle system-level windows, such as the status bar and navigation bar, and control their interaction with application windows. For instance, the WindowManagerService can manage window hierarchy and display order. For example, when an electronic device is in partial AOD (Always-On Display) mode, the WindowManagerService can set the AOD layer above the lock screen layer, and the lock screen layer above the wallpaper layer. Thus, the content displayed when the electronic device is in partial AOD mode can include the subtly visible content of the lock screen layer and the wallpaper layer.

[0407] The engine can include the MediaPlayer engine and the Open Graphics Library (OpenGL).

[0408] The MediaPlayer engine can include the "Android.media" software package for handling multimedia-related functions and the "AudioTrack" class for playing audio.

[0409] Open graphics libraries can include texture rendering engines, physics engines, and scene management engines, among others.

[0410] Among them, the texture rendering engine is a drawing engine that renders textures in the wallpaper in real time.

[0411] The physics engine is a rendering engine that renders light, shadows, and other elements in wallpapers in real time.

[0412] Scene managers can be used to manage scene elements stored on electronic devices and the matching relationships between scenes.

[0413] The following is combined Figure 21 The wallpaper display method mentioned in the embodiments of this application will be described.

[0414] In some specific implementations, after a user selects a theme and clicks "Apply" on the theme settings page, the theme application can unzip the theme package to obtain the theme files. Then, the wallpaper service manager can send a wallpaper change broadcast and activate the corresponding wallpaper service. Upon receiving the wallpaper change broadcast, SystemUI can update the system UI display based on the new wallpaper information to ensure consistency between the system UI and the new wallpaper style. Furthermore, SystemUI can also send control commands to the wallpaper service to trigger it to begin controlling the wallpaper display.

[0415] The embodiments disclosed in this application can also be implemented as instructions carried or stored thereon on one or more temporary or non-temporary machine-readable (e.g., computer-readable) storage media, which can be read and executed by one or more processors. For example, the instructions can be distributed via a network or via other computer-readable media. Therefore, machine-readable media can include any mechanism for storing or transmitting information in a machine-readable (e.g., computer-readable) form, including but not limited to floppy disks, optical disks, magnetic disks, magneto-optical disks, read-only memory (ROM), random access memory (RAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic cards or optical cards, flash memory, or tangible machine-readable storage for transmitting information (e.g., carrier waves, infrared signals, digital signals, etc.) using the Internet in the form of electrical, optical, acoustic, or other propagation signals. Therefore, machine-readable media includes any type of machine-readable medium suitable for storing or transmitting electronic instructions or information in a machine-readable (e.g., computer-readable) form.

[0416] Embodiments of this application can be implemented as computer programs or program code that execute on a programmable system, the programmable system including at least one processor, a storage system (including volatile and non-volatile memory and / or storage elements), at least one input device, and at least one output device.

[0417] Program code can be applied to input instructions to execute the functions described in this application and generate output information. The output information can be applied to one or more output devices in a known manner. For the purposes of this application, the processing system includes any system having a processor such as, for example, a digital signal processor (DSP), a microcontroller, an application-specific integrated circuit (ASIC), or a microprocessor.

[0418] The program code can be implemented using a high-level procedural language or an object-oriented programming language to communicate with the processing system. Assembly language or machine language can also be used when needed. In fact, the mechanisms described in this application are not limited to any particular programming language. In either case, the language can be a compiled language or an interpreted language.

[0419] In the accompanying drawings, some structural or methodological features may be shown in a specific arrangement and / or order. However, it should be understood that such a specific arrangement and / or order may not be necessary. Rather, in some embodiments, these features may be arranged in a manner and / or order different from that shown in the illustrative drawings. Furthermore, the inclusion of structural or methodological features in a particular figure does not imply that such features are required in all embodiments, and in some embodiments, these features may be omitted or may be combined with other features.

[0420] It should be noted that in the examples and description of this patent, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one" does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0421] Although this application has been illustrated and described with reference to certain embodiments thereof, those skilled in the art will understand that various changes in form and detail may be made thereto without departing from the scope of this application.< / interface>

Claims

1. A wallpaper display method, applied to an electronic device, characterized in that, include: The electronic device is detected to have entered a first display state, and the user scenario in which the electronic device is located is determined to form a first set of candidate scenarios, and the first set of candidate scenarios corresponds to a first set of candidate wallpapers, the first set of candidate wallpapers including multiple wallpapers; Display the first wallpaper in the first set of candidate wallpapers, wherein the first wallpaper is the wallpaper of the first user scene in the first set of candidate scenes, and the display content of the first wallpaper is related to the scene factors of the first user scene; After detecting that the electronic device has entered the second display state from the first display state, it re-enters the first display state; When the electronic device re-enters the first display state, the user scenario in which the electronic device is located is determined to form the first set of candidate scenarios, and the second wallpaper in the first set of candidate wallpapers is displayed, wherein the second wallpaper is different from the first wallpaper.

2. The method according to claim 1, characterized in that, The second wallpaper is the wallpaper of the first user scene in the first set of candidate scenes, and the display content of the second wallpaper is related to the scene factors of the first user scene; or The second wallpaper is the wallpaper of the second user scene in the first set of candidate scenes, and the display content of the second wallpaper is related to the scene factors of the second user scene.

3. The method according to claim 1, characterized in that, The method further includes: When the electronic device re-enters the first display state, the user scenario in which the electronic device is located is determined to form a second set of candidate scenarios, and a third wallpaper from the second set of candidate wallpapers is displayed. Wherein, at least one user scenario in the second set of candidate scenarios is different from that in the first set of candidate scenarios, and the third wallpaper, the second wallpaper, and the first wallpaper are different wallpapers.

4. The method according to claim 3, characterized in that, The first user scenario corresponds to the second set of candidate scenarios and the first set of candidate scenarios. The third wallpaper is the wallpaper of the first user scene in the second set of candidate scenes, and the display content of the third wallpaper is related to the scene factors of the first user scene; or The third wallpaper is the wallpaper of the third user scenario in the second set of candidate scenarios, and the display content of the third wallpaper is related to the scenario factors of the third user scenario.

5. The method according to claim 1, characterized in that, The method further includes: The user scenario in which the electronic device is located is determined based on scenario factors.

6. The method according to any one of claims 1 to 5, characterized in that, The scenario factors include at least one of the following: time related to the user scenario, space where the electronic device is located, the user's emotions, and user behavior.

7. The method according to claim 6, characterized in that, The time related to the user scenario includes at least one of the user's birthday, holidays, solar terms, and travel dates.

8. The method according to claim 7, characterized in that, The scenario factors were obtained through the following methods: The user's birthday is obtained based on the information recorded in the memo application; Based on the information recorded in the calendar application, obtain at least one of the festivals and the solar terms; Obtain the travel date based on the order information from the ticketing application; The location of the electronic device is obtained based on the information recorded in the weather application; Based on the text information of the social application, obtain at least one of the following: the user's birthday, the festival, the solar term, the user's mood on the electronic device, and the user's behavior on the electronic device; Based on chat information from a communication application, obtain at least one of the following: the user's birthday, the user's mood on the electronic device, and the user's behavior on the electronic device; Based on the usage information of the sports application, the user behavior of the user of the electronic device is obtained.

9. The method according to claim 6, characterized in that, The user's emotions on the electronic device are obtained through the following methods: Acquire the user's facial image captured by the image acquisition device in the electronic device; The user's emotion is determined based on the user's facial image.

10. The method according to any one of claims 1 to 5, characterized in that, The method further includes: The first candidate scenario set includes multiple candidate user scenarios, and the multiple candidate user scenarios belong to multiple scenario types. Based on the number of the multiple candidate user scenarios and the display priority of the scenario type to which each candidate user scenario belongs, the first user scenario is selected from the multiple candidate user scenarios. The wallpaper corresponding to the first user scenario is used as the first wallpaper.

11. The method according to claim 10, characterized in that, The step of selecting the first user scenario from the plurality of candidate user scenarios based on the number of candidate user scenarios and the display priority of the scenario type to which each candidate user scenario belongs includes: Based on the number of candidate user scenarios and the display priority of the scenario type to which each candidate user scenario belongs, the interval corresponding to the playback probability of each candidate user scenario is determined. The higher the display priority of the scenario type to which the candidate user scenario belongs, the larger the interval corresponding to the playback probability of the candidate user scenario. Generate random numbers; The candidate user scenario corresponding to the interval in which the random number falls is determined as the first user scenario.

12. The method according to claim 10, characterized in that, The step of using a wallpaper corresponding to the first user scenario as the first wallpaper includes: From the first set of candidate wallpapers for the first user scenario, randomly select one wallpaper as the first wallpaper.

13. The method according to any one of claims 1 to 5, characterized in that, The method further includes: The first set of candidate scenarios includes multiple candidate user scenarios, and one candidate user scenario is randomly selected from the multiple candidate user scenarios as the first user scenario. The wallpaper corresponding to the first user scenario is used as the first wallpaper.

14. The method according to any one of claims 1 to 5, characterized in that, The method further includes: The first candidate scenario set includes multiple candidate user scenarios. Based on the number of multiple candidate user scenarios and the display priority of each candidate user scenario, the first user scenario is selected from the multiple candidate user scenarios. The wallpaper corresponding to the first user scenario is used as the first wallpaper.

15. The method according to claim 1, characterized in that, The method further includes: Randomly select a wallpaper from the first set of candidate wallpapers as the first wallpaper.

16. The method according to claim 1, characterized in that, The first display state includes a locked screen state, and the second display state includes either an unlocked state or a screen-off state, or... The first display state includes an unlocked state, and the second display state includes either a screen-off state or a screen-locked state, or... The first display state includes a first desktop state, and the second display state includes a second desktop state. The first desktop state and the second desktop state are different desktops. The desktop includes a central desktop, a first page of the desktop, and a second page of the desktop.

17. The method according to claim 16, characterized in that, The step of detecting that the electronic device has entered the second display state after entering the first display state, and then re-entering the first display state includes: The electronic device is detected to have entered the second display state and the third display state sequentially from the first display state, and then enter the first display state again; The first display state includes a locked screen state, the second display state is an unlocked state, and the third display state is a screen-off state.

18. An electronic device, characterized in that, include: A memory for storing instructions executed by one or more processors of the electronic device, and a processor, being one of one or more processors of the electronic device, for performing the method according to any one of claims 1-17.

19. A readable storage medium, characterized in that, The readable storage medium stores instructions that, when executed on an electronic device, cause the electronic device to perform the method of any one of claims 1-17.

20. A computer program product, characterized in that, The computer program product includes computer instructions that, when executed by an electronic device, enable the electronic device to perform computer program code of the method as described in any one of claims 1-17.

Images