A processing method and electronic device

Abstract

The application discloses a processing method and an electronic device, the method comprising: obtaining target source code information currently in a display state; determining a first submodule to which the target source code information belongs among a plurality of submodules contained in a target project; determining first call relationship information according to the submodule; the first call relationship information is corresponding information capable of at least representing a call relationship of the first submodule to other submodules of the target project, which is extracted from source code call relationship information, and the source code call relationship information is information for representing a call relationship among a plurality of submodules, which is generated in advance based on a dynamic call process among the plurality of submodules contained in the target project; and performing display processing on the first call relationship information on a current source code interface corresponding to the target source code information.

Description

Technical Field

[0001] This application belongs to the field of software development technology, and in particular relates to a processing method and an electronic device. Background Technology

[0002] Currently, in an IDE (Integrated Development Environment), developers can switch source code files by clicking on the function name of the called function in the source code, in order to understand the source code or check for errors. For example, see... Figure 1 For example, if the AppController.java file calls the getAppInfoListAndClass function, then developers can click on the function name in the AppController.java file in the IDE to jump to the source code file IAppInfoServicePA.java that defines the getAppInfoListAndClass function.

[0003] However, in large projects, a project is often divided into several sub-modules, each of which runs independently, such as... Figure 2 As shown, the various sub-modules call each other through network protocols (usually HTTP), and the call relationship information is not directly written in the source code. This makes it impossible for developers to switch source code files in the IDE based on the call relationship between the source code. Summary of the Invention

[0004] Therefore, this application discloses the following technical solution:

[0005] A processing method, the method comprising:

[0006] Retrieve the target source code information that is currently being displayed;

[0007] Determine the first submodule to which the target source code information belongs among the multiple submodules contained in the target project;

[0008] First call relationship information is determined based on the first sub-module; the first call relationship information is: information extracted from the source code call relationship information that can at least be used to characterize the call relationship between the first sub-module and other sub-modules of the target project; the source code call relationship information is information pre-generated to characterize the call relationship between the multiple sub-modules, based at least on the dynamic call process between the multiple sub-modules contained in the target project.

[0009] On the current source code interface corresponding to the target source code information, the first call relationship information is displayed.

[0010] Optionally, before obtaining the target source code information currently in the display state, the method further includes:

[0011] Start the multiple sub-modules included in the target project to run the multiple sub-modules;

[0012] Based at least on the dynamic calling process between the multiple sub-modules at runtime, the source code calling relationship information between the multiple sub-modules is generated.

[0013] Optionally, generating the source code call relationship information among the multiple sub-modules, at least based on the dynamic calling process among the multiple sub-modules at runtime, includes:

[0014] For each of the aforementioned sub-modules' startup events, a service proxy is started synchronously.

[0015] The service proxy is used to record dynamic call information between various sub-modules during operation;

[0016] Based on the dynamic call information recorded by the service proxy, the call relationship between the multiple sub-modules is determined by static source code analysis of the source code files corresponding to each sub-module;

[0017] Generate a source code call relationship graph that matches the call relationships between the multiple sub-modules, and use it as the source code call relationship information.

[0018] Optionally, the synchronous startup service agent includes:

[0019] Simultaneously start the local agent corresponding to each submodule and the global agent corresponding to each submodule;

[0020] The method of using the service proxy to record dynamic call information between various sub-modules during operation includes:

[0021] Each of the aforementioned local proxies is used to record the call information of each function contained in the corresponding submodule during the running process;

[0022] The global proxy is used to record the call information between various sub-modules.

[0023] Optionally, in a preset development environment, the target project's multiple sub-modules and the service agent are started.

[0024] Optionally, the source code call relationship information includes call relationship information represented by a source code call relationship graph, wherein the first call relationship information includes a relationship subgraph extracted from the source code call relationship graph that can at least be used to represent the call relationship between the first submodule and other submodules of the target project;

[0025] The process of displaying the first call relationship information on the current source code interface corresponding to the target source code information includes:

[0026] The icons of the relationship subgraph are displayed in a preset area of ​​the current source code interface;

[0027] Alternatively, the relational subgraph can be displayed in a preset area of ​​the current source code interface.

[0028] Optionally, after displaying the first call relationship information, the method further includes:

[0029] In response to detecting a target operation on the first call relationship information, the current source code interface is switched to the source code interface of the corresponding source code file of the second submodule indicated by the target operation.

[0030] Optionally, the source code call relationship graph includes: the call or called relationship between different sub-modules, the function identifier of the function called in the corresponding other sub-module when a sub-module calls other sub-modules, and the file identifier of the source code file to which the called function belongs;

[0031] The step of switching the current source code interface to the source code interface of the corresponding source code file of the second submodule indicated by the target operation in response to detecting a target operation on the first call relationship information includes:

[0032] In response to a first operation on the icon displayed in the preset area, the current source code interface is switched to the source code interface of the corresponding source code file of the second sub-module indicated by the first operation; the first operation includes: operating the icon to expand the relationship sub-graph, and selecting the file identifier of the corresponding source code file of the second sub-module to be displayed in the expanded relationship sub-graph.

[0033] Alternatively, in response to a second operation on the relational subgraph displayed in the preset area, the current source code interface is switched to the source code interface of the corresponding source code file of the second submodule indicated by the second operation; the second operation includes: selecting the file identifier of the corresponding source code file of the second submodule to be displayed in the relational subgraph displayed in the preset area.

[0034] Optionally, before generating the source code call relationship information between the multiple sub-modules based at least on the dynamic call process between the multiple sub-modules at runtime, the method further includes:

[0035] Determine whether the source code files corresponding to each sub-module of the target project contain source code information indicating the calling relationship between different sub-modules;

[0036] If not included, the step of generating source code call relationship information between the multiple sub-modules is triggered, based at least on the dynamic calling process between the multiple sub-modules at runtime.

[0037] An electronic device, comprising:

[0038] Memory, used to store at least one set of computer instructions;

[0039] A processor for implementing the processing method described in any of the preceding descriptions by invoking and executing the instruction set stored in the memory.

[0040] As can be seen from the above scheme, the processing method and electronic device disclosed in this application, at least based on the dynamic calling process between multiple sub-modules contained in the target project, pre-generate source code calling relationship information to represent the calling relationship between multiple sub-modules of the target project, and then, for the target source code information in the display state, determine the first calling relationship information from the above source code calling relationship information according to the first sub-module to which it belongs in the target project. The first calling relationship information is the corresponding information extracted from the source code calling relationship information that can at least be used to represent the calling relationship of the first sub-module to other sub-modules of the target project, and display the first calling relationship information on the current source code interface.

[0041] This application generates source code call relationship information between sub-modules based on the dynamic call process between at least the sub-modules of the target project. Based on this, it extracts the matching part from the generated source code call relationship information of the target source code information in the display state for display processing. It can support source code file switching based on the call relationship between source code in IDE and other environments, and can solve the problem that projects that do not directly specify the call relationship in the source code cannot switch source code files based on the call relationship. Attached Figure Description

[0042] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of this application. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0043] Figure 1 This is an example of switching source code files based on the called function name;

[0044] Figure 2 This is an example of multiple sub-modules included in a large project;

[0045] Figure 3This is a flowchart provided in this application for generating source code call relationship information between various sub-modules of the target project;

[0046] Figure 4 This application provides a flowchart for recording dynamic call information based on the deployed service proxy, and generating source code call relationship information based on the recorded information.

[0047] Figure 5 This is an example provided in this application of recording dynamic call information by deploying local and global proxies, and generating a source code call relationship graph based on the recorded information;

[0048] Figure 6 This is a flowchart illustrating one of the processing methods provided in this application;

[0049] Figure 7 This is an example of a relational subgraph extracted from a source code call relational graph provided in this application;

[0050] Figure 8 This is an example of the icon display of the relational subgraph provided in this application;

[0051] Figure 9 This is another flowchart illustrating the processing method provided in this application;

[0052] Figure 10 This is an example of expanding a relational subgraph in the source code interface provided in this application;

[0053] Figure 11 This is a structural diagram of the electronic device provided in this application. Detailed Implementation

[0054] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0055] This application discloses a processing method and an electronic device. This method can be applied to, but is not limited to, electronic devices in various general-purpose or special-purpose computing environments or configurations, such as personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor devices, etc. This application primarily addresses the problem in software development scenarios where the source code of a software project does not directly specify call relationship information, preventing developers and other users from switching source code files based on call relationships within IDEs or similar environments. This allows users to conveniently and quickly switch between source code files.

[0056] This application pre-generates source code call relationship information to characterize the call relationships between multiple sub-modules of the target project, based on the dynamic call process between at least multiple sub-modules contained in the target project. This enables rapid switching of source code files of the target project based on the call relationships between source code, even when the source code of the target project does not directly specify the call relationship information.

[0057] See Figure 3 The process of generating source code call relationship information between various sub-modules of the target project can be implemented as follows:

[0058] Step 301: Start the multiple sub-modules included in the target project to run the multiple sub-modules.

[0059] The method described in this application is applicable to, but not limited to, application scenarios such as software development or testing.

[0060] The target project is a software project, specifically a software project within the current application scenario, such as the current software development or testing scenario.

[0061] The target project comprises multiple sub-modules. Based on the individual functions of these sub-modules and their inter-module collaboration, the overall functionality required by the target project is achieved. The calling relationships between each sub-module can be configured as needed, for example, by directly specifying the calling relationship information in the source code or indirectly configuring the calling relationship through network protocols. Each sub-module can contain one or more source code files. This application primarily addresses the scenario where calling relationship information is not explicitly specified in the source code, providing a solution for quickly switching between source code files based on calling relationships.

[0062] In this step, starting multiple sub-modules of the target project can refer to starting all or some of the sub-modules of the target project, without limitation. For example, during the development of the target project, according to the development schedule, only the sub-modules that have been completed at the current stage can be started; or, in the testing environment, all sub-modules of the target project can be started, or only the few sub-modules that need to be tested can be started, etc.

[0063] By activating multiple sub-modules included in the target project, multiple sub-modules are put into a running state.

[0064] Step 302: Based at least on the dynamic calling process between the above-mentioned sub-modules during runtime, generate source code calling relationship information between the above-mentioned sub-modules.

[0065] During the operation of the target project, multiple sub-modules will dynamically call each other as needed. This embodiment monitors the dynamic calling process, analyzes the calling relationship between different sub-modules, and generates source code calling relationship information that can reflect the calling relationship between different sub-modules.

[0066] Optionally, a service proxy can be deployed in the environment, and dynamic call information between various sub-modules during operation can be recorded based on the service proxy. Taking the IDE environment as an example, the service proxy deployed in the IDE can be used to record dynamic call information between various sub-modules of the target project during operation, so as to analyze the call relationship between various sub-modules of the target project based on the recorded dynamic call information and generate source code call relationship information based on this.

[0067] like Figure 4 As shown, the process of dynamically recording call information based on the deployed service proxy and generating source code call relationship information based on the recorded information specifically includes:

[0068] Step 401: For the startup events of multiple sub-modules of the target project, start the service agent synchronously.

[0069] There can be one or more service proxies, and if there are multiple service proxies, the types of the multiple service proxies can be the same or different, without restriction.

[0070] Preferably, in one embodiment, the service proxy includes multiple local proxies and a global proxy, wherein the multiple local proxies correspond one-to-one with multiple sub-modules of the target project, and the multiple sub-modules of the target project share the same global proxy.

[0071] Accordingly, when starting multiple sub-modules of the target project, the local proxy corresponding to each sub-module and the global proxy corresponding to each sub-module can be started simultaneously. For example, in an IDE environment, the IDE starts a corresponding local proxy for each sub-module and a global proxy for each sub-module, so as to record dynamic call information between sub-modules through the started global proxy and each local proxy.

[0072] Step 402: Use the service agent to record the dynamic call information between various sub-modules during the operation.

[0073] For the implementation of a service proxy that includes multiple local proxies and a global proxy, during the operation of each submodule, each started local proxy can be used to record the calling information of each function contained in its corresponding submodule, including but not limited to some or all of the information such as the function identifier (e.g., function name) of the called function in the corresponding submodule, the submodule identifier corresponding to the submodule that called the function (i.e., which submodule called it), the calling time, and the number of times.

[0074] It also uses a global proxy to record the call information between each submodule. That is, all calls between the submodules started by the target project must go through the global proxy, and the global proxy will uniformly record the submodule-level call information between each submodule.

[0075] The global proxy records the call information between various sub-modules, including but not limited to: the identifiers of different sub-modules corresponding to each call event, the call or called relationship between different sub-modules, the call time, the number of times, etc., some or all of the information.

[0076] For scenarios where the various sub-modules of a target project do not explicitly specify their call relationships in the source code, but instead communicate via network protocols (such as HTTP), the sub-modules communicate with each other through service calls. A global proxy can intercept these service call requests and analyze the caller and callee information to record the call details between the sub-modules. A local proxy, on the other hand, can monitor the call events of functions within its corresponding sub-module to record the call details of all functions within that sub-module.

[0077] See Figure 5 The provided example illustrates this: the local proxy is the IDE program proxy on the submodule side, while the global proxy is the IDE network proxy that can be shared by all submodules. The target project has four submodules: A, B, C, and D. For each submodule, the IDE starts its corresponding IDE program proxy and an IDE network proxy that can be shared among the submodules. During the execution of each submodule, the IDE program proxy records the call information of its respective functions, and the IDE network proxy records the call information between submodules A, B, C, and D.

[0078] Step 403: Based on the dynamic call information recorded by the service agent, determine the call relationship between the multiple sub-modules by analyzing the static source code of the source code files corresponding to each sub-module of the target project.

[0079] This system can aggregate and integrate various dynamic call information recorded by the service proxy for analysis of call relationships between multiple sub-modules of the target project. Specifically, for implementations where the service proxy includes multiple local proxies and a global proxy, the system can aggregate, integrate, and analyze the call information between sub-modules recorded by the global proxy and the call information of functions in their respective sub-modules recorded by each local proxy. Combined with static source code analysis of the source code files corresponding to each sub-module, the system can determine the call relationships between the sub-modules.

[0080] The identified calling relationships include, but are not limited to: which submodules call each other, the caller and callee (at the submodule level) for each call, which function is called in each call, and which source code file the called function belongs to, etc.

[0081] For example, see Figure 5 Specifically, information recorded by the IDE network agent and each IDE program agent can be summarized to obtain information on the call between submodules A, B, C, and D, as well as the call information of functions contained in each submodule A, B, C, and D. Based on this, the call relationship between submodules A, B, C, and D can be determined, including but not limited to determining which submodules have made calls, the caller and callee (at the submodule level) for each call, and which function was called in each call. At the same time, combined with static source code analysis, the source code file to which the called function belongs can be determined.

[0082] Step 404: Generate a source code call relationship graph that matches the call relationship between the above-mentioned multiple sub-modules, as the source code call relationship information between the above-mentioned multiple sub-modules.

[0083] After determining the calling relationships between each submodule, source code calling relationship information that reflects these relationships is further generated. Preferably, in this embodiment, the source code calling relationship information is implemented in the form of a relationship graph, which can generate a source code calling relationship graph that matches the calling relationships between multiple submodules, serving as the source code calling relationship information between multiple submodules.

[0084] In this application embodiment, the generated source code call relationship graph is also referred to as a call relationship map.

[0085] The generated source code call graph can represent the following series of call relationship information through the graph information it contains:

[0086] 11) Calling or being called relationships between different submodules;

[0087] 12) When a submodule calls another submodule, the function identifier, such as the function name, is used for the function called in that other submodule.

[0088] 13) The file identifier of the source code file to which the called function belongs, such as the source code file name.

[0089] The process of generating source code call relationship information (source code call relationship graph) described above can be regarded as part of the processing method of this application, or more precisely, as the preprocessing stage of the processing method of this application. Based on this, the subsequent processing flow of the processing method of this application can be executed according to the generated source code call relationship information to support the rapid switching of source code files in IDE and other environments based on the call relationship between source code.

[0090] See Figure 6 The processing method flowchart shown illustrates that, based on the aforementioned source code call relationship information (source code call relationship diagram), the processing method disclosed in this application includes at least the following steps:

[0091] Step 601: Obtain the target source code information that is currently in the display state.

[0092] Optionally, in a software development environment, such as an integrated development environment (IDE), when opening a source code file for information display, or when switching source code files to display information about the switched source code file, the currently displayed source code information on the electronic device (such as a personal computer) interface can be obtained as the target source code information currently being displayed. However, this is not limited to this; the target source code information currently being displayed can also be obtained in other environments, such as a testing environment, at the aforementioned times.

[0093] In other implementations, the user can trigger the device to obtain the target source code information currently in the display state by performing a corresponding operation. For example, the developer can trigger the device to obtain the target source code information currently in the display state by performing an operation that instructs the generation and display of the source code call relationships corresponding to the current source code interface.

[0094] Specifically, it can obtain the current video memory content through interaction with the graphics card of the electronic device, and obtain the target source code information currently in the display state based on the video memory content.

[0095] Step 602: Determine the first submodule to which the target source code information belongs among the multiple submodules contained in the target project.

[0096] After obtaining the target source code information currently in the display state, we can first determine the target source code file to which the target source code information belongs. Then, based on the inclusion relationship between different submodules and different source code files, we can determine the submodule to which the target source code file belongs among the multiple submodules contained in the target project, and use this as the first submodule to which the target source code information belongs in the target project.

[0097] Step 603: Determine the first call relationship information based on the first submodule.

[0098] The first call relationship information is: information extracted from the source code call relationship information between the sub-modules of the target project that can at least be used to characterize the call relationship between the first sub-module and other sub-modules of the target project.

[0099] For the implementation of the source code call relationship information between each submodule as a source code call relationship graph, specifically, a relationship subgraph that can be used to represent the call relationship of the first submodule to other submodules of the target project can be extracted from the source code call relationship graph as the first call relationship information.

[0100] Based on the first submodule to which the target source code information belongs. Figure 5 For example, see submodule A in [the document / context]. Figure 7 Furthermore, it provides a call relationship subgraph extracted from the source code call relationship graph corresponding to submodules A, B, C, and D, showing how submodule A calls other submodules (B, C, and D). Submodule A has a call relationship with submodules B and D, but no call relationship with submodule C. Specifically, submodule A can call function 1 in source code file 1 and function 2 in source code file 2 of submodule B, and function 3 in source code file 3 of submodule D. Figure 7 The call relationship subgraph shown can be used as the first call relationship information corresponding to submodule A.

[0101] In other embodiments, the first call relationship information may include, in addition to call relationship information that can be used to characterize the first submodule's call to other submodules of the target project, call relationship information that other submodules of the target project call to the first submodule, without limitation.

[0102] Step 604: On the current source code interface corresponding to the target source code information, display the first call relationship information.

[0103] In one embodiment, the extracted relationship subgraph (used as the first call relationship information) can be displayed as an icon in a preset area of ​​the current source code interface corresponding to the target source code information.

[0104] Preferably, the preset area is the edge free area of ​​the current source code interface.

[0105] like Figure 8 This provides an example of displaying the icons of the extracted relational subgraphs in the free area at the top right edge of the current source code interface.

[0106] At the same time, user operation functions are configured to match the displayed sub-graph icons, so that developers and other users can quickly switch source code files by operating the icons.

[0107] In other implementations, the extracted relationship subgraph can be directly displayed in a preset area of ​​the current source code interface. In this implementation, the displayed relationship subgraph is associated with matching user operation functions, thereby enabling developers and other users to quickly switch source code files by operating the relationship subgraph.

[0108] As can be seen from the above scheme, the processing method disclosed in this application is based at least on the dynamic calling process between multiple sub-modules contained in the target project. It pre-generates source code calling relationship information to represent the calling relationship between multiple sub-modules of the target project. Then, for the target source code information in the display state, according to the first sub-module to which it belongs in the target project, it determines the first calling relationship information from the above source code calling relationship information. The first calling relationship information is the corresponding information extracted from the source code calling relationship information that can at least represent the calling relationship of the first sub-module to other sub-modules of the target project. The first calling relationship information is then displayed on the current source code interface.

[0109] This application generates source code call relationship information between sub-modules based on the dynamic call process between at least the sub-modules of the target project. Based on this, it extracts the matching part from the generated source code call relationship information of the target source code information in the display state for display processing. It can support source code file switching based on the call relationship between source code in IDE and other environments, and can solve the problem that projects that do not directly specify the call relationship in the source code cannot switch source code files based on the call relationship.

[0110] In one embodiment, see Figure 9 The provided processing method flowchart, after step 604, may further include:

[0111] Step 605: In response to detecting a target operation on the first call relationship information on the current source code interface, switch the current source code interface to the source code interface of the corresponding source code file of the second submodule indicated by the target operation.

[0112] For the two implementation methods of displaying an icon of the extracted relational subgraph in the current source code interface, or displaying the extracted relational subgraph, this step can be implemented as follows:

[0113] 21) In response to the first operation on the relationship subgraph icon displayed in the above-mentioned preset area, the current source code interface is switched to the source code interface of the corresponding source code file of the second submodule indicated by the first operation; the first operation includes: operating the relationship subgraph icon to expand the corresponding relationship subgraph, and selecting the file identifier of the corresponding source code file of the second submodule to be displayed in the expanded relationship subgraph.

[0114] In this implementation, developers and other users can expand the corresponding subgraph by manipulating the displayed subgraph icons, for example, by clicking... Figure 8 The icons in the diagram expand to show the call relationships between submodule A and other corresponding submodules (B, D). The expanded diagram is as follows: Figure 10 As shown in the diagram (the expanded sub-diagram in this diagram is only for illustration and does not show the actual called function names, source code file names, etc. involved in the source code interface in the diagram), you can then select the file identifier of the source code file to be switched in the expanded sub-diagram to quickly switch to that source code file.

[0115] 22) In response to the second operation of the relationship subgraph displayed in the preset area, the current source code interface is switched to the source code interface of the corresponding source code file of the second submodule indicated by the second operation; the second operation includes: selecting the file identifier of the corresponding source code file of the second submodule to be displayed in the relationship subgraph displayed in the preset area.

[0116] In this implementation, developers and other users can quickly switch to a source code file by directly manipulating the corresponding objects in the displayed relationship subgraph, such as selecting the file identifier of the source code file to be switched.

[0117] This application intuitively displays the extracted relationship subgraphs or their icons on the current source code interface and associates them with corresponding user operation functions. This allows users to quickly switch source code files by operating on the displayed relationship subgraphs or icons. As a result, it supports switching source code files based on the call relationships between source code in environments such as IDEs, which can solve the problem that projects that do not directly specify the call relationships in the source code cannot switch source code files based on the call relationships.

[0118] It is worth noting that this application also applies to cases where the calling relationships are directly stated in the project source code. In such cases, users can also quickly switch source code files based on the displayed relationship subgraph icon or relationship subgraph. Users can choose to switch source code files by clicking the function name of the called function or by manipulating the relationship subgraph icon / relationship subgraph as needed.

[0119] In one embodiment, optionally, the processing method provided in this application, before generating the source code call relationship information between the multiple sub-modules based at least on the dynamic calling process between the multiple sub-modules at runtime, may further include the following processing:

[0120] Determine whether the source code files corresponding to each submodule of the target project contain source code information indicating the calling relationship between different submodules. If not, trigger the step of generating source code calling relationship information between the above-mentioned submodules based at least on the dynamic calling process between the above-mentioned submodules at runtime.

[0121] Specifically, before generating source code call relationship information between different sub-modules of the target project, static source code analysis can be performed on each sub-module of the target project to determine whether the call relationship between different sub-modules is directly stated in the source code of each sub-module. If so, source code call relationship information (such as source code call relationship diagram) between sub-modules will not be generated based on the dynamic call process between sub-modules, so as to minimize the consumption of device resources. In this case, users can jump to other source code files that define the function by clicking on the function name of the function called in the current source code file.

[0122] This application also discloses an electronic device, which may be, but is not limited to, a device in a variety of general or special computing device environments or configurations, such as: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor devices, etc.

[0123] The composition and structure of electronic devices, such as Figure 11 As shown, it includes at least:

[0124] Memory 10 is used to store the computer instruction set;

[0125] Computer instruction sets can be implemented in the form of computer programs.

[0126] Processor 20 is configured to implement the processing method disclosed in any of the above method embodiments by executing a computer instruction set.

[0127] The processor 20 can be a central processing unit (CPU), an application-specific integrated circuit (ASIC), a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices.

[0128] Electronic devices have a display device and / or have a display interface and can connect to an external display device.

[0129] Optionally, the electronic device may also include a camera assembly, and / or be connected to an external camera assembly.

[0130] In addition to these components, electronic devices may also include communication interfaces, communication buses, and other parts. Memory, processor, and communication interface communicate with each other through the communication bus.

[0131] Communication interfaces are used for communication between electronic devices and other devices. Communication buses can be Peripheral Component Interconnect (PCI) buses or Extended Industry Standard Architecture (EISA) buses, and can be categorized into address buses, data buses, control buses, etc.

[0132] It should be noted that the various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0133] For ease of description, the above systems or devices are described separately as various modules or units based on their functions. Of course, in implementing this application, the functions of each unit can be implemented in one or more software and / or hardware components.

[0134] As can be seen from the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware platforms. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in various embodiments or some parts of the embodiments of this application.

[0135] Finally, it should be noted that in this document, relational terms such as first, second, third, and fourth are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

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

Claims

1. A processing method, the method comprising: Retrieve the target source code information that is currently being displayed; Determine the first submodule to which the target source code information belongs among the multiple submodules contained in the target project; The first call relationship information is determined based on the first sub-module; The first call relationship information is: information extracted from the source code call relationship information that can at least be used to characterize the call relationship between the first submodule and other submodules of the target project; the source code call relationship information is information pre-generated to characterize the call relationship between the multiple submodules, based at least on the dynamic call process between the multiple submodules contained in the target project. On the current source code interface corresponding to the target source code information, the first call relationship information is displayed. The process of generating the source code call relationship information includes: The local proxy corresponding to each of the multiple submodules is used to record the call information of each function contained in the submodule, and the global proxy corresponding to each of the multiple submodules is used to record the call information between the submodules. The source code call relationship information is determined based on the function call information and the call information between the submodules.

2. The method according to claim 1, further comprising, before obtaining the target source code information currently in the display state: Start the multiple sub-modules included in the target project to run the multiple sub-modules; Based at least on the dynamic calling process between the multiple sub-modules at runtime, the source code calling relationship information between the multiple sub-modules is generated.

3. The method according to claim 2, wherein generating the source code call relationship information among the plurality of sub-modules based at least on the dynamic calling process among the plurality of sub-modules at runtime includes: For each of the aforementioned sub-modules' startup events, a service proxy is started synchronously. The service proxy is used to record dynamic call information between various sub-modules during operation; Based on the dynamic call information recorded by the service proxy, the call relationship between the multiple sub-modules is determined by static source code analysis of the source code files corresponding to each sub-module; Generate a source code call relationship graph that matches the call relationships between the multiple sub-modules, and use it as the source code call relationship information.

4. The method according to claim 3, wherein the synchronous startup service agent comprises: Simultaneously start the local agent corresponding to each submodule and the global agent corresponding to each submodule; The method of using the service proxy to record dynamic call information between various sub-modules during operation includes: Each of the aforementioned local proxies is used to record the call information of each function contained in the corresponding submodule during the running process; The global proxy is used to record the call information between various sub-modules.

5. The method according to claim 3, wherein, In the preset development environment, start the multiple sub-modules of the target project and start the service agent.

6. The method according to claim 1, wherein the source code call relationship information includes call relationship information represented by a source code call relationship graph, and the first call relationship information includes a relationship subgraph extracted from the source code call relationship graph that can at least be used to represent the call relationship between the first submodule and other submodules of the target project; The process of displaying the first call relationship information on the current source code interface corresponding to the target source code information includes: The icons of the relationship subgraph are displayed in a preset area of ​​the current source code interface; Alternatively, the relational subgraph can be displayed in a preset area of ​​the current source code interface.

7. The method according to claim 6, further comprising, after displaying the first call relationship information: In response to detecting a target operation on the first call relationship information, the current source code interface is switched to the source code interface of the corresponding source code file of the second submodule indicated by the target operation.

8. The method according to claim 7, wherein the source code call relationship graph comprises: The calling or called relationship between different submodules; the function identifier of the function called in the corresponding other submodule when a submodule calls another submodule; and the file identifier of the source code file to which the called function belongs. The step of switching the current source code interface to the source code interface of the corresponding source code file of the second submodule indicated by the target operation in response to detecting a target operation on the first call relationship information includes: In response to a first operation on the icon displayed in the preset area, the current source code interface is switched to the source code interface of the corresponding source code file of the second sub-module indicated by the first operation; the first operation includes: operating the icon to expand the relationship sub-graph, and selecting the file identifier of the corresponding source code file of the second sub-module to be displayed in the expanded relationship sub-graph. Alternatively, in response to a second operation on the relational subgraph displayed in the preset area, the current source code interface is switched to the source code interface of the corresponding source code file of the second submodule indicated by the second operation; the second operation includes: selecting the file identifier of the corresponding source code file of the second submodule to be displayed in the relational subgraph displayed in the preset area.

9. The method according to claim 2, further comprising, before generating the source code call relationship information between the plurality of sub-modules based at least on the dynamic call process between the plurality of sub-modules at runtime: Determine whether the source code files corresponding to each sub-module of the target project contain source code information indicating the calling relationship between different sub-modules; If not included, the step of generating source code call relationship information between the multiple sub-modules is triggered, based at least on the dynamic calling process between the multiple sub-modules at runtime.

10. An electronic device, comprising: Memory, used to store at least one set of computer instructions; A processor for implementing the processing method as described in any one of claims 1-9 by invoking and executing the instruction set stored in the memory.

Images