An end-side pageless decision system based on context identification
By using a context-aware, pageless decision-making system on the client side, the resource waste and latency issues of front-end JS logic without UI rendering in cross-platform development are solved, achieving efficient and seamless service execution and resource management, and ensuring data isolation and result delivery.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- JIANGSU MANYUN LOGISTICS INFORMATION CO LTD
- Filing Date
- 2026-05-29
- Publication Date
- 2026-07-03
AI Technical Summary
Existing technologies cannot efficiently adapt to the needs of executing front-end JS logic without UI rendering in cross-platform development. They suffer from problems such as high resource consumption, response latency, data obfuscation, lack of service addressing and isolation mechanisms with context identification, unstructured result return channels, and resource leakage.
A context-aware, pageless decision-making system is adopted on the client side, including a service registration module, a native proxy module, a cross-channel data sharing module, and a result callback and resource reclamation module. Service addressing, data isolation, and automatic resource reclamation are achieved through a global singleton registry, decorator proxy pattern, serviceName_contextId key combination, and Dispatcher.onHeadlessResult mechanism.
Significantly reduces resource consumption, shortens response time, enables zero-overhead data transmission, provides precise addressing for concurrent services, automates result delivery and resource recycling, and avoids resource leaks.
Smart Images
Figure CN122332151A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of next-generation information technology industry technology, and more specifically, to a pageless decision-making system on the terminal side based on context identifiers. Background Technology
[0002] In the field of new-generation information technology industry technology, with the development of cross-platform development technology, the cross-platform dynamic architecture of "JS executing business logic + Flutter handling rendering" has become the mainstream. It combines the dynamism of JS with the high-performance rendering advantages of Flutter, effectively reducing the cost of multi-platform development and is widely used in the development of various mobile applications.
[0003] Under this architecture, regular business pages need to go through the complete process of "creating native Activity → initializing FlutterEngine → loading JSBundle → executing JS logic → Flutter rendering UI", which can meet the needs of business scenarios with UI interaction requirements.
[0004] However, in practical applications, there are many scenarios that do not require UI rendering and only require the rapid execution of pre-defined JS logic on the client side, such as pop-up validation and page launch decisions. The core requirement for these scenarios is to efficiently execute the logic and return the result, without needing the complete page flow.
[0005] For the aforementioned scenario of executing pre-processing logic without UI rendering requirements, existing technologies mainly employ two solutions, but both suffer from insurmountable flaws and cannot adapt to the actual business needs of a JS-driven Flutter cross-platform architecture. The existing traditional page container solution requires fully launching the page container to execute the JS logic before closing it, resulting in excessive resource consumption and response latency due to redundant processes, making it unsuitable for such lightweight requirements. The other solution, a headless browser, while not requiring UI rendering, relies on an independent browser kernel, is isolated from the JS runtime in the architecture, cannot share context, and requires additional serialization operations for data transmission, increasing complexity and latency. Furthermore, both solutions share common drawbacks: a lack of service addressing and isolation mechanisms based on context identifiers, leading to data confusion; and the absence of a structured result return channel, coupled with the lack of standardized lifecycle management and resource reclamation mechanisms for page service instances, easily causing resource leaks and other problems.
[0006] In summary, the existing solutions cannot efficiently adapt to the execution requirements of UI-less front-end JS logic under this cross-platform architecture, and have many shortcomings. There is an urgent need for a targeted pageless JS service decision-making solution. Summary of the Invention
[0007] To address the aforementioned issues, the present invention aims to provide a context-based, pageless decision-making system for the next-generation information technology industry, which addresses at least one technical problem in cross-platform development.
[0008] To achieve the above technical objectives, this application provides a context-identifier-based, pageless decision-making system for the next-generation information technology industry, comprising: The service registration module is used to register each service to the global Map by serviceName; The native proxy module is used to wrap ThreshOwner with DecoratorOwner and selectively intercept UI-related operations. The cross-channel data sharing module is used to achieve data sharing and isolation between HeadlessService and subsequent pages through the serviceName_contextId combination key; The result callback and resource recycling module is used to send the result back to the callback interface after the JS service has finished executing. The callback message is intercepted by DecoratorOwner and the result is returned to the caller. Then, the service resources are released and the monitoring is reported on the UI thread.
[0009] Preferably, the service registration module is used to register each business Headless Service class to the global Map in the JS Bundle entry file by serviceName, so as to form a mapping pool of service name → service class.
[0010] Preferably, the service registration module is used to, when the Native sends a request through the headlessServiceHandle channel, parse the headlessService parameter from the route URL through the global singleton registry ServiceRegistry to obtain the serviceName, and extract the remaining URL parameters as business props; use contextId as the unique context identifier of the service instance to construct an IRouterServiceContext context object; look up the registered service class from the global Map by serviceName; and instantiate the service object after injecting the props with the __serviceName__ and __serviceContextId__ identifiers.
[0011] Preferably, the native proxy module is used to selectively intercept FlutterEngine creation, Fragment mounting, Platform initialization, and container lifecycle events via DecoratorOwner.
[0012] Preferably, the native proxy module is also used to retain the bidirectional communication channel between JSBundle loading and Native-JS.
[0013] Preferably, the cross-channel data sharing module is used to isolate and store data in ThreshStorage using the serviceName_contextId combination key, and to control the Headless Service and subsequent pages under the same contextId to read and write shared data using the same combination key.
[0014] Preferably, the cross-channel data sharing module is used to write data to ThreshStorage and name the storage space during the Headless Service execution phase using the setStorage(key, params) method; After the subsequent page is opened, the data under the same namespace is read through the static method getStorage(key, props), where the name is carried in props to restore the storage key; When the page is destroyed, clearStorage(props) clears the data in the corresponding namespace.
[0015] Preferably, the result callback and resource reclamation module is used to send the result back to the caller's callback interface via the Native channel through Dispatcher.onHeadlessResult.
[0016] Preferably, the result callback and resource reclamation module is used to send the result data carrying the contextId to the Native layer through the callNative channel.
[0017] Preferably, the result callback and resource recycling module is used to trigger OnExecuteThreshServiceResult to return the result to the original caller after the Native-side DecoratorOwner intercepts the callback message, and then performs service resource release and monitoring reporting on the UI thread through MBThreshServiceLifecycle.
[0018] The present invention discloses the following technical effects: The resource consumption of this invention is significantly reduced. This invention removes all overhead of container startup, FlutterEngine initialization and UI rendering. HeadlessService consumes only the minimum resources required for JS execution, and the service response time is significantly shortened. The present invention has zero data transmission overhead. When the HeadlessService and subsequent pages share the same JS runtime, they can directly read and write in ThreshStorage through the `serviceName_contextId` key combination without serialization / deserialization, and the data transmission latency is close to zero. This invention achieves precise and controllable multi-concurrent services. It uses contextId as an end-to-end transaction identifier, enabling each service instance to be accurately addressed, have independent result attribution, and have independent lifecycle recycling in concurrent scenarios. The `serviceName_contextId` combo key ensures natural data isolation between different instances, preventing interference between them. This invention automates the entire process of result delivery and resource recycling. After the caller initiates a request through Bridge.invoke, it can asynchronously wait for the service result. After the result is returned, the framework automatically completes resource release and monitoring reporting. Business developers do not need to manually manage the service lifecycle, fundamentally avoiding resource leakage. Attached Figure Description
[0019] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0020] Figure 1 This is the overall architecture diagram described in this invention; Figure 2 This is a flowchart of the service registration process described in this invention; Figure 3 This is a service execution flowchart as described in this invention. Detailed Implementation
[0021] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely represents selected embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.
[0022] like Figures 1-3As shown, the present invention provides a context-identifier-based end-side pageless decision-making system applied to the field of next-generation information technology industry technology. The overall architecture of the system consists of four collaborative modules, namely a service registration module, a native proxy module, a cross-channel data sharing module, and a result callback and resource reclamation module.
[0023] In one implementation, the service registration module (JS side) adopts a global singleton registry (ServiceRegistry). In the JSBundle entry file, each business HeadlessService class is registered to the global Map by serviceName, forming a mapping pool of "service name → service class".
[0024] For example, a JSBundle (JavaScript bundle file) is the final executable file generated by front-end build tools after parsing, compiling, merging, compressing, and optimizing multiple scattered JS modules, third-party libraries, and related static resources such as CSS and images in a project. It is the core code artifact deployed to the production environment after the project is completed.
[0025] For example, HeadlessService is a special type of Service in Kubernetes. Its core feature is that it does not assign ClusterIP (virtual IP) or provide load balancing. Instead, it directly returns a list of the real IPs of all backend Pods through DNS, allowing clients to connect directly to the Pods.
[0026] For example, serviceName is used to bind a HeadlessService, allowing the Pod created by the StatefulSet to obtain a stable, fixed domain name. This is a core parameter that stateful applications such as databases and middleware must configure.
[0027] For example, a global Map is a Map data structure that can be accessed throughout the entire project, the entire page, and the entire application lifecycle, and will not be destroyed. It is used for global caching, global state, global configuration, and global unique key-value pair management.
[0028] In one implementation, the native proxy module on the Native side wraps ThreshOwner using the DecoratorOwner pattern, selectively intercepting UI-related operations such as FlutterEngine creation, Fragment mounting, Platform initialization, and container lifecycle events, while retaining only the JSBundle loading and the bidirectional communication channel between Native and JS. For example, ThreshOwner is a standard term in network monitoring and operations, meaning the owner of a threshold rule.
[0029] For example, FlutterEngine creation, Fragment mounting, and Platform initialization are the three core components of Android native + Flutter hybrid development. Among them, FlutterEngine is the "running engine" of Flutter in Android; FlutterFragment is the container used by Android to "display the Flutter interface"; and Platform initialization = establishing a communication channel between Flutter and Android.
[0030] For example, a JSBundle is one or more complete JS files generated by packaging, compressing, and merging JavaScript code files, which can be directly loaded and executed in the runtime environment.
[0031] For example, Native-JS bidirectional communication means that the native client (Android / iOS) and the web page JS call each other's methods and pass data to each other. That is, Native-JS bidirectional communication = the native client and the JS in WebView call each other, pass parameters to each other, and call back to each other to achieve functional interoperability.
[0032] In one implementation of the cross-channel data sharing module, data is stored in isolation in ThreshStorage based on the `serviceName_contextId` key combination. HeadlessService and subsequent pages under the same contextId can read and write shared data using the same key combination. For example, serviceName_contextId is the core service routing and context isolation mechanism in Native-JS bidirectional communication, used to accurately locate "which service to call and in which environment / instance to execute".
[0033] For example, ThreshStorage is a dedicated local cache / persistent storage component.
[0034] For example, contextId is a context ID used to uniquely identify an "environment number" for a call, a page, a container, or a session.
[0035] In one implementation, after the JS service finishes execution, the result callback and resource recycling module sends the result back to the caller's callback interface via the Native channel through Dispatcher.onHeadlessResult. After the Native-side DecoratorOwner intercepts the callback message, it triggers OnExecuteThreshServiceResult to return the result to the original caller, and then performs service resource release and monitoring reporting on the UI thread through MBThreshServiceLifecycle.
[0036] For example, Dispatcher.onHeadlessResult is a "callback method / callback event", that is, Dispatcher.onHeadlessResult = callback function that dispatches the result after the headless service / headless instance has finished executing.
[0037] For example, Native means the native code that comes with the system.
[0038] For example, DecoratorOwner represents the decorator owner, which is the entity that holds and manages the decorator instance in the decorator pattern. It is responsible for the creation, binding, destruction, and state maintenance of the decorator, ensuring that the decoration logic is consistent with the lifecycle of the decorated object.
[0039] For example, OnExecuteThreshServiceResult represents the callback method for the result after the threshold service is completed, that is, the callback function used to receive the returned result when the threshold service is completed.
[0040] For example, MBThreshServiceLifecycle represents a lifecycle controller that manages the entire process of a threshold service from creation, execution to destruction. It is responsible for the state management of the entire process from startup to destruction, ensuring that the service does not run wild, does not leak, and that callbacks can return normally.
[0041] In one embodiment, the execution process of the end-side pageless decision-making system designed in this invention includes the following steps: Step S10 Service Registration: In the JSBundle entry file, the business developer calls ServiceRegistry.registerService(serviceName,HeadlessServiceClass) to register each HeadlessService class to the Map of the global singleton registry.
[0042] In step S20, the caller initiates a headless request. Any business JavaScript code calls the native `executeThreshService` method via `Bridge.invoke`, passing in the route URL containing the `headlessService` parameter. After receiving the request, the native `MBThresh` facade class constructs a route Intent on the UI thread, creates an `MBThreshHeadlessService` instance, calls the `execute` method, and registers the `OnExecuteThreshServiceResult` callback interface to wait for the service execution result.
[0043] Step S30 constructs a UI-free execution channel. During the create ThreshOwner phase, the MBThresh Headless Service uses the Decorator Owner to decorate the ThreshOwner proxy, intercepting UI-related operations such as FlutterEngine creation, Fragment mounting, and lifecycle events. At the same time, it sets the headless Service Flag to true and notifies the service creation event through MBThreshServiceLifecycle.onServiceCreate.
[0044] Step S40 loads the JSBundle and triggers the service, ensuring the JSBundle loading channel functions normally while loading the business JS code. When the script execution is complete and in the LoadScriptState.ExecuteScriptEnd state, DecoratorOwner sends a headlessServiceHandle message to the JS side via the execMessage method, carrying the route URL and contextId parameters.
[0045] Step S50 involves service addressing and instantiation. The JS-side Receiver channel receives the headlessServiceHandle message from S40 and forwards it to the ServiceRegistry.navigate method. This method parses the serviceName and business parameters from the URL, constructs the IRouterServiceContext using the contextId, searches for the registered Service class in S1 in the global Map, injects the serviceName and contextId identifiers, and then instantiates the Service.
[0046] Step S60 executes service logic by calling the headlessHandle method of the service instance to execute pre-processing business logic such as interface requests, data validation, and control judgments.
[0047] In step S70, after the service logic is completed, the JS side calls `Dispatcher.onHeadlessResult(context, resultData)` to send the result data, carrying the `contextId`, to the Native layer via the `callNative` channel. The Native side's `DecoratorOwner` intercepts the "on Thresh Headless Result" message in the `onJSCallNative` method and returns the result to the original caller in S20 via the `On Execute Thresh Service Result` callback interface.
[0048] Step S80 Resource reclamation and monitoring reporting: After the result is returned, the Decorator Owner reports the service shutdown monitoring metrics, including the serviceName and the call source dimension. Then, the service lifecycle end event is triggered on the UI thread through MBThreshServiceLifecycle.onServiceFinished to release the resources occupied by the service instance.
[0049] For example, during the execution of the above steps, step S10 is the pre-registration stage, which is executed once when the App starts and loads the JSBundle; step S20 is the service trigger entry point; steps S30 to S40 are the construction execution channel; steps S50 to S60 are the service core execution link; and steps S70 to S80 are the result feedback and resource reclamation stages.
[0050] In one embodiment, the present invention designs a UI-free execution channel construction mechanism based on decorator proxy. On the native side, the ThreshOwner of the standard page container is proxied and wrapped by the decorator pattern (DecoratorOwner), selectively intercepting all UI-related operations such as FlutterEngine creation, Fragment mounting, and container lifecycle messages, while retaining only the JSBundle loading channel and Native-JS bidirectional communication capability, so that JS code can run directly without creating any UI components or rendering engine.
[0051] For example, this UI-free execution channel construction mechanism fundamentally eliminates the resource overhead of FlutterEngine creation and UI rendering, and realizes a lightweight JS front-end execution channel.
[0052] In one implementation, the UI-less proxy interception mechanism is unavoidable. Without using DecoratorOwner to intercept the UI chain, including FlutterEngine creation, Fragment mounting, Dart route sending, and Platform initialization, the entire rendering engine initialization process still needs to be followed regardless of how the page container's startup parameters are adjusted. Therefore, the core goal of this solution—"no page, low overhead"—cannot be achieved. This UI-less execution channel construction mechanism is the only technical means to decouple JS execution capabilities from UI rendering capabilities.
[0053] In one embodiment, the present invention designs a global service registration and precise addressing mechanism based on context identifiers, establishes a global singleton ServiceRegistry on the JS side, and uses a Map data structure to maintain the mapping relationship between serviceName and HeadlessServiceClass.
[0054] For example, when a Native application sends a request through a headlessServiceHandle channel, the ServiceRegistry performs the following addressing process: (1) Parse the headlessService parameter from the routing URL to obtain the serviceName, and extract the remaining URL parameters as business props; (2) Use contextId as the unique context identifier of the service instance to construct the IRouterServiceContext context object; (3) Find the registered service class in the global Map by serviceName; (4) Inject the serviceName and serviceContextId identifiers into the props and then instantiate the service object.
[0055] For example, the addressing method is aligned with the management method of the page container. Each service instance can be accurately located in a multi-concurrency environment through the contextId. The contextId enables accurate addressing and lifecycle management of multi-concurrency service instances.
[0056] In one implementation, the contextId end-to-end identifier cannot be omitted. If only the serviceName or a temporary object reference is used to manage service instances, it is impossible to distinguish between instances in a multi-service concurrent scenario, leading to confusion of result attribution and loss of control over lifecycle management. The contextId is a unique transaction identifier that runs through the entire chain of Native requests, JS addressing, result postback, and resource recycling, and cannot be omitted or replaced by other weak identifiers.
[0057] In one embodiment, the present invention designs a cross-stage data sharing and isolation mechanism based on the serviceName_contextId composite key.
[0058] For example, in the HeadlessService base class, data sharing and isolation between HeadlessService and subsequent pages are achieved through the serviceName_contextId composite key: (1) During the execution phase of HeadlessService, data is written to ThreshStorage using the setStorage(key,params) method, with the storage namespace being ${serviceName}_${contextId}; (2) After the subsequent page is opened, the data under the same namespace is read through the static method getStorage(key,props), where __serviceName__ and __serviceContextId__ carried in props are used to restore the storage key; (3) When the page is destroyed, clearStorage(props) is used to clear the corresponding namespace data.
[0059] For example, since HeadlessService and subsequent pages run in the same JavaScript runtime, data sharing requires no serialization / deserialization, achieving zero-overhead data transfer. Service instances with different serviceNames or different contextIds are naturally isolated from each other and do not interfere with one another.
[0060] For example, this data sharing and isolation mechanism enables front-end services and subsequent pages to directly share state data in the same JS runtime, saving serialization overhead; different service instances are naturally isolated through composite keys, so they do not interfere with each other.
[0061] In one implementation, the serviceName_contextId composite key cannot be simplified. If it is stored or used as a globally shared variable only by serviceName, cross-instance data pollution is likely to occur when multiple instances are running concurrently. If it is changed to run independently or be executed in an independent container, serialization must be introduced, losing the advantage of zero-overhead sharing. The composite key mechanism is the only feasible path under the premise that both the constraints of "data shareability" and "strong isolation between instances" are met simultaneously, and it cannot be split into a single dimension.
[0062] In one embodiment, the present invention designs a mechanism for cross-layer result return from JS to Native and automatic recycling of service resources.
[0063] For example, establish a complete result return chain from the JS service execution layer to the native caller: (1) After the JS-side service finishes executing the business logic in headlessHandle, it actively calls Dispatcher.onHeadlessResult(context, resultData). This method sends the result data with contextId to the Native layer through the callNative channel. (2) The Native side DecoratorOwner overrides the onJSCallNative method, intercepts the call with the method name "onThreshHeadlessResult", and returns the result data to the original caller through the OnExecuteThreshServiceResult callback interface, similar to the openSchemeForResult mode. (3) After the result is returned, DecoratorOwner triggers the release of service resources on the UI thread through MBThresh ServiceLifecycle.onServiceFinished, and reports service usage monitoring metrics, including serviceName and call source.
[0064] For example, the entire callback and recycling process is managed uniformly by the framework. Business developers can call Dispatcher.onHeadlessResult once in headlessHandle to simultaneously return the result and release resources.
[0065] For example, this automatic recycling mechanism integrates result delivery and resource recycling into a single call, ensuring a complete closed loop in the service execution chain from the framework level.
[0066] In one implementation, result feedback and resource reclamation are inseparable. If only the result is returned without corresponding reclamation, the service instance will continue to occupy resources; if only reclamation is performed without guaranteeing result feedback, the caller will not be able to obtain the execution output. Both must be driven by the same feedback action to simultaneously meet the engineering closed-loop requirements of "deliverable results + automatic resource release + monitoring and reporting".
[0067] In one embodiment, the above mechanism can be replaced by equivalent means, such as changing the registry data structure, adjusting the callback naming, or changing the storage key format. As long as the technical combination relationship of "no UI execution channel + contextId transaction identifier + combination key sharing isolation + return and recycling linkage" is still achieved, it falls within the scope of equivalent replacement of the technical essence of this invention.
[0068] In summary, this invention eliminates all overhead associated with container startup, FlutterEngine initialization, and UI rendering. The Headless Service consumes only the minimum resources required for JS execution, significantly reducing service response time. When the Headless Service shares the same JS runtime with subsequent pages, this invention allows direct reading and writing in ThreshStorage via the `serviceName_contextId` key, eliminating the need for serialization / deserialization and achieving near-zero data transmission latency. Using contextId as an end-to-end transaction identifier, this invention ensures accurate addressing, independent result attribution, and independent lifecycle recycling for each service instance in concurrent scenarios. The `serviceName_contextId` key guarantees natural data isolation between different instances, preventing interference. Furthermore, this invention allows the caller to asynchronously wait for service results after initiating a request via Bridge.invoke. After the result is returned, the framework automatically releases resources and reports monitoring results, eliminating the need for business developers to manually manage the service lifecycle and fundamentally preventing resource leaks.
[0069] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Therefore, if these modifications and variations fall within the scope of the claims of this invention and their equivalents, this invention also intends to include these modifications and variations.
Claims
1. A context-based identification of end-side no-page decision system, characterized in that, include: The service registration module is used to register each service to the global Map by serviceName; The native proxy module is used to wrap ThreshOwner with DecoratorOwner and selectively intercept UI-related operations. The cross-channel data sharing module is used to achieve data sharing and isolation between HeadlessService and subsequent pages through the serviceName_contextId combination key; The result callback and resource recycling module is used to send the result back to the callback interface after the JS service has finished executing. The callback message is intercepted by DecoratorOwner and the result is returned to the caller. Then, the service resources are released and the monitoring is reported on the UI thread.
2. The context-identifier-based end-side pageless decision-making system according to claim 1, characterized in that: The service registration module is used to register each business Headless Service class to the global Map in the JS Bundle entry file by serviceName using a global singleton registry, so as to form a mapping pool of service name → service class.
3. The context-identifier-based end-side pageless decision-making system according to claim 1, characterized in that: The service registration module is used to obtain the serviceName by parsing the headlessService parameter from the routing URL through the global singleton registry ServiceRegistry when the Native sends a request through the headlessServiceHandle channel, and at the same time extract the remaining URL parameters as business props. Use contextId as the unique context identifier for the service instance to construct the IRouterServiceContext context object; look up the registered service class in the global Map by serviceName; and instantiate the service object after injecting props with the __serviceName__ and __serviceContextId__ identifiers.
4. The context-identifier-based end-side pageless decision-making system according to claim 1, characterized in that: The native proxy module is used to selectively intercept FlutterEngine creation, Fragment mounting, Platform initialization, and container lifecycle events through DecoratorOwner.
5. The context-identifier-based end-side pageless decision-making system according to claim 1, characterized in that: The native proxy module is also used to retain the bidirectional communication channel between JSBundle loading and Native-JS.
6. The context-identifier-based end-side pageless decision-making system according to claim 1, characterized in that: The cross-channel data sharing module is used to isolate and store data in ThreshStorage using the serviceName_contextId combination key, and to control Headless Services and subsequent pages under the same contextId to read and write shared data using the same combination key.
7. The context-identifier-based end-side pageless decision-making system according to claim 1, characterized in that: The cross-channel data sharing module is used to write data to ThreshStorage and name the storage space during the Headless Service execution phase using the setStorage(key, params) method. After the subsequent page is opened, the data under the same namespace is read through the static method getStorage(key, props), where the name is carried in props to restore the storage key; When the page is destroyed, clearStorage(props) clears the data in the corresponding namespace.
8. The context-identifier-based terminal-side pageless decision-making system according to claim 1, characterized in that: The result callback and resource recycling module is used to send the result back to the caller's callback interface via the Native channel through Dispatcher.onHeadlessResult.
9. The context-identifier-based terminal-side pageless decision-making system according to claim 8, characterized in that: The result callback and resource recycling module is used to send the result data with contextId to the Native layer through the callNative channel.
10. The context-identifier-based end-side pageless decision-making system according to claim 1, characterized in that: The result callback and resource recycling module is used to intercept the callback message on the Native side, and then trigger OnExecuteThreshServiceResult to return the result to the original caller. Subsequently, service resource release and monitoring reporting are performed on the UI thread through MBThreshServiceLifecycle.