A method and device for generating a heat map and displaying in an Android APP

Abstract

This invention discloses a method for generating heatmaps and displaying them in an Android app. The Android app collects user interactions with UI controls on its pages. The server rasterizes each UI control on each page of the Android app. The server generates grid-level heatmap data for each page of the app and returns the grid-level heatmap data for that page based on its page ID. The Android app receives the grid-level heatmap data for that page, matches the corresponding UI control on the current page based on the alias of the parent container and the control, iterates through a two-dimensional array to obtain the touch count for each grid cell, and overlays and renders a semi-transparent heatmap layer on top of the current page. This invention improves the real-time performance, accuracy, and user experience of heatmap display.

Description

Technical Field

[0001] This invention relates to a method for generating and displaying heatmaps of APP pages in a mobile terminal. Background Technology

[0002] The user interface (UI) of a mobile application (APP) consists of one or more pages. The UI elements on an APP page that interact with the user are called UI controls; common UI controls include buttons, sliders, input boxes, and checkboxes. The APP collects user clicks, swipes, and pauses on each UI control on each page of the APP. The server aggregates and calculates this data to generate a heatmap for each page of the APP. APP page heatmaps use different shades or levels of color to indicate which UI controls on the APP page interact with the user most frequently. They are suitable for scenarios such as product interaction optimization, user behavior insight, and interface design evaluation.

[0003] The current mainstream method for generating and displaying app page heatmaps typically adopts a "client-side tracking and reporting – server-side analysis – web-based display" approach. This approach displays the app page heatmap in a separate web-based management backend, resulting in significant latency. If the app page heatmap is to be displayed directly on the app page within an Android system, the web-based display logic cannot be used due to the inherent characteristics of the Android system, as detailed below.

[0004] First, the heatmaps of APP pages currently displayed on web pages usually use a static page layout, while APPs in the Android system (referred to as Android APPs) have dynamic page characteristics, causing the display logic on the web page to completely fail.

[0005] For example, Android app pages often include scenarios such as list loading (e.g., RecyclerView scrolling loading), component collapsing and expanding (e.g., collapsible panels), which causes the position and size of UI controls on Android app pages to change in real time with user actions. If the display logic of the web version is used, the heatmap data and the actual UI controls will be misaligned. For example, a button may initially be in the middle of the screen, but move to the top after scrolling, and the static positioning logic of the web version cannot be updated synchronously.

[0006] For example, UI controls in Android apps can exist in multiple states, such as active / inactive, selected / unselected, enabled / disabled, etc. Some UI controls (such as tab switches) will change their display position or hide depending on the state. The display logic on the web page lacks recognition of the dynamic states of these UI controls, which can lead to a mismatch between heatmap data and the states of UI controls. For instance, if a hidden control is counted for clicks, the heatmap will still render at that location.

[0007] Second, the current method of displaying heatmaps of APP pages on web pages relies on a fixed DOM (Document Object Model). The positioning of UI controls is achieved through the hierarchical path of the DOM tree. The positioning reference of UI controls is the top left corner of the page document flow, and the position of UI controls is relatively fixed.

[0008] In Android apps, the position of UI controls is based on the "parent container View" or the "visible area of ​​the screen," rather than a fixed page document flow. The relative coordinates of the same button, nested within different parent containers, will change as the parent container's position changes. For example, a button in a list item will have its coordinates relative to the screen updated as the list scrolls. Web-based UI element positioning methods cannot handle the dynamic coordinate shifts of UI elements caused by nesting levels.

[0009] Third, when displaying app page heatmaps on web pages, each UI control typically has a unique ID (identifier) ​​or class name. Android systems have a control reuse mechanism (such as Item reuse in RecyclerView), where multiple controls with the same style may share the same element identifier, differing only in position. If the display logic from the web page is followed, it will lead to incorrect overlay of heatmap data. For example, clicking the button for the first item in the list will simultaneously render the heatmap at the positions of all reused list item buttons.

[0010] Fourth, the web can simplify adaptation to different screen resolutions through responsive layout.

[0011] Android app pages need to be compatible with different mobile terminal brands, different screen resolutions, different foldable screen forms (sudden changes in screen size between unfolded and folded states), and system font scaling (user adjustments to font size cause element size stretching). This results in significant differences in the physical position and pixel ratio of the same element on the Android app page under different configurations. Directly reusing the display logic of the web version will lead to heatmap offsets or stretching distortion.

[0012] Fifth, the monitor's screen size is relatively large, making the small positioning error of the heat map visually acceptable.

[0013] Mobile devices have smaller screens than monitors, and user interactions are more concentrated (such as small buttons and densely populated control areas), requiring heatmaps to have higher pixel-level positioning accuracy. If the positioning deviation exceeds 5 pixels, the heatmap will become completely disconnected from the actual click location (e.g., clicking the left side of a button will result in the heatmap appearing on the right side of the button). Summary of the Invention

[0014] The technical problem to be solved by this invention is: how to render and display the heat map of the APP page in real time and accurately in the Android system.

[0015] To address the aforementioned technical problems, this invention proposes a method for generating heatmaps and displaying them in an Android app, comprising the following steps: Step S1: The Android app collects user interactions with UI controls on the app's pages, records these interactions in the full-tracking reporting information, and transmits them to the server. The UI control interaction information includes the width and height of the UI control being interacted with, the X-axis and Y-axis coordinates of the top-left corner of the UI control relative to the top-left corner of the screen, and the X-axis and Y-axis coordinates of the user's touch position relative to the top-left corner of the UI control. Step S2: The server rasterizes each UI control on each page of the Android app, meaning the server divides each UI control on each page of the Android app into multiple grid units. Step S2 and Step S1 can be performed either sequentially or simultaneously. Step S3: The server receives the full-tracking information reported by the APP from all Android mobile terminals, and generates grid-level heatmap data for each page of the APP, including element business aliases and a two-dimensional array. The element business aliases include the page ID, the alias of the top-level container, the alias of the parent container, the alias of the control, and the current state of the control. The two-dimensional array includes the grid cell index and the number of user touches. Step S4: The user enters a page of the Android APP and requests the heatmap data for that page. The Android APP requests the heatmap data for that page from the server, along with the element business aliases of each UI control currently displayed on the page. Step S5: The server returns the grid-level heatmap data for that page based on the page ID. Step S6: The Android APP receives the grid cell-level heatmap data of the page, matches the corresponding UI control in the current page according to the alias of the parent container and the control alias, traverses the two-dimensional array to obtain the touch count of each grid cell, calculates the color depth or color difference based on the touch count of each grid cell, and overlays and renders a semi-transparent heatmap layer on top of the current page.

[0016] Furthermore, the fully embedded reporting information includes: page ID, width and height of the UI control operated by the user, screen width and height of the mobile terminal, X-axis and Y-axis coordinates of the top left corner of the UI control operated by the user relative to the top left corner of the screen, X-axis and Y-axis coordinates of the user's touch position relative to the top left corner of the UI control operated, and the business version of the APP in the Android system.

[0017] Furthermore, in step S1, the Android APP uses a dual positioning method for the user's touch position—first, it obtains the X-axis and Y-axis coordinates of the upper left corner of the UI control operated by the user relative to the upper left corner of the screen; then, it calculates the X-axis and Y-axis coordinates of the user's touch position relative to the upper left corner of the UI control operated by the user; finally, it superimposes the two to obtain the X-axis and Y-axis coordinates of the user's touch position relative to the upper left corner of the screen.

[0018] Furthermore, in step S2, the same UI control on the same screen resolution uses the same grid cell size; the number and index of grid cells in the same UI control on different screen resolutions remain unchanged, and the size of each grid cell is adaptively adjusted according to the screen resolution.

[0019] Further, in step S2, the server generates the index (i,j) of each grid cell according to the coordinate system of the UI control itself, representing the grid cell in the i-th row and j-th column of the UI control; the Android APP first obtains the absolute coordinates (x0,y0) of the UI control relative to the top left corner of the screen, and then combines the grid division unit of the UI control to convert the relative index (i,j) of each grid cell in the UI control into the absolute pixel coordinates of the screen globally.

[0020] Furthermore, in step S3, the server establishes a unique association of "page - top-level container - parent container - element" through element business aliases.

[0021] Furthermore, in step S3, the server matches the page ID and the APP business version, and only counts the number of user touches that match the current page and the current APP business version.

[0022] Furthermore, in step S4, the element business aliases of UI controls not currently displayed on the page are not carried.

[0023] Furthermore, in step S6, once the Android APP detects a change in the page layout of the Android APP, steps S4 to S6 are repeated.

[0024] This invention also proposes an apparatus for generating heatmaps and displaying them in an Android app, comprising a data collection and reporting unit, a rasterization unit, a heatmap generation unit, a request unit, a transmission unit, and a heatmap rendering unit. The data collection and reporting unit collects user interactions with UI controls on the Android app's pages, records these interactions in the full-tracking reporting information, and transmits them to the server. The UI control interaction information includes the width and height of the UI control being interacted with, the X and Y coordinates of the top-left corner of the UI control relative to the top-left corner of the screen, and the X and Y coordinates of the user's touch position relative to the top-left corner of the UI control. The rasterization unit rasterizes each UI control on each page of the Android app, meaning the server divides each UI control on each page of the Android app into multiple raster units. The heatmap generation unit receives all the event tracking information reported by all Android apps and generates grid-level heatmap data for each page of the app, including element business aliases and a two-dimensional array. The element business aliases include the page ID, the alias of the top-level container, the alias of the parent container, the alias of the control, and the current state of the control. The two-dimensional array includes the index of each grid cell and the number of user touches. The request unit requests the heatmap data of the current page of the Android app from the server. The Android app also carries the element business aliases of each UI control displayed on the current page. The transmission unit returns the grid-level heatmap data of the page based on the page ID. The heatmap rendering unit receives the requested grid-level heatmap data of the page, matches the corresponding UI control on the current page based on the alias of the parent container and the control alias, traverses the two-dimensional array to obtain the number of user touches for each grid cell, calculates the color depth or color difference based on the number of touches for each grid cell, and overlays and renders a semi-transparent heatmap layer on top of the current page. The data collection and reporting unit, the request unit, and the heat map rendering unit are located on the mobile terminal side, while the rasterization unit, the heat map generation unit, and the transmission unit are located on the server side.

[0025] The technical effect achieved by this invention is that: based on the grid cell-level heatmap data of the requested Android APP page sent by the server, the Android APP dynamically matches each UI control in the requested Android APP page, generates and draws a heatmap layer covering the entire page on the current page of the Android APP, thereby improving the real-time performance, accuracy and user experience of the heatmap display. Attached Figure Description

[0026] Figure 1 This is a flowchart illustrating the method for generating heatmaps and displaying them in an Android app, as proposed in this invention.

[0027] Figure 2This is a schematic diagram of the device proposed in this invention for generating heat maps and displaying them in an Android app.

[0028] The attached figures are labeled as follows: 1. Data collection and reporting unit; 2. Rasterization unit; 3. Heatmap generation unit; 4. Request unit; 5. Transmission unit; 6. Heatmap rendering unit. Detailed Implementation

[0029] Please see Figure 1 The method for generating heatmaps and displaying them in an Android app, as proposed in this invention, includes the following steps.

[0030] Step S1: The Android app collects user interactions with UI controls on the app's pages and records them in full-tracking reporting information, which is then transmitted to the server. Full-tracking refers to a technique in mobile application analytics that comprehensively records every interaction between a user and the app. Full-tracking technology is typically used to collect all user action data within the app. The aim of full-tracking is to provide the most detailed possible application usage information, allowing developers to better understand user behavior and optimize app performance and user experience. The UI control interaction information includes the width and height of the UI control being interacted with, the X and Y coordinates of the top-left corner of the UI control relative to the top-left corner of the screen, and the X and Y coordinates of the user's touch position relative to the top-left corner of the UI control.

[0031] As an example, the fully embedded reporting information includes: page ID (identifier), width of the UI control operated by the user, height of the UI control operated by the user, screen width of the mobile terminal, screen height of the mobile terminal, X-axis coordinate of the top left corner of the UI control operated by the user relative to the top left corner of the screen, Y-axis coordinate of the top left corner of the UI control operated by the user relative to the top left corner of the screen, X-axis coordinate of the user's touch position relative to the top left corner of the UI control operated, Y-axis coordinate of the user's touch position relative to the top left corner of the UI control operated, and the business version of the APP in the Android system.

[0032] In this step, the Android app uses a dual positioning method to determine the user's touch position. First, the Android app obtains the X and Y coordinates of the top-left corner of the UI control being manipulated relative to the top-left corner of the screen. Then, it calculates the X and Y coordinates of the user's touch position relative to the top-left corner of the manipulated UI control. Finally, the two coordinates are superimposed to obtain the X and Y coordinates of the user's touch position relative to the top-left corner of the screen. Even if the UI control dynamically changes due to page scrolling or collapsing, the accuracy of the user's touch position within the UI control can be ensured by updating the coordinates of the top-left corner of the UI control in real time.

[0033] Step S2: The server performs gridding on each UI control on each page of the Android app. This means the server divides each UI control on each page of the Android app into multiple grid units. For example, a button is 100 pixels × 100 pixels. If the grid unit size is 20 pixels × 20 pixels, then the button is divided into 5 × 5 = 25 grid units. If the grid unit size is 40 pixels × 40 pixels, then the button is divided into 3 × 3 = 9 grid units. Cases where the division is not exact are rounded up.

[0034] Preferably, the size of the grid cells within the same UI control is bound to the screen resolution of the mobile terminal, with the same grid cell size used for the same screen resolution. To avoid heatmap stretching or offset due to differences in screen resolution, the number and index of grid cells in the same UI control remain unchanged across different screen resolutions, and the size of each grid cell is adaptively adjusted according to the screen resolution to ensure that the heatmap is perfectly aligned with the physical position of the UI control. For example, the size of the same button on a 1920 pixel × 1080 pixel screen is 120 pixels × 60 pixels, and the size of the grid cell is 30 pixels × 30 pixels; the size of the same button on a 2560 pixel × 1440 pixel screen is 160 pixels × 80 pixels, and the size of the grid cell is adaptively adjusted to 40 pixels × 40 pixels.

[0035] In this step, the server generates the index (i,j) of each grid cell based on the UI control's own coordinate system, representing the grid cell in the i-th row and j-th column of the UI control. The Android app first obtains the absolute coordinates (x0,y0) of the UI control relative to the top-left corner of the screen, and then combines this with the grid cell (unit) of the UI control. Here, it is assumed that the X-axis size and Y-axis size of each grid cell are the same, both being "unit". The relative index (i,j) of each grid cell within the UI control is converted into the absolute pixel coordinates of the entire screen. The formula is: the absolute coordinate of the top-left corner of each grid cell is (x0 + i × unit, y0 + j × unit), and the absolute coordinate of the bottom-right corner of each grid cell is (x0 + (i + 1) × unit, y0 + (j + 1) × unit), thus unifying the coordinate system of all grid cells of the UI control.

[0036] The order of steps S2 and S1 is not strictly limited; they can be performed either before or simultaneously.

[0037] Step S3: The server receives full event tracking information reported by the app from all Android mobile terminals. It then counts the number of user touches for each grid cell of each UI control on each page, generating grid-level heatmap data for each page of the app. The number of user touches for each grid cell is represented by the intensity or difference of the color. For example, a darker color indicates more touches, and a lighter color indicates fewer touches. Similarly, a redder color indicates more touches, and a greener color indicates fewer touches, with yellow as a transition. If the app has identical pages on other systems (e.g., iOS), this step also receives full event tracking information reported by the app on those other mobile terminals and includes it in the statistics.

[0038] As an example, the grid-level heatmap data for each page of this app includes: an element business alias (businessName) and a two-dimensional array (grid). The element business alias includes the page ID, the alias of the top-level container, the alias of the parent container, the control alias, and the current control's state. Here, "element" refers to UI controls. The current control's state includes whether the UI control is active or inactive (whether it's in an active interactive state), selected or unselected (whether checkboxes, tab switches, etc., are selected), enabled or disabled (whether it's interactive), and shown or hidden (whether it's displayed on the current screen). In the Android system, pages, top-level containers, parent containers, and UI controls form a hierarchical tree structure. For example, if the current control is a scrolling list, the current control's state is indicated by the `map_index` parameter, which item in the scrolling list the current UI control is. The first dimension of the two-dimensional array represents the index of the grid cell in the current element (i.e., the current UI control), and the second dimension represents the number of touches on each grid cell.

[0039] In this step, the server establishes a unique association of "page - top-level container - parent container - element" through element business aliases, rather than relying on fixed paths. Even if the page structure changes dynamically (such as changes in element nesting levels or control reuse), as long as the element business aliases remain unchanged, the Android app can accurately match the heatmap data of the corresponding UI control by traversing the UI control tree of the current page. For example, in the case of control reuse, the control aliases are the same, but the aliases of the parent containers are different, which can accurately distinguish each reused UI control and avoid confusion of heatmap data.

[0040] In this step, the server matches data based on the page ID and the app version, only counting data that matches the current page and the current app version. This avoids invalid data from across pages and versions from being included in the rendering process, thus improving matching efficiency and data accuracy.

[0041] Step S4: The user enters a page in the Android app and requests the heatmap data for that page. The Android app requests the heatmap data for that page from the server, along with the element business aliases of each UI control currently displayed on the page. For hidden UI controls that are not displayed on the current mobile device screen, this step does not include the element business aliases of UI controls not currently displayed on the page.

[0042] Step S5: The server returns the grid cell-level heatmap data for the page based on the page ID.

[0043] Step S6: The Android APP receives the grid cell-level heatmap data of the page, matches the corresponding UI control in the current page according to the alias of the parent container and the control alias, traverses the two-dimensional array to obtain the touch count of each grid cell, calculates the color depth or color difference based on the touch count of each grid cell, generates a standardized data format that can be directly called by the H5 page, and overlays and renders a semi-transparent heatmap layer on top of the current page to ensure the consistency of cross-platform rendering.

[0044] This invention adopts a scheme of "client-side data collection and reporting - server-side rasterization and distribution - client-side matching, aggregation and rendering".

[0045] In this step, once the Android app detects a change in the page layout—such as unfolding or folding a folded screen, or adjusting the font size—it repeats steps S4 to S6, re-requesting the heatmap data for that page from the server, while also carrying the element business aliases of each UI control currently displayed on the page. This is to recalculate the position of each grid cell based on the updated screen resolution, UI control size, and position, and to re-render the heatmap layer, ensuring that the heatmap is synchronized in real time with the dynamically changed page.

[0046] Please see Figure 2 The device for generating heat maps and displaying them in an Android app proposed in this invention includes a data acquisition and reporting unit 1, a rasterization unit 2, a heat map generation unit 3, a request unit 4, a transmission unit 5, and a heat map rendering unit 6. Figure 2 The device shown corresponds to Figure 1 The method shown.

[0047] The data collection and reporting unit 1 is used to collect user operations on UI controls in the Android APP's page and record them in the full-tracking reporting information, which is then transmitted to the server. The UI control operation information includes the width and height of the UI control operated by the user, the X-axis and Y-axis coordinates of the top-left corner of the UI control operated by the user relative to the top-left corner of the screen, and the X-axis and Y-axis coordinates of the user's touch position relative to the top-left corner of the UI control operated by the user.

[0048] The rasterization unit 2 is used to rasterize each UI control in each page of the Android APP.

[0049] The heatmap generation unit 3 receives all the event tracking information reported by all Android apps and generates grid-level heatmap data for each page of the app. The number of user touches per grid cell is represented by the intensity or difference of the color. The grid-level heatmap data includes element business aliases and a two-dimensional array. The element business aliases include the page ID, the alias of the top-level container, the alias of the parent container, the alias of the control, and the current state of the control. The two-dimensional array includes the index of each grid cell and the number of user touches.

[0050] The request unit 4 is used to request heatmap data of the current page of the Android APP from the server, and at the same time carry the element business aliases of each UI control that has been displayed on the current page.

[0051] The transmission unit 5 is used to return the grid cell level heatmap data of the page according to the page ID.

[0052] The heatmap rendering unit 6 is used to receive grid cell-level heatmap data of the requested page, match the corresponding UI control in the current page according to the alias of the parent container and the control alias, traverse the two-dimensional array to obtain the number of user touches of each grid cell, calculate the color depth or color difference according to the number of touches of each grid cell, generate a standardized data format for H5 page to call, and overlay and render a semi-transparent heatmap layer on the top of the current page.

[0053] Among them, the data collection and reporting unit 1, the request unit 4, and the heat map rendering unit 6 are located on the mobile terminal side, while the rasterization unit 2, the heat map generation unit 3, and the transmission unit 5 are located on the server side.

[0054] Compared with existing heatmap generation and display solutions, this application achieves the following beneficial effects.

[0055] First, this invention breaks through the limitation of traditional heat maps being displayed only on web pages, and realizes the dynamic matching of page elements to render and display heat maps on Android APP pages, thereby improving user experience and operational continuity.

[0056] Secondly, this invention abandons the traditional web-based matching method based on fixed element paths. Instead, it achieves precise matching between heatmap data and UI controls by using the business alias of elements in the heatmap data (businessName). This ensures a one-to-one correspondence between the heatmap data on the APP page and the UI controls in the dynamically changing pages on the client side, completely solving the matching misalignment problem caused by dynamic layout, control reuse, nesting level changes, multi-resolution, and foldable screen adaptation, thus improving the accuracy of heatmap drawing.

[0057] Third, this invention uses grid cells to aggregate click data, significantly reducing data transmission volume. The client dynamically generates a heatmap based on the touch data of the grid cells, balancing performance and visualization effects. For example, a business details page of an Android app generates 16,967,798 original clicks in a month. Without gridding, to visualize the click locations, the server would need to transmit all the data, including the precise coordinates, associated UI controls, and click times of 16.96 million original clicks, to the client—a massive amount of data. Gridding, however, statistically analyzes these 16.96 million original data points by grid cell, requiring only the click count for each grid cell to be transmitted. Ultimately, only the aggregated grid data is transmitted, significantly reducing data transmission volume.

[0058] The above are merely preferred embodiments of the present invention and are not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for generating a heat map and displaying in an Android APP, characterized in that, Includes the following steps; Step S1: The Android APP collects the user's operation on the UI controls on the APP page, records it in the full-tracking reporting information, and transmits it to the server; the UI control operation information includes the width and height of the UI control operated by the user, the X-axis and Y-axis coordinates of the upper left corner of the UI control operated by the user relative to the upper left corner of the screen, and the X-axis and Y-axis coordinates of the user's touch position relative to the upper left corner of the UI control operated. Step S2: The server performs gridding on each UI control on each page of the Android APP. This means that the server divides each UI control on each page of the Android APP into multiple grid units. The order of step S2 and step S1 can be arbitrary, or they can be performed simultaneously; Step S3: The server receives the full-tracking information reported by the APP from all Android mobile terminals and generates grid cell-level heatmap data for each page of the APP, including element business aliases and a two-dimensional array; the element business aliases include page ID, top-level container alias, parent container alias, control alias, and current control status; the two-dimensional array includes grid cell index and user touch count. Step S4: The user enters a page of the Android APP and requests the heatmap data of that page; the Android APP requests the heatmap data of that page from the server, and at the same time carries the element business aliases of each UI control displayed on the current page; Step S5: The server returns the grid cell-level heatmap data for the page based on the page ID; Step S6: The Android APP receives the grid cell-level heatmap data of the page, matches the corresponding UI control in the current page according to the alias of the parent container and the control alias, traverses the two-dimensional array to obtain the touch count of each grid cell, calculates the color depth or color difference based on the touch count of each grid cell, and overlays and renders a semi-transparent heatmap layer on top of the current page.

2. The method for generating heat map and displaying in Android APP according to claim 1, characterized in that, The fully embedded reporting information includes: page ID, width and height of the UI control operated by the user, screen width and height of the mobile terminal, X-axis and Y-axis coordinates of the top left corner of the UI control operated by the user relative to the top left corner of the screen, X-axis and Y-axis coordinates of the user's touch position relative to the top left corner of the UI control operated by the user, and the business version of the APP in the Android system.

3. The method for generating heat map and displaying in Android APP according to claim 1, characterized in that, In step S1, the Android APP uses a dual positioning method to determine the user's touch position: first, it obtains the X-axis and Y-axis coordinates of the upper left corner of the UI control operated by the user relative to the upper left corner of the screen; then, it calculates the X-axis and Y-axis coordinates of the user's touch position relative to the upper left corner of the UI control operated by the user; finally, it superimposes the two coordinates to obtain the X-axis and Y-axis coordinates of the user's touch position relative to the upper left corner of the screen.

4. The method for generating heat map and displaying in Android APP of claim 1, characterized in that, In step S2, the same UI control on the same screen resolution uses the same grid cell size; the number and index of grid cells in the same UI control on different screen resolutions remain unchanged, and the size of each grid cell is adaptively adjusted according to the screen resolution.

5. The method for generating heat map and displaying in Android APP according to claim 1, characterized in that, In step S2, the server generates the index (i,j) of each grid cell according to the coordinate system of the UI control itself, which represents the grid cell in the i-th row and j-th column of the UI control; the Android APP first obtains the absolute coordinates (x0,y0) of the UI control relative to the top left corner of the screen, and then combines the grid division unit of the UI control to convert the relative index (i,j) of each grid cell in the UI control into the absolute pixel coordinates of the screen globally.

6. The method for generating heat map and displaying in Android APP of claim 1, characterized in that, In step S3, the server establishes a unique association of "page - top-level container - parent container - element" through element business aliases.

7. The method for generating heat map and displaying in Android APP according to claim 2, characterized in that, In step S3, the server matches the page ID and the APP business version, and only counts the number of user touches that match the current page and the current APP business version.

8. The method for generating heat map and displaying in Android APP of claim 1, characterized in that, In step S4, the element business aliases of UI controls not currently displayed on the page are not carried.

9. The method for generating heat map and displaying in Android APP according to claim 2, characterized in that, In step S6, once the Android APP detects a change in the page layout of the Android APP, steps S4 to S6 are repeated.

10. An apparatus for generating a heat map and displaying in an Android APP, characterized in that, It includes a data acquisition and reporting unit, a rasterization unit, a heatmap generation unit, a request unit, a transmission unit, and a heatmap rendering unit; The data collection and reporting unit is used to collect user operations on UI controls in the Android APP page, record them in the full-tracking reporting information, and transmit them to the server. The UI control operation information includes the width and height of the UI control operated by the user, the X-axis and Y-axis coordinates of the upper left corner of the UI control operated by the user relative to the upper left corner of the screen, and the X-axis and Y-axis coordinates of the user's touch position relative to the upper left corner of the UI control operated by the user. The gridding unit is used to grid each UI control in each page of the Android APP. This means that the server divides each UI control in each page of the Android APP into multiple grid units. The heatmap generation unit is used to receive the full-tracking information reported by all Android apps and generate grid-level heatmap data for each page of the app, including element business aliases and a two-dimensional array; the element business aliases include page ID, top-level container alias, parent container alias, control alias, and current control state; the two-dimensional array includes the index of each grid cell and the number of user touches. The request unit is used to request heatmap data of the current page of the Android APP from the server. The Android APP also carries the element business aliases of each UI control that has been displayed on the current page. The transmission unit is used to return the grid cell-level heatmap data of the page according to the page ID; The heatmap rendering unit is used to receive grid cell-level heatmap data of the requested page, match the corresponding UI control in the current page according to the alias of the parent container and the control alias, traverse the two-dimensional array to obtain the number of user touches of each grid cell, calculate the color depth or different colors according to the number of touches of each grid cell, and overlay and render a semi-transparent heatmap layer on top of the current page. The data collection and reporting unit, the request unit, and the heat map rendering unit are located on the mobile terminal side, while the rasterization unit, the heat map generation unit, and the transmission unit are located on the server side.

Images