Business function implementation method and device and related product

Abstract

The embodiment of the invention discloses a business function implementation method and device and a related product, and the method comprises the steps: constructing a function implementation code of a function interface according to a difference point and the content defined by an interface under the same engineering project, and achieving a set of common codes which can be adaptive to application software and also can be adaptive to light applications. The function realization of two forms of products can be realized through one set of codes, and the project development cost and the subsequent maintenance workload are greatly saved; in addition, the function implementation codes of the two forms of products are deployed in the same engineering project, so that the interface effects finally displayed by the products are highly consistent due to existence of more generality.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of interface technology, and in particular to methods, devices, and related products for implementing business functions. Background Art

[0002] Some statistics have found that lightweight applications are more popular than application software (App). For example, in the application development process of Huawei's HarmonyOS NEXT, in order to fully cover user needs, developers usually choose to develop two forms of products: HarmonyOS applications and meta-services. Among them, HarmonyOS applications: can be installed through the application market and are applications that can be opened through desktop icons; meta-services (Atomica Service): are lightweight application forms on the HarmonyOS system that are installation-free, accessible anywhere, and provide direct service. As a lightweight service or light application, it does not require installation and users can use it immediately, achieving a quick or temporary service experience, such as checking the weather or maps.

[0003] Given the differences between HarmonyOS apps and meta-services at the API (Application Programming Interface) level, developers will build two projects for development based on existing software development technology solutions. Specifically, HarmonyOS apps are independent projects with their own set of code, and meta-services are also independent projects with their own set of code. These two projects are independent and maintained independently without interfering with each other. However, this solution has the following significant drawbacks: it requires a large amount of manpower and resources to support the development and subsequent maintenance of both projects, resulting in high overall costs. Summary of the Invention

[0004] The embodiments of the present application provide business function implementation methods, devices and related products, so that a set of codes can meet the functional implementation of products of different forms, greatly saving project development costs and subsequent maintenance workload.

[0005] A first aspect of an embodiment of the present application provides a method for implementing a service function, including:

[0006] Identify the differences between application software and lightweight applications in terms of references to achieve target business functions;

[0007] Define interfaces based on the target business functions to declare functional interfaces for the two forms of products to call;

[0008] According to the differences and the content of the interface definition, the function implementation code of the functional interface is constructed under the same engineering project, so that any of the form products can realize the target business function by running the method defined in the functional interface.

[0009] Optionally, determining the differences in references between the application software and the light application in order to implement the target business function includes:

[0010] Performing a differential comparison on the components and / or toolkits separately referenced by the two form products to implement the target business function, to obtain the differences in components and / or toolkits between the two form products.

[0011] Optionally, when the target business function is a caching function, the differences include the cache components that are respectively allowed to be used between the two form products;

[0012] When the target business function is a payment function, the differences include the payment toolkits that are respectively restricted to be used between the two form products.

[0013] Optionally, constructing the function implementation code of the function interface under the same engineering project according to the differences and the content defined by the interface includes:

[0014] Obtaining an implementation class for implementing the function interface;

[0015] According to the specific implementation logic of the implementation class, using the differences and the content defined by the interface to construct the function implementation code for the application software and the light application respectively under the same engineering project.

[0016] Optionally, the method further includes:

[0017] Defining that the methods in the function interface include an initialization method; the initialization method is used to indicate that when any one of the form products is enabled, the function implementation code constructed for the form product under the engineering project is run.

[0018] Optionally, the method further includes:

[0019] Constructing public module code under the engineering project based on the defined content for the public module, so that any one of the form products can improve the consistency between function feedback interfaces by running the public module code.

[0020] When the method described in the first aspect of this application is specifically implemented, the content described in the second aspect of this application can be used for implementation.

[0021] The second aspect of the embodiments of this application provides a business function implementation device, including: a determination unit and a processing unit;

[0022] The determination unit is used to determine the differences in references between the application software and the light application in order to implement the target business function;

[0023] The processing unit is configured to define an interface based on the target service function, so as to declare a function interface for the two forms of products to call;

[0024] The processing unit is further configured to construct the functional implementation code of the functional interface under the same engineering project according to the differences and the content of the interface definition, so that any one of the form products can implement the target service function by running the method defined in the functional interface.

[0025] A third aspect of the embodiments of the present application provides an electronic device, including: a processor and a memory;

[0026] The processor is configured to communicate with the memory and execute the instructions in the memory to implement the method described in the first aspect or any specific implementation manner of the first aspect of the embodiments of the present application.

[0027] A fourth aspect of the embodiments of the present application provides a computer-readable storage medium, where the readable storage medium stores computer instructions, and when the computer instructions are executed by a processor, the method described in the first aspect or any specific implementation manner of the first aspect of the embodiments of the present application is implemented.

[0028] A fifth aspect of the embodiments of the present application provides a computer program product, where the computer program product includes computer instructions, and when the computer instructions are executed by a processor, the method described in the first aspect or any specific implementation manner of the first aspect of the embodiments of the present application is implemented.

[0029] It can be seen from the above technical solutions that the embodiments of the present application have at least the following advantages:

[0030] In the embodiments of the present application, under the same engineering project, the functional implementation code of the functional interface is constructed according to the differences and the content of the interface definition, which can achieve a set of common code that can adapt to both application software and light applications, so that the functional implementation of the two forms of products can be satisfied by one set of code, and the project development cost and subsequent maintenance workload are greatly saved; in addition, the functional implementation codes of the two forms of products are deployed under the same engineering project, which can make the final displayed interface effects of each product highly consistent due to more commonalities. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following will briefly introduce the drawings required for the description of the embodiments. Obviously, the drawings in the following description are only some embodiments recorded in the present application, and those of ordinary skill in the art can also obtain other drawings based on these drawings.

[0032] It should be noted that although the steps in the flowchart diagrams (if any) involved in each embodiment are drawn in sequence according to the arrows, unless otherwise clearly stated in this document, the execution of these steps has no strict order limitation, and these steps can be executed in other orders. Moreover, at least a part of the steps in the flowchart diagrams involved in each embodiment may include multiple steps or multiple stages. These steps or stages do not necessarily need to be completed at the same moment, but can be executed at different moments. The execution order of these steps or stages is not necessarily sequential either, but can be executed alternately or in turn with at least a part of other steps or steps or stages in other steps.

[0033] Figure 1 It is a schematic diagram of the project architecture layering for the method of implementing business functions in the embodiments of this application;

[0034] Figure 2 It is a schematic flowchart of the method of implementing business functions in the embodiments of this application;

[0035] Figure 3 It is another schematic flowchart of the method of implementing business functions in the embodiments of this application;

[0036] Figure 4 It is a UML class diagram of the method of implementing business functions in the embodiments of this application regarding the caching function;

[0037] Figure 5 It is a UML class diagram of the method of implementing business functions in the embodiments of this application regarding the payment function;

[0038] Figure 6 It is a schematic diagram of the structure of the device for implementing business functions in the embodiments of this application;

[0039] Figure 7 It is a schematic diagram of the structure of an electronic device in the embodiments of this application. Detailed implementation manners

[0040] In order to make the objectives, technical solutions, and advantages of this application clearer, the following will further describe this application in detail with reference to the accompanying drawings. The described embodiments should not be regarded as limitations to this application. All other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the scope of protection of this application.

[0041] The terms "first", "second", "third", "fourth", etc. (if any) in the description, claims and drawings of this application are used to distinguish similar objects and do not necessarily describe a specific order or sequence. It should be understood that the data used in this way can be interchanged under appropriate circumstances so that the embodiments described here can be implemented in an order other than that illustrated or described here. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusion. For example, a process, method, product or device that includes a series of steps or units does not necessarily have to be limited to those steps or units clearly listed, but may include other steps or units not clearly listed or inherent to these processes, methods, products or devices.

[0042] In the following description, reference is made to "a specific embodiment" or "a specific example" and the like. These describe subsets of all possible embodiments. However, it can be understood that "a specific embodiment" or "a specific example" can be the same subset or different subsets of all possible embodiments and can be combined with each other without conflict. In the following description, the term "a plurality" refers to at least two. When it is said in this application that a certain numerical value reaches a threshold (if any), in some specific examples, it may include the case where the former is greater than the latter. If terms such as "any" or "at least one" and the like are mentioned, it may specifically refer to any one of the listed examples or any combination between these examples.

[0043] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by those of ordinary skill in the technical field to which this application belongs. The terms used herein are only for the purpose of describing the embodiments of this application and are not intended to limit this application.

[0044] Please refer to Figure 1 the schematic diagram of the project architecture layering. Taking the HarmonyOS as an example, in order to enable the HarmonyOS application software App and the light application (such as the meta service) to share a set of codes, the code project can be designed into three layers, namely the product layer, the feature layer and the base layer.

[0045] Among them, the product layer corresponds to different form products, such as HarmonyOS applications and meta-services; from the perspective of back-end developers, the feature layer corresponds to each business function module within the product, such as the home page module, login module, personal center module, payment module, cache module, etc.; the basic layer can define public modules that have nothing to do with the business, such as network request components, utility class components, etc., and the basic layer can also define interfaces for the differences between HarmonyOS applications and meta-services. The interface content (such as methods) defined by the basic layer is responsible for specifying what the interface can "do", that is, for functional specifications, such as specifying which methods and behaviors the interface needs to provide; while the implementation class of the feature layer is responsible for implementation details, specifying in detail "how to do it" (that is, the specific implementation logic) so that the functions of the interface can be truly implemented specifically.

[0046] Taking the payment function as an example, from the perspective of front-end users, in the embodiments of the present application, users can implement electronic payment by calling the methods in the function interface through HarmonyOS applications or meta-services. For specific details, please refer to the following description.

[0047] Please refer to Figure 2 , a specific embodiment of a method for implementing a business function is provided in the first aspect of the present application, and this embodiment includes the following operation steps:

[0048] Step S21: Determine the difference points in terms of reference for implementing the target business function between the two form products of application software and light applications;

[0049] The method of the embodiments of the present application can be used in operating systems such as HarmonyOS and Android. Taking HarmonyOS as an example, in the actual application scenario, the light applications (such as mini-programs or meta-services) of HarmonyOS have a shorter development cycle than HarmonyOS applications (which can be called Apps), do not need to be downloaded and installed, have a lower user experience threshold, and users can implement functions such as search, payment, and caching that can be used immediately through the meta-services on the negative first screen, and the experience can be comparable to that of native Apps.

[0050] In the development process, there are differences in APIs between HarmonyOS applications and meta-services. Therefore, in order to efficiently reuse code and save the upfront development cost and the later maintenance cost, it is possible to first determine the difference points in terms of reference for implementing the target business function (such as payment or caching function) between the two form products of HarmonyOS application Apps and meta-services. The difference points in terms of this reference specifically include the differences in at least one aspect such as the components (such as databases), toolkits, plugins, etc. referred to by these two form products for implementing the required functions. For specific details, please refer to the following text and will not be elaborated here.

[0051] Step S22: Define an interface based on the target business function to declare a function interface for the two form products to call;

[0052] In software development, defining interfaces based on target business functions enables products in different forms (such as HarmonyOS applications and meta-services) to call the required functions through these interfaces, thereby improving code reusability, maintainability, and system flexibility.

[0053] Specifically, the common business functions required by both forms of products can be identified and defined as common interface methods. For example, both apps and meta-services need to query the course list, and a getCourseList() method can be defined. For special requirements arising from different product forms, special interface methods can be defined separately or different parameters can be used to distinguish the methods defined in the interface. For instance, since apps support offline course downloads, a downloadCourseOffline() method can be defined; as meta-services emphasize quick preview of course content, a previewCourseBriefly() method can be defined. Additionally, the names of the function interfaces called by both forms of products to achieve the same business function can be the same or different, which can be determined as needed and is not limited here.

[0054] Step S23: Construct the functional implementation code of the functional interface under the same engineering project according to the differences and the content defined in the interface, so that any form of product can achieve the target business function by running the methods defined in the functional interface.

[0055] After the interface definition is completed, the interface can be implemented through an implementation class to implement the method functions declared in this interface. Specifically, according to the differences and the content of the above interface definition (such as method name, parameter type, function description, etc.), the implementation code of the functional interface can be constructed under the same engineering project, so that products of different forms can achieve the target business function by calling the methods in these interfaces. The interface implementation codes for different business functions can be deployed under one or more engineering projects, which can be determined as needed and is not limited here.

[0056] In summary, in the embodiment of this application, under the same engineering project, the functional implementation code of the functional interface is constructed according to the differences and the content of the interface definition (such as method name, parameter type, function description, etc.), which can achieve a set of common codes that can adapt to both application software and light applications. That is, through a set of codes, different products can achieve the target business function by calling the methods in the interface. At the same time, it greatly saves the project development cost and subsequent maintenance workload. In addition, the functional implementation codes of both forms of products are deployed under the same engineering project, which can make the final displayed interface effects of each product highly consistent due to more commonalities.

[0057] Based on the above example description, the method of this application will be further described in detail below, and some specific possible implementation examples will be provided. In actual applications, the implementation contents between these examples can be combined or implemented separately according to the corresponding functional principles and application logics. If combined, the execution order between the combined examples can be determined according to their respective processing logics, which can be specifically determined by the actual scenario.

[0058] As described above, please refer to Figure 3 , the embodiments of this application can be applied to the development process to address or solve the differences in APIs between HarmonyOS applications and meta-services. Among them, functional interfaces (or business logic interfaces) can be defined at the basic layer, and the feature layer modules can reference these interfaces. When in use, specific business logics can be implemented in the form of interface call methods; each product then differentiates and implements the methods corresponding to the interfaces according to the platform characteristics at the product layer. Simply put, the basic layer stipulates and declares the functions, attributes (which may include method names and interface names) of the functional interfaces, and the feature layer implements the abstract methods in the interfaces through implementation classes, so as to implement the functional interfaces for the form products at the product layer to call.

[0059] In some specific examples, the specific operation process of step S21 may include: differentiating and comparing the components and / or toolkits separately referenced by the two form products to achieve the target business function, and obtaining the differences in components and / or toolkits between the two form products.

[0060] In actual situations, some components and / or toolkits of the HarmonyOS system can be used in HarmonyOS applications, but are not supported in meta-services. Therefore, starting from the differences in components and / or toolkits between HarmonyOS applications (App) and meta-services when implementing the target business function, the differences in API references between HarmonyOS applications and meta-services can be discovered.

[0061] Taking the caching function as an example, for HarmonyOS application (App): it usually has relatively fixed and comprehensive local data storage requirements. For example, a shopping App may need to store data such as user personal information, browsing history, and favorite products, and these data also need to be quickly accessed and used when the user is offline; therefore, it is more inclined to use a local database to store a large amount of structured data to ensure data security and manageability. While for meta-service: it focuses more on lightweight data storage and real-time interaction. Since meta-services are often designed to meet the immediate needs of users in specific scenarios, the amount of data stored is relatively small, and more attention is paid to the real-time update of data; for example, a weather query meta-service may only need to store a small amount of current weather data and user query records, and these data need to be synchronized with the cloud in real time, so it may rely more on cloud databases or lightweight local cache components.

[0062] For another example, the above toolkit can be a software development kit (SDK, Software Development Kit) for implementing payment functions. For specific details, please refer to the following text and will not be elaborated here.

[0063] Further, in some specific examples, when the target business function is the caching function, the difference points include the cache components that are respectively allowed to be used between the two forms of products; when the target business function is the payment function, the difference points include the payment toolkits that are respectively restricted to be used between the two forms of products.

[0064] Taking the caching function as an example, there are multiple cache components in the HarmonyOS. Among them, KVManager (i.e., the distributed key-value database) is not supported in the meta-service, while preferences (i.e., the user preference component) can be used in the meta-service; or it can be correspondingly understood that the KVManager API can be used to implement the caching function in the HarmonyOS application, and the preferences API can be used to implement the caching function in the meta-service.

[0065] Correspondingly, to enable each module in the feature layer to share a set of codes, according to the solution provided in the embodiments of the present application, a cache interface ICache can be defined in the basic layer. Two methods, setValue() and getValue(), can be defined in this interface to implement the caching function:

[0066] export interface Icache{

[0067] / / Get cache

[0068] getValue(key:string):Promise <string>

[0069] / / Set cache

[0070] setValue(key: string, value: string): void

[0071] }

[0072] In some specific examples, the specific operation process of step S23 may include: obtaining an implementation class for implementing a functional interface; according to the specific implementation logic of the implementation class, using the difference points and the content defined by the interface to construct functional implementation codes for application software and light applications respectively under the same engineering project.

[0073] As described above, the implementation class can be used in the feature layer to truly implement the functional interface, so that the method of this functional interface (such as the cache method or the payment method) can be finally called in the product layer to implement the target business function. As Figure 4 shown, the cache interface "ICache" is implemented in the product layer through the logical design of the feature layer. Specifically, the functional implementation code for HarmonyOS applications can be constructed based on the implementation class named AppCacheEngine and the distributed key-value database KVManager available for HarmonyOS applications, so that the ICache interface can be implemented in the product layer, ensuring that the HarmonyOS application uses the KVManager (distributed key-value database) API through the implementation class AppCacheEngine of this interface to implement the cache function. Similarly, the functional implementation code for meta-services can be constructed based on the implementation class named AtomicCacheEngine and the user preferences component preferences available for meta-services, so that the ICache interface can be implemented in the product layer, ensuring that the meta-service uses the preferences API through the implementation class AtomicCacheEngine of this interface to implement the cache function. Among them, KVManager and preferences can be regarded as the difference points of HarmonyOS applications and meta-services regarding the cache component; in some examples, if the implementation classes used by HarmonyOS applications and meta-services for the same business function are different, the implementation class can also be called the difference point between HarmonyOS applications and meta-services.

[0074] In short, the business scenario where the cache function is used in the feature layer (or business layer) is to call the APIs adapted to each product through the setValue method and getValue method in the cache interface ICache to obtain and cache information; that is, during the operation of the above functional implementation code, the HarmonyOS application uses the API of the HarmonyOS application, and the meta-service uses the API of the meta-service, achieving a set of codes to solve the API differences between the HarmonyOS application and the meta-service system.

[0075] Take the payment function as another example. To enable the feature layer to achieve the effect of sharing a set of codes, that is, HarmonyOS applications use third-party tool payments (WeChat Pay or Alipay), and HarmonyOS meta-services use the built-in Huawei suite of the system for payment. According to the solution provided by the embodiments of the present application, the payment function interface IBasePay can be defined at the basic layer, and the payment method pay() is defined in this interface:

[0076] Definition of the BasePay payment function interface

[0077] export interface IBasePay{

[0078] pay <t>(context:common.UIAbility context, params: T): Promise<Map<string, string>>

[0079] }

[0080] In daily development, it is generally common to choose to integrate the Alipay payment SDK or WeChat payment SDK to implement the payment function. However, in HarmonyOS MetaServices, the MetaService installation package is often restricted to a size not exceeding 2M. Therefore, in MetaServices, the Huawei PaymentKit, which is built into the system (no need to introduce and will not increase the installation package size), is selected for the payment function. Therefore, by the same token as the implementation process of the above cache function, as Figure 5 shown, the IBasePay interface can be implemented in the product layer through the function implementation code in the feature layer, so as to ensure that the HarmonyOS application uses the Alipay payment SDK (cashier_alipay) through the implementation class AliPay of this interface to implement the payment function; the function implementation code can be used to ensure that the MetaService uses the built-in Huawei PaymentKit in the system through the implementation class HuaweiPay of the interface to implement the payment function. Among them, the Alipay payment SDK and the Huawei PaymentKit can be regarded as the differences in toolkits between HarmonyOS applications and MetaServices.

[0081] In short, in the business scenarios where the payment function is used in the feature layer, the actual payment is made by calling the toolkits adapted to each product through the pay() method provided by the payment interface IBasePay. That is, during the running of the above function implementation code, in the business payment scenario, one set of code in the feature layer can implement that the HarmonyOS application uses the Alipay payment SDK, and in the MetaService, the built-in Huawei PaymentKit in the system is used.

[0082] Based on Figure 2 the example content, in some specific examples, the method of the embodiment of the present application may further include (referring to the initialization method): the methods in the defined function interface include the initialization method; the initialization method is used to indicate that when any form of product is enabled, the function implementation code built for the form of product under the engineering project is run.

[0083] Exemplarily, the feature layer can provide the initialization method (such as the initData method) of the ICache interface to any form of product such as HarmonyOS applications or MetaServices for initialization, to indicate that when a certain user enables any form of product to implement the target business function, the function implementation code built for the form of product under the engineering project is run. In this way, the following business scenarios can be achieved: when the HarmonyOS application is enabled, the APIs of the HarmonyOS application are used to complete the caching, and when the MetaService is enabled, the APIs of the MetaService are used to complete the caching, so as to meet the personalized needs of users.

[0084] Based on Figure 2 Figure 2 Example content, in some specific examples, the method of the embodiments of the present application may further include (constructing common module code): constructing common module code under the above engineering project based on the defined content for the common module, so that any form of product can improve the consistency between function feedback interfaces by running the common module code.

[0085] Generally, a common module may refer to a component module that has no direct connection or a connection less than a certain condition with the business logic method defined by a specific function interface, such as a network request component, a tool class component, etc. The common module can be reflected in at least one of the following aspects: 1. Functional independence, the function of the common module does not depend on the business logic of a specific interface. For example, the main function of the network request component is to send network requests and process responses. It does not care what the specific business of the request is. Whether it is a login interface, a commodity query interface, or other interfaces, the network request component processes requests in the same way. The same is true for tool class components. The date processing tool class can be used anywhere that needs to process dates, not limited to the business scenario of a specific interface. 2. Reusability and generality: These common modules have high reusability and generality and can be used in multiple different business scenarios and interfaces. The network request component can be applied to each module of the entire system to provide network request services for different interfaces; tool class components such as string processing tool class can be used in multiple different business interfaces such as login, caching, commodity display, etc. to process operations such as string splicing, truncation, and replacement. 3. Decoupled design: Decoupling the common module from the interface business helps to improve the maintainability and scalability of the system. When the business logic of the interface changes, it will not affect the normal use of the common module; similarly, the update and optimization of the common module will not have a direct impact on the business logic of a specific interface. For example, when the business rules of the login interface change, common modules such as the network request component and the date processing tool class do not need to be modified.

[0086] Therefore, common module code can be constructed under the above engineering project, so that the effect of the function feedback interfaces presented by HarmonyOS applications and meta-services is highly consistent. The consistency between these interfaces can refer to the similarity in at least one aspect such as design style, output parameters, icon type, etc.

[0087] In summary, the embodiments of the present application only need a set of code to develop products of two application forms, namely HarmonyOS applications and meta-services, which greatly saves development manpower and material costs; the interface effects presented by the HarmonyOS applications and meta-services constructed through the embodiments of the present application are highly consistent.

[0088] Supplementary note, the above based on Figure 2 The execution order between the added steps "referencing the initialization method and constructing the common module code" for the example content and any one of the above steps S21 to S23 can be unrestricted, or they can be executed simultaneously; the execution order between the added steps such as "referencing the initialization method and constructing the common module code" can also be unrestricted, and it can be determined according to the actual situation.

[0089] Please refer to Figure 6 , a specific embodiment of a service function implementation device is provided in the second aspect of the present application. The device includes: a determination unit and a processing unit;

[0090] The determination unit is used to determine the difference points in reference aspects for realizing the target service function between the application software and the light application products.

[0091] The processing unit is used to define an interface based on the target service function to declare a function interface for the two types of products to call.

[0092] The processing unit is further used to construct the function implementation code of the function interface under the same engineering project according to the difference points and the content of the interface definition, so that any form of product can realize the target service function by running the method defined in the function interface.

[0093] In some specific examples, the determination unit is specifically used for:

[0094] Differentially compare the components and / or toolkits separately referenced by the two types of products to realize the target service function, and obtain the difference points between the two types of products regarding the components and / or toolkits.

[0095] In some specific examples, when the target service function is a caching function, the difference points include the caching components that are respectively allowed to be used between the two types of products;

[0096] When the target service function is a payment function, the difference points include the payment toolkits that are respectively restricted to be used between the two types of products.

[0097] In some specific examples, the processing unit is specifically used for:

[0098] Obtain the implementation class for realizing the function interface;

[0099] According to the specific implementation logic of the implementation class, use the difference points and the content of the interface definition to construct the function implementation codes respectively for the application software and the light application under the same engineering project.

[0100] In some specific examples, the processing unit is further used for:

[0101] The methods in the defined function interface include an initialization method; the initialization method is used to indicate that when any form of product is enabled, the function implementation code constructed for the form of product under the engineering project runs.

[0102] In some specific examples, the processing unit is further configured to:

[0103] Build common module code under the engineering project based on the defined content for the common module, so that any form of product can improve the consistency between function feedback interfaces by running the common module code.

[0104] In the embodiments of the present application, the operations performed by each unit of the business function implementation device are similar to those described in the foregoing first aspect or any specific method embodiment of the first aspect, and will not be elaborated herein specifically. Of course, the specific implementation process of each operation in the first aspect of the present application can also be implemented with reference to the relevant description in the second aspect.

[0105] Please refer to Figure 7 , the electronic device of the embodiment of the present application may include one or more processors (such as a central processing unit CPU, central processing units) and a memory, and one or more application programs or data are stored in the memory.

[0106] Among them, the memory may be volatile storage or persistent storage. The program stored in the memory may include one or more modules, and each module may include a series of instruction operations on the electronic device. Further, the processor may be configured to communicate with the memory and execute a series of instruction operations in the memory on the electronic device.

[0107] The electronic device may further include one or more power supplies, one or more wired or wireless network interfaces, one or more input / output interfaces, and / or, one or more operating systems, such as Windows Server, Mac OS X, Unix, Linux, FreeBSD, etc.

[0108] The processor may perform the operations performed in the foregoing first aspect or any specific method embodiment of the first aspect, which will not be elaborated herein specifically.

[0109] A computer-readable storage medium provided by the present application includes instructions, and when the instructions run on a computer, the computer is caused to execute the method described in the foregoing first aspect or any specific implementation manner of the first aspect.

[0110] A computer program product provided by the present application includes instructions or a computer program, and when the computer program product runs on a computer, the computer is caused to execute the method described in the foregoing first aspect or any specific implementation manner of the first aspect.

[0111] It should be understood that in various embodiments of the present application, the sequence numbers of the steps do not indicate the order of execution, and the order of execution of the steps should be determined by their functions and internal logics, and should not constitute any limitation on the implementation process of the embodiments of the present application. The operation contents added or refined in the various example solutions of the above method or device (if any) do not necessarily have to be executed during specific implementation. For example, if two or more operations are added, these operations can be combined or implemented separately, depending on the actual scenario.

[0112] Those skilled in the art can clearly understand that for the convenience and conciseness of description, the specific working processes of the above-described system (if any) and device can refer to the corresponding processes in the foregoing method embodiments, and will not be elaborated herein.

[0113] In several embodiments provided by the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the division of units is only a logical function division, and there can be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system or device, or some features can be ignored or not executed. Another point is that the displayed or discussed couplings or direct couplings or communication connections to each other can be through some interfaces, and the indirect couplings or communication connections of devices or units can be in electrical, mechanical or other forms.

[0114] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place, or may be distributed to multiple network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0115] In addition, in each embodiment of the present application, the functional units can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The above integrated units can be implemented in the form of hardware or in the form of software functional units.

[0116] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of this technical solution, can be embodied in the form of a software product. This computer software product (or computer program product) is stored in a storage medium and includes several instructions for causing a computer device (which can be a personal computer, a business server, or a network device, etc.) to execute all or part of the steps of the methods described in various embodiments of this application. The foregoing storage medium includes: various media that can store program codes, such as USB flash drives, mobile hard disks, read-only memories (ROMs), random access memories (RAMs), magnetic disks, or optical discs.< / t> < / string>

Claims

1. A method for implementing a service function, characterized in that, including: determining the differences in references between application software and light application products in order to achieve the target business function; defining an interface based on the target business function to declare a function interface for the two types of products to call; constructing the function implementation code of the function interface under the same engineering project according to the differences and the content of the interface definition, so that any one of the two types of products can achieve the target business function by running the methods defined in the function interface.

2. The method for implementing a service function according to claim 1, wherein The determination of the differences in references between application software and light application products in order to achieve the target business function includes: conducting a differential comparison of the components and / or toolkits separately referenced by the two types of products to achieve the target business function, and obtaining the differences in components and / or toolkits between the two types of products.

3. The service function implementation method according to claim 2, wherein When the target business function is a caching function, the differences include the caching components that are respectively allowed to be used by the two types of products. When the target business function is a payment function, the differences include the payment toolkits that are respectively limited to be used by the two types of products.

4. The service function implementation method according to claim 1 or 2, characterized in that, The construction of the function implementation code of the function interface under the same engineering project according to the differences and the content of the interface definition includes: obtaining an implementation class for implementing the function interface; according to the specific implementation logic of the implementation class, using the differences and the content of the interface definition to construct function implementation codes respectively for the application software and the light application under the same engineering project.

5. The service function implementation method according to claim 1 or 2, characterized in that The method further includes: defining that the methods in the function interface include an initialization method; the initialization method is used to indicate that when any one of the two types of products is enabled, the function implementation code constructed for the type of product under the engineering project is run.

6. The method for implementing a service function according to claim 1 or 2, characterized in that The method further includes: constructing public module code under the engineering project based on the defined content for the public module, so that any one of the two types of products can improve the consistency between function feedback interfaces by running the public module code.

7. A service function implementation device, characterized in that, including: a determination unit and a processing unit; the determination unit is used to determine the differences in references between application software and light application products in order to achieve the target business function; the processing unit is used to define an interface based on the target business function to declare a function interface for the two types of products to call; the processing unit is further used to construct the function implementation code of the function interface under the same engineering project according to the differences and the content of the interface definition, so that any one of the two types of products can achieve the target business function by running the methods defined in the function interface.

8. An electronic device, characterized in that, including: a processor and a memory; the processor is configured to communicate with the memory and execute the instructions in the memory to implement the method according to any one of claims 1 to 6.

9. A readable storage medium, characterized in that, The readable storage medium stores computer instructions, and when the computer instructions are executed by the processor, the method according to any one of claims 1 to 6 is implemented.

10. A computer program product, characterized in that, The computer program product includes computer instructions, and when the computer instructions are executed by the processor, the method according to any one of claims 1 to 6 is implemented.

Images