Scoring method, device, and storage medium

Abstract

The application discloses a dotting method, device and storage medium, and belongs to the computer field. The method comprises the following steps: in the case that a preset dotting event (a business fault occurs or a preset user behavior occurs) occurs in the running of a terminal device, event information of the preset dotting event is acquired. The event information is searched in preset preset dotting configuration information to find a dotting strategy corresponding to an event identifier in the event information, the dotting strategy comprising at least one of a first dotting strategy for limiting the number of the event information and a second dotting strategy for filtering event information that does not meet safety requirements. Then, the event information is checked to obtain a checking result. The event information is stored according to the checking result, and dotting is completed. Compared with the technical solution of dotting all event information, the number of dotting is reduced, and the power consumption of the terminal device is reduced. Moreover, through the dotting checking, the occupation of the storage space is reduced, more dotting data is obtained, and the comprehensiveness of the dotting data is improved.

Description

Technical Field

[0001] This application relates to the field of computers, and in particular to a dot-marking method, apparatus and storage medium. Background Technology

[0002] With the rapid development of communication and terminal technologies, users frequently operate their terminal devices, such as opening or closing applications, deleting notification messages, powering on, and powering off. They also encounter various problems, such as black screens, device freezes, application lag, abnormal device or application startup, application crashes, application outages, and network anomalies. To improve terminal device performance, a point-based system can be used to collect and store information on these user behaviors and business failures for subsequent analysis and optimization.

[0003] Currently, the business systems of terminal devices can pre-embed event tracking based on their own business logic, targeting potential business failures and user behaviors. This allows them to detect whether preset events (business failures or user behaviors) occur during process execution. Subsequently, once a preset event occurs, the terminal device can call the tracking framework's interface to collect event information related to the event and store it, thus completing the tracking of business failures or user behaviors (also known as event instrumentation).

[0004] However, as the number of business data points increases, the load and power consumption of terminal devices also increase. Moreover, due to the limited storage space and processing capabilities of each processing stage on the terminal devices, if a certain process has a large amount of data points, it will cause the loss of other data points, resulting in incomplete data points. Summary of the Invention

[0005] This application provides a data logging method, device, and storage medium, which can reduce the power consumption of terminal devices and improve the comprehensiveness of logged data. The technical solution is as follows:

[0006] Firstly, a point-tracking method is provided. This method includes: when a preset point-tracking event (business failure or preset user behavior) occurs during terminal device operation, acquiring event information of the preset point-tracking event, the event information including an event identifier. Pre-set preset point-tracking configuration information includes point-tracking policies for multiple event identifiers, with a one-to-one correspondence between event identifiers and point-tracking policies. Each point-tracking policy includes at least one of a first point-tracking policy for limiting the number of event information entries and a second point-tracking policy for filtering event information that does not meet security requirements, thereby achieving a lightweight point-tracking mode. The method involves searching the preset point-tracking configuration information for the point-tracking policy corresponding to the event identifier of the current event, verifying the event information, and obtaining a verification result. Based on the verification result, the event information is stored to obtain point-tracking data, thus completing the point-tracking of the event information.

[0007] Compared to technical solutions that record all event information, this application's embodiment achieves event tracking rate limiting through quantity restrictions and security filtering verification processes, reducing the number of events recorded and lowering the power consumption of terminal devices. By limiting the number of events recorded and implementing security filtering, storage space usage is reduced, allowing for the statistical analysis of business faults or user behaviors in more processes or areas, thus improving the comprehensiveness of the event tracking data. This simultaneously achieves the technical goals of problem localization and business improvement statistics.

[0008] In one possible implementation, before validating the event information, it can be first determined whether the current process containing the preset event meets the event limiting policy. That is, it can be determined whether the number of events performed by the current process containing the preset event within a preset time does not exceed the process limit. If yes, the event information is then validated. If not, the event information is discarded, meaning it is not stored.

[0009] In one possible implementation, when validating event information, it can be determined whether the current process containing the preset event meets the event limiting policy. Specifically, it can be determined whether the number of events recorded by the current process within the preset duration does not exceed the process limit. If so, the event information can be stored to complete the event recording; or further validation can be performed on the event information. If not, the event information is discarded, meaning it is not stored.

[0010] By limiting the number of event information on a single process, a lightweight event tracking mode is achieved, reducing the power consumption of terminal devices. This allows for the tracking of business failures or user behaviors in more processes or more areas, improving the accuracy and richness of event tracking data.

[0011] In one possible implementation, the first tracking strategy includes at least one of the following: tracking upper limit, sampling control strategy, tracking termination time, and tracking rate limiting strategy; the second tracking strategy includes at least one of the following: tracking level, and preset information of each object in the business or behavior.

[0012] For business failure types, at least one of the following is used to verify the event information: the upper limit of the event marker corresponding to the event identifier, the sampling control strategy, the event termination time, the event rate limiting strategy, the event level, and the preset information of each object in the business. For user behavior types, at least one of the following is used to verify the event information: the upper limit of the event marker corresponding to the event identifier, the sampling control strategy, the event termination time, the event rate limiting strategy, the event level, and the preset information of each object in the behavior. By setting multiple verification methods, in practical applications, verification can be combined according to the settings of the event markers, improving the flexibility of the verification methods.

[0013] In one possible implementation, the event information includes a tracking type, which is either a business failure type or a user behavior type. The aforementioned tracking upper limit includes a failure tracking upper limit within a first preset period and a behavior tracking upper limit within a second preset period. For business failure types, it is determined whether the number of tracking points for the business failure type within the first preset period is less than or equal to the failure tracking upper limit. If so, the event information can be stored to complete the tracking of the business failure; or further verification can be performed on the event information. If not, the event information is discarded, meaning it is not stored. For user behavior types, it is determined whether the number of tracking points for the user behavior type within the second preset period is less than or equal to the behavior tracking upper limit. If so, the event information can be stored to complete the tracking of the user behavior; or further verification can be performed on the event information. If not, the event information is discarded, meaning it is not stored.

[0014] For the data tracking types, business fault types and user behavior types are subject to separate quantity limits. This balances the quantity of different data tracking types within limited storage space and resources, improving the comprehensiveness of the data tracking. Furthermore, by limiting the number of event information within a preset period, a lightweight data tracking mode is achieved, reducing the power consumption of terminal devices. It also allows for the tracking of business faults or user behaviors in more processes or more areas, improving the accuracy and richness of the data tracking.

[0015] In one possible implementation, the event information includes the time of the event, and the sampling control strategy can be to instruct full collection, to instruct collection according to a preset time period, or to instruct collection according to sampling conditions.

[0016] In the case of full data collection, the event information is directly stored to complete the tracking of this event; or the event information is further validated.

[0017] For data collected within a preset time period, the system determines whether the event occurred within that period. If so, the event information can be stored to complete the event tracking; alternatively, further verification can be performed on the event information. If not, the event information is discarded, meaning it is neither stored nor verified, reducing power consumption and storage space on the terminal device. This allows for the tracking of other business failures or user behaviors, improving the comprehensiveness of the data.

[0018] For data collection based on sampling conditions, it is determined whether the preset tracking events meet the sampling conditions. If so, the event information can be stored to complete the tracking of this event; or further verification can be performed on the event information. If not, the event information is discarded, meaning it is neither stored nor verified, reducing the power consumption and storage space of the terminal device. This allows for the statistical analysis of other business failures or user behaviors, improving the comprehensiveness of the tracking data.

[0019] In one possible implementation, the sampling conditions may include at least one of a preset frequency and a device ratio.

[0020] For data collection at a preset frequency, the system checks whether the number of collections corresponding to the event identifier matches the sampling interval corresponding to the preset frequency. If they match, the event information can be stored to complete the event tracking; or further verification can be performed on the event information. If not, the event information is discarded, meaning it is neither stored nor verified, reducing the power consumption and storage space of the terminal device. This allows for the tracking of other business failures or user behaviors, improving the comprehensiveness of the data.

[0021] For data collection based on a device-to-device ratio, the system determines whether data collection is necessary for the terminal device. If so, the event information can be stored to complete the event tracking; alternatively, further verification can be performed on the event information. If not, the event information is discarded, meaning it is neither stored nor verified, reducing the power consumption and storage space of the terminal device. This allows for the tracking of other business failures or user behaviors, improving the comprehensiveness of the data.

[0022] In one possible implementation, the event information also includes the device identifier of the terminal device. For data collection based on a device ratio, the process of determining whether the terminal device needs to collect data can be implemented in the following ways: In one way, the terminal device generates a random number, and the system checks if the device identifier matches the random number. If they match, the terminal device needs to collect data; otherwise, it does not. In another way, the system receives a preset identifier generated by the cloud server based on the device ratio, and checks if the device identifier matches the preset identifier indicated by the device ratio. If they match, the terminal device needs to collect data; otherwise, it does not. In yet another way, the system receives an updated identifier sent by the cloud server; the updated identifier is generated by the cloud server based on business improvement needs; the preset identifier indicated by the device ratio is updated to the updated identifier. The system then checks if the device identifier matches the updated identifier; if they match, the terminal device needs to collect data; otherwise, it does not.

[0023] In this embodiment of the application, for the sampling control strategy that collects data according to the proportion of devices, it is possible to determine whether the current terminal device needs to report the data based on the generated random number, or it is possible to determine whether the current terminal device needs to report the data based on the preset or updated identifier issued by the cloud server, thereby improving the flexibility and diversity of the data collection strategy.

[0024] By setting preset frequencies, time periods, and device ratios, the number of event information is limited, achieving a lightweight event tracking mode. This reduces the power consumption of terminal devices and allows for the tracking of business failures or user behaviors in more processes or areas, improving the accuracy and richness of event tracking data.

[0025] In one possible implementation, event information includes the event occurrence time. It is determined whether the event occurrence time is before the event tracking termination time. If so, the event information can be stored to complete the tracking for this event; or further verification can be performed on the event information. If not, the event information is discarded, meaning it is neither stored nor verified, reducing the power consumption and storage space of the terminal device. This allows for the tracking of other business failures or user behaviors, improving the comprehensiveness of the tracking data.

[0026] In one possible implementation, the system receives the update termination time from the cloud server and updates the event tracking termination time accordingly. It then determines whether the event occurred before the update termination time. If so, the event information can be stored to complete the event tracking; alternatively, further verification can be performed on the event information. If not, the event information is discarded, meaning it is neither stored nor verified, reducing power consumption and storage space on the terminal device. This allows for the tracking of other business failures or user behaviors, improving the comprehensiveness of the tracking data.

[0027] In this embodiment of the application, the timing strategy for timing termination time can determine whether the event information needs to be timing based on the preset timing termination time, or it can determine whether the event information needs to be timing based on the update termination time issued by the cloud server, thereby improving the flexibility and diversity of timing strategy.

[0028] In this embodiment, by limiting the number of event information through the event termination time, a lightweight event tracking mode is achieved, which reduces the power consumption and storage space of the terminal device. Furthermore, it can collect statistics on business failures or user behaviors in more processes or more fields, thereby improving the accuracy and richness of event tracking data.

[0029] In one possible implementation, the tracking levels include fault tracking levels and privacy tracking levels, and the event information includes the fault level and privacy level corresponding to the preset tracking events.

[0030] For fault level verification, it is determined whether the fault level is greater than or equal to the fault tracking level. If so, the event information can be stored to complete the tracking of this event; or further verification can be performed on the event information. If not, the event information is discarded, meaning it is neither stored nor further verified, reducing the power consumption and storage space of the terminal device. This allows for the statistical analysis of other business faults or user behaviors, improving the comprehensiveness of the tracking data.

[0031] For privacy level verification, the system checks if the privacy level is less than or equal to the privacy tracking level. If so, the event information can be stored to complete the tracking of this event; or further verification can be performed on the event information. If not, the event information is discarded, meaning it is neither stored nor further verified, reducing the power consumption and storage space of the terminal device. This allows for the tracking of other business failures or user behaviors, improving the comprehensiveness of the tracking data.

[0032] In this embodiment, by using the tracking level and privacy level, event information that does not meet security requirements is discarded, thus realizing a lightweight tracking mode, reducing the power consumption of terminal devices, and enabling the collection of business failures or user behaviors in more processes or more fields, thereby improving the accuracy and richness of tracking data.

[0033] In one possible implementation, the event information includes attribute information for each object. For attribute information validation, it is determined whether each attribute matches a preset set of information. If so, the attribute information of multiple objects in this event information can be stored to complete the event tracking; or further validation of the event information can be performed. If there are objects whose attribute information does not match the preset information, these objects are considered non-compliant with security requirements. The attribute information of all objects except those that do not meet security requirements is stored to complete the event tracking; or further validation of the event information can be performed.

[0034] In this embodiment, by using preset information, attribute information that does not meet security requirements is discarded, thereby achieving a lightweight tracking mode, reducing the power consumption of terminal devices, and enabling the collection of business faults or user behaviors in more processes or more fields, thus improving the accuracy and richness of tracking data.

[0035] In one possible implementation, due to limited storage space, a maximum cache size is set. If the maximum cache size is not reached, the event information of the acquired preset event points is temporarily cached. Then, the event information is read from the temporary cache location and validated according to the event identifier corresponding to the event point strategy in the preset event point configuration information to obtain the validation result. If the maximum cache size is reached or exceeded, the oldest stored event information is overwritten, or the newest event information is discarded. By setting a maximum cache size, the space occupied by the terminal device is reduced, allowing for timely processing of event information and improving data processing efficiency.

[0036] In one possible implementation, event information includes a tracking type, which can be either a business failure type or a user behavior type. For each type, a corresponding tracking strategy is used to validate the event information. After validation, the event information for the business failure type and user behavior type is stored separately based on the validation results, resulting in a storage result. In other words, business failure types and user behavior types are stored separately. When reporting to the cloud server, the tracking data for the business failure type (i.e., the first tracking data) is sent to the cloud server according to a first preset format; the tracking data for the user behavior type (i.e., the second tracking data) is sent to the cloud server according to a second preset format. The tracking data for the business failure type and user behavior type are sent to the cloud server through different sending channels, improving reporting efficiency. Furthermore, the cloud server stores the tracking data for the business failure type and user behavior type separately for subsequent improvements and optimizations.

[0037] In one possible implementation, the operating system of the terminal device includes an application layer, an application framework layer, a local layer, and a kernel layer. The application framework layer includes a first tracking interface for retrieving event information when a preset tracking event occurs at the application layer. The local layer includes a second tracking interface for retrieving event information when a preset tracking event occurs at the local layer. The kernel layer includes a third tracking interface for retrieving event information when a preset tracking event occurs at the kernel layer.

[0038] In this embodiment of the application, by setting different point-tracking interfaces at different layers of the software system, different languages ​​can be supported to support point-tracking of business at different layers, thereby improving the universality and comprehensiveness of point-tracking.

[0039] In a second aspect, a terminal device is provided, the terminal device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the computer program is executed by the processor, it implements the dot-marking method as described in the first aspect or any implementation thereof.

[0040] Thirdly, a computer-readable storage medium is provided, wherein instructions are stored therein, which, when executed on a computer, cause the computer to perform the dot-marking method involved in the first aspect or any implementation thereof.

[0041] Fourthly, embodiments of this application provide a chip system that can be applied to an electronic device. The chip system includes one or more processors that invoke computer instructions to cause the electronic device to execute the dotting method as described in the first aspect or any implementation thereof.

[0042] Fifthly, a computer program product containing instructions is provided, which, when run on a computer, causes the computer to execute the dot-marking method described in the first aspect or any implementation thereof.

[0043] The technical effects achieved by the second, third, fourth, and fifth aspects mentioned above are similar to those achieved by the corresponding technical means in the first aspect mentioned above, and will not be repeated here. Attached Figure Description

[0044] Figure 1 This is a schematic diagram of the structure of a terminal device provided in an embodiment of this application;

[0045] Figure 2 This is a block diagram of a software system for a terminal device provided in an embodiment of this application;

[0046] Figure 3 This is a flowchart illustrating a dot-marking method provided in an embodiment of this application;

[0047] Figure 4 This is a flowchart illustrating another dot-marking method provided in an embodiment of this application;

[0048] Figure 5 This is a schematic diagram of a dot-marking process provided in an embodiment of this application;

[0049] Figure 6 This is a schematic diagram of a service interaction process provided in an embodiment of this application. Detailed Implementation

[0050] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0051] It should be understood that "multiple" as mentioned in this application refers to two or more. In the description of this application, unless otherwise stated, " / " indicates "or," for example, A / B can mean A or B; "and / or" in this document is merely a description of the relationship between related objects, indicating that three relationships can exist, for example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Furthermore, to facilitate a clear description of the technical solutions of this application, the terms "first," "second," etc., are used to distinguish identical or similar items with essentially the same function and effect. Those skilled in the art will understand that the terms "first," "second," etc., do not limit the quantity or execution order, and that "first," "second," etc., do not necessarily imply differences.

[0052] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0053] The event tracking method provided in this application can be applied to business systems in terminal devices to collect and store events such as business failures and user behavior, thus completing the event tracking process. Event tracking, also known as data collection tracking, is a term in the field of data collection, especially in the field of user behavior data collection. It refers to the related technologies and implementation processes for capturing, processing, and sending specific events.

[0054] Terminal devices include, but are not limited to, mobile phones, foldable phones, smart terminals, laptops, smart wearable devices, tablets, desktops, portable computers, handheld computers, wireless terminal devices, communication equipment, digital broadcast receivers, personal digital assistants (PDAs), portable android devices (PADs), and portable media players (PMPs).

[0055] Business failures include, but are not limited to, device black screens, device freezes, application lag, abnormal device or application startup, application crashes, application outages, and network anomalies. For example, if a database crashes while a user is making settings in application A, preventing data loading, this constitutes a business failure and requires tracking. User behavior includes, but is not limited to, opening or closing the application, deleting notification messages, powering on, or powering off the device. For example, for application B, tracking logic can be used to count how many times the user opened the application, the duration of each session, and which function buttons were clicked.

[0056] Currently, some terminal devices lack log information, making problem localization difficult. Therefore, the business systems of these terminal devices provide a logging framework to track business failures and user behavior. By collecting data reflecting the characteristics of business failures and usage data reflecting user behavior characteristics, it facilitates continuous evolution and improvement of features, enhancing problem-solving efficiency and enriching human-computer interaction. Based on its own business logic, the business system pre-embeds fault points for potential abnormal branches such as business failures and user behavior, essentially pre-tracking events. Without compromising user privacy or meeting privacy requirements, the logging framework's interface (the logging interface) is called to log abnormal logic (including business failures and user behavior), storing event information for problem localization. This logging logic applies to every application and every user behavior; however, as the number of business logging points increases, the load on terminal devices rises, resulting in higher power consumption. Furthermore, frequent calls to the event tracking interface to write event information can lead to data loss in other processes or areas due to limited processing capacity and upload bandwidth at each stage (i.e., quota limits). This can affect other business operations. Subsequently, terminal devices will upload event information to the cloud server, further increasing the load on the cloud server.

[0057] To address the aforementioned technical issues, this application provides a point-tracking method. Based on a point-tracking framework, point-tracking interfaces are provided at different architectural layers of the framework. When a preset point-tracking event (business failure or preset user behavior) occurs during terminal device operation, event information of the preset point-tracking event is obtained. Pre-stored preset point-tracking configuration information includes multiple preset point-tracking strategies for different event identifiers. Each point-tracking strategy includes a first point-tracking strategy for limiting the number of event information entries and a second point-tracking strategy for filtering event information that does not meet security requirements. Event information includes an event identifier. The point-tracking strategy corresponding to the event identifier of the current event is found in the preset point-tracking configuration information, and the event information is verified to achieve a lightweight point-tracking mode for business failures and user behaviors. This lightweight point-tracking mode can be reflected in rate limiting based on process and point-tracking type, as well as filtering based on fault level, privacy level, and security. Compared to technical solutions that track all event information, this application's embodiment limits or samples event information related to processes and tracking types through a verification process. It filters out event information that does not meet security requirements, such as those involving privacy or low-level faults, achieving a lightweight tracking mode. This reduces the power consumption of terminal devices and allows for the statistical analysis of business faults or user behaviors in more processes or areas, improving the accuracy and richness of the tracking data. It can simultaneously achieve the technical effects of problem localization and business improvement statistics.

[0058] Before providing a detailed explanation of the dot-marking method provided in the embodiments of this application, the terminal devices involved in the embodiments of this application will be described first.

[0059] Figure 1 This is a schematic diagram of the structure of a terminal device provided in an embodiment of this application. See also... Figure 1 The terminal device 100 may include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 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.

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

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

[0062] The controller can serve as the central nervous system and command center of the terminal device 100. The controller can generate operation control signals based on the instruction opcode and timing signals to control the fetching and execution of instructions.

[0063] The processor 110 may also include a memory for storing instructions and data.

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

[0065] It is understood that the interface connection relationships between the modules illustrated in the embodiments of this application are merely illustrative and do not constitute a structural limitation on the terminal device 100. In other embodiments of this application, the terminal device 100 may also adopt different interface connection methods or a combination of multiple interface connection methods as described in the above embodiments.

[0066] The wireless communication function of the terminal device 100 can be implemented through antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, modem processor and baseband processor, etc.

[0067] In some embodiments, the antenna 1 of the terminal device 100 is coupled to the mobile communication module 150, and the antenna 2 is coupled to the wireless communication module 160, so that the terminal device 100 can communicate with the network and other devices through wireless communication technology.

[0068] Terminal device 100 implements display functions through a GPU, display screen 194, and 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.

[0069] Terminal device 100 can perform shooting functions through ISP, camera 193, video codec, GPU, display 194 and application processor.

[0070] The external storage interface 120 can be used to connect an external storage card, such as a Micro SD card, to expand the storage capacity of the terminal device 100. The external storage card communicates with the processor 110 through the external storage interface 120 to perform data storage functions, such as saving music, video, and other files on the external storage card.

[0071] Internal memory 121 can be used to store computer-executable program code, which includes instructions. Processor 110 executes various functional applications and data processing of terminal device 100 by running the instructions stored in internal memory 121. 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 by terminal device 100 during use (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.

[0072] Terminal device 100 can implement audio functions, such as music playback and recording, through audio module 170, speaker 170A, receiver 170B, microphone 170C, headphone jack 170D and application processor.

[0073] The SIM card interface 195 is used to connect a SIM card. The SIM card can be inserted into or removed from the SIM card interface 195 to make contact with and detach from the terminal device 100. The terminal device 100 can support one or N SIM card interfaces, where N is an integer greater than 1. The SIM card interface 195 can support Nano SIM cards, Micro SIM cards, SIM cards, etc. Multiple cards can be inserted into the same SIM card interface 195 simultaneously. The multiple cards can be of the same or different types. The SIM card interface 195 is also compatible with different types of SIM cards. The SIM card interface 195 is also compatible with external memory cards. The terminal device 100 interacts with the network through the SIM card to realize functions such as calls and data communication. In some embodiments, the terminal device 100 uses an eSIM, i.e., an embedded SIM card. The eSIM card can be embedded in the terminal device 100 and cannot be separated from the terminal device 100.

[0074] The software system of terminal device 100 will be described next.

[0075] The software system of terminal device 100 can adopt a layered architecture, event-driven architecture, microkernel architecture, microservice architecture, or cloud architecture. This application embodiment uses a layered Android system as an example to illustrate the software system of terminal device 100.

[0076] Figure 2 This is a block diagram of a software system for a terminal device 100 provided in an embodiment of this application. See also... Figure 2 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 (app), the application framework layer (Android framework), the native layer, the hardware abstraction layer (HAL), and the kernel layer.

[0077] The Hardware Abstraction Layer (HAL) is an interface layer located between the operating system kernel and the hardware circuitry. Its purpose is to abstract the hardware; for example, it can encapsulate drivers in the driver layer and provide an interface for the application framework layer to call, shielding the implementation details of the underlying hardware. In this example, the HAL layer is used to write event information to the application framework layer and the native layer, and uses a point-based rate limiting method to control the number of event messages per process.

[0078] Based on the software system framework, the processing procedures in each layer are described when business failures occur or preset user behaviors appear.

[0079] The application layer can include a series of application packages. The application framework layer provides application programming interfaces (APIs) and programming frameworks for the applications in the application layer. The application framework layer includes a first event interface for obtaining event information from the application layer.

[0080] At the application layer, consider two examples: application A experiences business exception processes 1 and 2, and application B experiences business exception processes 3 and 4. Applications A and B can be applications such as camera, gallery, calendar, call, map, navigation, WLAN, Bluetooth, music, video, or SMS. The pre-programmed event tracking in the business system can detect these business exception processes (i.e., pre-defined event tracking) and capture their event information. The terminal device calls the first event tracking interface of the application framework layer to obtain the event information from the application layer. This event information is then transmitted to the kernel layer through the HAL layer. During transmission, the event information is written to the HAL layer, and a rate-limiting method is used to control the number of event messages per process. Event messages exceeding the process limit are discarded and not processed further.

[0081] The local layer includes a second event tracking interface for obtaining event information from system services. System services include, but are not limited to, Activity Manager Service (AMS), Package Manager Service (PMS), Notification Manager Service, Location Manager Service, and Connectivity Manager Service.

[0082] At the local layer, taking the abnormal processes 5 and 6 of the system service as examples, the pre-installed event tracking program in the business system can detect the above abnormal processes (i.e., the pre-defined event tracking) and capture the event information of the abnormal business processes. The terminal device calls the second event tracking interface to obtain the event information from the local layer. The event information is first written to the HAL layer, and event information exceeding the process limit in a single process is discarded without further processing.

[0083] Event information is written to the HAL layer, and event information exceeding the process limit in a single process is discarded. This means that event information exceeding the process limit is not written, improving the effectiveness of event information and reducing power consumption. The event information in the HAL layer is in user space. Then, through the connection channel between the HAL layer and the kernel layer, event information is written to the kernel layer. The event information in the kernel layer is in kernel space, realizing the conversion between user space and kernel space.

[0084] Event information writing to the HAL layer can be done using the event handling library (HiEvent) in C++. HiEvent is a powerful and easy-to-use event bus library. The connection channel between the HAL layer and the kernel layer can be implemented using the writev system call. writev is a system call function used to write data to a file descriptor in one or more non-contiguous buffers.

[0085] The kernel layer is the layer between hardware and software. The kernel layer includes a third-party endpoint interface for obtaining event information from kernel services.

[0086] At the kernel layer, taking the abnormal processes 7 and 8 in the kernel service as examples, the pre-installed event tracking program in the business system can detect these abnormal processes (i.e., pre-defined event tracking) and capture the event information of the abnormal business processes. The terminal device calls the third event tracking interface to obtain the event information from the local layer and directly writes the event information into the kernel layer. Of course, the third event tracking interface at the kernel layer can also add event tracking and rate limiting to discard event information exceeding the process limit in a single process. Under normal circumstances, since there are relatively few business failures or user behaviors at the kernel layer, event tracking and rate limiting can be omitted, and event information can be written directly.

[0087] Writing event information in the kernel layer can refer to writing to a cache partition, which is a special partition used to store configuration information and temporary data of the terminal device. For example, the cache partition can be a misc partition.

[0088] The writing of event information in the HAL layer and kernel layer can be understood as forwarding event information from one layer to another, which is the internal information flow between the layers of the terminal device's software system. After the event information is written in the kernel layer, it is stored in the device node. The device node in the kernel layer can be regarded as a file system used to store and manage data, essentially a temporary cache space for temporarily caching event information. It has a storage limit. If the storage limit is reached and the event information has not yet been read by the log engine, the earliest cached event information will be overwritten by new event information, or the earliest cached event information will be deleted.

[0089] The local layer includes a log engine, which reads event information from device nodes and uses pre-set logging configuration information to verify the event information, thereby limiting the number of event information and filtering it based on fault level, privacy level, security, etc.

[0090] The logging engine's logging configuration information can include at least one of the following: quota control, sampling control policy, logging sunset mechanism, fault level verification, security verification, and privacy processing. Quota control is set separately for business fault types and user behavior types. For business fault types, quota control refers to the upper limit of fault logging within a first preset period (e.g., daily fault logging quota), used to limit the number of logging entries for business fault types within the first preset period. For user behavior types, quota control refers to the upper limit of behavior logging within a second preset period (e.g., daily behavior logging quota), used to limit the number of logging entries for user behavior types within the second preset period. Sampling control policy is used to collect event information in full, according to preset time periods, according to preset frequencies, or according to device proportions. The logging sunset mechanism is a logging termination time set for specific event information. Event information before the logging termination time is valid, while event information after the logging termination time is invalid, i.e., unnecessary. Fault level verification is used to filter event information whose fault level meets the requirements. Security verification filters attribute information from multiple objects included in the event information to identify those that meet security requirements. Privacy processing filters event information that meets privacy level requirements. Fault level verification, security verification, and privacy processing all aim to improve the security of event information.

[0091] After verifying event information, the log engine can determine which events need to be logged and store the logged events, i.e., store the logging data. Once a preset quantity or period has been reached, the logging data is reported to the cloud server, where it is stored. On one hand, logging data can be used to improve business processes. For example, logging data shows that 90% of users typically delete or hide subway-related push notifications, meaning users don't view them. Based on this, subway-related push notifications can be optimized or improved to enhance user experience. On the other hand, when users select online services (e.g., consultation) or offline services (e.g., in-store repair), logging data can be retrieved to analyze terminal device problems and improve processing efficiency.

[0092] In this embodiment, different layers include different event tracking interfaces. For example, the first event tracking interface of the application framework layer can be written in Java; the second event tracking interface of the local layer can be written in C++; and the third event tracking interface of the kernel layer can be written in C. By setting different event tracking interfaces at different layers of the software system, event tracking for different layers of business can be supported, improving the universality and comprehensiveness of event tracking.

[0093] This solution is based on the overall framework of Android, as described above. Figure 2 The system provides event tracking interfaces at the hardware abstraction layer, local layer, and kernel layer. When a preset event occurs in the business logic of these layers, the event information of the preset event is collected and stored to complete the event tracking, that is, to record or mark the event information.

[0094] In this embodiment, event information is marked according to a standardized format, meaning that event information is captured and stored using a standardized format. The standardized format is used to standardize the parameters included when capturing event information. The captured event information may include parameters such as event identifier (also called markup code or scene code), event occurrence time, markup type (business failure or user behavior), failure level, privacy level, attribute information of each object, and markup cycle (i.e., markup frequency). The markup cycle is used to determine the number of times the preset markup event will be marked. The event identifier, markup type, failure level, privacy level, attribute information of each object, markup cycle, and other related parameters can be requested in advance by the business system. When the preset markup event occurs, information is captured according to the pre-requested standardized format.

[0095] The event information can further include the endpoint time and sampling mode corresponding to the event identifier. In other words, the collected event information carries the endpoint time and sampling mode, which can include full collection, collection according to a preset time period, collection according to a preset frequency, and collection according to device proportion. Thus, when validating the event information, event information that does not meet the criteria can be discarded based on the endpoint time and sampling mode.

[0096] It is understandable that the aforementioned endpoint timing and sampling pattern can also be stored in the log engine and correspond to the event identifier. In this way, when validating event information, the log engine finds the corresponding endpoint timing and sampling pattern based on the event identifier, and then discards event information that does not meet the conditions.

[0097] In this embodiment, the logging engine at the local layer executes the logging method. The logging engine stores pre-approved preset logging configuration information, which includes logging strategies for multiple event identifiers. The logging strategy includes event identifiers and parameters strongly associated with the business. The event identifiers (also called logging codes or scenario codes) correspond to applications, businesses, performance, reliability, power consumption, etc., and are used to indicate which business process or logging type it is. The parameters strongly associated with the business include at least one of the following: a fault logging cap within a first preset period (e.g., daily fault logging quota), a behavior logging cap within a second preset period (e.g., daily behavior logging quota), logging termination time, logging rate limiting strategy, fault logging level, privacy logging level, sampling control strategy, and preset information for each object. The preset information consists of pre-set attribute information that meets security requirements. If the obtained attribute information of an object is consistent with the preset information, it means that the object meets the security requirements and its attribute information can be marked. If the obtained attribute information of an object is inconsistent with the preset information, it means that the object does not meet the security requirements and its attribute information will not be marked.

[0098] The event tracking termination time can be understood as the event tracking sunset time. It can be used to track temporary events, such as tracking events for one month, after which the event is no longer needed. By adding a event tracking sunset mechanism and setting a sunset time, we can prevent events from remaining even when they are no longer needed due to aging characteristics or business requirements, thus avoiding increasing redundancy in the business system and improving the flexibility of event tracking. The event tracking termination time can be set on the terminal device side or dynamically issued by the cloud server. In practical applications, the cloud server dynamically identifies unnecessary events and sends the preset event tracking termination time to the terminal device. The terminal device then updates the preset event tracking termination time to match the new termination time.

[0099] The fault level of the preset event tracking detected by the log engine indicates the severity of the fault. Severity levels can include General, Alarm, and Critical; or Low, Normal, High, and Urgent; or Level 1, Level 2, and Level 3, etc. The fault tracking level refers to the lowest level of fault that requires tracking. In other words, tracking only occurs when the fault level is greater than or equal to the tracking level. For example, if the tracking level is Alarm, then tracking will occur when the fault level is Alarm or Critical; if the fault level is General, no tracking is required.

[0100] The privacy level of preset events detected by the log engine indicates the user's sensitivity to information. Privacy levels can be L0 (excluding data that is relatively sensitive to the user), L1 (including data that is relatively sensitive to the user), and L2 (including data that is very sensitive to the user). The privacy level refers to the lowest level of privacy that needs to be tracked. In other words, tracking only occurs when the privacy level is less than or equal to the privacy level of the tracking level. For example, if the privacy level is L1, then tracking will occur when the privacy level is L0 or L1. At a privacy level of L2, no tracking is required; that is, data that is very sensitive to the user will not be tracked.

[0101] Sampling control strategies can instruct for full data collection, collection within a preset time period, collection at a preset frequency, and collection based on device proportion. Full data collection means that all business-related data points are collected, such as system faults requiring full reporting. Collection within a preset time period means data is collected only during specific time periods, such as network status information, which is prone to anomalies during certain periods. Collection at a preset frequency means sampling data based on the number of data points collected, such as analyzing application startup duration distribution, where applications are used frequently and do not require collection every time; sampling reduces data volume, lowers terminal device power consumption, and increases data point flexibility. Collection based on device proportion means that only data points from a subset of devices are collected, such as for business improvement needs, where only data points from a subset of devices are selected for collection and reporting. The cloud server generates random numbers based on the reporting terminal devices. These random numbers correspond to device identifiers, with one device identifier corresponding to one terminal device. The random number is used to determine whether the current terminal device needs to report relevant data for data points.

[0102] This application provides a dot-marking method, such as... Figure 3 As shown, Figure 3 This is a flowchart illustrating a dot-marking method provided in an embodiment of this application. The dot-marking method includes:

[0103] S101. When a preset event occurs during the operation of the terminal device, obtain the event information of the preset event; the preset events include business failures and preset user behaviors, and the event information includes the event identifier.

[0104] In this embodiment, the program pre-embedded with event tracking data in the terminal device can detect whether a preset event (business failure or preset user behavior) occurs during the operation of the terminal device. Upon detecting a preset event, the event information is captured. The event tracking interface in the terminal device's software system pre-requests permission to obtain event information from the pre-embedded program. After the pre-embedded program captures the event information, it calls the event tracking interface to obtain the event information captured by the pre-embedded program.

[0105] Preset events in business logic can occur due to business failures, such as a database crash preventing data loading during configuration of application A in the application layer, or application B crashing during a version upgrade. Preset events can also occur due to pre-defined user behaviors, such as a user opening application C, staying in application C for 10 minutes, then closing application C; deleting a notification message from application D; or a user turning their device on or off.

[0106] Event information includes an event identifier, which (also known as a dot code or scene code) is used to indicate a unique dot event. It can be represented by coded information. For example, the event identifier (Event id) can be customized and uniquely edited. For example, it can be shown as a 4-digit code, such as Event id = 0001, Event id = 0002, etc.

[0107] S102. According to the event identifier corresponding to the event tracking strategy in the preset tracking configuration information, the event information is verified to obtain the verification result. The tracking strategy includes at least one of a first tracking strategy for limiting the number of event information and a second tracking strategy for filtering event information that does not meet the security requirements.

[0108] In this embodiment of the application, the pre-set preset point configuration information includes point strategies for multiple event identifiers. The event identifiers and point strategies correspond one-to-one. Each point strategy includes at least one of a first point strategy for limiting the number of event information and a second point strategy for filtering event information that does not meet security requirements. The point strategy realizes a lightweight point mode.

[0109] The system searches for the event identifier corresponding to the current event in the preset event tracking configuration information. It then uses the first and / or second event tracking strategies to verify the event information, obtaining the verification result. Compared to technical solutions that track all event information, this embodiment achieves event tracking rate limiting through a verification process that limits the number of events and filters security checks, thereby reducing the number of events tracked and lowering the power consumption of the terminal device.

[0110] S103. Store the event information based on the verification results.

[0111] In this embodiment, event information is stored based on the verification results to obtain event tracking data. The process of acquiring, verifying, and storing event information completes the event tracking. By limiting the number of tracking points and implementing security filtering, storage space usage is reduced, allowing for the tracking of business failures or user behaviors in more processes or areas, thus improving the comprehensiveness of the tracking data. This simultaneously achieves the technical goals of problem localization and business improvement statistics.

[0112] In some embodiments, before validating the event information, it can be first determined whether the current process containing the preset event meets the event limiting policy. That is, it can be determined whether the number of events performed by the current process containing the preset event within a preset time does not exceed the process limit. If yes, the event information is then validated. If no, the event information is discarded, meaning it is not validated.

[0113] In this embodiment, front-end rate limiting is implemented when writing event information in the HAL layer. As business volume increases, so does the number of event points, leading to a gradual increase in the number of event points for a single process. Therefore, when writing event information in the front-end HAL layer of the event point framework, overall rate limiting is applied to a single process. The rate limiting strategy can be that the number of event points within a preset time period does not exceed the process's upper limit. By determining whether the number of event points in the current process containing the preset event does not exceed the process's upper limit within the preset time period, if the number of event points in the current process exceeds the process's upper limit, the event information is not validated. In other words, no event information writing operation is performed in the HAL layer, reducing the power consumption of the terminal device. Furthermore, event point data from other processes can be collected, improving the comprehensiveness of the event point data.

[0114] In this embodiment of the application, the number of event information in the process dimension is limited through the verification process, which realizes a lightweight point-of-care mode, reduces the power consumption of terminal devices, and can count more processes or business failures or user behaviors in more fields, thereby improving the accuracy and richness of point-of-care data.

[0115] In some embodiments, the first tracking strategy includes at least one of the following: tracking upper limit, sampling control strategy, tracking termination time, and tracking rate limiting strategy; the second tracking strategy includes at least one of the following: tracking level, and preset information of each object in the business or behavior.

[0116] In this embodiment, the type of the preset tracking event can be either a business failure type or a user behavior type. The preset tracking event includes multiple objects, and these objects are not entirely identical. For business failure types, the multiple objects consist of business-related fields, such as event name, reason, fingerprint, version number, device name, application package name, foldable screen status, screen, application, signal strength, and duration. For user behavior types, the multiple objects consist of behavior-related fields, such as event name, reason, click, delete, exit, close, application, and duration. The content of these fields serves as the attribute information of the object.

[0117] For business failure types, the event information is verified using at least one of the following: the upper limit of the event marker corresponding to the event identifier, the sampling control strategy, the event termination time, the event rate limiting strategy, the event level, and the preset information of each object in the business. For user behavior types, the event information is verified using at least one of the following: the upper limit of the event marker corresponding to the event identifier, the sampling control strategy, the event termination time, the event rate limiting strategy, the event level, and the preset information of each object in the behavior. The process of verifying the event information based on at least one of the following: the upper limit of the event marker, the sampling control strategy, the event termination time, the event rate limiting strategy, the event level, and the preset information of each object. The verification process can be performed simultaneously or sequentially. The verification order can be appropriately adjusted according to the busy levels of the modules with verification functions to achieve cross-verification and improve verification efficiency.

[0118] The following sections explain the upper limit of the sampling point, the sampling control strategy, the sampling termination time, and the sampling rate limiting strategy in the first sampling strategy.

[0119] The point-based rate limiting strategy described above determines whether the current process containing the preset point-based event meets the point-based rate limiting strategy before verifying the event information.

[0120] It is understandable that the rate limiting strategy can also be part of the verification process. Based on this, in this solution, when verifying event information, it can be determined whether the current process containing the preset rate limiting event meets the rate limiting strategy; that is, whether the number of rate limiting events in the current process containing the preset rate limiting event does not exceed the process limit within a preset time period. If so, the event information can be stored to complete the rate limiting for this event; or other verifications can be performed on the event information. If not, the event information is discarded, meaning it is not stored.

[0121] In this embodiment, during the verification of event information in the backend local layer of the event tracking framework, overall event tracking and rate limiting are applied to a single process. The rate limiting strategy can be that the number of events tracked within a preset duration does not exceed the process's upper limit. By determining whether the number of events tracked by the current process containing the preset event does not exceed the process's upper limit within the preset duration, if the number of events tracked by the current process exceeds the process's upper limit, the event information is not stored or further verified, reducing the power consumption of the terminal device. Furthermore, event tracking data from other processes can be collected, improving the comprehensiveness of the event tracking data.

[0122] In this embodiment, the point-based rate limiting strategy can be set in the front-end HAL layer or in the log engine of the back-end local layer, which improves the flexibility of the point-based method.

[0123] In some embodiments, the event information includes a tracking type, which is either a business failure type or a user behavior type. The aforementioned tracking upper limit includes a failure tracking upper limit within a first preset period and a behavior tracking upper limit within a second preset period.

[0124] For each business failure type, determine whether the number of records for that business failure type within the first preset period is less than or equal to the upper limit for failure records. If so, the event information can be stored to complete the business failure recording; or further verification can be performed on the event information. If not, the event information is discarded, meaning it is neither stored nor verified.

[0125] For each user behavior type, it is determined whether the number of points recorded for that user behavior type within the second preset period is less than or equal to the upper limit of behavior points. If so, the event information can be stored to complete the user behavior tracking. If not, the event information is discarded, meaning it is not stored.

[0126] It should be noted that the first preset period and the second preset period can be the same or different, and this application embodiment does not impose any restrictions on this. For example, taking a first preset period of one day as an example, the upper limit for fault tracking within the first preset period refers to the daily fault tracking quota. Taking a second preset period of one day as an example, the upper limit for behavior tracking within the second preset period refers to the daily behavior tracking quota.

[0127] In this embodiment, the number of business fault types and user behavior types within the tracking categories is limited separately. This balances the number of different tracking types within limited storage space and resources, reducing situations where one type has a large number of tracking points while another has a small number, thus improving the comprehensiveness of the tracking data. Furthermore, by limiting the number of event information within a preset period for each tracking type (business fault type and user behavior type) through a verification process, a lightweight tracking mode is achieved, reducing the power consumption of terminal devices. This also allows for the statistical analysis of business faults or user behaviors across more processes or domains, improving the accuracy and richness of the tracking data.

[0128] In some embodiments, event information includes the time of event occurrence. Regardless of whether it's a business failure or a user behavior type, the following sampling control strategy can be applied. The sampling control strategy can be to instruct full data collection, to instruct collection within a preset time period, or to instruct collection according to sampling conditions. The sampling control strategy can also be a combination of instructing collection within a preset time period and collection according to sampling conditions. This application embodiment does not limit this aspect.

[0129] Example 1: For full data collection, the event information is directly stored to complete the event tracking; or the event information is further validated.

[0130] In this embodiment, full data collection means that as long as event information is captured, full data collection is performed. For example, in the event of a system failure, all data needs to be reported. For instance, after obtaining the event information of a system failure, the system failure tracking strategy is determined to be full data collection based on the event identifier in the event information. The system failure event information is then directly stored to complete the tracking. Alternatively, the system failure tracking strategy is determined to be full data collection based on the event identifier in the event information, and other processing is performed, such as quota control, tracking sunset mechanism, fault level verification, security verification, and privacy processing.

[0131] Example 2: For data collection within a preset time period, determine if the event occurred within that period. If so, store the event information to complete the event tracking; or perform further verification on the event information. If not, discard the event information, meaning neither store nor verify it, reducing power consumption and storage space on the terminal device. This allows for the tracking of other business failures or user behaviors, improving the comprehensiveness of the data.

[0132] In this embodiment, data collection according to a preset time period means collecting data only during a preset time period. For example, network status is prone to anomalies between 18:00 and 23:00, so data collection can be performed only during this period. For instance, if the network status event occurred at 15:00 and the preset time period is 18:00-23:00, after obtaining the network status event information, the network status tracking strategy is determined based on the event identifier in the event information: data collection according to the preset time period. If the event occurred outside the preset time period, the event information is discarded and not stored. This reduces the power consumption and storage space of the terminal device. Furthermore, it allows for the statistical analysis of other service failures or user behaviors, improving the comprehensiveness of the tracking data.

[0133] Example 3: For data collection based on sampling conditions, determine whether the preset event meets the sampling conditions. If so, the event information can be stored to complete the event tracking; or further verification can be performed on the event information. If not, the event information is discarded, meaning it is neither stored nor verified, reducing the power consumption and storage space of the terminal device. This allows for the statistical analysis of other business failures or user behaviors, improving the comprehensiveness of the tracking data.

[0134] Furthermore, the sampling conditions in Example 3 may include at least one of a preset frequency and a device ratio.

[0135] For data collection at a preset frequency, it is determined whether the number of collections corresponding to the event identifier matches the sampling interval corresponding to the preset frequency. If they match, the event information can be stored to complete the event tracking; or further verification can be performed on the event information. If not, the event information is discarded, meaning it is neither stored nor verified.

[0136] In this embodiment, data collection at a preset frequency refers to sampling based on the number of data points collected. For example, application startup time is frequently used, so it doesn't need to be collected every time. Therefore, application startup time can be sampled. For instance, taking a sampling interval of 1 in 10 times as an example, after obtaining the application startup time event information, the data collection strategy for application startup time is determined to be data collection at a preset frequency based on the event identifier in the event information. When the sampling number corresponding to the application startup time is the 10th time, it matches the sampling interval, and the event information for the application startup time is stored. Alternatively, other processing can be performed on the event information for the application startup time, such as quota control, sunset mechanism, fault level verification, security verification, and privacy processing. When the sampling number corresponding to the application startup time is the 1st to 9th time, it does not match the sampling interval, and the event information for the 1st to 9th times is discarded. This reduces the power consumption and storage space of the terminal device. Furthermore, it allows for the statistical analysis of other business faults or user behaviors, improving the comprehensiveness of the data collection.

[0137] For data collection based on a device-to-device ratio, the system determines whether data collection is necessary for the terminal device. If so, the event information can be stored to complete the event tracking; alternatively, further verification can be performed on the event information. If not, the event information is discarded, meaning it is neither stored nor verified, reducing the power consumption and storage space of the terminal device. This allows for the tracking of other business failures or user behaviors, improving the comprehensiveness of the data.

[0138] In this embodiment, proportional device data collection means that only a portion of the devices need to be tracked. For example, for business improvement needs, only data collection from a portion of the devices is required. For instance, for terminal device X, it needs to collect and report a preset tracking event Y reflecting the business experience. After obtaining the event information of preset tracking event Y, the tracking strategy for preset tracking event Y is determined to be proportional device data collection based on the event identifier in the event information. It is determined that terminal device X needs to be tracked. The event information of preset tracking event Y is stored, or further processing is performed on the event information of preset tracking event Y, such as quota control, tracking sunset mechanism, fault level verification, security verification, and privacy processing.

[0139] For terminal device Z, it is not necessary to collect and report preset tracking events O that reflect the service experience. After obtaining the event information of preset tracking event O, the tracking strategy of preset tracking event O is determined to be based on the event identifier in the event information. It is determined that terminal device Z does not need to collect the data. Therefore, the event information of preset tracking event O is not stored. This reduces the power consumption and storage space of the terminal device. Furthermore, it is possible to statistically analyze other service faults or user behaviors, improving the comprehensiveness of the tracking data.

[0140] It should be noted that the sampling control strategy is a special verification set for certain event tracking. For event tracking without a sampling control strategy, there is no need to perform the verification process related to the sampling control strategy. Alternatively, the sampling control strategy in the preset event tracking configuration information can be set to full collection. In this case, when verifying the event according to the sampling control strategy, the event information is directly stored to complete the event tracking; or other verifications can be performed on the event information.

[0141] In some embodiments, the event information also includes the device identifier of the terminal device. For cases where data is collected proportionally by device, the process for determining whether a terminal device needs to be collected can be implemented as follows: Example 1: Generate a random number, and determine whether the device identifier matches the random number. If they match, the terminal device needs to be collected. If not, the terminal device does not need to be collected.

[0142] In this example, for the case of random reporting, where the cloud server only needs a subset of devices to perform logging and reporting, a random number is generated by the log engine of the terminal device. This random number can be any single or multiple digits. The system then checks whether the device identifier matches the random number.

[0143] One device identifier corresponds to one terminal device. For example, if the device identifier is the serial number (SN) of the terminal device, the device identifier is determined by whether the serial number contains a random number. If the serial number contains a random number, it means that the device identifier and the random number match. For example, if the random number is 5, the system checks whether the serial number contains 5.

[0144] For example, the device identifier is determined to match the random number by checking if the last digit of the serial number is the same as the random number. If the last digit of the serial number matches the random number, then the device identifier matches the random number. For example, if the random number includes 1, 2, 3, 4, and 5, the determination is made as to whether the last digit of the serial number is any one of 1, 2, 3, 4, and 5.

[0145] Example 2: Receive the preset identifier generated by the cloud server based on the device ratio, and determine whether the device identifier matches the preset identifier indicated by the device ratio. If they match, it means the terminal device needs to collect data. If not, it means the terminal device does not need to collect data.

[0146] In this example, the cloud server sets the device ratio and generates a preset identifier based on the device ratio. The preset identifier can be an identifier used to indicate the model, manufacturer, batch, or number. The system then determines whether the device identifier matches the preset identifier.

[0147] For example, taking the device identifier as the serial number of the terminal device and the device ratio as 50%, the cloud server generates a preset identifier based on the 50% device ratio, which is an odd number (i.e., 1, 3, 5, 7, 9). This preset identifier is sent to the terminal device. The terminal device checks if the last digit of the serial number is odd. If it is, the device identifier matches the preset identifier. In this way, the technical effect of requiring 50% of terminal devices to report can be achieved: terminal devices with an odd last digit in their serial number need to report, while those with an even last digit do not need to report.

[0148] For example, taking a device identifier that is the serial number of a terminal device and a device ratio of 20% as an example, the cloud server generates preset identifiers of 3 and 7 based on the 20% device ratio. These preset identifiers are sent to the terminal devices. The terminal devices determine whether the last digit of the serial number is 3 or 7. If so, it means the device identifier matches the preset identifier. In this way, the technical effect of requiring 20% ​​of terminal devices to report can be achieved.

[0149] Example 3: Receive the update identifier sent by the cloud server; the update identifier is generated by the cloud server based on business improvement needs; update the preset identifier of the device ratio indicator to the update identifier. Determine whether the device identifier and the update identifier match. If they match, it means the terminal device needs to collect data. If not, it means the terminal device does not need to collect data.

[0150] In this example, the cloud server needs to change the device ratio based on business improvements and generates an update identifier based on the changed device ratio. For example, this could be an increase or decrease in the number of reported terminal devices. The update identifier can be an identifier indicating the model, manufacturer, batch, or number, and the system determines whether the device identifier matches the update identifier.

[0151] For example, taking the device identifier as the serial number of the terminal device as an example, the cloud server needs to increase the number of reported terminal devices, changing the device ratio to 80%. The update identifier generated based on this 80% device ratio is between 1 and 8. This update identifier is sent to the terminal device, which checks if the last digit of its serial number is any one of 1 to 8. If it is, the device identifier matches the update identifier. In this way, the technical effect of requiring 80% of terminal devices to report can be achieved.

[0152] In this embodiment of the application, for the sampling control strategy that collects data according to the proportion of devices, it is possible to determine whether the current terminal device needs to report the data based on the generated random number, or it is possible to determine whether the current terminal device needs to report the data based on the preset or updated identifier issued by the cloud server, thereby improving the flexibility and diversity of the data collection strategy.

[0153] In this embodiment, the number of event information in the frequency, time period and device dimensions included in the sampling control strategy is limited through the verification process, thereby realizing a lightweight point-tracking mode, reducing the power consumption of terminal devices, and being able to count business failures or user behaviors in more processes or more fields, thus improving the accuracy and richness of point-tracking data.

[0154] In some embodiments, event information includes the event occurrence time. It is determined whether the event occurrence time is before the event tracking termination time. If so, the event information can be stored to complete the tracking of this event; or further verification can be performed on the event information. If not, the event information is discarded, meaning it is neither stored nor verified, reducing the power consumption and storage space of the terminal device. This allows for the tracking of other business failures or user behaviors, improving the comprehensiveness of the tracking data.

[0155] In this embodiment, the endpoint time is used to statistically analyze a temporary endpoint. For example, for a preset endpoint event A, if it is expected to be statistically analyzed for 3 months, the endpoint time for the preset endpoint event A can be set to the time corresponding to three months from the current point in time. For example, for a preset endpoint event A, if it is expected to be statistically analyzed up to a certain date, the endpoint time for the preset endpoint event A can be set to that date. By setting the endpoint time, unnecessary endpoints can be filtered out, improving the flexibility of the endpoint analysis.

[0156] It should be noted that the endpoint time is a special check set for certain temporary endpoint events. For endpoint events without an endpoint time set, it means that the endpoint event is not temporary and there is no need to perform the endpoint time check process.

[0157] In some embodiments, the system receives an update termination time sent by the cloud server and updates the event tracking termination time to the update termination time. It then determines whether the event occurrence time is before the update termination time. If so, the event information can be stored to complete the event tracking; or further verification can be performed on the event information. If not, the event information is discarded, meaning it is neither stored nor verified, reducing power consumption and storage space on the terminal device. This allows for the tracking of other business failures or user behaviors, improving the comprehensiveness of the tracking data.

[0158] In this embodiment, the logging termination time can be set on the terminal device side. That is, when the log engine sets the preset logging configuration information, it sets the termination time for certain temporary logging events in its logging strategy. Alternatively, the logging termination time can be dynamically issued by the cloud server. In practical applications, the cloud server dynamically identifies unnecessary logging events and sends the update termination time of the preset logging events to the terminal device. The terminal device updates the preset logging termination time of the events, modifying it to the update termination time. Then, it determines whether the event occurrence time is before the update termination time.

[0159] In this embodiment of the application, the timing strategy for timing termination time can determine whether the event information needs to be timing based on the preset timing termination time, or it can determine whether the event information needs to be timing based on the update termination time issued by the cloud server, thereby improving the flexibility and diversity of timing strategy.

[0160] In this embodiment of the application, the number of event information in the dimension of event termination time is limited through the verification process, thereby realizing a lightweight event tracking mode, reducing the power consumption of terminal devices, and enabling the collection of business failures or user behaviors in more processes or more fields, thus improving the accuracy and richness of event tracking data.

[0161] The following explains the pre-set information for each object in the second management strategy, including the management level, business or behavior.

[0162] In some embodiments, the monitoring level includes a fault monitoring level and a privacy monitoring level, and the event information includes the fault level and privacy level corresponding to a preset monitoring event.

[0163] For fault level verification, it is determined whether the fault level is greater than or equal to the fault tracking level. If so, the event information can be stored to complete the tracking of this event; or further verification can be performed on the event information. If not, the event information is discarded, meaning it is neither stored nor further verified, reducing the power consumption and storage space of the terminal device. This allows for the statistical analysis of other business faults or user behaviors, improving the comprehensiveness of the tracking data.

[0164] In this embodiment, the fault level indicates the severity of the fault, and the fault marking level refers to the lowest level of the fault that needs to be marked. In other words, a fault is marked only if the fault level is greater than or equal to the fault marking level, so that the marking meets the safety requirements and improves the effectiveness of the marking.

[0165] For privacy level verification, the system checks if the privacy level is less than or equal to the privacy tracking level. If so, the event information can be stored to complete the tracking of this event; or further verification can be performed on the event information. If not, the event information is discarded, meaning it is neither stored nor further verified, reducing the power consumption and storage space of the terminal device. This allows for the tracking of other business failures or user behaviors, improving the comprehensiveness of the tracking data.

[0166] In this embodiment, the privacy level indicates the user's sensitivity to information. The privacy tracking level refers to the lowest level of privacy that needs to be tracked; that is, tracking is only performed when the privacy level is less than or equal to the privacy tracking level, ensuring that tracking meets security requirements and improving tracking effectiveness.

[0167] For example, privacy levels can include Level 1 (L0, excluding sensitive user data), Level 2 (L1, including relatively sensitive user data), and Level 3 (L2, including highly sensitive user data). L0 can be non-personal user data such as application package names, which can be directly uploaded. Examples include the frequency of user application usage; for instance, application crashes, where the tracking type is a business failure and the failure level is very serious, without any personal user information, would be Level 1 (L0). L1 can be the frequency of user application usage, which is sensitive user data, and users can choose whether to upload it in their settings. When setting privacy tracking levels, if the user agrees to upload, the privacy tracking level can be set to L1; if the user does not agree, the privacy tracking level can be set to L0. L2 can be the user's identity information, which is not tracked. Although identity information is transmitted between different layers, it is not written to the final file system, does not occupy space on the terminal device, and is not sent to the cloud server.

[0168] In this embodiment, the event information in the two dimensions of tracking level and privacy level is filtered out for non-security requirements through the verification process, thereby realizing a lightweight tracking mode, reducing the power consumption of terminal devices, and enabling the collection of business failures or user behaviors in more processes or more fields, thus improving the accuracy and richness of tracking data.

[0169] In some embodiments, the fault level refers to the severity of the entire event, and the privacy level refers to the sensitivity of the entire event. The preset event tracking also includes multiple objects, and the event information includes the attribute information of each object. The multiple objects included in each preset event tracking are not entirely the same. For business fault types, the event information includes the attribute information of multiple objects related to the business, and these objects are fields related to the business. For user behavior types, the event information includes the attribute information of multiple objects related to the behavior, and these objects are fields related to the behavior. The content of the fields serves as the attribute information of the objects. Two examples are provided below to illustrate this.

[0170] Example 1: Each object corresponds to one attribute and one preset information. The attribute is captured from the current event, and the preset information is pre-set attribute information that meets security requirements. For attribute validation, it's determined whether each attribute matches each preset information. If they do, the attribute information of multiple objects in the current event information can be stored to complete the event tracking; or further validation can be performed on the current event information. If there are objects whose attribute information does not match the preset information, these objects are considered non-compliant with security requirements. The attribute information of all objects except those that do not meet security requirements is stored to complete the event tracking; or further validation can be performed on the current event information.

[0171] In this example, if an object's attribute information matches its preset information, it means the attribute information matches the preset information, the object meets the security requirements, and its attribute information can be stored. If an object's attribute information does not match its preset information, it means the attribute information does not match the preset information, the object does not meet the security requirements, and its attribute information is not stored. This process is repeated for each object, checking whether its attribute information matches the preset information, filtering out objects that do not meet the security requirements, and storing the attribute information of objects that do meet the security requirements. This satisfies the security requirements and improves the effectiveness of data tracking.

[0172] Example 2: Each object corresponds to one attribute. If the object is found in the tracking strategy, it means that the object meets the security requirements, and its attribute information is stored in the event information. If the object is not found in the tracking strategy, it means that the object does not meet the security requirements, and its attribute information is filtered out from the event information. This process is repeated for each object, ultimately storing the attribute information of all objects except those that do not meet the security requirements to complete the tracking of this event; alternatively, further validation of the event information may be performed.

[0173] This example can be understood as the preset information, or attribute information, of objects in the tracking strategy. If the object is found in the tracking strategy, it means that its attribute information matches the preset information (i.e., a match). If the object is not found in the tracking strategy, it means that its attribute information does not match the preset information (i.e., a mismatch). In other words, the preset information is pre-set attribute information that meets security requirements; attribute information that is not pre-set is directly filtered out. This process continues, filtering out objects that do not meet security requirements and storing the attribute information of objects that do meet the security requirements. This satisfies security requirements and improves the effectiveness of tracking.

[0174] It should be noted that the fault level and privacy level mentioned above apply to the entire event, while attribute information applies to multiple objects within the event. If the fault level or privacy level of the entire event does not meet security requirements, the entire event is discarded. If some attribute information within the entire event does not meet security requirements, only the attribute information that does not meet security requirements is discarded. For example, for a tagging event with a privacy level of "protected," if its privacy level does not meet security requirements, the event information is discarded. For a tagging event with a privacy level of "public" and a certain field being "protected," if its privacy level meets security requirements, but that field does not meet security requirements, that field is discarded, and the event information excluding that field is stored.

[0175] In this embodiment, the event information of the object's attribute dimension is filtered out to meet security requirements through the verification process, thereby realizing a lightweight tracking mode, reducing the power consumption of the terminal device, and enabling the collection of business failures or user behaviors in more processes or more fields, thus improving the accuracy and richness of the tracking data.

[0176] In some embodiments, the acquired event information, as well as the process of verifying and storing the event information, all require storage space. Due to limited storage space, a maximum cache size is set here. If the maximum cache size is not reached, the event information of the acquired preset marker events is temporarily cached. Then, the event information is read from the temporary cache location, and the event information is verified according to the marker strategy corresponding to the event identifier in the preset marker configuration information to obtain the verification result. If the maximum cache size is reached or exceeded, the earliest stored event information is overwritten, or the latest event information is discarded. By setting a maximum cache size, the space occupied by the terminal device is reduced, enabling timely processing of event information and improving data processing efficiency.

[0177] In some embodiments, event information includes a tracking type, which is either a business failure type or a user behavior type. For each business failure type and user behavior type, a corresponding tracking strategy is used to validate the event information. After validation, the event information for the business failure type and user behavior type is stored separately based on the validation results, resulting in a storage result. In other words, business failure types and user behavior types are stored separately. When reporting to the cloud server, the tracking data for the business failure type (i.e., the first tracking data) is sent to the cloud server according to a first preset format; the tracking data for the user behavior type (i.e., the second tracking data) is sent to the cloud server according to a second preset format. The tracking data for the business failure type and user behavior type are sent to the cloud server through different sending channels.

[0178] For the data tracking types, business failure types and user behavior types are verified and stored separately. When reporting tracking data to the cloud server, they are also reported separately: business failure type tracking data is reported through the first transmission channel, while user behavior type tracking data is reported through the second transmission channel, improving reporting efficiency. Furthermore, the cloud server stores business failure type and user behavior type tracking data separately for future improvements and optimizations.

[0179] In some embodiments, the operating system of the terminal device includes an application layer, an application framework layer, a local layer, and a kernel layer. The application framework layer includes a first tracking interface for obtaining event information of a preset tracking event when such event occurs at the application layer. The local layer includes a second tracking interface for obtaining event information of a preset tracking event when such event occurs at the local layer. The kernel layer includes a third tracking interface for obtaining event information of a preset tracking event when such event occurs at the kernel layer.

[0180] In this embodiment of the application, different point-tracking interfaces are included at different layers of the software system, which can support different languages ​​to support point-tracking of business at different layers, thereby improving the universality and comprehensiveness of point-tracking.

[0181] The process of verifying event information is explained based on the first and second point-of-sale strategies described above. For example... Figure 4 As shown, Figure 4 This is a flowchart illustrating another dot-marking method provided in an embodiment of this application.

[0182] S201. When a preset event occurs during the operation of the terminal device, obtain the event information of the preset event; the event information includes the event identifier, the event type, the device identifier of the terminal device, the event occurrence time, the fault level, the privacy level, and the attribute information of each object; wherein, the preset event includes the occurrence of a business fault and the occurrence of a preset user behavior, and the event type includes the business fault type and the user behavior type.

[0183] In this embodiment, the program that pre-installs event tracking in the terminal device can detect whether a preset event (business failure or preset user behavior) occurs during the operation of the terminal device. Upon detecting a preset event, the program captures the event information. After capturing the event information, the program calls the event tracking interface to obtain the event details.

[0184] S202. Determine whether the number of times the current process containing the preset event has made a point within the preset time does not exceed the process limit.

[0185] If yes, then execute S203. If no, then execute S218.

[0186] In this embodiment, a point-based rate limiting method is used to control the number of event information in a single process. Event information that exceeds the process's upper limit within a preset time period is discarded and not processed further. By controlling the number of event information in a single process, the power consumption of the terminal device is reduced. Furthermore, point data from other processes can be collected, improving the comprehensiveness of the point data.

[0187] S203. Determine if the maximum cache size has not been reached.

[0188] If yes, then execute S204; otherwise, execute S218.

[0189] S204. Temporarily cache event information.

[0190] By setting a maximum cache size, temporary caching is performed when the maximum cache size is not reached, reducing the space occupied by the terminal device, so as to process event information in a timely manner and improve data processing efficiency.

[0191] S205. Read event information from the temporary cache location and determine whether the number of dots within the preset period is less than or equal to the upper limit of the number of dots.

[0192] If yes, then execute S206; otherwise, execute S218.

[0193] This step includes the following two scenarios: When the tracking type is a business fault type, determine whether the number of tracking points for the business fault type within the first preset period is less than or equal to the upper limit for fault tracking points. When the tracking type is a user behavior type, determine whether the number of tracking points for the user behavior type within the second preset period is less than or equal to the upper limit for behavior tracking points.

[0194] By setting separate quantity limits for business fault types and user behavior types, we can reduce the occurrence of situations where one type of data point has a large number of data points while the other type has a small number of data points, thereby improving the comprehensiveness of the data points.

[0195] By controlling the upper limit of each dot type within a preset period, the power consumption of the terminal device can be reduced.

[0196] S206. Determine whether the sampling control strategy indicates full data collection.

[0197] If yes, then execute S210; otherwise, execute S207.

[0198] S207. When the sampling control strategy indicates that sampling should be performed within a preset time period, determine whether the time of the event occurs within the preset time period.

[0199] If yes, then execute S210; otherwise, execute S218.

[0200] S208. When the sampling control strategy indicates that sampling should be performed at a preset frequency, determine whether the number of samplings corresponding to the event identifier matches the sampling interval corresponding to the preset frequency.

[0201] If yes, then execute S210; otherwise, execute S218.

[0202] S209. When the sampling control strategy indicates that sampling should be carried out according to the proportion of devices, determine whether the terminal device needs to collect data.

[0203] This step can be achieved in the following two ways:

[0204] Generate random numbers; if the device identifier matches the random number, determine which terminal device needs to collect data;

[0205] Alternatively, if the device identifier matches the preset identifier of the device ratio indicator, it can be determined that the terminal device needs to collect data; whereby the preset identifier is generated by the cloud server based on the device ratio.

[0206] Before S209, S301 and S302 can be executed first.

[0207] S301, Receive the update identifier sent by the cloud server; the update identifier is generated by the cloud server based on business improvement needs.

[0208] S302. Update the preset identifier of the equipment ratio indicator to the updated identifier.

[0209] Following S302, S209 determines whether the terminal device needs to collect data by judging whether the device identifier and the update identifier match.

[0210] In this embodiment, the number of event information is limited by preset frequency, preset time period and device ratio, which realizes a lightweight point-tracking mode, reduces the power consumption of terminal devices, and can then count more processes or business failures or user behaviors in more fields, thereby improving the accuracy and richness of point-tracking data.

[0211] S210. Determine if the event occurred before the end time of the tracking.

[0212] If yes, then execute S211; otherwise, execute S218.

[0213] Before S210, S401 and S402 can be executed first.

[0214] S401, Receive the update termination time sent by the cloud server.

[0215] S402. Update the dot termination time to the update termination time.

[0216] Following S402, S210 determines whether to proceed to the next stage of verification by checking whether the event occurrence time is before the update termination time.

[0217] In this embodiment, the timing strategy for the timing termination time can determine whether the event information needs to be timing based on a pre-set timing termination time or an update termination time issued by the cloud server, thus improving the flexibility and diversity of the timing strategy. Furthermore, by limiting the amount of event information through the timing termination time, a lightweight timing mode is achieved, reducing the power consumption of terminal devices. This allows for the collection of data on business failures or user behaviors in more processes or areas, improving the accuracy and richness of the timing data.

[0218] S211. Determine if the fault level is greater than or equal to the fault checkpoint level.

[0219] If yes, then execute S212; otherwise, execute S218.

[0220] By verifying the security requirements of event information through fault point levels, event information with low fault levels is filtered out, improving the effectiveness of the data, realizing a lightweight point-of-care mode, reducing the power consumption of terminal devices, and thus enabling the collection of business faults or user behaviors in more processes or more areas, thereby improving the accuracy and richness of point-of-care data.

[0221] S212. Determine if the privacy level is less than or equal to the privacy point level.

[0222] If yes, then execute S213; otherwise, execute S218.

[0223] By verifying the security requirements of event information through privacy tracking levels, filtering event information with higher privacy levels, data security is improved, a lightweight tracking mode is achieved, the power consumption of terminal devices is reduced, and business failures or user behaviors in more processes or more areas can be statistically analyzed, thereby improving the accuracy and richness of tracking data.

[0224] S213. Determine whether each attribute information corresponds and matches each preset information one by one.

[0225] If yes, then execute S214; otherwise, if there are objects that do not meet the security requirements, execute S215; if multiple objects are objects that do not meet the security requirements, execute S218. Objects that do not meet the security requirements refer to objects whose attribute information does not match the preset information.

[0226] S214. Store the event identifier, point type, terminal device identifier, event occurrence time, fault point level, privacy point level, and attribute information of each object in the event information to obtain the storage result; the storage result includes the first point data corresponding to the business fault type and the second point data corresponding to the user behavior type.

[0227] S215. Store the event identifier, event type, terminal device identifier, event occurrence time, fault event level, privacy event level, and attribute information of objects other than those that do not meet security requirements in the event information; the storage results include the first event data corresponding to the business fault type and the second event data corresponding to the user behavior type.

[0228] The security requirement verification of event information is carried out through preset information, and the event information with mismatched attribute information and preset information is filtered, which improves the security of data, realizes a lightweight logging mode, reduces the power consumption of terminal devices, and then more business failures or user behaviors in more processes or more fields can be counted, improving the accuracy and richness of the logged data.

[0229] After S214 or S215, execute S216 and S217.

[0230] S216: Send the first logged data to the cloud server according to the first preset format.

[0231] S217: Send the second logged data to the cloud server according to the second preset format.

[0232] S218: Discard the current event information and end the verification process of the current event.

[0233] It should be noted that the event information includes an event identifier and a logging type. It may also include at least one of the event occurrence time, the device identifier of the terminal device, the fault logging level, the privacy logging level, and the attribute information of each object. The specific parameters included in the event information of each preset logging event can be configured in advance by a program for pre-buried points.

[0234] Exemplarily, the program for pre-buried points configures in advance that the event information includes the following parameters: event identifier (Event id), logging type (model), fault level (Fault Level), fault type (Fault Type), privacy level (Privacy Level), valid duration (Valid Time), and the attribute information of the object can be in the following manner: <Paramid="0", name="parameter 1", type="parameter type", length="parameter length">; <param id＝"1"，name＝"参数2"，type＝"参数类型"，length＝"参数长度"> The above is only an exemplary illustration and does not mean that the embodiments of the present application are limited thereto.

[0235] For each preset logging event, the steps of restricting the quantity by using the process upper limit value, the maximum cache quantity, the logging upper limit value, the preset period, the preset frequency, the device ratio, and the logging termination time, and the steps of filtering the steps that do not meet the security requirements by using the fault logging level, the privacy logging level, and the preset information of each of the multiple objects do not necessarily have to execute these steps, and some of these steps can be executed.

[0236] For example, the event information is stored when at least one of the following conditions is met: the number of times the current process containing the preset event does not exceed the process limit within a preset duration; the maximum cache size has not been reached; the number of times the event occurs within a preset period is less than or equal to the maximum limit; the event occurs within a preset time period; the number of collections corresponding to the event identifier matches the sampling interval corresponding to the preset frequency; the terminal device needs to collect data; the event occurs before the event termination time; the fault level is greater than or equal to the fault event level; the privacy level is less than or equal to the privacy event level; or the object's attribute information matches its preset information.

[0237] This application's embodiments achieve point-based rate limiting through quantity restrictions and security filtering verification processes, reducing the number of points to be recorded and lowering the power consumption of terminal devices. By limiting the number of points recorded and implementing security filtering, storage space usage is reduced, allowing for the statistical analysis of business faults or user behaviors in more processes or areas, thus improving the comprehensiveness of the point-based data. This simultaneously achieves the technical goals of problem localization and business improvement statistics.

[0238] Based on the above Figure 3 and Figure 4 The dot-marking method shown, combined with Figure 2 Software system framework, such as Figure 5 As shown, Figure 5 This is a schematic diagram illustrating the framework of a dot-marking process provided in an embodiment of this application. Based on the above... Figures 1-4 ,exist Figure 5 Based on the provided framework of the data logging process, the data logging method is explained in conjunction with the interaction between the framework layers of the software system, such as... Figure 6 As shown, Figure 6 This is a schematic diagram of a service interaction process provided in an embodiment of this application.

[0239] As mentioned above Figure 2 As shown, the software system of the terminal device includes: an application layer, an application framework layer, a local layer, a hardware abstraction layer, and a kernel layer. The application framework layer includes a first endpoint interface, the local layer includes a second endpoint interface, and the kernel layer includes a third endpoint interface.

[0240] S11. Detect business failures or user behavior, and capture event information.

[0241] Applications with pre-installed event tracking can detect business failures or user actions. Upon detecting such failures or actions, event information is captured.

[0242] S12, Obtain event information.

[0243] The first event interface of the application framework layer obtains event information from the application layer.

[0244] S13. Write the event information to the hardware abstraction layer.

[0245] The flow of event information is from top to bottom. That is, the event information reaches the kernel layer after passing through the hardware abstraction layer. Therefore, by calling the first tracking interface, the event information is obtained from the program that has been pre-tracked and the event information is written to the hardware abstraction layer.

[0246] S21. Detect business failures or user behavior, and obtain event information.

[0247] S22. Write the event information to the hardware abstraction layer.

[0248] The pre-implemented event tracking program in the local layer can detect whether a business failure or user behavior has occurred. Upon detecting a business failure or user behavior, it captures event information, calls the second event tracking interface to obtain the event information from the pre-implemented program, and writes the event information to the hardware abstraction layer.

[0249] S31. Write the event information to the device node in the kernel layer.

[0250] The hardware abstraction layer writes event information to device nodes in the kernel layer for temporary storage, thus transferring the event information from user space to kernel space.

[0251] S32. Detect business failures or user behavior, obtain event information, and cache the event information to the device node.

[0252] The pre-installed event tracking program in the kernel layer can detect whether a business failure or user behavior has occurred. Upon detecting such a failure or behavior, it captures event information, calls a third-party event tracking interface to retrieve the event information from the pre-installed program, and caches the event information on the device node.

[0253] A device node is a temporary cache space used to temporarily cache event information. It has a maximum cache size and stores event information (business failures or user behaviors) from the application layer, local layer, and kernel layer. When the maximum cache size is not reached, event information for the preset events is temporarily cached. When the maximum cache size is reached or exceeded, the oldest stored event information is overwritten, or the latest event information is discarded.

[0254] like Figure 5As shown, when system desktop and configuration events occur at the application layer, the first event tracking interface in the application framework layer is called to write event information at the hardware abstraction layer (HAL), and the number of event messages per process is controlled using a rate-limiting method. When communication events occur at the local layer, the second event tracking interface is called to write event information at the HAL, and the number of event messages per process is controlled using a rate-limiting method. When driver events occur at the kernel layer, the third event tracking interface is called to write event information at the HAL, and the number of event messages per process is controlled using a rate-limiting method. Finally, the HAL writes the event information to the device node in the kernel layer for temporary storage, thus transferring the event information from user space to kernel space.

[0255] As business operations increase, so too does the number of event tracking points, leading to a gradual increase in the number of tracking points for a single process. In this embodiment, front-end rate limiting is implemented when writing event information in the HAL layer to reduce the power consumption of the terminal device. This also allows for the collection of tracking data from other processes, improving the comprehensiveness of the tracking data.

[0256] S33. Read event information from device nodes in the kernel layer.

[0257] The logging engine in the local layer reads event information from a temporary cache location in the kernel layer (i.e., the device node).

[0258] S34. The cloud server issues the proportion of devices that need to upload tracking data or preset identifiers, as well as the tracking sunset mechanism.

[0259] The log engine in the local layer receives sampling and control policies for devices from the cloud server. For example, it may specify the proportion of devices that need to upload tracking data, such as 50% or devices whose serial numbers end in an odd number. It may also specify the preset identifiers that need to upload tracking data, such as devices whose serial numbers end in 5.

[0260] The log engine in the local layer also receives a sunset event tracking mechanism from the cloud server. This sunset event tracking mechanism sets the termination time for specific event information. The cloud dynamically identifies unnecessary tracking events and sends the sunset event tracking mechanism to the log engine, improving the flexibility of tracking.

[0261] S35. Based on the preset point configuration information, combined with the device ratio or preset identifier issued by the cloud server, and the point sunset mechanism, verify the event information, store the event information according to the verification result, and obtain the storage result.

[0262] The log engine in the local layer updates the logging policy corresponding to the event identifier in the preset logging configuration information based on the update information (device ratio or preset identifier, and logging sunset mechanism) issued by the cloud server, and then verifies the event information to obtain the verification result. The event information is then stored based on the verification result to obtain the storage result.

[0263] S36. Send the dotted data from the stored results to the cloud server.

[0264] like Figure 5 As shown, the kernel-level log engine reads event information from device nodes and performs the following checks based on business fault types and user behavior types: sunset logging mechanism (i.e., verifying whether the event occurred before the logging end time), fault level verification (i.e., verifying that the fault level is greater than or equal to the fault logging level), quota control (i.e., verifying that the number of logging events within a preset period is less than or equal to the logging limit), sampling control strategy, privacy processing (i.e., verifying that the privacy level is less than or equal to the privacy logging level), and security verification (i.e., verifying that the attribute information matches the preset information). After the above verification process, the data is written to the logging points, which means storing the logging data. After a period of time or after reaching a certain quantity, the logging data is packaged as private logs and sent to the cloud server.

[0265] In this embodiment, the kernel-level log engine includes multiple verification methods and performs lightweight backend sampling based on the logging strategy corresponding to the preset logging events, thereby reducing the amount of data and lowering the load on the terminal device side and the storage pressure on the cloud server side.

[0266] The data points indicating a business fault type in the storage results are sent to the cloud server according to the first preset format; the data points indicating a user behavior type in the storage results are sent to the cloud server according to the second preset format.

[0267] The above Figure 5 and Figure 6 The verification process for event information can be found in the description of the verification process above, and will not be repeated here.

[0268] It should be noted that the point-tracking method provided in this application embodiment can be obtained by decompiling the source code to obtain the point-tracking process of the terminal device. If the terminal device uses any one or at least two of the following methods: setting single-process point-tracking limit, point-tracking sunset, quota control, sampling control, privacy verification, fault verification, and security verification of attribute information, then it indicates that the terminal device adopts this solution.

[0269] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, can implement the steps in the various method embodiments described above.

[0270] 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 instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of 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 via wired (e.g., coaxial cable, fiber optic, Digital Subscriber Line, DSL) 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 media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., Digital Versatile Discs (DVDs)), or semiconductor media (e.g., Solid State Disks (SSDs)).

[0271] The above-described embodiments are optional embodiments provided by this application and are not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the technical scope disclosed in this application should be included within the protection scope of this application.

Claims

1. A dot-marking method, characterized in that, Applied to a terminal device, the method includes: When a preset event occurs during the operation of the terminal device, the event information of the preset event is obtained; the preset event includes a service failure and a preset user behavior, and the event information includes an event identifier; According to the event identifier corresponding to the event tracking strategy in the preset tracking configuration information, the event information is verified to obtain the verification result. The tracking strategy includes at least one of a first tracking strategy for limiting the number of event information and a second tracking strategy for filtering event information that does not meet security requirements. The event information is stored based on the verification result; The first tracking strategy includes at least one of the following: tracking upper limit, sampling control strategy, tracking termination time, and tracking flow restriction strategy; the second tracking strategy includes at least one of the following: tracking level, and preset information of each object in business or behavior.

2. The method as described in claim 1, characterized in that, The step of verifying the event information according to the event identifier corresponding to the preset event configuration information and obtaining the verification result includes: If the current process of the preset event satisfies the event limiting policy, the event information is verified according to the event limiting policy corresponding to the event identifier to obtain the verification result; wherein, the event limiting policy is used to indicate that the number of events of a single process within a preset time does not exceed the process limit value.

3. The method as described in claim 1, characterized in that, The event information includes a point type, the point strategy includes a first point strategy, the first point strategy includes a point upper limit value, and the point upper limit value includes a fault point upper limit value within a first preset period and a behavior point upper limit value within a second preset period. The step of storing the event information based on the verification result includes: If the verification result indicates that the point type is a business fault type, and the number of points for the business fault type within the first preset period is less than or equal to the upper limit of the fault points, the event information is stored. If the verification result indicates that the point type is a user behavior type, and the number of points for the user behavior type within the second preset period is less than or equal to the upper limit of the behavior points, the event information is stored.

4. The method as described in claim 1, characterized in that, The event information includes the event occurrence time, and the tracking strategy includes the first tracking strategy, which in turn includes a sampling control strategy. The step of storing the event information based on the verification result includes: When the sampling control strategy instructs full data collection, the event information is stored; When the sampling control strategy indicates that data is collected within a preset time period, and the verification result indicates that the event occurred within the preset time period, the event information is stored. When the sampling control strategy indicates that sampling is performed according to the sampling conditions and the verification result indicates that the sampling conditions are met, the event information is stored.

5. The method as described in claim 4, characterized in that, The sampling conditions include at least one of a preset frequency and a device ratio; The storage of the event information when the sampling control strategy indicates that sampling is performed according to the sampling conditions and the verification result indicates that the sampling conditions are met includes: When the sampling control strategy indicates that sampling should be performed at a preset frequency, and the verification result indicates that the number of samplings corresponding to the event identifier matches the sampling interval corresponding to the preset frequency, the event information is stored. When the sampling control strategy indicates that data should be collected according to the device ratio, and the verification result indicates that the terminal device needs to collect data, the event information is stored.

6. The method as described in claim 5, characterized in that, The event information also includes the device identifier of the terminal device; The method further includes: When the sampling control strategy indicates that sampling should be conducted according to a certain device ratio, a random number is generated; when the device identifier matches the random number, the verification result indicates that the terminal device needs to collect data. Alternatively, if the sampling control strategy indicates that sampling should be conducted according to a device ratio, and the device identifier matches a preset identifier indicated by the device ratio, the verification result indicates that the terminal device needs to collect data; wherein, the preset identifier is generated by the cloud server based on the device ratio.

7. The method as described in claim 6, characterized in that, Before determining that the verification result indicates the terminal device needs to collect data, if the device identifier matches a preset identifier of the device ratio indicator, the method further includes: Receive an update identifier sent by the cloud server; the update identifier is generated by the cloud server based on business improvement needs; Update the preset identifier of the device ratio indicator to the updated identifier.

8. The method according to any one of claims 1-7, characterized in that, The point-marking strategy includes the first point-marking strategy, the first point-marking strategy includes a point-marking termination time, and the event information includes the event occurrence time. The step of storing the event information based on the verification result includes: If the verification result indicates that the event occurred before the dot termination time, the event information is stored.

9. The method as described in claim 8, characterized in that, Before storing the event information if the verification result indicates that the event occurred before the timing termination time, the method further includes: Receive the update termination time sent by the cloud server; Update the dot termination time to the updated termination time.

10. The method according to any one of claims 1, 3-7, characterized in that, The point-marking strategy includes the first point-marking strategy, which includes a point-marking rate-limiting strategy; the point-marking rate-limiting strategy is used to indicate that the number of points marked by a single process within a preset time period does not exceed the process upper limit value. The step of storing the event information based on the verification result includes: If the verification result indicates that the current process of the preset event satisfies the event limiting policy, the event information is stored.

11. The method according to any one of claims 1-7, characterized in that, The point-marking strategy includes a second point-marking strategy, the second point-marking strategy includes point-marking levels, the point-marking levels include fault point-marking levels, and the event information includes the fault level corresponding to the preset point-marking event. The step of storing the event information based on the verification result includes: If the verification result indicates that the fault level is greater than or equal to the fault marker level, the event information is stored.

12. The method according to any one of claims 1-7, characterized in that, The tracking strategy includes a second tracking strategy, the second tracking strategy includes tracking levels, the tracking levels include privacy tracking levels, and the event information includes the privacy level corresponding to the preset tracking event; The step of storing the event information based on the verification result includes: If the verification result indicates that the privacy level is less than or equal to the privacy rating level, the event information is stored.

13. The method according to any one of claims 1-7, characterized in that, The tracking strategy includes the second tracking strategy, which includes preset information for each object in the business or behavior, and the event information includes the attribute information of each object. The step of storing the event information based on the verification result includes: If the verification result indicates that each attribute information matches each preset information one by one, the attribute information of each object in the event information is stored. If the verification result indicates the existence of an object that does not meet the security requirements, the attribute information of the objects in the event information other than the object that does not meet the security requirements is stored; wherein, the object that does not meet the security requirements indicates an object whose attribute information does not match the preset information.

14. The method according to any one of claims 1-7, characterized in that, Before verifying the event information according to the event identifier corresponding to the event strategy in the preset event configuration information and obtaining the verification result, the method further includes: If the maximum cache limit is not reached, the event information is temporarily cached. The step of verifying the event information according to the event identifier corresponding to the preset event configuration information and obtaining the verification result includes: The event information is read from the temporary cache location, and the event information is verified according to the marking strategy corresponding to the event identifier in the preset marking configuration information to obtain the verification result.

15. The method according to any one of claims 1-7, characterized in that, The event information includes the point type; After storing the event information based on the verification result, the method further includes: The first point data in the storage result obtained by storing the event information is sent to the cloud server according to the first preset format; the first point data indicates that the point type is a business fault type. The second point data in the storage result is sent to the cloud server according to the second preset format; the second point data indicates that the point data is user behavior type point data.

16. The method according to any one of claims 1-7, characterized in that, The operating system of the terminal device includes an application layer, an application framework layer, a native layer, and a kernel layer. When a preset timing event occurs during the operation of the terminal device, the event information of the preset timing event is obtained, including: When the preset event occurs at the application layer, the event information of the preset event is obtained through the first event interface of the application framework layer. When the preset marker event occurs in the local layer, the event information of the preset marker event is obtained through the second marker interface of the local layer; When the preset timing event occurs in the kernel layer, the event information of the preset timing event is obtained through the third timing interface of the kernel layer.

17. A terminal device, characterized in that, The terminal device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program, when executed by the processor, implements the method as described in any one of claims 1-16.

18. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores instructions that, when executed on a computer, cause the computer to perform the method as described in any one of claims 1-16.

19. A computer program product containing instructions, characterized in that, When it is run on a computer, it causes the computer to perform the method as described in any one of claims 1-16.

Images