Base system for compatibility mutual authentication and performance optimization of credential terminal

Abstract

The invention discloses a credential terminal compatibility mutual authentication and performance tuning base system, and relates to the technical field of credential terminal compatibility mutual authentication and performance tuning bases. The method is used for solving the problems that an address book module, a service number module and a workbench module are difficult to bear in a unified manner under various credential operation systems and domestic CPU architectures, multi-security domain service routing is easy to make mistakes, and terminal performance and compatibility are difficult to collaboratively optimize. According to cooperative work of a credential terminal base construction dependency reconstruction module, a mobile application interface architecture rendering scheduling module and the like, credential terminal base construction and dependency reconstruction are automatically completed based on environment compatibility scores, and the reliability of the credential terminal base is improved on the premise that unauthorized personal information of public places is not collected. And in combination with business module loading sequence optimization, interface zooming and rendering priority control and performance scoring and credential compatibility test matrix closed-loop tuning, the unified interface experience and operation stability under multi-operation system, multi-CPU architecture and multi-security domain deployment are improved.

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, 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 terminal.

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

[0004] 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: 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, and signal connection between modules; The Xinchuang terminal base construction relies on a reconstruction module for completing source code adaptation and dependency reconstruction by environment detection, compatibility quantization, driving a cross-platform desktop framework, and a third-party dependent library. The mobile application interface architecture rendering scheduling module is used to create a unified interface shell layer, divide navigation areas, content display areas, and auxiliary tool areas, and adjust interface scaling and rendering priorities of each view area according to resolution and interface element importance. The multi-domain service integration compatible mutual authentication module is used to identify a current security domain according to an environment feature vector, perform multi-factor comprehensive analysis on a set of security domains to which a service instance belongs or is accessible and a business semantic category, construct a service routing comprehensive generation value based on a plurality of risk quantities and performance indicators, and control access paths and interface adaptation intensities according to the generation value to unify front-end interfaces and control back-end access according to security domains and business semantics. The Xinchuang terminal performance tuning compatibility verification module is used to periodically collect system-level indicators to generate a comprehensive performance score, locate performance bottlenecks in combination with environment compatibility scores and service routing scores, and complete performance tuning and compatibility verification through local adjustment, pipeline optimization, and Xinchuang compatibility test matrix linkage. The address book module, the service number module, and the workbench module are derived from existing mobile application platforms. The address book module is used to display and retrieve contact information on the Xinchuang terminal. The service number module is used to carry service messages and business notification interactions. The workbench module is used to aggregate business entry and work order task operation interfaces.

[0006] In a preferred embodiment, an environment detection program is deployed on the Xinchuang terminal to quantify the compatibility of the operating system kernel, drivers, file systems, and security policies. Based on this, a standard adaptation path is automatically selected or an additional adaptation layer and capability pruning are enabled. The main process, rendering process, and underlying abstraction layer of the cross-platform desktop framework are modified and recompiled under the Xinchuang toolchain to generate a runtime that adapts to different Xinchuang operating systems and domestic processors. Meanwhile, each third-party dependent library and script native module is recompiled, replaced locally, and adapted to bridge candidate solutions. The best solution is automatically selected and dependency reconstruction is completed based on adaptation cost evaluation.

[0007] 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 delay is calculated by measuring access frequency and initialization time to determine the optimal loading order of the three types of modules. A set of terminal base construction and dependency reconstruction processes for the Xinchuang environment is constructed.

[0008] In a preferred embodiment, after the Xinchuang terminal base is started in the aforementioned loading order, a unified interface shell layer 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 the address book, service number and workbench are allocated corresponding sub-areas; a scaling coefficient is calculated based on the ratio of the reference resolution to the current resolution and the importance of the interface elements, and the element position, size and font are uniformly adjusted to realize adaptive layout on multiple domestic display devices; at the same time, the interface is divided into several view areas, the rendering priority is calculated according to the event triggering frequency, visibility and interaction activity, and the view complexity upper limit is combined to clip the redraw area and redraw order in each frame.

[0009] In a preferred embodiment, a multi-domain service integration compatible mutual authentication module is built inside the Xinchuang terminal base, first, an environment feature vector containing only network segment and routing identification, security domain label, certificate trust domain, login role domain attribute, and Xinchuang operating system version and domestic central processing unit architecture identification is used to calculate the matching score of each security domain and automatically determine the security domain or restricted mode to which the current session belongs; then, in the service registration stage, the belonging or accessible security domain set, business semantic category, Xinchuang adaptation level, interface version and parameter structure constraint metadata of each backend service instance and its interface are pre-labeled, the domain crossing risk amount, semantic mismatch risk amount and platform compatibility risk amount are calculated respectively at runtime, and together with the network delay and failure retry performance indicators, the interface access risk comprehensive amount and service routing comprehensive value are formed.

[0010] In a preferred embodiment, in each access request initiated by the address book module, service number module and workbench module, the service instances with domain crossing risk exceeding the limit are first removed according to the current security domain, then the remaining instances are sorted and routed according to the comprehensive value, and different intensity of interface adaptation strategies such as lightweight parameter mapping, field completion and clipping, return value fault tolerance, read-only protection and even function degradation are enabled according to the level of semantic mismatch risk, and the service routing score is calculated according to the comprehensive value based on the actual routing record within the statistical time window.

[0011] In a preferred embodiment, the terminal periodically collects system-level indicators such as processor occupancy, memory occupancy, interface rendering frame time and service call delay, and uniformly converts them into comprehensive performance scores to automatically identify abnormalities, and aggregates the bottlenecks according to the address book, service number, workbench and different combinations of Xinchuang operating system and domestic processors, and locates the problem source combined with the environment compatibility score and service routing score.

[0012] In a preferred embodiment, by locally adjusting the thread and background task frequency, tightening the single-frame rendering complexity, redistributing the rendering priority of the key interface area, triggering optimization compilation and dependency reconstruction weight adjustment on the construction pipeline for problem platform combinations, and taking the Xiongguanneng compatibility test matrix covering multiple operating system and multiple processor combinations as the release threshold, the performance tuning and compatibility verification are integrated into a closed-loop mechanism.

[0013] The technical effects and advantages of the Xiongguanneng terminal compatibility mutual authentication and performance tuning base system of the present application are as follows: The present application introduces environmental compatibility score and dependency adaptation cost function in the dependency reconstruction module of the Xiongguanneng terminal base, making the construction of the Electron Xiongguanneng terminal base no longer dependent on empirical judgment, but automatically selecting local recompilation, domestic library replacement or adaptation layer bridging scheme for different Xiongguanneng operating systems and domestic CPU architectures, ensuring compatibility while considering performance and maintenance cost. In the mobile application interface architecture rendering scheduling module, the loading order of the address book module, service number module and workbench module is optimized in combination with access frequency and initialization time, and through interface scaling and rendering priority control based on resolution and element importance, the limited CPU and graphics rendering capability is preferentially allocated to the area most sensitive to user perception, effectively reducing the first use waiting time and scrolling lag probability. The multi-domain service integration compatibility mutual authentication module, without collecting any unauthorized personal information in public places, takes the security domain matching score and multi-dimensional risk as the link, and integrates the domain boundary risk, interface semantic mismatch risk and Xiongguanneng compatibility risk into a unified decision framework, significantly reducing cross-domain misrouting and compatibility exceptions. The Xiongguanneng terminal performance tuning compatibility verification module forms a closed-loop mechanism of local adjustment and construction regression through performance score and Xiongguanneng compatibility test matrix compatibility coverage, so that terminal performance tuning and multi-platform compatibility verification are carried out cooperatively, improving the overall operation stability and maintainability in large-scale Xiongguanneng deployment scenarios. BRIEF DESCRIPTION OF DRAWINGS

[0014] Figure 1 The module schematic diagram of the Xiongguanneng terminal compatibility mutual authentication and performance tuning base system of the present application.

[0015] Figure 2 The timing diagram of the Xiongguanneng terminal compatibility mutual authentication and performance tuning base system of the present application. DETAILED DESCRIPTION

[0016] With reference to the accompanying drawings, the technical solutions in the embodiments of the present application will be described clearly and completely. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative efforts belong to the scope of the present application.

[0017] Embodiment The application discloses a kind of Xinteng terminal compatibility mutual authentication and performance tuning pedestal system, as shown in Figure Figure 1 Including: Xinteng terminal pedestal construction dependency reconstruction module, mobile application interface architecture rendering scheduling module, multi-domain service integration compatible mutual authentication module, Xinteng terminal performance tuning compatible verification module, address book module, service number module, workbench module, signal connection between each module.

[0018] As shown in Figure Figure 2 In Xinteng terminal pedestal construction dependency reconstruction module, first, Electron framework is selected as cross-platform runtime basis in target Xinteng terminal environment, in UOS, Galaxy Kirin and other Xinteng operating systems and Feiteng, Loongson and other domestic CPU architectures, a series of orderly technical actions are performed on Electron kernel components, third-party dependent libraries and address book module, service number module and workbench module, to complete the construction and dependency reconstruction of Xinteng terminal pedestal.

[0019] Specifically, before Xinteng terminal pedestal construction, first, deploy environment detection program on target Xinteng terminal, collect current operating system kernel version, system call support, graphics and input-output driver loading, file system characteristics and security policy constraints and other information, organize these information into environment feature vector e, and calculate the environment compatibility score of the environment according to the unified environment compatibility score model . Preferably, According to the following formula: ; Wherein, Indicates the support ratio of system call interface required by Electron under environment e, Indicates the available ratio of key drivers such as graphics driver and input device driver in environment e, Indicates the degree of consistency of file system in environment e with the expected behavior of Electron in file monitoring, locking mechanism and other aspects, Indicates the proportion of system capabilities actually allowed to enable under the security policy constraints of environment e. 、 、 、 are the weight coefficients of each index, which are pre-set according to actual deployment requirements and meet .

[0020] During construction, each type of capability is detected item by item in the ChinaSoft terminal through a detection program, and the detection results are normalized to obtain 、 、 、 , which are substituted into the above formula to obtain , and compared with the pre-set compatibility threshold : when , the standard Electron source code adaptation path is adopted in the environment; when , an additional adaptation layer or a part of the capability is automatically enabled in the construction script, for example, a user-mode simulation is added for a missing system call, and a wrapper function is added for abnormal file system behavior to avoid forcibly using an unsupported capability in a low compatibility environment.

[0021] After completing the environment compatibility quantification and determining the adaptation mode, the source code corresponding to the version of Electron is pulled on the construction server, and source-level modifications are made to the Electron main process, rendering process and underlying platform abstraction layer under the constraints of the ChinaSoft terminal tool chain: the ChinaSoft operating system branch is added to the system call branch originally facing Windows or general GNU / Linux, and the API combination actually provided by the ChinaSoft operating system is rewritten for key path calls such as window creation, process management and file monitoring; configuration, compilation and linking are performed in Feiteng and Loongson target architecture environments respectively to generate Electron runtime binaries facing different ChinaSoft operating systems and CPU architectures, realizing the kernel framework of the ChinaSoft terminal base.

[0022] After the Electron kernel adaptation is completed, the dependency library package reconstruction is continued around the third-party libraries and Node native modules relied on by the ChinaSoft terminal base. In the reconstruction process, a dependency adaptation cost function is introduced to quantitatively evaluate different adaptation schemes of each dependency library d in environment e. Preferably, is calculated according to the following formula: ; wherein represents the amount of work and modification complexity required for source code transplantation or replacement of the dependency library d in the environment e, represents the relative degree of influence on the running performance of the ChinaSoft terminal base after selecting the adaptation scheme, represents the cost of subsequent maintenance of the adaptation scheme; all of them are normalized to [0, 1] through historical transplantation experience, code difference analysis and performance evaluation; 、 , The weight coefficients of each cost item are pre-configured according to the trade-off relationship of the project among the transplantation cost, performance and maintainability, and meet .

[0023] Afterwards, in actual implementation, after parsing the project dependency configuration file, a local recompilation, a domestic library replacement and an adaptation layer bridging of each dependency library d are constructed, and the , , of these schemes are respectively estimated, the corresponding is calculated, and the scheme with the smallest cost is automatically selected and written into a build script; for the dependency selected for local recompilation, the source code thereof is pulled in the ChinaSoft compilation environment, recompiled according to the Electron target architecture to generate library files adapted to the instruction set of Feiteng and Longxin, and the dependency path is updated; for the dependency selected for domestic library replacement, the calling is diverted to the implementation of the domestic equivalent library without changing the upper-layer calling interface; for the dependency selected for the adaptation layer bridging scheme, an interface adaptation layer is implemented in the Electron main process, the original calling parameters and return values are format-converted and error-compatible, so that the upper-layer business logic can run on the ChinaSoft terminal base without modification.

[0024] After the reconstruction of the dependency library package is completed, the ChinaSoft terminal base construction dependency reconstruction module performs structured splitting and hanging in the ChinaSoft environment on the address book module, the service number module and the workbench module in the existing mobile application platform of the company. In specific implementation, firstly, the original implementation of the three types of modules is divided into a front-end display layer and a back-end access layer, the address book interface, the service number message interface and the workbench entry interface are reconstructed using HTML5, CSS and JavaScript in the Electron rendering process, and the interface structure and interaction logic thereof are encapsulated as front-end components adapted to the ChinaSoft terminal window management and input system; the calling adaptation layer for accessing the back-end service is established in the Electron main process for the address book module, the service number module and the workbench module, and the HTTP request, WebSocket connection or establishment and maintenance logic of the enterprise-internal special protocol are encapsulated, so that the three types of modules can stably access the original mobile application platform back-end under the constraints of the network stack and security policy of the ChinaSoft operating system. On this basis, the ChinaSoft terminal base construction dependency reconstruction module determines the loading order of the three types of modules in the ChinaSoft terminal base by measuring the access frequency and initialization time consumption of the three types of modules in real business scenarios, and further shortens the perceived waiting time of the user in the first round of use.

[0025] To make the determination process of loading order repeatable and measurable, the address book module, the service number module and the workbench module are recorded as three elements m1, m2, m3 in the set M, the average access frequency of each module in a unit time under a typical business scenario is recorded as , the time required for the module to start initialization to be able to receive user requests is recorded as . After the start of the Xingcheng terminal base, the modules complete initialization in a certain loading order , , . Preferably, the expected weighted start-up delay under the loading order σ is defined as: ; Wherein, , , , represents the cumulative time point when the kth module completes initialization under the loading order σ. k ∈ {1, 2, 3} is the loading position serial number, m represents the module set composed of the address book module, the service number module and the workbench module, represents the module loading order, and represents a permutation of the module set M; under the loading order σ, the three modules loaded in sequence are represents the initialization time required for the module m to start initialization to be able to receive user requests, represents the cumulative time point when the kth module completes initialization under the loading order σ; In actual deployment, the and of the address book module, the service number module and the workbench module are measured on the prototype Xingcheng terminal, all possible loading orders σ of the three modules are enumerated, the corresponding is calculated, and the loading order with the smallest is selected to be written into the start configuration of the Xingcheng terminal base, so that the Electron Xingcheng terminal base initializes the modules with high access frequency and short initialization time in priority after completing kernel initialization and dependency loading, thereby ensuring that the comprehensive waiting time is minimized when the user accesses the address book, the service number and the workbench for the first time.

[0026] ​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.

[0027] 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.

[0028] 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: ; ; 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. : ; 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. For giving higher readability and click area reservation to high importance elements such as address book list title, service number message digest, workbench key entry button, etc. in the scaling process. In the Electron rendering process, the reference size of each element is multiplied by the corresponding , and the actual style sheet adapted to the current resolution of the ChinaSoft terminal is dynamically generated to realize adaptive layout of the same set of UI structure on UOS and Kirin terminals with different resolutions and DPIs.

[0029] Then, after the establishment of the interface scaling model is completed, the mobile application interface architecture rendering scheduling module further constructs a local redrawing strategy based on rendering priority score around the rendering scheduling of the mobile application UI interface architecture to reduce the invalid redrawing overhead when rendering the address book interface, service number message interface and workbench interface on the ChinaSoft terminal and improve the response speed of the key interaction area. To this end, in the rendering process, the UI interface is divided into a plurality of view areas q, each view area corresponding to a relatively independent redrawable unit, such as the address book list area, the service number message stream area, the workbench task card area, etc. At runtime, the rendering priority score of each view area is calculated by collecting the event trigger frequency, visibility and interaction density , and the areas with high scores are preferentially rendered and updated in the scheduling loop.

[0030] Preferably, the rendering priority score of the view area q is defined as: ; wherein, represents the normalized frequency of user input events (such as clicks, scrolling, keyboard input) and data push events (such as new message arrival, task state change) received by the view area q in the latest evaluation time window; V(q) represents the visibility index of the view area q, which is 1 when the area is completely in the visible viewport, the visible proportion between 0 and 1 when partially visible, and 0 when completely invisible; represents the activity index of the interaction carried by the view area q, for example, the normalized value of the number of times the controls in the area are clicked or focused per unit time. The three weight coefficients , , are preset according to product characteristics and experience requirements, satisfying .

[0031] In specific rendering scheduling, the rendering process maintains a view area q and its The priority queue is constituted, and in the period requiring redrawing, the area with high score is selected for DOM update and layer redrawing, and the area with low score and current invisibility is delayed in redrawing or only does lightweight placeholder update, so that the limited CPU and GPU rendering resources are preferentially allocated to the sensitive area of user perception such as address list scrolling, new service number message display and workbench task state change on the XG terminal.

[0032] Meanwhile, in order to avoid excessive rendering in complex scenarios leading to a decrease in rendering frame rate, interface complexity constraints are introduced in the rendering scheduling loop, and the set of view areas planned to be redrawn in each frame is The interface complexity of the current frame is calculated , and only in the case where it is lower than the preset threshold, the full redrawing is performed, otherwise the rendering priority score is trimmed. Preferably, the interface complexity at time t is defined as: ; Wherein, represents the set of view areas planned to be redrawn by the rendering scheduling loop at time t, and c(q) represents the complexity index of view area 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 in the area. In actual implementation, in the Electron rendering process, when the scheduler selects a batch of candidate redrawing areas from queue , first calculate and compare it with the complexity upper limit set according to the CPU and GPU capabilities of the XG terminal, when , the whole redrawing is performed, and when , the area is sequentially excluded from according to the rendering priority from low to high, until the complexity of the remaining area is not more than , and then the actual redrawing is started. In this way, the mobile application UI interface architecture can maintain the smoothness of interface response in complex business scenarios on the XG terminal.

[0033] It should be noted that the Xinda terminal base based on the Electron framework runs in the production control domain, the simulation exercise domain and the production management domain simultaneously. The address book module, the service number module and the workstation module on the same terminal maintain consistency in interface form, but the actual access behind them is a plurality of service instances distributed in different security domains, different Xinda operating system versions and different domestic CPU architectures. These service instances have obvious differences in network latency, stability, Xinda adaptation degree, interface version and authentication strategy, and even are not equivalent in business semantics: the workstation interface in the production control domain directly drives real devices and scheduling systems, the same interface in the simulation 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.

[0034] Under this multi-domain and multi-instance coexistence Xinda deployment pattern, if a single backend address is still statically configured for each terminal, or only a service instance is selected according to a single indicator such as network latency and success rate, the following problems may occur: production terminals are routed to simulation exercise services, causing alarms and instructions to fall into the wrong environment; simulation terminals are routed to real production services, causing exercise instructions to mistakenly enter the production system; or terminals are routed to instances with a backward interface version but optimal short-term performance, causing frequent crashes and compatibility errors on the current Xinda operating system and CPU combination.

[0035] Therefore, in the multi-domain service integration compatible mutual authentication module of the embodiment, a hierarchical comprehensive analysis and decision mechanism oriented to security domains, service instances and interface semantics is constructed inside the Xinda terminal base. Without collecting any unauthorized personal information in public places, three levels of linkage control of current security domain identification, domain semantics and risk quantification, and service routing and interface adaptation execution are sequentially completed, so that the address book module, the service number module and the workstation module maintain interface consistency in the production control domain, the simulation exercise domain and the production management domain, and strictly distinguish real production, simulation exercise and management collaboration in the background access path and interface behavior.

[0036] Specifically, in the security domain identification layer, the Xinda terminal base first extracts a set of environment feature vectors irrelevant to the user's identity around the current running environment, including 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 Xinda operating system version and domestic CPU architecture identifier. These features are uniformly encoded into an environment feature vector. A set of feature weight coefficients is pre-configured for the production control domain, the simulation exercise domain and the production management domain respectively , , , and a matching degree function is defined for each feature in different security domains At runtime, the XJ terminal base calculates the matching scores of the three security domains according to the following formula respectively: , ; wherein, , and respectively represent the matching scores of the current environment with the production control domain, the simulation exercise domain and the production management domain, represents the influence weight of the ith feature on the judgment result in the security domain k, represents the matching degree of the environment feature vector x in the feature dimension.

[0037] Subsequently, the XJ terminal base selects the security domain with the highest score and higher than the preset domain judgment threshold as the security domain identifier of the current session according to the three score values, and when all the scores are lower than the threshold, the current session is downgraded to a restricted mode, the real control interface related to the production control domain is prohibited from being accessed, and only the strictly trimmed management type or read-only interface is allowed to be accessed.

[0038] In the domain semantic and risk quantification layer, the embodiment pre-labels a plurality of groups of metadata related to security domains and semantics for each backend service instance e and each interface p exposed by the instance in the service registration and interface configuration phase, including a security domain set to which the service instance belongs or is allowed to access, an XJ adaptation level label of the service instance, a business semantic category of the interface, an interface version number, and a feature vector of parameter structure and data constraint.

[0039] For the above metadata, the XJ terminal base calculates three types of risk quantities for the current security domain D, the candidate service instance e and its interface p at runtime: the first is the domain boundary risk quantity , which is used to depict whether the current security domain D calls the service instance e in violation of the security domain isolation strategy, when the allowed access domain set of the instance e contains D, a low value close to zero is taken, and when the instance e is not allowed to be used in the current security domain a higher value is taken; the second is the semantic mismatch risk quantity , which is used to depict the deviation between the expected business semantics of the current security domain and the actual semantics of the interface p, for example, when the workstation request under the production control domain is mapped to the simulation interface of the simulation exercise domain, the semantic mismatch risk significantly increases; and the third is the platform compatibility risk quantity , which is used to reflect the adaptation perfection degree and the test coverage degree that has passed of the service instance e on the current XJ operating system and the domestic CPU combination. Based on the above three types of risk quantities, the embodiment constructs an interface access risk comprehensive quantity: ; wherein, , , 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.

[0040] 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. ; 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 of them exceed the upper limit, the Xinchuang terminal base directly degrades the corresponding function to an unusable state or guides the user to switch to a suitable security domain before continuing operation to avoid passive return to uncontrolled default routing behavior in extreme cases.

[0041] Meanwhile, in order to quantitatively evaluate the routing strategy of the service instance in the subsequent performance tuning phase, the embodiment constructs a service routing score in the multi-domain service integration compatible mutual authentication module based on the comprehensive cost function . Preferably, in a preset statistical time window, record all the access record sets actually routed to the service instance e as , wherein the comprehensive cost of the jth access in the security domain and the interface is , and the service routing score is defined as: ; wherein is an optional time decay weight for giving higher weight to recent access records when needed. Since and are both normalized indicators, and the resulting can also be constrained in the interval [0, 1], and the higher the value, the higher the comprehensive risk and performance cost of the service instance in historical access.

[0042] Finally, through the multi-factor comprehensive analysis and linkage decision of the security domain matching score , the risk amount , , and the comprehensive cost as the link between the three levels, the embodiment constructs an unconventional service routing and interface adaptation mechanism for the address book module, the service number module and the workbench module on the same Electron Xinchuang terminal base in the Xinchuang deployment environment coexisting in the production control domain, the simulation exercise domain and the production management domain: on the one hand, it maintains the unified architecture of the interface layer and the base layer in the foregoing steps, and on the other hand, it can dynamically adjust the background access path and the adaptation strength according to the security domain attribute, the Xinchuang compatibility and the interface semantic difference, thereby fundamentally avoiding the cross-domain misrouting, semantic mismatch and compatibility exception problems caused by single indicator decision in the prior art.

[0043] ​Further, in the Xinchuang terminal performance optimization compatibility verification module, based on the Xinchuang terminal base constructed in the 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 mutual authentication module, after the Xinchuang terminal base completes startup and enters the stable running stage, the Electron main process and the rendering process respectively collect system-level running indicators directly related to platform performance and compatibility under the premise of not associating with user identity and not recording specific user behavior content, mark each collection time as t, and mark the CPU utilization, physical memory occupation, UI rendering frame time, and service call delay observed by the Xinchuang terminal side at this time as 、 、 and .

[0044] In order to eliminate the absolute value difference between different hardware platforms, the Xinchuang terminal performance optimization compatibility verification module normalizes the above indicators to obtain normalized indicators 、 、 and . For example, for CPU utilization, it can be normalized as follows: set the acceptable upper limit of CPU utilization to , when the observed value , take , when the observed value exceeds the upper limit, truncate to 1; memory occupation, rendering frame time and service call delay can be normalized in a similar way using their respective acceptable upper limits. Realize that on Xinchuang terminals of different CPU models and different physical memory capacities, the performance indicator vectors , , , } can be compared; On the basis of the above normalized indicators, the Xinchuang terminal performance optimization compatibility verification module constructs an overall performance score function for each Xinchuang terminal running time, which is used to measure the comprehensive performance state of the Xinchuang terminal base and the address book module, service number module and workbench module running thereon at that time. Preferably, is defined as the weighted sum of each normalized indicator according to the weight: ; Wherein, , , , are the weight coefficients of CPU utilization, memory occupation, rendering frame time and service call delay in the comprehensive performance evaluation, which satisfy In implementation, the weights can be set according to the different emphases of the business on fluency, end-to-end delay and resource occupation, for example, the weights of rendering frame time and service delay are increased in the scenarios of quick search in the address book module and scrolling of the workbench list, and the weights of CPU and memory occupation are appropriately increased in the scenario of batch update in the background of the service number module. During running, the China-inspired terminal base periodically calculates the average performance score in the latest time window , and compares it with the preset performance target interval. When the average performance score continuously falls below the upper limit of the target or approaches 1, it is considered that the running state is close to a resource bottleneck or there is obvious performance degradation, and the automatic tuning branch needs to be entered.

[0045] Preferably, L performance score samples are collected in the last statistical time window, and the corresponding sampling time is , , , The average performance score is defined as: ; After detecting the abnormal performance score, the performance tuning and compatibility verification module of the China-inspired terminal does not simply record logs, but aggregates and attributes the performance problems according to the module dimension, scenario dimension and platform dimension. In implementation, the China-inspired terminal base maintains the performance index sequences of the address book module, service number module and workbench module respectively , , , etc. Through the sliding average and fluctuation amplitude analysis of these index sequences in the time dimension, it is identified that resource occupation and response delay mainly concentrate in which type of module or which type of interactive scenario. At the same time, based on the China-inspired terminal base, the environment compatibility obtained in the dependency reconstruction module and the service routing score of the multi-domain service integration compatibility mutual authentication module are constructed, the performance degradation samples are compared with the combination of low environment compatibility and high service instance routing score, and the mode that a certain type of China-inspired operating system version + a certain CPU architecture + a certain service instance selection strategy leads to a continuously high performance score is extracted, providing clear environment and service strategy clues for the next round of tuning.

[0046] 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.

[0047] 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.

[0048] 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: ; And further statistics on the compatibility coverage of the whole signal creation compatibility test matrix, define the overall compatibility coverage The weighted average of the compatibility pass rate of all test units: ; Where, Indicates the set of all signal creation operating systems and CPU architecture combinations contained in the test matrix, The weight of test unit c, which reflects the proportion or importance of the combination in actual deployment, satisfies In the actual implementation process, when a new dependency refactoring strategy is introduced, the service routing parameters are adjusted, or the UI rendering scheduling algorithm is modified, the construction pipeline automatically executes all use cases on each test unit, calculates the updated And Only when the compatibility pass rate of all test units with high weights is higher than the preset threshold and the overall compatibility coverage Is not lower than the historical baseline, the new construction result is allowed to be released to the signal creation terminal environment; for the construction result with decreased compatibility coverage, the automation regression system automatically marks it as an unqualified version and prevents it from being released, thereby forming a compatibility verification closed loop based on the test matrix.

[0049] The above formulas are dimensionless numerical calculations, and the formulas are obtained by software simulation of a large amount of data to obtain the latest real situation. The preset parameters in the formula are set by a person skilled in the art according to the actual situation.

[0050] The above embodiments can be realized wholly or partially by software, hardware, firmware or any combination thereof. When realized by software, the above embodiments can be realized wholly or partially in the form of a computer program product.

[0051] Those skilled in the art can realize that the modules and algorithm steps of the examples described in combination with the embodiments disclosed herein can be realized by electronic hardware or a combination of computer software and electronic hardware. Whether the functions are realized in hardware or software depends on the specific application of the technical solution and the constraints of the invention. Professional technicians can use different methods to realize the described functions for each specific application, but such implementation should not be considered beyond the scope of the present application.

[0052] In addition, the functional modules in each embodiment of the present application can be integrated in one processing module, or each module can exist physically alone, or two or more modules can be integrated in one module.

[0053] The above merely provides the specific implementation of the present application, but the protection scope of the present application is not limited to this. Any person skilled in the art can easily think of the changes or replacements within the technical range disclosed by the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.

[0054] Finally, the above merely provides the preferred embodiments of the present application, but is not used to limit the present application. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included in the protection scope of the present application.

Claims

1. A Xinyi terminal compatibility mutual authentication and performance tuning base system, characterized in that, Comprise: Xin creation terminal base construction dependent reconfiguration module, mobile application interface architecture rendering scheduling module, multi-domain service integration compatible mutual authentication module, Xin creation terminal performance tuning compatible verification module, address book module, service number module, workbench module, signal connection between modules; Xin creation terminal base construction dependent reconfiguration module is used for completing source code adaptation and dependent reconfiguration by environment detection and compatibility quantization driving cross-platform desktop framework and third-party dependent library; Mobile application interface architecture rendering scheduling module is used for creating unified interface shell layer, dividing navigation area, content display area and auxiliary tool area, and adjusting interface scaling and rendering priority of each view area according to resolution and interface element importance; Multi-domain service integration compatible mutual authentication module is used for identifying current security domain according to environment feature vector, performing multi-factor comprehensive analysis on service instance belonging or accessible security domain set and business semantic category, constructing service routing comprehensive generation value according to multiple risk quantity and performance index, and controlling access path and interface adaptation intensity according to the generation value, so that front-end interface is unified and back-end access is controlled according to security domain and business semantic domain; Xin creation terminal performance tuning compatible verification module is used for periodically collecting system-level indicators to generate comprehensive performance score, combining environment compatibility score and service routing score to locate performance bottleneck, and completing performance tuning and compatibility verification through local adjustment, pipeline optimization and Xin creation compatibility test matrix linkage; Address book module, service number module and workbench module are derived from existing mobile application platform, address book module is used for displaying and retrieving contact information on Xin creation terminal, service number module is used for carrying service message and business notification interaction, and workbench module is used for aggregating business portal and work order task operation interface.

2. The system according to claim 1, wherein the system is characterized in that: An environment detection program is deployed on Xin creation terminal to quantify compatibility of operating system kernel, driver, file system and security policy, so as to automatically select standard adaptation path or enable additional adaptation layer and capability pruning, source code modification and recompilation of main process, rendering process and underlying abstraction layer of cross-platform desktop framework under Xin creation tool chain to generate runtime adapted to different Xin creation operating systems and domestic processors; meanwhile, recompilation, local replacement and adaptation bridge candidate scheme of each third-party dependent library and script native module are constructed, and the optimal one is automatically selected and dependent reconfiguration is completed according to adaptation cost evaluation.

3. The system according to claim 1, wherein the system further comprises a compatibility authentication and performance tuning base station. Address book, service number and workbench modules are split into front-end display layer and back-end access layer, front-end interface components are reconstructed and network access adaptation layer is encapsulated, start-up delay is calculated by measuring access frequency and initialization time consumption, optimal loading order of three types of modules is determined, and a set of terminal base construction and dependent reconfiguration process for Xin creation environment is constructed.

4. The system according to claim 1, wherein the system is characterized in that: After Xin creation terminal base is started in the foregoing loading order, a unified interface shell layer is created in the desktop running framework, windows are divided into navigation area, content display area and auxiliary tool area, and address book, service number and workbench are allocated corresponding sub-areas; The scaling factor is calculated based on the ratio of the reference resolution and the current resolution and the importance of the interface elements, and the element position, size and font are uniformly adjusted to achieve adaptive layout on various domestic display devices. Meanwhile, the interface is divided into several view areas, and the rendering priority is calculated according to the event triggering frequency, visibility and interactive activity. In each frame, the view complexity limit is combined to clip the redraw area and redraw order.

5. The system according to claim 1, wherein the system is characterized in that: A multi-domain service integration compatible mutual authentication module is constructed inside the Xinchuang terminal base. First, an environment feature vector containing only network segment and routing identification, security domain label, certificate trust domain, login role domain attribute, Xinchuang operating system version and domestic central processor architecture identification is used to calculate the matching score of each security domain and automatically determine the security domain or restricted mode to which the current session belongs. Then, in the service registration stage, the belonging or accessible security domain set, business semantic category, Xinchuang adaptation level, interface version and parameter structure constraint metadata of each backend service instance and its interface are pre-labeled. The domain boundary risk, semantic mismatch risk and platform compatibility risk are calculated respectively, and together with the network delay and failure retry performance indicators, they form the interface access risk comprehensive amount and service routing comprehensive value.

6. The system according to claim 5, wherein the system further comprises a compatibility authentication and performance optimization base station. In each access request initiated by the address book module, service number module and workbench module, the service instances with domain boundary risk exceeding the limit are first removed according to the current security domain, and then the remaining instances are sorted and routed according to the comprehensive value. At the same time, according to the level of semantic mismatch risk, different intensity of interface adaptation strategies such as lightweight parameter mapping, field completion and trimming, return value fault tolerance, read-only protection and even function degradation are enabled, and the actual routing records are calculated for service routing score according to the comprehensive value within the statistical time window.

7. The system according to claim 1, wherein the system is characterized in that: The terminal periodically collects system-level indicators such as processor occupancy, memory occupancy, interface rendering frame time and service call delay, and uniformly converts them into comprehensive performance score to automatically identify abnormalities. According to the address book, service number, workbench and different combinations of Xinchuang operating system and domestic processor, the bottleneck is aggregated and analyzed, and the problem source is located combined with the environment compatibility score and service routing score.

8. The system according to claim 7, wherein the system further comprises a compatibility authentication and performance optimization base station. By adjusting the frequency of local adjustment threads and background tasks, tightening the rendering complexity of single frame, and redistributing the rendering priority of key interface areas, the single machine pressure is reduced. On the construction pipeline, optimization compilation and dependency reconstruction weight adjustment are triggered for problem platform combinations, and the Xinchuang compatibility test matrix covering multiple operating systems and multiple processor combinations is used as the release threshold, forming an integrated closed-loop mechanism for performance tuning and compatibility verification.

Images