Method of updating superscript and electronic device

Abstract

The application provides a method for updating a badge and an electronic device. When a first user operation triggers a condition for the electronic device to update a badge of an application, the electronic device first compares a first value and a second value. When the first value and the second value are inconsistent, the electronic device updates the first value displayed by the badge to the second value. When the first value and the second value are consistent, the electronic device does not update the badge. The first value is used to represent a number displayed by the badge, and the second value is used to represent a number of unread messages of the application. In this way, the electronic device can reduce repeated updating of the same badge by determining whether the badge needs to be updated. The load of the electronic device is reduced, and the performance of the electronic device is improved.

Description

Technical Field

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

[0002] Most electronic devices nowadays have message notification functions. When a third-party application installed on an electronic device receives a new message, the electronic device can display the application's badge on the desktop, such as displaying a badge in the upper right corner of the application icon to indicate the number of messages.

[0003] Generally, when a desktop provides a badge interface to third-party applications, the existing logic dictates that for each badge update, the third-party application needs to call the badge interface to send badge information to the desktop, which then updates and draws the badge based on that information. Since each interface call generates system load, frequent calls to the badge interface by third-party applications can lead to significant system load and negatively impact the performance of electronic devices. Summary of the Invention

[0004] The embodiments of this application provide a method and electronic device for updating superscripts, which can reduce the repeated drawing and updating of the same superscripts by the electronic device, reduce the load, and improve the performance of the electronic device.

[0005] In a first aspect, this application provides a method for updating superscripts, the method comprising:

[0006] In response to a first user action, a first value and a second value are determined, wherein the first user action is used to trigger a condition for updating the application's badge, the first value is used to represent the number displayed by the badge, and the second value is used to represent the number of unread messages in the application;

[0007] If the first value and the second value are inconsistent, the first value displayed by the superscript will be updated to the second value.

[0008] In the above method, when the first user action triggers the update of the application's badge, the electronic device first determines the first and second values. If the first and second values ​​are inconsistent, the electronic device updates the badge data. Since the first value corresponds to the number displayed on the badge, and the second value corresponds to the number of unread messages, the inconsistency between the first and second values ​​can be understood as a change in the number of unread messages in the application; the number currently displayed on the badge is inconsistent with the number of unread messages the electronic device needs to show the user. Therefore, the electronic device can update the badge to show the user the actual number of unread messages. By determining when to update the badge, the electronic device can update it when the number currently displayed on the badge is inconsistent with the number of unread messages to be shown to the user, providing the user with a more accurate badge notification.

[0009] In one possible implementation, after determining the first and second values ​​in response to a first user operation, the method further includes:

[0010] If the first value and the second value are the same, the application's badge is not updated.

[0011] In the above method, the electronic device does not update the badge when the first value and the second value are inconsistent. This can be understood as the number of unread messages in the application not changing, and the number displayed on the current badge matches the number of unread messages the electronic device needs to show the user; therefore, the electronic device does not need to repeatedly update the same badge. In existing solutions, when the first user triggers the condition to update the application's badge, the application calls the badge interface provided by the electronic device to update the badge. That is, in existing solutions, the electronic device may repeatedly update the same badge. Since each badge update by the electronic device generates some load, repeatedly updating the same badge may waste resources, resulting in a large load and affecting the performance of the electronic device. This application embodiment adds a judgment process, which can avoid repeatedly updating the same badge, saving computing resources, reducing load, and improving the performance of the electronic device.

[0012] In one possible implementation, after updating the first value displayed by the superscript to the second value when the first value and the second value are inconsistent, the method further includes:

[0013] The second value is stored in the memory data of the system service.

[0014] In the above method, after updating the badge based on the second value, the electronic device can store the second value in the system service's memory data. When the electronic device responds to the first user's operation again, it can retrieve the second value from the memory data to determine whether the badge needs to be updated. Furthermore, storing the second value in the system service's memory data improves the stability and security of the stored data because memory data is less susceptible to interference.

[0015] In one possible implementation, the first user operation includes one or more of the following: launching an application, switching the application from foreground to background, switching the application from background to foreground, switching pages in the application interface, switching pages from other pages back to the main page in the application interface, and browsing information in the application interface.

[0016] In one possible implementation, determining the first and second values ​​in response to a first user action includes:

[0017] In response to the first user operation, the first value is determined based on the index cache data stored in the memory data of the system service;

[0018] The second value is determined from the number of unread messages obtained from the application.

[0019] In the above method, the first value is obtained from the system service, and the second value is obtained from the application. The first value is stored in the system service's memory data. Since memory data is less susceptible to interference, the accuracy of the obtained first value can be improved. Obtaining the second value from the application ensures that the second value corresponds to the number of unread messages in the application, thus displaying the actual number of unread messages to the user.

[0020] In one possible implementation, the method further includes:

[0021] In response to a second user action on the application, the badge cache data corresponding to the application is deleted from the memory data of the system service.

[0022] In one possible implementation, the second user operation includes one or more of the following: clearing data in the application, uninstalling the application, and deleting a user account, wherein the user account corresponds to a user desktop and the application is installed on the user desktop.

[0023] In the above method, the second user operation may cause the badge cache data corresponding to the application to become invalid cache, i.e., dirty data in the memory data. This application embodiment responds to various second user operations to clear the badge cache data, releasing memory space and clearing dirty data from the memory data of system services.

[0024] Secondly, an electronic device is provided in the embodiments of this application, the electronic device comprising: one or more processors and one or more memories; wherein, the one or more memories are coupled to the one or more processors, the one or more memories are used to store computer program code, the computer program code including computer instructions, and the one or more processors call the computer instructions to cause the electronic device to perform the method for updating subscripts described in the first aspect or any possible implementation of the first aspect.

[0025] Thirdly, this application provides a chip or chip system including at least one processor and a communication interface. The communication interface and the at least one processor are interconnected via a circuit. The at least one processor is used to run a computer program or instructions to execute the method for updating subscripts described in the first aspect or any possible implementation of the first aspect. The communication interface in the chip can be an input / output interface, pins, or circuits, etc.

[0026] In one possible implementation, the chip or chip system described above in the embodiments of this application further includes at least one memory, in which instructions are stored. The memory can be an internal storage unit of the chip, such as a register or cache, or it can be a storage unit of the chip itself (e.g., read-only memory, random access memory, etc.).

[0027] Fourthly, embodiments of this application provide a computer storage medium storing a computer program that, when executed by a processor, causes the computer to perform a method for updating a subscript as described in the first aspect or any possible implementation thereof.

[0028] Fifthly, embodiments of this application provide a computer program product that, when run on a communication device, causes the communication device to perform a method for updating a badge as described in the first aspect or any possible implementation thereof.

[0029] It should be understood that the descriptions of technical features, technical solutions, beneficial effects, or similar language in this application do not imply that all features and advantages can be achieved in any single embodiment. Rather, it is understood that the description of a feature or beneficial effect means that a specific technical feature, technical solution, or beneficial effect is included in at least one embodiment. Therefore, the descriptions of technical features, technical solutions, or beneficial effects in this specification do not necessarily refer to the same embodiment. Furthermore, the technical features, technical solutions, and beneficial effects described in this embodiment can be combined in any suitable manner. Those skilled in the art will understand that embodiments can be implemented without one or more specific technical features, technical solutions, or beneficial effects of a particular embodiment. In other embodiments, additional technical features and beneficial effects may be identified in specific embodiments that do not embody all embodiments. Attached Figure Description

[0030] The accompanying drawings used in the embodiments of this application are described below.

[0031] Figure 1 This is a schematic diagram of the interface of an electronic device provided in an embodiment of this application;

[0032] Figure 2 This is a schematic diagram of an updated superscript provided in an embodiment of this application;

[0033] Figure 3 This is a flowchart illustrating an update of the badge of a first application, provided in an embodiment of this application.

[0034] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application;

[0035] Figure 5 This is a software structure block diagram of an electronic device provided in an embodiment of this application;

[0036] Figure 6 This is a flowchart illustrating an update of a superscript marker, as provided in an embodiment of this application.

[0037] Figure 7 This is a flowchart illustrating a method for reading a cache, as provided in an embodiment of this application.

[0038] Figure 8 This is a flowchart illustrating an embodiment of updating badge cache data provided in this application;

[0039] Figure 9 This is a schematic diagram illustrating a method of cleaning up data via the desktop, as provided in an embodiment of this application.

[0040] Figure 10 This is a schematic diagram illustrating the clearing of invalid cache provided in an embodiment of this application;

[0041] Figure 11 This is a schematic diagram illustrating another method for clearing expired cache provided in an embodiment of this application;

[0042] Figure 12 This is another flowchart of updating a superscript provided in an embodiment of this application;

[0043] Figure 13 This is a schematic flowchart of a method for updating superscripts provided in an embodiment of this application. Detailed Implementation

[0044] The terminology used in the following embodiments of this application is for the purpose of describing particular embodiments only and is not intended to be limiting of this application. As used in the specification and appended claims of this application, the singular expressions “a,” “an,” “the,” “the,” “the,” and “this” are intended to include the plural expressions as well, unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in this application refers to and includes any or all possible combinations of one or more of the listed items.

[0045] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature, and in the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more.

[0046] To facilitate understanding of the embodiments of this application, some terms used in the embodiments of this application are explained below, so that those skilled in the art can understand them.

[0047] 1. Desktop (launcher): Also known as a desktop application, desktop launcher, or desktop application, it is a graphical user interface (GUI) program, which is a computer operating user interface displayed in a graphical way. A graphical user interface (GUI) is a human-computer communication interface format that allows users to use input devices such as a mouse to manipulate icons or menu options on the screen to select commands, access files, launch programs, or perform other everyday tasks.

[0048] 2. Badge: Also known as a desktop badge or unread message badge, when an application installed on an electronic device receives a message, the device can display a badge on the application icon on the desktop. For example, a badge message (such as a number, icon, symbol, etc.) is displayed on the application icon (say, the upper right corner). The badge message is used to indicate that the application currently has unread messages. When the badge message is a number, the number indicates the number of unread messages.

[0049] Please see Figure 1 , Figure 1 This is a schematic diagram of the interface of an electronic device provided in an embodiment of this application. For example... Figure 1 As shown, the applications installed in electronic device 100 include system applications and third-party applications. For example, system applications mainly refer to applications that come pre-installed on the electronic device or core applications provided by the manufacturer, including but not limited to... Figure 1 The user interface 101 shown in (a) includes applications such as "App Market," "Memo," "Store," and "Browser." Third-party applications primarily refer to applications developed and provided by entities other than device manufacturers or operating system developers. These applications can be downloaded and installed through other channels, such as their official websites or third-party app markets. The types of third-party applications include, but are not limited to, communication, lifestyle, business, and entertainment applications. This application embodiment does not limit the categories of third-party applications.

[0050] like Figure 1 As shown in (a), the user interface 101 includes a first badge 1011, a status bar 1012, a page indicator 1013, and multiple application icons. The icons of third-party applications display the first badge 1011, which indicates the first number of unread messages. For example, the first badge 1011 includes the symbol "○" in the upper right corner of the third-party application's desktop icon and the number "3" inside it, indicating that the first number of unread messages is 3.

[0051] The status bar 1012 may include one or more signal strength indicators for mobile communication signals (also known as cellular signals) such as 5G, Wi-Fi signal strength indicators, battery status indicators, time indicators (e.g., 8:00), etc.

[0052] Page indicator 1013 can be used to indicate the positional relationship between the currently displayed page and other pages.

[0053] Multiple application icons may include time application icons (e.g., 08:00), date application icons (e.g., January 1st, Friday), weather application icons (e.g., 5℃), app store application icons, memo application icons, shopping mall application icons, browser application icons, phone application icons, messaging application icons, camera application icons, settings application icons, etc. In addition to the above icons, the user interface 101 may also include other application icons, which are not listed here. Multiple application icons may be distributed across multiple pages. A page indicator 1013 can be used to indicate which of the multiple pages hosting the multiple applications the user is currently viewing. Users can browse other pages using left and right swipe touch operations.

[0054] When the user clicks Figure 1 When the user clicks the icon of the third-party application in the user interface 101 shown in (a), the electronic device 100 switches from the desktop to the interface of the third-party application in response to the user's click operation, displaying as shown in (a). Figure 1 User interface 102 shown in (b).

[0055] exist Figure 1 The user interface 102 shown in (b) includes a status bar 1012 and specific information about the user page. The specific information about the user page includes user profile, unread messages, and version information. Specifically, the user interface 102 displays three unread messages. The user interface 102 may also include specific information about other user pages, which will not be listed here.

[0056] In one implementation, if the third-party application does not receive a new message, and the electronic device 100 does not receive a user's click / read unread message action, the number of unread messages remains at 3. In this case, if the electronic device 100 responds to the user's return action and returns from the third-party application's user interface 102 to the desktop, it displays... Figure 1 User interface 103 shown in (c) is where the third-party application switches from running in the foreground to running in the background.

[0057] like Figure 1 As shown in (c), the user interface 103 includes a second badge 1031, a status bar 1012, a page indicator 1013, and multiple application icons. The status bar 1012, page indicator 1013, and multiple application icons can be found in [reference needed]. Figure 1The specific description in (a) is as follows. The icon of the third-party application displays a second badge 1031, which indicates the second number of unread messages. Specifically, the second badge 1031 includes the "○" symbol in the upper right corner of the third-party application's desktop icon and the number "3" inside it. The number "3" indicates that the second number of unread messages is 3. Since the third-party application does not receive any new messages, and the electronic device 100 does not receive any user click / read unread message operation, the number of unread messages in the third-party application remains unchanged, and the badge value displayed by the third-party application also remains unchanged. For example, from... Figure 1 (a) and Figure 1 As can be seen from (c), the first subscript 1011 and the second subscript 1031 are the same. This is understandable. Figure 1 The first superscript 1011 and the second superscript 1031 shown can also be called numeric superscripts. The numbers contained in the numeric superscripts are used to indicate the number of unread messages. This application embodiment does not limit the shape, position, color, size, or other parameters of the numeric superscripts.

[0058] The following will combine Figure 2 This section provides a detailed explanation of how to update badges on electronic devices.

[0059] Figure 2 This is a schematic diagram of an updated superscript provided in an embodiment of this application, such as... Figure 2 As shown, the desktop of an electronic device provides an interface to third-party applications, allowing these applications to call the interface provided by the desktop to update and draw the badges on icons.

[0060] like Figure 2 As shown, the desktop provides an interface to third-party applications and the ability to draw badges. When the badge of a third-party application needs to be updated, the third-party application can call the badge interface to update the badge on the desktop icon of the third-party application.

[0061] For example, when a user clicks... Figure 1 As shown in (a), the icon of a third-party application is displayed. When an electronic device launches the third-party application in response to a user action and navigates from the desktop to the third-party application's interface, the third-party application needs to update its badge once. The third-party application can... Figure 2The method shown calls the desktop's badge interface, thereby invoking the desktop's badge update function. Simultaneously, third-party applications can also send data packets containing badge values ​​to the desktop through the aforementioned badge interface. The badge value represents the number of unread messages received by the third-party application. In one implementation, when a third-party application is launched, if it hasn't received any new messages, its unread message count remains 3. The third-party application then sends a data packet containing a badge value of 3 to the desktop. Based on the received badge value of 3, the desktop draws and updates a second badge 1031 with a badge value of 3 on the desktop icon corresponding to the third-party application. Therefore, even if the number of unread messages in the third-party application remains unchanged, launching the third-party application still requires the electronic device to draw and update a second badge 1031 that matches the first badge 1011 currently displayed by the third-party application.

[0062] For another example, in response to a user's back operation, electronic device 100 returns from the user interface 102 of a third-party application to the desktop, displaying... Figure 1 User interface 103 is shown in (c). At this point, the third-party application switches from running in the foreground to running in the background, and the third-party application needs to update its badge once. The third-party application can... Figure 2 The method shown calls the desktop's badge interface, thereby invoking the desktop's badge update function. In one implementation, when a third-party application switches from foreground to background operation, if the third-party application does not receive any new messages and its unread message count remains at 3, the third-party application sends a data packet containing a badge value of 3 to the desktop. Based on the received badge value of 3, the desktop draws and updates a second badge 1031 with a badge value of 3 on the desktop icon corresponding to the third-party application. Therefore, even if the number of unread messages in the third-party application remains unchanged, if the third-party application switches from foreground to background operation, the electronic device still needs to draw and update a second badge 1031 that matches the first badge 1011 currently displayed by the third-party application.

[0063] In summary, at the first moment, the third-party application's badge is the first badge 1011, and the value in the first badge 1011 is the first value, which represents the number of unread messages. At the second moment, if the condition for updating the badge is triggered (e.g., ... Figure 1 The operation of launching a third-party application in (a) and (b), or Figure 1In steps (b) and (c), which involve switching the third application from foreground to background operation, the third application calls the desktop's badge interface to update the badge. Understandably, if the third application doesn't receive any new messages from the first moment to the second moment, and the user doesn't click / read any unread messages, then the number of unread messages in the third application at the second moment is the same as the number of unread messages at the first moment—for example, both being the first number. Therefore, at the second moment, the value in the second badge 1031 drawn by the desktop based on the first number is also the first value, meaning the second badge 1031 is the same as the first badge 1011. In this situation, the desktop draws and updates the same badge for the third application, resulting in wasted resources.

[0064] In one possible implementation, whether a third-party application calls the badge interface provided by the desktop is determined by the business design of the third-party application itself. For example, the business design of the third-party application may include one or more of the following as conditions to trigger the third-party application to call the badge interface: launching the third-party application (e.g.,...). Figure 1 In (a) and (b), the electronic device jumps from the desktop to the interface of a third-party application, and the third-party application switches from running in the foreground to running in the background (e.g. Figure 1 In (b) and (c), the electronic device returns to the desktop from the interface of a third-party application, the third-party application switches from running in the background to running in the foreground, the page in the interface of the third-party application is switched, the page in the interface of the third-party application is switched from other pages back to the main page, the information in the third-party application is browsed, and so on.

[0065] For example, when an electronic device launches a first application in response to a first user's operation, or when an electronic device switches pages of the first application interface in response to a second user's operation, the first application can be triggered to call the badge interface.

[0066] Therefore, due to the inherent business design of third-party applications, there may be situations where users continuously trigger conditions to update badges while using these applications. Furthermore, since electronic devices provide badge interfaces to third-party applications, these applications can call the badge interface provided by the desktop without being restricted by the electronic device's operating system. If the electronic device continuously triggers the third-party application to update badges in response to user actions, there may be instances where the third-party application repeatedly calls the badge interface to display the same badge on the desktop. Since each call to the badge interface by a third-party application generates some load, if the third-party application repeatedly calls the badge interface to display the same numerical badge on the desktop, it will cause unnecessary waste of resources, thereby increasing the system load and desktop load.

[0067] The following will combine Figure 3 This section provides a detailed explanation of the internal processing steps involved in updating badges on electronic devices.

[0068] Please see Figure 3 , Figure 3 This is a flowchart illustrating an update of the badge of a first application, provided in an embodiment of this application. The first application will be used as an example for explanation. Figure 3 As shown, the flowchart includes S301 to S310, involving the system framework, system service (SystemServer) and desktop (Launcher). The first application mentioned above can be a third-party application installed in the electronic device.

[0069] S301, the system framework increases the priority of the compute memory management parameter (OomAdj).

[0070] In this embodiment, the desktop updates the badge of the first application through a ContentProvider component. The `call` method is a general method provided by the ContentProvider for handling specific requests or commands. Therefore, the system framework can use the `call` method to invoke the ContentProvider component on the desktop, enabling the ContentProvider component to update the badge of the first application.

[0071] Each time the system framework calls the `call` method, it triggers the system to perform two calculations of OomAdj on the desktop. For example, the first OomAdj calculation includes steps S301-S303, and the second OomAdj calculation includes steps S308-S310.

[0072] Among them, the memory management parameter (Out of Memory Adjustment, OomAdj) is an important parameter for the system to adjust memory when memory is insufficient, determining the order in which the system reclaims memory. When dealing with application (APP) startup speed, the priority of the main thread can be set to ensure that the main thread occupies the Central Processing Unit (CPU) for a sufficient period of time. When the system is short of memory, it can release memory sequentially according to the size of OomAdj.

[0073] Therefore, before updating the badge of the first application on the desktop, the system framework can first increase the priority of calculating OomAdj to calculate the priority of processes on the desktop, ensuring that the desktop has enough memory to update the numeric badge. Increasing the priority of calculating OomAdj is to adjust the order in which OomAdj calculations are executed, so that OomAdj calculations are performed first.

[0074] S302, SystemServer calculates OomAdj.

[0075] For example, after the system framework increases the priority of calculating OomAdj, SystemServer can prioritize the calculation of OomAdj.

[0076] S303, SystemServer traverses all reachable processes on the desktop and updates OomAdj.

[0077] In one possible implementation, when calculating OomAdj, the electronic device's SystemServer can traverse all reachable processes on the desktop and update the process's memory management parameters based on the current usage of all reachable processes. Here, reachable processes can be understood as processes currently running on the desktop.

[0078] For example, if a process is running in the foreground, it has a higher priority and a lower OomAdj value. If a process is running in the background, it has a lower priority and a higher OomAdj value.

[0079] S304, the system framework calls the desktop content provider component through the call method.

[0080] Before calling the `call` method, the system framework triggers a system service to calculate `OomAdj` for all reachable processes on the desktop. Then, memory is released sequentially based on the size of `OomAdj` to ensure the desktop has sufficient memory to update numeric indices.

[0081] A ContentProvider is a component on the Android platform used to manage application data and allow different applications to share data. It provides a standardized interface that enables applications to perform CRUD operations on data, while also controlling access permissions for other applications' data.

[0082] ContentProviders are typically used for: storing and managing an application's structured data, such as tabular data in a database; allowing other applications to access and share the application's data, such as contact information and media files; and providing a standardized interface that enables applications to access data from different sources in the same way.

[0083] The `call` method is a general method provided by ContentProvider for handling specific requests or commands that may not be suitable for implementation using standard CRUD (Create, Read, Update, Delete) operations. Therefore, the `call` method can be used to pass complex operation requests between content providers and users. Thus, in this embodiment, a third-party application can invoke the ContentProvider on the desktop by calling the `call` method.

[0084] S305, the badge of the first application to update on the desktop.

[0085] For example, because the ContentProvider component can provide a flexible and secure data access interface to other applications, electronic devices can use the ContentProvider component to update application badges.

[0086] Specifically, the ContentProvider component updates the badge of the first application based on the badge value to be updated. This badge value can be a parameter carried in the first request. Since the first request may carry one or more parameters, the ContentProvider component can determine the badge value to be updated from these parameters. Then, it updates the badge of the first application based on the badge value to be updated. For example, if the badge value to be updated is "3", then the badge value of the first application drawn will also be "3".

[0087] S306, Desktop update desktop database.

[0088] For example, after the desktop updates the badge of the first application, the parameters in the desktop change. Therefore, the desktop also needs to update the desktop database based on the updated badge.

[0089] The desktop database typically refers to the database used by the launcher application, storing information such as application icons, shortcuts, folders, and widgets on the user's home screen. Therefore, after updating the badge of the first application, the corresponding data for that application in the desktop database also needs to be updated. This ensures that the badge information of the first application stored in the desktop database corresponds to the updated badge information.

[0090] For example, if the first application's index value stored in the desktop database is 1, and the updated index value of the first application is 3, then the desktop can change the index value of the first application stored in the desktop database from 1 to 3.

[0091] S307 monitors changes in the first application's badge.

[0092] Specifically, when a Content Provider user needs to monitor data changes, they can do so through step S307. For example, when the desktop updates the numeric badge of the first application, step S307 can monitor the data changes in the ContentProvider component, i.e., the changes in the badge of the first application, and thus notify the user of the data changes.

[0093] In one implementation, the desktop generates notification messages for the observer.

[0094] Specifically, when a Content Provider user needs to monitor data changes, it can register an Observer to do so. The Content Provider user can be the user or other components within the electronic device; there are no restrictions here. Therefore, when the desktop updates the badge of the first application through the Content Provider component, the data in the Content Provider component changes, and the desktop can generate an Observer notification. This Observer notification is used to inform the Content Provider user of the data change in the Content Provider component, specifically the change in the first application badge.

[0095] The Observer pattern is a design pattern used to establish a one-to-many dependency relationship, so that when the state of one object changes, all objects that depend on it are notified and automatically updated. This pattern can be used to implement event systems, data binding, notification mechanisms, etc.

[0096] In one implementation, the observer sends a notification to the content service.

[0097] In Android, the ContentService can be considered a system-level message center. Applications can subscribe to messages they are interested in and send messages to notify other processes. Therefore, if an application subscribes to messages (such as badge update messages) from the ContentService, when the home screen updates the badge of the first application, the Observer can send the change in the badge of the first application to the ContentService.

[0098] In one implementation, ContentService sends notifications to ContentObserver.

[0099] ContentObserver is a class in Android development used to observe changes in data. It's typically used to monitor changes in data within a Content Provider so that appropriate actions can be taken when the data changes. In Android, a Content Provider is a component used to manage data access; it provides a standard interface for applications to access and manipulate data stored on the device. A ContentObserver can register with a Uniform Resource Identifier (URI), and will be notified when data associated with that URI changes.

[0100] S308, the system framework reduces the priority of calculating OomAdj.

[0101] After updating the numerical badge of the first application on the desktop, because the priority of calculating OomAdj is increased in S301, the system framework can reduce the priority of calculating OomAdj to avoid consuming process memory. After reducing the priority of calculating OomAdj, a second OomAdj calculation is required.

[0102] Lowering the priority of calculating OomAdj is to adjust the order in which OomAdj is calculated, so that the calculation of OomAdj is performed later.

[0103] S309, SystemServer calculates OomAdj.

[0104] For example, after the system framework lowers the priority of calculating OomAdj, the SystemServer of the electronic device can perform the calculation of OomAdj. Steps S309 and S302 are identical.

[0105] S310, SystemServer traverses all reachable processes on the desktop and updates OomAdj.

[0106] In one possible implementation, when calculating OomAdj, the electronic device's SystemServer can traverse all reachable processes on the desktop and update the process's memory management parameters based on the current usage of all reachable processes. Here, reachable processes can be understood as processes currently running on the desktop.

[0107] For example, if a process is running in the foreground, it has a higher priority and a smaller OomAdj value. If a process is running in the background, it has a lower priority and a larger OomAdj value. Steps S310 and S303 are identical.

[0108] Please continue reading. Figure 3 As can be seen from S301-S303 and S308-S310, updating the badge on an electronic device triggers the system to perform two OomAdj calculations on the desktop. Since the desktop's OomAdj calculation typically iterates through all reachable processes and recalculates the memory management parameters of all reachable processes, if the number of reachable processes is large, the desktop's OomAdj calculation may be time-consuming and consume a significant load. For example, during the badge update process, the time taken to complete the OomAdj calculation may be 1-10 milliseconds, resulting in a longer badge update time.

[0109] Please continue reading. Figure 3 ,according to Figure 3 As shown in S301 and S302, after the system framework increases the priority of calculating OomAdj, OomAdj is calculated in SystemServer. Therefore, the system framework's increase in the priority of calculating OomAdj ensures that the electronic device's calculation of OomAdj in SystemServer is a result of cross-process communication. Similarly, according to... Figure 3 As shown in S308 and S310, after the system framework lowers the priority of calculating OomAdj, OomAdj is calculated in SystemServer. Therefore, by lowering the priority of calculating OomAdj, the system framework ensures that the electronic device calculates OomAdj in SystemServer, which is also a result of cross-process communication.

[0110] Furthermore, since cross-process communication usually needs to be performed in the binder thread, the above calculation of OomAdj needs to be performed in the binder thread, which will cause the binder thread to be overloaded.

[0111] The Binder thread is a key component for inter-process communication (IPC). Binder is a lightweight IPC mechanism that allows different processes to exchange data, and it is also the foundation for communication between many core services in the system.

[0112] Please continue reading. Figure 3 ,according to Figure 3 As can be seen from S306, after updating the application's badge, it is also necessary to update the corresponding data of the application in the desktop database.

[0113] Therefore, if electronic devices repeatedly update application badges, the desktop will also need to perform database operations frequently. For example, frequent input / output (IO) operations when updating the desktop database can increase the database operation load on the desktop application, leading to a load on subsequent ContentObserver system updates.

[0114] In summary, if the electronic device updates the badge for the third-party application after the third-party application calls the badge interface according to the existing solution, then the aforementioned system load and desktop load issues will exist.

[0115] To address the aforementioned issues, this application proposes a method for updating a badge. An electronic device stores the badge value updated by a first application at a first moment. When the first application triggers a badge update condition at a second moment due to user operation, the electronic device first compares the badge value to be updated at the second moment with the stored badge value from the first moment. If the value at the second moment is equal to the value at the first moment, the electronic device does not update the badge of the first application. If the value at the second moment is not equal to the value at the first moment, the electronic device draws and updates the badge of the first application on the desktop. Note that the second moment occurs after the first moment, and the badge of the first application is not updated during the period from the first moment to the second moment.

[0116] Therefore, the method provided in this application is optimized and controlled at the system level of the electronic device, without requiring the support of third-party applications. Thus, given the numerous capability scenarios and established ecosystem and functional specifications of third-party applications, there is no need to communicate and coordinate with each third-party application developer individually. Third-party applications can still initiate a badge update request to the electronic device's system when responding to user actions to update badges. Upon receiving the request, the electronic device's system can determine whether to update the badge currently displayed by the third-party application based on the badge value that the third-party application needs to update. Furthermore, when the badge value that the third-party application needs to update is the same as the badge value currently displayed by the third-party application, the electronic device can choose not to update the badge of this third-party application. This avoids resource waste caused by updating the same badge to a certain extent, reducing system load and desktop load.

[0117] The method for updating superscripts according to embodiments of this application will now be described in conjunction with the hardware and software structures of the electronic device.

[0118] In some embodiments, electronic devices include, but are not limited to, mobile phones, portable Android devices (PADs), personal digital assistants (PDAs), handheld devices with wireless communication capabilities, computing devices, in-vehicle devices or wearable devices, virtual reality (VR) terminal devices, augmented reality (AR) terminal devices, wireless terminals in industrial control, wireless terminals in self-driving, wireless terminals in remote medical care, wireless terminals in smart homes, and other mobile or fixed terminals with touchscreens. The form of the electronic device is not specifically limited in the embodiments of this application.

[0119] Please see Figure 4 , Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application, such as... Figure 4As shown, the electronic device 100 may include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) connector 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, a headphone jack 170D, a sensor module 180, buttons 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a subscriber identification module (SIM) card interface 195, etc. The sensor module 180 may include a pressure sensor 180A, a gyroscope sensor 180B, a barometric pressure sensor 180C, a magnetic sensor 180D, an accelerometer sensor 180E, a distance sensor 180F, a proximity sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, a touch sensor 180K, an ambient light sensor 180L, a bone conduction sensor 180M, etc.

[0120] It is understood that the structures illustrated in the embodiments of the present invention do not constitute a specific limitation on the electronic device 100. In other embodiments of this application, the electronic device 100 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.

[0121] The processor 110 can generate operation control signals based on the instruction opcode and timing signals to control the instruction fetching and execution.

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

[0123] In some embodiments, the processor 110 compares the value of the stored index cache data with the index value to be updated. When the value of the stored index cache data and the index value to be updated are inconsistent, the index of the third-party application is updated according to the index value to be updated. When the value of the stored index cache data and the index value to be updated are consistent, the index of the third-party application is not updated.

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

[0125] The UART interface is a universal serial data bus used for asynchronous communication. This bus can be a bidirectional communication bus. It converts the data to be transmitted between serial and parallel communication. In some embodiments, the UART interface is typically used to connect the processor 110 and the wireless communication module 160.

[0126] The MIPI interface can be used to connect the processor 110 to peripheral devices such as the display 194 and the camera 193. The MIPI interface includes the camera serial interface (CSI) and the display serial interface (DSI).

[0127] In some embodiments, the processor 110 and the display screen 194 communicate via a DSI interface to realize the display function of the electronic device 100. For example, the processor controls the display screen 194 to display the application icon of the desktop application and add a badge to the application icon to indicate unread messages.

[0128] The wireless communication function of electronic device 100 can be realized through antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, modem processor and baseband processor, etc.

[0129] Antenna 1 and antenna 2 are used to transmit and receive electromagnetic wave signals. Each antenna in electronic device 100 can be used to cover one or more communication frequency bands. Different antennas can also be multiplexed to improve antenna utilization. For example, antenna 1 can be multiplexed as a diversity antenna for a wireless local area network. In some other embodiments, the antennas can be used in conjunction with tuning switches.

[0130] The wireless communication module 160 can provide solutions for wireless communication applications on the electronic device 100, including wireless local area networks (WLAN) (such as wireless fidelity (Wi-Fi) networks), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), infrared (IR) technology, etc.

[0131] Electronic device 100 implements display functions through a GPU, a display screen 194, and an application processor. The GPU is a microprocessor for image processing, connected to the display screen 194 and the application processor. The GPU is used to perform mathematical and geometric calculations and for graphics rendering. Processor 110 may include one or more GPUs, which execute program instructions to generate or modify display information.

[0132] In one embodiment, the processor 110 can control the display screen 194 to add a preset icon, such as a dot mark or a number, to a designated icon to remind the user of unread messages.

[0133] Internal memory 121 can be used to store executable program code, including instructions. Internal memory 121 may include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a function (such as sound playback, image playback, etc.), etc. The data storage area may store data created during the use of electronic device 100 (such as audio data, phonebook, etc.). Furthermore, internal memory 121 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, universal flash storage (UFS), etc. Processor 110 executes various functional applications and data processing of electronic device 100 by running instructions stored in internal memory 121 and / or instructions stored in memory located within the processor.

[0134] In one embodiment of this application, the internal memory 121 may store application index cache data. After the processor 110 updates the application index, it can store the index cache data corresponding to the updated index in the internal memory 121.

[0135] Pressure sensor 180A is used to sense pressure signals and convert them into electrical signals. In some embodiments, pressure sensor 180A can be disposed on display screen 194. There are many types of pressure sensors 180A, such as resistive pressure sensors, inductive pressure sensors, and capacitive pressure sensors. A capacitive pressure sensor may include at least two parallel plates with conductive material. When force is applied to pressure sensor 180A, the capacitance between the electrodes changes. Electronic device 100 determines the pressure intensity based on the change in capacitance. When a touch operation is applied to display screen 194, electronic device 100 detects the touch operation intensity based on pressure sensor 180A. Electronic device 100 can also calculate the touch position based on the detection signal from pressure sensor 180A. In some embodiments, touch operations applied to the same touch position but with different touch operation intensities can correspond to different operation commands.

[0136] In some embodiments, after a user presses or taps the display screen 194, the pressure sensor 180A senses the pressure signal applied by the user and converts the pressure signal into an electrical signal. This allows the processor 110 to trigger an update of the application badge or clear the corresponding invalid cache of the application based on the user's pressing action.

[0137] Touch sensor 180K, also known as a "touch device," can be located on display screen 194. The touch sensor 180K and display screen 194 together form a touchscreen, also known as a "touchscreen." Touch sensor 180K detects touch operations applied to or near it. The touch sensor can transmit the detected touch operation to the application processor to determine the type of touch event. Visual output related to the touch operation can be provided through display screen 194. In other embodiments, touch sensor 180K may also be located on the surface of electronic device 100, in a different position than display screen 194.

[0138] Please see Figure 5 , Figure 5 This is a software architecture block diagram of an electronic device provided in an embodiment of this application. The software system of the electronic device 100 can adopt a layered architecture, event-driven architecture, microkernel architecture, microservice architecture, or cloud architecture. For example, a layered architecture software system can be the Android system, the Harmony operating system (OS), or other software systems. This embodiment of the application uses the layered architecture Android system as an example to illustrate the software structure of the electronic device 100.

[0139] A layered architecture divides software into several layers, each with a clear role and function. Layers communicate with each other through software interfaces. In some embodiments, the Android system is divided into four layers, from top to bottom: the application layer, the application framework layer, the Android runtime and system libraries, and the kernel layer.

[0140] The application layer can include a series of application packages.

[0141] like Figure 5 As shown, the application package may include applications such as desktop, camera, WLAN, music, SMS, gallery, call, navigation, and Bluetooth. The applications in this application can also be replaced with other software such as mini-programs or atomic services. The applications in the embodiments of this application can also be replaced with other software such as mini-programs or atomic services.

[0142] A desktop, also known as a desktop application, is a computer's user interface displayed graphically. A graphical user interface (GUI) is a human-computer interaction format that allows users to manipulate icons or menu options on the screen using input devices such as a mouse to select commands, access files, launch programs, or perform other everyday tasks.

[0143] In some embodiments, the desktop also includes a ContentProvider component. The ContentProvider manages application data and allows data sharing between different applications. It provides a standardized interface that enables applications to perform CRUD operations on data.

[0144] In one possible implementation, the desktop uses a ContentProvider component to update the badges. For example, based on badge values ​​from third-party applications, the desktop uses the ContentProvider component to draw and update the badges of those third-party applications, ensuring that the updated badge numbers match the original badge values.

[0145] The application framework layer provides application programming interfaces (APIs) and programming frameworks for applications in the application layer. For example, the API includes symbolic interfaces. The application framework layer includes some predefined functions.

[0146] like Figure 5As shown, the application framework layer can include system framework and system services. System services include window manager, content provider, view system, phone manager, resource manager, notification manager, etc.

[0147] In some embodiments, the Android system of the electronic device 100 starts up and creates a system service (SystemServer) in the application framework layer. The services in the Android system reside in the SystemServer process. For example, system services such as Window Manager Server (WMS), Activity Manager System Service (AMS), and Package Manager Server (PMS) exist in the SystemServer process as threads.

[0148] In one possible implementation, SystemServer provides a service for storing badge cache data. For example, SystemServer receives updated badge cache data from the desktop and replaces the stored badge cache data with the updated data. Alternatively, the application framework layer reads badge cache data from SystemServer to determine whether the application's badges need to be updated.

[0149] In some embodiments, the system framework receives a first request from an application, wherein the first request requests an update to the application's badge. In response to the first request, the system framework retrieves cached badge data for the application from a system service. The system framework compares the cached badge data with the badge value to be updated. If the cached badge data and the badge value to be updated do not match, the system framework sends a request to the desktop to update the badge. If the cached badge data and the badge value to be updated match, the system framework does not update the application's badge.

[0150] The window manager is used to manage windowed applications. It can retrieve screen size, determine the presence of a status bar, lock the screen, and capture screenshots, among other things.

[0151] Content providers store and retrieve data, making that data accessible to applications. This data can include videos, images, audio, phone calls made and received, browsing history and bookmarks, phone books, and more.

[0152] In some embodiments, the content provider may store preset icons for badges. The preset icons may have shapes including, but not limited to, circles, squares, triangles, or rhombuses. The preset icons may be left blank or filled with a color, such as a striking color like red or orange, to allow users to more clearly observe badge changes and promptly view unread messages.

[0153] A view system includes visual controls, such as controls for displaying text and controls for displaying images. View systems can be used to build applications. A display interface can consist of one or more views. For example, a display interface including a text notification icon could include views for displaying text and views for displaying images.

[0154] In some embodiments, the desktop sends a notification to the view system to update the badge, and the view system displays the badge on the desktop icon, updates the number in the badge on the desktop icon, or removes the badge displayed on the desktop icon.

[0155] The file explorer provides applications with various resources, such as localized strings, icons, images, layout files, video files, and more.

[0156] The notification manager allows applications to display notifications in the status bar. These can be used to convey informational messages and can disappear automatically after a short pause, requiring no user interaction. For example, the notification manager is used for message reminders. The notification manager can also display notifications as icons or scrolling text in the top status bar, such as notifications from background applications, or as dialog boxes on the screen. Examples include displaying text messages in the status bar, emitting sounds, vibrating electronic devices, and flashing indicator lights.

[0157] 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.

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

[0159] In some embodiments, the surface manager is used to merge the layer corresponding to the preset icon with the layer corresponding to the desktop icon, so that the preset icon is displayed as a badge of the desktop icon.

[0160] 3D graphics processing libraries are used to implement 3D graphics drawing, image rendering, compositing, and layer processing. 2D graphics engines are drawing engines for 2D graphics.

[0161] The kernel layer is the layer between hardware and software. The kernel layer includes at least display drivers, camera drivers, audio drivers, and sensor drivers.

[0162] The following example, using a scenario of displaying updated badges, illustrates the workflow of the software and hardware of electronic device 100.

[0163] When the touch sensor 180K receives a touch operation, a corresponding hardware interrupt is sent to the kernel layer. The kernel layer processes the touch operation into a raw input event (including touch coordinates, timestamp of the touch operation, etc.). The raw input event is stored in the kernel layer. The application framework layer retrieves the raw input event from the kernel layer and identifies the control corresponding to the input event. Taking a touch click as an example, where the corresponding control is, for instance, an icon control of a third-party application on the desktop, the third-party application calls the interface of the application framework layer to retrieve the preset icon corresponding to the badge from the content provider, calls the view system to create a badge including the preset icon, and then calls the kernel layer to start the display driver, displaying the badge including the preset icon on the screen at the corresponding position of the third-party application's desktop icon.

[0164] The method for updating superscripts provided in the embodiments of this application will now be described in detail with reference to the accompanying drawings.

[0165] The method for updating badges provided in this application embodiment can be applied to applications with, for example, […]. Figure 4 The hardware structure shown and as Figure 5 In electronic devices with the software structure shown, or in electronic devices with more or fewer components than shown, or in electronic devices with combined or separated components, or in electronic devices with different component arrangements, etc., similar hardware and software structures.

[0166] Please see Figure 6 , Figure 6 This is a flowchart of updating a superscript provided in an embodiment of this application. The following will first combine... Figure 6 The exemplary flowchart shown illustrates the specific implementation of displaying badges on application icons in this application embodiment. Here, we will still use numerical badges as an example for explanation. Figure 6 As shown, the flowchart includes S601 to S608, which involve the first application, system framework, system services, and desktop (Launcher).

[0167] S601, the first application sends the first request to the system framework.

[0168] Specifically, the first application sends a first request to the system framework. The first application includes a third-party application, and the first request is used to request an update of the badge corresponding to the first application. For example, when the conditions for the first application to update its badge are triggered, the first application may send a first request to the system framework, requesting the system framework to update the badge corresponding to the first application. The conditions for triggering the first application to update its badge may include one or more of the following: launching the first application, switching the first application from foreground to background, switching the first application from background to foreground, switching pages in the first application's interface, switching pages in the first application's interface from other pages back to the main page, or browsing information in the first application, etc.

[0169] In one implementation, when the condition for the first application to update the badge is triggered, the first application sends a first request to the system framework by calling the call method.

[0170] The `call` method is a general method provided by the ContentProvider for handling specific requests or commands. Therefore, the first application can use the `call` method to pass complex operation requests to the ContentProvider. The ContentProvider is a component on the Android platform used to manage application data and allow data sharing between different applications. Furthermore, this embodiment uses the ContentProvider component to update the application's badge. Therefore, by calling the `call` method to send a first request to the system framework, the first application can enable the system framework to call the desktop ContentProvider component to update the badge of the first application.

[0171] S602, the system framework sends a second request to the system service.

[0172] For example, after receiving a first request from a first application, the system framework determines a second request based on the first request and sends the second request to the system service. The second request is used to read index cache data.

[0173] The first request carries one or more parameters, including: the target package name to be updated, the target component name to be updated, and the badge number to be updated. For example, these parameters can be carried in the first request as a Bundle data packet. After receiving the first request from the first application, the system framework can determine the information of the first application based on the one or more parameters carried in the first request. Then, the system framework carries the information of the first application in a second request. For example, the system framework determines the name of the first application based on the target package name to be updated in the first request, determines the desktop icon of the first application based on the target component name to be updated, and determines the number to be displayed on the badge of the first application, i.e., the number of unread messages in the first application, based on the badge number to be updated. Therefore, the information of the first application includes one or more of the following: the name of the first application and the desktop icon of the first application.

[0174] S603, the system service sends the first application's badge cache data to the system framework.

[0175] For example, based on the information of the first application carried in the second request (e.g., the name of the first application), the system service determines the badge cache data corresponding to the first application from the memory data, and sends the badge cache data corresponding to the first application to the system framework. The badge value in the badge cache data is consistent with the value displayed on the badge of the current first application. For example, after an electronic device updates its badge, the updated badge value can be stored as badge cache data in the system service. Therefore, the badge value of the badge cache data obtained by the system architecture from the system service is consistent with the value displayed on the badge of the first application.

[0176] In one possible implementation, the system framework is based on Figure 7 The steps shown retrieve the badge cache data corresponding to the first application from the system service. Figure 7 The steps shown are more detailed implementations of steps S602 and S603; for specific implementation details, please refer to [link to implementation details]. Figure 7 S6021-S6024.

[0177] Please see Figure 7 , Figure 7 This is a flowchart of reading a cache provided in an embodiment of this application, such as... Figure 7 As shown, the flowchart includes S6021 to S6024, as detailed below.

[0178] S6021, the system framework calls the first interface.

[0179] Specifically, after receiving the first request from the first application, the system framework can send a second request to the system service through the first interface. The first interface is used to read the corresponding badge cache data of the first application from the system service.

[0180] S6022, The system service determines the information of the first application.

[0181] Specifically, since the system service may store badge cache data corresponding to multiple applications, the system service can first determine the information of the first application, so that the badge cache data read based on the information of the first application is the data corresponding to the first application.

[0182] For example, a system service receives a second request from the system framework and determines information about the first application (e.g., the name of the first application) from one or more parameters carried in the second request.

[0183] S6023, the system service reads the index cache data.

[0184] For example, the system service of the electronic device reads the badge cache data corresponding to the first application from the memory data based on the information of the first application determined in S6022. The read badge cache data includes the value displayed in the badge of the current first application.

[0185] S6024, the system service sends badge cache data to the system framework.

[0186] For example, after reading the badge cache data of the first application, the system service of the electronic device can return the badge cache data to the system framework through the first interface.

[0187] It's understandable that if badge cache data is stored within an application, there's a risk of data inconsistency when badges are updated across applications. For example, when a second application calls a function of the first application, the second application might trigger a condition for the first application to update its badge. The second application can request the system to update the first application's badge, and simultaneously, the first application can send the badge value to be updated to the desktop, allowing the desktop to update the first application's badge based on this value. However, if the first application's badge cache data is stored within the first application, when the first application sends the badge value to be updated to the desktop, it might also send the stored badge cache data to the desktop. This would result in the badge value of the first application displayed on the desktop matching the value corresponding to the badge cache data, but not matching the badge value to be updated. When the badge cache data is stored in the system, the situation of the first application sending the badge cache data to the desktop doesn't occur. Therefore, the problem of inconsistency between the badge value of the first application displayed on the desktop and the badge value to be updated is avoided. This reduces the risk of data inconsistency when updating badges across applications and improves the stability and reliability of data storage.

[0188] In one possible implementation, if the system service does not have the badge cache data for the first application in S603, it means that the system service has not received the badge cache data for the first application, or the system service has cleared the badge cache data for the first application. In this case, the electronic device can directly execute S605 to draw the badge of the first application.

[0189] S604, the system framework determines whether the index value to be updated is consistent with the index cache data.

[0190] The badge value to be updated can be a parameter carried in the first request, representing the number of unread messages received by the first application, which is also the value to be displayed on the badge of the first application. The badge cache data is data obtained from the system service by the system framework according to step S603, and the badge value stored in the badge cache data is used to represent the value of the current badge of the first application.

[0191] Specifically, the system framework compares the index value to be updated with the index value stored in the index cache data.

[0192] For example, when the value of the badge to be updated is inconsistent with the stored value, it indicates that the value displayed on the badge of the current first application is inconsistent with the value of the badge to be updated. This can further be explained by the fact that from the time the electronic device draws the badge of the current first application until the system framework receives the first request, the first application receives a new message, or the user clicks on or reads an unread message of the first application, changing the number of unread messages. The system framework needs to update the badge of the first application by executing step S605.

[0193] For example, when the value of the badge to be updated matches the stored value, it means that the value displayed on the badge of the current first application is consistent with the value of the badge to be updated. This further indicates that from the time the electronic device draws the badge of the current first application until the system framework receives the first request, the first application has not received any new messages, and the user has not clicked or read any unread messages in the first application; therefore, the number of unread messages in the first application remains unchanged. The electronic device can end the process without having to draw the same numerical badge for the first application again. This avoids the resource waste caused by the electronic device repeatedly drawing the same numerical badge, reducing system load and desktop load.

[0194] In one possible implementation, since the index cache data needs to be read from the system service's memory data, to facilitate the application of the index cache data by other modules in the system framework, the system framework can return the data to the system framework's cache. That is, the system framework updates the index cache data of the first application as a cache in the cache. When other modules in the system framework need the index cache data of the first application, they can read it directly from the cache without requesting it from the system service again.

[0195] S605, the system framework sends a third request to the desktop.

[0196] For example, if the value of the badge to be updated is inconsistent with the value of the stored badge, it means that the value displayed on the badge of the current first application is inconsistent with the value of the badge to be updated. Furthermore, from the time the electronic device draws the badge of the current first application to the time the system framework receives the first request, the first application receives a new message, or the user clicks or reads the unread message of the first application, and the number of unread messages of the first application changes. The electronic device needs to redraw the digital badge for the first application according to the value of the badge to be updated.

[0197] Specifically, the system framework sends a third request to the desktop, which requests the invocation of a component on the desktop used to update badges to update the badge of the first application. In one possible implementation, the component used to update badges can be a content provider component. The desktop can update the badge of the first application according to step S606 via the content provider component.

[0198] The ContentProvider component is responsible for sharing data, allowing other applications to access and modify it. It provides a standardized interface that allows other applications to access and modify data within an application. Because multiple applications installed on an electronic device run in independent processes, and these processes generally cannot communicate directly, application data cannot be directly shared with other applications, hindering the implementation of various application functionalities. Therefore, the ContentProvider component enables data exchange between multiple applications on an electronic device, allowing the device to update application badges.

[0199] S606, the badge of the first application to update on the desktop.

[0200] For example, the desktop updates the badge of the first application based on the badge value to be updated. This badge value can be a parameter carried in the first request. Since the first request may carry one or more parameters, the desktop can determine the badge value to be updated from these parameters using the ContentProvider component. Then, the desktop draws the badge of the first application based on the badge value to be updated.

[0201] In one possible implementation, the desktop invokes the badge update function by calling a second interface. Then, the desktop sets badge parameters based on the badge update function, thereby updating the badge of the first application. The second interface can be the badge update interface. For example, if the badge value to be updated is "3", then the badge parameter set above is "3", so that the value in the drawn badge of the first application is also "3".

[0202] S607, the desktop sends a fourth request to the system service.

[0203] For example, after updating the badge of the first application, the desktop also needs to store the updated badge value in the system service so that the first application can use it the next time it updates the badge. Therefore, the desktop sends a fourth request to the system service to request the system service to update the badge cache data of the first application. Specifically, the fourth request is a request to update the badge cache data of the first application.

[0204] S608, System service updates the badge cache data of the first application.

[0205] For example, after receiving the fourth request, the system service invokes the function to update the badge cache data by calling the third interface, thereby updating the badge cache data of the first application. The third interface is the badge cache refresh interface; for details on how the system service updates the badge cache data, please refer to [link to relevant documentation]. Figure 8 The steps S6081 to S6083 are shown.

[0206] Please see Figure 8 , Figure 8 This is a flowchart illustrating an embodiment of updating badge cache data provided in this application. For example... Figure 8 As shown, the flowchart includes S6081 to S6083, as detailed below.

[0207] S6081, the third interface receives a fourth request from the desktop. The system services of the electronic device can receive a fourth request from the desktop (Launcher) through the third interface, namely a request to update the badge cache data of the first application.

[0208] S6082, the system service updates the badge cache data. The third interface receives the fourth request, and the system service can invoke the function to update the badge cache data by calling the third interface. For example, if the badge value corresponding to the currently stored badge cache value of the first application in the system service is "1", and the updated badge value of the first application is "3", then the system service can invoke the function to update the badge cache data by calling the third interface, thereby updating the badge value corresponding to the first application in the badge cache data from "1" to "3".

[0209] S6083, after the permission check is passed, the system service stores the badge cache data of the first application. To ensure the security of data storage, the system service can store the badge cache data of the first application after the permission check of the corresponding operation in step S6082 is passed.

[0210] The above embodiments describe a method for updating subscripts in an electronic device. It can be seen that before updating the subscripts, the electronic device can determine whether an update is needed based on stored subscript cache data. After updating the subscripts, the electronic device can replace the stored subscript cache data with the subscript value corresponding to the updated subscript. Therefore, storing subscript cache data plays a significant role in this embodiment. To ensure the accuracy of the subscript cache data and reduce the probability of dirty data...

[0211] The following will introduce specific implementation examples of clearing invalid cache through several scenarios. It should be understood that the clearing of invalid cache by electronic devices is not limited to the following scenarios, and is not limited here.

[0212] Scenario 1: Users clean up data from third-party applications via their desktop.

[0213] When using third-party applications, users can manually clear the application's data via the desktop. Therefore, in response to the user's action, the electronic device 100 deletes the badge database used to store badge data from the desktop. The electronic device 100 also clears the badges of the third-party applications from the desktop. Therefore, after the user clears the data of third-party applications via the desktop, the badges on the third-party applications are not displayed. Simultaneously, after the user clears the data of third-party applications via the desktop, the badge cache data stored in the system services of the third-party applications becomes invalid, and the electronic device accordingly clears the badge cache data corresponding to the third-party applications.

[0214] For example, please refer to Figure 9 , Figure 9 This is a schematic diagram illustrating a method of cleaning up data via the desktop, as provided in an embodiment of this application. Figure 9 As shown in (a), the user interface 901 of the electronic device 100 includes a first badge 9011, a status bar 9012, a page indicator 9013, and multiple application icons. The icons of third-party applications display the first badge 9011, which indicates the first number of unread messages. For example, the first badge 9011 includes an "○" in the upper right corner of the third-party application's desktop icon and the number "3" inside it, indicating that the first number of unread messages is 3.

[0215] The status bar 9012 may include one or more signal strength indicators for mobile communication signals (also known as cellular signals) such as 5G, Wi-Fi signal strength indicators, battery status indicators, time indicators (e.g., 8:00), etc.

[0216] Page indicator 9013 can be used to indicate the positional relationship between the currently displayed page and other pages.

[0217] Multiple application icons may include time application icons (e.g., 08:00), date application icons (e.g., Friday, January 1st), weather application icons (e.g., 5℃), app store application icons, memo application icons, shopping mall application icons, browser application icons, phone application icons, messaging application icons, camera application icons, settings application icons, etc. In addition to the above icons, the user interface 901 may also include other application icons, which will not be listed here. Multiple application icons may be distributed across multiple pages. The page indicator 9013 can be used to indicate which of the multiple pages hosting the multiple applications the user is currently viewing. Users can browse other pages using left and right swipe touch operations.

[0218] When the user clicks Figure 9 When the user clicks the icon of the third-party application in the user interface 901 shown in (a), the electronic device 100 switches from the desktop to the interface of the third-party application in response to the user's click operation, displaying as shown in (a). Figure 9 User interface 902 is shown in (b).

[0219] exist Figure 9 User interface 902, shown in (b), includes a status bar 9012 and specific information on a settings page. The settings page includes controls for editing profiles, account and security, and clearing the cache. Specifically, the clear cache control in user interface 902 displays that the cache of electronic device 100 is 260MB. User interface 902 may also include other settings page information, which will not be listed here.

[0220] When the user clicks Figure 9 When the cache clearing control in the user interface 902 shown in (c) is invoked, the electronic device 100, in response to the user's motor operation, clears the desktop cache of the third-party application. In response to the user's back operation, the electronic device 100 returns from the user interface 902 of the third-party application to the desktop, displaying... Figure 9 The user interface 903 is shown in (d).

[0221] like Figure 9 As shown in (d), the user interface 903 includes a status bar 9012, a page indicator 9013, and multiple application icons. The status bar 9012, page indicator 9013, and multiple application icons can be found in [reference needed]. Figure 9 The specific description in (a). For example... Figure 9 As shown in (d), the badge is no longer displayed on the third-party application. Therefore, the electronic device 100 clears the badge of the third-party application in response to the user's operation of clearing the cache of the third-party application via the desktop.

[0222] In one possible implementation, if a user clears the data (e.g., cache) of a third-party application via the desktop, the badge cache data corresponding to the third-party application stored in the system service will become invalid cache, and the electronic device can clear the aforementioned invalid cache.

[0223] Specifically, electronic devices can access a third interface of the system service via the desktop to clear the invalid cache of the aforementioned third applications within the system service. This third interface is the refresh badge cache interface. For details on how electronic devices can use this third interface to clear invalid caches, please refer to [link to relevant documentation]. Figure 10 .

[0224] Please see Figure 10 , Figure 10 This is a schematic diagram illustrating a method for clearing expired cache provided in an embodiment of this application. For example... Figure 10 As shown, the flowchart includes S1001 to S1005, involving a first application, system services, and a desktop (Launcher). The first application can be a third-party application installed on an electronic device.

[0225] S1001, the user clears the data of the first application. The user can then... Figure 9 The method shown clears the data of the first application via the desktop.

[0226] S1002, the desktop deletes the badge database of the first application and the cache of the first application on the desktop. For example, in response to the user's operation of clearing the data of the first application, the desktop deletes the badge database of the first application and the cache of the first application on the desktop. In response to the user's operation of clearing the data of the first application, the desktop removes the badge from the first application icon. Therefore, after the user clears the data of the first application, the badge is not displayed on the first application.

[0227] S1003, the desktop sends a request to the third interface to update the badge cache data. After deleting the badge database of the first application and the cache of the first application on the desktop, the desktop can send a request to the third interface to update the badge cache data of the first application.

[0228] S1004, the system service updates the badge cache data. After receiving a request to update the badge cache data of the first application, the system service can update the cache through a third interface. For example, if the badge cache data stored in the system service includes the package name of the first application, then the system service can determine the badge cache data corresponding to the first application from the cache using the package name of the first application. Then, the system service deletes the badge cache data corresponding to the first application from the cache through the third interface, thereby clearing the invalid cache of the first application.

[0229] S1005: After the system service passes the permission check, it updates the badge cache data of the first application. To ensure data storage security, after the system service passes the permission check for the operation in S1004, it can delete the expired cache of the first application.

[0230] Scenario 2: Uninstalling the application.

[0231] For example, when a user interacts with the icon of a third-party application on the home screen of an electronic device (e.g., long-presses it), the device displays a function card with an "Uninstall" control (i.e., a control to uninstall the application). The user can then uninstall the third-party application by interacting with the "Uninstall" control (e.g., clicking it).

[0232] After a third-party application is uninstalled, its cache in the system becomes invalid. Therefore, the badge cache data stored in system services for the third-party application is also invalid. To avoid invalid data consuming memory space, electronic devices can clear the invalid cache after uninstalling a third-party application; that is, the electronic device deletes the badge cache data corresponding to the third-party application through system services.

[0233] The following will combine Figure 11 This paper introduces specific implementation methods for clearing invalid caches in electronic devices.

[0234] Please see Figure 11 , Figure 11 This is a schematic diagram illustrating another method for clearing invalid cache provided in an embodiment of this application. For example... Figure 11 As shown, the electronic device's system can receive broadcasts about uninstalling applications, such as those generated when uninstalling a third-party application, by registering a broadcast listener. Then, based on the uninstallation broadcast, the system identifies the application being uninstalled and clears the corresponding invalid cache in the electronic device's system services. Because the invalid cache includes badge cache data, the electronic device also clears the badge cache data corresponding to the uninstalled application.

[0235] For example, when a user uninstalls a first application, the electronic device receives a broadcast notification that the first application has been uninstalled. The device then checks the system service cache for the corresponding cached data based on this broadcast. The electronic device can then delete this cached data to clear expired cache entries.

[0236] Scenario 3: Electronic devices receive a data cleanup broadcast.

[0237] In one implementation, the electronic device's system receives data cleanup broadcasts by registering to listen for broadcasts. The electronic device then cleans up invalid caches based on the data cleanup broadcasts. These data cleanup broadcasts can be for clearing desktop data, clearing other data, etc., and are not limited here.

[0238] For example, if multiple application icons on the desktop display badges, clicking the clear data control in the desktop sidebar can trigger the electronic device to clear the desktop data. This removes the badges from the application icons. Therefore, an electronic device can clear application icon badges by clearing desktop data. For example, the electronic device, in response to the user or other applications installed on the device, can call the clearuser API to clear desktop data, thereby removing the badges from application icons.

[0239] When an application's badge is cleared, the application's badge cache data stored in system services becomes invalid cache. This will be discussed further below. Figure 11 This section will introduce the specific implementation method for clearing invalid caches from electronic devices in scenario 3.

[0240] like Figure 11 As shown, the electronic device's system can receive data cleanup broadcasts, such as those generated for cleaning desktop data, by registering to listen for broadcasts. Then, based on the data cleanup broadcast, it identifies invalid caches and cleans the corresponding invalid caches in the electronic device's system services. Because invalid caches include indexed cache data, the electronic device also cleans the indexed cache data corresponding to the data cleanup broadcast.

[0241] For example, an electronic device clears the desktop data of applications one, two, and three. The system service receives the corresponding data clearing broadcast. Based on this broadcast, the electronic device uses the system service to retrieve the corresponding index cache data for applications one, two, and three from its cache. Then, the electronic device can delete the corresponding index cache data for these applications, thus clearing the invalid cache.

[0242] Scenario 4: The electronic device receives a user's delete broadcast.

[0243] In one implementation, the electronic device includes a multi-user scenario, meaning the device can provide multiple desktop applications to users by setting up multiple user accounts. For example, the electronic device includes a first user and a second user. The first user is the system's primary user, corresponding to the first desktop, and is allowed to install, use, and uninstall applications on the first desktop. The second user is the system's sub-user, corresponding to the second desktop, and is allowed to install, use, and uninstall applications on the second desktop. Therefore, the first and second desktops can provide services independently and are independent processes.

[0244] When a user deletes a sub-user account, the electronic device receives a user deletion broadcast. The device then clears its invalid cache based on this broadcast. For example, a sub-user might include a second application. When a user deletes a sub-user account, a user deletion broadcast is generated, and the electronic device will correspondingly delete the second application under that sub-user. Therefore, the badge cache data stored in the system services for the second application is considered invalid cache, and the electronic device can clear this invalid cache based on the user deletion broadcast.

[0245] The following will continue to combine Figure 11 This section will introduce the specific implementation method for clearing invalid caches from electronic devices in scenario 4.

[0246] like Figure 11 As shown, the electronic device's system can receive user deletion broadcasts by registering to listen for broadcasts, such as the broadcast generated when a user deletes a sub-user account. Then, based on the user deletion broadcast, the system determines the invalidation cache and clears the corresponding invalidation cache in the electronic device's system services. Because the invalidation cache includes badge cache data, the electronic device also clears the badge cache data corresponding to the user deletion broadcast.

[0247] For example, when a user deletes a sub-user account, the electronic device responds by generating a deletion broadcast. This sub-user includes a second application and a third application. The electronic device then determines the corresponding badge cache data for the second and third applications based on the system service cache of the deletion broadcast. The electronic device can then delete the corresponding badge cache data for the second and third applications to clear the expired cache.

[0248] Please see Figure 12 , Figure 12 This is another flowchart for updating superscripts provided in an embodiment of this application. For example... Figure 12 As shown, the flowchart includes S1201 to S1204. The specific steps are as follows:

[0249] S1201, the first application sends the first request to the system framework.

[0250] When the conditions for the first application to update its badge are triggered, the first application can send a first request to the system framework. The first application may include a third-party application, and the first request is a request to update the badge.

[0251] The ContentResolver is a system service used to access and manipulate data provided by other applications. It provides a unified interface that allows applications to share data without directly depending on each other. It allows applications to access various types of data, including data from content providers, files, databases, etc. Therefore, an application can use a content provider through the ContentResolver.

[0252] S1202, the system framework reads the index cache data.

[0253] For example, when the system framework receives a request to update the badge of a first application, it can read the badge cache data of the first application from the information that has already been set. This already set information can be information that the desktop has already set for the application. For instance, the information that the desktop has already set for the application includes the application's badge information, which is stored in a system service as badge cache data. Therefore, the system framework can read the badge cache data from the already set information.

[0254] For example, the information already set may include one or more of the following: the application's package name, the application's component name, and the application's index value. The information already set may be written after the index is updated, and the system framework can read the stored index value from the information already set based on the first application's package name or component name.

[0255] S1203, the system framework determines whether the index value to be updated is consistent with the stored index value.

[0256] The badge value to be updated can be a parameter carried in the first request, used to represent the number of unread messages received by the first application, that is, the value that needs to be displayed on the badge of the first application. The stored badge value is data read from the information that has been set according to step S1202 by the system framework, and the stored badge value is used to represent the value in the current badge of the first application.

[0257] When the value of the index to be updated matches the value of the current index, the electronic device can avoid redrawing the same index, thus reducing system load. Therefore, the system framework reads the index value of the first application from the pre-set information. Then it determines whether the value of the index to be updated matches the value of the current index.

[0258] For example, if the system framework determines that the value of the index to be updated is the same as the current index value, the electronic device does not need to set the index parameter again, and the electronic device can end the process. This avoids the waste of resources caused by repeatedly drawing the same index, and reduces system load and desktop load.

[0259] For example, if the system framework determines that the value of the index to be updated is inconsistent with the value of the current index, then the index of the first application needs to be updated, and S1204 is executed.

[0260] S1204, Update the badge of the first application. Step S1204 may include... Figure 3 As shown in steps S301-S310, the electronic device can update the badge of the first application according to steps S301-S310. See details... Figure 3 Specific implementation details are omitted here.

[0261] It should be noted that, Figure 12 The steps described are the same as Figure 3 Compared to the steps described above, Figure 12 Before updating the badge, a check was performed to determine whether the badge needed to be updated. See details below. Figure 12 The steps corresponding to S1201 to S1203. Called by a third-party application. Figure 1 Following the indicated sub-label interface, in the existing solution, the electronic device will follow... Figure 3 The steps shown are for updating the badge of a third-party application. However, the timing of triggering a third-party application to call the badge interface depends on the business design of the third-party application itself. Therefore, there may be situations where a third-party application repeatedly calls the interface to make the same badge appear on the desktop.

[0262] According to the embodiments of this application (e.g.) Figure 12 As shown in S1201 to S1203, upon receiving a badge update request from a third-party application, the system does not update the badge directly. Instead, it first determines whether the badge value to be updated is the same as the current badge value of the third-party application. If they are the same, the badge is not updated; otherwise, the update is performed. This solves the problem of third-party applications repeatedly calling the interface to make the system draw the same badge, reducing the load on the system and desktop.

[0263] The following section will describe the load and revenue when updating badges, using a specific testing process as an example.

[0264] The specific testing steps are as follows:

[0265] 1. Restart the device. Turning the phone off and then on again can close processes and free up some memory, reducing interference factors during testing.

[0266] 2. Open the first application. Open the application you want to test, such as the first application, which is a third-party application installed on your phone. When the first application launches, it will trigger the conditions for the first application to call the badge API to update the badge.

[0267] 3. Click to enter any page, stay for 5 seconds, and then return. Clicking to enter any page of the first application is equivalent to switching the interface of the first application. When switching the interface of the first application, it can trigger the first application to call the badge interface to update the badge.

[0268] 4. Repeat step 3 three times. To ensure the accuracy of the test results, the operation can be repeated multiple times.

[0269] For example, if the electronic device's system is based on an existing scheme (e.g. Figure 3 Following the steps shown, without determining whether the badge needs updating, the badge of the first application is updated directly. The load and revenue calculated based on the above test steps are as follows:

[0270] 1. Each time the page of the first application is switched, the application badge capabilities related to business operations are enabled, resulting in a load of approximately 70% (of which, desktop load is about 31%), while the actual business load of the first application is only about 22.84%. Therefore, the existing solution will generate a significant system load and desktop load.

[0271] 2. The load and benefits caused by updating the badge can be completely eliminated. If no new logic is added, the load caused by updating the badge is between 60% and 70%. Therefore, the existing solution will result in a large load and low benefits.

[0272] For example, if the electronic device's system follows the method provided in the embodiments of this application (e.g. Figure 12 (As shown in the steps), first determine whether the badge needs to be updated. If it does, update the badge of the first application; otherwise, do not update the badge of the first application. Then, during use, the system load (system processes and desktop applications) will decrease, and the benefit calculated based on the above testing steps is 60%-70%.

[0273] In one possible implementation, if the electronic device's system follows the method provided in the embodiments of this application (e.g.) Figure 12 Follow the steps shown to update the subscript. Then, Figure 3 The loads of S302, S303, S305, S306, S307, S309 and S310 can all be reduced.

[0274] Therefore, in summary, the method provided by the embodiments of this application can reduce the load during use and increase the benefits during use.

[0275] Please see Figure 13 , Figure 13 This is a schematic flowchart illustrating a method for updating superscript markers provided in an embodiment of this application. This method can be applied to... Figure 4 The electronic device 100 shown and Figure 5 The electronic device 100 shown. The method includes, but is not limited to, the following steps:

[0276] Step S1301: The electronic device responds to the first user's operation and determines the first value and the second value.

[0277] In one implementation, the first user action is used to trigger a condition for updating the application's badge, such as the condition for triggering the first application to update its badge in step S601.

[0278] Specifically, the first user operation includes one or more of the following: launching the application, switching the application from foreground to background, switching the application from background to foreground, switching pages in the application interface, switching pages from other pages back to the main page in the application interface, and browsing information in the application interface.

[0279] In one implementation, the first value is used to represent the number displayed by the subscript, such as the value corresponding to the subscript cache data in step S603.

[0280] In one implementation, the second value is used to represent the number of unread messages in the application, such as the index value to be updated in step S602.

[0281] In one possible implementation, the electronic device, in response to a first user operation, determines a first value based on index cache data stored in the memory data of a system service. The electronic device then determines a second value from the number of unread messages retrieved by the application.

[0282] Specifically, the first value can be determined by the electronic device from the badge cache data stored in the system service. For example, in step S603, the system service determines the badge cache data corresponding to the first application from the memory data. The second value can be determined by the electronic device from the number of unread messages obtained from the application. For example, in step S602, the first request from the first application carries a badge value to be updated, and the system framework determines the number to be displayed on the badge of the first application based on the badge value to be updated.

[0283] Step S1302: When the first value and the second value are inconsistent, the electronic device updates the first value displayed by the badge to the second value. For example, in step S604, when the system framework determines that the badge value to be updated is inconsistent with the stored badge value, it executes S605 to update the badge of the first application based on the badge value to be updated.

[0284] In one implementation, after the electronic device updates the first value displayed by the badge to a second value, the second value is stored in the memory data of the system service. For example, in step S608, the system service updates the badge cache data of the first application.

[0285] In one possible implementation, after the electronic device determines the first and second values ​​in response to the first user's operation, it may not update the application's badge if it determines that the first and second values ​​are consistent. For example, in step S604, when the badge value to be updated is consistent with the stored badge value, the electronic device can end the process.

[0286] In one possible implementation, the electronic device, in response to a second user operation on the application, deletes the application's corresponding badge cache data from the system service's memory data. For example, this could be scenario 1, scenario 2, scenario 3, and scenario 4, where the electronic device clears expired cache. The electronic device deleting the application's corresponding badge cache data could be, for example,... Figure 11 The corresponding expired cache in the electronic device cleanup system service.

[0287] The second user operation includes one or more of the following: clearing data in the application (e.g., scenario 1 or scenario 3), uninstalling the application (e.g., scenario 2), and deleting the user account (e.g., scenario 4). The user account corresponds to the user's desktop, and the application is installed on the user's desktop.

[0288] It should be understood that the steps in the above-described method embodiments provided in this application can be implemented by integrated logic circuits in the processor hardware or by instructions in software form. The method steps disclosed in the embodiments of this application can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules in the processor.

[0289] This application also provides an electronic device that may include a memory and a processor. The memory may be used to store a computer program; the processor may be used to invoke the computer program in the memory to cause the electronic device to perform the methods in any of the above embodiments.

[0290] This application also provides a chip system including at least one processor for implementing the functions involved in the methods performed by the electronic device in any of the above embodiments.

[0291] In one possible design, the chip system also includes a memory for storing program instructions and data, which may be located within or outside the processor.

[0292] The chip system can consist of chips or include chips and other discrete components.

[0293] Optionally, the chip system may contain one or more processors. These processors can be implemented in hardware or software. When implemented in hardware, the processor can be a logic circuit, an integrated circuit, etc. When implemented in software, the processor can be a general-purpose processor, implemented by reading software code stored in memory.

[0294] Optionally, the chip system may contain one or more memories. The memory may be integrated with the processor or disposed separately from it; this application embodiment does not limit this. For example, the memory may be a non-transient processor, such as a read-only memory (ROM), which may be integrated with the processor on the same chip or disposed separately on different chips. This application embodiment does not specifically limit the type of memory or the arrangement of the memory and processor.

[0295] For example, the chip system may be a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), a system on chip (SoC), a central processor unit (CPU), a network processor (NP), a digital signal processor (DSP), a micro controller unit (MCU), a programmable logic device (PLD), or other integrated chips.

[0296] This application also provides a computer program product comprising: a computer program (also referred to as code or instructions) that, when run, causes a computer to perform the method executed by the electronic device in any of the above embodiments.

[0297] This application also provides a computer-readable storage medium storing a computer program (also referred to as code or instructions). When the computer program is run, it causes the computer to perform the method executed by the electronic device in any of the above embodiments.

[0298] The various embodiments of this application can be combined arbitrarily to achieve different technical effects.

[0299] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive).

[0300] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This program can be stored in a computer-readable storage medium, and when executed, it can include the processes described in the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM or random access memory (RAM), magnetic disks, or optical disks.

[0301] In summary, the above description is merely an embodiment of the technical solution of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made according to the disclosure of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for updating superscripts, characterized in that, The method is applied to an electronic device, which includes applications, system frameworks, system services, and a desktop. The method includes: In response to a first user operation, the system framework of the electronic device receives a first request from an application, wherein the first user operation is used to trigger a condition for updating the application's badge, and the first user operation includes one or more of the following: launching the application, switching the application from foreground to background, switching the application from background to foreground, switching pages in the application interface, switching pages from other pages back to the main page in the application interface, and browsing information in the application interface. The first request carries one or more parameters, including: a target package name to be updated and a badge value to be updated, wherein the target package name to be updated is used to determine the name of the application, and the badge value to be updated is used to determine the number of unread messages in the application. The system framework determines a second request based on the first request and sends the second request to the system service, the second request carrying the name of the application; The system service reads the corresponding badge cache data from the memory data based on the application name carried in the second request, and sends the badge cache data to the system framework layer. ， The index values ​​in the index cache data are consistent with the values ​​displayed on the indexes of the application. The system framework layer determines a first value based on the badge cache data and a second value based on the number of unread messages in the application. When the first value and the second value are inconsistent, the system framework sends a third request to the desktop to call the content provider component to update the first value displayed by the badge to the second value; After the desktop updates the application's badge, the desktop sends a fourth request to the system service to store the second value in the system service's memory data to update the application's badge cache data; When the first value and the second value are the same, the system framework does not update the application's badge.

2. The method according to claim 1, characterized in that, The method further includes: In response to a second user action on the application, the badge cache data corresponding to the application is deleted from the memory data of the system service.

3. The method according to claim 2, characterized in that, The second user operation includes one or more of the following: clearing data in the application, uninstalling the application, and deleting the user account, wherein the user account corresponds to the user desktop, and the application is installed on the user desktop.

4. An electronic device, characterized in that, The electronic device includes: one or more processors and one or more memories; wherein the one or more memories are coupled to the one or more processors, the one or more memories are used to store computer program code, the computer program code including computer instructions, and the one or more processors call the computer instructions to cause the electronic device to perform the method as described in any one of claims 1-3.

5. A chip system, characterized in that, The chip system is applied to an electronic device, the chip system including one or more processors, the processors being used to invoke computer instructions to cause the electronic device to perform the method as described in any one of claims 1-3.

6. A computer program product containing instructions, characterized in that, When the computer program product is run on an electronic device, it causes the electronic device to perform the method as described in any one of claims 1-3.

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

Images