Xin creation terminal compatibility mutual authentication and performance tuning pedestal system

Abstract

The application discloses a kind of Xinxin terminal compatibility mutual authentication and performance tuning pedestal system, it is related to Xinxin terminal compatibility mutual authentication and performance tuning pedestal technical field, for solving the problem that address book module, service number module and workbench module under multiple Xinxin operating system and domestic CPU architecture are difficult to be uniformly carried, multi-security domain service routing error and terminal performance and compatibility are difficult to collaborative optimization;Around Xinxin terminal pedestal, collaborative work such as dependent reconstruction module, mobile application interface architecture rendering scheduling module is constructed, based on environmental compatibility score, Xinxin terminal pedestal construction and dependent reconstruction are automatically completed, under the premise that unlicensed personal information in public places is not collected, in combination with business module loading sequence optimization, interface scaling and rendering priority control and performance score and Xinxin compatibility test matrix closed loop optimization, improve the unified interface experience and running stability under multiple operating systems, multiple CPU architecture and multiple security domain deployment.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of Xinyuan terminal compatibility mutual authentication and performance optimization base, more specifically, the present application relates to a kind of Xinyuan terminal compatibility mutual authentication and performance optimization base system. BACKGROUND

[0002] With the deployment scale of Xinyuan UOS, Galaxy Kirin and other Xinyuan operating systems and Feiteng, Loongson and other domestic CPU architectures in party and government, energy and industrial control scenarios continues to expand, cross-platform mobile applications based on Electron framework are gradually migrated to Xinyuan terminal environment for running.In the prior art, mobile applications are usually adapted to a single operating system and CPU combination, and library transplantation relies on manual experience configuration, lacking quantitative measurement of environment compatibility and dependency adaptation cost, resulting in uneven quality of construction results on different Xinyuan platforms, and some terminals have compatibility problems such as window management abnormalities, file listening invalidation or security policy conflicts.At the same time, to support production control domain, simulation exercise domain and production management domain and other multi-security domain businesses, address book module, service number module and workbench module need to access multiple sets of service instances distributed in different security domains, different versions of Xinyuan operating systems and different domestic CPU architectures.The existing multi-domain service routing scheme mostly uses static configuration or simple network delay and availability indicators as decision basis, and it is difficult to simultaneously consider security domain isolation, interface semantic consistency and Xinyuan compatibility, which may cause problems such as production control domain terminal misconnection simulation exercise service or simulation terminal misconnection real production service.On the other hand, Xinyuan terminals are generally subject to CPU power, graphics processing capability and memory capacity, and when carrying complex Electron applications, interface rendering scheduling is not fine, module loading sequence is not reasonable, and service calling strategy is not good, which may cause CPU utilization to be close to the upper limit for a long time, rendering frame time to fluctuate greatly or service calling latency to increase significantly, affecting the overall experience of the terminal.

[0003] To solve the above problems, the present application provides a solution. SUMMARY

[0004] In order to overcome the above-mentioned defects of the prior art, the embodiments of the present application provide a Xinyuan terminal compatibility mutual authentication and performance optimization base system to solve the problems raised in the background art.

[0005] To achieve the above-mentioned purpose, the present application provides the following technical solutions:

[0006] In one preferred embodiment, it comprises: Xinyuan terminal base construction dependency reconstruction module, mobile application interface architecture rendering scheduling module, multi-domain service integration compatibility mutual authentication module, Xinyuan terminal performance optimization compatibility verification module, address book module, service number module, workbench module, signal connection between modules;

[0007] The dependency refactoring module for building the IT innovation terminal base is used to drive the cross-platform desktop framework and third-party dependency libraries to complete source code adaptation and dependency refactoring through environment detection and compatibility quantification.

[0008] The mobile application interface architecture rendering scheduling module is used to create a unified interface shell to divide the navigation area, content display area and auxiliary tool area, and adjust the interface scaling and rendering priority of each view area according to the resolution and the importance of interface elements.

[0009] The multi-domain service integration compatibility and mutual authentication module is used to identify the current security domain based on the environmental feature vector, perform multi-factor comprehensive analysis on the set of security domains to which the service instance belongs or can be accessed and the business semantic category, construct the comprehensive service routing cost value by combining multiple risk quantities and performance indicators, and control the access path and interface adaptation strength according to the cost value, so that the front-end interface is unified while the back-end access is controlled by security domain and business semantic domain.

[0010] The IT innovation terminal performance tuning and compatibility verification module is used to periodically collect system-level indicators to generate a comprehensive performance score. It combines the environmental compatibility score and service routing score to locate performance bottlenecks, and completes performance tuning and compatibility verification through local adjustment, pipeline optimization, and the linkage of the IT innovation compatibility test matrix.

[0011] The address book module, service account module, and workbench module are derived from existing mobile application platforms. The address book module is used to display and retrieve contact information on domestically developed terminals, the service account module is used to carry service messages and business notification interactions, and the workbench module is used to aggregate business entry points and work order task operation interfaces.

[0012] In a preferred embodiment, an environment detection program is deployed on the domestically developed terminal to quantify the compatibility of the operating system kernel, drivers, file system, and security policies. Based on this, a standard adaptation path is automatically selected or additional adaptation layers and capability trimming are enabled. The main process, rendering process, and underlying abstraction layer of the cross-platform desktop framework are modified and recompiled in the domestically developed toolchain to generate runtimes adapted to different domestically developed operating systems and domestic processors. At the same time, candidate solutions for recompiling, local replacement, and adaptation bridging are built for each third-party dependency library and script native module. The optimal solution is automatically selected based on the adaptation cost and the dependency refactoring is completed.

[0013] In a preferred embodiment, the address book, service number, and workbench modules are split into a front-end display layer and a back-end access layer. The front-end interface components are reconstructed and a network access adaptation layer is encapsulated. The startup latency is calculated by measuring the access frequency and initialization time, and the optimal loading order of the three types of modules is determined. A terminal base construction and dependency reconstruction process for the information technology innovation environment is constructed.

[0014] In a preferred embodiment, after the domestically developed terminal base is started according to the aforementioned loading order, a unified interface shell is created in the desktop runtime framework, dividing the window into a navigation area, a content display area, and an auxiliary tool area, and assigning corresponding sub-areas to the address book, service number, and workbench; a scaling factor is calculated based on the ratio of the reference resolution to the current resolution and the importance of interface elements, and the position, size, and font of elements are uniformly adjusted to achieve adaptive layout on various domestic display devices; at the same time, the interface is split into several view areas, and the rendering priority is calculated according to the event triggering frequency, visibility, and interaction activity. Within each frame, the redraw area and redraw order are trimmed and redrawn in combination with the upper limit of view complexity.

[0015] In a preferred embodiment, a multi-domain service integration, compatibility, and inter-authentication module is built inside the domestically developed terminal base. First, using an environmental feature vector containing only network segment and routing identifiers, security domain labels, certificate trust domains, login role domain attributes, and domestically developed operating system version and domestic central processing unit architecture identifiers, the matching score of each security domain is calculated, and the security domain or restricted mode to which the current session belongs is automatically determined. Then, during the service registration phase, each backend service instance and its interface is pre-labeled with its own or accessible security domain set, business semantic category, domestically developed adaptation level, interface version, and parameter structure constraint metadata. At runtime, the domain boundary risk, semantic mismatch risk, and platform compatibility risk are calculated respectively, and together with network latency and failure retry performance indicators, a comprehensive interface access risk and a comprehensive service routing cost are formed.

[0016] In a preferred implementation, in each access request initiated by the address book module, service account module, and workbench module, service instances with domain out-of-bounds risk are first eliminated according to the current security domain. Then, the remaining instances are sorted and routed based on the comprehensive cost value. At the same time, interface adaptation strategies of different strengths are enabled according to the level of semantic mismatch risk, such as lightweight parameter mapping, field completion and pruning, return value fault tolerance, read-only protection, and even function degradation to prohibit access. And within the statistical time window, the service route score is calculated based on the comprehensive cost value of the actual route selection record.

[0017] In a preferred embodiment, the terminal periodically collects system-level indicators such as processor usage, memory usage, interface rendering frame time, and service call latency, which are then uniformly converted into a comprehensive performance score to automatically identify anomalies. Bottlenecks are aggregated and analyzed according to the address book, service number, workbench, and different combinations of domestically developed operating systems and domestic processors. The source of the problem is located by combining environmental compatibility scores and service routing scores.

[0018] In a preferred embodiment, the single-machine pressure is reduced by adjusting the frequency of threads and background tasks locally, tightening the rendering complexity of a single frame, and reallocating the rendering priority of key interface areas. On the build pipeline, optimization compilation and dependency refactoring weight adjustment are triggered for problematic platform combinations. A domestic IT innovation compatibility test matrix covering multiple operating system and multi-processor combinations is used as the release threshold, forming an integrated closed-loop mechanism for performance tuning and compatibility verification.

[0019] The technical effects and advantages of the domestic IT terminal compatibility interoperability authentication and performance optimization base system of the present invention are as follows:

[0020] This invention introduces environmental feature vectors, environmental compatibility scoring, and dependency adaptation cost functions into the dependency reconstruction module for building the Electron-based IT innovation terminal base. This eliminates reliance on empirical judgment in the construction of the terminal base, automatically selecting local recompilation, domestic library replacement, or adaptation layer bridging solutions for different IT innovation operating systems and domestic CPU architectures. This ensures compatibility while balancing performance and maintenance costs. In the mobile application interface architecture rendering scheduling module, the loading order of the address book module, service account module, and workbench module is optimized based on access frequency and initialization time. Furthermore, interface scaling and rendering priority control based on resolution and element importance prioritizes the allocation of limited CPU and graphics rendering capabilities to the most sensitive areas for user perception, effectively reducing initial usage waiting time and scrolling lag probability. The multi-domain service integration compatibility and inter-authentication module, without collecting any unauthorized personal information from public places, uses security domain matching scores and multi-dimensional risk quantities as a link to incorporate domain boundary crossing risks, interface semantic mismatch risks, and IT innovation compatibility risks into a unified decision-making framework, significantly reducing cross-domain misrouting and compatibility anomalies. The IT innovation terminal performance tuning and compatibility verification module forms a closed-loop mechanism that integrates local adjustment and regression testing by combining performance scoring with the compatibility coverage of the IT innovation compatibility test matrix. This enables terminal performance tuning and multi-platform compatibility verification to be carried out in tandem, improving the overall operational stability and maintainability in large-scale IT innovation deployment scenarios. Attached Figure Description

[0021] Figure 1 This is a schematic diagram of a base system module for compatibility authentication and performance optimization of domestically developed terminals according to the present invention.

[0022] Figure 2 This is a timing diagram of a base system for compatibility authentication and performance optimization of domestically developed terminals according to the present invention. Detailed Implementation

[0023] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. 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 are within the scope of protection of the present invention.

[0024] Example

[0025] This invention discloses a base system for compatibility authentication and performance optimization of domestically developed terminals, such as... Figure 1 As shown, it includes: a domestically developed terminal base construction dependency reconstruction module, a mobile application interface architecture rendering and scheduling module, a multi-domain service integration compatibility and mutual authentication module, a domestically developed terminal performance tuning compatibility verification module, an address book module, a service account module, a workbench module, and signal connections between the modules.

[0026] like Figure 2 As shown, in the dependency reconstruction module for building the domestically developed terminal base, the Electron framework is first selected as the cross-platform runtime foundation in the target domestically developed terminal environment. On domestically developed operating systems such as Tongxin UOS and Galaxy Kylin, as well as domestic CPU architectures such as Phytium and Loongson, a series of orderly technical actions are performed on the Electron kernel components, third-party dependency libraries, address book module, service account module, and workbench module to complete the construction and dependency reconstruction of the domestically developed terminal base.

[0027] Specifically, before constructing the domestically developed terminal base, an environment detection program is first deployed on the target domestically developed terminal to collect information such as the current operating system kernel version, system call support, graphics and input / output driver loading status, file system characteristics, and security policy constraints. This information is then organized into an environment feature vector e, and an environment compatibility score is calculated for that environment according to a unified environment compatibility scoring model. Preferably, Calculate according to the following formula:

[0028] ;

[0029] in, This indicates the percentage of system call interfaces supported by Electron in environment e. This indicates the availability of critical drivers such as graphics card drivers and input device drivers in environment e. This indicates the degree to which the file system of environment e conforms to the expected behavior of Electron in terms of file listening, locking mechanisms, etc. This indicates the proportion of system capabilities that are actually allowed to be enabled under the security policy constraints of environment e; , , , The weighting coefficients for each indicator are pre-set according to actual deployment requirements and satisfy the following conditions: .

[0030] During the construction process, a detection program is used to perform item-by-item testing on each type of capability in the domestically developed terminal, and the test results are normalized to obtain... , , , Substituting into the above formula, we obtain and with preset compatibility threshold Comparison: When In this environment, a standard Electron source code adaptation path is used; when In this case, the build script can automatically enable additional adaptation layers or trim some capabilities, such as adding user-space emulation for missing system calls or adding wrapper functions for abnormal file system behavior, to avoid forcing the use of unsupported capabilities in a low-compatibility environment.

[0031] After completing the environmental compatibility quantification and determining the adaptation mode, the source code corresponding to the Electron version was pulled from the build server. Under the constraints of the domestic IT terminal toolchain, the Electron main process, rendering process, and underlying platform abstraction layer were modified at the source code level: a domestic IT operating system branch was added to the system call branch originally for Windows or general GNU / Linux, and key path calls such as window creation, process management, and file monitoring were rewritten to the API combination actually provided by the domestic IT operating system. Configuration, compilation, and linking were performed in target architecture environments such as Phytium and Loongson to generate Electron runtime binaries for different domestic IT operating systems and CPU architectures, thus realizing the kernel framework of the domestic IT terminal base.

[0032] After the Electron kernel adaptation was completed, the dependency library packages were refactored around the third-party libraries and Node native modules that the domestic IT application development terminal base depends on. A dependency adaptation cost function was introduced during the refactoring process. A quantitative evaluation is performed on the different adaptation schemes for each dependency library d in environment e. Preferably, Calculate according to the following formula:

[0033] ;

[0034] in, This represents the workload and modification complexity required to port or replace the source code of dependent library d in environment e. This indicates the relative impact of selecting this adaptation scheme on the operational performance of the domestically developed terminal base. This indicates the cost of maintaining the adaptation scheme; all three are normalized to [0,1] based on historical porting experience, code difference analysis, and performance evaluation. , , The weighting coefficients for each cost item are pre-set based on the project's trade-offs between migration cost, performance, and maintainability, and satisfy the following conditions: .

[0035] Subsequently, in actual implementation, after parsing the project dependency configuration file, several candidate solutions were considered, including local recompilation for each dependency library, replacement of domestic libraries, and adaptation layer bridging. The cost of each solution was then estimated. , , Calculate the corresponding Automatic selection The minimum solution is written into the build script; for dependencies that choose local recompilation, their source code is pulled from the domestic IT innovation compilation environment, and recompiled according to the Electron target architecture to generate library files adapted to instruction sets such as Phytium and Loongson, and the dependency path is updated; for dependencies that choose domestic library replacement, the calls are redirected to the implementation of the domestic equivalent library without changing the upper-layer call interface; for dependencies that choose the adaptation layer bridging solution, an interface adaptation layer is implemented in the Electron main process to perform format conversion and error compatibility handling for the original call parameters and return values, so that the upper-layer business logic can run on the domestic IT innovation terminal base without modification.

[0036] After the dependency library reconstruction was completed, the dependency reconstruction module for the domestically developed terminal base structured and decomposed the address book module, service account module, and workbench module in the company's existing mobile application platform and integrated them into the domestically developed environment. Specifically, the original implementations of the three modules were first divided into a front-end presentation layer and a back-end access layer. In the Electron rendering process, HTML5, CSS, and JavaScript were used to reconstruct the address book interface, service account message interface, and workbench entry interface, encapsulating their interface structure and interaction logic into front-end components adapted to the domestically developed terminal window management and input system. In the Electron main process, call adaptation layers for accessing back-end services were established for the address book module, service account module, and workbench module respectively, encapsulating the establishment and maintenance logic of HTTP requests, WebSocket connections, or enterprise-specific protocols. This ensures that the three modules can stably access the original mobile application platform back-end under the constraints of the domestically developed operating system's network stack and security policies. Based on this, the dependency reconstruction module for the domestically developed terminal base measured the access frequency and initialization time of the three modules in real business scenarios to determine the loading order of these modules in the domestically developed terminal base, further shortening the perceived waiting time for users during their first use.

[0037] To ensure the repeatability and measurability of the loading order determination process, the address book module, service account module, and workbench module are denoted as three elements m1, m2, and m3 in set M. The average access frequency of each module per unit time under typical business scenarios is denoted as... The time required for a module to go from initialization to being able to receive user requests is denoted as . After the domestically developed terminal base is started, the modules load in a specific order. , , Initialization complete. Preferably, the expected weighted startup delay under the loading order σ is... Defined as:

[0038] ;

[0039] in, , , , representing the cumulative time point when the k-th module completes initialization under the loading order σ. k∈{1,2,3} is the loading position number, and m represents the module set, consisting of the address book module, the service number module, and the workbench module. This represents the module loading order, indicating an arrangement of the module set M; under the loading order σ, the three modules loaded in sequence are denoted as follows: This represents the initialization time required for module m to go from initialization to being able to receive user requests. This represents the cumulative time point when the k-th module completes initialization under the loading order σ;

[0040] During actual deployment, the address book module, service account module, and workbench module were measured on the prototype IT innovation terminal. and Enumerate all possible loading orders σ for the three modules and calculate the corresponding... Select The minimum loading order is written into the startup configuration of the Electron-based IT terminal base, so that after the kernel initialization and dependency loading are completed, the Electron-based IT terminal base will prioritize the initialization of modules with high access frequency and short initialization time, thereby ensuring that the overall waiting time when the user first accesses the address book, service number and workbench is minimized in the algorithm.

[0041] In the mobile application interface architecture rendering scheduling module, after the IT innovation terminal base starts and completes the module loading order determined in the IT innovation terminal base construction dependency refactoring module, the Electron main process first creates a main window for the mobile application platform according to the preset configuration, and loads a unified UI shell page in the main window through the rendering process. The UI shell page divides the entire window into three logical blocks: a navigation area, a content display area, and an auxiliary tool area through a predefined layout grid, and assigns fixed or switchable content display sub-areas to the address book module, service account module, and workbench module respectively.

[0042] Meanwhile, in order to ensure that the interface layout is not disrupted on domestic display devices with different resolutions and DPIs, an interface scaling factor calculation model based on resolution and element importance is introduced into the UI shell to uniformly adjust the position and size of each interface element.

[0043] Preferably, the reference resolution in the mobile application UI design is set to [resolution value]. The actual resolution of the current information technology application innovation terminal display device is denoted as . The horizontal scaling factor is calculated first when the UI shell is loaded. With vertical scaling factor Specifically:

[0044] ;

[0045] ;

[0046] in, This indicates the baseline width and height used for typesetting and annotation during the design phase. and This represents the actual screen width and height detected during runtime on the domestically developed terminal. For each UI element *u*, a preset element importance weight is assigned. , The range of values ​​is Elements with higher importance are retained more during scaling. Then, during UI rendering, a scaling factor is calculated for element u. :

[0047] ;

[0048] in, Used to simultaneously adjust the visual properties of the element u, such as its width, height, and font size; This is used to ensure that the overall layout remains unchanged on terminals with inconsistent aspect ratios. This feature enhances readability and clickability of high-importance elements such as contact list titles, service account message summaries, and key entry buttons on the workbench during scaling. In practice, during the Electron rendering process, the preset reference size of each element is multiplied by the corresponding [size / value] using CSS variables or runtime styles. It dynamically generates actual style sheets that adapt to the current resolution of domestically developed terminals, enabling the same UI structure to be adaptively laid out on Tongxin UOS and Galaxy Kylin terminals with different resolutions and DPIs.

[0049] Next, after establishing the interface scaling model, the mobile application interface architecture rendering scheduling module further constructs a local redrawing strategy based on rendering priority scoring around the rendering scheduling of the mobile application UI interface architecture. This aims to reduce the ineffective redrawing overhead when rendering the address book interface, service account message interface, and workbench interface on domestically developed terminals, thereby improving the response speed of key interactive areas. To this end, the UI interface is divided into several view areas q during the rendering process. Each view area corresponds to a relatively independent redrawable unit, such as the address book list area, the service account message stream area, and the workbench task card area. During runtime, by collecting event triggering frequency, visibility status, and interaction density, a rendering priority score is calculated for each view area. And in the scheduling loop, the regions with high scores are given priority for rendering updates.

[0050] Preferably, the rendering priority of the view region q is scored. Defined as:

[0051] ;

[0052] in, V(q) represents the normalized frequency of user input events (such as clicks, scrolling, keyboard input) and data push events (such as new messages arriving, task status changes) received in the view area q within the most recent evaluation time window; V(q) represents the visibility index of the view area q, which is 1 when the area is completely within the visible viewport, a visibility ratio between 0 and 1 when it is partially visible, and 0 when it is completely invisible. This represents an activity level metric for the view area q, such as the normalized number of times controls within that area are clicked or focused per unit time. Three weighting coefficients. , , Pre-set according to product characteristics and experience requirements to meet .

[0053] During the actual rendering schedule, the rendering process maintains a list consisting of each view region q and its corresponding region q. The priority queue prioritizes high-scoring areas for DOM updates and layer redraws during redraw cycles, while delaying redraws or performing only lightweight placeholder updates for low-scoring areas that are not currently visible. This allows limited CPU and GPU rendering resources on IT-enabled terminals to be allocated preferentially to user-sensitive areas such as scrolling contact lists, displaying new service account messages, and changes in workbench task status.

[0054] Meanwhile, to avoid over-rendering in complex scenes that could lead to a drop in rendering frame rate, a UI complexity constraint is introduced into the rendering scheduling loop, which determines the set of view areas to be redrawn in each frame. Calculate the UI complexity of the current frame. A full redraw is performed only if the value is below a preset threshold; otherwise, pruning is performed according to rendering priority scores. Preferably, the interface complexity at time t is defined as:

[0055] ;

[0056] in, This represents the set of view regions planned to be redrawn in the rendering scheduler at time t. c(q) represents the complexity index of view region q, which can be calculated and normalized based on the number of DOM nodes, the amount of bound data, and the number of animation effects within the region according to certain rules. In actual implementation, during the Electron rendering process, whenever the scheduler... The queue selects a batch of candidate redraw regions. Then, calculate first. And with the complexity cap set according to the CPU and GPU capabilities of the domestically developed terminal. In comparison, when Perform a full batch redraw when Then from Regions are removed sequentially from low to high rendering priority until the complexity of the remaining regions does not exceed a certain threshold. Then, the actual redrawing is restarted. In this way, the mobile application UI architecture can maintain smooth interface response in complex business scenarios on domestically developed terminals.

[0057] It should be noted that the domestically developed terminal base based on the Electron framework runs simultaneously in three security domains: production control domain, simulation and exercise domain, and production management domain. The address book module, service number module, and workbench module on the same terminal maintain a consistent interface, but they actually access multiple service instances distributed across different security domains, different domestically developed operating system versions, and different domestic CPU architectures. These service instances differ significantly in terms of network latency, stability, domestically developed compatibility, interface versions, and authentication policies, and are even not equivalent in terms of business semantics: the workbench interface in the production control domain directly drives real devices and scheduling systems, the interface with the same name in the simulation and exercise domain is only used for virtual tasks and simulated alarms, and the interface in the production management domain is only used for work order collaboration and statistical analysis.

[0058] In this multi-domain, multi-instance deployment pattern of domestic IT innovation, if we still adopt the approach of statically configuring a single backend address for each terminal, or selecting service instances based solely on single indicators such as network latency and success rate, serious problems may arise, such as production terminals being routed to simulation and training services, resulting in alarms and instructions falling into the wrong environment; simulation terminals being routed to real production services, resulting in training instructions being mistakenly entered into the production system; or terminals being routed to instances with outdated interface versions but optimal short-term performance, leading to frequent crashes and compatibility errors on the current domestic IT innovation operating system and CPU combination.

[0059] Therefore, in the multi-domain service integration and compatibility authentication module of this embodiment, a hierarchical comprehensive analysis and decision-making mechanism oriented towards security domains, service instances and interface semantics is built inside the domestically developed terminal base. Without collecting any unauthorized personal information in public places, the linkage control of three levels is completed in sequence: current security domain identification, domain semantics and risk quantification, and service routing and interface adaptation execution. This ensures that the address book module, service account module and workbench module maintain interface consistency in the production control domain, simulation exercise domain and production management domain, while strictly distinguishing between real production, simulation exercise and management collaboration in terms of background access path and interface behavior.

[0060] Specifically, in the security domain identification layer, the domestically developed terminal base first extracts a set of environmental feature vectors unrelated to user identity based on the current operating environment. These include the network segment and routing identifier where the terminal is located, the security domain label issued through the gateway or security device, the trust domain identifier of the root certificate or certificate chain loaded by the terminal, the domain attribute information of the role corresponding to the login account, and the current domestically developed operating system version and domestic CPU architecture identifier. These features are then uniformly encoded into an environmental feature vector. Feature weight coefficient sets are pre-configured for the production control domain, simulation exercise domain, and production management domain, respectively. , , And define a matching degree function for each feature under different security domains. During runtime, the domestically developed terminal base calculates the matching scores for the three security domains according to the following formula:

[0061] , ;

[0062] in, , and These represent the matching scores between the current environment and the production control domain, simulation exercise domain, and production management domain, respectively. This represents the weight of the i-th feature in the security domain k on the judgment result. This indicates the degree of matching of the environmental feature vector x on this feature dimension.

[0063] Subsequently, the IT innovation terminal base selects the security domain with the highest score that is higher than the preset domain judgment threshold as the security domain identifier for the current session. When all scores are lower than the threshold, the current session is downgraded to restricted mode, prohibiting access to the real control interfaces related to the production control domain, and only allowing access to strictly trimmed management classes or read-only interfaces.

[0064] In the domain semantics and risk quantification layer, this embodiment pre-labels multiple sets of metadata related to security domains and semantics for each backend service instance e and each interface p exposed by the instance during the service registration and interface configuration phase. These include the set of security domains to which the service instance belongs or is allowed to access, the information technology innovation adaptation level label of the service instance, the business semantic category of the interface, the interface version number, and the feature vector of parameter structure and data constraints.

[0065] Regarding the aforementioned metadata, the domestically developed terminal base calculates three types of risk quantities during runtime for the current security domain D, candidate service instance e, and its interface p: the first being the domain boundary crossing risk quantity. This is used to characterize whether the current security domain D violates the security domain isolation policy when calling service instance e. When instance e's allowed access domain set includes D, Take a low value close to zero when instance e is not allowed in the current security domain. The higher value is taken; the second is the semantic mismatch risk. This is used to characterize the deviation between the expected business semantics of the current security domain and the actual semantics of interface p. For example, when a workbench request under the production control domain is mapped to a simulation interface in the simulation exercise domain, the risk of semantic mismatch increases significantly; thirdly, it is the platform compatibility risk. This reflects the degree of compatibility and test coverage of service instance e on the current combination of domestically developed operating systems and CPUs. Based on the above three types of risk quantities, this embodiment constructs a comprehensive interface access risk quantity:

[0066] ;

[0067] in, , , The weighting coefficients for the three risk parameters reflect the system's emphasis on domain out-of-bounds access, prevention of semantic confusion, and compatibility with domestic IT innovation, satisfying the following requirements. By adjusting , , The value of can be flexibly balanced in different units and projects, with multiple strategies such as absolute security priority, strict semantic consistency priority, and compatibility and stability priority for information technology innovation.

[0068] In the service routing and interface adaptation execution layer, this embodiment, within the Electron main process, for each backend access request initiated by the address book module, service account module, or workbench module, first calls the calculation result of the security domain identification layer to determine the current session security domain D. Then, it selects all service instances of this business type registered in each security domain from the service registry as a candidate set. Combining the domain boundary crossing risk and semantic mismatch risk calculated in the previous layer, the candidate set is subjected to hierarchical filtering and sorting. In specific implementation, the domestically developed terminal base first eliminates requests from the current security domain... Service instances exceeding the domain security threshold are prevented from being mistakenly connected to simulation exercise instances by production control domain terminals or to real production instances by simulation terminals. In the remaining instances, this embodiment further combines the comprehensive interface access risk with operational performance indicators to construct a comprehensive cost function.

[0069] ;

[0070] in, This represents the normalized performance cost of service instance e within the most recent statistical window. It is obtained by weighting indicators such as average network latency and failure retry rate. The larger the value, the worse the performance. As a risk priority weight, it is taken close to 1 when security requirements are high, and appropriately reduced when performance requirements are more sensitive. The domestically developed terminal base calculates the requirements for each candidate service instance and its interface. The instance and interface with the minimum cost function value are selected as the access path for this operation, and the semantic mismatch risk component in the comprehensive interface access risk is used as the access path. Automatically determine interface adaptation strength: when When the risk level is below the low-risk threshold, only lightweight parameter mapping and protocol adaptation are performed; when... When the value is in the middle range, preset field completion, field pruning, and return value error handling are enabled; when... When the risk level approaches the high-risk threshold but has not yet exceeded the domain boundary restriction, a strict semantic validation and read-only protection policy should be enforced. For example, prohibiting any state modification operations performed through management interfaces within the production control domain. If all candidate instances within a certain security domain... or If all exceed the allowed limit, the IT innovation terminal base will directly downgrade the corresponding function to an unavailable state or guide the user to switch to a suitable security domain before continuing to operate, in order to avoid being passively reverted to uncontrolled default routing behavior in extreme cases.

[0071] Meanwhile, in order to quantitatively evaluate the routing strategy of service instances in the subsequent performance tuning phase, this embodiment uses a comprehensive cost function in the multi-domain service integration compatibility and inter-authentication module. Build service route scoring Preferably, within a preset statistical time window, the set of all access records actually routed to service instance e is recorded as follows: The j-th access is in the security domain and interface The corresponding comprehensive cost is Then the service routing score will be determined. Defined as:

[0072] ;

[0073] in Optional time decay weights are used to assign higher weight to recently accessed records when needed. Because and These are all normalized indicators. And what is derived from this It can also be constrained to the range [0,1]. The higher the value, the higher the overall risk and performance cost of the service instance in historical access.

[0074] Finally, the scores are determined by matching security domains among the three levels mentioned above. Risk level , , and comprehensive costs Using multi-factor comprehensive analysis and coordinated decision-making as a link, this embodiment constructs an unconventional service routing and interface adaptation mechanism for the address book module, service number module, and workbench module on the same Electron domestic innovation terminal base in a domestic innovation deployment environment where production control domain, simulation exercise domain, and production management domain coexist. On the one hand, it maintains the unified architecture of the interface layer and base layer in the aforementioned steps. On the other hand, it can dynamically adjust the background access path and adaptation strength according to security domain attributes, domestic innovation compatibility, and interface semantic differences, fundamentally avoiding cross-domain misrouting, semantic mismatch, and compatibility anomalies caused by single-index decision-making in existing technologies.

[0075] Furthermore, in the domestically developed terminal performance tuning and compatibility verification module, based on the domestically developed terminal base built in the domestically developed terminal base construction dependency reconstruction module, the mobile application UI interface architecture formed in the mobile application interface architecture rendering scheduling module, and the service integration and mutual authentication mechanism established in the multi-domain service integration compatibility and mutual authentication module, after the domestically developed terminal base completes startup and enters the stable operation phase, the Electron main process and rendering process collect system-level operation indicators directly related to platform performance and compatibility without associating with user identity or recording specific user behavior content. Each collection time is recorded as t, and the CPU utilization, physical memory usage, UI rendering frame time, and service call latency observed on the domestically developed terminal side at that time are recorded as t, respectively. , , and .

[0076] To eliminate the absolute differences between different hardware platforms, the domestic IT terminal performance tuning and compatibility verification module standardizes the above indicators to obtain normalized indicators. , , and For example, CPU utilization can be normalized as follows: set the acceptable upper limit of CPU utilization to... When the observed value Time to take When the observed value exceeds the upper limit, The threshold is truncated to 1; memory usage, rendering frame time, and service call latency can be normalized using their respective acceptable upper limits in a similar manner. This enables the generation of comparable performance metric vectors on domestically developed terminals with different CPU models and physical memory capacities. , , , };

[0077] Based on the above normalized indicators, the domestic IT innovation terminal performance optimization and compatibility verification module constructs an overall performance scoring function for each domestic IT innovation terminal at any given time. This is used to measure the overall performance status of the domestically developed terminal base and its running address book module, service number module, and workbench module at a given moment. Preferably, [the following is used]... Defined as the weighted sum of the normalized indices according to their respective weights:

[0078] ;

[0079] in, , , , These are the weighting coefficients for CPU utilization, memory usage, rendering frame time, and service call latency in the overall performance evaluation, respectively, to meet the following requirements. In practical implementation, the weights can be set according to the different priorities of the business regarding smoothness, end-to-end latency, and resource consumption. For example, in scenarios such as quick search in the address book module and scrolling of the workbench list, the weights of rendering frame time and service latency can be increased; in scenarios such as batch updates in the service account module, the weights of CPU and memory consumption can be appropriately increased. During operation, the domestically developed terminal base periodically calculates the average performance score within the latest time window. And compare it with the preset performance target range, when When the value remains below the target upper limit or approaches 1, it is considered that the running status is approaching the resource bottleneck or there is obvious performance degradation, and it needs to enter the automatic tuning branch.

[0080] Preferably, let L be the number of performance score samples collected within the most recent statistical time window, and let the corresponding sampling time be L. , , , Then the average performance score Defined as:

[0081] ;

[0082] Upon detecting performance score anomalies, the domestically developed terminal performance tuning and compatibility verification module does not simply log the issues. Instead, it aggregates and attributes performance problems by module, scenario, and platform dimensions. Specifically, the domestically developed terminal base maintains its own performance indicator sequences for the address book module, service account module, and workbench module. , , By analyzing the moving average and fluctuation amplitude of these indicator sequences over time, we can identify which modules or interaction scenarios primarily experience resource consumption and response delays. Simultaneously, we can build environmental compatibility based on the dependencies obtained from the refactoring module within the domestically developed terminal base. Service routing scoring in the multi-domain service integration and compatibility interoperability authentication module By comparing historical records with combinations of performance degradation samples and service instance routing scores that have low environmental compatibility, we can extract patterns that lead to consistently high performance scores due to a certain type of domestic operating system version, a certain CPU architecture, and a certain service instance selection strategy. This provides clear clues about the environment and service strategies for the next round of optimization.

[0083] After obtaining the above performance bottleneck attribution results, the domestic IT innovation terminal performance tuning and compatibility verification module performs tuning actions at both the local and pipeline levels of the domestic IT innovation terminal based on a unified performance tuning model. On the local domestic IT innovation terminal, for the high-load modules and scenarios identified through analysis, the Electron main process and rendering process adjust the thread pool size, reduce the execution frequency of some background tasks, and reduce the upper limit of the complexity allowed per frame in the UI rendering scheduler. Or, the UI complexity function defined in the mobile application UI architecture rendering scheduling module. A lazy loading strategy is implemented for the corresponding complex view areas, directly reducing the instantaneous resource pressure on a single terminal; at the same time, the rendering priority is scored in the mobile application interface architecture rendering scheduling module. Weights in , , Fine-tuning was performed to appropriately reduce the rendering priority of non-critical view areas in performance-constrained environments, while increasing the resource allocation for the address book list, service account message list, and workbench task card areas. This ensured the smoothness of the core user interaction path within limited resources.

[0084] At the pipeline construction level, when multiple domestically developed IT terminals are combined on the same platform, they all demonstrate... When the weighting is too high, a regression build task for that platform combination is automatically triggered, more aggressive compilation optimization options are enabled, or the weighting of the dependency refactoring phase is adjusted. , , Adjustments were made to prioritize the local recompilation solution with better performance, replacing the original bridging solution which had lower maintenance costs but mediocre performance, thus forming a closed loop of performance optimization across versions.

[0085] While optimizing performance, the compatibility verification module for domestically developed terminals also needs to perform systematic verification and regression testing on the domestically developed terminal base and its running address book module, service account module, and workbench module from the perspectives of compatibility coverage and stability. This ensures that newly introduced adaptation strategies do not compromise the compatibility of existing platforms. Specifically, a test matrix is ​​constructed targeting multiple domestically developed operating system versions such as UnionTech UOS and Galaxy Kylin, as well as multiple domestic CPU architectures such as Phytium and Loongson. Each combination of operating system version and CPU architecture is designated as a test unit c. A pre-designed set of automated test cases is run within this test unit to verify core business scenarios such as startup, login, address book retrieval, service account message browsing, and workbench task operations. For each test unit c, the number of successful test cases is recorded. and total number of use cases Define the compatibility pass rate of this test unit. for:

[0086] ;

[0087] Furthermore, the compatibility coverage of the entire domestic IT innovation compatibility test matrix was statistically analyzed, and the overall compatibility coverage was defined. The weighted average of the compatibility pass rates for all test units:

[0088] ;

[0089] in, This represents the complete set of domestically developed operating systems and CPU architecture combinations included in the test matrix. The weight of test unit c reflects the proportion or importance of this combination in actual deployment, satisfying the following requirements. In actual implementation, when a new dependency refactoring strategy is introduced, service routing parameters are adjusted, or the UI rendering scheduling algorithm is modified, the build pipeline automatically executes all test cases on each test unit and calculates the updated... and Only when the compatibility pass rate of all test units with higher weights is higher than the preset threshold and the overall compatibility coverage is... New build results are only allowed to be released to the domestic IT application development terminal environment when they are no lower than the historical baseline. For build results with decreased compatibility coverage, the automated regression system automatically marks them as unqualified versions and prevents their release, thus forming a closed loop of compatibility verification based on the test matrix.

[0090] The above formulas are all dimensionless calculations. The formulas are derived from software simulations based on a large amount of collected data to obtain the most recent real-world results. The preset parameters in the formulas are set by those skilled in the art according to the actual situation.

[0091] The above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, in the form of a computer program product.

[0092] Those skilled in the art will recognize that the modules and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and inventive constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0093] In addition, the functional modules in the various embodiments of this application can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module.

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

[0095] In conclusion, the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A base system for compatibility authentication and performance optimization of domestically developed terminals, characterized in that, include: The system includes a domestically developed terminal base construction dependency reconstruction module, a mobile application interface architecture rendering and scheduling module, a multi-domain service integration compatibility and inter-authentication module, a domestically developed terminal performance tuning compatibility verification module, an address book module, a service number module, a workbench module, and signal connections between the modules. The dependency refactoring module for building the domestically developed terminal base is used to drive the cross-platform desktop framework and third-party dependency libraries to complete source code adaptation and dependency refactoring through environment detection and compatibility quantification. The compatibility quantification includes quantifying the compatibility of the operating system kernel, drivers, file system and security policies. The mobile application interface architecture rendering scheduling module is used to create a unified interface shell to divide the navigation area, content display area and auxiliary tool area, and adjust the interface scaling and rendering priority of each view area according to the resolution and the importance of interface elements. The multi-domain service integration compatibility and mutual authentication module is used to identify the current security domain based on environmental feature vectors, perform multi-factor comprehensive analysis on the set of security domains to which the service instance belongs or is accessible and the business semantic category, and construct a comprehensive service routing cost value by combining multiple risk quantities and performance indicators. The multiple risk quantities include domain boundary risk quantity, semantic mismatch risk quantity, and platform compatibility risk quantity. The performance indicators include network latency and failure retry performance indicators. Based on the risk quantities and performance indicators, a comprehensive service routing cost value is constructed, and access paths and interface adaptation strength are controlled hierarchically according to the cost value, so that the front-end interface is unified while the back-end access is controlled by security domain and business semantic domain. The IT innovation terminal performance tuning and compatibility verification module is used to periodically collect system-level indicators to generate a comprehensive performance score. It combines the environmental compatibility score and service routing score to locate performance bottlenecks, and completes performance tuning and compatibility verification through local adjustment, pipeline optimization, and the linkage of the IT innovation compatibility test matrix. The address book module, service account module, and workbench module are derived from existing mobile application platforms. The address book module is used to display and retrieve contact information on domestically developed terminals, the service account module is used to carry service messages and business notification interactions, and the workbench module is used to aggregate business entry points and work order task operation interfaces. The optimal loading order of the three types of modules is determined by measuring the access frequency and initialization time of the address book module, service account module, and workbench module to calculate the startup latency.

2. The domestically developed terminal compatibility interoperability authentication and performance optimization base system according to claim 1, characterized in that: On domestically developed terminals, an environment detection program is deployed to quantify the compatibility of the operating system kernel, drivers, file system, and security policies. Based on this, a standard adaptation path is automatically selected or additional adaptation layers and capability trimming are enabled. The main process, rendering process, and underlying abstraction layer of the cross-platform desktop framework are modified and recompiled under the domestically developed toolchain to generate runtimes adapted to different domestically developed operating systems and domestic processors. At the same time, candidate solutions for recompilation, local replacement, and adaptation bridging are built for each third-party dependency library and script native module. The optimal solution is automatically selected and the dependency refactoring is completed based on the adaptation cost evaluation. The adaptation cost evaluation includes calculating the adaptation cost for each candidate solution. The adaptation cost is obtained by weighting the workload and modification complexity required for source code porting or replacement, the relative impact on running performance, and the subsequent maintenance cost. The candidate solution with the lowest adaptation cost is selected to complete the dependency refactoring.

3. The domestically developed terminal compatibility interoperability authentication and performance optimization base system according to claim 1, characterized in that: The address book, service account, and workbench modules are split into a front-end presentation layer and a back-end access layer. The front-end interface components are reconstructed and a network access adaptation layer is encapsulated. By measuring the access frequency and initialization time, the startup latency is calculated, and the optimal loading order of the three types of modules is determined. A terminal base construction and dependency reconstruction process for the information technology innovation environment is constructed.

4. The domestically developed terminal compatibility interoperability authentication and performance optimization base system according to claim 1, characterized in that: After the information technology innovation terminal base is started according to the optimal loading order defined in claim 1, a unified interface shell is created in the desktop running framework, the window is divided into a navigation area, a content display area and an auxiliary tool area, and corresponding sub-areas are assigned to the address book, service number and workbench. The scaling factor is calculated based on the ratio of the reference resolution to the current resolution and the importance of the interface elements. The position, size and font of the elements are adjusted uniformly to achieve adaptive layout on various domestic display devices. At the same time, the interface is divided into several view areas, and the rendering priority is calculated according to the event triggering frequency, visibility and interaction activity. Within each frame, the redraw area and redraw order are clipped based on the upper limit of view complexity.

5. The domestically developed terminal compatibility interoperability authentication and performance optimization base system according to claim 1, characterized in that: A multi-domain service integration, compatibility, and inter-authentication module is built within the domestically developed terminal base. First, using environmental feature vectors containing only network segment and routing identifiers, security domain labels, certificate trust domains, login role domain attributes, and domestically developed operating system versions and domestic central processing unit architecture identifiers, the matching score of each security domain is calculated, and the security domain or restricted mode to which the current session belongs is automatically determined. Then, during the service registration phase, each backend service instance and its interface is pre-labeled with its own or accessible security domain set, business semantic category, domestically developed adaptation level, interface version, and parameter structure constraint metadata. At runtime, the domain out-of-bounds risk, semantic mismatch risk, and platform compatibility risk are calculated respectively, and together with network latency and failure retry performance indicators, a comprehensive interface access risk and a comprehensive service routing cost are formed.

6. The domestically developed terminal compatibility interoperability authentication and performance optimization base system according to claim 5, characterized in that: In each access request initiated by the address book module, service account module, and workbench module, service instances with domain out-of-bounds risk are first eliminated according to the current security domain. Then, the remaining instances are sorted and routed based on the comprehensive cost value. At the same time, interface adaptation strategies of different strengths are enabled according to the level of semantic mismatch risk, such as lightweight parameter mapping, field completion and pruning, return value fault tolerance, read-only protection, and even function degradation to prohibit access. Within the statistical time window, the service routing score is calculated based on the comprehensive cost value of the actual routing records.

7. The domestically developed terminal compatibility interoperability authentication and performance optimization base system according to claim 1, characterized in that: The system collects system-level metrics such as processor usage, memory usage, interface rendering frame time, and service call latency periodically from the terminal, and converts them into a comprehensive performance score to automatically identify anomalies. It also performs aggregated analysis of bottlenecks based on the address book, service number, workbench, and different combinations of domestically developed operating systems and domestic processors, and uses environmental compatibility scores and service routing scores to pinpoint the source of the problem.

8. The domestically developed terminal compatibility interoperability authentication and performance optimization base system according to claim 7, characterized in that: By adjusting the frequency of local threads and background tasks, reducing the complexity of single-frame rendering, and redistributing the rendering priority of key interface areas to reduce the pressure on a single machine, the pipeline is optimized for compiling and refactoring dependencies based on problematic platform combinations. Furthermore, a domestic IT innovation compatibility test matrix covering multiple operating systems and processor combinations is used as the release threshold, thus forming an integrated closed-loop mechanism for performance tuning and compatibility verification.

Images