Mobile terminal data acquisition method and device, electronic equipment, and storage medium

Abstract

This invention discloses a mobile terminal data acquisition method, apparatus, electronic device, and storage medium, relating to the fields of mobile communication and data acquisition technology or other related fields. The method includes: upon detecting the startup of a target application on a mobile device, obtaining the latest acquisition strategy from a server and acquiring the mobile device's operating environment information; upon receiving a data acquisition instruction, determining whether to execute data acquisition based on the acquisition strategy and operating environment information; if the determination result indicates that data acquisition is permitted, acquiring the corresponding raw data according to the data acquisition instruction and performing standardization processing on the raw data; and storing the standardized data in the local cache of the mobile device. This invention solves the technical problem in related technologies where indiscriminate triggering of data acquisition events on mobile terminals leads to resource waste.

Description

Technical Field

[0001] This invention relates to the field of mobile communication and data acquisition technology, and more specifically, to a mobile terminal data acquisition method and apparatus, electronic device, and storage medium. Background Technology

[0002] With the rapid development of the mobile internet, mobile applications have become the core carrier of user services. To optimize product experience and support business decisions, developers generally integrate data collection functions into mobile applications to collect user behavior, device performance, and anomaly information. Current mainstream technologies adopt a "full-data collection, unified reporting" model. This involves embedding fixed collection code at various key event points in the application (such as page opening, button clicks, and interface swiping). Once an event is triggered, data records are generated and temporarily stored locally. After preset conditions are met (such as time intervals, number of data entries, or a Wi-Fi network environment), the data is packaged and uploaded to the server. In this model, all events are recorded indiscriminately, regardless of their business value, and all undergo the complete process of collection, storage, and reporting.

[0003] In the aforementioned technologies, the lack of intelligent judgment based on the device's real-time operating status and data value priority during data collection leads to the continuous generation and storage of large amounts of low-value, repetitive, or invalid data. This results in excessive consumption of mobile device CPU, memory, storage I / O, and power, severely impacting application smoothness and device battery life. Furthermore, in cellular network environments, high-frequency data reporting consumes significant user bandwidth, causing user dissatisfaction. Additionally, the influx of massive amounts of low-value data into backend servers significantly increases storage costs, cleaning burdens, and analysis latency, reducing data availability. While existing solutions can control reporting timing through network type, they cannot suppress the generation of invalid data at the source. They lack dynamic response capabilities to multi-dimensional environmental factors such as device load, power consumption, frame rate, and foreground / background status, and there is no mechanism for real-time decision-making and filtering of the collection process itself. This makes the data collection system cumbersome and lacks adaptability, making it difficult to balance user experience, resource efficiency, and data quality.

[0004] There is currently no effective solution to the above problems. Summary of the Invention

[0005] This invention provides a mobile data acquisition method, device, electronic device, and storage medium to at least solve the technical problem of resource waste caused by indiscriminately triggering data acquisition events on mobile terminals in related technologies.

[0006] According to one aspect of the present invention, a mobile terminal data collection method is provided, comprising: upon detecting the startup of a target application on a mobile device, obtaining the latest collection strategy from a server and obtaining the operating environment information of the mobile device; upon receiving a data collection instruction, determining whether to perform data collection based on the collection strategy and the operating environment information; if the determination result indicates that data collection is permitted, collecting corresponding raw data according to the data collection instruction and performing standardization processing on the raw data; and storing the data obtained after standardization processing in the local cache area of ​​the mobile device.

[0007] Further, the step of obtaining the latest collection strategy from the server includes: if there is no local collection strategy in the local cache of the mobile device, downloading the strategy text from the server; if there is a local collection strategy in the local cache of the mobile device, obtaining the current version number of the local collection strategy and the latest version number in the server; if the current version number and the latest version number are the same, using the local collection strategy; if the current version number and the latest version number are different, downloading the latest version of the strategy text from the server; parsing the strategy text to obtain a set of rules containing event types, collection switches, and restrictions, and storing the set of rules as the currently effective collection strategy in the local cache.

[0008] Furthermore, the step of obtaining the operating environment information of the mobile device includes: determining the current network type by periodically obtaining network status change notifications issued by the mobile operating system of the mobile device; and obtaining the remaining battery percentage of the device by querying the system interface of the mobile operating system.

[0009] Further, the step of determining whether to perform data collection based on the collection strategy and the operating environment information includes: confirming the event type corresponding to the data collection instruction according to the collection strategy, and determining whether collection is allowed based on the event type; determining whether the current network type of the mobile device is a cellular network based on the operating environment information; determining whether the current remaining battery power of the mobile device is lower than a preset threshold based on the operating environment information; and setting the determination result to allow data collection only when the event type allows collection, the current network type is a non-cellular network, and the current remaining battery power is not lower than the threshold.

[0010] Further, the step of collecting corresponding raw data according to the data collection instruction and standardizing the raw data includes: obtaining event attribute information triggered by the data collection instruction, wherein the event attribute information includes: event name, trigger time and page path; organizing the event attribute information according to a preset field structure to obtain a unified data format; standardizing the raw data based on the unified data format, and associating the standardized data with the corresponding device identifier and application version number.

[0011] Furthermore, if the judgment result indicates that data acquisition is not allowed, the method further includes: not acquiring the original data corresponding to the data acquisition instruction; recording an acquisition failure log and storing the acquisition failure log in the local cache.

[0012] Furthermore, when the target application is detected to be launched on the mobile device, the method further includes: running an abnormal monitoring process of the target application; if it fails to obtain the latest collection strategy from the server, calling an emergency backup strategy as the currently effective collection strategy through the abnormal monitoring process; if it fails to obtain the operating environment information of the mobile device, simulating and generating operating environment information based on the mobile device model and the number of currently running processes through the abnormal monitoring process; if the original data collection fails, recording a collection failure log through the abnormal monitoring process; and if the local cache storage fails, performing data rewriting a specified number of times through the abnormal monitoring process and recording a storage failure log.

[0013] According to another aspect of the present invention, a mobile data collection device is also provided, comprising: an acquisition unit, configured to acquire the latest collection strategy from a server and acquire the operating environment information of the mobile device when a target application on a mobile device is detected to be launched; a judgment unit, configured to determine whether to perform data collection based on the collection strategy and the operating environment information after receiving a data collection instruction; a collection unit, configured to collect corresponding raw data according to the data collection instruction and perform standardization processing on the raw data if the judgment result indicates that data collection is allowed; and a storage unit, configured to store the data obtained after standardization processing in the local cache area of ​​the mobile device.

[0014] Further, the acquisition unit includes: a first download module, configured to download the policy text from the server when no local acquisition policy exists in the local cache of the mobile device; a first acquisition module, configured to acquire the current version number of the local acquisition policy and the latest version number in the server when a local acquisition policy exists in the local cache of the mobile device; a reuse module, configured to reuse the local acquisition policy when the current version number and the latest version number are the same; a second download module, configured to download the latest version of the policy text from the server when the current version number and the latest version number are different; and a storage module, configured to parse the policy text to obtain a set of rules containing event types, acquisition switches, and restrictions, and store the set of rules as the currently effective acquisition policy in the local cache.

[0015] Furthermore, the acquisition unit also includes: a first determining module, used to determine the current network type by periodically acquiring network status change notifications issued by the mobile operating system of the mobile device; and a second acquisition module, used to acquire the remaining battery percentage of the device by querying the system interface of the mobile operating system.

[0016] Further, the judgment unit includes: a second determining module, used to confirm the event type corresponding to the data collection instruction according to the collection strategy, and to determine whether collection is allowed according to the event type; a first judging module, used to determine whether the current network type of the mobile device is a cellular network according to the operating environment information; a second judging module, used to determine whether the current remaining battery power of the mobile device is lower than a preset threshold according to the operating environment information; and a setting module, used to set the judgment result to allow data collection only when the event type allows collection, the current network type is a non-cellular network, and the current remaining battery power is not lower than the threshold.

[0017] Furthermore, the acquisition unit includes: a third acquisition module, used to acquire event attribute information triggered by the data acquisition command, wherein the event attribute information includes: event name, trigger time and page path; an organization module, used to organize the event attribute information according to a preset field structure to obtain a unified data format; and a processing module, used to standardize the original data based on the unified data format, and associate the standardized data with the corresponding device identifier and application version number.

[0018] Furthermore, the mobile data acquisition device also includes: a first recording module, used to not acquire the original data corresponding to the data acquisition instruction when the judgment result indicates that data acquisition is not allowed; record acquisition failure logs and store the acquisition failure logs in the local cache area.

[0019] Furthermore, the mobile data acquisition device further includes: a running module, used to run an abnormal monitoring process of the target application when the target application on the mobile device is detected to be launched; a calling module, used to call an emergency backup strategy as the currently effective acquisition strategy through the abnormal monitoring process when it fails to obtain the latest acquisition strategy from the server; a generation module, used to simulate and generate operating environment information based on the mobile device model and the number of currently running processes through the abnormal monitoring process when it fails to obtain the operating environment information of the mobile device; a second recording module, used to record acquisition failure logs through the abnormal monitoring process when the original data acquisition fails; and a rewriting module, used to rewrite the data a specified number of times through the abnormal monitoring process and record storage failure logs when the local cache storage fails.

[0020] According to another aspect of the present invention, a computer-readable storage medium is also provided, the computer-readable storage medium including a stored computer program, wherein, when the computer program is executed, it controls the device where the computer-readable storage medium is located to execute any of the above-described mobile terminal data acquisition methods.

[0021] According to another aspect of the present invention, an electronic device is also provided, including one or more processors and a memory, the memory being used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to implement any of the above-described mobile terminal data acquisition methods.

[0022] This invention proposes a mobile data collection method. First, when the target application on the mobile device is detected to be launched, the latest collection strategy and the operating environment information of the mobile device are obtained from the server. Then, after receiving the data collection instruction, it is determined whether to perform data collection based on the collection strategy and the operating environment information. If the determination result indicates that data collection is allowed, the corresponding raw data is collected according to the data collection instruction, and the raw data is standardized. Finally, the standardized data is stored in the local cache of the mobile device.

[0023] This invention employs a source filtering mechanism based on policy-driven and environment-aware collaborative decision-making. By dynamically retrieving remote data collection policies and acquiring device network type and battery status in real time upon application startup, and combining three conditions—event type permissibility, network non-cellular environment, and battery level exceeding a preset threshold—for each data collection command triggered, raw data collection and structured encapsulation are only executed when all conditions are met. The processed data is then written to a local cache. This approach effectively suppresses invalid data collection at the source of data generation, fundamentally shifting data collection on mobile terminals from a "full-scale triggering" to an "on-demand execution" paradigm. Furthermore, it solves the technical problem of resource waste caused by indiscriminately triggering data collection events on mobile terminals in related technologies. This solution avoids continuous collection and storage of high-frequency, low-value events under low power, cellular network, or background conditions, significantly reducing CPU usage, I / O pressure, and memory overhead. At the same time, it ensures the stable operation of the collection system itself through local caching and anomaly fallback mechanisms, matching data collection behavior with the actual carrying capacity of the device. This fundamentally eliminates the extensive mode of traditional solutions that "collect and write regardless of necessity," achieving precise alignment between resource consumption and data value. Attached Figure Description

[0024] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this application, illustrate exemplary embodiments of the invention and, together with their description, serve to explain the invention and do not constitute an undue limitation thereof. In the drawings:

[0025] Figure 1 This is a diagram illustrating the composition of an optional mobile data acquisition system based on a dynamic strategy, according to an embodiment of the present invention.

[0026] Figure 2 This is a flowchart of an optional mobile terminal data collection method according to an embodiment of the present invention;

[0027] Figure 3 This is a schematic diagram illustrating the implementation principle of an optional mobile data acquisition method based on dynamic strategies according to an embodiment of the present invention.

[0028] Figure 4 This is an optional data acquisition flowchart according to an embodiment of the present invention;

[0029] Figure 5 This is a schematic diagram of an optional intelligent acquisition module acquisition strategy according to an embodiment of the present invention;

[0030] Figure 6 This is a schematic diagram of an optional mobile data acquisition device according to an embodiment of the present invention;

[0031] Figure 7This is a structural block diagram of an electronic device for performing a mobile data acquisition method according to an embodiment of the present invention. Detailed Implementation

[0032] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0033] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0034] The following embodiments of the present invention can be applied to various systems / applications / devices that require user behavior data collection and device resource-sensitive data reporting. They enable dynamic control of data collection behavior based on remote policies and real-time device status during mobile application operation, avoiding invalid writing and transmission during low battery, cellular network, or background processes. The present invention uses a collaborative mechanism between a policy management module and an environment awareness module to pre-judge collection commands, and then executes raw data collection and structured encapsulation only when the policy and environment permit. This better reduces the CPU load, memory usage, storage I / O pressure, and cellular network traffic consumption of mobile devices, while ensuring the complete capture and reliable local storage of critical event data.

[0035] The present invention will now be described in detail with reference to various embodiments.

[0036] Example 1

[0037] According to an embodiment of the present invention, a mobile terminal data collection method embodiment is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0038] Examples of embodiments of the present invention Figure 1 The illustrated mobile data acquisition method and system based on dynamic strategies Figure 1 This is a diagram illustrating the composition of an optional mobile data acquisition system based on dynamic policies according to an embodiment of the present invention. It mainly includes five modules: a policy management module, an environment awareness module, an intelligent acquisition module, an anomaly monitoring module, and a data storage module. Specifically, the policy management module is responsible for retrieving, parsing, and caching dynamic acquisition policies from the server, and providing policy queries; the environment awareness module is responsible for collecting and providing various environmental status parameters of the mobile device in real time; the intelligent acquisition module is the core module of the system, mainly relying on the policy management module and the environment awareness module to achieve dynamic data acquisition; the data storage module is responsible for storing the data collected by the intelligent acquisition module and connecting to the subsequent reporting process; the anomaly monitoring module is mainly responsible for ensuring the stable operation of the other four modules on the device, primarily monitoring for abnormal situations in each module and triggering emergency management.

[0039] Examples of embodiments of the present invention Figure 2 The mobile data collection method shown is implemented by a mobile application data collection system. It combines policy-driven and environment-aware collaborative control technologies to collect user behavior and performance data in mobile internet applications. This method addresses the resource waste and experience degradation caused by full data collection when the battery is low, on a cellular network, or running in the background. By implementing policy matching and environmental condition dual verification at the data collection entry point, specifically, it retrieves and caches the collection policy issued by the server when the application starts, obtains the network type and battery status in real time, and determines whether the event type is allowed, whether the current network is non-cellular, and whether the battery level is higher than the threshold when each collection command is triggered. Only when all three conditions are met is the raw data collected and standardized and stored in the local cache. This aims to suppress the generation of invalid data from the source, reduce device load and network consumption, and ensure the stable operation of the collection system.

[0040] Figure 2 This is a flowchart of an optional mobile data collection method according to an embodiment of the present invention, such as... Figure 2 As shown, the method includes the following steps:

[0041] Step S101: When the target application on the mobile device is detected to be launched, the latest collection strategy is obtained from the server, and the operating environment information of the mobile device is obtained.

[0042] Specifically, upon application launch or when the local caching policy is missing or expired, the system proactively sends a request to the remote policy server to obtain a set of collection rules defined in structured text (such as JSON) format. This set of rules includes event types (such as "page view" and "button click"), collection switches (enabled / disabled), and restrictions (such as "collect only under Wi-Fi" and "sampling rate 50%)." Essentially, it decouples the collection logic from client-side hard-coding to a remotely configurable policy model.

[0043] Next, the system activates the environment awareness module during the startup phase, continuously monitoring the device status through native operating system interfaces (such as obtaining network type through ConnectivityManager and obtaining battery percentage through BatteryManager) to form a lightweight "device snapshot", including key indicators such as current network type, remaining battery power, application foreground / background status, memory usage level, and frame rate.

[0044] The above steps ensure that each subsequent data collection command can make accurate judgments based on the latest policies and real-time environment by preloading policies and establishing an environment baseline when the application starts, rather than relying on static configurations or outdated states. This provides a consistent and reliable basis for intelligent data collection.

[0045] In the above embodiments, upon detecting the launch of a target application on a mobile device, the system first triggers a policy acquisition process, requesting the latest collection policy from the server via a network connection to ensure that the collection rules followed locally are synchronized with those on the server. Simultaneously, the system synchronously reads the mobile device's current operating environment information, including but not limited to network status, memory usage, battery level, and application foreground / background status, providing real-time environmental data for subsequent collection actions. This process is completed at the initial stage of application launch, ensuring that the collection policy and device environment information are in place before data collection occurs.

[0046] Furthermore, the step of obtaining the latest collection strategy from the server includes: if the local collection strategy does not exist in the local cache of the mobile device, downloading the strategy text from the server; if the local collection strategy exists in the local cache of the mobile device, obtaining the current version number of the local collection strategy and the latest version number from the server; if the current version number and the latest version number are the same, using the local collection strategy; if the current version number and the latest version number are different, downloading the latest version of the strategy text from the server; parsing the strategy text to obtain a set of rules containing event types, collection switches, and restrictions, and storing the set of rules as the currently effective collection strategy in the local cache.

[0047] The above steps describe in detail the core synchronization mechanism of the policy management module, which is the foundation for realizing dynamic policy-driven data collection. In one optional embodiment, if no policy is available locally, the policy text is downloaded. This is applicable when a user installs the application for the first time, or when the local cache is deleted due to cleanup, upgrade, or anomaly. The policy management module detects that the local policy file (e.g., strategy_v2.json) does not exist and immediately initiates a lightweight request (carrying basic context such as application version, device type, and language) to the policy server via HTTPS. The server returns a structured policy text (e.g., in JSON format).

[0048] In another optional embodiment, if a policy exists locally, a version comparison is performed. This is applicable to scenarios such as application restart, background wake-up, or policy update push. The implementation system reads the local policy file, extracts the version field (e.g., 3.0), and requests the latest version number from the server (via a HEAD request or a lightweight interface to avoid downloading the full text).

[0049] Furthermore, if the versions are the same, the local version is used without initiating data downloads, saving bandwidth and battery power. If the versions are different, the latest policy is downloaded; that is, the complete policy text is only downloaded when the server version is higher (incremental updates are not used because the policy is small and changes infrequently). The signature is immediately verified (e.g., SHA-256) after downloading to prevent man-in-the-middle tampering (although not explicitly stated in the disclosure, this is a standard feature in industrial implementations and is considered general knowledge).

[0050] Furthermore, once the new strategy is successfully downloaded, it is immediately parsed. A JSON parser can be used to convert the text into an in-memory object (such as an instance of the StrategyRuleSet class). Each rule is compiled into an executable function or state machine (such as isEligible(event, deviceState)). The rule contains three core elements: ① Event type: such as page_view, app_crash, payment_success; ② Collection switch: enabled: true / false, which supports dynamically disabling certain types of data points; ③ Restrictions: network_restriction: "wifi_only", sampling_rate: 0.2, aggregation: "5_consecutive" (aggregating repetitive behaviors), etc.

[0051] Finally, after the policy is updated, the old version is immediately overwritten and stored in the local cache. Atomic writes can be used, i.e., first writing to a temporary file (strategy_v3.1.tmp), and then renaming and replacing the original file after the write is complete, to prevent policy corruption due to write interruption; the file can be stored in the application's private directory (e.g., / data / data / ). <package>( / files / strategy.json) provides access control to prevent other applications from reading it; it also records the timestamp of the policy taking effect for auditing and anomaly backtracking.

[0052] An alternative approach involves, upon detecting the launch of a target application on a mobile device, prioritizing a check of the local cache for a stored collection strategy. If not found, the strategy text is downloaded directly from the server for initialization. If found, the local version number is compared with the latest server version number, triggering a strategy update download only when versions are inconsistent. This significantly reduces unnecessary network transmission and resource consumption. The downloaded strategy text, after structured parsing, is broken down into a set of explicit rules containing event types, collection switches, and constraints. This ensures that subsequent data collection decisions no longer rely on vague raw text but are based on quantifiable and verifiable structured rules and real-time runtime environment information for collaborative decision-making, guaranteeing accurate and controllable collection behavior. This strategy set is cached locally for reuse in subsequent collection commands, achieving efficient maintenance and dynamic synchronization of the strategy state. This effectively solves problems such as update redundancy, low cache reuse rate, and ambiguous collection judgment caused by the lack of version control in strategy acquisition and unstructured content. Ultimately, this achieves the technical effects of reducing mobile resource consumption and improving the response efficiency and accuracy of collection strategies.

[0053] It should be noted that, as Figure 1 In the mobile data collection method and system based on dynamic policies shown, the policy management module is the configuration management center of the system. Its core responsibility is to keep the policy synchronized with the remote server, parse the obtained text policy configuration into a rule model that the system can understand, and perform efficient caching and fast retrieval locally to provide a basis for decision-making. The version number comparison mechanism avoids unnecessary network transmission and ensures the timeliness and flexibility of the policy.

[0054] Furthermore, the steps for obtaining the operating environment information of the mobile device include: determining the current network type by periodically obtaining network status change notifications issued by the mobile operating system of the mobile device; and obtaining the remaining battery percentage of the device by querying the system interface of the mobile operating system.

[0055] The above steps focus on two core status acquisition methods for the environmental perception module: network type and remaining battery power. Essentially, it combines native operating system event-driven mechanisms with interface queries to achieve lightweight, real-time, and low-overhead environmental perception.

[0056] First, the current network type is determined by periodically receiving network status change notifications from the mobile operating system. For example, when a user moves from a Wi-Fi environment to a subway tunnel, the network switches from 4G to no network; or from public Wi-Fi to cellular network. In practice, the environment awareness module registers a system broadcast listener to monitor network type change events. When a network switch occurs, the system actively pushes the event (e.g., TYPE_WIFI → TYPE_CELLULAR), and the module immediately updates the device snapshot in memory. To prevent event loss (e.g., broadcasts not being delivered due to system resource constraints), the module simultaneously starts a timed polling mechanism (e.g., actively checking the current network status every 30 seconds), forming a dual-channel guarantee of "event-driven + timed backup".

[0057] Furthermore, by querying the mobile operating system's system interface, the remaining battery percentage of the device is obtained. For example, if a user uses the app continuously for 2 hours and the battery drops from 85% to 12%, the system is about to enter low power mode. In practice, the current percentage is obtained by calling the battery interface provided by the operating system. To avoid increased power consumption due to frequent calls, the query is only triggered at critical times (such as when the application starts, the network switches, or before data collection decisions), or a "change threshold trigger" strategy is adopted (such as updating only when the battery changes by ≥5%). The obtained data is formatted as a standardized field (such as "electricity":"Low") rather than the raw number, which facilitates policy logic judgment (such as "battery <15% → disable non-critical data collection").

[0058] The above two items are only partial inputs. The environment awareness module can also simultaneously collect and integrate the following parameters to form a complete snapshot of the device status: application foreground / background status (is_foreground: true / false); memory availability (memory_available: High / Medium / Low, determined by available system memory or memory pressure level); UI frame rate (fps: 60 / 30 / <20, monitored by Choreographer or system performance monitoring); CPU load (optional, obtained via / proc / stat or system API). All fields are updated uniformly and atomically written to a memory object for the intelligent collection module to read at once, avoiding performance loss caused by multiple API calls.

[0059] An alternative approach involves periodically receiving network status change notifications pushed by the mobile device's operating system to accurately determine the current network type in real time. It also queries the system interface provided by the operating system to obtain the device's remaining battery percentage, ensuring high real-time performance and accuracy of the acquired operating environment information. By combining the collection strategy with a comprehensive judgment of network type and battery percentage, it can effectively identify high-cost operating states such as low battery levels under cellular networks when data collection commands are triggered. This avoids unnecessary data collection under resource-sensitive conditions such as non-Wi-Fi or low battery levels, thereby curbing invalid collection behavior caused by ambiguous environmental information at the source. This significantly reduces unnecessary data consumption and battery drain, improving the intelligence and resource friendliness of mobile data collection.

[0060] It should be noted that, as Figure 1 In the mobile data acquisition method and system based on dynamic strategies shown, the environment perception module is the system's intelligence perception system. By listening to various status broadcasts issued by the mobile operating system and calling the application programming interfaces provided by the system, it continuously collects the real-time operating environment parameters of the mobile device and maintains a lightweight, up-to-date snapshot of the device status in memory to provide real-time context for decision-making.

[0061] Step S102: After receiving the data acquisition instruction, determine whether to perform data acquisition based on the acquisition strategy and operating environment information.

[0062] Specifically, after a data collection instruction (such as "user clicks button" or "page timeout") is captured by the intelligent collection module, it first queries the cached policy rule model in the policy management module to determine whether the event is allowed to be collected (e.g., the switch status is "on"), whether sampling is required (e.g., only collect 30% of similar events), and whether aggregation is required (e.g., merge 5 consecutive clicks into 1 record). This is the access control at the business logic layer.

[0063] If permitted by policy, the system further utilizes the latest device snapshots provided by the environment awareness module (e.g., network type "4G", battery level below 15%, foreground application frame rate <30fps, memory usage exceeding 85%) to assess environmental health based on preset thresholds. For example, if the network is a cellular network and the event is "high-frequency page browsing", data collection is refused; if the battery level is below the threshold or the device is under high load, even if permitted by policy, the system will proactively downgrade to "skip data collection".

[0064] The above steps break through the traditional one-dimensional control mode of "the strategy only controls on / off, and the environment does not participate in the decision-making". For the first time, the joint logical operation of business intent (strategy) and physical constraints (environment) is completed at the moment the collection command is triggered, realizing "collecting when it should be collected and prohibiting when it should not be collected", and truly achieving source filtering of data collection.

[0065] In the above embodiments, upon receiving a data acquisition command, the system makes a comprehensive judgment based on a preset acquisition strategy and current operating environment information to determine whether to execute the data acquisition behavior. The acquisition strategy, serving as the basis for control rules, specifies the conditions under which acquisition is allowed or prohibited, while the operating environment information reflects the real-time status of the device at the time the command is triggered. Together, they constitute the sole input condition for the acquisition decision. This process does not directly execute acquisition; instead, it pre-screens acquisition behavior through the matching relationship between the strategy and the environment, ensuring that only acquisition requests that meet the strategy requirements and are permitted by the environment are allowed to be executed. This achieves proactive control of the acquisition behavior after the command is received but before data generation.

[0066] Furthermore, the step of determining whether to perform data collection based on the collection strategy and operating environment information includes: confirming the event type corresponding to the data collection instruction according to the collection strategy, and determining whether collection is allowed based on the event type; determining whether the current network type of the mobile device is a cellular network based on the operating environment information; determining whether the current remaining battery power of the mobile device is lower than a preset threshold based on the operating environment information; and setting the judgment result to allow data collection only when the event type allows collection, the current network type is a non-cellular network, and the current remaining battery power is not lower than the threshold.

[0067] The above steps construct a joint decision-making logic with three constraints, which is the core judgment engine for achieving intelligent on-demand data collection in this embodiment of the invention. First, the event type is confirmed according to the collection strategy, and it is determined whether collection is allowed. For example, when a user clicks the "Favorite Item" button, the event `event_id:favorite_click` is triggered. In specific implementation, the intelligent collection module parses the event, queries the rule set in the strategy management module, and matches the corresponding event type. The strategy defines this event as: `enabled:true, sampling_rate:0.5`, meaning collection is allowed, but only 50% is sampled. At this point, the judgment result is "strategy allows," but a final decision on whether to collect has not yet been made; environment verification is required.

[0068] Next, based on the operating environment information, it is determined whether the current network type is a cellular network. For example, if the device's current network is 4G / 5G (cellular network) and the user is using the app on the subway, in specific implementation, the environment awareness module provides the latest device snapshot: network_type: "cellular"; the policy restricts this event as: network_restriction: "wifi_only"; since the device is on a cellular network, and the policy requires data collection only under Wi-Fi, this condition is not met, and it is determined as "collection prohibited".

[0069] Finally, based on the operating environment information, it is determined whether the current remaining power is lower than a preset threshold. For example, if the device power is 8%, the system enters low power mode. In specific implementation, the environment snapshot shows: electricity: "Low", and the threshold is set to 15%. Regardless of whether the policy allows it or whether the network is Wi-Fi, as long as the power is lower than the threshold, data collection is refused to prioritize ensuring device battery life. This is a "hard protection mechanism" with higher priority than all business policies.

[0070] Data collection is only allowed when all three conditions are met simultaneously. The logical relationship is: Allowed collection = (Policy allowed) ∧ (Network ≠ Cellular) ∧ (Battery power ≥ Threshold). The execution path includes: If any condition is not met (e.g., policy is enabled but network is cellular, or battery power is insufficient), data collection is skipped directly, without writing to the cache, triggering reporting, or consuming any resources. Data collection and standardized storage are only performed when all three conditions are met simultaneously (e.g., event is "payment successful", network is Wi-Fi, battery power is 70%).

[0071] The above steps achieve atomic joint decision-making between the business intent of policy control and the physical reality of environmental constraints, and all three are ANDed, meaning none can be omitted. This is something that traditional solutions cannot achieve: Traditional solutions only determine "whether it is on Wi-Fi," ignoring battery power and event priority; the embodiments of this invention, however, progressively determine whether the event is critical; whether the network is expensive; and whether the device is malfunctioning; all three must be satisfied simultaneously before data collection is allowed.

[0072] It should be noted that after receiving a data collection command, the system determines whether data collection is allowed based on the event type defined in the collection strategy. Simultaneously, it acquires real-time information about the mobile device's operating environment, assessing whether the current network type is cellular and whether the remaining battery power exceeds a preset threshold. Data collection is only allowed when all three conditions are met: the event type explicitly allows collection, the network environment is non-cellular, and the device has sufficient battery power. This effectively avoids blindly triggering data collection in unfavorable environments such as high mobile network costs and limited battery resources, significantly reducing unnecessary network traffic consumption and device power consumption. It solves the problems of resource waste and invalid data overload caused by indiscriminate collection strategies, achieving improved energy efficiency and user experience for mobile devices while ensuring the effectiveness of data collection.

[0073] Step S103: If the judgment result indicates that data acquisition is allowed, collect the corresponding raw data according to the data acquisition instruction, and perform standardization processing on the raw data.

[0074] Specifically, the intelligent data collection module only responds to the collection command after both the policy and environment verifications pass, extracting raw event data from the application runtime context (such as page path, control ID, operation timestamp, and user session ID). This process does not involve full log recording, but rather precise extraction according to the field set defined by the policy, such as only collecting "event_id:click", "page:Home", "element:BookButton", "timestamp:…", avoiding the collection of irrelevant stack traces, memory snapshots, or device unique identifiers and other redundant information.

[0075] The collected raw data is immediately converted into a unified data model (such as JSON Schema), containing fixed fields: event type, timestamp, device identifier (anonymized), application version, data collection source module, policy version number, and other metadata, forming structured data records that can be directly parsed by the backend system without cleaning. This process does not perform compression or aggregation, but only format standardization to ensure that the data is traceable, verifiable, and compatible with analysis platforms.

[0076] The above steps minimize the data collection process and establish a contractual data structure. Unlike traditional solutions that involve "collecting all data at once and then cleaning it upon reporting," this invention completes the first quality control of data the instant it is collected. This eliminates the need for subsequent storage, transmission, and analysis processes to incur the cost of "dirty data cleaning," significantly reducing the overall system overhead.

[0077] In the above embodiments, when the judgment result indicates that data acquisition is permitted, the system directly initiates the corresponding data acquisition process based on the received data acquisition instruction to obtain the raw data records. Subsequently, the acquired raw data undergoes standardization processing, converting it into a unified format to ensure that the data structure conforms to the system's preset specifications for subsequent storage and transmission. This process does not involve filtering, aggregating, or reducing noise in the data content; it only completes the acquisition and formatting of the raw data under the premise that acquisition is permitted.

[0078] Furthermore, the steps of collecting corresponding raw data according to the data collection command and standardizing the raw data include: obtaining event attribute information triggered by the data collection command, wherein the event attribute information includes: event name, trigger time and page path; organizing the event attribute information according to a preset field structure to obtain a unified data format; standardizing the raw data based on the unified data format, and associating the standardized data with the corresponding device identifier and application version number.

[0079] The above steps are the core processing steps of this invention to achieve "collection as standardization, data as asset". Essentially, they transform unstructured user operation events into standardized data records that are traceable, analyzable, and reusable. First, the event attribute information triggered by the data collection command is obtained. For example, a user clicks the "Book Now" button on the application homepage to enter the flight selection page. In specific implementation, the intelligent collection module captures this operation event and extracts the following context attributes: event_name: "click" (event name, not a vague description such as "button clicked"); timestamp: "2025-09-27T10:00:01Z" (UTC timestamp, accurate to milliseconds to ensure time sequence consistency); page_path: " / home / flight_search" (structured page path, not ambiguous expressions such as "homepage", using a hierarchical naming convention); Optional data collection includes: operation element ID (e.g., element_id: "book_btn_001"), session ID (session_id), and operation sequence number (sequence_no), used to reconstruct the user's behavior path.

[0080] Next, the event attribute information is organized according to a preset field structure to obtain a unified data format. For example, the raw data generated by different modules (clicks, page views, exception reporting) needs to be modeled uniformly. In specific implementation, all collected events are forcibly mapped to a unified schema, such as a JSON structure.

[0081] json

[0082] {

[0083] "event_name":"click",

[0084] "timestamp":"2025-09-27T10:00:01Z",

[0085] "page_path":" / home / flight_search",

[0086] "element_id":"book_btn_001",

[0087] "session_id":"sess_abc123",

[0088] "strategy_version":"3.1",

[0089] "device_id_hash":"a1b2c3...",

[0090] "app_version":"2.8.1"

[0091] }

[0092] Field names, types, and formats (e.g., time uses ISO 8601) are globally unique and cannot be changed, ensuring that data reported by different devices and versions can be processed uniformly; this structure is synchronously issued by the policy management module during policy parsing, serving as a "data contract" for the acquisition module to enforce.

[0093] Furthermore, the raw data is standardized based on a unified data format and associated with device identifiers and application version numbers. For example, this data will be stored long-term and aggregated for cross-device analysis. In specific implementation, the device identifier is not collected using privacy-sensitive information such as IMEI or IDFA, but rather an anonymized unique ID (device_id_hash) is generated based on device hardware characteristics (such as chip ID and ROM hash), which complies with privacy compliance requirements. As for the application version number, it is automatically injected with the current App version (e.g., 2.8.1) for subsequent analysis of behavioral differences between versions (e.g., "v2.8.0 shows a sudden drop in click-through rate"). In addition, the strategy version number (strategy_version) is automatically injected to ensure that the data is traceable to "which set of collection rules was used at the time," supporting retrospective auditing.

[0094] The above steps realize the contractualization and metadataization of the data collection behavior: it is not "what is collected is what is collected", but "which fields must be collected, how to name them, and how to associate them"; it is not "raw log stacking", but "structured, indexable, and analyzable data assets", so that the backend does not need to clean, map, or adapt, and the data is "ready to use", which greatly reduces the analysis cost.

[0095] In this embodiment of the invention, when a target application on a mobile device triggers a data collection command, the system first obtains the event attribute information corresponding to the command, including the event name, trigger time, and page path. Then, these key event elements are standardized and organized according to a preset field structure to form a data format with a unified structure. Based on this unified format, the collected raw data is then standardized to ensure consistency in semantic expression and field organization across all collected data. Simultaneously, during the standardization process, the device identifier and application version number are automatically bound to the processed data as contextual metadata. This provides a complete and traceable basis for the device's operating environment for subsequent data analysis, effectively solving the problems of semantic ambiguity, incomparability, and untraceability caused by the lack of a unified structure and device attribution identifier in the raw data. Ultimately, this achieves high availability and high reliability of the collected data in backend analysis.

[0096] It should be noted that, as Figure 1 In the mobile data acquisition method and system based on dynamic strategies shown, the intelligent acquisition module is the intelligent decision-making center of the system, providing a single data acquisition entry point. When a acquisition request is triggered, it is not processed immediately, but first consults the strategy management module and the environment awareness module. Based on the acquired rules and real-time status, a series of logical judgments and calculations are performed to ultimately decide whether to acquire the data and how to process it, thereby achieving intelligent noise reduction and aggregation of the data source.

[0097] Furthermore, if the judgment result indicates that data acquisition is not allowed, the method also includes: not acquiring the raw data corresponding to the data acquisition instruction; recording the acquisition failure log and storing the acquisition failure log in the local cache.

[0098] The above steps constitute a closed-loop handling mechanism for scenarios where data collection decisions fail. Essentially, refusing data collection does not equate to ignoring the event; rather, the "rejection behavior" itself is recorded as an auditable and optimizable system signal. First, the original data corresponding to the data collection command is not collected. For example, a user clicks "View Promotion Page" on a 4G network, but the policy stipulates that this event can only be collected under Wi-Fi, and the current battery level is 12%. In practice, the intelligent data collection module, after dual judgment based on policy and environment, concludes "collection prohibited"; immediately suspends any generation, serialization, or memory storage operations of original data; it does not generate intermediate objects, trigger I / O writes, or consume CPU and power, achieving true zero-overhead rejection.

[0099] Next, record the data collection failure log and store it in the local cache. In specific implementation scenarios, the system needs to analyze "why the collection rate of a certain type of event is low," whether it is due to overly strict policies or abnormal user behavior. Specifically, a failure log record can be generated, with the following structure:

[0100] json

[0101] {

[0102] "log_type":"Data collection rejected",

[0103] "event_name":"view_promo_page",

[0104] "timestamp":"2025-09-27T10:00:05Z",

[0105] "reason":"network_type=cellular&&electricity<15%",

[0106] "strategy_version":"3.1",

[0107] "device_id_hash":"a1b2c3...",

[0108] "app_version":"2.8.1"

[0109] }

[0110] The meanings of some fields in the above data structure are as follows:

[0111] Reason: Describe the reason for rejection (such as network + battery combination), not simply "filtered";

[0112] strategy_version: Used to determine whether a large number of rejections are caused by policy mismatch;

[0113] device_id_hash: Used to identify whether a device is rejected in a specific model / system version.

[0114] This log is stored in the same local cache (such as the SQLite table collect_logs) as the successfully collected data, using the same transaction mechanism to ensure that it is not lost due to application crashes; this log is not included in reporting and analysis, but is only used for system self-reflection and strategy optimization to avoid polluting business data.

[0115] Traditional solutions remain completely silent about "filtered events," making it impossible to know how many were rejected, why they were rejected, or whether there were false rejections. In contrast, this invention treats rejection itself as high-value diagnostic data, providing feedback upon failure to collect data and using rejection behavior as a signal, thus forming a closed-loop optimization capability.

[0116] In this embodiment, when the target application on the mobile device is detected to be launched, the system first obtains the latest data collection strategy from the server and collects the current operating environment information of the device. After receiving the data collection instruction, the system comprehensively judges whether to allow the collection behavior based on the strategy and environment information. If the judgment result is that collection is not allowed, the system actively terminates the collection operation of the original data to avoid unnecessary resource consumption. At the same time, the system actively records the collection failure log, which includes the reason for failure, timestamp, strategy version and environment parameters, and persists the log to the local cache of the mobile device. Together with the successfully collected data, the log forms a complete collection behavior record system, thereby realizing the traceability, retrospective and analyzability of the entire collection decision process. This effectively solves the technical defects of not being able to optimize the strategy and locate system anomalies due to the lack of behavior records caused by the rejection of collection. Ultimately, the system achieves the effect of improving the intelligence, maintainability and data decision support capabilities of the collection system.

[0117] Step S104: Store the data obtained after standardization processing in the local cache of the mobile device.

[0118] Specifically, data records standardized by S103 (such as structured JSON) are not uploaded immediately. Instead, the intelligent acquisition module calls the data storage module's interface to persist them to a local lightweight database (such as SQLite or an embedded key-value store) in a transactional write manner. This cache is organized by timestamp, event type, policy version, and other dimensions, supporting efficient appending, batch reading, and breakpoint resumption, avoiding data loss due to application crashes, system restarts, or network interruptions.

[0119] The cache in the cache area is not a simple stack of files, but has a lifecycle management mechanism: each record is marked with a unique ID, collection time, policy version, and whether it has been reported (flag). It supports sorting by priority (e.g., crash logs take precedence over page clicks) and limits the maximum capacity (e.g., 10MB) to prevent unlimited growth from affecting device storage.

[0120] The above steps completely decouple the data collection and reporting actions. Data collection is a lightweight operation that is real-time, highly responsive, and low-latency, while reporting is an asynchronous, conditional, and batch-based background process. The local cache, as the sole trusted data source, solves the typical mobile problem of "data collected but not transmitted" or "data transmitted but the system crashed." It is not simply a "temporary folder," but an embedded data warehouse with transactional, auditable, recoverable, and priority-schedulable capabilities, achieving a highly available data collection system.

[0121] In one optional embodiment, storing the standardized data in the local cache of the mobile device means that the data records with unified format and standardized structure are securely written into the local storage space of the mobile terminal, forming a persistent data set. This provides a reliable data source for subsequent batch reporting or asynchronous transmission, ensuring that the data will not be lost due to process termination, network interruption or system abnormality before it is successfully sent to the server, while maintaining the orderly organization and traceability of the data on the device.

[0122] It should be noted that, as Figure 1 In the mobile data collection method and system based on dynamic strategies shown, the data storage module is the system's data buffer and warehouse. It is responsible for receiving and securely persisting all valid data records produced by the intelligent collection module, organizing and managing them efficiently, and connecting with the subsequent reporting process to ensure that data is not lost due to application crashes or poor network conditions.

[0123] Furthermore, when the target application is detected to be launched on the mobile device, the method further includes: running an abnormal monitoring process for the target application; if it fails to obtain the latest collection strategy from the server, calling the emergency backup strategy as the currently effective collection strategy through the abnormal monitoring process; if it fails to obtain the mobile device's operating environment information, simulating and generating operating environment information based on the mobile device model and the number of currently running processes through the abnormal monitoring process; if the original data collection fails, recording the collection failure log through the abnormal monitoring process; and if the local cache storage fails, rewriting the data a specified number of times through the abnormal monitoring process and recording the storage failure log.

[0124] The above steps construct a system resilience assurance system with anomaly monitoring process at its core. In essence, when any submodule fails, the system does not crash, interrupt, or lose data. Instead, it maintains the core functions in a "minimum availability" state through preset degradation logic.

[0125] First, upon detecting the launch of the target application, an abnormal monitoring process for the target application is run. For example, when a user clicks the app icon, the application enters the foreground from a cold start. In specific implementation, after the application's main process initializes, a lightweight background monitoring thread or daemon process (not the main thread, and does not block the UI) is started independently as soon as possible. This process does not participate in data collection itself, but is only responsible for listening to abnormal events (such as crashes, timeouts, and returns of illegal states) of other modules (policy, environment, collection, and caching). A global exception capture mechanism is adopted.

[0126] Next, if retrieving the latest collection policy from the server fails, the emergency backup policy is invoked as the currently effective collection policy via the abnormal monitoring process. This is for example, if the device is in a weak network environment (such as an underground parking lot) and the policy server times out. In practice, if the policy management module request fails (network error, 500, parsing exception), the abnormal monitoring process immediately intervenes and triggers the "emergency backup policy"—this policy is a hard-coded default rule built into the application binary, for example:

[0127] json

[0128] {

[0129] "default_rules":[

[0130] {"event":"app_crash","enabled":true,"override_environment":true},

[0131] {"event":"payment_success","enabled":true,"override_environment":true},

[0132] {"event":"page_view","enabled":false},

[0133] {"event":"button_click","enabled":false,"sampling_rate":0.01} ]

[0135] }

[0136] Only the highest priority events (crash, payment) are collected, and all others are either disabled or sampled at very low levels to ensure that "it is better to miss some data than to consume too much power"; at the same time, logs are recorded: "Policy pull failed, default policy is enabled" for subsequent analysis.

[0137] Furthermore, in the event that obtaining the mobile device's operating environment information fails, the abnormal monitoring process simulates and generates operating environment information based on the mobile device model and the number of currently running processes. For example, if the user has disabled battery or network permissions, the system API may return a null value or an exception. In specific implementation, the environment awareness module may be unable to obtain the true state due to missing permissions, system compatibility, or system resource limitations. The abnormal monitoring process then activates an intelligent estimation engine: if the device model is a "low-end device" (e.g., RAM≤2GB), it is judged as "high load, low battery" by default; if the number of background processes is >15, it is judged as "memory shortage"; if the network type cannot be obtained, it is treated as "cellular network" by default (security priority principle); if the frame rate cannot be obtained, it is inferred from the CPU usage: if CPU>70%, then fps: Low; the generated "simulated snapshot" is not used for precise analysis, but only to trigger a conservative collection strategy (e.g., disabling non-critical events).

[0138] Furthermore, in the event of raw data acquisition failure, an exception monitoring process logs the acquisition failure. For example, the acquisition module may fail to generate valid data due to thread blocking, memory overflow, or missing event fields. During implementation, exceptions during the acquisition process (such as NullPointerException, data format validation failure) are captured; structured logs are recorded, including: log_type: acquisition exception; event_name: click; error_code: FORMAT_INVALID; stack_trace_hash: xxx (used to locate code problems); timestamp, app_version, and device_id_hash. This log is stored separately from the policy rejection log to distinguish between business rejection and system failure.

[0139] Finally, in the event of local cache storage failure, the exception monitoring process performs a specified number of data rewrites and logs the storage failures. Examples of failures include insufficient device storage space, file lock conflicts, and database corruption. Specifically, the data storage module returns a write failure message (e.g., SQLite SQLITE_FULL, IOError); the exception monitoring process initiates a retry mechanism: a maximum of three attempts, each with a 500ms interval, to prevent high-frequency writes from exacerbating the problem; an atomic write + renaming mechanism is used to prevent file corruption due to write interruptions; if all three attempts fail, a storage failure log is recorded, and the data is marked as "pending recovery"; the cache module attempts to reload and retry the write when the application starts again. Simultaneously, if five consecutive storage failures occur, "cache degradation" is triggered: only the most recent 100 critical events (such as crashes) are retained, and the rest are discarded to prevent the device storage from being overwhelmed.

[0140] In this invention's system, upon detecting the launch of a target application on a mobile device, an anomaly monitoring process is simultaneously initiated. This process automatically invokes a local emergency backup strategy to maintain continuous data acquisition when the acquisition strategy fails to retrieve data from the server. When acquiring environment information fails, it dynamically simulates and generates reliable environment parameters based on the device model and the current number of processes, ensuring that subsequent data acquisition decisions are grounded in reality. Upon receiving a data acquisition command, the system determines the validity of the acquisition based on the strategy and environment information. If the acquisition of raw data fails during the acquisition process, the anomaly monitoring process immediately records a failure log for traceability. When writing standardized data to the local cache fails, the anomaly monitoring process triggers a retry mechanism, performing a specified number of rewrite operations and simultaneously recording storage failure logs. This ensures the executability of the acquisition strategy, the availability of environment information, the traceability of data acquisition, and the fault-tolerant recovery capability of storage behavior even in complex environments such as no network, low resources, or storage anomalies. It effectively avoids the interruption of the entire data acquisition chain due to a single point of failure, achieving dual protection of system function continuity and data integrity under harsh operating conditions.

[0141] It should be noted that, as Figure 1 In the mobile data acquisition method and system based on dynamic strategies shown, the anomaly monitoring module acts as the system's stability guardian. Through embedded monitoring points, health check mechanisms, and global anomaly capture, it continuously monitors the operational health of all other modules. Once abnormal behavior is predicted or detected, a pre-set contingency plan is immediately activated to ensure that the main functions of the system remain available in most abnormal situations, preventing application crashes and impacting the main program.

[0142] Figure 3 This is a schematic diagram illustrating the implementation principle of an optional mobile data acquisition method based on a dynamic strategy according to an embodiment of the present invention, such as... Figure 3 As shown, the specific implementation method is as follows:

[0143] T1, Application initialization, starts the exception monitoring module, data storage module, and policy management module.

[0144] T2: The policy management module reads the locally cached policy information. If no policy is cached locally, it directly requests the latest policy from the server. When the local policy information already exists, the policy management module compares the local policy version number with the latest version number on the server. If the version is lower than the server version, it retrieves and updates the latest policy.

[0145] T3. After the strategy is successfully obtained, the strategy management module parses the strategy, converts it into an internally executable rule model, and sets up the strategy query interface.

[0146] T4: When an anomaly occurs in the policy module during the acquisition or parsing process, the anomaly monitoring module intervenes, provides emergency backup policies, records anomaly logs, and subsequently reports them to the server.

[0147] T5 initializes the environment awareness module, enabling monitoring of parameters such as device network connection status, device memory usage, and application foreground / background status.

[0148] T6 integrates the monitored information into a unified device status snapshot. This snapshot comprehensively reflects the device's real-time resource status and operating context, and is used to determine whether the data collection behavior has a significant impact on the device experience.

[0149] When the environmental perception module malfunctions, the T7's anomaly monitoring module activates an intelligent degradation strategy. It can simulate and estimate the device status based on information such as the phone model and the number of currently running processes to support data collection and decision-making, and record anomaly logs for subsequent reporting to the server.

[0150] T8: When a user interacts with the application, the intelligent data acquisition module receives a data acquisition instruction.

[0151] T9, the intelligent acquisition module reads the policy information stored locally, performs policy matching, and determines whether the current event meets the conditions for data acquisition.

[0152] T10: The intelligent data acquisition module activates the environmental perception module to obtain a snapshot of the current mobile phone, and then uses the strategy to determine whether there are any negative impacts on data acquisition.

[0153] T11. If the strategy and environment allow, then data collection will proceed.

[0154] T12: When the data acquisition module triggers an abnormal alarm, the abnormal monitoring module records the data acquisition log and subsequently reports it to the server.

[0155] The T13 processes the collected raw data through formatting, serialization, and other methods before storing it in the cache module, and provides a data reading interface for data transmission.

[0156] T14 manages the data lifecycle. Once the data has been successfully reported through the reporting process, the cache module will delete the data.

[0157] T15: When the caching module malfunctions, the exception monitoring module attempts to protect data integrity and records the exception log, which is then reported to the server.

[0158] T16: When an unhandled exception occurs in the program as a whole, the exception monitoring module uses a global exception capture mechanism to ensure that the core functions of the host program are not affected.

[0159] Through the above steps S101 to S104, when the target application on the mobile device is detected to be launched, the latest collection strategy and the operating environment information of the mobile device can be obtained from the server. After receiving the data collection instruction, it is determined whether to perform data collection based on the collection strategy and the operating environment information. If the determination result indicates that data collection is allowed, the corresponding raw data is collected according to the data collection instruction, and the raw data is standardized. Finally, the data obtained after standardization is stored in the local cache of the mobile device.

[0160] By applying the technical solution of this embodiment, when the target application on the mobile device is detected to be launched, the latest data collection strategy is actively obtained from the server and the current operating environment information of the device is obtained simultaneously. Subsequently, upon receiving a data collection instruction, a preliminary decision is made based on the obtained collection strategy and operating environment information. The data collection process is triggered only when the strategy allows and the environmental conditions are met, thereby avoiding resource waste and invalid data flooding caused by indiscriminate collection without evaluation. After confirming that collection is allowed, only the raw data specified by the instruction is collected and immediately standardized to ensure that the data format is uniform and highly usable. Finally, the processed valid data is cached locally and uploaded uniformly when network conditions are suitable, significantly reducing real-time transmission pressure and power consumption. Therefore, it can effectively solve the problems of excessive mobile terminal resource occupation, invalid data accumulation, and system performance degradation caused by the lack of strategy and environment evaluation mechanisms in the prior art, achieving a comprehensive technical effect of precise control of collection behavior, improved device operating efficiency, optimized data quality, and reduced system load.

[0161] In this embodiment of the invention, a source filtering mechanism based on policy-driven and environment-aware collaborative decision-making is adopted. By dynamically pulling the remote collection policy and obtaining the device's network type and power status in real time when the application starts, and combining the event type permission, whether the network is a non-cellular environment, and whether the power is higher than a preset threshold for joint judgment when each collection command is triggered, the raw data collection and structured encapsulation are only executed when all conditions are met, and the processed data is written to the local cache. This achieves the goal of suppressing invalid collection behavior at the source of data generation, thereby realizing the technical effect of fundamentally changing the data collection paradigm on mobile terminals from "full triggering" to "on-demand execution", and thus solving the technical problem of resource waste caused by indiscriminate triggering of data collection events on mobile terminals in related technologies. This solution avoids continuous collection and storage of high-frequency, low-value events under low power, cellular network, or background conditions, significantly reducing CPU usage, I / O pressure, and memory overhead. At the same time, it ensures the stable operation of the collection system itself through local caching and anomaly fallback mechanisms, matching data collection behavior with the actual carrying capacity of the device. This fundamentally eliminates the extensive mode of traditional solutions that "collect and write regardless of necessity," achieving precise alignment between resource consumption and data value.

[0162] The present invention will now be described in conjunction with another specific embodiment.

[0163] The embodiments of the present invention provide a specific implementation environment based on the above-described mobile terminal data collection method. Figure 4 This is an optional data acquisition flowchart according to an embodiment of the present invention, such as... Figure 4 As shown, a user has installed an airline's app on their mobile phone. The user uses the app to book a flight, CA1439, departing from City C and arriving in City B. The specific process is as follows:

[0164] S1, the user clicks on an airline's app icon. Upon app startup, the policy management module, data storage module, anomaly monitoring module, and environment awareness module are initialized. The anomaly monitoring module takes effect immediately, beginning to monitor for anomalies throughout the app.

[0165] In step S2, the policy management module is activated and checks the app's local storage to find the previously cached data collection policy. Assuming this is the user's first time using the app or the cache has been cleared, there is no policy file locally. The module then sends a request to Air China's data policy server to obtain the latest policy. Upon the second launch, a cached file already exists locally; the version number is compared to retrieve the latest policy file.

[0166] S3. After successfully acquiring the policy, the policy management module parses the policy text sent by the server and converts it into rule objects that the system can understand. Once parsing is complete, the module provides a query interface to receive inquiries from other modules.

[0167] S4 is the exception monitoring module and the protection strategy module. If a network request fails or the parsed format is incorrect, the exception monitoring module will intervene, use a built-in, most conservative default strategy, and log a "strategy fetch failed" message.

[0168] S5 initializes the environment awareness module. This module registers a listener with the system to continuously monitor the device's network connection status (identifying whether it is currently using Wi-Fi or 5G / 4G cellular network), device memory status (checking if there is sufficient remaining memory), frame rate, battery level, and whether the current app is in the foreground or background.

[0169] In S6, the environment awareness module integrates the monitored data (such as: {network_type:"5G", memory_available:"High", fps:60, electricity:80%, is_foreground:true}) into a lightweight, real-time updated device status snapshot. This snapshot reflects the phone's current resource load, providing a basis for subsequent judgments on whether data collection actions will affect device performance.

[0170] S7 is an anomaly monitoring module and a protection environment awareness module. If this module fails, the anomaly monitoring module will intelligently calculate a "conservative mode" state based on the device model and the currently running app. For example, for low-end phones, due to their poor performance, a large amount of data collection will affect the operation of the app itself, so the collection frequency will be reduced. Or, if the network type cannot be obtained due to permission issues, it will be determined by default to "cellular network" to avoid large-scale data collection under poor network conditions.

[0171] It should be noted that, Figure 5 This is a schematic diagram of an optional intelligent acquisition module acquisition strategy according to an embodiment of the present invention, such as... Figure 5 As shown, the strategy of the intelligent acquisition module for events with high priority and normal environmental perception is as follows (S8~S11):

[0172] S8, when a user enters the App's homepage and clicks the "Flight Booking" entry, this click action triggers a data collection command, and the intelligent data collection module receives an event named "Flight Booking".

[0173] After receiving the instruction, the intelligent data collection module does not record it immediately. First, it consults the strategy management module: "What is the strategy for handling the 'flight booking' event?" The strategy module returns the rule: This event has a high priority and needs to be collected.

[0174] S10, next, the intelligent data acquisition module "consults" the environment awareness module: "What is the current device status? Is it suitable for data acquisition?" The environment module returns the current device snapshot: network is 5G, memory is sufficient, app is in the foreground, 60fps, battery: 80%. Conclusion: Data acquisition has no impact on device performance and user experience. The intelligent data acquisition module's strategy for events with normal priority and abnormal environment awareness is as follows:

[0175] S11. After both the above-mentioned strategy and environment judgments are approved, the intelligent data collection module will execute the data collection operation and generate a formatted data record, such as: {event_id:"click",page:"Home",element: "BookButton",timestamp:"2025-09-27 10:00:01"}.

[0176] Another option, such as Figure 5 As shown, the strategy of the intelligent acquisition module for events with normal priority but abnormal environmental perception is as follows (S8'~S11'):

[0177] S8', the user enters the App's homepage and clicks the "Hotel Booking" entry. This click action triggers a data collection command, and the intelligent data collection module receives an event named "Hotel Booking".

[0178] After receiving the instruction, the intelligent data collection module (S9') does not record immediately. It first consults the strategy management module: "What is the strategy for handling the 'hotel booking' event?" The strategy module returns the rule: This event has a normal priority and needs to be collected.

[0179] S10', Next, the intelligent data acquisition module "consults" the environment awareness module: "What is the current device status? Is it suitable for data acquisition?" The environment module returns the current device snapshot: Network is 5G, insufficient memory, App is in the foreground, 20fps, battery: 5%. Conclusion: Data acquisition has an impact on device performance and user experience.

[0180] S11' After both the above strategies and the environment were judged and rejected, the intelligent acquisition module abandoned data acquisition.

[0181] S12, enter the data caching module. When data is being collected, if the application malfunctions due to reasons within the app itself and data collection is incomplete, the exception monitoring module will record the exception log and report it to the server on the next startup.

[0182] S13: All approved data collection is processed into a standard format by the intelligent collection module, and then the data caching module's interface is called to securely store these data records in a local database table for temporary storage. A read interface is provided. An independent reporting program (or module) will periodically or in a Wi-Fi environment retrieve unreported data in batches from this interface.

[0183] S14: Once the reporting program confirms that a batch of data has been successfully sent to Air China's data server, it notifies the data caching module. The caching module then performs a deletion operation, removing this batch of successfully sent data from the local database to manage storage space and prevent data from piling up in an unordered manner.

[0184] S15. During the entire process, if the data caching module encounters an exception during storage or retrieval (such as too much database content causing multiple IO streams to write, resulting in write failure), the exception monitoring module will capture this error, attempt to store the data again to prevent data loss, and record a "database exception" log.

[0185] S16: From the moment a user enters the app until the booking is completed, the anomaly monitoring module runs continuously in the background. If any unexpected crash occurs at any stage (such as environment awareness, where different system versions require permission verification, but some programs fail to request permissions, causing monitoring to crash), this module will capture this global anomaly to prevent the app from suddenly crashing due to data collection, ensuring that the user can continue to complete the booking process, and at the same time record the crash log for subsequent analysis.

[0186] The mobile data acquisition method and system based on dynamic strategies in the embodiments of the present invention have the following advantages:

[0187] Reduce resource consumption and improve application performance: Through dynamic strategies, real-time intelligent filtering and noise reduction are performed at the source of data generation to eliminate invalid data collection. This fundamentally reduces the load on mobile devices, power consumption, memory usage, and storage I / O operations, ensuring the smooth operation of the main application and the device's battery life.

[0188] Optimize network traffic and save user costs: The strategy can be implemented differently according to network type. Under cellular network, it can automatically suspend the collection and reporting of non-critical, high-volume data, saving users data traffic and avoiding user resentment caused by data consumption.

[0189] Data value density and reduced backend pressure: By performing preprocessing such as sampling and aggregation at the terminal, only valid and high-quality data is reported, which reduces the pressure on the backend server in terms of data storage, cleaning and analysis, reduces the overall cost and improves data analysis efficiency.

[0190] Adaptability and flexibility: The system can dynamically adjust its data acquisition behavior based on the real-time status of the device (load, network) and remotely issued strategies, enabling fine-grained control.

[0191] The system boasts strong stability: the built-in anomaly monitoring module provides resilience across the entire chain. Any single point of failure (such as network anomalies or module failures) will trigger a degradation scheme to ensure that the data acquisition system itself will not cause the host application to crash and that the stability of core business functions will not be affected.

[0192] The invention will now be described in conjunction with another alternative embodiment.

[0193] Example 2

[0194] The mobile data acquisition device provided in this embodiment includes multiple implementation units, each of which corresponds to a specific implementation step in Embodiment 1 above.

[0195] Figure 6 This is a schematic diagram of an optional mobile data acquisition device according to an embodiment of the present invention, such as... Figure 6 As shown, the device may include: an acquisition unit 61, a judgment unit 62, a collection unit 63, and a storage unit 64.

[0196] The acquisition unit 61 is used to acquire the latest collection strategy from the server and acquire the operating environment information of the mobile device when the target application on the mobile device is detected to be launched.

[0197] The judgment unit 62 is used to determine whether to perform data acquisition based on the acquisition strategy and operating environment information after receiving the data acquisition instruction.

[0198] The acquisition unit 63 is used to acquire the corresponding raw data according to the data acquisition instruction when the judgment result indicates that data acquisition is allowed, and to perform standardization processing on the raw data.

[0199] Storage unit 64 is used to store the data obtained after standardization processing in the local cache of the mobile device.

[0200] The aforementioned mobile data collection device can first obtain the latest collection strategy and the mobile device's operating environment information from the server when the target application on the mobile device is detected to be launched by the acquisition unit 61. Then, after receiving the data collection instruction, the judgment unit 62 determines whether to perform data collection based on the collection strategy and the operating environment information. If the judgment result indicates that data collection is allowed, the collection unit 63 collects the corresponding raw data according to the data collection instruction and performs standardization processing on the raw data. Finally, the storage unit 64 stores the standardized data in the local cache area of ​​the mobile device.

[0201] In this embodiment of the invention, a source filtering mechanism based on policy-driven and environment-aware collaborative decision-making is adopted. By dynamically pulling the remote collection policy and obtaining the device network type and power status in real time when the application starts, and combining the event type permission, whether the network is a non-cellular environment, and whether the power is higher than a preset threshold for joint judgment when each collection command is triggered, the raw data collection and structured encapsulation are only executed when all conditions are met, and the processed data is written to the local cache. This achieves the goal of suppressing invalid collection behavior at the source of data generation, thereby realizing the technical effect of fundamentally changing the data collection paradigm on mobile terminals from "full triggering" to "on-demand execution", and thus solving the technical problem of resource waste caused by indiscriminate triggering of data collection events on mobile terminals in related technologies. This solution avoids continuous collection and storage of high-frequency, low-value events under low power, cellular network, or background conditions, significantly reducing CPU usage, I / O pressure, and memory overhead. At the same time, it ensures the stable operation of the collection system itself through local caching and anomaly fallback mechanisms, matching data collection behavior with the actual carrying capacity of the device. This fundamentally eliminates the extensive mode of traditional solutions that "collect and write regardless of necessity," achieving precise alignment between resource consumption and data value.

[0202] Furthermore, the acquisition unit includes: a first download module, used to download the policy text from the server when the local acquisition policy does not exist in the local cache of the mobile device; a first acquisition module, used to acquire the current version number of the local acquisition policy and the latest version number on the server when the local acquisition policy exists in the local cache of the mobile device; a reuse module, used to reuse the local acquisition policy when the current version number and the latest version number are the same; a second download module, used to download the latest version of the policy text from the server when the current version number and the latest version number are different; and a storage module, used to parse the policy text to obtain a set of rules containing event types, acquisition switches, and restrictions, and store the set of rules as the currently effective acquisition policy in the local cache.

[0203] Furthermore, the acquisition unit also includes: a first determination module, used to determine the current network type by periodically acquiring network status change notifications issued by the mobile operating system of the mobile device; and a second acquisition module, used to acquire the remaining battery percentage of the device by querying the system interface of the mobile operating system.

[0204] Furthermore, the judgment unit includes: a second determining module, used to confirm the event type corresponding to the data collection instruction according to the collection strategy, and determine whether collection is allowed according to the event type; a first judging module, used to determine whether the current network type of the mobile device is a cellular network according to the operating environment information; a second judging module, used to determine whether the current remaining battery power of the mobile device is lower than a preset threshold according to the operating environment information; and a setting module, used to set the judgment result to allow data collection only when the event type allows collection, the current network type is a non-cellular network, and the current remaining battery power is not lower than the threshold.

[0205] Furthermore, the acquisition unit includes: a third acquisition module, used to acquire event attribute information triggered by the data acquisition command, wherein the event attribute information includes: event name, trigger time and page path; an organization module, used to organize the event attribute information according to a preset field structure to obtain a unified data format; and a processing module, used to standardize the raw data based on the unified data format and associate the standardized data with the corresponding device identifier and application version number.

[0206] Furthermore, the mobile data acquisition device also includes: a first recording module, used to not collect the original data corresponding to the data acquisition instruction when the judgment result indicates that data acquisition is not allowed; record the acquisition failure log and store the acquisition failure log in the local cache.

[0207] Furthermore, the mobile data acquisition device also includes: a running module, used to run the abnormal monitoring process of the target application when the target application is detected to be launched on the mobile device; a calling module, used to call the emergency backup strategy as the currently effective acquisition strategy through the abnormal monitoring process when it fails to obtain the latest acquisition strategy from the server; a generation module, used to simulate and generate operating environment information based on the mobile device model and the number of currently running processes through the abnormal monitoring process when it fails to obtain the operating environment information of the mobile device; a second recording module, used to record acquisition failure logs through the abnormal monitoring process when the original data acquisition fails; and a rewriting module, used to rewrite the data a specified number of times through the abnormal monitoring process and record the storage failure logs when the local cache storage fails.

[0208] The aforementioned mobile data acquisition device may also include a processor and a memory. The aforementioned acquisition unit 61, judgment unit 62, acquisition unit 63, storage unit 64, etc., are all stored in the memory as program units, and the processor executes the aforementioned program units stored in the memory to realize the corresponding functions.

[0209] The aforementioned processor contains a kernel, which retrieves the corresponding program units from memory. One or more kernels can be configured. By adjusting kernel parameters, when a target application is detected to be launched on the mobile device, the processor obtains the latest data collection strategy from the server and acquires the mobile device's operating environment information. Upon receiving a data collection command, it determines whether to execute data collection based on the collection strategy and operating environment information. If the determination indicates that data collection is permitted, it collects the corresponding raw data according to the data collection command and performs standardization processing on the raw data. The standardized data is then stored in the mobile device's local cache.

[0210] The aforementioned memory may include non-permanent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM, and the memory includes at least one memory chip.

[0211] This application also provides a computer program product, which, when executed on a data processing device, is suitable for executing an initialization program with the following method steps: upon detecting the startup of a target application on a mobile device, obtaining the latest collection strategy from a server and obtaining the operating environment information of the mobile device; upon receiving a data collection instruction, determining whether to perform data collection based on the collection strategy and the operating environment information; if the determination result indicates that data collection is allowed, collecting the corresponding raw data according to the data collection instruction and performing standardization processing on the raw data; and storing the data obtained after standardization processing in the local cache area of ​​the mobile device.

[0212] According to another aspect of the present invention, a computer-readable storage medium is also provided, the computer-readable storage medium including a stored computer program, wherein, when the computer program is running, it controls the device where the computer-readable storage medium is located to execute any of the mobile terminal data acquisition methods in the first embodiment described above.

[0213] According to another aspect of the present invention, an electronic device is also provided, including one or more processors and a memory, wherein the memory is used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to implement the mobile terminal data acquisition method of any one of the above embodiments.

[0214] Figure 7 This is a structural block diagram of an electronic device for performing a mobile data acquisition method according to an embodiment of the present invention, such as... Figure 7 As shown, the electronic device may include: one or more ( Figure 7 (Only one is shown) processor 702, memory 704, memory controller, and peripheral interface, wherein the peripheral interface is connected to the radio frequency module, audio module and display.

[0215] The memory can be used to store software programs and modules, such as the program instructions / modules corresponding to the mobile data acquisition method and device in this application embodiment. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory, thereby realizing the aforementioned mobile data acquisition method. The memory may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory may further include memory remotely located relative to the processor, and these remote memories can be connected to the terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0216] Those skilled in the art will understand that Figure 7 The structure shown is for illustrative purposes only. Electronic devices can also be smartphones, tablets, handheld computers, mobile internet devices (MIDs), PADs, and other terminal devices. Figure 7 This does not limit the structure of the aforementioned electronic device. For example, electronic devices may also include components that are more... Figure 7 The more or fewer components shown (such as network interfaces, display devices, etc.), or having the same Figure 7 The different configurations shown.

[0217] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing the hardware related to the terminal device. The program can be stored in a computer-readable storage medium, which may include: flash drive, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0218] The sequence numbers of the above embodiments of the present invention are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0219] In the above embodiments of the present invention, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0220] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0221] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0222] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0223] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0224] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.< / package>

Claims

1. A mobile terminal data collection method, characterized in that, include: When the target application is detected to be launched on the mobile device, the latest collection strategy is obtained from the server, and the operating environment information of the mobile device is obtained. Upon receiving a data acquisition instruction, the system determines whether to perform data acquisition based on the acquisition strategy and the operating environment information. If the judgment result indicates that data acquisition is permitted, the corresponding raw data is acquired according to the data acquisition instruction, and the raw data is standardized. The data obtained after the standardization process is stored in the local cache of the mobile device.

2. The mobile terminal data collection method according to claim 1, characterized in that, The steps to obtain the latest data collection strategy from the server include: If the local collection policy is not present in the local cache of the mobile device, the policy text from the server is downloaded. If a local collection strategy exists in the local cache of the mobile device, obtain the current version number of the local collection strategy and the latest version number in the server; If the current version number is the same as the latest version number, the local collection strategy shall be continued; If the current version number is inconsistent with the latest version number, download the latest version of the policy text from the server; The policy text is parsed to obtain a set of rules containing event types, collection switches, and restrictions. The set of rules is then stored in the local cache as the currently effective collection policy.

3. The mobile terminal data collection method according to claim 1, characterized in that, The steps for obtaining the operating environment information of the mobile device include: The current network type is determined by periodically receiving network status change notifications from the mobile operating system of the mobile device. The remaining battery percentage of the device can be obtained by querying the system interface of the mobile operating system.

4. The mobile terminal data collection method according to claim 1, characterized in that, The step of determining whether to perform data collection based on the collection strategy and the operating environment information includes: The event type corresponding to the data acquisition instruction is confirmed according to the acquisition strategy, and whether acquisition is allowed is determined according to the event type. Based on the operating environment information, determine whether the current network type of the mobile device is a cellular network; Based on the operating environment information, determine whether the current remaining battery power of the mobile device is lower than a preset threshold; The judgment result will be set to allow data collection only if the event type allows collection, the current network type is a non-cellular network, and the current remaining battery power is not lower than the threshold.

5. The mobile terminal data collection method according to claim 1, characterized in that, The steps of collecting corresponding raw data according to the data acquisition instruction and standardizing the raw data include: Obtain the event attribute information triggered by the data collection command, wherein the event attribute information includes: event name, trigger time and page path; The event attribute information is organized according to a preset field structure to obtain a unified data format; The original data is standardized based on the unified data format, and the data obtained after standardization is associated with the device identifier and application version number.

6. The mobile terminal data collection method according to claim 1, characterized in that, If the judgment result indicates that data collection is not allowed, the method further includes: The raw data corresponding to the data acquisition command will not be collected; Record the collection failure log and store the collection failure log in the local cache.

7. The mobile terminal data collection method according to claim 1, characterized in that, When the target application is detected to be launched on the mobile device, the method further includes: Run the anomaly monitoring process of the target application; If it fails to obtain the latest collection strategy from the server, the emergency backup strategy is invoked through the abnormal monitoring process as the currently effective collection strategy. If the acquisition of the operating environment information of the mobile device fails, the abnormal monitoring process simulates and generates the operating environment information based on the mobile device model and the number of currently running processes. In the event that the original data acquisition fails, the acquisition failure log is recorded through the abnormal monitoring process; In the event of a storage failure in the local cache, the data is rewritten a specified number of times through the exception monitoring process, and a storage failure log is recorded.

8. A mobile data acquisition device, characterized in that, include: The acquisition unit is used to acquire the latest collection strategy from the server and acquire the operating environment information of the mobile device when the target application on the mobile device is detected to be launched. The judgment unit is used to determine whether to perform data acquisition based on the acquisition strategy and the operating environment information after receiving the data acquisition instruction. The acquisition unit is used to acquire corresponding raw data according to the data acquisition instruction when the judgment result indicates that data acquisition is allowed, and to perform standardization processing on the raw data. A storage unit is used to store the data obtained after the standardization process in the local cache of the mobile device.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored computer program, wherein, when the computer program is executed, it controls the device on which the computer-readable storage medium is located to perform the mobile data acquisition method according to any one of claims 1 to 7.

10. An electronic device, characterized in that, It includes one or more processors and a memory, the memory being used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to implement the mobile data acquisition method according to any one of claims 1 to 7.

Images