A service capability trace-back method based on compile-time bytecode analysis
By analyzing bytecode files during compilation and tracing client API call behavior in reverse, the problem of insufficient awareness of API call behavior on the server side is solved, enabling efficient API management and upgrade support.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- CHONGQING LIFAN VEHICLE RESEARCH INSTITUTE CO LTD SHANGHAI BRANCH
- Filing Date
- 2026-02-25
- Publication Date
- 2026-06-05
Smart Images
Figure CN122152555A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of API call management technology, and in particular to a method for tracing back service capabilities based on compile-time bytecode analysis. Background Technology
[0002] In a client-server (CS) architecture, the server typically provides various APIs (Application Programming Interfaces) to offer functionalities or services to different clients. Due to the inherent characteristics of the CS architecture, the server primarily responds to client requests passively during operation, making it difficult to proactively perceive the actual usage of various API capabilities by specific clients. In scenarios with a large number of clients, wide distribution, and significant version differences, the server often cannot accurately determine which clients are calling specific APIs, their call frequency, or changes in call behavior.
[0003] The aforementioned issues are particularly prominent during API lifecycle management. When the server upgrades, adjusts, or takes an API offline, the lack of effective awareness of the actual usage by clients can easily lead to an inability to accurately pinpoint the scope of affected clients. Consequently, the only solutions are broadcast notifications, prolonged compatibility with old interfaces, or reliance on manual confirmation, which increases system maintenance costs and technical debt, and also reduces the efficiency and security of API evolution.
[0004] To compensate for the server's lack of awareness of client-side API calls, existing technologies typically employ methods such as log analysis, client-side event tracking, or manual statistics to collect and analyze API usage. However, these solutions generally suffer from the following shortcomings: On the one hand, logging and event tracking solutions typically rely on developers manually embedding statistical logic on the client or server side, resulting in high implementation and maintenance costs, and data incompleteness due to omissions or inconsistent implementations. On the other hand, log data is often lagging, requiring offline analysis or manual aggregation, making it difficult to reflect the actual usage status of API capabilities by clients in real time and accurately. Furthermore, manual statistical methods rely on human organization and judgment, which is inefficient and difficult to adapt to complex scenarios with large-scale, multi-version clients coexisting.
[0005] Therefore, existing technologies lack a technical means to effectively track and manage the usage of client API capabilities by the server in a client-server architecture, so as to support the server's comprehensive awareness of API usage relationships and provide a reliable basis for API upgrades, governance and evolution.
[0006] The drawbacks of existing technologies are that the server has difficulty in perceiving the actual usage of the API capabilities provided by the client, which leads to difficulties in API lifecycle management and inaccurate assessment of the impact of upgrades and adjustments. Summary of the Invention
[0007] This invention provides a service capability retrospective tracing method based on compile-time bytecode analysis, enabling the server to obtain client call information for various API capabilities, thereby achieving effective perception and management of API usage.
[0008] To achieve the above objectives, this invention provides a service capability retrospective tracing method based on compile-time bytecode analysis, the key of which includes the following steps: Step 1: Construct a service capability retrospective tracing system based on compile-time bytecode analysis. This service capability retrospective tracing system includes a bytecode acquisition module, a bytecode analysis module, and a service capability recording module set on the user end. Step 2: The bytecode acquisition module acquires the bytecode file from the compilation artifacts during the compilation process of the user application and passes it to the bytecode analysis module; Step 3: The bytecode analysis module traverses and parses the bytecode file, analyzes the client's call behavior to the server's API capabilities at the bytecode level, extracts the API service capability call information, and passes it to the service capability recording module; Step 4: The service capability recording module organizes the API service capability call information and generates a tracking data file that represents the correspondence between the client and the API service capability.
[0009] Through the above design, this invention establishes a tracking mechanism for service capability usage relationships during client-server interactions. This enables the server to obtain client call information for various application programming interface (API) capabilities, thereby achieving effective perception and management of API usage. With this solution, the server can accurately grasp the service capability usage status of different clients without relying on manual statistics or sporadic log analysis, providing technical support for API upgrades, evolution, and maintenance.
[0010] In addition, the present invention can reduce the maintenance costs caused by manual data collection and analysis to a certain extent, improve the efficiency of server-side management of API capability usage, and thus improve the problem of the lack of effective means for server-side to track client call relationships in the prior art.
[0011] Preferably, the API service capabilities provided by the server are defined using a hierarchical identification method, and the API service capability identifier includes at least the service domain, service subdomain, and capability identifier.
[0012] Preferably, the client invokes server-side capabilities through a unified API call entry point.
[0013] This invention establishes a mapping between client and service capability usage based on service capability identifiers. Instead of performing forward statistics on service capabilities based on client behavior, this invention traces client usage of service capabilities from the perspective of server-side capabilities.
[0014] Preferably, during the compilation or building phase of the client application, the bytecode acquisition module intercepts the build process through the build tool extension mechanism, thereby obtaining the bytecode file in the compilation output.
[0015] Preferably, the bytecode analysis module is used to traverse and parse the bytecode file to identify the API categories, methods, and method call instructions in the bytecode file; The API category is a classification of APIs based on their functions or uses, such as: data access APIs, business logic APIs, third-party service APIs, and system management APIs. API methods are specific functionalities provided by the API, including but not limited to one or more combinations of methods such as GET method for retrieving resources, POST method for creating resources, PUT method for updating resources, and DELETE method for deleting resources.
[0016] The bytecode analysis module performs unified processing on the bytecode file without affecting the original construction result of the bytecode file.
[0017] Preferably, the bytecode analysis module further parses the parameter loading instruction corresponding to the identified method call instruction, and extracts the corresponding API service capability identifier parameters from the parameter loading instruction, including service domain parameters, service subdomain parameters, and capability identifier parameters, thereby determining the client's usage relationship of API service capabilities.
[0018] Preferably, when the API service capability identifier is passed in the form of a variable or constant, the bytecode analysis module restores the API service capability identifier by analyzing the constant pool, field references and method parameter passing relationships in the bytecode context, thereby obtaining complete API service capability identifier information.
[0019] Preferably, the service capability recording module organizes and records the API service capability call information according to a preset data structure, thereby generating a tracking data file; The data structure includes an application identifier, application version information, and service capability usage details, wherein the service capability usage details include at least the API service capability identifier and the corresponding call location.
[0020] Preferably, the service capability retrospective tracking system is also connected to a cloud processing system, which is equipped with a cloud processing module and a cloud visualization module. The cloud processing module is used to aggregate, clean, and deduplicate tracking data files from various clients or application versions, and then send the processed tracking data to the cloud visualization module. The cloud-based visualization module is used to generate visualization results that display the usage of API service capabilities based on the processed tracking data, so as to support the server in querying, analyzing and managing API usage relationships.
[0021] This invention establishes the usage relationship between service capabilities and clients from the perspective of service capabilities, so as to support the server's decision-making on upgrading, adjusting or taking offline service capabilities.
[0022] The beneficial effects of this invention are: 1. Achieving effective awareness of client API usage by the server: This invention analyzes bytecode during the application construction phase to establish a correspondence between client and server API capabilities, enabling the server to obtain the actual usage of APIs without relying on active reporting from the client, thereby overcoming the problem of the server lacking awareness of client call behavior in the CS architecture.
[0023] 2. Reduce maintenance costs associated with manual event tracking and statistics: Compared to existing solutions that rely on manual event tracking or statistics, this invention uses automated bytecode analysis to collect service capability call information, reducing reliance on manual intervention by developers, lowering the risk of missed event tracking and inconsistencies, and improving overall maintenance efficiency.
[0024] 3. Avoid intrusion into business operation logic and performance impact: This invention completes the collection of service capability tracking information during the compilation or build phase, without the need to insert additional logic during application runtime, thereby avoiding runtime performance overhead and impact on business code execution paths, and improving system stability and controllability.
[0025] 4. Supports unified tracking and management in multi-version and multi-module scenarios: By uniformly parsing bytecode files in the build process, this invention can be applied to application build scenarios with different modules and versions, which is beneficial for centralized collection and unified management of service capability usage in complex projects or multi-client environments.
[0026] 5. Improve the accuracy and controllability of API lifecycle management: By systematically tracking the usage relationships of service capabilities, this invention can provide a reliable basis for API upgrades, adjustments, or decommissioning, reducing compatibility risks caused by unclear calling relationships, thereby improving the problem of API lifecycle management relying on experience judgment in the prior art.
[0027] 6. Excellent scalability and adaptability: Based on bytecode-level analysis, this invention can adapt to different programming language compilation results and build tool implementations, making it easy to extend support for new service capability identification rules or tracking dimensions without changing the overall solution, thereby improving the versatility and adaptability of the solution. Attached Figure Description
[0028] Figure 1 This is a flowchart of the method of the present invention in an embodiment; Figure 2 This is a system architecture diagram from an embodiment. Detailed Implementation
[0029] The present invention will be further described in detail below with reference to the accompanying drawings and specific examples. The following embodiments or drawings are used to illustrate the present invention, but are not intended to limit the scope of the present invention.
[0030] like Figure 1 , Figure 2 As shown, a service capability retrospective tracing method based on compile-time bytecode analysis includes the following steps: Step 1: Construct a service capability retrospective tracing system based on compile-time bytecode analysis. This service capability retrospective tracing system includes a bytecode acquisition module, a bytecode analysis module, and a service capability recording module set on the user end. Step 2: The bytecode acquisition module acquires the bytecode file from the compilation artifacts during the compilation process of the user application and passes it to the bytecode analysis module; Step 3: The bytecode analysis module traverses and parses the bytecode file, analyzes the client's call behavior to the server's API capabilities at the bytecode level, extracts the API service capability call information, and passes it to the service capability recording module; Step 4: The service capability recording module organizes the API service capability call information and generates a tracking data file that represents the correspondence between the client and the API service capability.
[0031] The service capability recording module generates a complete tracking data file at the end of the construction process and uploads it to the cloud processing system. The cloud processing system aggregates, cleans, and deduplicates the tracking data, and generates a visualization result to show the usage of API service capabilities, supporting the server-side query, analysis, and management of API usage relationships.
[0032] This invention establishes the usage relationship between service capabilities and clients from the perspective of service capabilities, so as to support the server's decision-making on upgrading, adjusting or taking offline service capabilities.
[0033] Through the above design, this invention establishes a tracking mechanism for service capability usage relationships during client-server interactions. This enables the server to obtain client call information for various application programming interface (API) capabilities, thereby achieving effective perception and management of API usage. With this solution, the server can accurately grasp the service capability usage status of different clients without relying on manual statistics or sporadic log analysis, providing technical support for API upgrades, evolution, and maintenance.
[0034] The API service capabilities provided by the server are defined using a hierarchical identification method. The API service capability identifier includes at least the service domain, service subdomain, and capability identifier.
[0035] For example, the identifier for a certain service capability is: user.profile.queryUserInfo Here, user represents the service domain, profile represents the service subdomain, and queryUserInfo represents the specific service capabilities.
[0036] The client invokes server-side capabilities through a unified API call entry point. For example, the following calling method can be defined in the business code: UserApi.queryUserInfo(userId); The corresponding methods in the UserApi class are defined as follows: public class UserApi { public static Object queryUserInfo(String userId) { return ApiClient.call( "user", "profile", "queryUserInfo", userId );} } During the compilation or building phase of the client application, the bytecode acquisition module intercepts the build process through the build tool extension mechanism, thereby obtaining the bytecode file in the compilation output.
[0037] The bytecode analysis module is used to traverse and parse the bytecode file to identify the API categories, methods, and method call instructions in the bytecode file; The API category is a classification of APIs based on their functions or uses, such as: data access APIs, business logic APIs, third-party service APIs, and system management APIs. API methods are specific functionalities provided by the API, including but not limited to one or more combinations of methods such as GET method for retrieving resources, POST method for creating resources, PUT method for updating resources, and DELETE method for deleting resources.
[0038] For example, when parsing the queryUserInfo method of the UserApi class, the bytecode analysis module detects a call instruction to the unified API call method in its bytecode instructions, such as INVOKESTATIC ApiClient.call.
[0039] The bytecode analysis module further parses the parameter loading instruction corresponding to the identified method call instruction, and extracts the corresponding service domain parameter "user", service subdomain parameter "profile", and capability identifier parameter "queryUserInfo" from the parameter loading instruction to determine the client's usage relationship of API service capabilities.
[0040] When the API service capability identifier is passed in the form of a variable or constant, the bytecode analysis module restores the API service capability identifier by analyzing the constant pool, field references and method parameter passing relationships in the bytecode context, thereby obtaining complete API service capability identifier information.
[0041] After completing the bytecode analysis, the service capability recording module organizes and records the API service capability call information according to a preset data structure, thereby generating a trace data file; The data structure includes an application identifier, application version information, and service capability usage details, wherein the service capability usage details include at least the API service capability identifier and the corresponding call location. For example: { "appId": "com.example.app", "appVersion": "1.2.3", "abilities": [ { "serviceDomain": "user", "serviceSubDomain": "profile", "abilityCode": "queryUserInfo", "callerClass": "UserApi", "callerMethod": "queryUserInfo" } ] } Through the above embodiments, the client's usage of service capabilities can be obtained during the application construction phase without intruding on the client's runtime logic, making the service capability retrospective tracing solution feasible and verifiable.
[0042] The technical features of this invention include: 1. Based on the service capability identifier, establish a mapping of usage relationship between the client and the service capability: From the perspective of the server capability, track the client's usage of the service capability in reverse, rather than from the forward statistics of the client behavior.
[0043] 2. Obtain service capability call information during the application compilation or build phase: This involves acquiring service capability call relationships during the build phase, without relying on runtime or online data. This avoids runtime performance overhead, data loss, and upload failures.
[0044] 3. Identify service capability invocation behavior by parsing method call instructions in bytecode: Instead of analyzing the source code, it directly parses classes, methods, and call instructions at the bytecode level. This approach is independent of language features, unaffected by obfuscation, and works across modules and source code origins.
[0045] 4. Based on the call context, the service capability identifier is restored or deduced to generate structured data describing the correspondence between the client and the service capability: When the service capability identifier exists in the form of variables, constant combinations, or placeholders, it is parsed and restored through the bytecode context. This is not a simple string matching process and can handle constant references, constructor parameters, and multi-level method passing.
[0046] 5. In multi-module, multi-project construction scenarios, uniformly collect and merge service capability usage information: This is geared towards real large-scale projects, not demonstration-level solutions.
[0047] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.
Claims
1. A service capability retrospective tracing method based on compile-time bytecode analysis, characterized in that, Includes the following steps: Step 1: Construct a service capability retrospective tracing system based on compile-time bytecode analysis. This service capability retrospective tracing system includes a bytecode acquisition module, a bytecode analysis module, and a service capability recording module set on the user end. Step 2: The bytecode acquisition module acquires the bytecode file from the compilation artifacts during the compilation process of the user application and passes it to the bytecode analysis module; Step 3: The bytecode analysis module traverses and parses the bytecode file, analyzes the client's call behavior to the server's API capabilities at the bytecode level, extracts the API service capability call information, and passes it to the service capability recording module; Step 4: The service capability recording module organizes the API service capability call information and generates a tracking data file that represents the correspondence between the client and the API service capability.
2. A service capability retrospective tracing method based on compile-time bytecode analysis as described in claim 1, characterized in that: The API service capabilities provided by the server are defined using a hierarchical identification method. The API service capability identifier includes at least the service domain, service subdomain, and capability identifier.
3. A service capability retrospective tracing method based on compile-time bytecode analysis as described in claim 1, characterized in that: The client invokes server capabilities through a unified API call entry point.
4. A service capability retrospective tracing method based on compile-time bytecode analysis as described in claim 1, characterized in that: During the compilation or build phase of the client application, the bytecode acquisition module intercepts the build process through the build tool extension mechanism, thereby obtaining the bytecode file in the compilation output.
5. A service capability retrospective tracing method based on compile-time bytecode analysis as described in claim 1, characterized in that: The bytecode analysis module is used to traverse and parse the bytecode file to identify the API categories, methods, and method call instructions in the bytecode file; The API category is a classification of APIs based on their functions or uses, such as: data access APIs, business logic APIs, third-party service APIs, and system management APIs. API methods are specific functionalities provided by the API, including but not limited to one or more combinations of methods such as GET method for retrieving resources, POST method for creating resources, PUT method for updating resources, and DELETE method for deleting resources.
6. A service capability retrospective tracing method based on compile-time bytecode analysis as described in claim 5, characterized in that: The bytecode analysis module further parses the parameter loading instruction corresponding to the identified method call instruction, and extracts the corresponding API service capability identifier parameters from the parameter loading instruction, including service domain parameters, service subdomain parameters, and capability identifier parameters, thereby determining the client's usage relationship of API service capabilities.
7. A service capability retrospective tracing method based on compile-time bytecode analysis as described in claim 2 or 6, characterized in that: When the API service capability identifier is passed in the form of a variable or constant, the bytecode analysis module restores the API service capability identifier by analyzing the constant pool, field references and method parameter passing relationships in the bytecode context, thereby obtaining complete API service capability identifier information.
8. A service capability retrospective tracing method based on compile-time bytecode analysis as described in claim 1, characterized in that: The service capability recording module organizes and records the API service capability call information according to a preset data structure, thereby generating a tracking data file; The data structure includes an application identifier, application version information, and service capability usage details, wherein the service capability usage details include at least the API service capability identifier and the corresponding call location.
9. A service capability retrospective tracing method based on compile-time bytecode analysis as described in claim 1, characterized in that: The service capability retrospective tracking system is also connected to a cloud processing system, which is equipped with a cloud processing module and a cloud visualization module. The cloud processing module is used to aggregate, clean, and deduplicate tracking data files from various clients or application versions, and then send the processed tracking data to the cloud visualization module. The cloud-based visualization module is used to generate visualization results that display the usage of API service capabilities based on the processed tracking data, so as to support the server in querying, analyzing and managing API usage relationships.