CN117931142A

CN117931142A - Information processing method, device, equipment and medium

Info

Publication number: CN117931142A
Application number: CN202410097544.8A
Authority: CN
Inventors: 汪兆鹏; 余明哲; 饶劲超; 赵鑫亮
Original assignee: Industrial and Commercial Bank of China Ltd ICBC
Current assignee: Industrial and Commercial Bank of China Ltd ICBC
Priority date: 2024-01-24
Filing date: 2024-01-24
Publication date: 2024-04-26

Abstract

The disclosure provides an information processing method applied to a client, which can be used in the financial field or other fields. The method comprises the following steps: in response to receiving the starting instruction, starting a main body framework of the client, and synchronizing basic function packages of each plug-in a local plug-in list from the server, wherein a program file of each plug-in comprises a basic function package and a service logic package, the updating frequency of the basic function package is lower than that of the service logic package, and the local plug-in list comprises information of all plug-ins required locally; when a first call request for the target plugin is received under the condition that the target plugin is not started, downloading a service logic package of the target plugin from a server; updating the program file of the target plug-in unit in response to the completion of downloading the service logic package of the target plug-in unit; and loading the program file of the target plug-in to start the target plug-in. The present disclosure also provides an information processing apparatus, device, storage medium, and program product provided at a client.

Description

Information processing method, device, equipment and medium

Technical Field

The present disclosure relates to the field of software design, and may be used in the financial field or other fields, and more particularly to an information processing method, apparatus, device, medium, and program product.

Background

In order to meet the individuation and diversification requirements of client users, the client program can be split into two parts of a main body framework and a plug-in program when the client is developed, and the two parts can be independently developed. The main body framework realizes the general function, the version is stable, plug-in programs are customized and developed according to service requirements, and plug-ins are mutually independent.

The inventor finds that in the process of implementing the inventive concept, the plug-in is integrated in the client in the related art, the plug-in can operate together with the main body framework of the client, if a new plug-in is needed or the plug-in is updated, the plug-in is often needed to be reinstalled in the client, and the process needs a user to wait for the plug-in to be installed or the plug-in to be updated to be completed before the client can be continuously used. If the plug-in of the client is more or the plug-in is updated frequently, the use experience of the client user is seriously affected.

Disclosure of Invention

In view of the foregoing, the present disclosure provides an information processing method, apparatus, device, medium, and program product that can dynamically load a plug-in according to call requirements after a body frame of a client is started.

In a first aspect of the embodiments of the present disclosure, an information processing method applied to a client is provided. The method comprises the following steps: in response to receiving a start instruction, starting a main body frame of the client; responding to the starting of the main body framework, synchronizing basic function packages of each plug-in a local plug-in list from a server side, wherein a program file of each plug-in comprises a basic function package and a service logic package, the updating frequency of the basic function package is lower than that of the service logic package, and the local plug-in list comprises information of all plug-ins required locally; when a first call request to a target plug-in is received under the condition that the target plug-in is not started, downloading a business logic package of the target plug-in from the server; updating the program file of the target plug-in unit in response to the completion of the downloading of the business logic package of the target plug-in unit; loading a program file of the target plug-in to start the target plug-in; and invoking the target plugin based on the first invocation request.

According to an embodiment of the present disclosure, after the loading of the program file of the target plug-in to launch the target plug-in, the method further includes: receiving a second call request to the target plugin; responding to the second call request, calculating the information abstract of the service logic package in the program file of the target plug-in to obtain a first information abstract; sending a verification request to the server, wherein the verification request comprises the first information abstract; receiving a verification result returned by the server; and when the verification result shows that the first information abstract is consistent with the information abstract of the business logic package of the target plug-in stored in the server, calling the target plug-in based on the second calling request.

According to an embodiment of the present disclosure, the method further comprises: when the verification result shows that the first information abstract is inconsistent with the information abstract of the business logic package of the target plug-in stored in the server, downloading the business logic package of the target plug-in from the server; updating the program file of the target plug-in unit in response to the completion of the downloading of the business logic package of the target plug-in unit; unloading the loaded target plugin; after the target plug-in is completely unloaded, reloading the program file of the target plug-in to restart the target plug-in; and invoking the target plugin based on the second invocation request in response to the restart of the target plugin.

According to an embodiment of the disclosure, after the synchronizing, from the server side, the basic function package of each plug-in the local plug-in list in response to the start of the main body framework, the method further includes: receiving a plug-in basic function package updating instruction pushed by the server, wherein the plug-in basic function package updating instruction comprises updating information of a basic function package of a second plug-in; downloading the basic function package of the second plug-in from the server based on the update information of the basic function package of the second plug-in; and updating the basic function package of the second plug-in response to completion of downloading of the basic function package of the second plug-in.

According to an embodiment of the present disclosure, after the loading of the program file of the target plug-in to launch the target plug-in, the method further includes: receiving a third call request to the target plugin; responding to the third call request, obtaining time information for loading the target plug-in, and obtaining a cache starting moment; acquiring the latest updated time information of the basic function package of the target plug-in to obtain the latest updated time; unloading the loaded target plug-in when the cache starting time is earlier than the latest updating time; after the target plug-in is completely unloaded, reloading the program file of the target plug-in and restarting the target plug-in; and invoking the target plugin based on the third invocation request in response to the restart of the target plugin.

According to an embodiment of the present disclosure, the method further comprises: registering a timed task in response to the initiation of the body frame; the version updating information of the main body frame is acquired from the server at regular time through the timing task; when the version update of the main body frame is determined according to the version update information, downloading a program file of the main body frame with a new version from the server; acquiring a main body frame upgrading program; and running the main body frame upgrade program, wherein the main body frame upgrade program is configured to: closing the main body frame; reinstalling the body frame based on the program files of the new version body frame in response to the closing of the body frame; and sending the start instruction to the client in response to the installation of the main body frame being completed.

According to an embodiment of the present disclosure, the acquiring the main body frame upgrade program includes: and registering a hook program, wherein the hook program is hooked with the main body frame and the starting script of the program file of the new version main body frame respectively.

According to an embodiment of the present disclosure, in response to the initiation of the main body framework, synchronizing, from the server, a basic function package of each plug-in the local plug-in list includes: sending a local plug-in information request to a server; receiving the local plug-in list returned by the server, wherein the local plug-in list comprises information summaries of basic function packages of all plug-ins required locally; acquiring a local existing plug-in list, wherein the local existing plug-in list comprises locally stored information abstracts of basic function packages of all plug-ins; the information of at least one first plug-in with inconsistent information in the local plug-in list and the local existing plug-in list is obtained by comparing the local plug-in list and the local existing plug-in list; and updating the locally stored basic function package of at least one first plug-in based on the information of the at least one first plug-in.

According to an embodiment of the present disclosure, the updating the locally stored basic function package of at least one first plug-in based on the information of the at least one first plug-in includes: deleting the locally stored program file of the first plug-in when the first plug-in does not belong to the local plug-in list; when the first plug-in does not belong to the local existing plug-in list, downloading a basic function package of the first plug-in from the server and storing the basic function package to the local; and when the first plugin belongs to the local existing plugin list and the local plugin list at the same time, downloading the basic function package of the first plugin from the server and replacing the basic function package of the first plugin which is stored locally.

In a second aspect of the embodiments of the present disclosure, an information processing apparatus provided at a client is provided. The device comprises: the system comprises a starting module, a local plug-in management module and a plug-in dynamic loading module.

The starting module is used for responding to the received starting instruction and starting the main body framework of the client.

The local plug-in management module is used for responding to the starting of the main body framework, synchronizing basic function packages of all plug-ins in a local plug-in list from a server side, wherein program files of all plug-ins comprise basic function packages and business logic packages, the updating frequency of the basic function packages is lower than that of the business logic packages, and the local plug-in list comprises information of all plug-ins required locally.

Plug-in dynamic loading module, is used for: when a first call request to a target plug-in is received under the condition that the target plug-in is not started, downloading a business logic package of the target plug-in from the server; updating the program file of the target plug-in unit in response to the completion of the downloading of the business logic package of the target plug-in unit; loading a program file of the target plug-in to start the target plug-in; and invoking the target plugin based on the first invocation request.

In a third aspect of the disclosed embodiments, an electronic device is provided. The electronic device includes one or more processors and memory. The memory is configured to store one or more programs that, when executed by the one or more processors, cause the one or more processors to perform the above-described method.

In a fourth aspect of the disclosed embodiments, there is also provided a computer-readable storage medium having stored thereon executable instructions that, when executed by a processor, cause the processor to perform the above-described method.

In a fifth aspect of the disclosed embodiments, there is also provided a computer program product comprising a computer program which, when executed by a processor, implements the above method.

One or more of the above embodiments have the following advantages or benefits: when the client is started, the main body framework can be started first, and the basic function package of each plug-in all plug-ins locally required by the client can be synchronized from the server. And then when the target plug-in is to be called, immediately downloading a service logic package of the target plug-in from the server, and loading a program file obtained by combining the basic function package and the service logic package of the target plug-in into a memory, thereby starting the plug-in. Thus, the plug-in service logic package is used at the following time according to the calling requirement. When the corresponding plug-in is not used after the client is started, plug-in loading is not needed, network overhead is not needed to download the business logic package of the plug-in, unnecessary computer loading consumption is reduced, and unnecessary network overhead is also reduced. And the data volume of the service logic package is usually smaller, so that the process of reloading the plug-in after downloading can realize no perception of the client and does not influence the use experience of the client.

Drawings

The foregoing and other objects, features and advantages of the disclosure will be more apparent from the following description of embodiments of the disclosure with reference to the accompanying drawings, in which:

FIG. 1 schematically illustrates an application scenario diagram of an information processing method, apparatus, device, medium, and program product according to an embodiment of the present disclosure;

FIG. 2 schematically illustrates a system architecture diagram of information processing methods, apparatus, devices, media, and program products according to embodiments of the present disclosure;

FIG. 3 schematically illustrates a functional schematic of a client management module in the server shown in FIG. 2;

FIG. 4 schematically illustrates a functional schematic of a plug-in management module in the server shown in FIG. 2;

FIG. 5 schematically illustrates a flow chart of an information processing method of an embodiment of the present disclosure;

FIG. 6 schematically illustrates a subsequent call flow diagram of a plug-in an information processing method of another embodiment of the present disclosure;

FIG. 7 schematically illustrates a flowchart of a basic function package of an update plug-in an information processing method according to an embodiment of the present disclosure;

FIG. 8 schematically illustrates a flowchart of a basic function package of an update plug-in an information processing method according to still another embodiment of the present disclosure;

FIG. 9 schematically illustrates a subsequent call flow diagram of a plug-in an information processing method of another embodiment of the present disclosure;

FIG. 10 schematically illustrates a flowchart of updating a subject framework in an information processing method of an embodiment of the present disclosure;

FIG. 11 schematically illustrates a flowchart of updating a subject framework in an information processing method of another embodiment of the present disclosure;

Fig. 12 schematically shows a block diagram of an information processing apparatus according to an embodiment of the present disclosure; and

Fig. 13 schematically shows a block diagram of an electronic device adapted to implement an information processing method according to an embodiment of the present disclosure.

Detailed Description

Hereinafter, embodiments of the present disclosure will be described with reference to the accompanying drawings. It should be understood that the description is only exemplary and is not intended to limit the scope of the present disclosure. In the following detailed description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the embodiments of the present disclosure. It may be evident, however, that one or more embodiments may be practiced without these specific details. In addition, in the following description, descriptions of well-known structures and techniques are omitted so as not to unnecessarily obscure the concepts of the present disclosure.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the disclosure. The terms "comprises," "comprising," and/or the like, as used herein, specify the presence of stated features, steps, operations, and/or components, but do not preclude the presence or addition of one or more other features, steps, operations, or components.

All terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art unless otherwise defined. It should be noted that the terms used herein should be construed to have meanings consistent with the context of the present specification and should not be construed in an idealized or overly formal manner.

Where a convention analogous to "at least one of A, B and C, etc." is used, in general such a convention should be interpreted in accordance with the meaning of one of skill in the art having generally understood the convention (e.g., "a system having at least one of A, B and C" would include, but not be limited to, systems having a alone, B alone, C alone, a and B together, a and C together, B and C together, and/or A, B, C together, etc.).

The embodiment of the disclosure provides an information processing method, an information processing device, an information processing medium and a program product applied to a client. In the embodiment of the disclosure, the client is divided into two major parts, namely a main body frame and plug-ins, wherein the program file of each plug-in can be divided into two parts, namely a basic functional package and a service logic package, and the update frequency of the basic functional package is lower than that of the service logic package. The basic function package may include various library packages, such as a dependency library package, interface logic that invokes a third party database, and the like. Typically, the basic package does not need to be updated as long as the database or third party interface on which the plug-in function depends is unchanged. The service logic package is a file package composed of code files and the like for realizing the plug-in service logic, and needs to be updated more frequently along with the change of service requirements and the change of plug-in service processing logic. Moreover, in general, the basic function packet has a larger data volume than the service logic packet, for example, the basic function has tens of megabits, and the service logic packet has only one or two megabits.

According to the embodiment of the disclosure, when the client starts, the main body framework can be started first, and meanwhile, the basic function package of each plug-in all plug-ins locally required by the client is synchronized from the server. Then when a certain plug-in (namely, a target plug-in is called herein), the service logic package of the target plug-in is immediately downloaded from the server, and then the program file obtained by combining the basic function package and the service logic package of the target plug-in is loaded into the memory, so that the plug-in is started. Thus, the plug-in service logic package is used at the following time according to the calling requirement. When the corresponding plug-in is not used after the client is started, plug-in loading is not needed, network overhead is not needed to download the business logic package of the plug-in, unnecessary computer loading consumption is reduced, and unnecessary network overhead is also reduced; when the plug-in is called for the first time, the latest business logic package can be immediately downloaded and then the plug-in is loaded, and as the data volume of the business logic package is usually smaller, the process of reloading the plug-in after the downloading can be perceived by a client, so that the latest plug-in can be used when the plug-in is needed, and the use experience of the client is not influenced.

Fig. 1 schematically illustrates an application scenario diagram of an information processing method, apparatus, device, medium, and program product according to an embodiment of the present disclosure. Fig. 1 is only an example of a system architecture to which embodiments of the present invention may be applied to assist those skilled in the art in understanding the technical content of the present invention, but does not mean that the present invention may not be used in other devices, systems, environments, or scenarios.

As shown in fig. 1, an application scenario 100 according to this embodiment may include clients 101, 102, 103, a network 104, and a service system 105. Network 104 is the medium used to provide communications links between clients 101, 102, 103 and service system 105. The network 104 may include various connection types, such as wired, wireless communication links, or fiber optic cables, among others.

Clients 101, 102, 103 are devices deployed in a client environment, such as servers or terminal devices. Clients 101, 102, 103 may be installed with clients that obtain services from service system 105. The client may be a terminal program with a user interaction interface or a background program interfacing with other systems in the clients 101, 102, 103.

Service system 105 may include one or more servers. The service system 105 deploys a server that can provide background services to clients installed by the clients 101, 102, 103.

The explanation will be given by taking a bank as an example of its enterprise clients. The service system 105 is a service system of a bank, and the clients 101, 102, 103 are devices on the enterprise client side of the deployment bank. The banking will provide its enterprise customers with client programs deployed on clients 101, 102, 103, facilitating the customers to interface their own systems with the bank's service system 105.

Some client programs are complex, and interconnection and intercommunication with the bank service system 105 can be actively realized through modes of interface calling, database operation and the like. For example, a client program provided by a bank opens up software modules of a plurality of mainstream ERP manufacturers, but a system of a certain customer only needs to call one software module, and the bank is required to realize function customization according to the ERP flow of the system.

In order to meet different demands of customers, banks need to provide a plurality of specific client programs without using a plug-in mode. Given that n ERP vendors from number 1 to number n are provided, each ERP has m modules implemented according to the requirements of customer customization, it is theoretically possible to issue n×m versions of clients, and meanwhile, the problem of upgrading the version of the subsequent client is considered, so that the problem that the client is difficult to popularize and maintain due to excessive versions is inevitably caused.

The clients installed and running in the clients 101, 102 and 103 can be divided into two parts, namely a main body framework and a plug-in program, so that the client can well cope with the diversity requirement of the clients in the situation. Moreover, the main body framework and the plug-in program can be independently developed without mutual influence in terms of version. The main body framework realizes the general function, the version is stable, plug-in programs are customized and developed according to service requirements, and plug-ins are mutually independent. Thus, the function customization, popularization and maintenance of the client are convenient.

It should be understood that the number of terminal devices, networks and servers in fig. 1 is merely illustrative. There may be any number of terminal devices, networks, and servers, as desired for implementation.

Fig. 2 schematically illustrates a system architecture diagram of an information processing method, apparatus, device, medium, and program product according to an embodiment of the present disclosure.

As shown in fig. 2, the system architecture may include a server 201 and a client 202. With reference to fig. 1, a server 201 is deployed to a service system 105, and clients 202 are deployed to clients 101, 102, 103.

The server 201 may include a client management module, a plug-in management module, a framework version management module, and a secure communication module. Wherein the functions of the client management module are shown in fig. 3, and the functions of the plug-in management module are shown in fig. 4.

Fig. 3 schematically shows a functional schematic of the client management module in the server 201 shown in fig. 2.

As shown in fig. 3, the client management module in the server 201 may use a database to register a client number, a client name, a main body frame version, and a plug-in list used by each client, where the plug-in list may include information of all plug-ins used by the client in the current stage, for example, a summary of information of a basic function package of each plug-in, and so on.

The server side administrator may accurately manage the plug-ins in the client 202 according to the client dimension. According to the personalized demands of clients, a plug-in list is configured through a client management module, and the plug-in range used by each client, the basic function package in each plug-in, the business logic package of each plug-in and the version thereof are listed.

Fig. 4 schematically shows a functional schematic of the plug-in management module in the server 201 shown in fig. 2.

As shown in fig. 4, in the plug-in management module in the server 201, plug-ins may be divided according to service function granularity, and each plug-in includes a basic function packet and a service logic packet. Since the basic function packages are mainly library-dependent packages, logic packages for calling the third party interface and the like, there is usually only one basic function package for each plug-in, but the business logic package can support that multiple versions exist. The program files of the plug-ins may be managed using an open source distributed version control system (G1 obal Information Tracker, GIT) and registered with a database for plug-in names, functions, basic function packages of the plug-ins, versions of service logic packages, plug-in library address information, information summaries of the basic function packages, information summaries of the service logic packages, and the like. Wherein, in one embodiment, the information digest of the basic functional package or the business logic package may be a digest generated by a secure hash algorithm (Secure Hash Algorithm, SHA) algorithm.

The plug-in management module may obtain the library address information of the plug-ins according to the plug-in list configured by the client management module for each client, pull the corresponding plug-ins from the GIT version control system according to the client instruction, and may send update, uninstall notification, etc. of the basic function package or the service logic package in the corresponding plug-ins to the client 202.

Accordingly, the framework version management module in the server 201 may use the GIT version control system to manage the main framework program file, and provide the version query and update function of the main framework to the client 202.

In addition, the server 201 further includes a secure communication module, and the secure communication module uses RSA asymmetric encryption and signature technology to ensure confidentiality and tamper resistance of communication with the client 202.

With continued reference to FIG. 2, the client 202 includes two parts, a body framework and a plug-in. The client 202 may execute the information processing method described in the embodiments of the present disclosure, so that, except that the first downloading and installation of the client 202 requires manual operations by a user, the downloading and the memory loading of the plug-in program file in the client 202 may be automatically executed in a state that the user does not feel. Even in some embodiments, version upgrades of the subject framework in the client 202 may be performed automatically without user intervention. In the interaction process between the client 202 and the server 201, RSA encryption and signature technology can be adopted, so that the confidentiality and tamper resistance of communication with the server 201 are ensured.

The information processing method according to the embodiment of the present disclosure will be described in detail below with reference to fig. 5 to 11 based on the application scenario described in fig. 1 and the system architecture introduced in fig. 2 to 4. It should be noted that the sequence numbers of the respective operations in the following methods are merely representative of the operations for the sake of description, and should not be considered to represent the order of execution of the respective operations. The method need not be performed in the exact order shown unless explicitly stated.

Fig. 5 schematically shows a flowchart of an information processing method of an embodiment of the present disclosure.

As shown in fig. 5, the information processing method of this embodiment includes operations S501 to S506, where the information processing method is applied to the client 202.

In operation S501, in response to receiving the start instruction, the body frame of the client 202 is started. The initiation instruction may be triggered by a user manually operating the initiation client 202 or may be initiated by a program in the client 101, 102, 103, for example by a client system interfacing with the client 202.

In operation S502, in response to the start of the body framework, the basic function package of each plug-in the local plug-in list is synchronized from the server 201. For example, the basic function package of the plug-in to be synchronized is pulled from the GIT version control system under the framework version management module of the server 201, downloaded locally, and stored in a designated directory outside the main framework.

In one embodiment, after the body framework is started, the client 202 may send a local plugin information request to the server 201, and obtain a local plugin list returned by the server 201, where the local plugin list may be a response of the server 201 to the local plugin information request. The local plug-in manifest includes information (e.g., plug-in name and functionality) for all plug-ins that are locally required. In some embodiments, the local plug-in manifest may also include information for the basic packages in each plug-in (e.g., a summary of the basic packages).

Under the system architecture shown in fig. 2, customer information may be included in the plug-in information request. Thus, after receiving the plug-in request information, the server 201 may query the corresponding plug-in list through the client information management module in the server 20 ]. It will of course be appreciated that the information in the plug-in information request is not limited to customer information. For example, in some cases when the server allocates a client plug-in based on the version of the principal frame in the client, the plug-in request information may include version information of the principal frame. For another example, when the server 201 allocates a plugin based on the area where the client is located, the plugin request information may include the area information where the client is located. The relevant examples are not the same and will not be described in detail here.

In one embodiment, before synchronizing the basic function packages of each plug-in the local plug-in list from the server 201, there may also be some basic function packages of some plug-ins that have been downloaded before locally, and to avoid repeated downloading, the local existing plug-in list may be acquired by first collecting information of the basic function packages of all plug-ins stored locally. In one embodiment, the local existing plug-in manifest includes a locally stored information summary of the basic function package of each of all plug-ins. And then, the information of at least one first plug-in with inconsistent information in the local plug-in list and the local existing plug-in list is obtained by comparing the local plug-in list and the local existing plug-in list. In this way, only the basic function packages of these first plug-ins whose information is inconsistent can be updated.

For example, when the first plugin does not belong to the local plugin list, it indicates that the server 201 has deleted the first plugin, and then deletes the locally stored program file (including the basic function package and the service logic package downloaded before); when the first plug-in does not belong to the local existing plug-in list, the first plug-in is described as being locally missing, and then a basic function package of the first plug-in is downloaded from the server 201 and stored locally; and when the first plug-in belongs to both the local existing plug-in list and the local plug-in list (e.g., the information summary pair of the basic function package of the first plug-in is not up), downloading the basic function package of the first plug-in from the server 201 and replacing the basic function package of the first plug-in stored locally.

It can be seen that, by automatically updating the basic function package of the locally stored plug-in according to the comparison with the local plug-in list when the main body framework is started, the basic function package of the locally stored plug-in can be kept consistent with the basic function package of the plug-in locally allocated to the server 201 after the client 202 (or the main body framework) is started, including the number of plug-ins, the plug-in functions and the versions are all consistent.

Next, in operation S503, when a first call request to the target plug-in is received without the target plug-in being started, the service logic package of the target plug-in is downloaded from the server 201.

In operation S504, the program file of the target plug-in is updated in response to completion of the download of the service logic package of the target plug-in. The newly downloaded business logic package may be placed under the same or a file directory associated with the basic functionality package of the target application (e.g., both placed in the folder of the target plug-in), so that after the business logic package is downloaded, the business logic package and the basic functionality package may be combined into a new complete program file of the target plug-in. If the service logic package of the target plug-in is stored in the local before the service logic package of the target plug-in is downloaded, the latest service logic package is correspondingly used for replacing the original service logic package.

In operation S505, the program file of the target plug-in is loaded to start the target plug-in. Thus, the client 202 does not need to start the target plug-in synchronously when it is started, and when the target plug-in is called, it downloads the current latest service logic package and then starts the target plug-in immediately. Because the service logic packet update frequency is high. This way of delaying the start of the target plugin according to the embodiments of the present disclosure makes it unnecessary for the client 202 to care about the version update of the service logic package of the target plugin before the first invocation. And the service logic package used in the first call can be ensured to be the latest version required to be used locally. The impact of updating the business logic package of the target plugin on the client 202 is reduced to some extent.

Finally, in operation S506, the target plug-in is invoked based on the first invocation request.

According to the embodiment of the present disclosure, since the basic function packages of all the plug-ins required locally are already stored locally by synchronizing the basic function packages of the plug-ins stored locally at the time of the body frame startup, when the first call to the target plug-in the client 202 is received, the target plug-in can be loaded and started by the following use of the service function package of the target plug-in. The loading process does not need to restart the main body framework, and because the service logic package capacity is smaller, the user does not feel, and the user does not need extra operation, thereby realizing the dynamic loading of the plug-in.

Fig. 6 schematically illustrates a subsequent call flow diagram of a plug-in an information processing method according to another embodiment of the present disclosure.

As shown in fig. 6, in conjunction with fig. 5, when a subsequent call request to the target plug-in is received after the target plug-in is started, the client 202 may perform operations S601 to S610.

In operation S601, a second call request to a target plug-in is received.

In operation S602, in response to the second call request, a message digest of the service logical package in the program file of the target plug-in is calculated, to obtain a first message digest.

In operation S603, a verification request is sent to the server 201, where the verification request includes the first information digest.

In operation S604, the verification result returned by the server 201 is received.

In operation S605, it is determined, according to the verification result, whether the service logic packet of the local target plug-in is consistent with the service logic packet version of the target plug-in stored in the server 201 for local use. Specifically, when the first information abstract is consistent with the information abstract of the service logic packet of the target plug-in stored in the server 201, the service logic packet in the local target plug-in is consistent with the version in the server 201, otherwise, the description is inconsistent. If so, operation S610 is performed, and if not, operation S606 is performed.

In the embodiment of the present disclosure, the service logic package of the target plug-in stored locally may not be updated when the target plug-in is not called, so that the locally stored service logic package may not need to be automatically downloaded and updated along with the update of the server 201 during the two calls, which avoids the extra update operation and network overhead of the service logic package when the target plug-in is not used, on the one hand, and on the other hand, when the target plug-in is called later, the information abstract of the locally currently stored service logic package may be uploaded to the server 201 for verification, so as to determine whether the service logic package of the target plug-in loaded in the current client 202 is the latest version.

In operation S606, when the service logic package in the local target plugin is inconsistent with the service logic package of the target plugin for local use stored in the server 201, the service logic package of the target plugin is downloaded from the server 201.

In operation S607, the program file of the target plug-in is updated in response to completion of the download of the service logic package of the target plug-in. For example, after the service logic package compression package is downloaded, the data integrity of the compression package is checked, after the data integrity of the compression package is determined, the service logic package of the original target plug-in unit is deleted, and then the compression package is decompressed under the program file directory of the target plug-in unit, so that the program file of the target plug-in unit is updated.

Next, in operation S608, the loaded target plug-in is unloaded.

Then, in operation S609, after the target plug-in is completely unloaded, the program file of the target plug-in is reloaded to restart the target plug-in.

Finally, in operation S610, the target plug-in is invoked based on the second invocation request.

It can be seen that, according to embodiments of the present disclosure, in a subsequent call after the target plug-in is started, by interacting with the server 201 before the target plug-in is called, a request may be made to verify whether the service logic package in the currently loaded target plug-in is the latest version. If yes, directly calling a target plug-in; if not, immediately downloading the latest version of service logic package from the server 201 to update the program file of the target plug-in, then unloading the loaded target plug-in and reloading the program file of the target plug-in to realize the automatic version upgrading of the target plug-in. In this way, the service logic package of the target plug-in can be downloaded from the server 201 only when being called locally if the service logic package needs to be updated, so that the downloading update time of the service logic package is more accurate, and the network overhead of data downloading between the client 202 and the server 201 is reduced.

The basic function package of the plug-in is not updated usually, but if the database or the third party interface on which the plug-in functions depend is changed, the basic function package of the plug-in also has to be updated, otherwise, the plug-in cannot be used normally. Because the update frequency and the effect of the basic function package of the plugin are different from those of the service logic package, in some embodiments of the present disclosure, when the basic function package of the plugin in the server 201 is updated, the client is notified to synchronously update the basic function package of the plugin, and the latest basic function package is enabled in the latest call of the plugin. Reference is made in particular to the description of figures 7 to 9 below.

Fig. 7 schematically illustrates a flowchart of a basic function package of an update package in an information processing method according to an embodiment of the present disclosure.

As shown in fig. 7, the information processing method in the embodiment of the present disclosure may further include operations S701 to S703.

In operation S701, a plug-in basic function package update instruction pushed by the server 201 is received, where the plug-in basic function package update instruction includes update information of a basic function package of the second plug-in.

In operation S702, the basic function package of the second plug-in is downloaded from the server 201 based on the update information of the basic function package of the second plug-in.

In operation S703, the basic function package of the second plug-in is updated in response to completion of the download of the basic function package of the second plug-in.

According to the embodiment of the disclosure, in addition to updating the basic function package of the plug-in unit stored locally through interaction with the server when the main body frame is started, the basic function package of the plug-in unit stored locally can be synchronously updated along with the change information of the basic function package pushed by the server 201 in the operation after the main body frame is started.

Fig. 8 schematically shows a flowchart of a basic function package of an update plug-in an information processing method according to still another embodiment of the present disclosure.

As shown in fig. 8, the process of updating the basic function package of the locally stored second plug-in includes S81 to S88.

S81, receiving a plug-in updating instruction pushed by the server 201, wherein updating of a basic function package of the second plug-in is indicated.

S82, pulling the compressed package of the basic function package of the second plug-in from the GIT version control system under the framework version management module of the server 201.

S83, checking whether the data of the downloaded compressed packet is complete. For example, when summary information of a package to be compressed is included in the plug-in update instruction, the summary information of the downloaded package may be calculated, and then it may be determined whether the downloaded package is complete through comparison of the information summaries. If not, S84 is performed. If so, S85 is performed.

S84, when the downloaded compressed packet is found to be incomplete through verification, abnormal information can be prompted.

And S85, when the downloaded compressed package is found to be complete through verification, judging whether the basic functional package of the second plug-in with the same version exists locally. If so, ending; if not, S86 is performed.

S86, deleting the original basic function package of the second plug-in.

S87, decompressing the downloaded compressed package and storing the compressed package in a directory where a basic function package is located in a program file of the local original second plug-in.

S88, recording the local update time of the basic function package of the second plug-in.

The second plug-in may be a plug-in that has been started (e.g., a target plug-in) or may be a plug-in that has not been started. For a plug-in that has not been started, the update of the plug-in's basic feature package does not affect the plug-in's first invocation procedure. For the started plug-in, after the basic function package of the target plug-in is updated, the program file of the target plug-in needs to be reloaded before or during the next call of the target plug-in. One embodiment of which may be referred to as the illustration of fig. 9.

Fig. 9 schematically illustrates a subsequent call flow diagram of a plug-in an information processing method according to another embodiment of the present disclosure.

As shown in fig. 9, according to the information processing method of this embodiment, operations S901 to S906 may be further included after operations S501 to S506.

In operation S901, a third call request to a target plug-in is received. It should be noted that, herein, the "third call request" and the "second call request" refer to a call request after the first call request (i.e., the first call request) to the target plug-in, and the naming distinction between the two is only for convenience of description and is not limited.

In operation S902, in response to the third call request, time information of loading the target plugin is obtained, and a cache start time is obtained. For example, the time record of loading the target plugin before is searched from the log file of the client 202, so as to determine the cache starting time of the target plugin.

In operation S903, the time information of the last update of the basic function package of the target plug-in is obtained, and the latest update time is obtained.

By comparing the cache start time with the latest update time, it can be determined whether the basic function package of the target plug-in has been updated after the target plug-in has been loaded.

Specifically, when the cache start time is later than the latest update time, it indicates that the basic function package of the target plug-in has not been changed after the target plug-in is loaded, in this case, in some embodiments, the call of the target plug-in may be performed with reference to operations S602 to S610 in fig. 6.

When the starting time of the cache is earlier than the latest updating time, the basic function package of the target plug-in after the target plug-in is loaded is indicated to be changed, and the target plug-in needs to be reloaded before the target plug-in is called this time to enable a new basic function package, and the implementation process is as follows.

In operation S904, when the cache start time is earlier than the latest update time, the loaded target plug-in is unloaded.

In operation S905, after the target plug-in is completely unloaded, the program file of the target plug-in is reloaded and the target plug-in is restarted.

In other embodiments, when the basic function package update is found to result in the need to reload the target plugin, it may also be determined whether the service logic package of the target plugin currently stored locally is the latest version by performing operations S904 and S905 as described in the foregoing operations S602 to S605. If so, operations S904 and S905 are performed; if not, the service logic package of the target plug-in may be downloaded and updated first, and then operations S904 and S905 are performed. Of course, in some embodiments, when the update of the basic functional package results in that the target plug-in needs to be reloaded, since the probability of updating the basic functional package and the business logic package in the same time period is relatively low, and the business logic package with a low version is usually available, the program file of the currently stored target plug-in can be directly loaded from the local place regardless of whether the version of the business logic package stored locally is up to date.

In operation S906, the target plug-in is invoked based on the third invocation request in response to the restart of the target plug-in.

In the embodiment of the disclosure, when the class loader is used for loading the plug-in, when the loaded target plug-in is unloaded and a new target plug-in is loaded again from the local place, a new class loader for loading the target plug-in can be created before the unloading is executed, then the new class loader is started to load the target plug-in, and meanwhile, the original class loader for loading the target plug-in before is closed, and memory resources occupied by the original class loader are released, so that the memory leakage can be prevented.

It can be seen that in the client 202 of the disclosed embodiment, the basic function package and the business logic package of the plug-in can be updated and used according to different update logic. For the basic function package, due to the large volume and low update frequency, the basic function package can be synchronized to be consistent with the server 201 when the main body framework is started, and the local basic function package can be updated synchronously along with the update operation of the server 201. For the service logic package, due to small volume and high update frequency, the service logic package of the latest version can be downloaded from the server 201 when the target plug-in is called if updating is needed, so that the service logic package can be used as needed. In this way, while meeting the use requirement of the plug-in of the client 202, the data transmission between the client 202 and the server 201 can be reduced, the plug-in update frequency of the client 202 is reduced, and the loading process of the plug-in can be performed in the running process of the main body framework, so that dynamic loading can be realized, and no perception is achieved for a user.

Unlike the plug-in which can perform version upgrade by dynamic loading, the version update of the main body frame needs to be turned off and restarted by the client 202, so as to facilitate automatic update of the main body frame, and minimize the operations of the user.

Fig. 10 schematically shows a flowchart of updating a main body framework in the information processing method of an embodiment of the present disclosure.

As shown in fig. 10, the information processing method of this embodiment may further include operations S1001 to 1005, in addition to the various operations described above. The client 202 can automatically update the main body frame in operations S1001 to S1005.

First, in operation S1001, a timing task is registered in response to the start of the main body framework.

Then, in operation S1002, version update information of the main body frame is acquired from the server 201 at regular time by the timing task. For example, the timing task may query the version update information of the subject framework from a framework version management module in the server 201.

In one embodiment, the body frame may actively report version information of the body frame to the server 201 at startup. The server 201 registers version information of the main body frame in a main body frame version field in the client management module. After the server 201 updates the version of the main body frame, the server 201 may return version update information of the main body frame to the client 202 according to the version information query request of the timing task. In this way, the designated main body frame version query update information can be returned to the client 202 according to the client dimension, so that the main body frame version can be issued according to the gray scale of the client dimension.

Next, in operation S1003, when the version update of the main body frame is determined according to the version update information, the program file of the new version main body frame is downloaded from the server 201.

Meanwhile, in operation S1004, a main body frame upgrade program is acquired, for example, a hook program is registered using a hook technology, or a corresponding script is downloaded from the server 201.

Next, in operation S1005, a main body frame upgrade program is run. Wherein the main body frame upgrade program is configured to: closing the body frame, reinstalling the body frame based on the program file of the new version body frame in response to the closing of the body frame, and transmitting a start instruction to the client 202 in response to the installation of the body frame being completed.

When the main body framework upgrade program sends the start instruction, the client 202 receives the start instruction, and the process shown in fig. 5 may be executed, so as to implement automatic operation of the client 202.

In this way, after the program file of the new version main body frame is downloaded, the main body frame can be automatically updated by means of the main body frame upgrading program, so that the problem that a client user needs to manually download the new version and manually update the new version is avoided.

Fig. 11 schematically illustrates a flowchart of updating a main body framework in an information processing method according to another embodiment of the present disclosure.

As shown in fig. 11, the flow of updating the main body frame of this embodiment may include S111 to S119.

S111, starting the main body frame.

S112, registering a timing task, and inquiring whether the version of the main body frame is upgraded or not from the service end 201 through the timing task.

S113, the frame version management module in the server 201 returns the version number of the main body frame program file corresponding to the client managed in the GIT version control system, and obtains the main version number.

S114, comparing whether the main version number is consistent with the version number of the local main body frame. And if the two types of the data are consistent, ending. If not, S115 is executed.

S115, request the latest version file download from the server 201.

S116, after the file package of the main body frame of the latest version is downloaded from the server 201, whether the file package is complete is checked. If not, reporting abnormality and ending; if yes, S117 is performed.

S117, decompressing the file package of the main body frame of the latest version to the corresponding catalogue.

S118, registering a hook program by adopting a hook technology. The hook program is associated with the running main body frame on one hand, and is used for closing the main body frame after registration is completed, and is associated with a start script in a new version of main body frame program file, and is used for triggering the execution of the start script after closing the main body frame, and the installation of the new version of main body frame is started through the start script.

S119, running a hook program to update a version of the main body frame by the hook program, including: closing the main body frame by the hook program, executing the starting script, installing the main body frame of the new version, and sending a starting instruction to the client 202 after the main body frame of the new version is installed, so as to start the client 202.

It can be seen that when using the client 202 according to the embodiment of the present disclosure, the client user may only pay attention to the first download and installation of the client 202, and the updating, upgrading, unloading and loading of the subsequent plug-ins and the upgrading of the main body framework may all be automatically processed, so that the user experience is greatly improved.

Based on the information processing method applied to the client in each embodiment, the disclosure also provides an information processing device arranged at the client. The device will be described in detail below in connection with fig. 12.

Fig. 12 schematically shows a block diagram of an information processing apparatus 1200 according to an embodiment of the present disclosure. The information processing apparatus 1200 may be provided in the client 202.

As shown in fig. 12, according to some embodiments of the present disclosure, an apparatus 1200 may include a startup module 1210, a local plug-in management module 1220, and a plug-in dynamic loading module 1230. According to further embodiments of the present disclosure, the apparatus 1200 may further include a framework version upgrade module 1240. The apparatus 1200 may perform the methods described with reference to fig. 5-11.

The initiation module 1210 is configured to initiate a body frame of the client 202 in response to receiving the initiation instruction. In one embodiment, the start module 1210 may perform operation S501 described above.

The local plugin management module 1220 is configured to synchronize, in response to the initiation of the main framework, a basic function package of each plugin in the local plugin manifest from the server 201, where a program file of each plugin includes a basic function package and a service logic package, where an update frequency of the basic function package is lower than that of the service logic package, and the local plugin manifest includes information of all plugins locally required. In one embodiment, the local plugin management module 1220 may perform operation S502 described previously.

The plug-in dynamic loading module 1230 is configured to: when a first call request to the target plugin is received under the condition that the target plugin is not started, downloading a service logic package of the target plugin from the server 201; updating the program file of the target plug-in unit in response to the completion of downloading the service logic package of the target plug-in unit; loading a program file of the target plug-in to start the target plug-in; and invoking the target plugin based on the first invocation request. In one embodiment, the plug-in dynamic loading module 1230 may perform operations S503-S506 described previously.

In some embodiments, the plug-in dynamic loading module 1230 is also used to: after loading the program file of the target plug-in to start the target plug-in, receiving a second call request for the target plug-in; responding to the second call request, calculating the information abstract of the business logic package in the program file of the target plug-in to obtain a first information abstract; sending a verification request to the server 201, wherein the verification request comprises a first information abstract; receiving a verification result returned by the server 201; and when the verification result shows that the first information abstract is consistent with the information abstract of the business logic package of the target plug-in stored in the server 201, calling the target plug-in based on the second calling request.

In other embodiments, the plug-in dynamic loading module 1230 is also configured to: when the verification result shows that the first information abstract is inconsistent with the information abstract of the service logic package of the target plug-in stored in the server 201, downloading the service logic package of the target plug-in from the server 201; updating the program file of the target plug-in unit in response to the completion of downloading the service logic package of the target plug-in unit; unloading the loaded target plugin; after the target plug-in is completely unloaded, reloading the program file of the target plug-in to restart the target plug-in; and invoking the target plugin based on the second invocation request in response to the restart of the target plugin.

The framework version upgrade module 1240 is configured to: in response to the start of the main body frame, registering a timing task by which version update information of the main body frame is acquired from the server 201 at a timing; when version update of the main body frame is determined according to the version update information, the program file of the new version main body frame is downloaded from the server 201; acquiring a main body frame upgrading program; and running the main body framework upgrading program. Wherein the main body frame upgrade program is configured to: closing the main body frame; reinstalling the body frame based on the program files of the new version body frame in response to the closing of the body frame; and in response to the installation of the body frame being completed, sending a startup instruction to the client 202. In one embodiment, the framework version upgrade module 1240 may perform operations S1001 through S1005 described above.

Any of the start-up module 1210, the local plug-in management module 1220, the plug-in dynamic loading module 1230, and the framework version upgrade module 1240 may be combined in one module to be implemented, or any of the modules may be split into multiple modules, according to embodiments of the present disclosure. Or at least some of the functionality of one or more of the modules may be combined with, and implemented in, at least some of the functionality of other modules. According to embodiments of the present disclosure, at least one of the start-up module 1210, the local plug-in management module 1220, the plug-in dynamic loading module 1230, and the framework version upgrade module 1240 may be implemented, at least in part, as hardware circuitry, such as a Field Programmable Gate Array (FPGA), a Programmable Logic Array (PLA), a system-on-chip, a system-on-substrate, a system-on-package, an Application Specific Integrated Circuit (ASIC), or may be implemented in hardware or firmware in any other reasonable manner of integrating or packaging circuitry, or in any one of or a suitable combination of any of the three. Or at least one of the start-up module 1210, the local plug-in management module 1220, the plug-in dynamic loading module 1230 and the framework version upgrade module 1240 may be at least partially implemented as a computer program module which, when executed, performs the corresponding functions.

As shown in fig. 13, an electronic device 1300 according to an embodiment of the present disclosure includes a processor 130 that can perform various appropriate actions and processes according to a program stored in a Read Only Memory (ROM) 302 or a program loaded from a storage portion 1308 into a Random Access Memory (RAM) 1303. Processor 1301 may include, for example, a general purpose microprocessor (e.g., a CPU), an instruction set processor and/or an associated chipset and/or a special purpose microprocessor (e.g., an Application Specific Integrated Circuit (ASIC)), or the like. Processor 1301 may also include on-board memory for caching purposes. Processor 1301 may include a single processing unit or multiple processing units for performing different actions of the method flow according to embodiments of the present disclosure.

In the RAM 1303, various programs and data necessary for the operation of the electronic apparatus 1300 are stored. The processor 1301, the ROM 1302, and the RAM 1303 are connected to each other through a bus 1304. The processor 1301 performs various operations of the method flow according to the embodiment of the present disclosure by executing programs in the ROM 1302 and/or the RAM 1303. Note that the program may be stored in one or more memories other than the ROM 1302 and the RAM 1303. Processor 1301 may also perform various operations of the method flow according to embodiments of the present disclosure by executing programs stored in the one or more memories.

According to an embodiment of the disclosure, the electronic device 1300 may also include an input/output (I/O) interface 1305, the input/output (I/O) interface 1305 also being connected to the bus 1304. The electronic device 1300 may also include one or more of the following components connected to the I/O interface 1305: an input section 1306 including a keyboard, a mouse, and the like; an output portion 1307 including a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), and the like, and a speaker, and the like; a storage portion 1308 including a hard disk or the like; and a communication section 1309 including a network interface card such as a LAN card, a modem, or the like. The communication section 1309 performs a communication process via a network such as the internet. The drive 1310 is also connected to the I/O interface 1305 as needed. Removable media 1311, such as magnetic disks, optical disks, magneto-optical disks, semiconductor memory, and the like, is installed as needed on drive 1310 so that a computer program read therefrom is installed as needed into storage portion 1308.

The present disclosure also provides a computer-readable storage medium that may be embodied in the apparatus/device/system described in the above embodiments; or may exist alone without being assembled into the apparatus/device/system. The computer-readable storage medium carries one or more programs which, when executed, implement methods in accordance with embodiments of the present disclosure.

According to embodiments of the present disclosure, the computer-readable storage medium may be a non-volatile computer-readable storage medium, which may include, for example, but is not limited to: a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this disclosure, a computer-readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. For example, according to embodiments of the present disclosure, the computer-readable storage medium may include ROM 1302 and/or RAM 1303 described above and/or one or more memories other than ROM 1302 and RAM 1303.

Embodiments of the present disclosure also include a computer program product comprising a computer program containing program code for performing the methods shown in the flowcharts. The program code means for causing a computer system to carry out the information processing method provided by the embodiments of the present disclosure when the computer program product is run on the computer system.

The above-described functions defined in the system/apparatus of the embodiments of the present disclosure are performed when the computer program is executed by the processor 1301. The systems, apparatus, modules, units, etc. described above may be implemented by computer program modules according to embodiments of the disclosure.

In one embodiment, the computer program may be based on a tangible storage medium such as an optical storage device, a magnetic storage device, or the like. In another embodiment, the computer program can also be transmitted, distributed over a network medium in the form of signals, downloaded and installed via the communication portion 1309, and/or installed from the removable medium 1311. The computer program may include program code that may be transmitted using any appropriate network medium, including but not limited to: wireless, wired, etc., or any suitable combination of the foregoing.

In such embodiments, the computer program may be downloaded and installed from a network via the communication portion 1309 and/or installed from the removable medium 1311. The above-described functions defined in the system of the embodiments of the present disclosure are performed when the computer program is executed by the processor 1301. The systems, devices, apparatus, modules, units, etc. described above may be implemented by computer program modules according to embodiments of the disclosure.

According to embodiments of the present disclosure, program code for performing computer programs provided by embodiments of the present disclosure may be written in any combination of one or more programming languages, and in particular, such computer programs may be implemented in high-level procedural and/or object-oriented programming languages, and/or assembly/machine languages. Programming languages include, but are not limited to, such as Java, c++, python, "C" or similar programming languages. The program code may execute entirely on the user's computing device, partly on the user's device, partly on a remote computing device, or entirely on the remote computing device or server. In the case of remote computing devices, the remote computing device may be connected to the user computing device through any kind of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or may be connected to an external computing device (e.g., connected via the Internet using an Internet service provider).

The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams or flowchart illustration, and combinations of blocks in the block diagrams or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

Those skilled in the art will appreciate that the features recited in the various embodiments of the disclosure and/or in the claims may be provided in a variety of combinations and/or combinations, even if such combinations or combinations are not explicitly recited in the disclosure. In particular, the features recited in the various embodiments of the present disclosure and/or the claims may be variously combined and/or combined without departing from the spirit and teachings of the present disclosure. All such combinations and/or combinations fall within the scope of the present disclosure.

The embodiments of the present disclosure are described above. These examples are for illustrative purposes only and are not intended to limit the scope of the present disclosure. Although the embodiments are described above separately, this does not mean that the measures in the embodiments cannot be used advantageously in combination. The scope of the disclosure is defined by the appended claims and equivalents thereof. Various alternatives and modifications can be made by those skilled in the art without departing from the scope of the disclosure, and such alternatives and modifications are intended to fall within the scope of the disclosure.

Claims

1. An information processing method applied to a client, comprising the following steps:

in response to receiving a start instruction, starting a main body frame of the client;

Responding to the starting of the main body framework, synchronizing basic function packages of each plug-in a local plug-in list from a server side, wherein a program file of each plug-in comprises a basic function package and a service logic package, the updating frequency of the basic function package is lower than that of the service logic package, and the local plug-in list comprises information of all plug-ins required locally;

When a first call request to a target plug-in is received under the condition that the target plug-in is not started, downloading a business logic package of the target plug-in from the server;

Updating the program file of the target plug-in unit in response to the completion of the downloading of the business logic package of the target plug-in unit;

Loading a program file of the target plug-in to start the target plug-in; and

And calling the target plug-in based on the first calling request.

2. The method of claim 1, wherein after the loading of the program file of the target plug-in to launch the target plug-in, the method further comprises:

receiving a second call request to the target plugin;

Responding to the second call request, calculating the information abstract of the service logic package in the program file of the target plug-in to obtain a first information abstract;

Sending a verification request to the server, wherein the verification request comprises the first information abstract;

receiving a verification result returned by the server;

and when the verification result shows that the first information abstract is consistent with the information abstract of the business logic package of the target plug-in stored in the server, calling the target plug-in based on the second calling request.

3. The method of claim 2, wherein the method further comprises:

When the verification result shows that the first information abstract is inconsistent with the information abstract of the business logic package of the target plug-in stored in the server, downloading the business logic package of the target plug-in from the server;

unloading the loaded target plugin;

after the target plug-in is completely unloaded, reloading the program file of the target plug-in to restart the target plug-in; and

And responding to the restarting of the target plug-in, and calling the target plug-in based on the second calling request.

4. The method of claim 1, wherein after synchronizing the basic function package of each plug-in the local plug-in manifest from the server in response to the initiation of the body framework, the method further comprises:

Receiving a plug-in basic function package updating instruction pushed by the server, wherein the plug-in basic function package updating instruction comprises updating information of a basic function package of a second plug-in;

downloading the basic function package of the second plug-in from the server based on the update information of the basic function package of the second plug-in; and

And updating the basic function package of the second plug-in response to completion of downloading of the basic function package of the second plug-in.

5. The method of claim 4, wherein after the loading of the program file of the target plug-in to launch the target plug-in, the method further comprises:

receiving a third call request to the target plugin;

Responding to the third call request, obtaining time information for loading the target plug-in, and obtaining a cache starting moment;

acquiring the latest updated time information of the basic function package of the target plug-in to obtain the latest updated time;

Unloading the loaded target plug-in when the cache starting time is earlier than the latest updating time;

after the target plug-in is completely unloaded, reloading the program file of the target plug-in and restarting the target plug-in; and

And responding to the restarting of the target plug-in, and calling the target plug-in based on the third calling request.

6. The method of claim 1, wherein the method further comprises:

Registering a timed task in response to the initiation of the body frame;

The version updating information of the main body frame is acquired from the server at regular time through the timing task;

when the version update of the main body frame is determined according to the version update information, downloading a program file of the main body frame with a new version from the server;

Acquiring a main body frame upgrading program; and

Running the main body frame upgrade program, wherein the main body frame upgrade program is configured to: closing the main body frame; reinstalling the body frame based on the program files of the new version body frame in response to the closing of the body frame; and sending the start instruction to the client in response to the installation of the main body frame being completed.

7. The method of claim 6, wherein the acquiring a subject frame upgrade procedure comprises:

registering a hook program; the hook program is respectively hooked with the main body frame and the starting script of the program file of the new version main body frame.

8. The method of claim 1, wherein synchronizing the basic functionality packages of each plug-in the local plug-in manifest from the server in response to the initiation of the body framework comprises:

sending a local plug-in information request to a server;

receiving the local plug-in list returned by the server, wherein the local plug-in list comprises information summaries of basic function packages of all plug-ins required locally;

Acquiring a local existing plug-in list, wherein the local existing plug-in list comprises locally stored information abstracts of basic function packages of all plug-ins;

the information of at least one first plug-in with inconsistent information in the local plug-in list and the local existing plug-in list is obtained by comparing the local plug-in list and the local existing plug-in list; and

Updating a locally stored basic function package of at least one first plug-in based on the information of the at least one first plug-in.

9. The method of claim 8, wherein updating the locally stored basic functionality packages of at least one of the first plug-ins based on the information of the at least one of the first plug-ins comprises:

deleting the locally stored program file of the first plug-in when the first plug-in does not belong to the local plug-in list;

When the first plug-in does not belong to the local existing plug-in list, downloading a basic function package of the first plug-in from the server and storing the basic function package to the local; and

And when the first plug-in belongs to the local existing plug-in list and the local plug-in list at the same time, downloading the basic function package of the first plug-in from the service end and replacing the basic function package of the first plug-in stored locally.

10. An information processing apparatus provided at a client, comprising:

the starting module is used for responding to the received starting instruction and starting the main body framework of the client;

The local plug-in management module is used for: responding to the starting of the main body framework, synchronizing basic function packages of each plug-in a local plug-in list from a server side, wherein a program file of each plug-in comprises a basic function package and a service logic package, the updating frequency of the basic function package is lower than that of the service logic package, and the local plug-in list comprises information of all plug-ins required locally;

plug-in dynamic loading module, is used for:

Loading a program file of the target plug-in to start the target plug-in; and

And calling the target plug-in based on the first calling request.

11. An electronic device, comprising:

One or more processors;

a memory for storing one or more programs,

Wherein the one or more programs, when executed by the one or more processors, cause the one or more processors to perform the method of any of claims 1-9.

12. A computer readable storage medium having stored thereon executable instructions which, when executed by a processor, cause the processor to perform the method of any of claims 1 to 9.