Method, device and equipment for collecting page browsing duration of swan monk system, storage medium and product

Abstract

The invention relates to the technical field of computers, and discloses a method, a device, equipment, a storage medium and a product for collecting page browsing duration of a swan mongolian system.The method comprises the steps that event triggering conditions of a routing page and a navigation page are obtained in real time through double monitors deployed in parallel, and the routing navigation modes of the routing page and the navigation page are different; the routing page comprises a navigation page; when a navigation target switching event of the navigation page is triggered, determining a current effective page, and determining a navigation page duration according to the current effective page; when the routing page updating event of the routing page is triggered, judging the updating type of the routing page, and determining the duration of the routing page according to the updating type; and determining browsing duration of the page according to the navigation page duration and the routing page duration. The event triggering conditions of the two routing frameworks are monitored at the same time, and the corresponding browsing duration is determined for the two different routing navigation modes, so that full-coverage acquisition of the two routing navigation modes is realized, and the accuracy of data is ensured.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, apparatus, device, storage medium, and product for collecting page browsing time in the HarmonyOS system. Background Technology

[0002] Currently, HarmonyOS provides two routing and navigation methods: router and navigation. The router method is used to solve page switching, data transfer, and page stack management at the application window level, such as jumping from a complete page to a completely new page (from the product list to the product details). The navigation method mainly solves the problem of switching between partial views within a single page, such as switching between different functional modules within a main page (clicking the "Home", "Shop", "My" tabs at the bottom of the application to switch to the corresponding sub-view area).

[0003] Traditional methods for collecting page view duration can only process the data based on a single routing framework. For projects that use a mix of routing and navigation methods (such as in a HarmonyOS application where deep navigation through full-screen pages is performed via router, and then switching core modules on the navigation bar via navigation after navigating to the current page), the duration can only be calculated separately for the router page and navigation page under their respective routing frameworks, and then summed. This results in missing data for pages corresponding to uncovered routing frameworks, leading to incomplete overall page view duration data that doesn't fully reflect actual user page access behavior. Consequently, there are issues with inaccurate or missing data when collecting page view duration. For example, when a router page contains a navigation page, on the one hand, switching between navigation pages can easily confuse the router page duration with the navigation page duration in the statistics; on the other hand, router page updates do not adapt the corresponding duration calculation rules for different update types. Summary of the Invention

[0004] The main purpose of this application is to provide a method, device, equipment, storage medium and product for collecting page browsing time in HarmonyOS, aiming to solve the technical problem that existing page browsing time collection methods have inaccurate statistics or missing statistical data when collecting page browsing time in HarmonyOS systems where two routing navigation methods coexist.

[0005] To achieve the above objectives, this application proposes a method for collecting page browsing time in the HarmonyOS system. The method includes:

[0006] The event triggering status of the routing page and navigation page is obtained in real time by dual listeners deployed in parallel. The routing page and navigation page have different routing and navigation methods, and the routing page includes the navigation page.

[0007] When the navigation target switching event of the navigation page is triggered, the currently valid page is determined, and the duration of the navigation page is determined based on the currently valid page;

[0008] When the route page update event of the route page is triggered, determine the update type of the route page, and determine the route page duration based on the update type;

[0009] The page browsing duration is determined based on the duration of the navigation page and the duration of the routing page.

[0010] Optionally, the step of determining the currently valid page and determining the duration of the navigation page based on the currently valid page when the navigation target switching event of the navigation page is triggered includes:

[0011] When the navigation target switching event of the navigation page is triggered, record the current navigation page;

[0012] Based on the current navigation page, determine whether the navigation page returns to the navigation bar, and determine the currently valid page based on the determination result;

[0013] Record the page entry time of the currently valid page;

[0014] The navigation page duration is calculated based on the page entry time and the historical navigation entry time. The historical navigation entry time is the page entry time of the currently valid page corresponding to the last navigation target switching event.

[0015] Optionally, the step of determining whether the current navigation page returns to the navigation bar based on the current navigation page, and determining the currently valid page based on the determination result, includes:

[0016] Obtain the page identifier of the current navigation page and compare the page identifier with the preset navigation bar page identifier;

[0017] If the comparison matches, it is determined that the navigation page returns to the navigation bar, and the current route page corresponding to the navigation bar is set as the current valid page;

[0018] If the comparison is inconsistent, it is determined that the navigation page has not returned to the navigation bar, and the current navigation page is set as the current valid page.

[0019] Optionally, the step of determining the update type of the route page and determining the duration of the route page based on the update type when the route page update event is triggered includes:

[0020] When the route page update event of the route page is triggered, obtain the status information corresponding to the route page update event;

[0021] The update type of the route page is determined based on the status information, and the update type includes page display events and page hide events;

[0022] If the update type is a page hide event, the routing page duration is calculated based on the trigger time of the page hide event and the first historical trigger time of the previous page hide event.

[0023] Alternatively, the duration of the routed page can be calculated based on the trigger time of the page hiding event and the second historical trigger time of the previous page display event, provided that no routed page update event was triggered between the page hiding event and the previous page display event.

[0024] Optionally, after the step of determining the update type of the route page based on the status information, wherein the update type includes page display events and page hide events, the method further includes:

[0025] If the update type is a page display event, then record the current route page and determine whether the current route page has changed;

[0026] If so, the current route page is updated to the current valid page, and the trigger time of the page display event is used as the page entry time of the current valid page;

[0027] If not, then the current valid page of the route page remains unchanged.

[0028] Optionally, after the step of determining the page browsing duration based on the navigation page duration and the routing page duration, the method further includes:

[0029] The page browsing time is validated to determine whether the page browsing time conforms to the preset time logic rules;

[0030] If the browsing time of the page does not conform to the duration logic rule, the browsing time will be corrected based on the page's historical browsing time data and the current page's attribute information.

[0031] Furthermore, to achieve the above objectives, this application also proposes a HarmonyOS system page browsing time collection device, which includes:

[0032] The event trigger listening module is used to obtain the event triggering status of the routing page and the navigation page in real time through dual listeners deployed in parallel. The routing page and the navigation page have different routing and navigation methods, and the routing page includes the navigation page.

[0033] The navigation duration determination module is used to determine the currently valid page and determine the navigation page duration based on the currently valid page when the navigation target switching event of the navigation page is triggered.

[0034] The route duration determination module is used to determine the update type of the route page when the route page update event is triggered, and determine the route page duration based on the update type.

[0035] The browsing duration determination module is used to determine the browsing duration of a page based on the duration of the navigation page and the duration of the routing page.

[0036] In addition, to achieve the above objectives, this application also proposes a HarmonyOS page browsing time collection device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the HarmonyOS page browsing time collection method described above.

[0037] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the HarmonyOS page browsing time collection method described above.

[0038] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the HarmonyOS system page browsing time collection method described above.

[0039] This application discloses a method for real-time acquisition of event triggering status of routing pages and navigation pages through parallel deployment of dual listeners. The routing pages and navigation pages employ different routing and navigation methods, with the routing page encompassing the navigation page. When a navigation target switching event is triggered on the navigation page, the currently valid page is determined, and its duration is calculated based on this. When a routing page update event is triggered on the routing page, the update type is determined, and its duration is calculated based on this. Finally, the page browsing duration is determined based on both the navigation page duration and the routing page duration. By simultaneously listening to the event triggering status of both routing and navigation pages, and determining the navigation page duration and routing page duration for the two different routing and navigation methods respectively, and integrating these to obtain the page browsing duration, full coverage data collection for both routing and navigation methods is achieved, ensuring the comprehensiveness, accuracy, and continuity of the page browsing duration data. Furthermore, through a dynamic tracking mechanism of the currently valid page, seamless data connection is achieved when switching between the navigation page and the routing page, effectively avoiding confusion, duplication, or omissions in duration statistics under different routing modes. Attached Figure Description

[0040] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0041] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0042] Figure 1 This is a flowchart illustrating the first embodiment of the HarmonyOS system page browsing time collection method of this application;

[0043] Figure 2 This is a flowchart illustrating the second embodiment of the HarmonyOS system page browsing time collection method of this application;

[0044] Figure 3 This is a schematic diagram illustrating the route switching of the navigation page in this application;

[0045] Figure 4 This is a flowchart illustrating the third embodiment of the HarmonyOS system page browsing time collection method of this application;

[0046] Figure 5 This is a schematic diagram of the module structure of the HarmonyOS page browsing time collection device in an embodiment of this application;

[0047] Figure 6This is a schematic diagram of the hardware operating environment involved in the HarmonyOS page browsing time collection method in this application embodiment.

[0048] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0049] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0050] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0051] HarmonyOS provides two routing and navigation methods. Traditional data collection methods can only process the collection time based on a single routing framework. Existing technologies lack a mechanism for linking and integrating the time data of the two routing frameworks. When a user switches between the routing page and the navigation page, the time data under different routing frameworks are independent and have no connection. It is impossible to form a complete user page access time chain. For example, the entire process time from the routing page to the navigation page and back to the routing page cannot be counted continuously. Furthermore, the routing page and the navigation page are nested, and there is a lack of coordinated processing of the event triggering logic of the two routing frameworks, which leads to duplication, omission, or logical errors in the time calculation.

[0052] Therefore, this application provides a method for collecting page browsing time in HarmonyOS system. It simultaneously monitors the event triggering of two routing frameworks, distinguishes the event types of the two routing frameworks, clarifies the criteria for determining the current valid page and adapts the time calculation logic to different scenarios, and realizes the collaborative association of the two time data based on the dynamic determination of the current valid page, and finally integrates them to obtain the complete page browsing time, ensuring the accuracy of the data.

[0053] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, page navigation, and program execution functions, such as a computer, or an electronic device capable of performing the above functions. The following description uses an electronic device applied to the HarmonyOS system as an example to illustrate this embodiment and the subsequent embodiments.

[0054] Based on this, this application provides a method for collecting page browsing time in the HarmonyOS system, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the HarmonyOS system page browsing time collection method of this application.

[0055] In this embodiment, the method for collecting page browsing time in the HarmonyOS system includes:

[0056] Step S10: The event triggering status of the routing page and the navigation page is obtained in real time through dual listeners deployed in parallel. The routing page and the navigation page have different routing and navigation methods, and the routing page includes the navigation page.

[0057] It should be noted that the routing page refers to the page in the HarmonyOS system that implements page navigation and management based on the Router routing framework. Its routing navigation method triggers page switching through interfaces such as pushUrl and replaceUrl of the Router component, focusing on global navigation across pages. The navigation page refers to the page that implements page hierarchy management based on the Navigation routing framework. Its routing navigation method triggers local hierarchy switching within or between pages through events such as navDestinationSwitch of the Navigation component, focusing on structured navigation within the page.

[0058] Additionally, it's important to note that the routing and navigation methods for the routing page and the navigation page differ. Specifically, the Router routing framework uses URLs (Uniform Resource Locators) as the core identifier to implement page navigation and stack management, while the Navigation routing framework uses the NavDestination as the core to implement page-level switching and the association with the NavBar. These two differ fundamentally in their triggering mechanisms and management scope. A routing page containing a navigation page means that the navigation page is a sub-component of the routing page, such as a Navigation sub-component nested within the Router page. Users can trigger navigation level switching within the routing page.

[0059] It's understandable that, since the Router page and the Navigation page are contained within each other, when the Router route triggers an entry page but doesn't trigger an exit page, and instead triggers an entry page for the Navigation page, the currently valid page is the Navigation page, and the page browsing time is the sum of the Router page's duration and the Navigation page's duration.

[0060] It should be understood that when using dual listeners deployed in parallel to monitor event triggering on the routing and navigation pages in real time, the lifecycle callbacks of both the Router and Navigation pages can be listened to simultaneously. This is achieved by registering event listeners for the corresponding routing framework at the application or framework layer of the HarmonyOS system. For example, for the routing page, the RouterPageUpdate listener (routing page update event) of the Router framework is registered. This listener can capture state update events such as the display (e.g., page loading, foreground switching) and hiding (e.g., page popping, background switching) of the routing page. For the navigation page, the NavDestinationSwitch listener (nav target switching event) of the Navigation framework is registered. This listener can capture target switching events (e.g., switching from one NavDestination to another) and hierarchical change events such as returning to the NavBar. By deploying dual listeners in parallel, the state change signals of pages under the two routing frameworks can be obtained in real time. Combined with the nesting relationship between routing pages and navigation pages, this lays the foundation for data collection to differentiate different routing scenarios and accurately determine the currently valid page, avoiding event omissions caused by a single route listener.

[0061] Step S20: When the navigation target switching event of the navigation page is triggered, determine the currently valid page and determine the duration of the navigation page based on the currently valid page.

[0062] It's important to note that the navigation target switching event refers to the event triggered when the target page (NavDestination) of a navigation page changes hierarchy within the HarmonyOS Navigation routing framework. This corresponds to the system event `navDestinationSwitch`. Triggering scenarios include switching from one NavDestination page to another, or returning to the NavBar from a NavDestination page. The currently active page refers to the page the user is currently browsing and interacting with. In scenarios where routing and navigation pages are nested, this needs to be dynamically determined based on the specific scenario of the navigation target switching event; it could be a navigation page (when not returning to the navigation bar) or a routing page (when returning to the navigation bar). The navigation page duration refers to the duration from when the user enters the navigation page to when they leave it, when the currently active page is a navigation page. It can be calculated based on the entry time of the currently active page and the trigger time of the next navigation target switching event.

[0063] It should be understood that if multiple navigation target switching events are triggered at the same time due to system delays or other factors, the event with the latest timestamp should be selected as the valid trigger event based on the timestamp carried by the event to avoid confusion in the determination of the current valid page due to event concurrency. At the same time, when recording the entry time of the current valid page, it is necessary to associate it with the page's lifecycle state to prevent deviations in duration calculation caused by the page not being fully loaded or being hidden.

[0064] Step S30: When the routing page update event of the routing page is triggered, determine the update type of the routing page and determine the duration of the routing page based on the update type.

[0065] It should be noted that the route page update event refers to the event triggered when the lifecycle state of a route page changes within the Router routing framework of the HarmonyOS system. It corresponds to the routerPageUpdate system event, and the triggering scenarios include the page switching from the background to the foreground, being covered or popped from the current stack, and initialization. The update type is based on the classification of route page state changes, specifically divided into page display events and page hide events. The route page duration refers to the duration for which a user browses the route page, that is, the time interval from when the route page enters the display state to when it enters the hidden state, which can be calculated based on the trigger time of the page display event and the page hide event.

[0066] It should be understood that when calculating the duration of a routed page, if there are multiple consecutive show / hide events, such as jitter caused by rapid page switching, a minimum time threshold can be set to filter out duration records less than the threshold, preventing distortion of duration data caused by high-frequency invalid events.

[0067] Step S40: Determine the page browsing duration based on the navigation page duration and the routing page duration.

[0068] Understandably, determining page browsing time based on navigation page duration and route page duration can be integrated using the dynamic switching logic of the currently active page: when the currently active page is a navigation page, the navigation page duration for that period is included in the total browsing time of the corresponding navigation page, while the accumulation of route page duration is paused; when the currently active page switches to a route page, the route page duration for that period is included in the total browsing time of the corresponding route page. For scenarios where the same page is accessed multiple times at different times, the navigation page duration or route page duration for each time period needs to be accumulated to form the complete browsing time of the page, ensuring that the duration data under the two routing frameworks is neither counted repeatedly nor that key time periods are missed.

[0069] It should be understood that determining the page browsing duration based on the navigation page duration and the routing page duration requires duration overlap verification. If the navigation page duration and routing page duration overlap due to system event delays (e.g., the navigation page has been switched but the routing page update event has not been triggered in time), the overlap can be corrected by comparing the current valid page lifecycle states corresponding to the two durations and using the lifecycle state change time as a benchmark to ensure the accuracy of the total browsing duration. Furthermore, for scenarios where the page is closed or destroyed, the incomplete navigation page duration or routing page duration must be forcibly calculated when the page lifecycle event is triggered to avoid data loss due to abnormal page destruction.

[0070] Furthermore, in order to perform validity verification after determining the page browsing duration, identify and process abnormal duration data, effectively filter or correct erroneous data that may occur during the collection process, and further improve the accuracy and reliability of the page browsing duration data, the method following step S40 also includes:

[0071] The page browsing time is validated to determine whether it conforms to a preset time logic rule. If the page browsing time does not conform to the time logic rule, the browsing time is corrected based on the page's historical browsing time data and the current page's attribute information.

[0072] It should be noted that validity verification refers to checking the logical rationality of the calculated page browsing time in order to identify abnormal data; preset duration logic rules refer to the pre-set standards used to determine the validity of the duration, including but not limited to the duration non-negativity rule (the browsing time cannot be negative), the life cycle matching rule (the browsing time cannot exceed the actual life cycle of the page from display to hiding), and the threshold range rule (the browsing time cannot exceed the reasonable duration range of similar pages); historical browsing time data refers to the set of records of the page being normally browsed within a certain period of time in the past; the attribute information of the current page includes information describing the characteristics of the page, such as page type (e.g., form page, display page), functional complexity (e.g., number of interactive elements), and typical browsing scenarios (e.g., fragmented browsing, deep operation).

[0073] It should be understood that when validating the page browsing duration, the calculated duration is first compared with the preset duration logic rules one by one: if the duration is negative, it violates the duration non-negativity rule; if the duration exceeds the actual lifecycle of the page from display to hiding, it violates the lifecycle matching rule; if the duration significantly deviates from the historical average duration of similar pages, it violates the threshold range rule. When an abnormal duration is determined, the normal duration range of the page is calculated based on historical browsing duration data. Combined with the attribute information of the current page, a weighted algorithm is used to determine the correction value, which replaces the abnormal duration, ensuring that the corrected duration conforms to historical patterns and is suitable for the characteristics of the current page.

[0074] Understandably, when performing validity checks, the threshold range in the preset duration logic rules can be iterated periodically based on the actual browsing data of the user group to avoid the rules becoming invalid due to changes in user behavior habits. For new pages without historical browsing data, the most similar historical pages can be matched based on page attributes through a similar page mapping mechanism, and their rules and correction parameters can be reused.

[0075] In this embodiment, by simultaneously acquiring the event triggering status of the routing page and navigation page in real time through dual listeners deployed in parallel, the duration of the navigation page and the duration of the routing page are determined for the two different routing and navigation methods, and then integrated to obtain the page browsing duration. This solves the problems of incomplete, inaccurate, and discontinuous data collection of page browsing duration when the two routing and navigation methods are used in combination in the prior art. It achieves full coverage collection of the two routing and navigation methods, ensuring the comprehensiveness, accuracy, and continuity of the page browsing duration data.

[0076] Reference Figure 2 , Figure 2 This is a flowchart illustrating the second embodiment of the HarmonyOS system page browsing time collection method of this application. Based on the first embodiment described above, a second embodiment of the HarmonyOS system page browsing time collection method of this application is proposed.

[0077] In the second embodiment, step S20 includes:

[0078] Step S201: When the navigation target switching event of the navigation page is triggered, record the current navigation page.

[0079] It should be noted that a navigation target switching event is triggered when a user's action causes a change in the target page of the navigation content area, such as when the user clicks a navigation bar toggle item or the back button. The current navigation page refers to the page actually displayed in the navigation content area after the navigation target switching event is completed. It is the specific page that the user is currently interacting with in the navigation hierarchy and has a unique page identifier.

[0080] Specifically, when the navigation target switching event of the navigation page is triggered, the event is first captured through the event listening interface provided by the HarmonyOS system (such as NavDestinationSwitch), and the unique identifier of the navigation target after the switch, such as the page route path and component ID, is parsed from the event callback parameters. Secondly, the corresponding navigation page instance is located based on the identifier, and its basic attribute information, such as page type and navigation bar, is obtained. Finally, the identifier and attribute information of the navigation page are associated with the event trigger timestamp and stored in the local temporary cache, while the global state variables of the current navigation page are updated.

[0081] Step S202: Determine whether the current navigation page returns to the navigation bar based on the current navigation page, and determine the current valid page based on the determination result.

[0082] It should be noted that returning to the navigation bar means that a user action (such as clicking the back button on the navigation bar) triggers the navigation page to switch from the sub-level page NavDestination to the root-level page corresponding to the navigation bar NavBar. At this time, the page displayed in the navigation content area is directly related to the navigation bar, rather than a nested sub-level page.

[0083] Furthermore, in order to determine whether the navigation page returns to the navigation bar through page identifier comparison, and to ensure accurate identification of the currently valid page between the navigation page and the routing page in switching scenarios, thus guaranteeing the accuracy of navigation page duration calculation, step S202 may include:

[0084] Obtain the page identifier of the current navigation page and compare it with the preset navigation bar page identifier; if the comparison matches, determine that the navigation page returns to the navigation bar and set the current route page corresponding to the navigation bar as the current valid page; if the comparison does not match, determine that the navigation page has not returned to the navigation bar and set the current navigation page as the current valid page.

[0085] It should be noted that the page identifier of the current navigation page refers to a string or code used to uniquely identify the current navigation page, such as a page route path, component ID, or custom unique identifier. The preset navigation bar page identifier refers to a unique identifier pre-stored in the system configuration to identify the root page corresponding to the navigation bar, and has a fixed association with the navigation bar.

[0086] Understandably, the process involves obtaining the page identifier of the current navigation page through the page attribute interface provided by the HarmonyOS system to ensure the completeness and accuracy of the identifier. Secondly, the page identifier corresponding to the navigation bar is read from the application's preset configuration file as a comparison benchmark. Then, a string matching method is used to compare the two identifiers. If the comparison results are consistent, it is determined that the user has returned from the sub-navigation page to the root page of the navigation bar. At this point, based on the nesting relationship between route pages and navigation pages, the current route page containing the navigation bar is set as the current valid page. If the comparison results are inconsistent, it is determined that the user is still within the sub-navigation page hierarchy, and the current navigation page is directly set as the current valid page, completing the dynamic update of the valid page.

[0087] Step S203: Record the page entry time of the currently valid page.

[0088] It should be noted that page entry time refers to the point in time when the currently valid page switches from an invisible state to a visible state and completes basic rendering (such as page component loading and data initialization).

[0089] Understandably, after identifying the current valid page, the system obtains the current millisecond-level timestamp through the time interface provided by HarmonyOS to ensure the consistency and accuracy of the time source. Secondly, it determines the type of the current valid page (navigation page or route page). If it is a navigation page, it needs to be confirmed that the page has been rendered and is visible before recording the timestamp. If it is a route page, it needs to be confirmed that the page has been loaded and displayed to avoid time recording deviations caused by incomplete page rendering. Finally, the obtained timestamp is bound to the page identifier of the current valid page and stored in the local cache.

[0090] Step S204: Calculate the navigation page duration of the navigation page based on the page entry time and the historical navigation entry time. The historical navigation entry time is the page entry time of the current valid page corresponding to the last navigation target switching event.

[0091] It should be noted that the historical navigation entry time refers to the page entry time of the currently valid page when the last navigation target switching event was triggered, corresponding to the navigation page for the current calculation duration.

[0092] Specifically, after the navigation target switching event is triggered and the current valid page is determined, the historical navigation entry time bound to the unique identifier of the navigation page is retrieved from the local cache, that is, the entry time recorded when the navigation page was last set as the current valid page; secondly, the time order of the current page entry time and the historical navigation entry time is confirmed, and it is necessary to ensure that the historical navigation entry time is earlier than the current page entry time to avoid time logic errors caused by abnormal event triggering order; finally, the duration of the navigation page from the last entry to the current switch is obtained by using the difference calculation method.

[0093] In one example, reference Figure 3 , Figure 3 This diagram illustrates the routing of the navigation page in this application. The left side is the NavBar, which includes a title bar, menus, a Navigation sub-component for the content area, and a toolbarConfiguration. The right side is the NavDestination sub-page, which includes a title bar, menus, and a NavDestination sub-component for the content area. The two can be switched between each other via routing, demonstrating the composition and interaction logic of different levels of pages in the HarmonyOS navigation system. This is used to construct the navigation flow within the application and help users switch between different functional pages.

[0094] It should be understood that when a user enters the navigation page from the routing page, the navigation target switching event and the routing page update event are not triggered, so only the page entry time of entering the navigation page is recorded.

[0095] In this embodiment, by recording the current navigation page to anchor the event-related object, and then determining whether to return to the navigation bar to accurately locate the current valid page, the continuity of the navigation page duration calculation is ensured, avoiding the confusion of duration segmentation caused by multiple switching, and effectively solving the problem of easy breakage of duration statistics in the nested relationship between navigation pages and routing pages.

[0096] Reference Figure 4 , Figure 4 This is a flowchart illustrating the third embodiment of the HarmonyOS system page browsing time collection method of this application. Based on the second embodiment described above, the third embodiment of the HarmonyOS system page browsing time collection method of this application is proposed.

[0097] In the third embodiment, step S30 includes:

[0098] Step S301: When the routing page update event of the routing page is triggered, obtain the status information corresponding to the routing page update event.

[0099] It's important to note that route page update events are system events triggered within the Router framework when the lifecycle or display state of a route page changes, such as a page switching from the background to the foreground, being popped from the top of the stack, or completing its initial load. These correspond to the `routerPageUpdate` event in the HarmonyOS system. The state information is the core data set carried when this event is triggered, including key parameters such as page identifier (e.g., page URL, unique ID), page visibility state (e.g., show, hide), event trigger timestamp, and page stack position. These parameters are used to determine the update type and current state of the route page.

[0100] Understandably, during application initialization or when a route page is created, an event callback function is registered through the Router event listener interface provided by the HarmonyOS system to establish a binding between the event and the processing logic. Secondly, when the routerPageUpdate event is triggered, the system automatically passes the state information as a parameter to the callback function. At this time, the state information is extracted through the formal parameters of the callback function, such as obtaining the page identifier from event.url, obtaining the page visibility state from event.state, and obtaining the event trigger timestamp from event.timestamp.

[0101] Step S302: Determine the update type of the routing page based on the status information. The update type includes page display events and page hide events.

[0102] It should be noted that update type is a classification of changes in the state of a routed page, used to distinguish different state transition scenarios in the page lifecycle. Specifically, it is divided into two categories: page display events and page hide events. Page display events refer to the update type where a routed page switches from an invisible state (such as running in the background or being covered by other pages) to a visible state (such as being displayed in the foreground or completing its first load), corresponding to the scenario where the user starts browsing the page. Page hide events refer to the update type where a routed page switches from a visible state to an invisible state (such as being moved to the background, being covered by a new page, or the page being destroyed), corresponding to the scenario where the user finishes browsing the page.

[0103] Specifically, key parameters for determining page visibility, such as the `state` field, are extracted from the state information. If the value of the `state` field is a preset display identifier, such as "show", "visible", or "onTop", and matches the enumeration value of the current system version, then the update type is determined to be a page display event; if the value of the `state` field is a preset hide identifier, such as "hide", "nvisible", or "offTop", then the update type is determined to be a page hide event.

[0104] Furthermore, in order to determine whether to update the current valid page and page entry time by judging whether the current route page has changed, and to avoid errors in duration calculation due to unrecognized page changes when the update type is a page display event, this ensures the dynamic and accurate updating of the current valid page when the route page is in the display state. After step S302, the method further includes:

[0105] If the update type is a page display event, then record the current route page and determine whether the current route page has changed; if yes, then update the current route page to the current valid page, and use the trigger time of the page display event as the page entry time of the current valid page; if no, then keep the current valid page of the route page unchanged.

[0106] It should be noted that the current route page refers to the route page that triggered the page display event, which can be identified by its unique identifier, such as the page URL or ID.

[0107] It should be understood that when the update type is a page display event, the unique identifier of the current route page is extracted through the event state information and recorded in the local cache. Next, the current route page identifier is compared with the previous route page identifier recorded in the cache to determine if the page has changed. If the comparison result is inconsistent, meaning the page has changed, the current route page is updated to the new currently valid page, and the trigger timestamp of the page display event is recorded as the page entry time of this currently valid page, overwriting the old page entry time. If the comparison result is consistent, meaning the page has not changed (e.g., the page is switched from the background to the foreground but not changed), the currently valid page remains unchanged, and the page entry time is not updated, ensuring that only the first entry time is recorded when the same page is displayed multiple times.

[0108] Step S303: If the update type is a page hiding event, then calculate the routing page duration based on the trigger time of the page hiding event and the first historical trigger time of the previous page hiding event.

[0109] It should be noted that the first historical trigger time refers to the system timestamp of the most recent time the page was hidden before this page-hiding event.

[0110] It should be understood that when the update type is a page hide event, the trigger timestamp is extracted from the status information of this page hide event; secondly, the first historical trigger time of the previous page hide event associated with the current route page is retrieved from the local cache, and this time is updated and stored after each page hide event is processed; then, the two are subtracted to calculate the browsing duration in the current period; finally, the calculation result is associated with the current route page identifier and stored, and the current trigger time is updated to the new first historical trigger time, overwriting the old value, providing a benchmark for the duration calculation of the next page hide event.

[0111] Understandably, two consecutive page hide events mark the beginning (the page reappears after the previous page hide event) and the end (the current page hide event), respectively, of a browsing cycle. By taking the time difference between the two page hide events, the actual time the user sees and interacts within that cycle can be accurately captured, avoiding the inclusion of invalid time when the page is hidden, such as when it is running in the background.

[0112] Step S304, or, calculate the duration of the routed page based on the trigger time of the page hiding event and the second historical trigger time of the previous page display event, wherein no routed page update event was triggered between the page hiding event and the previous page display event.

[0113] It should be noted that the second historical trigger time refers to the system timestamp of the most recent page display event triggered before this page hide event, i.e., the initial page. No route page update event was triggered between the page hide event and the previous page display event; that is, no other routerPageUpdate events occurred on the route page during the interval between the two events.

[0114] Specifically, after confirming that the update type is a page hide event through the status information, the system first checks whether there are other route page update event records in the local cache within the time interval between the current page hide event and the previous page display event. If it is confirmed that there are no other update events, the system retrieves the second historical trigger time of the previous page display event of the route page from the cache, and at the same time extracts the trigger time of the current hide event. The two are subtracted to obtain the route page duration.

[0115] It should be understood that when there are no other route update events between the page hide event and the previous page show event, it means that the route page has remained in a state without being covered or exited to the background during this time period. In this case, the trigger time of the previous page show event is the starting point when the user begins browsing, and the trigger time of this page hide event is the ending point when the user ends browsing. The difference between the two can accurately reflect the continuous and effective browsing time of the user on this route page, avoiding missing the browsing period after the first display.

[0116] In this embodiment, by distinguishing between page display events and page hide events, and providing a method for calculating the duration of routed pages for page hide events, the problem of repetition and omission in the duration calculation of routed pages in scenarios with multiple event triggers or complex updates is solved, ensuring the completeness and accuracy of the duration calculation of routed pages.

[0117] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the method for collecting page browsing time in the HarmonyOS system. Any simple modifications based on this technical concept are within the protection scope of this application.

[0118] This application also provides a device for collecting page browsing time in the HarmonyOS system. Please refer to... Figure 5 The HarmonyOS system page browsing time collection device includes:

[0119] The event trigger listening module 10 is used to obtain the event triggering status of the routing page and the navigation page in real time through dual listeners deployed in parallel. The routing page and the navigation page have different routing and navigation methods, and the routing page includes the navigation page.

[0120] The navigation duration determination module 20 is used to determine the currently valid page and determine the navigation page duration based on the currently valid page when the navigation target switching event of the navigation page is triggered.

[0121] The route duration determination module 30 is used to determine the update type of the route page and determine the route page duration based on the update type when the route page update event of the route page is triggered.

[0122] The browsing duration determination module 40 is used to determine the browsing duration of a page based on the duration of the navigation page and the duration of the routing page.

[0123] The HarmonyOS page browsing time collection device provided in this application adopts the HarmonyOS page browsing time collection method in the above embodiments, which can solve the technical problem that existing page browsing time collection methods have inaccurate statistics or missing statistical data when collecting page browsing time in HarmonyOS systems where two routing navigation methods coexist. Compared with the prior art, the beneficial effects of the HarmonyOS page browsing time collection device provided in this application are the same as the beneficial effects of the HarmonyOS page browsing time collection method provided in the above embodiments, and other technical features in the HarmonyOS page browsing time collection device are the same as the features disclosed in the methods of the above embodiments, and will not be repeated here.

[0124] This application provides a HarmonyOS system page browsing time collection device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the HarmonyOS system page browsing time collection method in the above embodiment 1.

[0125] The following is for reference. Figure 6 This document illustrates a structural diagram of a HarmonyOS page browsing time collection device suitable for implementing embodiments of this application. The HarmonyOS page browsing time collection device in these embodiments may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital radio receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), and in-vehicle terminals (e.g., in-vehicle navigation terminals), as well as fixed terminals such as digital TVs and desktop computers. Figure 6 The HarmonyOS page browsing time collection device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0126] like Figure 6As shown, the HarmonyOS page browsing time acquisition device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to the program stored in the read-only memory 1002 or the program loaded from the storage device 1003 into the random access memory 1004. The random access memory 1004 also stores various programs and data required for the operation of the HarmonyOS page browsing time acquisition device. The processing unit 1001, the read-only memory 1002, and the random access memory 1004 are interconnected via a bus 1005. An input / output interface 1006 is also connected to the bus. Typically, the following systems can be connected to the input / output interface 1006: input devices 1007 including, for example, a touchscreen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage devices 1003 including, for example, magnetic tape, hard disk, etc.; and communication devices 1009. Communication device 1009 allows the HarmonyOS page browsing time collection device to communicate wirelessly or wiredly with other devices to exchange data. Although the figure shows HarmonyOS page browsing time collection devices with various systems, it should be understood that implementing or having all of the systems shown is not required. More or fewer systems can be implemented alternatively.

[0127] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0128] The HarmonyOS page browsing time collection device provided in this application, employing the HarmonyOS page browsing time collection method described in the above embodiments, can solve the technical problem of inaccurate or missing statistical data when collecting page browsing time in HarmonyOS systems where two routing navigation methods coexist. Compared with the prior art, the beneficial effects of the HarmonyOS page browsing time collection device provided in this application are the same as those of the HarmonyOS page browsing time collection method provided in the above embodiments, and other technical features of this HarmonyOS page browsing time collection device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0129] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0130] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0131] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the HarmonyOS page browsing time collection method in the above embodiments.

[0132] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0133] The aforementioned computer-readable storage medium may be included in the HarmonyOS page browsing time collection device; or it may exist independently and not be installed in the HarmonyOS page browsing time collection device.

[0134] The aforementioned computer-readable storage medium carries one or more programs. When the aforementioned one or more programs are executed by the HarmonyOS page browsing time collection device, the HarmonyOS page browsing time collection device performs the HarmonyOS page browsing time collection method described above.

[0135] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0136] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0137] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0138] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described HarmonyOS page browsing time collection method. This solves the technical problem of inaccurate or missing statistical data when collecting page browsing time in existing page browsing time collection methods within the HarmonyOS system where two routing navigation methods coexist. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the HarmonyOS page browsing time collection method provided in the above embodiments, and will not be repeated here.

[0139] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the HarmonyOS system page browsing time collection method described above.

[0140] The computer program product provided in this application can solve the technical problem that existing page browsing time collection methods suffer from inaccurate statistics or missing statistical data when collecting page browsing time in the HarmonyOS system where two routing navigation methods coexist. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the page browsing time collection method for the HarmonyOS system provided in the above embodiments, and will not be repeated here.

[0141] The above description is only a part of the embodiments of this application and does not limit the scope of this application. All equivalent structural transformations made under the technical concept of this application and using the content of this application specification and drawings, or direct / indirect applications in other related technical fields, are included within the protection scope of this application.

Claims

1. A method for collecting page browsing time in the HarmonyOS system, characterized in that, The method for collecting page browsing time in the HarmonyOS system includes: The event triggering status of the routing page and navigation page is obtained in real time by dual listeners deployed in parallel. The routing page and navigation page have different routing and navigation methods, and the routing page includes the navigation page. When the navigation target switching event of the navigation page is triggered, the currently valid page is determined, and the duration of the navigation page is determined based on the currently valid page; When the route page update event of the route page is triggered, determine the update type of the route page, and determine the route page duration based on the update type; The page browsing duration is determined based on the duration of the navigation page and the duration of the routing page.

2. The method for collecting page browsing time in the HarmonyOS system as described in claim 1, characterized in that, The step of determining the currently valid page and determining the duration of the navigation page based on the currently valid page when the navigation target switching event of the navigation page is triggered includes: When the navigation target switching event of the navigation page is triggered, record the current navigation page; Based on the current navigation page, determine whether the navigation page returns to the navigation bar, and determine the currently valid page based on the determination result; Record the page entry time of the currently valid page; The navigation page duration is calculated based on the page entry time and the historical navigation entry time. The historical navigation entry time is the page entry time of the currently valid page corresponding to the last navigation target switching event.

3. The method for collecting page browsing time in the HarmonyOS system as described in claim 2, characterized in that, The step of determining whether the current navigation page returns to the navigation bar based on the current navigation page, and determining the currently valid page based on the determination result, includes: Obtain the page identifier of the current navigation page and compare the page identifier with the preset navigation bar page identifier; If the comparison matches, it is determined that the navigation page returns to the navigation bar, and the current route page corresponding to the navigation bar is set as the current valid page; If the comparison is inconsistent, it is determined that the navigation page has not returned to the navigation bar, and the current navigation page is set as the current valid page.

4. The method for collecting page browsing time in the HarmonyOS system as described in claim 1, characterized in that, The step of determining the update type of the route page and determining the duration of the route page based on the update type when the route page update event is triggered includes: When the route page update event of the route page is triggered, obtain the status information corresponding to the route page update event; The update type of the route page is determined based on the status information, and the update type includes page display events and page hide events; If the update type is a page hide event, the routing page duration is calculated based on the trigger time of the page hide event and the first historical trigger time of the previous page hide event. Alternatively, the duration of the routed page can be calculated based on the trigger time of the page hiding event and the second historical trigger time of the previous page display event, provided that no routed page update event was triggered between the page hiding event and the previous page display event.

5. The method for collecting page browsing time in the HarmonyOS system as described in claim 4, characterized in that, After determining the update type of the route page based on the status information, where the update type includes page display events and page hide events, the method further includes: If the update type is a page display event, then record the current route page and determine whether the current route page has changed; If so, the current route page is updated to the current valid page, and the trigger time of the page display event is used as the page entry time of the current valid page; If not, then the current valid page of the route page remains unchanged.

6. The method for collecting page browsing time in the HarmonyOS system as described in any one of claims 1 to 5, characterized in that, After the step of determining the page browsing duration based on the navigation page duration and the routing page duration, the method further includes: The page browsing time is validated to determine whether the page browsing time conforms to the preset time logic rules; If the browsing time of the page does not conform to the duration logic rule, the browsing time will be corrected based on the page's historical browsing time data and the current page's attribute information.

7. A device for collecting page browsing time in the HarmonyOS system, characterized in that, The device includes: The event trigger listening module is used to obtain the event triggering status of the routing page and the navigation page in real time through dual listeners deployed in parallel. The routing page and the navigation page have different routing and navigation methods, and the routing page includes the navigation page. The navigation duration determination module is used to determine the currently valid page and determine the navigation page duration based on the currently valid page when the navigation target switching event of the navigation page is triggered. The route duration determination module is used to determine the update type of the route page when the route page update event is triggered, and determine the route page duration based on the update type. The browsing duration determination module is used to determine the browsing duration of a page based on the duration of the navigation page and the duration of the routing page.

8. A device for collecting page browsing time in the HarmonyOS system, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the HarmonyOS page browsing time collection method as described in any one of claims 1 to 6.

9. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the HarmonyOS page browsing time collection method as described in any one of claims 1 to 6.

10. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the steps of the HarmonyOS page browsing time collection method as described in any one of claims 1 to 6.

Images