File uploading method and device, terminal and storage medium

Abstract

The invention provides a file uploading method and device, a terminal and a storage medium. The method is applied to the terminal and comprises the following steps: in response to a touch event of a user on a screen of the terminal, determining a target window corresponding to the touch event from at least one window managed by the terminal; determining a target view element corresponding to the touch event from at least one view element of the target window; obtaining an identifier of a target application program corresponding to the target window, and obtaining an identifier of a target view element; recording the touch event, an identifier of a target application program corresponding to the target window and an identifier of the target view element in a pre-created log file in an associated manner; and uploading the log file to a server corresponding to the terminal. Based on the scheme, the touch event, the identifier of the target application program corresponding to the target window and the identifier of the target view element can be uploaded to the server in the form of the log file, and meanwhile, the effects of reducing the development workload and improving the terminal performance are achieved.

Description

Technical Field

[0001] The present application relates to the field of terminal technology, and more specifically, to a file uploading method, device, terminal and storage medium in the field of terminal technology. Background Art

[0002] At present, the mainstream implementation of tracking technology is to integrate the tracking SDK (Software Development Kit) into the terminal application. The tracking SDK is responsible for collecting relevant data within the application and uploading it to the server corresponding to the application for analysis. However, the current mainstream implementation scheme has significant limitations. It can only collect data from specific applications that have integrated the tracking SDK. For multi-application environments, such as vehicles, its applicability is greatly reduced. Vehicles often have multiple applications installed, some of which come from third parties. Requiring vehicle developers to add a tracking SDK for each application separately not only increases the development workload, but also the simultaneous operation of multiple tracking SDKs will occupy a large amount of the vehicle's computing resources, affecting the overall performance of the terminal.

[0003] In short, the above solution of adding tracking SDKs to different applications has the problem of large development workload and affecting the overall performance of the terminal. Summary of the invention

[0004] The present application provides a file uploading method, device, terminal and storage medium. The method can upload touch events, the identification of the target application corresponding to the target window, and the identification of the target view element to the server in the form of a log file, while reducing the development workload and improving the terminal performance.

[0005] In a first aspect, a file uploading method is provided, which is applied to a terminal, and the method comprises:

[0006] In response to a touch event of a user on a screen of a terminal, determining a target window corresponding to the touch event from at least one window managed by the terminal;

[0007] Determine, from at least one view element of the target window, a target view element corresponding to the touch event;

[0008] Obtaining the ID of the target application corresponding to the target window, and obtaining the ID of the target view element;

[0009] The touch event, the identifier of the target application corresponding to the target window, and the identifier of the target view element are recorded in association with each other in a pre-created log file;

[0010] Upload the log file to the server corresponding to the terminal.

[0011] Through the above scheme, first of all, the method is applied to the terminal, which can uniformly respond to and process the user's touch events on the screen, without the need to separately integrate the tracking SDK for each application, thereby greatly reducing the workload of developers. Secondly, by determining the target window and target view element corresponding to the touch event from the window managed by the terminal, and obtaining their identifiers, accurate capture of user behavior is achieved without relying on the simultaneous operation of multiple tracking SDKs, effectively reducing the occupancy of the terminal's computing resources. Finally, the touch event, the identifier of the target application, and the identifier of the target view element are associated and recorded in a pre-created log file, and uploaded to the server, ensuring the integrity and real-time nature of the data, which is convenient for subsequent analysis and processing. In this way, it can reduce the development workload and improve terminal performance.

[0012] In combination with the first aspect, in some possible implementations, in response to a touch event of a user on the screen of the terminal, determining a target window corresponding to the touch event from at least one window managed by the terminal includes: determining, in response to a touch event of a user on the screen of the terminal, a pixel coordinate range of each window in at least one window managed by the terminal; determining at least one window whose pixel coordinate range contains pixel coordinates indicated by the touch event as a candidate window; determining the hierarchy of each candidate window in at least one candidate window; and determining the candidate window with the highest hierarchy as the target window.

[0013] Through the above solution, the target window corresponding to the touch event is determined from the window managed by the terminal, and its identifier is obtained, so as to accurately capture the user behavior. In this process, there is no need to rely on the simultaneous operation of multiple tracking SDKs, which effectively reduces the computing resource usage of the terminal, improves the performance of the terminal, and effectively reduces the development workload.

[0014] In combination with the first aspect and the above-mentioned implementation methods, in some possible implementation methods, determining a target view element corresponding to a touch event from at least one view element of the target window includes: obtaining a view tree of the target window, wherein the view tree is composed of at least one view element; determining a pixel coordinate range of each view element in the view tree; determining at least one view element whose pixel coordinate range contains the pixel coordinates indicated by the touch event as a candidate view element; determining a level of each candidate view element in the at least one candidate view element in the view tree; and determining the candidate view element with the highest level as the target view element.

[0015] Through the above scheme, the view tree of the target window is first obtained, and the pixel coordinate range of each view element therein is determined, which provides a reliable premise for the subsequent determination of the target view element. Secondly, by determining the view element whose pixel coordinate range contains the pixel coordinate indicated by the touch event as a candidate view element, and further screening each candidate view element according to its level in the view tree, the candidate view element with the highest level can be accurately located and determined as the target view element. This implementation method not only improves the accuracy of the determination of the target view element, but also effectively reduces the occupation of computing resources, improves the performance of the terminal, and effectively reduces the amount of development.

[0016] In combination with the first aspect and the above-mentioned implementation methods, in some possible implementation methods, after obtaining the identifier of the target application corresponding to the target window and obtaining the identifier of the target view element, before recording the touch event, the identifier of the target application corresponding to the target window, and the identifier of the target view element in a pre-created log file, it also includes: transmitting the touch event and the identifier of the target view element to the target application, so that the target application can choose to consume or not consume the touch event according to the identifier of the target view element; obtaining the consumption result of the touch event by the target application; and recording the touch event, the identifier of the target application corresponding to the target window, and the identifier of the target view element in a pre-created log file, including: recording the touch event, the identifier of the target application corresponding to the target window, the identifier of the target view element, and the consumption result of the touch event by the target application in a pre-created log file.

[0017] Through the above solution, the consumption results of the touch event by the target application can be recorded in the log file, which effectively improves the data dimension of the log file, so that the user behavior of the terminal can be analyzed more accurately in the subsequent use of the log file.

[0018] In combination with the first aspect and the above-mentioned implementation methods, in some possible implementation methods, the touch event, the identifier of the target application corresponding to the target window, the identifier of the target view element, and the consumption result of the touch event by the target application are associated and recorded in a pre-created log file, including: if the consumption result of the touch event indicates that the touch event is consumed by the target application, then the touch event, the identifier of the target application corresponding to the target window, the identifier of the target view element, and the consumption result of the touch event by the target application are associated and recorded in a pre-created log file.

[0019] Through the above solution, user behavior data is recorded in the log file only when the touch event is consumed, which can avoid storing a large amount of invalid data in the log file, thereby reducing the size of the log file, improving storage efficiency and also improving the readability of the log file.

[0020] In combination with the first aspect and the above-mentioned implementation methods, in some possible implementation methods, before uploading the log file to the server corresponding to the terminal, it also includes: obtaining the terminal identifier, wherein the terminal identifier is pre-bound to the terminal user information; and recording the terminal identifier in the log file.

[0021] Through the above solution, before uploading the log file to the server corresponding to the terminal, the terminal identifier is first obtained and recorded in the log file. Since the terminal identifier is pre-bound to the terminal user information, recording the terminal identifier in the log file actually indirectly associates the user information. This enables the subsequent analysis and processing of the log file to more accurately locate the specific user, thereby improving the accuracy and effectiveness of data analysis.

[0022] In combination with the first aspect and the above-mentioned implementation methods, in some possible implementation methods, obtaining the identifier of the target application corresponding to the target window includes: obtaining the process number of the target application; determining the identifier of the target application based on the process number of the target application and the mapping relationship between the process number and the identifier of the application.

[0023] Through the above scheme, the process ID of the target application is first obtained, and then the identification of the target application is accurately determined by using the mapping relationship between the process ID and the identification of the application. This implementation method not only improves the accuracy of the identification of the target application, but also maintains good scalability and compatibility, and can be easily applied to different operating systems.

[0024] In a second aspect, a file uploading device is provided, which is applied to a terminal, and the device includes:

[0025] A first determining unit, configured to determine, in response to a touch event of a user on a screen of a terminal, a target window corresponding to the touch event from at least one window managed by the terminal;

[0026] A second determining unit, configured to determine a target view element corresponding to the touch event from at least one view element of the target window;

[0027] An acquisition unit, used to acquire an identifier of a target application corresponding to a target window, and to acquire an identifier of a target view element;

[0028] A recording unit, used to associate and record the touch event, the identifier of the target application corresponding to the target window, and the identifier of the target view element into a pre-created log file;

[0029] The upload unit is used to upload the log file to the server corresponding to the terminal.

[0030] According to a third aspect, a terminal is provided, wherein the terminal includes:

[0031] A memory for storing executable program codes;

[0032] The processor is used to call and run the executable program code from the memory, so that the terminal executes the method in the above-mentioned first aspect or any possible implementation manner of the first aspect.

[0033] In a fourth aspect, a computer program product is provided, comprising: a computer program code, which, when executed on a computer, enables the computer to execute the method in the first aspect or any possible implementation of the first aspect.

[0034] In a fifth aspect, a computer-readable storage medium is provided, which stores a computer program code. When the computer program code runs on a computer, the computer executes the method in the above-mentioned first aspect or any possible implementation manner of the first aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] Figure 1 This is a schematic diagram of a scenario in which an application program uploads data according to an embodiment of the present application;

[0036] Figure 2 It is a flowchart of a file uploading method provided in an embodiment of the present application;

[0037] Figure 3 This is an example schematic diagram of a file upload provided in an embodiment of the present application;

[0038] Figure 4 is a schematic diagram of a process for determining a target window provided in an embodiment of the present application;

[0039] Figure 5 is a schematic diagram of a process for determining a target view element provided by an embodiment of the present application;

[0040] Figure 6 It is a flow chart of adding uploaded consumption results provided by an embodiment of the present application;

[0041] Figure 7 It is a schematic diagram of a process of selectively uploading consumption results provided by an embodiment of the present application;

[0042] Figure 8 It is a flow chart of adding an identifier of an uploading terminal provided in an embodiment of the present application;

[0043] Fig. 9 It is a schematic diagram of a process of obtaining an identification of a target application provided in an embodiment of the present application;

[0044] Fig.10 It is a structural diagram of a file uploading device provided in an embodiment of the present application;

[0045] Fig.11 It is a structural diagram of a terminal provided in an embodiment of the present application. DETAILED DESCRIPTION

[0046] The technical solution in the present application will be described clearly and in detail below in conjunction with the accompanying drawings. In the description of the embodiments of the present application, unless otherwise specified, " / " means or, for example, A / B can mean A or B: "and / or" in the text is only a description of the association relationship of associated objects, indicating that there can be three relationships, for example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone. In addition, in the description of the embodiments of the present application, "multiple" means two or more than two.

[0047] In the following, the terms "first" and "second" are used for descriptive purposes only and should not be understood as suggesting or implying relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of the features.

[0048] As a means of data collection, tracking technology is widely used in the fields of application performance monitoring, user behavior analysis, etc. Its core lies in presetting data collection points at specific locations in the application to capture various types of data during runtime. Currently, the mainstream implementation solution is to integrate tracking in the terminal application. This tracking SDK is responsible for collecting relevant data in the application and uploading it to the corresponding server of the application for analysis.

[0049] However, the current mainstream implementation scheme has significant limitations. It can only collect data from specific applications that have integrated the tracking SDK. For multi-application environments, such as vehicles, its applicability is greatly reduced. As a terminal, vehicles often install multiple applications, and some applications are from third parties. Requiring vehicle developers to add a tracking SDK for each application separately not only increases the development workload, but also the simultaneous operation of multiple tracking SDKs will occupy a large amount of vehicle computing resources, affecting the overall performance of the terminal.

[0050] See also Figure 1 , Figure 1This is a schematic diagram of a scenario of application tracking and uploading data provided by an embodiment of the present application. Among them, vehicle 001 is installed with application 002a, application 002b, and application 002c. Application 002a will upload user behavior data to server 003a, application 002b will upload user behavior data to server 003b, and application 002c will upload user behavior data to server 003c. It can be understood that the uploading process of the above-mentioned user behavior data depends on the tracking SDK of each application 002a, application 002b, and application 002c, which occupies a large amount of computing resources of vehicle 001, and the development amount of the tracking SDK is also large.

[0051] In short, the above solution of adding tracking SDKs to different applications has the problem of large development workload and affecting the overall performance of the terminal.

[0052] In response to the above problems, the method proposed in the embodiment of the present application is first applied to the terminal, which can uniformly respond to and process the user's touch events on the screen, without the need to separately integrate the tracking SDK for each application, thereby greatly reducing the workload of developers. Secondly, by determining the target window and target view element corresponding to the touch event from the window managed by the terminal, and obtaining their identifiers, accurate capture of user behavior is achieved without relying on the simultaneous operation of multiple tracking SDKs, effectively reducing the occupancy of the terminal's computing resources. Finally, the touch event, the identifier of the target application, and the identifier of the target view element are associated and recorded in a pre-created log file, and uploaded to the server, ensuring the integrity and real-time nature of the data, and facilitating subsequent analysis and processing. In this way, it can reduce the development workload and improve terminal performance.

[0053] based on Figure 1 The scene shown is shown below. Figure 2 - Fig. 9 , the file upload method provided in the embodiment of the present application is introduced in detail.

[0054] See also Figure 2 , Figure 2 The flowchart of a file uploading method provided by the embodiment of the present application is shown in FIG. 1 , wherein the method of the present embodiment is applied to a terminal. Figure 2 As shown, the method of the embodiment of the present application may include the following steps S101-S105.

[0055] S101 : In response to a touch event of a user on a screen of a terminal, determining a target window corresponding to the touch event from at least one window managed by the terminal.

[0056] Specifically, the terminal involved in this embodiment is a general concept, which refers to various mobile phones, tablet computers, personal computers, vehicles, etc. that can be touched by users. The terminal is provided with a screen and supports user touch operations based on the screen.

[0057] When a user touches the screen of a terminal, the touch sensor on the screen senses the operation and converts the touch operation into an electrical signal, which is then transmitted to the operating system of the terminal. After receiving the electrical signal, the operating system recognizes that it is a touch event and prepares for further processing.

[0058] Specifically, a touch event may indicate one or more information about a touch operation, including:

[0059] Event type: such as DOWN, MOVE, UP, etc. These event types are used to distinguish different touch operations of the user.

[0060] Pixel coordinates: Each touch event is accompanied by one or more pixel coordinates, which record the specific location (usually in pixels) when the user touches the screen.

[0061] Timestamp: A touch event also contains a timestamp, which is used to record the time when the touch event occurs.

[0062] Number of touch points: In a multi-touch scenario, a touch event also includes the number of touch points to distinguish between single-point touch and multi-point touch.

[0063] The terminal manages at least one window, and the above touch event is usually for one of the windows. Among them, one or more applications are usually running on the terminal at the same time, and each application may open one or more windows. The terminal is responsible for managing these windows, including their display, hiding, switching, etc. It can be understood that since the window is created by the application, each window managed by the terminal has a corresponding application.

[0064] Furthermore, in response to the above touch event, the terminal will determine the target window corresponding to the touch event according to the layout and status of all windows it manages. The target window refers to the window where the user actually performs a touch operation, that is, the window where the touch event occurs.

[0065] S102: Determine a target view element corresponding to the touch event from at least one view element of the target window.

[0066] Specifically, view elements are the basic units that make up the display interface of a window. They can be buttons, text boxes, pictures, list items, and any other interactive elements that users can see on the window. Each view element has its own specific properties and functions, which together make up the display interface of the window.

[0067] The relationship between a window and a view element is a relationship of inclusion and being included. A window can be composed of multiple view elements, which are arranged in the window according to a specific layout and hierarchy to jointly realize the functions of the window and the display interface performance.

[0068] In order to determine the target view element from at least one view element of the target window, the terminal determines the target view element corresponding to the touch event according to the layout and state of all view elements in the target window. It can be understood that the target view element refers to the view element that the user actually touches.

[0069] S103, obtaining an identifier of a target application corresponding to the target window, and obtaining an identifier of a target view element.

[0070] Specifically, the application ID refers to the identity information that can uniquely identify an application, or "App ID" for short. The application ID plays a role in distinguishing different applications in the terminal's operating system, ensuring that each application can be accurately identified and managed by the system. For example, in the terminal's Android system, each application has a unique package name as its identifier.

[0071] The ID of a view element refers to the identity information that can uniquely identify a view element (such as a button, text box, etc.) in the display interface of a window, or "View ID" for short. The ID of a view element is used to distinguish different view elements within the application to support precise operation and control of these view elements.

[0072] The target application and the target view element have been determined in the above steps. Here, the identifier of the target application and the identifier of the target view element can be directly obtained.

[0073] S104, associate and record the touch event, the identifier of the target application corresponding to the target window, and the identifier of the target view element into a pre-created log file.

[0074] Specifically, a log file is a file used to record events, operations or errors during the running of a program. For example, if the terminal is running the Android system, there is a default log file that records various operating states and events of the Android system, including application startup, crash, user operations, etc. For developers, log files are an important tool for diagnosing problems, monitoring application behavior and optimizing performance.

[0075] There are several possible ways to associate the touch event, the target application ID corresponding to the target window, and the target view element ID with each other and record them in a log file:

[0076] In one possible implementation, a logging method in a log API (Application Programming Interface) may be called, which receives a touch event, an identifier of a target application, and an identifier of a target view element as parameters, and associates these parameters with each other and records them in a pre-created log file for subsequent analysis and use.

[0077] In a possible implementation, a logging program may be installed in the terminal, and the logging program may be used to associate and record the touch event, the identifier of the target application program, and the identifier of the target view element into a log file.

[0078] In a possible implementation, the terminal can run a logging service, which monitors touch events. When a touch event occurs, the logging service is triggered and performs a corresponding logging operation. In the logging operation, the logging service associates the touch event, the identifier of the target application, and the identifier of the target view element, and writes them into a log file.

[0079] It should be noted that a touch event, an identifier of a target application, an identifier of a target view element, or other data that can reflect user behavior can all be referred to as user behavior data, that is, user behavior data is not limited to the three types of data shown above. After a touch event occurs, the terminal can selectively associate one or more types of user behavior data and record them in a log file.

[0080] Association recording means recording user behavior data such as touch events, target application IDs, and target view element IDs as a group for subsequent analysis and processing. For example, when a user clicks a virtual button (view element) in a window opened by an application, the terminal will record the touch event, the application ID, and the virtual button ID as a group of information in a log file. In this way, you can check the log file later to find out which virtual button the user clicked in which application, so as to perform relevant analysis and processing.

[0081] Pre-creation means that the log file is created before the log is needed. In this way, when the user behavior data needs to be recorded in the log file, the user behavior data can be directly written into the existing log file without creating a new log file every time. This can improve the efficiency of user behavior data recording and facilitate subsequent log file management and analysis.

[0082] S105, uploading the log file to the server corresponding to the terminal.

[0083] Specifically, it should be made clear that the server involved in this embodiment does not refer to the server corresponding to a certain application installed on the terminal, but refers to the server corresponding to the entire terminal. The main function of this server is to collect user behavior data of the terminal, rather than user behavior data of a single application in the terminal. In other words, no matter which application is run on the terminal, the user behavior data generated by the user's touch operation will be recorded in a log file and uploaded to the server for unified analysis and processing.

[0084] Secondly, the terminal does not upload log files to the server at will, but only when the preset conditions are met. There are many ways to judge the preset conditions. For example, each time a trigger event occurs and the user behavior data corresponding to the trigger event is recorded, it can be determined that the preset conditions are met; or, after each preset period (such as one day, one week, etc.), it is determined that the preset conditions are met; or, when the terminal is connected to WiFi or has other network transmission capabilities, it can also be determined that the preset conditions are met. In addition, there may be other situations that meet the preset conditions, such as when the terminal has sufficient power, when the terminal is in a non-roaming state, etc., which are not listed here one by one.

[0085] Finally, when the preset conditions are met, the terminal will start uploading log files to the server, which usually requires the terminal to upload based on network transmission.

[0086] In a possible implementation, the terminal will package and compress the log file to reduce the amount of data during transmission; then, the packaged log file will be sent to the server through a network connection (such as WiFi, mobile data network, etc.); after receiving the log file, the server will unpack and decompress it, restore the original data, and store and analyze it. In this way, the entire log file upload process is completed.

[0087] It should be noted that, unlike the solution of integrating the tracking SDK into the application, steps S101-S105 of this embodiment can be executed by a service in the terminal that is independent of the application.

[0088] In a possible implementation, steps S101-S105 are executed by the terminal's management service, which consists of an input management service (IMS) and a window management service (WMS). The IMS and WMS are services at the operating system level of the terminal and are not applications installed on the terminal. Therefore, user behavior data collection at the operating system level can be achieved based on the IMS and WMS.

[0089] More specifically, after the user performs a touch operation on the screen of the terminal, the input management service determines the touch event; the input management service transmits the touch event to the window management service in response to the touch event; the window management service determines the target window and the target view element according to the touch event, and informs the target application corresponding to the target window, and the target application chooses to consume or not consume the touch event; in addition, the input management service obtains the identifier of the target application corresponding to the target window and the identifier of the target view element according to the target window and the target view element determined by the window management service; the input management service associates the touch event, the identifier of the target application corresponding to the target window, and the identifier of the target view element to a pre-created log file, and uploads the log file to the server corresponding to the terminal when the preset conditions are met.

[0090] See also Figure 3 , Figure 3It is an example schematic diagram of a file upload provided in an embodiment of the present application. Among them, vehicle 001 is installed with application 002d, application 002e, and application 002f, and management service 004 is running at the operating system level of vehicle 001. Management service 004 can obtain user behavior data of users for application 002d, application 002e, and application 002f based on the scheme of this embodiment, and record the obtained user behavior data in a log file. When the preset conditions are met, management service 004 will upload the log file to the server 005 corresponding to vehicle 001, so that server 005 can analyze and output the user portrait of the user of vehicle 001 based on the log file or use it for other purposes. It can be understood that server 005 does not correspond to any one of application 002d, application 002e, and application 002f.

[0091] It should be noted that, assuming that the operating system of the terminal is the Android system, each window running in it will have a corresponding Activity and Fragment. The opening or closing of the Activity and Fragment will be regarded as a user behavior data, which will be recorded in the above log file by default and uploaded to the server together with other user behavior data.

[0092] It should be noted that this embodiment finally uploads the log file to the server corresponding to the terminal. After receiving the log file uploaded by the terminal, the server can use data analysis tools such as Python to parse and process the log file. By extracting the user behavior data in the log file, the server can analyze the user's specific touch operations on certain applications and obtain analysis results. Furthermore, the server can analyze the results and output a detailed user behavior portrait. The user behavior portrait not only shows the user's usage habits, but also reveals the user's preferences and needs for different functions of the application, providing valuable data support for subsequent product optimization and user experience improvement.

[0093] In this embodiment, the method is first applied to the terminal, which can uniformly respond to and process the user's touch events on the screen, without the need to separately integrate the tracking SDK for each application, thereby greatly reducing the workload of developers. Secondly, by determining the target window and target view element corresponding to the touch event from the window managed by the terminal and obtaining their identifiers, accurate capture of user behavior is achieved without relying on the simultaneous operation of multiple tracking SDKs, effectively reducing the occupancy of the terminal's computing resources. Finally, the touch event, the identifier of the target application, and the identifier of the target view element are associated and recorded in a pre-created log file, and uploaded to the server, ensuring the integrity and real-time nature of the data, which is convenient for subsequent analysis and processing. In this way, it can reduce the development workload and improve terminal performance.

[0094] See also Figure 4 , a schematic diagram of a process for determining a target window is provided for an embodiment of the present application, such as Figure 4 As shown, the method of the embodiment of the present application may include the following steps S201-S204, and steps S201-S204 can be used as Figure 2 The refinement of step S101 in the illustrated embodiment.

[0095] S201, in response to a touch event of a user on a screen of a terminal, determining a pixel coordinate range of each window of at least one window managed by the terminal;

[0096] S202, determining at least one window whose pixel coordinate range includes the pixel coordinates indicated by the touch event as a candidate window;

[0097] S203, determining the level of each candidate window in at least one candidate window;

[0098] S204: Determine the candidate window with the highest level as the target window.

[0099] Specifically, when a user touches the screen of a terminal, the terminal responds to a touch event generated by the touch operation. In order to determine the target window corresponding to the touch event, it is first necessary to obtain the pixel coordinate range of each window currently opened on the terminal. This is because windows are positioned and displayed on the screen in units of pixels, and each window has its own specific pixel coordinate range, which is used to accurately represent the position and size of the window on the screen.

[0100] Furthermore, after determining the pixel coordinate ranges of each window, the pixel coordinates indicated by the touch event need to be compared with the pixel coordinate ranges of these windows. The purpose of this comparison is to find out the windows whose pixel coordinate ranges contain the pixel coordinates indicated by the touch event. These windows may be the windows where the user actually performs touch operations. Therefore, these windows are determined as candidate windows. It should be noted that the pixel coordinate ranges of multiple windows may contain the pixel coordinates indicated by the touch event at the same time, so there will be multiple candidate windows.

[0101] Furthermore, since the number of candidate windows is one or more, the hierarchy of these candidate windows needs to be determined. The hierarchy of windows refers to the stacking order of windows on the screen, and windows with higher hierarchies will cover windows with lower hierarchies. The hierarchy of candidate windows is determined to find the window that is most likely to be touched by the user, because in actual use, users usually only interact with the top-most window.

[0102] After determining the levels of each candidate window, the candidate window with the highest level can be determined as the target window, because the candidate window with the highest level is the top-most candidate window and is also the window that the user actually performs a touch operation on.

[0103] To facilitate understanding of this embodiment, an example is provided below:

[0104] Assume that three windows are currently opened on the terminal, namely window A (a social media application), window B (a game application) and window C (a music player application). The pixel coordinate ranges of these three windows on the screen are: window A (100, 100, 300, 300), window B (200, 200, 400, 400), window C (300, 300, 500, 500). The four numbers in the brackets represent the x-coordinate, y-coordinate of the upper left corner and the x-coordinate, y-coordinate of the lower right corner of the window.

[0105] The user performs a touch operation on the screen, and the pixel coordinates of the touch event generated are (250, 250). According to step S201, the pixel coordinate ranges of the three windows are first known; according to step S202, it can be determined that window A and window B are both candidate windows, because their pixel coordinate ranges both contain the pixel coordinates of the touch event (250, 250); then, according to step S203, it is necessary to determine the levels of window A and window B, and through query, it is known that the level of window B is higher than that of window A; finally, according to step S204, the window B with the highest level is determined as the target window, that is, the window that the user actually wants to perform a touch operation.

[0106] In this embodiment, the target window corresponding to the touch event is determined from the window managed by the terminal, and its identifier is obtained, so as to accurately capture the user behavior. In this process, there is no need to rely on the simultaneous operation of multiple tracking SDKs, which effectively reduces the occupation of the terminal's computing resources, improves the performance of the terminal, and effectively reduces the development workload.

[0107] See also Figure 5 , provides a flow chart of determining a target view element for an embodiment of the present application, such as Figure 5 As shown, the method of the embodiment of the present application may include the following steps S301-S305, and steps S301-S305 can be used as Figure 2 The refinement of step S102 in the illustrated embodiment.

[0108] S301, obtaining a view tree of a target window, wherein the view tree is composed of at least one view element;

[0109] S302, determining the pixel coordinate range of each view element in the view tree;

[0110] S303, determining at least one view element whose pixel coordinate range includes the pixel coordinates indicated by the touch event as a candidate view element;

[0111] S304, determining a level of each candidate view element in the at least one candidate view element in the view tree;

[0112] S305: Determine the candidate view element with the highest level as the target view element.

[0113] Specifically, in order to determine the target view element, the view tree of the target window needs to be obtained first. The view tree is composed of at least one view element, which is the basic unit constituting the display interface of the window, such as a virtual button, a text box, etc.

[0114] Furthermore, it is necessary to determine the pixel coordinate range of each view element in the view tree. Since the view elements are positioned and displayed in pixels on the display interface of the window, each view element has its own specific pixel coordinate range, which accurately represents the position and size of the view element on the display interface of the window.

[0115] When a user performs a touch operation on the display interface of a window, a touch event is generated, which contains a specific pixel coordinate. The pixel coordinates indicated by this touch event are compared with the pixel coordinate ranges of each view element in the view tree, and the view elements whose pixel coordinate ranges contain the pixel coordinates indicated by the touch event are found. These view elements may be the view elements that the user actually performs a touch operation on, so they are determined as candidate view elements.

[0116] In the view tree, view elements have a hierarchical relationship, and view elements with a higher hierarchy will cover view elements with a lower hierarchy. The purpose of determining the hierarchy of candidate view elements is to find the view elements that are most likely to be touched by the user, because in actual use, users usually only interact with the top-level view elements.

[0117] Therefore, after determining the hierarchy of each candidate view element, the candidate view element with the highest hierarchy can be determined as the target view element. This is because the candidate view element with the highest hierarchy is the top-level candidate element and is also the view element that the user actually touches.

[0118] To facilitate understanding of this embodiment, a specific example is provided below:

[0119] Assume that there are three view elements in the view tree of a certain window, namely view element D (a button), view element E (a text box) and view element F (a picture). The pixel coordinate ranges of these three view elements on the display interface of the window are: view element D (100, 100, 200, 200), view element E (150, 150, 250, 250), view element F (200, 200, 300, 300). The four numbers in the brackets represent the x-coordinate, y-coordinate of the upper left corner and the x-coordinate, y-coordinate of the lower right corner of the view element.

[0120] The user performs a touch operation on the display interface of the window, and the pixel coordinates of the touch event generated are (175, 175). According to step S301, first obtain the view tree of the target window corresponding to the touch event; according to step S302, determine the pixel coordinate ranges of the three view elements; according to step S303, it can be determined that view element D and view element E are both candidate view elements, because their pixel coordinate ranges both contain the pixel coordinates (175, 175) indicated by the touch event; according to step S304, determine the levels of view element D and view element E in the view tree, and through query, it is known that the level of view element E is higher than that of view element D; according to step S305, determine that the view element E with the highest level is the target view element, that is, the view element that the user actually wants to perform a touch operation.

[0121] In this embodiment, the view tree of the target window is first obtained, and the pixel coordinate range of each view element therein is determined, which provides a reliable premise for the subsequent determination of the target view element. Secondly, by determining the view element whose pixel coordinate range contains the pixel coordinate indicated by the touch event as a candidate view element, and further screening each candidate view element according to its level in the view tree, the candidate view element with the highest level can be accurately located and determined as the target view element. This implementation method not only improves the accuracy of the determination of the target view element, but also effectively reduces the occupation of computing resources, improves the performance of the terminal, and effectively reduces the amount of development.

[0122] See also Figure 6 , provides a flow chart of adding uploaded consumption results for the embodiment of the present application, such as Figure 6 As shown, the method of the embodiment of the present application may include the following steps S401-S403, and steps S401-S402 may be Figure 2 In the illustrated embodiment, step S403 is performed after step S103 and before step S104, and step S403 can be regarded as a refinement of step S104.

[0123] S401, transmitting a touch event and an identifier of a target view element to a target application, so that the target application can choose to consume or not consume the touch event according to the identifier of the target view element;

[0124] S402, obtaining the consumption result of the touch event by the target application;

[0125] S403: associate and record the touch event, the identifier of the target application corresponding to the target window, the identifier of the target view element, and the result of the target application consuming the touch event into a pre-created log file.

[0126] Specifically, steps S401-S403 involved in this embodiment can be executed by the management service. Figure 2 The management service transmits the touch event and the identifier of the target view element to the target application, and the target application can choose to consume or not consume the touch event after receiving the information.

[0127] The process of the target application consuming the touch event is actually the process of the application responding to the user's touch operation. If the target application decides to consume the touch event, it will execute the code related to the touch event, such as opening a new window, executing a command, etc. If the target application decides not to consume the touch event, the touch event will be ignored and will not produce any effect.

[0128] Regardless of whether the target application consumes or does not consume the touch event, a consumption result is generated, indicating that the touch event is consumed (for example, indicated by a Boolean value of true) or not consumed (for example, indicated by a Boolean value of false).

[0129] Furthermore, the consumption result is returned by the target application to the management service, that is, the management service obtains the consumption result.

[0130] Furthermore, the management service associates and records the touch event, the identifier of the target application corresponding to the target window, the identifier of the target view element, and the result of the target application consuming the touch event into a pre-created log file.

[0131] To facilitate understanding of this embodiment, an example is provided below:

[0132] Assume that a target application is running on the terminal. There is a button on the main interface of the target application. The user can open a new window by clicking this button. When the user clicks this button, the management service will determine a touch event and transmit the touch event and the button identifier to the target application. After receiving this information, the target application will determine that the operation the user wants to perform is to open a new window based on the button identifier. Therefore, the target application may consume this touch event and execute the code to open a new window. After the execution is completed, the management service will obtain the consumption result of the target application (that is, indicating that the new window is successfully opened), and associate the touch event, the identifier of the target application, the identifier of the button, and the consumption result to the log file. Alternatively, the target application may not consume this touch event, and the management service will also obtain the consumption result of the target application (that is, indicating that the new window is not opened), and associate the touch event, the identifier of the target application, the identifier of the button, and the consumption result to the log file. In this way, the log file records the consumption result of the touch event. If the developer needs to analyze user behavior or debug the application later, this log file can be used to understand how the user interacts with the application.

[0133] In this embodiment, the consumption result of the touch event by the target application can be recorded in the log file, which effectively improves the data dimension of the log file, so that the user behavior of the terminal can be analyzed more accurately in the subsequent use of the log file.

[0134] See also Figure 7 , provides a flow chart of selectively uploading consumption results for the embodiment of the present application, such as Figure 7 As shown, the method of the embodiment of the present application may include the following steps S501, and step S501 may be used as Figure 6 The refinement of step S403 in the illustrated embodiment.

[0135] S501, if the consumption result of the touch event indicates that the touch event is consumed by the target application, the touch event, the identifier of the target application corresponding to the target window, the identifier of the target view element, and the consumption result of the touch event by the target application are associated and recorded in a pre-created log file.

[0136] Specifically, the touch event, the identifier of the target application corresponding to the target window, the identifier of the target view element, and the consumption result of the touch event by the target application are all user behavior data. Before recording the user behavior data in the log file, it is necessary to determine whether the touch event is consumed by the target application based on the consumption result.

[0137] If the consumption result of the touch event indicates that the touch event is not consumed by the target application, the above user behavior data will not be recorded in the log file; if the consumption result of the touch event indicates that the touch event is consumed by the target application, the above user behavior data will be recorded in the log file.

[0138] It is understandable that filtering and recording user behavior data based on consumption results of touch events can ensure that only user behavior data with higher value is retained in the log file.

[0139] In this embodiment, user behavior data is recorded in the log file only when a touch event is consumed, which can avoid storing a large amount of invalid data in the log file, thereby reducing the size of the log file, improving storage efficiency and also improving the readability of the log file.

[0140] See also Figure 8 , a schematic diagram of a process for adding an identifier of an uploading terminal is provided for an embodiment of the present application, such as Figure 8 As shown, the method of the embodiment of the present application may include the following steps S601-S602, and steps S601-S602 may be Figure 2 In the illustrated embodiment, it is performed before step S105.

[0141] S601, obtaining an identifier of a terminal, wherein the identifier of the terminal is pre-bound with user information of the terminal;

[0142] S602: Record the terminal identifier into a log file.

[0143] Specifically, the terminal identifier plays a role in uniquely identifying the terminal, such as the IMEI (International Mobile Equipment Identity) of a mobile phone, the MAC (Media Access Control) address of a computer, the VIN (Vehicle Identification Number) of a vehicle, etc. Therefore, before uploading the log file to the server corresponding to the terminal, it is necessary to first obtain the terminal identifier and record the terminal identifier in the log file.

[0144] It is worth noting that the terminal identifier is pre-bound to the terminal user information, and there is a mapping relationship between the identifier and the user information. That is to say, after the server receives the log file uploaded by the terminal, it can extract the terminal identifier from the log file, and determine the terminal user information based on the terminal identifier and the mapping relationship between the identifier and the user information.

[0145] To facilitate understanding of this embodiment, an example is provided below:

[0146] Assuming that the terminal is a vehicle, the terminal identifier can be the VIN of the vehicle. The server records the owner information (a kind of user information) corresponding to different VINs, that is, the VIN of the vehicle is pre-bound with the owner information of the vehicle.

[0147] The vehicle records the corresponding VIN in a log file, and then uploads the log file to the corresponding server. After receiving the log file, the server can extract the VIN of the vehicle from it, and then determine the owner information of the vehicle based on the VIN of the vehicle and the mapping relationship between the VIN and the owner information. In this way, a data basis is provided for the server to subsequently output the user portrait of the owner of the vehicle.

[0148] In this embodiment, before uploading the log file to the server corresponding to the terminal, the terminal identifier is first obtained and recorded in the log file. Since the terminal identifier is pre-bound to the user information of the terminal, recording the terminal identifier in the log file actually indirectly associates the user information. This enables the subsequent analysis and processing of the log file to more accurately locate the specific user, thereby improving the accuracy and effectiveness of data analysis.

[0149] See also Fig. 9 , provides a schematic diagram of a process for obtaining the identification of a target application program in an embodiment of the present application, such as Fig. 9 As shown, the method of the embodiment of the present application may include the following steps S701-S702, and steps S701-S702 may be used as Figure 2 The refinement of step S103 in the illustrated embodiment.

[0150] S701, obtaining the process ID of the target application;

[0151] S702: Determine the identifier of the target application program according to the process ID of the target application program and the mapping relationship between the process ID and the identifier of the application program.

[0152] Specifically, in the terminal's operating system, whenever an application is started, the operating system will assign a unique process number (Process ID, abbreviated as PID) to the application. This process number is an identifier used by the operating system to identify and manage the application. It is worth noting that the process number remains unchanged during the life cycle of the application (i.e., from startup to shutdown). Even if the application is suspended or running in the background for a period of time, its process number will not change until the application is completely closed. Of course, if the application is restarted, the operating system may assign it a new process number.

[0153] Therefore, after the target application is determined, the process ID of the target application can be printed out in some way (such as using a system command or a programming interface).

[0154] After obtaining the process ID of the target application, you can use system commands or programming interfaces to query the identifier corresponding to the process ID, that is, the identifier of the target application, which is usually expressed as a package name. For example, in the Android system, you can use the "ps" command or the "ActivityManager" class to query the process information and extract the package name of the application as the identifier.

[0155] To help you understand this scenario, here is an example:

[0156] Assume that a target application named "ExampleApp" is running on the terminal. After the target application is started, the operating system of the terminal assigns it a process number "12345". At this time, the process number "12345" of the target application can be printed out through system commands or programming interfaces. Then, based on the process number "12345" and the mapping relationship between the process number and the application identifier maintained by the operating system, the application identifier corresponding to the process number is queried and determined to be "com.example.app" (i.e., the package name of "ExampleApp"). In this way, the identifier of the target application is successfully obtained.

[0157] In this embodiment, the process ID of the target application is first obtained, and then the identification of the target application is accurately determined by using the mapping relationship between the process ID and the identification of the application. This implementation method not only improves the accuracy of the identification of the target application, but also maintains good scalability and compatibility, and can be easily applied to different operating systems.

[0158] Based on the above Figure 1 The following will combine Fig.10 The file upload device provided in the embodiment of the present application is introduced in detail. It should be noted that: Fig.10 The file upload device in is used to execute this application Figure 2 - Fig. 9 For the convenience of explanation, only the part related to the embodiment of the present application is shown. For the specific technical details not disclosed, please refer to the present application. Figure 2 - Fig. 9 Specifically, the file uploading device 800 may include a first determining unit 801, a second determining unit 802, an acquiring unit 803, a recording unit 804, and an uploading unit 805, as follows:

[0159] A first determining unit 801 is configured to determine, in response to a touch event of a user on a screen of a terminal, a target window corresponding to the touch event from at least one window managed by the terminal;

[0160] A second determining unit 802 is used to determine a target view element corresponding to the touch event from at least one view element of the target window;

[0161] The acquisition unit 803 is used to acquire the identifier of the target application corresponding to the target window and the identifier of the target view element;

[0162] The recording unit 804 is used to associate and record the touch event, the identifier of the target application corresponding to the target window, and the identifier of the target view element into a pre-created log file;

[0163] The uploading unit 805 is used to upload the log file to the server corresponding to the terminal.

[0164] Optionally, in some embodiments, the first determination unit 801 can be used to: determine the pixel coordinate range of each window in at least one window managed by the terminal in response to a user touch event on the screen of the terminal; determine at least one window whose pixel coordinate range contains pixel coordinates indicated by the touch event as a candidate window; determine the hierarchy of each candidate window in at least one candidate window; and determine the candidate window with the highest hierarchy as the target window.

[0165] Optionally, in some embodiments, the second determination unit 802 can be used to: obtain a view tree of the target window, wherein the view tree is composed of at least one view element; determine a pixel coordinate range of each view element in the view tree; determine at least one view element whose pixel coordinate range contains the pixel coordinates indicated by a touch event as a candidate view element; determine the hierarchy of each candidate view element in the at least one candidate view element in the view tree; and determine the candidate view element with the highest hierarchy as the target view element.

[0166] Optionally, in some embodiments, the file uploading device 800 can be used to: transmit the touch event and the identifier of the target view element to the target application, so that the target application can choose to consume or not consume the touch event according to the identifier of the target view element; obtain the consumption result of the touch event by the target application; the recording unit 804 can be used to: associate the touch event, the identifier of the target application corresponding to the target window, the identifier of the target view element, and the consumption result of the touch event by the target application to a pre-created log file.

[0167] Optionally, in some embodiments, the recording unit 804 can be used to: if the consumption result of the touch event indicates that the touch event is consumed by the target application, the touch event, the identifier of the target application corresponding to the target window, the identifier of the target view element, and the consumption result of the touch event by the target application are associated and recorded in a pre-created log file.

[0168] Optionally, in some embodiments, the file uploading device 800 may be used to: obtain an identifier of a terminal, wherein the identifier of the terminal is pre-bound to user information of the terminal; and record the identifier of the terminal into a log file.

[0169] Optionally, in some embodiments, the acquisition unit 803 may be used to: acquire the process ID of the target application; and determine the identifier of the target application according to the process ID of the target application and a mapping relationship between the process ID and the identifier of the application.

[0170] In this embodiment, the device is applied to the terminal, and can uniformly respond to and process the user's touch events on the screen. There is no need to integrate the tracking SDK for each application separately, which greatly reduces the workload of developers. Secondly, by determining the target window and target view element corresponding to the touch event from the window managed by the terminal and obtaining their identifiers, accurate capture of user behavior is achieved without relying on the simultaneous operation of multiple tracking SDKs, effectively reducing the occupancy of the terminal's computing resources. Finally, the touch event, the identifier of the target application, and the identifier of the target view element are associated and recorded in a pre-created log file, and uploaded to the server, ensuring the integrity and real-time nature of the data, which is convenient for subsequent analysis and processing. In this way, it can reduce the development workload and improve terminal performance.

[0171] See also Fig.11 , which is a schematic diagram of the structure of a terminal provided in an embodiment of the present application. Fig.11 As shown, the terminal 900 includes a processor 901 and a memory 902. The processor 901 is electrically connected to the memory 902.

[0172] The processor 901 is the control center of the terminal 900 and may include one or more processing cores. The processor 901 uses various interfaces and lines to connect various parts of the entire terminal 900, and executes various functions and processes data of the terminal 900 by running or calling computer programs stored in the memory 902, and calling data stored in the memory 902, so as to control the terminal 900 as a whole. Optionally, the processor 901 can be implemented in at least one hardware form of digital signal processing (DSP), field programmable gate array (FPGA), and programmable logic array (PLA). The processor 901 may integrate one or a combination of CPU, graphics processing unit (GPU), modem, etc. Among them, the CPU mainly processes the operating system, user pages, and applications; the GPU is responsible for rendering and drawing display content; and the modem is used to process wireless communications. It is understandable that the above-mentioned modem may not be integrated into the processor 901, but may be implemented separately through a communication chip.

[0173] The memory 902 may be used to store software programs and modules, and the processor 901 executes various functional applications and data processing by running computer programs and modules stored in the memory 902. The memory 902 may mainly include a program storage area and a data storage area, wherein the program storage area may store an operating system, a computer program required for at least one function, etc.; the data storage area may store data created according to the use of the terminal 900, etc.

[0174] In addition, the memory 902 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, or other volatile solid-state storage devices. Accordingly, the memory 902 may also include a memory controller to provide the processor 901 with access to the memory 902.

[0175] In this embodiment, the processor 901 in the terminal 900 loads instructions corresponding to the processes of one or more computer programs into the memory 902 according to the following steps, and the processor 901 runs the computer program stored in the memory 902 to implement various functions, as follows:

[0176] In this embodiment, the memory 902 is used to store executable program codes;

[0177] The processor 901 is used to call and run the executable program code from the memory 902, so that the terminal 900 executes the above-mentioned related steps to implement a file uploading method provided by the above-mentioned embodiment.

[0178] It should be understood that the device provided in the embodiment of the present application is used to execute the above-mentioned file uploading method, and thus can achieve the same effect as the above-mentioned implementation method.

[0179] In the case of an integrated unit, the device may include a processing module and a storage module. When the device is applied to a terminal, the processing module may be used to control and manage the actions of the terminal. The storage module may be used to support the terminal to execute relevant program codes, etc.

[0180] The processing module may be a processor or a controller, which may implement or execute various exemplary logic blocks, modules and circuits described in conjunction with the disclosure of this application. The processor may also be a combination that implements computing functions, such as a combination of one or more microprocessors, a combination of digital signal processing (DSP) and a microprocessor, etc. The storage module may be a memory.

[0181] In addition, the device provided in the embodiment of the present application can specifically be a chip, component or module, and the chip may include a connected processor and memory; wherein the memory is used to store instructions, and when the processor calls and executes the instructions, the chip can execute a file uploading method provided in the above embodiment.

[0182] An embodiment of the present application also provides a computer-readable storage medium, in which a computer program code is stored. When the computer program code is executed on a computer, the computer executes the above-mentioned related method steps to implement a file uploading method provided in the above-mentioned embodiment.

[0183] This embodiment also provides a computer program product. When the computer program product runs on a computer, it enables the computer to execute the above-mentioned related steps to implement a file uploading method provided by the above embodiment.

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

[0185] Through the description of the above implementation methods, technical personnel in the relevant field can understand that for the convenience and simplicity of description, only the division of the above-mentioned functional modules is used as an example. In actual applications, the above-mentioned functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

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

[0187] The above contents are only specific implementation methods of the present application, but the protection scope of the present application is not limited thereto. Any technician familiar with the technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

Claims

1. A file upload method, It is characterized in that Applied to terminals, including: In response to a touch event of a user on a screen of the terminal, determining a target window corresponding to the touch event from at least one window managed by the terminal; Determining, from at least one view element of the target window, a target view element corresponding to the touch event; Obtaining an identifier of a target application corresponding to the target window, and obtaining an identifier of the target view element; Associatively recording the touch event, the identifier of the target application corresponding to the target window, and the identifier of the target view element into a pre-created log file; Upload the log file to the server corresponding to the terminal.

2. The method according to claim 1, It is characterized in that In response to a touch event of a user on a screen of the terminal, determining a target window corresponding to the touch event from at least one window managed by the terminal includes: In response to a touch event of the terminal screen by a user, determining a pixel coordinate range of each of the at least one window managed by the terminal; Determine at least one of the windows whose pixel coordinate range includes the pixel coordinates indicated by the touch event as a candidate window; determining a level of each of the candidate windows in at least one of the candidate windows; The candidate window with the highest level is determined as the target window.

3. The method according to claim 1, It is characterized in that The determining, from at least one view element of the target window, a target view element corresponding to the touch event comprises: Acquire a view tree of the target window, wherein the view tree is composed of at least one view element; Determining a pixel coordinate range of each of the view elements in the view tree; Determine at least one of the view elements whose pixel coordinate range includes the pixel coordinate indicated by the touch event as a candidate view element; Determining a level of each of the candidate view elements in the view tree; The candidate view element with the highest level is determined as the target view element.

4. The method according to claim 1, It is characterized in that After obtaining the identifier of the target application corresponding to the target window and obtaining the identifier of the target view element, before associating and recording the touch event, the identifier of the target application corresponding to the target window, and the identifier of the target view element to a pre-created log file, the method further includes: Transmitting the touch event and the identifier of the target view element to the target application, so that the target application chooses to consume or not consume the touch event according to the identifier of the target view element; Obtaining a consumption result of the touch event by the target application; The step of associating and recording the touch event, the identifier of the target application corresponding to the target window, and the identifier of the target view element into a pre-created log file includes: The touch event, the identifier of the target application corresponding to the target window, the identifier of the target view element, and the consumption result of the touch event by the target application are associated and recorded in the pre-created log file.

5. The method according to claim 4, It is characterized in that The step of associating and recording the touch event, the identifier of the target application corresponding to the target window, the identifier of the target view element, and the consumption result of the touch event by the target application to the pre-created log file includes: If the consumption result of the touch event indicates that the touch event is consumed by the target application, the touch event, the identifier of the target application corresponding to the target window, the identifier of the target view element, and the consumption result of the touch event by the target application are associated and recorded in the pre-created log file.

6. The method according to claim 1, It is characterized in that Before uploading the log file to the server corresponding to the terminal, the method further includes: Acquire an identifier of the terminal, wherein the identifier of the terminal is pre-bound with user information of the terminal; The identification of the terminal is recorded in the log file.

7. The method according to claim 1, It is characterized in that The step of obtaining an identifier of a target application corresponding to the target window includes: Obtaining the process ID of the target application; The identifier of the target application is determined according to the process ID of the target application and the mapping relationship between the process ID and the identifier of the application.

8. A file uploading device, It is characterized in that Applied to terminals, including: a first determining unit, configured to determine, in response to a touch event of a user on a screen of the terminal, a target window corresponding to the touch event from at least one window managed by the terminal; A second determining unit, configured to determine a target view element corresponding to the touch event from at least one view element of the target window; An acquiring unit, configured to acquire an identifier of a target application corresponding to the target window, and acquire an identifier of the target view element; A recording unit, configured to associate and record the touch event, the identifier of the target application corresponding to the target window, and the identifier of the target view element into a pre-created log file; The uploading unit is used to upload the log file to the server corresponding to the terminal.

9. A terminal, It is characterized in that include: A memory for storing executable program codes; A processor, configured to call and run the executable program code from the memory, so that the terminal executes the method according to any one of claims 1 to 7.

10. A computer-readable storage medium, It is characterized in that The computer-readable storage medium stores a computer program code, and when the computer program code is executed, the method according to any one of claims 1 to 7 is implemented.

Images