Object processing method and device, equipment and medium

By instantiating associated inherited classes in system-level applications and rewriting the clone implementation function via callback, the problem that modules at the operating system level and application development level cannot directly call each other's standard libraries is solved. This achieves lifecycle management of complex objects and transfer of object ownership, thus avoiding memory leaks.

CN121029136APending Publication Date: 2025-11-28BEIJING CO WHEELS TECH CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202410670213.9
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2024-05-28
Publication Date
2025-11-28

AI Technical Summary

Technical Problem

In system-level application development, modules at the operating system level and application development level cannot directly call each other's standard libraries due to the use of different compilers. This makes it impossible to achieve seamless calls and callbacks at the standard library level. Furthermore, parameter transmission interfaces developed using lower-level programming languages ​​cannot utilize the features of higher-level programming languages, such as lifecycle management of complex objects.

Method used

By instantiating the associated inheritance class in the first program, deriving the inherited class object based on the base class in the second program, and rewriting the clone implementation function through the complex object interface function callback, the cloning of the inherited class object is achieved, thereby obtaining ownership of the complex object. The polymorphic inheritance function of the object-oriented programming language is used to realize the passing of parameters between different levels of code.

Benefits of technology

It enables the transfer of object ownership between different code modules, efficiently solves the functionality provided by high-level programming languages, and implements lifecycle management of complex objects through cloning, avoiding memory leaks.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN121029136A_ABST
    Figure CN121029136A_ABST
Patent Text Reader

Abstract

The embodiment of the invention provides an object processing method, device and equipment and a medium object processing method. The method comprises the steps that under the condition that an object needing to be transmitted is a complex object, an association inheritance class associated with the complex object in a first program is instantiated, an inheritance class object is obtained, and the complex object is transmitted to the inheritance class object; taking the inheritance class object as a passing parameter, and calling a complex object interface function provided by a second program; after the inheritance class object is received through the complex object interface function, the second program calls back the rewrite clone implementation function, and the ownership of the inheritance class object is obtained based on the rewrite clone implementation function. By adopting the scheme of the embodiment of the invention, the function provided by the object-oriented high-level language can be adopted to realize the ownership transmission of the complex object.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This disclosure relates to the field of software programming technology, and more specifically to a method, apparatus, device, and medium for processing objects. Background Technology

[0002] When designing and developing certain system-level applications, it is generally necessary to develop and compile program code at both the operating system level and the application development level to obtain system-level modules and application development level modules, and then combine the system-level modules and application development level modules into a system-level application. For example, when designing and developing Android system-level operating applications, code development and compilation are required at both the Android open-source operating system level (Android Open Source Project, AOSP) and the application-level development platform level (Native Development Kit, NDK) to obtain corresponding AOSP-level code modules and NDK-level code modules, and then combine the AOSP-level code modules and NDK-level code modules into an Android system-level application.

[0003] Although the operating system and application development code are written in the same high-level programming language, for security and compatibility reasons, the source code is compiled using different compilers. The application binary interface (ABI) of the standard library used by different compilers is different, which means that the system-level modules and the application development modules cannot directly call each other's standard library, and cannot achieve seamless calling and callback at the standard library level.

[0004] To address this issue, related technologies employ a lower-level programming language (as opposed to the aforementioned high-level programming languages) that is compatible with both the operating system and application development level compilers to develop a communication interface. This interface is then used to enable communication between system-level modules and application development level modules. For example, related technologies use a C interface written in C to facilitate communication between AOSP-level code modules and NDK-level code modules (both written in C++).

[0005] However, when developing parameter transmission interfaces using lower-level programming languages, the features and functionalities of higher-level programming languages ​​cannot be used due to the limitations of the parameter transmission interface code. For example, the automated management of the lifecycle of complex objects cannot be achieved. Summary of the Invention

[0006] To address the aforementioned technical problems, this disclosure provides a method, apparatus, device, and medium for processing objects. In a first aspect, this disclosure provides a method for processing objects, including:

[0007] In response to obtaining the object to be transferred, the object type of the object to be transferred is determined, wherein the object to be transferred is an object whose ownership needs to be transferred from the first program to the second program;

[0008] In the case where the object to be passed is a complex object, the associated inheritance class in the first program that is associated with the complex object is instantiated to obtain an inheritance class object, and the complex object is passed to the inheritance class object; wherein, the associated inheritance class is derived from the base class in the second program, the base class includes a clone function declared as a pure virtual function, and the inheritance class includes an overridden clone implementation function of the clone function, the overridden clone implementation function being used to clone the inheritance class object;

[0009] The inherited class object is passed as a parameter to call the complex object interface function provided by the second program.

[0010] After receiving the inherited class object through the complex object interface function, the second program calls back the overridden clone implementation function and obtains ownership of the inherited class object based on the overridden clone implementation function.

[0011] Optionally, the second program calls back the overridden clone implementation function to obtain ownership of the inherited class object based on the overridden clone implementation function, including:

[0012] The second program calls back the overridden clone implementation function to clone the inherited class object, thereby obtaining a cloned object of the inherited class object;

[0013] Based on the cloned object, create a second program's own inherited class object to obtain ownership of the inherited class object.

[0014] Optionally, the second program calls back the overridden cloning implementation function to clone the inherited class object, obtaining a cloned object of the inherited class object, including:

[0015] The second program finds the corresponding virtual function table through the virtual table pointer of the inherited class object, and determines the overridden clone implementation function based on the virtual function table; wherein, the virtual function table is used to store the address of the overridden clone implementation function;

[0016] The overridden clone function is used to clone the inherited class object.

[0017] Optionally, creating a derived class object of the second program based on the cloned object includes:

[0018] A smart pointer is used to inherit the cloned object, and a second program creates its own inherited class object based on the smart pointer to obtain ownership of the inherited class object.

[0019] Optionally, the base class further includes a function declared as a pure virtual function, and the inherited class includes an overridden function that implements the function. The overridden function is used to enable the first program to listen for events occurring in the second program.

[0020] After acquiring ownership of the complex object, the method further includes: the second program calling back the rewrite function implementation function and passing the event to be listened to as a parameter, so that the event to be listened to can be listened to by the first program.

[0021] Optionally, the base class further includes a virtual destructor for destructing the inherited class object and declared as a pure virtual function; the method further includes:

[0022] After the second program executes each of the rewritten implementation functions, including the rewritten clone implementation function, the virtual destructor is executed to release the memory space of the polymorphic inherited class object; wherein, the virtual destructor is used to clear and release the memory space allocated to the inherited class object.

[0023] Optionally, the first program further includes a container class, the container class including a container pointer and a container length; the method further includes:

[0024] When the type of the object to be passed is a simple container class object, the container class of the first program is instantiated to obtain a container class object, and the original pointer is passed to the container pointer of the container class object, and the object length is passed to the container length;

[0025] The container class object is passed as a parameter to call the container object interface function provided by the second program.

[0026] In response to receiving the container class object through the container object interface function, the second program packages a new container class object with ownership based on the container pointer and the container length.

[0027] Optionally, the method further includes:

[0028] When the type of the object to be passed is a simple struct object, the simple struct object is used as the passing parameter, and the struct object interface function provided by the second program is called.

[0029] Upon receiving the simple struct object through the struct object interface function, the second program acquires ownership of the simple struct object.

[0030] In a second aspect, embodiments of this disclosure provide an object processing apparatus, comprising:

[0031] The object type determination unit is used to determine the object type of the object to be transmitted in response to obtaining the object to be transmitted, wherein the object to be transmitted is an object whose ownership needs to be transferred from the first program to the second program.

[0032] An object creation unit is used to instantiate the associated inheritance class in the first program that is associated with the complex object when the object to be passed is a complex object, to obtain an inheritance class object, and to pass the complex object to the inheritance class object. The associated inheritance class is derived from a base class in the second program. The base class includes a clone function declared as a pure virtual function. The inheritance class includes an overridden clone implementation function of the clone function. The overridden clone implementation function is used to clone the inheritance class object.

[0033] The function call unit is used to call the complex object interface function provided by the second program by passing the inherited class object as a parameter.

[0034] The callback unit is used to cause the second program to call back the overridden clone implementation function after receiving the inherited class object through the complex object interface function, and to obtain ownership of the inherited class object based on the overridden clone implementation function.

[0035] Thirdly, embodiments of this disclosure provide a computing device, characterized in that it includes a processor and a memory, the memory being used to store a computer program; when the computer program is loaded by the processor, it causes the processor to execute the object processing method as described above.

[0036] Fourthly, embodiments of this disclosure provide a computer-readable storage medium storing a computer program that, when executed by a processor, causes the processor to implement the object processing method as described above.

[0037] The technical solution provided in this disclosure has the following advantages compared with the prior art:

[0038] The solution provided in this disclosure creates a derived class object when the object to be transferred is a complex object. This related derived class is created based on the base class in the second program. Based on the functionality of object-oriented programming, after the second program receives the derived class object through the complex object interface function, it can directly call back and override the cloning implementation function to clone the derived class object, thereby acquiring ownership of the derived class object, and thus ownership of the complex object. Therefore, the solution in this disclosure can utilize the functionality provided by object-oriented high-level languages ​​to achieve the transfer of ownership of complex objects. Attached Figure Description

[0039] The accompanying drawings, which are incorporated in and form a part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure.

[0040] To more clearly illustrate the technical solutions in the embodiments of this disclosure or the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, those skilled in the art can obtain other drawings based on these drawings without any creative effort, wherein:

[0041] Figure 1 This is a flowchart of the object processing method provided in the embodiments of this disclosure;

[0042] Figure 2 This is a flowchart illustrating the method for passing simple container class objects provided in this embodiment of the disclosure;

[0043] Figure 3 This is a schematic diagram of the structure of the object processing apparatus provided in the embodiments of this disclosure;

[0044] Figure 4 This is a schematic diagram of the structure of a computing device provided in an embodiment of this disclosure. Detailed Implementation

[0045] Embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.

[0046] The term "comprising" and its variations as used herein are open-ended, meaning "including but not limited to". The term "based on" means "at least partially based on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". Definitions of other terms will be given in the description below. It should be noted that the concepts of "first", "second", etc., used in this disclosure are only used to distinguish different devices, modules, or units, and are not intended to limit the order of functions performed by these devices, modules, or units or their interdependencies.

[0047] It should be noted that the terms "a" and "a plurality of" used in this disclosure are illustrative rather than restrictive, and those skilled in the art should understand that, unless otherwise expressly indicated in the context, they should be understood as "one or more".

[0048] To address the problem that existing technologies using low-level programming languages ​​to develop parameter transmission interfaces for passing parameters between different code modules cannot utilize the functionalities provided by high-level programming languages, this disclosure provides a novel object processing method. The object processing method provided in this disclosure utilizes polymorphic inheritance and related functionalities provided by object-oriented programming languages. By using object-oriented programming languages, parameter passing between different code levels can be achieved, allowing the second program to acquire ownership of the object.

[0049] Figure 1 This is a flowchart of an object processing method provided in an embodiment of this disclosure. For example... Figure 1 As shown, the object processing method provided in this embodiment includes S110-S150.

[0050] The object processing method provided in this embodiment is executed by a computing device loaded with first program and second program code, and capable of loading and running the aforementioned first program and second program code during program execution.

[0051] For convenience, the following examples use the NDK-level code in the Android system as the first program and the AOSP-level code module as the second program to illustrate the object processing method provided in this disclosure. In practical applications, the first program is not limited to the aforementioned NDK-level code module, and the second program is not limited to the aforementioned AOSP-level code module.

[0052] In some specific implementations, the AOSP-level code modules and NDK-level code modules are obtained by compiling the program source code written by the programmers using the corresponding compilers. The AOSP-level code modules and NDK-level code modules are stored as dynamic link libraries and are loaded and run by the computing device when needed.

[0053] S110: In response to obtaining the object to be passed, determine the object type of the object to be passed; if it is a complex object, execute S120; if it is a non-complex object, execute S150.

[0054] In this disclosure, the object to be transferred is the object whose ownership needs to be transferred from the first program to the second program. In practical applications, the object to be transferred may be a complex object or a non-complex object. A complex object is one that includes complex encapsulation, type erasure, or involves object ownership management. Only the first program can determine the internal members and member functions of a complex object, as well as its specific data storage structure and data processing methods. For parties other than the first program (including the second program), the complex object is essentially a black box.

[0055] In practical applications, although the aforementioned complex objects use the same name in both the first and second programs, the different ABIs used by the NDK-level and AOSP-level standard libraries during compilation prevent direct transfer of these complex objects between the two programs. In some embodiments, the complex object is such as std::map.<int,double> std::shared_ptr <std::vector <int>Objects instantiated from complex classes such as Ndk::UserDefinedClass.

[0056] Non-complex objects are those that do not include the aforementioned complex encapsulation and type erasure. Non-complex objects can be simple container class objects or simple struct objects.

[0057] S120: Instantiate the associated inherited class of the complex object in the first program, obtain the inherited class object, and pass the complex object to the inherited class object.

[0058] After determining that a complex object needs to be passed, that is, when it is determined that a complex object that the first program is managing and owns needs to be passed to the second program, the computing device loads and instantiates the inherited class of the first program according to the program code of the first program, and obtains the inherited class object.

[0059] The process of creating an object of an inherited class based on an inherited class is as described in existing technologies. It includes loading the inherited class, allocating memory, executing the constructor, and returning the object pointer. The specific creation process will not be analyzed in detail here. For relevant content, please refer to existing technology literature.

[0060] In practice, computing devices can create inherited class objects by passing complex objects as parameters to function calls, similar to function calls, and then pass the complex objects to the inherited class objects. Passing the complex object to the inherited class object involves passing a pointer to the complex object to a member of the same type within the complex object.

[0061] In this embodiment of the disclosure, the aforementioned inherited class is derived from the base class in the second program, that is, the inherited class is a subclass of the base class in the second program.

[0062] Specifically, the base class includes a clone function declared as a pure virtual function, and the derived class includes an overridden clone implementation function for the clone function. This overridden clone implementation function is used to clone objects of the derived class. It's conceivable that since complex objects and derived class objects are both created by the first program, the overridden clone implementation function written in the first program can achieve the cloning of derived class objects.

[0063] The following examples of the base class and inherited class in the embodiments of this disclosure are provided in the form of program source code to facilitate understanding of the operation and limitations in step S120, and thus facilitate understanding of the following text.

[0064] In some embodiments, the base class's program code is as follows.

[0065]

[0066] The virtualObjectInterface* clone()const = 0 is the declaration in the base class that the clone function is a pure virtual function.

[0067] In practical applications, due to the inherent limitations of complex objects, they can only be passed through cloning, not copying. To avoid copying complex objects and inherited class objects, the base class declares `ObjectInterface(const ObjectInterface&) = delete` before declaring the cloning function, thus disabling the copy constructor.

[0068] Furthermore, to manage the lifecycle of inherited class objects, a virtual destructor is included in the base class. This destructor is used to delete the derived class object using a pointer from the base class when the lifecycle of a subsequent inherited class object ends. Additionally, `protected:ObjectInterface() = default` declares the default constructor.

[0069] Corresponding to the base class program code mentioned above, the inherited class program code is as follows.

[0070]

[0071] Obj is a member class created by the first program to handle complex objects. It is of type Ndk::Object, which is the complex object type in NDK.

[0072] The `virtualObjectInterface* clone() const override { / / return new ObjectImpl(obj);}` method represents the overriding of a clone function declared as a pure virtual function in the base class, which is essentially overriding the clone implementation function. For simplicity, the overridden clone implementation function is not actually written in code here; instead, a simplified representation is used to demonstrate the implementation in the inherited class.

[0073] In practice, the computing device can execute the following program code to create an object of the inherited class based on the inherited class and pass the complex object to the inherited class object.

[0074] void ndk_foo(const Ndk::Object&obj)

[0075] {

[0076] auto objWrapper=ObjectImpl(obj);

[0077] }

[0078] As described in the aforementioned code, the computing device instantiates a subclass object named objWrapper by executing objWrapper = ObjectImpl(obj) and passes the complex object obj to the aforementioned subclass object.

[0079] S130: Pass the inherited class object as a parameter to call the complex object interface function provided by the second program.

[0080] Complex object interface functions are interface functions that are initially defined in the first program but implemented in a second program. These complex object interface functions can accept parameters provided by the first program and pass those parameters to the second program.

[0081] In one embodiment, the complex object interface function is declared as aosp_interface_foo(objWrapper); based on the aforementioned declaration, it can be determined that the first program can pass the already created inherited class object objWrapper to the second program.

[0082] Here's an analysis. In practical applications, for convenience, the declaration of the base class in the second program can be written as a parameter type wrapper interface, along with the complex object interface function, and included in the header file. When writing the first program code, this header file can be directly loaded to ensure correct compilation.

[0083] S140: After receiving the inherited class object through the complex object interface function, the second program calls back to rewrite the clone implementation function, and obtains ownership of the inherited class object based on the rewritten clone implementation function.

[0084] In practice, after the first program calls the complex object interface function, the computing device loads the implementation code of the complex object interface function provided by the second program, forming a new thread, and uses the aforementioned thread to implement the function of the complex object interface function.

[0085] In a specific application, when the complex object interface function is declared as aosp_interface_foo(objWrapper), the specific implementation of this complex object interface function can be as follows.

[0086] void aosp_interface_foo(const ObjectInterface&obj)

[0087] {

[0088] std::shared_ptr <objectinterface>sp{obj.clone()};

[0089] return aosp_foo(create_aosp_object(sp));

[0090] }

[0091] According to the aforementioned code, after receiving the inherited class object, the complex object interface function calls back the overridden cloning implementation function in the inherited class object, thus cloning the inherited class object. After obtaining the cloned object, the second program can acquire ownership of the inherited class object by inheriting the cloned object. Since the inherited class object contains the aforementioned complex object, the second program correspondingly acquires ownership of the complex object.

[0092] S150: Determine the type of the non-complex object, and pass it to the second program using an associative passing method based on the type of the non-complex object.

[0093] The specific implementation details of S150 will be analyzed in more detail later.

[0094] The following explains why the second program can use a callback method to call the overridden clone implementation function in the inherited class object. To understand the aforementioned scheme, we will first analyze some operations in the compilation process of the inherited class and some operations in the creation process of the inherited class.

[0095] During the compilation process of an inherited class, since the inherited class is derived from a base class, a virtual function table is created during compilation, and the addresses of virtual functions are placed in the virtual function table (referred to as the virtual table in the industry). If the inherited class includes the implementation of a virtual function, the virtual function table formed during the compilation process will store the address of the overridden virtual function. For example, if the virtual function is a cloned function, the virtual table of the corresponding inherited class object will store the address of the cloned overridden implementation function.

[0096] When a derived class is instantiated and an object of that derived class is obtained, the computing device stores a virtual table pointer in the memory space corresponding to the derived class object. When a corresponding virtual function is called through the derived class object, the computing device first finds the corresponding virtual function table through the virtual table pointer of the derived class object, and then finds the corresponding virtual function based on the address of the virtual function in the virtual function table.

[0097] Returning to the scheme of this embodiment, after the second program receives the inherited class object through the complex object interface function, it can obtain the virtual table pointer of the inherited class object. Because the inherited class object is created based on the inherited class derived from the base class of the second program, the second program can directly use the virtual table pointer of the inherited class object and use the virtual table pointer to find the corresponding virtual function table; wherein, the virtual function table is used to store the address of the overridden clone implementation function. Subsequently, based on the address stored in the aforementioned virtual function table, the overridden clone implementation function can be found, which allows the computing device to load the overridden clone implementation function (equivalent to a callback) to clone the inherited class object, and thus obtain ownership of the inherited class object through cloning, thereby realizing ownership of the complex object.

[0098] In practical applications, after acquiring ownership of a complex object, the second program can then manage the lifecycle of the complex object based on Resource Acquisition Is Initialization (RAII), enabling it to be safely destroyed in the second program and thus avoiding memory leaks.

[0099] It should be noted that although the second program has acquired ownership of the inherited class object, from the perspective of the second program, the inherited class object and its contained complex member objects are still a black box.

[0100] As mentioned earlier, in S140, the second program callback rewrites the clone implementation function, thus acquiring ownership of the complex object. Specifically, based on the program code above, in practical applications, the computing device uses the following S141-S142 steps to acquire ownership of the complex object.

[0101] S141: The second program callback rewrites the clone implementation function to clone the inherited class object, and obtains the cloned object of the inherited class object.

[0102] Specifically, the callback overrides the clone implementation function, and the clone object of the inherited class is obtained through obj.clone().

[0103] In high-level programming languages, a clone implementation function is a hidden copy constructor implemented by the compiler during code compilation. It uses the prototype pattern (such as C++) to specify the type of object to be created with a prototype instance and creates a new object by copying the existing object. During the initial compilation process, the compiler utilizes the features provided by the high-level programming language to create a hidden copy constructor based on the characteristics of the inherited class object itself; this hidden copy constructor serves as the overridden clone implementation function that is actually used.

[0104] In practical applications, as described above, S141 specifically includes S1411-S1412.

[0105] S1411: The second program finds the corresponding virtual function table through the virtual table pointer of the inherited class object, and determines the rewritten clone implementation function based on the virtual function table; wherein, the virtual function table is used to store the address of the rewritten clone implementation function;

[0106] S1412: Implement function cloning of inherited class objects based on overriding cloning.

[0107] In other words, the second procedure utilizes the association between the virtual table pointer and the virtual function table in class inheritance. The virtual table pointer points to the premise of the overridden clone implementation function, thereby enabling the call to the overridden clone implementation function to clone the inherited class object.

[0108] S142: Based on the cloned object, create a second program's own inherited class object to obtain ownership of the inherited class object.

[0109] After obtaining the cloned object, a second program can then create its own inherited class object based on the cloned object. Because the inherited class object belongs to the second program, the second program acquires ownership of the inherited class object and can manage its lifecycle.

[0110] In specific implementation, the aforementioned S142 may include the following S1421.

[0111] S1421: Use smart pointers to inherit the cloned object, and create a second program's own inherited class object based on the smart pointers to obtain ownership of the inherited class object.

[0112] Smart pointers are pointers designed in high-level programming languages ​​to ensure that programs are free from memory and resource leaks and are exceptionally safe. Using smart pointers, memory is automatically and appropriately allocated during construction and automatically released when no longer needed, thus eliminating the need for developers to manually manage memory.

[0113] In some instances, smart pointers are used to manage cloned objects, specifically std::shared_ptr. <objectinterface>sp{} is obtained. By using smart pointers to inherit cloned objects, the memory specified by the original pointer can be deleted at the appropriate time.

[0114] After obtaining a cloned object using smart pointers, a second program can then create a derived class object with ownership based on the smart pointers. This derived class object is essentially still a derived class object. At this point, the second program acquires ownership of the complex object.

[0115] In some embodiments of this disclosure, the base class may include not only clone functions declared as pure virtual functions, but also function calls declared as pure virtual functions. The inherited class includes overridden implementation functions of the aforementioned function calls. These overridden implementation functions can be used to enable the first program to monitor events occurring in the second program.

[0116] Corresponding to the aforementioned functional functions and reimplementation functions, after acquiring ownership of the complex object, the following S160 can also be executed.

[0117] S160: The second program callback rewrite function implements the function and passes the event to be listened to as a parameter so that the event to be listened to can be listened to by the first program.

[0118] As mentioned earlier, the overridden function implements the functionality of a first program to listen for events occurring in the second program. Since the second program has acquired ownership of the inherited class object, it can call back the overridden function's method and pass the parameters of the events to be monitored to the first program, thus enabling the first program to listen for events occurring in the second program. Specifically, when the second program calls back the overridden function, it passes the event to be monitored as a parameter, allowing the first program to listen for that event.

[0119] For example, the Android system divides software modules into functional modules at the NDK level and functional modules at the AOSP level.

[0120] The functional modules at the NDK level are application-level modules, which often contain complex business logic. As the software iterates, this business logic will be continuously upgraded and iterated due to business needs.

[0121] As part of the operating system, AOSP-level modules need to ensure reliable power supply, resulting in a relatively low update frequency. From a software engineering perspective, AOSP-level modules generally contain only the necessary and minimal logical power, such as operations on the hardware abstraction layer, drivers, and / or the Android kernel.

[0122] In practical applications, if the modules involving business logic are written at the AOSP layer, changes in business requirements and logic will necessitate modifications to these AOSP-level modules. This contradicts the functionality of the AOSP-level modules.

[0123] By employing the method of this embodiment, a pure virtual function is declared in the base class of the second program, and an overridden function implementing the function is written in the derived class of the first program. After the second program acquires ownership of the derived class object, it uses a callback to the overridden function to enable the first program to listen for events occurring in the second program. In this way, complex business logic code only needs to be written in the first program (e.g., at the NDK level), without needing to be written in the second program (e.g., at the AOSP level), thus avoiding the problem of the second program needing continuous iteration and upgrades due to business logic requirements.

[0124] In practice, when the first program is an NDK-level module and the second program is an AOSP-level module, the NDK-level module can implement C++ exceptions that occur in the AOSP-level module by writing specific re-implementation functions, without requiring the AOSP-level module to convert the C++ exceptions into C program code and then pass them to the NDK-level module.

[0125] In practical applications, according to software function specifications, the interface between the first and second programs should be as small as possible. Therefore, the aforementioned function implementation functions should also be as few as possible, specifically the fewest functions required to listen for events occurring in the second program. In other words, overriding function functions does not mean rewriting all functions of a complex object, but rather the specific functions required to complete the necessary specific functions.

[0126] In practice, the second procedure still finds the corresponding virtual function table through the virtual table pointer of the inherited class object, and then determines the function to implement the overriding function based on the virtual function table. The virtual function table is used to store the address of the function to implement the overriding function. In other words, the address of the function to implement the overriding function is found from the virtual function table, and the function to implement the overriding function is loaded.

[0127] As analyzed earlier, the base class also includes a declaration prohibiting copying. Therefore, derived classes based on the base class also include a declaration prohibiting copying. The purpose of including this declaration in the base class is to prevent the derived class from executing a copy operation during its development, thus avoiding the automatic construction of a rewritten clone implementation function through cloning.

[0128] As shown in the base class code above, the base class also includes a virtual destructor, declared as a pure virtual function, for destructing objects of the inherited class. The virtual destructor is used to clean up and release the memory space allocated to objects of the inherited class. Accordingly, after executing S140 or S160, the following S170 can also be executed.

[0129] S170: After the second program executes the various overridden implementation functions, including the overridden clone implementation function, it executes the virtual destructor to release the memory space of the polymorphic inherited class object; wherein, the virtual destructor is used to clean up and release the memory space allocated to the inherited class object.

[0130] If the functionality of the destructor is required, after all the overridden implementation functions, including the aforementioned overridden clone implementation function, have been executed, the memory space of the polymorphic inherited class object can be released by executing the virtual destructor, thus avoiding memory leaks.

[0131] The preceding text analyzed how to pass complex objects. In practical applications, the objects passed from the first program to the second program may include not only the aforementioned complex objects, but also other types of objects, such as simple container objects or simple struct objects. The following analysis addresses how to pass other objects.

[0132] In some embodiments, the object passed from the first program to the second program also includes a simple container class object. A simple container class object is obtained by instantiating a simple container class. Specifically, a simple container class refers to a Standard Template Library (STL) or an inner class of the second program that has an internal C implementation; the aforementioned internal C implementation refers to the raw pointer and length of the content held by the container. A simple container class can be such as std::string or std::vector. <int>std::string_view and String16 (AOSP base classes).

[0133] Due to compilation limitations, the aforementioned simple container class exhibits different behaviors in the first program (such as the NDK level) and the second program (such as the AOSP level), meaning their corresponding ABIs are incompatible. Therefore, instantiated objects of the aforementioned simple container class cannot be directly passed as parameters. However, considering that the raw pointers and sizes of the contents held by the simple container class object can be obtained, the members of the simple container class object can be extracted and passed using an unpacking and packing method.

[0134] The following analysis examines the method in S150 for determining the type of a non-complex object and passing it to the second program using an associative passing method based on the type of the non-complex object. As analyzed earlier, a non-complex object can be a simple container class object or a simple struct object.

[0135] Figure 2 This is a flowchart illustrating the method for passing simple container class objects provided in this embodiment of the disclosure. Figure 2 As shown, the methods for passing simple container class objects include S210-S240.

[0136] S210: If it is determined that the object to be passed is a simple container class object, obtain the original pointer and object length of the simple container class object.

[0137] S210 is essentially the process of unpacking simple container class objects.

[0138] S220: Instantiate the container class of the first program, obtain a container class object, pass the original pointer to the container pointer of the container class object, and pass the object length to the container length.

[0139] In this embodiment of the disclosure, the first procedure includes a pre-declared container class. Members of the container class include a container pointer and a container length, where the container pointer is essentially a raw pointer. After obtaining a container class object, the container pointer and container length within the container class object can be initialized using the raw pointer and object length of the simple container class object, respectively.

[0140] In practical applications, the aforementioned container class is a container class created in the second program, which can be written into the interface header file. When programming the first program, by preloading the aforementioned interface header file, the aforementioned container class can be written into the first program's code for use in subsequent compilation and object instantiation during program execution.

[0141] In practice, the container class code is as follows.

[0142] struct SimpleContainer

[0143] {

[0144] const char*data;

[0145] size_t length;

[0146] }

[0147] S230: Pass the container class object as a parameter and call the container object interface function provided by the second program.

[0148] After the container class object is created, the first program can then call the container object interface function provided by the second program to pass the container class object to the second program.

[0149] The container object interface functions are intended for the first program, but are implemented in the second program. Because the container class is declared in the second program, the second program can resolve objects instantiated from this class.

[0150] S240: In response to receiving a container class object through the container object interface function, the second program packages a new container class object with ownership based on the container pointer and container length.

[0151] In some embodiments, after receiving a container class object through the container object interface function, the second program extracts the container pointer and container length from the container class object, then instantiates a new container class object that it owns, and passes the aforementioned container pointer and container length to the original container class object, thus forming a new container class object owned by the second program. After acquiring ownership of the new container class object, the second program can then perform corresponding operations based on its ownership of the new container class object, such as reading and modifying data within the container.

[0152] The simple structure object mentioned in this embodiment is a structure object containing standard library types and user-defined types. Its structure members may have special members such as destructors and copy constructors, and the aforementioned special members can still be nested. The aforementioned simple structure object is indistinguishable between the first program and the second program. Therefore, the first program can use a conventional parameter passing method to pass the simple structure object to the second program, specifically using the following steps S310-S320.

[0153] S310: Pass a simple struct object as a parameter and call the struct object interface function provided by the second program.

[0154] S320: In response to receiving a simple struct object through the struct object interface function, the second program acquires ownership of the simple struct object.

[0155] As analyzed above, in order to pass complex objects and simple container class objects, the base class and interface functions of the objects can be written into the interface header file. When writing the first program code, the aforementioned interface header file is loaded into the first program code to ensure that the first program code can be compiled correctly. It should be noted that the aforementioned interface header file needs to meet the following requirements: (1) It does not contain any standard library types or header files of any standard library, but it can include header files of lower programming languages, such as C language header files; (2) The header file does not contain global variables.

[0156] To provide a clearer understanding of this solution, the following example will further analyze the object handling methods within it. The goal of this example is to allow a vehicle application within an NDK-level module of the Android system to listen for and process events from the power management module within the AOSP-level module. This example also demonstrates the implementation of functor-level callbacks between the NDK-level and AOSP-level modules.

[0157] The AOSP-level power management library interface is summarized below.

[0158] class CarPowerManager

[0159] {

[0160] public:

[0161] using Listener=std::function<void(int statePrev,intstateCurr)> ;

[0162] / / The callback will be performed in a new thread

[0163] int setListener(Listener listener,const android::String16&packageName);

[0164] }

[0165] The following points should be noted here: (1) The parameter listener is created in the NDK calling thread. After the call, the ownership of the listener is transferred to the AOSP power management library; (2) The AOSP power management library is responsible for calling back the NDK-level function through the listener in another working thread, and is responsible for destroying the listener when needed; (3) The type android::String16 of packageName is a unique type of AOSP and does not exist in NDK.

[0166] To achieve the goal of this solution, the following operations need to be performed: (1) Design an AOSP to NDK interface and form an interface header file based on the aforementioned AOSP to NDK interface. The aforementioned AOSP to NDK interface contains a complex object interface function setListener. (2) The aosp parameter type of the second parameter of the AOSP to NDK object interface function setListener is android::String16, which belongs to the system-level simple container type at the AOSP level. For its corresponding ndk parameter type, we can choose std::string. The two types can be converted and passed using the unpacking-packing method based on the container object interface function. (3) The first parameter of the AOSP to NDK interface function setListener is listener, and its aosp parameter type is std::function, which is a complex object. Its corresponding ndk parameter type is also std::function with the same name. This complex type needs to be converted and passed using the solution involving complex object interface functions in the aforementioned embodiment.

[0167] In practical implementation, we first analyze the functional transformation from NDK's `std::function` to AOSP's `std::function` and the core function of the parameter passing interface. Clearly, this is a functional transformation of a functor, and a functor is a callable object. Its core functionality, or parameter interface core function, is as follows.

[0168]

[0169] Following the aforementioned operational approach, we first design the base class and object interface functions in AOSP, and then use the declarations of the aforementioned base class and object interface functions to form the AOSP interface header file to NDK, the code of which is as follows.

[0170] The base class source code is as follows.

[0171]

[0172] The function declaration for the complex object interface is as follows.

[0173]

[0174] The aforementioned AOSP NDK interface header file does not include types and header files for the C++ standard library and third-party libraries. Based on the first parameter CarPMWrapper::setListener in the aforementioned object interface function, and taking advantage of the characteristics of std::function, the AOSP base class is designed as CarPMListenerWrapper. Based on the second parameter CarPMWrapper::setListener in the aforementioned object interface function, and taking advantage of the characteristics of String16, the AOSP parameter metatype is designed as constchar*.

[0175] The implementation code for the first program (NDK level) is as follows.

[0176]

[0177] The aforementioned code represents the following main tasks performed at the NDK level: (1) The NDK level constructs a subclass CarPMListenerWrapperImpl that inherits from the base class CarPMListenerWrapper, and uses an instance cb of the NDK parameter type to implement the EventListenerWrapper::call method of the base class, thus implementing the cloning function of the base class and the construction function of CarPMListenerWrapperImpl. (2) The NDK first program creates an instance cbWrapper of CarPMListenerWrapperImpl. (3) The NDK level calls the object interface function CarPMWrapper::setListener with cbWrapper as the parameter.

[0178] The implementation of the AOSP layer object interface function is shown in the following code.

[0179]

[0180] The aforementioned code represents the following main tasks performed at the AOSP level: (1) After receiving the parameter interface object, the object interface function CarPMWrapper::setListener clones it and then uses the smart pointer std::shared_ptr <carpmlistenerwrapper>(2) CarPMWrapper::setListener constructs aosp parameter type object cb with smart pointer object to complete the forwarding of callback function, and executes the rewritten function listener. call(s1, s2) implemented in the inheritance class. (3) Object interface function CarPMWrapper::setListener repackages the package name with the constructor of String16 to form an Aosp parameter meta type.

[0181] Figure 3 is a structural schematic diagram of the object processing apparatus provided by the embodiments of the present disclosure. As shown in Figure 3 The object processing apparatus 300 provided by the embodiments of the present disclosure includes a need-to-pass object type determination unit 301, an object creation unit 302, a function calling unit 303, and a callback unit 304304.

[0182] The need-to-pass object type determination unit 301 is configured to determine the object type of a need-to-pass object in response to obtaining the need-to-pass object, the need-to-pass object being an object whose ownership needs to be passed from a first program to a second program.

[0183] The object creation unit 302 is configured to, in a case where the need-to-pass object is a complex object, instantiate an associated inheritance class associated with the complex object in the first program to obtain an inheritance class object, and pass the complex object to the inheritance class object, wherein the associated inheritance class is derived based on a base class in the second program, the base class including a clone function declared as a pure virtual function, and the inheritance class including a rewritten clone implementation function of the clone function, the rewritten clone implementation function being configured to clone the inheritance class object.

[0184] The function calling unit 303 is configured to call a complex object interface function provided by the second program with the inheritance class object as a passing parameter.

[0185] The callback unit 304 is configured to, after receiving the inheritance class object through the complex object interface function, cause the second program to call the rewritten clone implementation function, and obtain the ownership of the inheritance class object based on the rewritten clone implementation function.

[0186] In some embodiments, the callback unit 304 causes the second program to call the rewritten clone implementation function to clone the inheritance class object, to obtain a cloned object of the inheritance class object; and based on the cloned object, creates an inheritance class object owned by the second program, to obtain the ownership of the inheritance class object.

[0187] In some embodiments, the callback unit 304 enables the second program to find the corresponding virtual function table through the virtual table pointer of the inherited class object, and to determine the overridden clone implementation function based on the virtual function table; wherein, the virtual function table is used to store the address of the overridden clone implementation function; and the inherited class object is cloned based on the overridden clone implementation function.

[0188] In some embodiments, the callback unit 304 causes the second program to use a smart pointer to take over the cloned object and create its own inherited class object based on the smart pointer, so as to obtain ownership of the inherited class object.

[0189] In some embodiments, the base class also includes a function declared as a pure virtual function, and the inherited class includes an overridden function that implements the function. The overridden function is used to enable the first program to listen to events occurring in the second program. After acquiring ownership of the complex object, the callback unit 304 causes the second program to call back the overridden function and pass the event to be listened to as a parameter so that the event to be listened to can be listened to by the first program.

[0190] In some embodiments, the base class further includes a virtual destructor for destructing the inherited class object and declared as a pure virtual function; after the second program executes each of the rewritten implementation functions within the rewritten clone implementation function, the callback unit 304 executes the virtual destructor to release the memory space of the polymorphic inherited class object; wherein, the virtual destructor is used to clear and release the memory space allocated to the inherited class object.

[0191] In some embodiments, the first program further includes a container class, which includes a container pointer and a container length. When the type of the object to be passed is a simple container class object, the function call unit 303 instantiates the container class of the first program to obtain a container class object, passes the original pointer to the container pointer of the container class object, and passes the object length to the container length; it then calls the container object interface function provided by the second program, using the container class object as a parameter; in response to receiving the container class object through the container object interface function, the second program packages the container based on the container pointer and container length to form a new container class object with ownership.

[0192] In some embodiments, when the type of the object to be passed is a simple struct object, the function calling unit 303 uses the simple struct object as the passing parameter and calls the struct object interface function provided by the second program; in response to receiving the simple struct object through the struct object interface function, the second program acquires ownership of the simple struct object.

[0193] This disclosure also provides a computing device for implementing the aforementioned method. Figure 4 This is a schematic diagram of the structure of a computing device provided in an embodiment of this disclosure. See below for details. Figure 4 It shows a schematic diagram of a structure suitable for implementing the computing device 400 in the embodiments of this disclosure. Figure 4 The computing device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments disclosed herein.

[0194] like Figure 4 As shown, the computing device 400 may include a processing unit (e.g., a central processing unit, a graphics processing unit, etc.) 401, which can perform various appropriate actions and processes according to a program stored in a read-only memory ROM 402 or a program loaded from a storage device 408 into a random access memory RAM 403. The RAM 403 also stores various programs and data required for the operation of the computing device 400. The processing unit 401, ROM 402, and RAM 403 are interconnected via a bus 404. An input / output (I / O) interface 405 is also connected to the bus 404.

[0195] Typically, the following devices can be connected to I / O interface 405: input devices 405 including, for example, touchscreens, touchpads, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 407 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 408 including, for example, magnetic tapes, hard disks, etc.; and communication devices 409. Communication device 409 allows computing device 400 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 4 A computing device 400 with various devices is shown, but it should be understood that it is not required to implement or have all of the devices shown. More or fewer devices may be implemented or have alternatively.

[0196] In particular, according to embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this disclosure include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication device 409, or installed from storage device 408, or installed from ROM 402. When the computer program is executed by processing device 401, it performs the functions defined in the methods of embodiments of this disclosure.

[0197] It should be noted that the computer-readable medium described in this disclosure can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this disclosure, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in connection with an instruction execution system, apparatus, or device. In this disclosure, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (radio frequency), etc., or any suitable combination thereof.

[0198] In some implementations, clients and servers can communicate using any currently known or future-developed network protocol such as HTTP (Hypertext Transfer Protocol) and can interconnect with digital data communication (e.g., communication networks) of any form or medium. Examples of communication networks include local area networks ("LANs"), wide area networks ("WANs"), the Internet (e.g., the Internet of Things), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks), as well as any currently known or future-developed networks.

[0199] The aforementioned computer-readable medium may be included in the aforementioned computing device; or it may exist independently and not assembled into the computing device.

[0200] The aforementioned computer-readable medium carries one or more programs. When the one or more programs are executed by the computing device, the computing device: in response to obtaining an object to be transferred, determines the object type of the object to be transferred, wherein the object to be transferred is an object whose ownership needs to be transferred from a first program to a second program; if the object to be transferred is a complex object, instantiates an associated inheritance class in the first program associated with the complex object to obtain an inheritance class object, and passes the complex object to the inheritance class object; wherein the associated inheritance class is derived from a base class in the second program, the base class includes a clone function declared as a pure virtual function, the inheritance class includes an overridden clone implementation function of the clone function, the overridden clone implementation function being used to clone the inheritance class object; using the inheritance class object as a pass parameter, calls the complex object interface function provided by the second program; after receiving the inheritance class object through the complex object interface function, causes the second program to call back the overridden clone implementation function, and obtains ownership of the inheritance class object based on the overridden clone implementation function.

[0201] Computer program code for performing the operations of this disclosure can be written in one or more programming languages ​​or a combination thereof, including but not limited to object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as "C" or similar programming languages. The program code can be executed entirely on the tester's computer, partially on the tester's computer, as a standalone software package, partially on the tester's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the tester's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0202] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0203] The units described in the embodiments of this disclosure can be implemented in software or hardware. The names of the units are not, in some cases, intended to limit the specific unit.

[0204] The functions described above in this document can be performed, at least in part, by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: Field Programmable Gate Arrays (FPGAs), Application-Specific Integrated Circuits (ASICs), Application Standard Products (ASSPs), System-on-Chip (SoCs), Complex Programmable Logic Devices (CPLDs), and so on.

[0205] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include, based on electrical connections of one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0206] This disclosure also provides a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it can implement the methods of any of the above method embodiments. The execution method and beneficial effects are similar, and will not be described again here.

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

[0208] The above are merely specific embodiments of this disclosure, enabling those skilled in the art to understand or implement this disclosure. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this disclosure. Therefore, this disclosure is not to be limited to the embodiments described herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.< / carpmlistenerwrapper> < / int> < / objectinterface> < / objectinterface> < / int>

Claims

1. A method for processing objects, characterized in that, include: In response to obtaining the object to be transferred, the object type of the object to be transferred is determined, wherein the object to be transferred is an object whose ownership needs to be transferred from the first program to the second program; In the case where the object to be passed is a complex object, the associated inheritance class in the first program that is associated with the complex object is instantiated to obtain an inheritance class object, and the complex object is passed to the inheritance class object; wherein, the associated inheritance class is derived from the base class in the second program, the base class includes a clone function declared as a pure virtual function, and the inheritance class includes an overridden clone implementation function of the clone function, the overridden clone implementation function being used to clone the inheritance class object; The inherited class object is passed as a parameter to call the complex object interface function provided by the second program. After receiving the inherited class object through the complex object interface function, the second program calls back the overridden clone implementation function and obtains ownership of the inherited class object based on the overridden clone implementation function.

2. The method according to claim 1, characterized in that, The second program calls back the overridden clone implementation function, and obtains ownership of the inherited class object based on the overridden clone implementation function, including: The second program calls back the overridden clone implementation function to clone the inherited class object, thereby obtaining a cloned object of the inherited class object; Based on the cloned object, create a second program's own inherited class object to obtain ownership of the inherited class object.

3. The method according to claim 2, characterized in that, The second program calls back the overridden cloning implementation function to clone the inherited class object, obtaining a cloned object of the inherited class object, including: The second program finds the corresponding virtual function table through the virtual table pointer of the inherited class object, and determines the overridden clone implementation function based on the virtual function table; wherein, the virtual function table is used to store the address of the overridden clone implementation function; The overridden clone function is used to clone the inherited class object.

4. The method according to claim 2, characterized in that, The step of creating a custom inherited class object of the second program based on the cloned object includes: A smart pointer is used to inherit the cloned object, and a second program creates its own inherited class object based on the smart pointer to obtain ownership of the inherited class object.

5. The method according to any one of claims 1-4, characterized in that, The base class also includes a function declared as a pure virtual function, and the inherited class includes an overridden function that implements the function. The overridden function is used to enable the first program to listen for events that occur in the second program. After acquiring ownership of the complex object, the method further includes: the second program calling back the rewrite function implementation function and passing the event to be listened to as a parameter, so that the event to be listened to can be listened to by the first program.

6. The method according to any one of claims 1-4, characterized in that, The base class also includes a virtual destructor declared as a pure virtual function for destructing the inherited class object; the method further includes: After the second program executes each of the rewritten implementation functions, including the rewritten clone implementation function, the virtual destructor is executed to release the memory space of the polymorphic inherited class object; wherein, the virtual destructor is used to clear and release the memory space allocated to the inherited class object.

7. The method according to any one of claims 1-4, characterized in that, The first program also includes a container class, which includes a container pointer and a container length; the method further includes: When the type of the object to be passed is a simple container class object, the container class of the first program is instantiated to obtain a container class object, and the original pointer is passed to the container pointer of the container class object, and the object length is passed to the container length; The container class object is passed as a parameter to call the container object interface function provided by the second program. In response to receiving the container class object through the container object interface function, the second program packages a new container class object with ownership based on the container pointer and the container length.

8. The method according to any one of claims 1-4, characterized in that, The method further includes: When the type of the object to be passed is a simple struct object, the simple struct object is used as the passing parameter, and the struct object interface function provided by the second program is called. Upon receiving the simple struct object through the struct object interface function, the second program acquires ownership of the simple struct object.

9. An object processing apparatus, characterized in that, include: The object type determination unit is used to determine the object type of the object to be transmitted in response to obtaining the object to be transmitted, wherein the object to be transmitted is an object whose ownership needs to be transferred from the first program to the second program. An object creation unit is used to instantiate the associated inheritance class in the first program that is associated with the complex object when the object to be passed is a complex object, to obtain an inheritance class object, and to pass the complex object to the inheritance class object. The associated inheritance class is derived from a base class in the second program. The base class includes a clone function declared as a pure virtual function. The inheritance class includes an overridden clone implementation function of the clone function. The overridden clone implementation function is used to clone the inheritance class object. The function call unit is used to call the complex object interface function provided by the second program by passing the inherited class object as a parameter. The callback unit is used to cause the second program to call back the overridden clone implementation function after receiving the inherited class object through the complex object interface function, and to obtain ownership of the inherited class object based on the overridden clone implementation function.

10. A computing device, characterized in that, Includes a processor and a memory, the memory being used to store computer programs; When the computer program is loaded by the processor, it causes the processor to execute the processing method of the object as described in any one of claims 1-8.

11. A computer-readable storage medium, characterized in that, The storage medium stores a computer program that, when executed by a processor, causes the processor to implement the object processing method as described in any one of claims 1-8.