CN112486569B - Plug-in SDK generation method, device, computer equipment and storage medium - Google Patents

Plug-in SDK generation method, device, computer equipment and storage medium Download PDF

Info

Publication number
CN112486569B
CN112486569B CN202011231744.6A CN202011231744A CN112486569B CN 112486569 B CN112486569 B CN 112486569B CN 202011231744 A CN202011231744 A CN 202011231744A CN 112486569 B CN112486569 B CN 112486569B
Authority
CN
China
Prior art keywords
plug
sdk
code
class
name
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202011231744.6A
Other languages
Chinese (zh)
Other versions
CN112486569A (en
Inventor
陶学诚
张国祥
朱晓鑫
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Guangzhou Sanqi Network Technology Co ltd
Original Assignee
Guangzhou Sanqi Network Technology Co ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Guangzhou Sanqi Network Technology Co ltd filed Critical Guangzhou Sanqi Network Technology Co ltd
Priority to CN202011231744.6A priority Critical patent/CN112486569B/en
Publication of CN112486569A publication Critical patent/CN112486569A/en
Application granted granted Critical
Publication of CN112486569B publication Critical patent/CN112486569B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/70—Software maintenance or management
    • G06F8/76—Adapting program code to run in a different environment; Porting
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/362—Software debugging
    • G06F11/3628—Software debugging of optimised code

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Stored Programmes (AREA)

Abstract

The application relates to a plug-in SDK generation method, a device, computer equipment and a storage medium, wherein the method comprises the following steps: acquiring an SDK code of a non-plug-in board; acquiring a first code of a system class and a first name of a first pair of external interface classes in a non-plug-in SDK code; converting the first code into a second code of a non-component base class, converting the first name into a preset second name, so that the names of a first pair of external interface classes after the name conversion are different from the names of a second pair of external interface classes corresponding to the first pair of external interface classes in a host, and obtaining the code to be converted; and generating a plug-in SDK of the plug-in board according to the code to be converted, wherein the plug-in SDK communicates with the outside through a second external interface class of the host. The method can reduce the generation amount of the SDK codes so as to reduce resource waste and reduce the maintenance cost of manually maintaining the game app codes.

Description

Plug-in SDK generation method, device, computer equipment and storage medium
Technical Field
The present application relates to the field of code processing technologies, and in particular, to a method and apparatus for generating a plug-in SDK, a computer device, and a storage medium.
Background
SDK (Software Development Kit ) refers to a collection of related documents, examples, and development tools provided in assisting in developing a particular app (Application), including utility tools for debugging and other purposes. It may simply provide some files of an application programming interface api (Application Programming Interface ) for a programming language, may include complex hardware capable of communicating with an embedded system, and may include example code, supporting technical notes, or other supporting documents that clarify erasures for basic references.
In game app release, the combination of three codes, i.e., a research and development SDK code, an issuer SDK code, and a channel SDK code, is involved. Therefore, the rollback scheme when the multiparty scheme conflicts needs to be considered when realizing the plugin. For example, if the channel side SDK uses the plug-in technology, and the issuer also uses the plug-in technology when providing the game app code, there is a conflict in technology implementation, and the issuer is required to rollback the plug-in SDK to be a non-plug-in mode. Otherwise, the issuer provides the plug-in SDK externally. In this case, the cost of implementing a set of plug-in versions and a set of non-plug-in versions of the SDKs by the issuer will be high at subsequent maintenance. It is also desirable to provide a suite of plug-in versions of SDKs and a suite of non-plug-in versions of SDKs in order to match the two schemes. Therefore, two sets of SDK codes are required to be generated in research and development, so that not only is the resource wasted, but also the labor consumption is high.
Disclosure of Invention
In view of the foregoing, it is desirable to provide a plug-in SDK generation method, apparatus, computer device, and storage medium that can reduce the generation amount of SDK codes to reduce resource waste and reduce maintenance costs for manually maintaining game app codes.
A plug-in SDK generation method, the method comprising: acquiring an SDK code of a non-plug-in board; querying a first code of a system class and a first name of a first pair of external interface classes in the SDK code of the non-plug-in board; converting the first code into a second code of a non-component base class, converting the first name into a preset second name, so that the names of a first pair of external interface classes after the name conversion are different from the names of a second pair of external interface classes corresponding to the first pair of external interface classes in a host, and obtaining the code to be converted; and generating a plug-in SDK of the plug-in board according to the code to be converted, wherein the plug-in SDK communicates with the outside through a second external interface class of the host.
In one embodiment, the system class includes one or more of a class of Activity components, a class of Service components, a class of ContentProvider components, a class of BroadcastReceiver components, and an Application class, and the converting the first code to a second code that is not a component-based class includes: in the transformation link of the gradle plugin, the code of the class of the Activity component or the code of the class of the Service component or the code of the class of the ContentProvider component or the code of the class of the BroadcastReceiver component or the code of the Application class is converted into a second code of the non-component base class.
Preferably, converting the first name into a preset second name includes: in the transform link of the gradle plug-in, the first name is converted into a pre-determined second name by adopting the javassist java byte code modification technology.
In one embodiment, a plug-in SDK generating method further includes: generating a host code of a host, wherein the name of a second external interface class in the host code is the same as the name of a third external interface class in the SDK code of the non-plug-in board, and the SDK code of the non-plug-in board communicates with the outside through the third external interface class.
In one embodiment, a plug-in SDK generating method further includes: acquiring identification information of classes in the plug-in SDK; obtaining a proxy class corresponding to a class in the plug-in SDK in the host code; and associating the identification information of the class in the plug-in SDK with the proxy class so that the proxy class loads the class in the plug-in SDK through the identification information.
In one embodiment, associating the identification information of the class in the plug-in SDK with the proxy class so that the proxy class loads the class in the plug-in SDK with the identification information includes: the control agent class calls the class in the plug-in SDK by identifying the identification information and adopting a reflection mode to load the class in the plug-in SDK.
In one embodiment, a plug-in SDK generating method further includes: acquiring a first resource package of a non-plug-in SDK code; acquiring a first file packet corresponding to a first resource packet in a plug-in SDK; and replacing the first file package in the plug-in SDK with the first resource package to obtain a replaced SDK code of the non-plug-in.
Preferably, before obtaining the first resource package of the non-plug-in SDK code, the method further includes: one or more first target resource packages are extracted from the SDK code of the non-plug-in board, and a first resource package is obtained, wherein the first resource package comprises one or more first target resource packages.
In one embodiment, after replacing the first package of files in the plug-in SDK with the first package of resources to obtain the replaced SDK code of the non-plug-in, the method further includes: acquiring a second resource package of the plug-in SDK; acquiring a second file packet corresponding to a second resource packet in the replaced SDK code of the non-plug-in board; and replacing a second file package of the replaced SDK code of the non-plug-in board with the second resource package to obtain the replaced SDK of the plug-in board.
Preferably, obtaining the second resource package of the plug-in SDK includes: and extracting one or more second target resource packages from the plug-in SDK to obtain second resource packages, wherein the second resource packages comprise one or more second target resource packages.
A plug-in SDK generating apparatus, the apparatus comprising: the acquisition module is used for acquiring the SDK code of the non-plug-in board; the query module is used for querying a first code of a system class and a first name of a first pair of external interface classes in the SDK code of the non-plug-in board; the conversion module is used for converting the first code into a second code of a non-component base class, converting the first name into a preset second name, so that the name of a first pair of external interface classes after the conversion of the names is different from the name of a second pair of external interface classes corresponding to the first pair of external interface classes in a host, and obtaining the code to be converted; and the generating module is used for generating a plug-in SDK of the plug-in board according to the code to be converted, and the plug-in SDK communicates with the outside through a second external interface class of the host.
A computer device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, the processor implementing the steps of any of the methods of the embodiments described above when the computer program is executed by the processor.
A computer readable storage medium having stored thereon a computer program which when executed by a processor performs the steps of the method of any of the embodiments described above.
According to the plug-in SDK generation method, the device, the computer equipment and the storage medium, the issuer system obtains the non-plug-in SDK code, inquires the first code of the system class and the first name of the first pair of external interface classes in the non-plug-in SDK code, converts the first code into the second code of the non-component base class, converts the first name into the preset second name, and enables the names of the first pair of external interface classes after the name conversion to be different from the names of the second pair of external interface classes corresponding to the first pair of external interface classes in the host, so that the code to be converted is obtained. And finally, generating a plug-in SDK of the plug-in board according to the code to be converted, wherein the plug-in SDK communicates with the outside through a second external interface class of the host. Therefore, when the plug-in SDK and the non-plug-in SDK are required to be provided externally, the system only needs to maintain one set of non-plug-in SDK codes. When testing is performed on the SDK code of the external non-plug-in version, and the plug-in SDK can be used externally, modifying the first code of the system class and the first name of the first external interface class in the SDK code of the non-plug-in version maintained in the system to generate a corresponding plug-in SDK. Because the converted second name of the first external interface class is different from the name of the second external interface class of the host, external communication of the plug-in SDK through the second external interface class of the host can be realized, so that the conversion of the SDK code of the non-plug-in edition into the plug-in SDK is realized, a set of plug-in SDK is not required to be independently arranged, and the waste of resources in the system is reduced. Meanwhile, the system does not need to maintain two sets of SDKs at the same time, so that the maintenance cost of manually maintaining the game app codes is reduced.
Drawings
FIG. 1 is an application environment diagram of a plug-in SDK generation method in one embodiment;
FIG. 2 is a flow diagram of a plug-in SDK generation method in one embodiment;
FIG. 3 is a flow chart of a method of applying a plug-in SDK in one embodiment;
FIG. 4 is a block diagram of a plug-in SDK generation device in one embodiment;
Fig. 5 is an internal structural diagram of a computer device in one embodiment.
Detailed Description
The present application will be described in further detail with reference to the drawings and examples, in order to make the objects, technical solutions and advantages of the present application more apparent. It should be understood that the specific embodiments described herein are for purposes of illustration only and are not intended to limit the scope of the application.
The plug-in SDK generation method provided by the application is applied to an application environment shown in figure 1. In game app release, a combination of three codes, a research and development SDK code provided by the research and development system 104, an issuer SDK code provided by the issuer system 106, and a canal SDK code provided by the canal system 102, is involved. When either party uses the plugin scheme, the other party can no longer use the plugin technique. For example, the channel side SDK code uses a plug-in technique, and the issuer SDK code provided by the issuer system 106 cannot use the plug-in technique any more in order to avoid a conflict in the technique. Conversely, if the plug-in technology is not used by other parties, the plug-in technology may be used by the issuer SDK code provided by the issuer system 106. In the present application, the issuer system 106 is configured to implement a plug-in SDK generating method of the present application, where the issuer system 106 can implement conversion between a non-plug-in SDK and a plug-in SDK by only maintaining a set of non-plug-in SDK codes. Specifically, the issuer system 106 obtains the non-plug-in SDK code from the database 108, and obtains the first code of the system class and the first name of the first pair of external interface classes in the non-plug-in SDK code. Further, converting the first code into a second code of a non-component base class, and converting the first name into a preset second name, so that the names of the first pair of external interface classes after the name conversion are different from the names of the second pair of external interface classes corresponding to the first pair of external interface classes in the host, and obtaining the code to be converted. And finally, generating a plug-in SDK of the plug-in board according to the code to be converted. The plug-in SDK communicates externally through a host, and the host communicates externally through a second external interface class. Thus, when the plug-in SDK within the issuer system 106 is invoked, the external system directly invokes the second external interface class of the host to communicate with the host. The host invokes the first pair of external interface classes of the plug-in SDK again, and further invokes the plug-in SDK to implement the functions within the plug-in SDK. Because the system class in the plug-in SDK is converted into the non-component base class, no conflict is generated with the system class in the host when the host call is realized. Meanwhile, because the names of the first pair of external interface classes in the plug-in SDK are different from the names of the second pair of external interface classes of the host, the external system can not generate contradiction and conflict when calling the host. Thus, it is achieved that the issuer system 106 transcodes the internal non-plug-in version of the SDK to obtain a plug-in SDK.
In one embodiment, as shown in fig. 2, a plug-in SDK generation method is provided, and the method is applied to the issuer system 106 in fig. 1 for illustration, and includes the following steps:
s102, acquiring SDK codes of non-plug-in boards.
In this embodiment, the non-plug-in SDK code is stored in a database, and a set of non-plug-in SDK code is maintained in the system. In the test process, the system adopts the SDK code of the non-plug-in board to carry out test and check. When it is checked that the plug-in technology is available to the outside, the system provides the plug-in SDK to the outside. Classes in the non-plug-in SDK code include system classes and non-system classes. The system class refers to a class containing the attribute and the method of the system, and in the running process, the system class executes the internal method according to the attribute of the system in the system class so as to realize the business logic on the operation of the system. The method of the system class in the SDK code of the non-plug-in board can call the method of the system class in the implementation process. Specifically, the system class in the non-plug-in SDK code comprises a class of four large components, and the four large components comprise an Activity component, a Service component, a ContentProvider component and a BroadcastReceiver component in Android. The system class also includes an Application class. The non-system class in the non-plug-in SDK code may be a non-component base class. In the implementation process, the method of the base class of the non-component does not need to call the method of the system class, and the interface is empty for being called by the system class.
S104, inquiring a first code of a system class and a first name of a first pair of external interface classes in the SDK code of the non-plug-in board.
In this embodiment, the system queries a first code of a system class in the non-plug-in SDK code and a first pair of external interface classes of the non-plug-in SDK code. The system class refers to a class which calls a system method and performs a system function in the running process, and is loaded by a class loader of the system. The first code of the system class includes the code of the Activity component, the code of the Service component, the code of the ContentProvider component, the code of the BroadcastReceiver component, and the first code also includes the code of the Application class. Specifically, when loading the first code of the system class, the system verifies which class loader the first code is loaded by. Since the first code belongs to the code of the system class, the first code is loaded by the class loader of the system. In addition, the first external interface class of the non-plug-in SDK code is an interface class called when the external system communicates, the external system communicates with the SDK generated by the non-plug-in SDK code by calling the first external interface class, and meanwhile, the SDK generated by the non-plug-in SDK code communicates with the external system by calling the first external interface class. Specifically, the service corresponding to the system realizes the corresponding function by calling the first external interface class of the SDK code of the non-plug-in board and the first code of the system class and the codes of other non-system classes in the SDK code of the non-plug-in board.
S106, converting the first code into a second code of a non-component base class, and converting the first name into a preset second name so that the names of the first pair of external interface classes after the name conversion are different from the names of the second pair of external interface classes corresponding to the first pair of external interface classes in the host, thereby obtaining the code to be converted.
In this embodiment, the SDK code of the non-plug-in board is a code for implementing a specific non-plug-in function, which is called by a service corresponding to the system. The first code of the system class in the non-plug-in SDK code belongs to the code of the system class, and the first code is loaded by a class loader of the system. In the process of generating the plug-in SDK by transcoding the non-plug-in SDK, if the attribute of the first code is not changed, the system detects that the first code is loaded by a class loader of the system, and the host apk corresponding to the first code is not loaded by the same class loader, so that the system can report errors abnormally. After the first code is converted into the second code of the non-component base class, the system class in the non-plug-in SDK code becomes a common class which can be called, and the converted second code can be called in a proxy class calling mode in a host. At this time, the second code and the host apk are loaded by the same class loader, thereby realizing the function of the plug-in SDK. In a specific application scenario, the specific operation of converting the first code into the second code of the non-component base class is: and acquiring a parent class in the SDK code of the non-plug-in version, and screening out a system class from the parent class. Such as screening four component classes from parent classes and Application classes, modifying the parent classes to non-component base classes.
An example of an Activity class is illustrated: the parent class of SDKACTIVITY classes in the non-plug-in SDK code is replaced by a common base class, and the SDKACTIVITY classes are only common java classes. A ProxyActivity class is defined in the host, is a real Activity class and belongs to a system class. A corresponding method in class ProxyActivity, such as onCreate method call SDKACTIVITY in onCreate method, can proxy class ProxyActivity to execute class SDKACTIVITY. Thus, a plug-in agent for non-plug-in SDK code may be implemented. At this time, the system can directly convert the non-plug-in version of the SDK maintained internally into a plug-in SDK for use.
In addition, the name of the first external interface class in the non-plug-in SDK code, namely the first name, is the same as the name of the second external interface class of the external communication in the host. In order to enable the host to communicate externally through the second external interface class without generating abnormality, the first name of the first external interface class in the SDK code of the non-plug-in board is changed into a preset second name. The second name is different from the name of the second pair of external interface classes, so that no call exception occurs when the second pair of external interface classes of the host is called. In this embodiment, a first name of a first external interface class in the non-plug-in SDK code is converted into a preset second name, so that the name of the first external interface class in the non-plug-in SDK code is different from the name of a second external interface class of the host, and abnormal call can not be generated when the host is used for external communication for the plug-in SDK generated subsequently. It should be noted that, the host in this step may be a generated host, and the generated host is provided with a second external interface class and a second name thereof.
After the plug-in SDK is generated subsequently, when the function of the plug-in SDK is realized, the external system calls the host through the second pair of external interface classes, and the proxy class in the host calls the plug-in SDK through the first pair of external interface classes, so that the business logic in the plug-in SDK is operated.
S108, generating a plug-in SDK of the plug-in board according to the code to be converted, wherein the plug-in SDK communicates with the outside through a second external interface class of the host.
In this embodiment, the system generates a plug-in SDK for the plug-in board according to the code to be converted. Specifically, the code to be converted includes the second code and the second name obtained by conversion and other codes which are not converted in the SDK code of the non-plug-in board, and the code to be converted is compiled into an apk file to obtain the plug-in SDK of the plug-in board. That is, the apk file obtained after compiling can be used as a plug-in.
The generated plug-in SDK communicates externally through a host, and the host communicates externally through a second external interface class. That is, the plug-in SDK needs to be set in the host during use. The proxy class in the host calls the plug-in SDK through the first pair of external interface classes, and the plug-in SDK is communicated with the outside through the second pair of external interface classes after realizing service logic in the plug-in SDK. It should be noted that, in step S106, the first name is converted into a preset second name, so that the names of the first pair of external interface classes after the name conversion are different from the names of the second pair of external interface classes corresponding to the first pair of external interface classes in the host. The purpose is that in the subsequent plug-in SDK application process, the name of the external interface of the plug-in SDK cannot be the same as the name of the external interface of the host so as to avoid calling exception.
According to the plug-in SDK generation method, the system acquires the SDK code of the non-plug-in version, inquires the first code of the system class and the first name of the first external interface class in the SDK code of the non-plug-in version, converts the first code into the second code of the non-component base class, and converts the first name into the preset second name, so that the names of the first external interface class after the name conversion are different from the names of the second external interface class corresponding to the first external interface class in the host, and the code to be converted is obtained. And finally, generating a plug-in SDK of the plug-in board according to the code to be converted, wherein the plug-in SDK communicates with the outside through a second external interface class of the host. Therefore, when the plug-in SDK and the non-plug-in SDK are required to be provided externally, the system only needs to maintain one set of non-plug-in SDK codes. When testing is performed on the SDK code of the external non-plug-in version, and the plug-in SDK can be used externally, modifying the first code of the system class and the first name of the first external interface class in the SDK code of the non-plug-in version maintained in the system to generate a corresponding plug-in SDK. Because the converted second name of the first external interface class is different from the name of the second external interface class of the host, external communication of the plug-in SDK through the second external interface class of the host can be realized, so that the conversion of the SDK code of the non-plug-in edition into the plug-in SDK is realized, a set of plug-in SDK is not required to be independently arranged, and the waste of resources in the system is reduced. Meanwhile, the system does not need to maintain two sets of SDKs at the same time, so that the maintenance cost of manually maintaining the game app codes is reduced.
In one embodiment, the system classes include one or more of a class of Activity components, a class of Service components, a class of ContentProvider components, a class of BroadcastReceiver components, and an Application class. In S106, converting the first code into a second code that is not a component base class, comprising: in the transformation link of the gradle plugin, the code of the class of the Activity component or the code of the class of the Service component or the code of the class of the ContentProvider component or the code of the class of the BroadcastReceiver component or the code of the Application class is converted into a second code of the non-component base class. In S106, converting the first name into a preset second name includes: in the transform link of the gradle plug-in, the first name is converted into a pre-determined second name by adopting the javassist java byte code modification technology.
In this embodiment, the system class includes a class of four major components. The four major components refer to an Activity component, a Service component, a ContentProvider component and a BroadcastReceiver component in Android. Specifically, the system class includes a parent class having a component class of four large components as well as an Application-related parent class. The Android system will load these four large components and will check which class of loader is loaded by. If not the same class loader as the host apk will report the exception. The class of the four-component is replaced with the non-component base class because the four-component is a class of the system, methods in the class will call methods of the system class, and class loaders other than hosts will throw exceptions. And after the system class is replaced by the non-component base class, the system class in the SDK code of the non-plug-in board is only the common java class. As an example of an Activity class, the class of an Activity component is an Activity class of a system class. When converting an Activity class into a non-component base class BaseActivity class, the non-component base class BaseActivity class and the original Activity class have the same api interface and are all empty implementations. The purpose of the api interface being empty is: if the Activity class of the system is a system class, the system detects that the super.onCreate () method of onCreate methods in the Activity class is not the host class loader load throw exception. When the proxy mode is adopted, the system firstly calls the onCreate method in the proxy class ProxyActivity in the host, and executes super. Since super. OnCreate exists in the host, the onCreate method of SDKACTIVITY classes of plug-in SDKs loaded after execution is completed does not present a problem. Therefore, the plug-in SDK can be obtained by transcoding the internal non-plug-in SDK, and the plug-in SDK can be used.
In the transform link of the gradle plug-in, the first name is converted into a pre-determined second name by adopting the javassist java byte code modification technology. Specifically, javassist's java byte code modifying technology is adopted to adjust the name of the plug-in SDK to the external api class. Such as modifying the first name SQwanCore of the plug-in SDK to the second name SQwanCoreImpl. At this time, the name of the second external interface class in the host may still be reserved as SQwanCore, and the name of the external interface of the SDK code of the non-plug-in board is also SQwanCore. Therefore, the system provides both plug-in SDK and non-plug-in SDK code with the same name. At this time, the first name of the plug-in SDK is different from the corresponding name in the host, so that calling conflict does not occur, the system is realized to convert the internal non-plug-in SDK code into the corresponding plug-in SDK for use, and the name of the code call provided externally does not need to be modified. If SQwanCore is adopted as the name of code call, SQwanCore is adopted as the call parameter, and the call of the SDK code of the plug-in or non-plug-in board can be realized.
In one embodiment, before S102, the method further includes: generating a host code of a host, wherein the name of a second external interface class in the host code is the same as the name of a third external interface class in the SDK code of the non-plug-in board, and the SDK code of the non-plug-in board communicates with the outside through the third external interface class.
In this embodiment, the host code of the host is generated before the plug-in SDK is generated. In other embodiments, the operation of generating the host code of the host may also be performed after step S108. However, in this case, before the host code of the host is generated, the name of the second external interface class in the host code needs to be set, so that the conversion of the first name into the preset second name in step S106 can be ensured, so that the name of the first external interface class after the conversion of the name is different from the name of the second external interface class corresponding to the first external interface class in the host, which can be implemented.
Specifically, host code of the host of the plug-in SDK is written. Meanwhile, the name of the second external interface class in the host code is the same as the name of the third external interface class in the SDK code of the non-plug-in board. Thus, the system may call the plug-in SDK or non-plug-in SDK code by the same name. In a specific implementation process, the third pair of external interface classes is the same as the first pair of external interface classes, and are all external communication interfaces of the SDK codes of the non-plug-in boards. In step S102, the non-plug-in SDK code may be obtained by copying, and the non-plug-in SDK code is still remained in the system. In the process of generating the plug-in SDK, the first name of the first pair of external interface classes in the copied non-plug-in SDK code is modified, and the name of the third external interface class of the non-plug-in SDK code stored by the system is kept unchanged. At this time, the first external interface class and the third external interface class refer to interfaces with the same property. When the name of the second external interface class in the host code is the same as the name of the third external interface class in the non-plug-in SDK code, the system can call the plug-in SDK or the non-plug-in SDK code through the same name.
Namely, writing the class loading of the external api which is the same as that of the non-plug-in SDK code, so that the steps of accessing the system when the non-plug-in SDK code and the plug-in SDK are loaded are consistent, a new access step is not required to be developed for a new plug-in SDK, the workload of research and development is reduced, and the maintenance amount of the system code is also reduced.
In one embodiment, after S108, further comprising: acquiring identification information of classes in the plug-in SDK; obtaining a proxy class corresponding to a class in the plug-in SDK in the host code; and associating the identification information of the class in the plug-in SDK with the proxy class so that the proxy class loads the class in the plug-in SDK through the identification information.
In this embodiment, since the plug-in SDK is a new plug-in, it is necessary to set its internal class to be associated with the proxy class of the host so that the proxy class of the host can call the class within the plug-in SDK. Specifically, identification information is set for the class in the plug-in SDK. The identification information may be a class name of the class. The class name of the class in the plug-in SDK is associated with the corresponding proxy class in the host, so that the proxy class loads the class in the plug-in SDK through the class name of the class in the plug-in SDK. Specifically, the class name of the class in the plug-in SDK is used as a parameter, and the parameter is transmitted into the proxy class, and the proxy class loads the class in the plug-in SDK through the class name of the class in the plug-in SDK, and the method of the class in the plug-in SDK is executed.
For example, as shown in fig. 3. The system judges that the Activity class in the plug-in SDK is executed, and the executed steps are as follows:
step 1: and acquiring an Activity class name, such as ACTIVITYA, in the plug-in SDK to be started, and writing the Activity class name into the Intent as a parameter. Intent is a database commonly used in Android to store data.
Step 2: the proxy Activity class is started. The proxy Activity class is a proxy class in the host. The super. OnCreate method of the proxy Activity class is executed, at which point the flow goes through onCreate logic of the system.
Step 3: and loading ACTIVITYA types in the plug-in SDK according to the parameters stored in the step 1, and executing the onCreate method of ACTIVITYA types. Since the parent class of class ACTIVITYA has been changed to base class BaseActivity, where super.
According to the above steps 1,2,3, when the ACTIVITYA classes in the plug-in SDK are started, the proxy Activity class is called up, then the parent class of the proxy Activity class, that is, the onCreate method of the system Activity class is executed, then the onCreate method of the ACTIVITYA class of the plug-in SDK is executed, and the service logic code is operated. The flow of the step is consistent with the flow of the Activity class of the SDK code of the non-plug-in, the onCreate method of the system Activity class is walked first, and then the business logic is walked. Thus, the system may implement the functionality of the plug-in SDK.
In an embodiment, associating the identification information of the class in the plug-in SDK with the proxy class such that the proxy class loads the class in the plug-in SDK with the identification information includes: the control agent class calls the class in the plug-in SDK by identifying the identification information and adopting a reflection mode to load the class in the plug-in SDK.
In this embodiment, when the host code of the host is generated, the proxy class corresponding to the class in the plug-in SDK is created, and the proxy class is controlled to call the class in the plug-in SDK by identifying the identification information and adopting the reflection mode. The identification information may be a class name of a class in the plug-in SDK, and the class name of the class in the plug-in SDK is used as an entry of the proxy class, and the proxy class calls the class in the plug-in SDK in a reflection manner through the entry. Specifically, two classes with the same name cannot be loaded in java class loading, SQwanCore classes in the plug-in SDK are replaced by SQwanCoreImpl classes, SQwanCore classes are rewritten in a host of the plug-in SDK, and a SQwanCoreImpl class method is called in a reflection mode, so that the host calls the plug-in SDK to realize the function of the plug-in SDK.
In one embodiment, after S108, further comprising: acquiring a first resource package of a non-plug-in SDK code; acquiring a first file packet corresponding to a first resource packet in a plug-in SDK; and replacing the first file package in the plug-in SDK with the first resource package to obtain a replaced SDK code of the non-plug-in. Preferably, before obtaining the first resource package of the non-plug-in SDK code, the method further includes: one or more first target resource packages are extracted from the SDK code of the non-plug-in board, and a first resource package is obtained, wherein the first resource package comprises one or more first target resource packages.
In this embodiment, the system analyzes the non-plug-in SDK code, and obtains one or more first target resource packages from the non-plug-in SDK code, to obtain a first resource package. The first target resource package can be used for replacing a corresponding resource file in the plug-in SDK. Further, the system acquires a first file package corresponding to the first resource package in the plug-in SDK, and replaces the first file package in the plug-in SDK with the first resource package to obtain a replaced SDK code of the non-plug-in version. Specifically, the non-plug-in version SDK code is subjected to packet cutting processing, and the non-plug-in resource is generated by adopting common SDK engineering. The non-plug-in resource is herein referred to as the first resource package. And replacing the first resource package with a corresponding first file package in the plug-in SDK in a resource replacement mode, so that the replaced SDK code of the non-plug-in can be obtained. Therefore, the conversion of the SDK codes of the plug-in board and the non-plug-in board can be realized, and the conversion efficiency of the SDK codes of the plug-in board and the non-plug-in board is improved.
In an embodiment, after replacing the first package of files in the plug-in SDK with the first package of resources to obtain the replaced SDK code of the non-plug-in, the method further includes: acquiring a second resource package of the plug-in SDK; acquiring a second file packet corresponding to a second resource packet in the replaced SDK code of the non-plug-in board; and replacing a second file package of the replaced SDK code of the non-plug-in board with the second resource package to obtain the replaced SDK code of the plug-in board. Preferably, obtaining the second resource package of the plug-in SDK includes: and extracting one or more second target resource packages from the plug-in SDK to obtain a second resource package, wherein the second resource package comprises one or more second target resource packages.
In this embodiment, after the plug-in SDK is generated, one or more second target resource packages are extracted from the plug-in SDK. The second target resource package can be used for replacing the corresponding resource file in the SDK code of the non-plug-in board. Further, a second file package corresponding to a second resource package in the replaced SDK code of the non-plug-in board is obtained, and the replaced SDK of the plug-in board can be obtained by replacing the second resource package with the second file package, so that the conversion of the SDK of the plug-in board and the SDK of the non-plug-in board can be realized, and the conversion efficiency of the SDK of the plug-in board and the SDK of the non-plug-in board is improved.
Specifically, two types of resources are prepared in the packet cutting link: and generating a first resource package of the non-plug-in SDK code, namely a non-plug-in resource by using common SDK engineering. The second target resource package generated by the plug-in SDK and the host code is the plug-in resource. When the package is cut according to the requirement, if the package cannot be used due to channel conflict, a non-plug-in resource is used for replacing a corresponding file package in the plug-in SDK, and a non-plug-in SDK code is generated for use. Otherwise, the plug-in SDK is generated for use in a mode of replacing the corresponding file package in the non-plug-in SDK code by using the plug-in resource. If the development software conflicts with the development mother package, the development software is provided with a plug-in SDK for development access in an old mode, and non-plug-in resources are used when the package is cut.
Therefore, the quick conversion of two codes can be realized according to the practical requirements.
It should be understood that, although the steps in the flowchart are shown in sequence as indicated by the arrows, the steps are not necessarily performed in sequence as indicated by the arrows. The steps are not strictly limited to the order of execution unless explicitly recited herein, and the steps may be executed in other orders. Moreover, at least some of the steps in the figures may include multiple sub-steps or stages that are not necessarily performed at the same time, but may be performed at different times, nor does the order in which the sub-steps or stages are performed necessarily performed in sequence, but may be performed alternately or alternately with at least a portion of other steps or other steps.
The application also provides a plug-in SDK generating device, as shown in fig. 4, which comprises an acquisition module 10, a query module 20, a conversion module 30 and a generating module 40. An acquisition module 10 for acquiring the SDK code of the non-plug-in board; a query module 20, configured to query a first code of a system class and a first name of a first pair of external interface classes in a non-plug-in SDK code; the conversion module 30 is configured to convert the first code into a second code of a non-component base class, and convert the first name into a preset second name, so that the name of the first pair of external interface class after the conversion of the name is different from the name of a second pair of external interface class corresponding to the first pair of external interface class in the host, to obtain a code to be converted; the generating module 40 is configured to generate a plug-in SDK of the plug-in board according to the code to be converted, where the plug-in SDK communicates with the outside through a second external interface class of the host.
In one embodiment, the system class includes one or more of a class of Activity components, a class of Service components, a class of ContentProvider components, a class of BroadcastReceiver components, and an Application class; the conversion module 30 is specifically configured to convert, in a transformation link of the gradle plug-in, a code of a class of an Activity component or a code of a class of a Service component or a code of a class of a ContentProvider component or a code of a class of a BroadcastReceiver component or a code of an Application class into a second code of a non-component base class.
Preferably, the conversion module 30 is further specifically configured to convert the first name into the second name in the conversion link of gradle plug-in by using the javassist java bytecode modification technology.
In one embodiment, the plug-in SDK generating device further includes a host code generating module, configured to generate a host code of a host, where a name of a second external interface class in the host code is the same as a name of a third external interface class in the non-plug-in SDK code, and the non-plug-in SDK code communicates with the outside through the third external interface class.
In one embodiment, the plug-in SDK generating device further includes an association module, configured to obtain identification information of a class in the plug-in SDK; obtaining a proxy class corresponding to a class in the plug-in SDK in the host code; and associating the identification information of the class in the plug-in SDK with the proxy class so that the proxy class loads the class in the plug-in SDK through the identification information.
In one embodiment, associating the identification information of the class in the plug-in SDK with the proxy class so that the proxy class loads the class in the plug-in SDK with the identification information includes: the control agent class calls the class in the plug-in SDK by identifying the identification information and adopting a reflection mode to load the class in the plug-in SDK.
In one embodiment, the plug-in SDK generating device further includes a replacing module, configured to obtain a first resource package of a non-plug-in SDK code; acquiring a first file packet corresponding to a first resource packet in a plug-in SDK; and replacing the first file package in the plug-in SDK with the first resource package to obtain a replaced SDK code of the non-plug-in.
Preferably, before obtaining the first resource package of the non-plug-in SDK code, the method further includes: one or more first target resource packages are extracted from the SDK code of the non-plug-in board, and a first resource package is obtained, wherein the first resource package comprises one or more first target resource packages.
In one embodiment, after replacing the first package of files in the plug-in SDK with the first package of resources to obtain the replaced SDK code of the non-plug-in, the method further includes: acquiring a second resource package of the plug-in SDK; acquiring a second file packet corresponding to a second resource packet in the replaced SDK code of the non-plug-in board; and replacing a second file package of the replaced SDK code of the non-plug-in board with the second resource package to obtain the replaced SDK of the plug-in board.
Preferably, one or more second target resource packages are extracted from the plug-in SDK to obtain second resource packages, and the second resource packages comprise one or more second target resource packages.
The specific definition of the plug-in SDK generating device may be referred to the definition of the plug-in SDK generating method hereinabove, and will not be described herein. The respective modules in the above-described plug-in SDK generation device may be implemented in whole or in part by software, hardware, or a combination thereof. The above modules may be embedded in hardware or may be independent of a processor in the computer device, or may be stored in software in a memory in the computer device, so that the processor may call and execute operations corresponding to the above modules.
In one embodiment, a computer device is provided, which may be a server supporting the operation of the issuer system 106, the internal structural diagram of which may be as shown in FIG. 5. The computer device includes a processor, a memory, a network interface, and a database connected by a system bus. Wherein the processor of the computer device is configured to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The network interface of the computer device is used for connecting with an external database to read the SDK codes of the non-plug-in boards in the database. The computer program, when executed by a processor, implements a plug-in SDK generation method.
It will be appreciated by those skilled in the art that the structure shown in FIG. 5 is merely a block diagram of some of the structures associated with the present inventive arrangements and is not limiting of the computer device to which the present inventive arrangements may be applied, and that a particular computer device may include more or fewer components than shown, or may combine some of the components, or have a different arrangement of components.
In one embodiment, a computer device is provided comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, the processor implementing the steps of when executing the computer program: acquiring an SDK code of a non-plug-in board; querying a first code of a system class and a first name of a first pair of external interface classes in the SDK code of the non-plug-in board; converting the first code into a second code of a non-component base class, converting the first name into a preset second name, so that the names of a first pair of external interface classes after the name conversion are different from the names of a second pair of external interface classes corresponding to the first pair of external interface classes in a host, and obtaining the code to be converted; and generating a plug-in SDK of the plug-in board according to the code to be converted, wherein the plug-in SDK communicates with the outside through a second external interface class of the host.
In one embodiment, the system classes include one or more of a class of Activity components, a class of Service components, a class of ContentProvider components, a class of BroadcastReceiver components, and an Application class. When the processor executes the computer program to realize the step of converting the first code into the second code of the non-component base class, the following steps are specifically realized: in the transformation link of the gradle plugin, the code of the class of the Activity component or the code of the class of the Service component or the code of the class of the ContentProvider component or the code of the class of the BroadcastReceiver component or the code of the Application class is converted into a second code of the non-component base class.
In one embodiment, when the processor executes the computer program to implement the step of converting the first name into the preset second name, the following steps are specifically implemented: in the transform link of the gradle plug-in, the first name is converted into a pre-determined second name by adopting the javassist java byte code modification technology.
In one embodiment, the processor when executing the computer program further performs the steps of: generating a host code of a host, wherein the name of a second external interface class in the host code is the same as the name of a third external interface class in the SDK code of the non-plug-in board, and the SDK code of the non-plug-in board communicates with the outside through the third external interface class.
In one embodiment, the processor when executing the computer program further performs the steps of: acquiring identification information of classes in the plug-in SDK; obtaining a proxy class corresponding to a class in the plug-in SDK in the host code; and associating the identification information of the class in the plug-in SDK with the proxy class so that the proxy class loads the class in the plug-in SDK through the identification information.
In one embodiment, when the processor executes the computer program to implement the above-mentioned step of associating the identification information of the class in the plug-in SDK with the proxy class, so that the proxy class loads the class in the plug-in SDK through the identification information, the following steps are specifically implemented: the control agent class calls the class in the plug-in SDK by identifying the identification information and adopting a reflection mode to load the class in the plug-in SDK.
In one embodiment, the processor when executing the computer program further performs the steps of: acquiring a first resource package of a non-plug-in SDK code; acquiring a first file packet corresponding to a first resource packet in a plug-in SDK; and replacing the first file package in the plug-in SDK with the first resource package to obtain a replaced SDK code of the non-plug-in.
In one embodiment, the processor when executing the computer program further performs the steps of: one or more first target resource packages are extracted from the SDK code of the non-plug-in board, and a first resource package is obtained, wherein the first resource package comprises one or more first target resource packages.
In one embodiment, the processor when executing the computer program further performs the steps of: acquiring a second resource package of the plug-in SDK; acquiring a second resource package of the plug-in SDK; acquiring a second file packet corresponding to a second resource packet in the replaced SDK code of the non-plug-in board; and replacing a second file package of the replaced SDK code of the non-plug-in board with the second resource package to obtain the replaced SDK of the plug-in board.
In one embodiment, when the processor executes the step of obtaining the second resource package of the plug-in SDK by using the computer program, the following steps are specifically implemented: and extracting one or more second target resource packages from the plug-in SDK to obtain second resource packages, wherein the second resource packages comprise one or more second target resource packages.
In one embodiment, a computer readable storage medium is provided having a computer program stored thereon, which when executed by a processor, performs the steps of: acquiring an SDK code of a non-plug-in board; querying a first code of a system class and a first name of a first pair of external interface classes in the SDK code of the non-plug-in board; converting the first code into a second code of a non-component base class, converting the first name into a preset second name, so that the names of a first pair of external interface classes after the name conversion are different from the names of a second pair of external interface classes corresponding to the first pair of external interface classes in a host, and obtaining the code to be converted; and generating a plug-in SDK of the plug-in board according to the code to be converted, wherein the plug-in SDK communicates with the outside through a second external interface class of the host.
In one embodiment, the system classes include one or more of a class of Activity components, a class of Service components, a class of ContentProvider components, a class of BroadcastReceiver components, and an Application class. When the computer program is executed by a processor to realize the step of converting the first code into the second code of the non-component base class, the following steps are specifically realized: in the transformation link of the gradle plugin, the code of the class of the Activity component or the code of the class of the Service component or the code of the class of the ContentProvider component or the code of the class of the BroadcastReceiver component or the code of the Application class is converted into a second code of the non-component base class.
In one embodiment, when the computer program is executed by the processor to implement the step of converting the first name into the preset second name, the following steps are specifically implemented: in the transform link of the gradle plug-in, the first name is converted into a pre-determined second name by adopting the javassist java byte code modification technology.
In one embodiment, the computer program when executed by the processor further performs the steps of: generating a host code of a host, wherein the name of a second external interface class in the host code is the same as the name of a third external interface class in the SDK code of the non-plug-in board, and the SDK code of the non-plug-in board communicates with the outside through the third external interface class.
In one embodiment, the computer program when executed by the processor further performs the steps of: acquiring identification information of classes in the plug-in SDK; obtaining a proxy class corresponding to a class in the plug-in SDK in the host code; and associating the identification information of the class in the plug-in SDK with the proxy class so that the proxy class loads the class in the plug-in SDK through the identification information.
In one embodiment, when the computer program is executed by the processor to implement the above-mentioned step of associating the identification information of the class in the plug-in SDK with the proxy class, so that the proxy class loads the class in the plug-in SDK through the identification information, the following steps are specifically implemented: the control agent class calls the class in the plug-in SDK by identifying the identification information and adopting a reflection mode to load the class in the plug-in SDK.
In one embodiment, the computer program when executed by the processor further performs the steps of: acquiring a first resource package of a non-plug-in SDK code; acquiring a first file packet corresponding to a first resource packet in a plug-in SDK; and replacing the first file package in the plug-in SDK with the first resource package to obtain a replaced SDK code of the non-plug-in.
In one embodiment, the computer program when executed by the processor further performs the steps of: one or more first target resource packages are extracted from the SDK code of the non-plug-in board, and a first resource package is obtained, wherein the first resource package comprises one or more first target resource packages.
In one embodiment, the computer program when executed by the processor further performs the steps of: acquiring a second resource package of the plug-in SDK; acquiring a second resource package of the plug-in SDK; acquiring a second file packet corresponding to a second resource packet in the replaced SDK code of the non-plug-in board; and replacing a second file package of the replaced SDK code of the non-plug-in board with the second resource package to obtain the replaced SDK of the plug-in board.
In one embodiment, when the computer program is executed by the processor to implement the step of obtaining the second resource package of the plug-in SDK, the following steps are specifically implemented: and extracting one or more second target resource packages from the plug-in SDK to obtain second resource packages, wherein the second resource packages comprise one or more second target resource packages.
Those skilled in the art will appreciate that implementing all or part of the above described methods may be accomplished by way of a computer program stored on a non-transitory computer readable storage medium, which when executed, may comprise the steps of the embodiments of the methods described above. Any reference to memory, storage, database, or other medium used in embodiments provided herein may include non-volatile and/or volatile memory. The nonvolatile memory can include Read Only Memory (ROM), programmable ROM (PROM), electrically Programmable ROM (EPROM), electrically Erasable Programmable ROM (EEPROM), or flash memory. Volatile memory can include Random Access Memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms such as Static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double Data Rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link (SYNCHLINK) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), among others.
The technical features of the above embodiments may be arbitrarily combined, and all possible combinations of the technical features in the above embodiments are not described for brevity of description, however, as long as there is no contradiction between the combinations of the technical features, they should be considered as the scope of the description.
The above examples illustrate only a few embodiments of the application, which are described in detail and are not to be construed as limiting the scope of the application. It should be noted that it will be apparent to those skilled in the art that several variations and modifications can be made without departing from the spirit of the application, which are all within the scope of the application. Accordingly, the scope of protection of the present application is to be determined by the appended claims.

Claims (13)

1. A plug-in SDK generation method, the method comprising:
Acquiring an SDK code of a non-plug-in board;
inquiring a first code of a system class and a first name of a first pair of external interface classes in the non-plug-in SDK code;
Converting the first code into a second code of a non-component base class, converting the first name into a preset second name so that the names of the first pair of external interface classes after the name conversion are different from the names of a second pair of external interface classes corresponding to the first pair of external interface classes in a host, and obtaining a code to be converted, wherein the code to be converted comprises the second code, the second name and other codes which are not converted in the SDK code of the non-plug-in board;
And generating a plug-in SDK of a plug-in board according to the code to be converted, wherein the plug-in SDK communicates with the outside through the second external interface class of the host.
2. The method of claim 1, wherein the system class comprises one or more of a class of Activity components, a class of Service components, a class of ContentProvider components, a class of BroadcastReceiver components, and an Application class, the converting the first code to a second code that is not a component-based class comprising:
In the transform link of the gradle plug-in, the code of the class of the Activity component or the code of the class of the Service component or the code of the class of the ContentProvider component or the code of the class of the BroadcastReceiver component or the code of the Application class is converted into a second code of a non-component base class.
3. The method of claim 2, wherein the converting the first name to a preset second name comprises:
in the transform link of the gradle plug-in, the first name is converted into a pre-determined second name by adopting the javassist java byte code modification technology.
4. The method according to claim 1, wherein the method further comprises:
Generating a host code of the host, wherein the name of the second external interface class in the host code is the same as the name of a third external interface class in the non-plug-in SDK code, and the non-plug-in SDK code communicates with the outside through the third external interface class.
5. The method according to claim 4, wherein the method further comprises:
Acquiring identification information of the class in the plug-in SDK;
Acquiring proxy classes corresponding to the classes in the plug-in SDK in the host code;
And associating the identification information of the class in the plug-in SDK with the proxy class so that the proxy class loads the class in the plug-in SDK through the identification information.
6. The method of claim 5, wherein associating the identification information of the class in the plug-in SDK with the proxy class such that the proxy class loads the class in the plug-in SDK with the identification information comprises:
And controlling the proxy class to load the class in the plug-in SDK by identifying the identification information and calling the class in the plug-in SDK in a reflection mode.
7. The method according to claim 1, wherein the method further comprises:
acquiring a first resource package of the SDK code of the non-plug-in board;
Acquiring a first file package corresponding to the first resource package in the plug-in SDK;
And replacing the first file package in the plug-in SDK with the first resource package to obtain a replaced SDK code of the non-plug-in version.
8. The method of claim 7, wherein prior to the obtaining the first resource package of the non-plug-in version of the SDK code, further comprising:
And extracting one or more first target resource packages from the non-plug-in SDK code to obtain the first resource packages, wherein the first resource packages comprise one or more first target resource packages.
9. The method of claim 7, wherein the replacing the first package of resources with the first package of resources in the add-on SDK to obtain the non-add-on version of the replaced SDK code further comprises:
acquiring a second resource package of the plug-in SDK;
Acquiring a second file packet corresponding to the second resource packet in the replaced SDK code of the non-plug-in board;
and replacing the second resource package with the second file package of the replaced SDK code of the non-plug-in board to obtain the replaced SDK of the plug-in board.
10. The method of claim 9, wherein the obtaining the second resource package of the plug-in SDK comprises:
And extracting one or more second target resource packages from the plug-in SDK to obtain the second resource packages, wherein the second resource packages comprise the one or more second target resource packages.
11. A plug-in SDK generating apparatus, the apparatus comprising:
the acquisition module is used for acquiring the SDK code of the non-plug-in board;
the query module is used for querying a first code of a system class and a first name of a first pair of external interface classes in the SDK code of the non-plug-in board;
The conversion module is used for converting the first code into a second code of a non-component base class, converting the first name into a preset second name, so that the names of the first pair of external interface classes after the name conversion are different from the names of a second pair of external interface classes corresponding to the first pair of external interface classes in a host, and obtaining codes to be converted, wherein the codes to be converted comprise the second code, the second name and other codes which are not converted in the SDK codes of the non-plug-in board;
And the generating module is used for generating a plug-in SDK of a plug-in board according to the code to be converted, and the plug-in SDK communicates with the outside through the second external interface class of the host.
12. A computer device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, characterized in that the processor implements the steps of the method according to any one of claims 1 to 10 when the computer program is executed by the processor.
13. A computer readable storage medium, on which a computer program is stored, characterized in that the computer program, when being executed by a processor, implements the steps of the method of any of claims 1 to 10.
CN202011231744.6A 2020-11-06 2020-11-06 Plug-in SDK generation method, device, computer equipment and storage medium Active CN112486569B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202011231744.6A CN112486569B (en) 2020-11-06 2020-11-06 Plug-in SDK generation method, device, computer equipment and storage medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202011231744.6A CN112486569B (en) 2020-11-06 2020-11-06 Plug-in SDK generation method, device, computer equipment and storage medium

Publications (2)

Publication Number Publication Date
CN112486569A CN112486569A (en) 2021-03-12
CN112486569B true CN112486569B (en) 2024-04-30

Family

ID=74928811

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202011231744.6A Active CN112486569B (en) 2020-11-06 2020-11-06 Plug-in SDK generation method, device, computer equipment and storage medium

Country Status (1)

Country Link
CN (1) CN112486569B (en)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9678726B1 (en) * 2015-03-27 2017-06-13 Amazon Technologies, Inc. Automatic generation of plugins for development tools
CN110502222A (en) * 2019-07-23 2019-11-26 北京字节跳动网络技术有限公司 AAR method, apparatus, medium and the equipment in outgoing dependence inner base library
CN111290760A (en) * 2020-03-03 2020-06-16 北京字节跳动网络技术有限公司 Application program compiling method and device, electronic equipment and storage medium
CN111309335A (en) * 2020-02-28 2020-06-19 腾讯音乐娱乐科技（深圳）有限公司 Plug-in application compiling method and device and computer readable storage medium

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9678726B1 (en) * 2015-03-27 2017-06-13 Amazon Technologies, Inc. Automatic generation of plugins for development tools
CN110502222A (en) * 2019-07-23 2019-11-26 北京字节跳动网络技术有限公司 AAR method, apparatus, medium and the equipment in outgoing dependence inner base library
CN111309335A (en) * 2020-02-28 2020-06-19 腾讯音乐娱乐科技（深圳）有限公司 Plug-in application compiling method and device and computer readable storage medium
CN111290760A (en) * 2020-03-03 2020-06-16 北京字节跳动网络技术有限公司 Application program compiling method and device, electronic equipment and storage medium

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
Android移动应用热更新方案的研究与实现;赵家祝;《中国优秀硕士学位论文全文数据库 信息科技辑》;20190115;正文全文 *
基于Android的移动游戏数据采集工具设计与实现;杨唯;《中国优秀硕士学位论文全文数据库 信息科技辑》;20190515;正文全文 *

Also Published As

Publication number Publication date
CN112486569A (en) 2021-03-12

Similar Documents

Publication Publication Date Title
US10795660B1 (en) Live code updates
US7784043B2 (en) Method and system for automated code-source indexing in Java Virtual Machine environment
US8612930B2 (en) Methods and apparatus for dynamic class reloading and versioning
US8756616B2 (en) System and method for reducing the static footprint of mixed-language JAVA classes
US10331425B2 (en) Automated source code adaption to inject features between platform versions
CN109032662B (en) Code file generation method and device, computer equipment and storage medium
US20100070960A1 (en) Method and system for automated root-cause analysis for class loading failures in java
US20090138847A1 (en) Optimized code generation by eliminating unused virtual function
EP2340481A2 (en) Caching runtime generated code
CN109614167B (en) Method and system for managing plug-ins
CN112306503A (en) Front-end resource packaging method and device, computer equipment and storage medium
US20230297352A1 (en) Method for Starting Serverless Container and Related Device
CN111427557A (en) Application microservice method and device, electronic equipment and readable storage medium
US20040172407A1 (en) Method and system of processing an encapsulated file at a management computer
CN112486569B (en) Plug-in SDK generation method, device, computer equipment and storage medium
CN104423932A (en) Method for calling binary element in Javascript
CN108536444B (en) Plug-in compiling method and device, computer equipment and storage medium
CN101216804A (en) Testing device and method
CN110673890B (en) Plug-in calling method, system, medium and device
CN115374083A (en) Data source switching method and device, electronic equipment and storage medium
Gregersen et al. Towards a Dynamic-update-enabled JVM
CN114003486A (en) Plug-in debugging method, client, server and storage medium
CN114564385A (en) Software testing method and device, computer equipment and storage medium
CN111949301A (en) Application program hot updating method and device, computer readable storage medium and computer equipment
CN114490103A (en) Operating system interface calling method and device and electronic equipment

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant