CN111880804A

CN111880804A - Application program code processing method and device

Info

Publication number: CN111880804A
Application number: CN202010668760.5A
Authority: CN
Inventors: 谢祖庆
Original assignee: Tencent Technology Shenzhen Co Ltd
Current assignee: Tencent Technology Shenzhen Co Ltd
Priority date: 2020-07-13
Filing date: 2020-07-13
Publication date: 2020-11-03

Abstract

The invention provides a processing method and a processing device of an application program code, electronic equipment and a storage medium; the method comprises the following steps: acquiring a hot reloading code file corresponding to an application program, wherein the hot reloading code file is generated based on the modified source code of the application program; analyzing the hot reloading code file, and generating an executable code based on an analysis result; establishing an incidence relation between the executable code and the source code of the application program in a running state; based on the incidence relation, calling the executable code to update the interface content corresponding to the application program; by the method and the device, the development efficiency of the application program can be improved.

Description

Application program code processing method and device

Technical Field

The present invention relates to the field of computer technologies, and in particular, to a method and an apparatus for processing an application program code, an electronic device, and a storage medium.

Background

With the development of the internet, various applications are more and more, in order to be compatible with more functions and services, the engineering of the applications is larger and larger, and the time consumption of compiling once is longer and longer. When only a small amount of code is modified in the development process, the development efficiency is seriously affected if the waiting time is long. Specifically, factors that affect application debugging latency include compilation time of engineering code, and viewing of the operational effects of the application: under the condition of modifying a small amount of codes, the compiling time of the engineering codes of the whole application program is quite long, in order to check the code modification effect, the application program needs to return to the corresponding scene step by step according to the original path for effect checking after being started, the step is complex to realize, especially, a plurality of complex scenes need to be completed by the cooperation of a plurality of application programs, and the development efficiency is greatly influenced.

Disclosure of Invention

The embodiment of the invention provides a method and a device for processing an application program code, an electronic device and a storage medium, which can improve the development efficiency of an application program.

The technical scheme of the embodiment of the invention is realized as follows:

the embodiment of the invention provides a method for processing an application program code, which comprises the following steps:

acquiring a hot reloading code file corresponding to an application program, wherein the hot reloading code file is generated based on the modified source code of the application program;

analyzing the hot reloading code file, and generating an executable code based on an analysis result;

establishing an incidence relation between the executable code and the source code of the application program in a running state;

and calling the executable code based on the incidence relation so as to update the interface content corresponding to the application program.

presenting source code of an application program in a code editing interface;

in response to a modification operation for source code of an application program, updating the presented source code of the application program based on content corresponding to the modification operation;

generating a hot reloading code file corresponding to the application program in response to the determination operation for the updated source code;

sending the hot reloading code file to the application program in a running state;

and the hot reloading code file is used for updating the interface content corresponding to the application program based on the hot reloading code file in the running state of the application program.

An embodiment of the present invention further provides a device for processing an application program code, including:

the system comprises an acquisition module, a storage module and a processing module, wherein the acquisition module is used for acquiring a hot reloading code file corresponding to an application program, and the hot reloading code file is generated based on a modified source code of the application program;

the analysis module is used for analyzing the hot reloaded code file and generating an executable code based on an analysis result;

the establishing module is used for establishing an incidence relation between the executable code and the source code of the application program in the running state;

and the calling module is used for calling the executable code based on the incidence relation so as to update the interface content corresponding to the application program.

In the above scheme, the establishing module is further configured to determine a class included in the executable code;

registering a class contained in the executable code to a class manager, wherein the class manager is used for calling the executable code based on the class manager when the application program runs;

and establishing an association relation between the executable code and the source code of the application program in a running state based on a class manager registered with a class contained by the executable code.

In the above scheme, the establishing module is further configured to obtain class inheritance relationships among classes included in the executable code;

and registering various types contained in the executable code to the class manager according to the registration sequence of a parent class before a child class and based on the acquired class inheritance relationship.

In the above scheme, the establishing module is further configured to register a parent class included in the executable code to the class manager;

acquiring the offset and the size of the member variable of the parent class;

determining the offset and the size of the member variable of the corresponding subclass based on the offset and the size of the member variable of the parent class;

registering the child class to the class manager based on the determined offset and size of the member variables of the child class.

In the above scheme, the apparatus further comprises:

the comparison module is used for comparing the class contained in the executable code with the class in the class manager to obtain a comparison result;

when the comparison result represents that the class manager has the same class as the class contained in the executable code, taking the same class as a target class;

correspondingly, the establishing module is further configured to obtain a code field of the member variable corresponding to the target class in the executable code;

updating the code field of the member variable of the target class in the class manager according to the acquired code field; and are

And replacing the member method of the target class in the class manager with the member method of the target class contained in the executable code.

In the above solution, the establishing module is further configured to add, when the class manager does not have a member method of the target class, the member method of the target class included in the executable code to the class manager;

when the class manager has the member method of the target class, updating the pointer of the member method of the target class in the class manager based on the pointer of the member method of the target class contained in the executable code.

In the above scheme, the establishing module is further configured to obtain a target member method, which is different from the member method of the target class included in the executable code, in the member methods of the target class of the class manager;

when the target member method is a heavy-load method, updating the pointer of the target member method to the pointer of the member method of the corresponding parent class;

when the target member method is not a heavy load method, keeping the target member method unchanged.

In the above scheme, the establishing module is further configured to redirect the executable code, for a reference of a class included in the executable code, to a reference of the class registered to the class manager, so as to establish an association relationship between the executable code and a source code of the application program in a running state.

In the foregoing solution, the calling module is further configured to call the class registered in the class manager when the application program is in a running state, so as to call the executable code.

In the above scheme, the apparatus further comprises:

the trigger module is used for monitoring the state change of the main thread of the application program;

and when the main thread of the application program is determined to be in the starting state, triggering the operation of establishing the association relation.

In the above scheme, the triggering module is further configured to monitor a release state change of an object corresponding to the modified source code;

and when determining that the object corresponding to the modified source code is in a released state, triggering the operation of establishing the association relationship.

In the above solution, the triggering module is further configured to identify a modified source code of the application program;

triggering an operation of establishing the association relationship when it is determined that the modified source code does not involve modification for a member variable.

the presentation module is used for presenting the source code of the application program in the code editing interface;

the updating module is used for responding to modification operation aiming at the source code of the application program and updating the presented source code of the application program based on the content corresponding to the modification operation;

the generating module is used for responding to the determination operation aiming at the updated source code and generating a hot reloading code file corresponding to the application program;

the sending module is used for sending the hot reloading code file to the application program in the running state;

An embodiment of the present invention further provides an electronic device, including:

a memory for storing executable instructions;

and the processor is used for realizing the processing method of the application program code provided by the embodiment of the invention when the executable instruction stored in the memory is executed.

The embodiment of the invention also provides a computer-readable storage medium, which stores executable instructions, and when the executable instructions are executed by a processor, the method for processing the application program codes provided by the embodiment of the invention is realized.

The embodiment of the invention has the following beneficial effects:

analyzing a hot reloading code file of the application program, generating an executable code based on an analysis result, then establishing an incidence relation between the executable code and a source code of the application program in an operating state, and calling the executable code in the operating process of the application program based on the incidence relation so as to update an interface corresponding to the application program; the hot reloading code file is generated based on the modified source code, the application program can call the executable code corresponding to the hot reloading code file through the established incidence relation in the running process so as to immediately present the interface content corresponding to the modified source code, so that the whole engineering code of the application program does not need to be compiled again, the application program does not need to be restarted to check the effect of the modified code, the debugging waiting time is saved, and the development efficiency of the application program is greatly improved.

Drawings

Fig. 1 is an implementation scenario diagram of a processing method of application program code according to an embodiment of the present invention;

fig. 2 is a schematic structural diagram of an electronic device provided in an embodiment of the present invention;

FIG. 3 is a flowchart illustrating a method for processing application code according to an embodiment of the present invention;

FIG. 4 is a diagram illustrating an association relationship between executable code and source code of an application provided by an embodiment of the present invention;

FIG. 5A is a diagram illustrating registration of member variables provided by an embodiment of the invention;

fig. 5B is a schematic diagram of registration of a member method according to an embodiment of the present invention;

FIG. 6 is a schematic diagram of code redirection provided by an embodiment of the present invention;

FIG. 7 is a flowchart illustrating a method for processing application code according to an embodiment of the present invention;

8A-B are diagrams of updating application interface content provided by embodiments of the present invention;

FIG. 9A is an architecture diagram of a LLVM provided by an embodiment of the invention;

FIG. 9B is a workflow diagram of LLVM-JIT provided by an embodiment of the invention;

FIG. 10 is a system architecture diagram of a method for processing application code provided by an embodiment of the present invention;

FIG. 11 is a flowchart illustrating a method for processing application code according to an embodiment of the present invention;

FIG. 12 is a diagram of an ObjC object structure provided by the embodiment of the present invention;

FIGS. 13A-B are schematic diagrams of the registration of classes provided in the related art;

FIG. 14 is a diagram illustrating a C/C + + function hot reload according to an embodiment of the present invention;

FIG. 15 is a schematic structural diagram of an apparatus for processing application code according to an embodiment of the present invention;

fig. 16 is a schematic structural diagram of a processing apparatus for application program codes according to an embodiment of the present invention.

Detailed Description

In order to make the objects, technical solutions and advantages of the present invention clearer, the present invention will be further described in detail with reference to the accompanying drawings, the described embodiments should not be construed as limiting the present invention, and all other embodiments obtained by a person of ordinary skill in the art without creative efforts shall fall within the protection scope of the present invention.

In the following description, reference is made to "some embodiments" which describe a subset of all possible embodiments, but it is understood that "some embodiments" may be the same subset or different subsets of all possible embodiments, and may be combined with each other without conflict.

In the following description, references to the terms "first \ second \ third" are only to distinguish similar objects and do not denote a particular order, but rather the terms "first \ second \ third" are used to interchange specific orders or sequences, where appropriate, to enable embodiments of the invention described herein to be practiced in other than the order shown or described herein.

Unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs. The terminology used herein is for the purpose of describing embodiments of the invention only and is not intended to be limiting of the invention.

Before further detailed description of the embodiments of the present invention, terms and expressions mentioned in the embodiments of the present invention are explained, and the terms and expressions mentioned in the embodiments of the present invention are applied to the following explanations.

1) In response to the condition or state on which the performed operation depends, one or more of the performed operations may be in real-time or may have a set delay when the dependent condition or state is satisfied; there is no restriction on the order of execution of the operations performed unless otherwise specified.

2) LLVM: a set of open-source modular and reusable compilers and toolchain technologies, employing the Apache License v2.0 open-source protocol.

3) LLVM-JIT: a just-in-time compiler module under the LLVM project can dynamically generate machine codes in the memory.

4) Clang: is a LLVM-based C/C + +/ObjC compiler front-end.

5) Xcode: the Integrated Development Environment (IDE) is used for developing application programs of platforms such as iPhone, iPad, iWatch and macOS, and is internally provided with a Clang compiler. Xcode is an integrated development tool (IDE) running on the operating system Mac OS X, developed by Apple Inc. The Xcode is the fastest way to develop macOS and iOS applications, has a uniform user interface design, and completes coding, testing and debugging in a simple window.

6) ObjC: Objective-C is an object-oriented programming language for expanding C, and is mainly used for developing application programs of apple Inc.

7) ObjC-Runtime: the ObjC language runtime, which is also a manager, is responsible for managing the relevant information of all ObjC classes in the process, and the ObjC classes need to be registered with the ObjC language runtime before being used.

8) Code hot-reload (hot-load): mainly means that under the condition that the process of the app is not restarted, machine codes in the process are dynamically modified, so that the behavior of the app is changed, and the method is similar to patching.

9) A bytecode: LLVM defined intermediate language format (IR).

10) The field pointer is a pointer pointing to a deleted object or a pointer not applying for accessing the restricted memory area.

In the related art, the method is usually implemented by using an Xcode interface debugging tool, injectioniii implements the injection of modified source code into an iOS simulator under a Mac platform by using a remote code injection mode, and the modified source code is implemented by using a Mac-inject third-party library, but the scheme is limited by strict security limitations of an iOS system and cannot be implemented on an iOS real machine. Meanwhile, the injection time of the modified source code is random, so that the application program often conflicts during running, and the member method, the class method and the like cannot be deleted.

Based on this, embodiments of the present invention provide a method and an apparatus for processing an application program code, an electronic device, and a storage medium, so as to at least solve the above existing problems.

Next, based on the above explanations of terms and terms related to the embodiments of the present invention, an implementation scenario of the processing method of the application code provided by the embodiments of the present invention is first described, referring to fig. 1, fig. 1 is a schematic diagram of an implementation scenario of the processing method of the application code provided by the embodiments of the present invention, in order to support an exemplary application, a terminal (including a terminal 200-1 and a terminal 200-2) is implemented, where the terminal 200-1 is used for a developer to modify a source code, the terminal 200-2 is used for running an application program to be developed, the terminal 200-1 and the terminal 200-2 are connected to the server 100 through a network 300, and the network 300 may be a wide area network or a local area network, or a combination of the two, and data transmission is implemented using a wireless or wired link.

The terminal 200-1 is used for presenting the source code of the application program in a code editing interface; in response to a modification operation on the source code of the application program, updating the source code of the presented application program based on the content corresponding to the modification operation; generating a hot reloading code file corresponding to the application program in response to the determination operation for the updated source code; sending the hot reloading code file to the application program in the running state;

the server 100 is used for receiving the hot reloading code file of the terminal 200-1 and forwarding the hot reloading code file to the terminal 200-2;

the terminal 200-2) is used for receiving the hot reloading code file corresponding to the application program; analyzing the hot reloading code file, and generating an executable code based on an analysis result; establishing an incidence relation between the executable code and the source code of the application program in the running state; and calling the executable code based on the association relation so as to update the interface content corresponding to the application program.

In practical applications, the server 100 may be a server configured independently to support various services, or may be a server cluster; the terminal (e.g., terminal 200-1) may be any type of user terminal such as a smartphone, tablet, laptop, etc., and may also be a wearable computing device, a Personal Digital Assistant (PDA), a desktop computer, a cellular phone, a media player, a navigation device, a game console, a television, or a combination of any two or more of these or other data processing devices.

The following describes in detail a hardware structure of an electronic device including, but not limited to, a server or a terminal according to the method for processing an application program code provided in the embodiment of the present invention. Referring to fig. 2, fig. 2 is a schematic structural diagram of an electronic device according to an embodiment of the present invention, and the electronic device 200 shown in fig. 2 includes: at least one processor 210, memory 250, at least one network interface 220, and a user interface 230. The various components in electronic device 200 are coupled together by a bus system 240. It is understood that the bus system 240 is used to enable communications among the components. The bus system 240 includes a power bus, a control bus, and a status signal bus in addition to a data bus. For clarity of illustration, however, the various buses are labeled as bus system 240 in fig. 2.

The Processor 210 may be an integrated circuit chip having Signal processing capabilities, such as a general purpose Processor, a Digital Signal Processor (DSP), or other programmable logic device, discrete gate or transistor logic device, discrete hardware components, or the like, wherein the general purpose Processor may be a microprocessor or any conventional Processor, or the like.

The user interface 230 includes one or more output devices 231, including one or more speakers and/or one or more visual display screens, that enable the presentation of media content. The user interface 230 also includes one or more input devices 232, including user interface components that facilitate user input, such as a keyboard, mouse, microphone, touch screen display, camera, other input buttons and controls.

The memory 250 may be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid state memory, hard disk drives, optical disk drives, and the like. Memory 250 optionally includes one or more storage devices physically located remotely from processor 210.

The memory 250 includes volatile memory or nonvolatile memory, and may include both volatile and nonvolatile memory. The nonvolatile Memory may be a Read Only Memory (ROM), and the volatile Memory may be a Random Access Memory (RAM). The memory 250 described in embodiments of the invention is intended to comprise any suitable type of memory.

In some embodiments, memory 250 is capable of storing data, examples of which include programs, modules, and data structures, or a subset or superset thereof, to support various operations, as exemplified below.

An operating system 251 including system programs for processing various basic system services and performing hardware-related tasks, such as a framework layer, a core library layer, a driver layer, etc., for implementing various basic services and processing hardware-based tasks;

a network communication module 252 for communicating to other computing devices via one or more (wired or wireless) network interfaces 220, exemplary network interfaces 220 including: bluetooth, wireless compatibility authentication (WiFi), and Universal Serial Bus (USB), etc.;

a presentation module 253 to enable presentation of information (e.g., a user interface for operating peripherals and displaying content and information) via one or more output devices 231 (e.g., a display screen, speakers, etc.) associated with the user interface 230;

an input processing module 254 for detecting one or more user inputs or interactions from one of the one or more input devices 232 and translating the detected inputs or interactions.

In some embodiments, the processing device of the application program code provided by the embodiments of the present invention may be implemented in software, and fig. 2 shows the processing device 255 of the application program code stored in the memory 250, which may be software in the form of programs and plug-ins, etc., and includes the following software modules: an obtaining module 2551, a parsing module 2552, a building module 2553 and a calling module 2554, which are logical and thus can be arbitrarily combined or further split according to the implemented functions, which will be described below.

In other embodiments, the processing Device of the Application program code provided by the embodiments of the present invention may be implemented by a combination of hardware and software, and by way of example, the processing Device of the Application program code provided by the embodiments of the present invention may be a processor in the form of a hardware decoding processor, which is programmed to execute the processing method of the Application program code provided by the embodiments of the present invention, for example, the processor in the form of the hardware decoding processor may be implemented by one or more Application Specific Integrated Circuits (ASICs), DSPs, Programmable Logic Devices (PLDs), Complex Programmable Logic Devices (CPLDs), Field Programmable Gate Arrays (FPGAs), or other electronic components.

Before explaining the processing method of the application program code provided by the present invention, first, the selected scheme is tried before the method provided by the present invention is obtained. First, an improvement on injectioniii is firstly attempted, and the injection task of the modified source code is completed by using a way that dlopen loads a dynamic library, but all dynamic libraries can only be loaded from a bundle directory (read-only) of an application, the dynamic libraries are prohibited from being loaded from a sandbox directory (read-write) of the application, and dlopen does not support loading from a memory, so that the generated dynamic libraries cannot be loaded successfully even if being transmitted to an application program. Secondly, the method is realized through virtual machines, including a JSPatch virtual machine and an OCS virtual machine, but both cannot complete automatic code conversion, and syntax is not completely equivalent, so that the development efficiency of the application program cannot be improved.

Therefore, the premise that the code can be dynamically executed when the application program runs is to dynamically load the code into the application program process, and two ways for achieving the purpose are a virtual machine-based way and a traditional way for loading a dynamic library, but the two ways are not feasible. In fact, the code is not only compiled into a binary machine code in advance and then loaded into the application program memory, but also can be dynamically generated in the application program memory and then executed, which is called just-in-time (JIT). In the Xcode integrated development environment adopted in the development of the iOS application, the LLVM/Clang toolset is used for compilation, and it is found through research that the LLVM toolset includes a JIT engine.

Referring to fig. 3, fig. 3 is a flowchart illustrating a processing method of application program codes according to an embodiment of the present invention; in some embodiments, the processing method of the application code may be implemented by a server or a terminal alone, or implemented by a server and a terminal in a cooperation manner, taking the terminal as an example, the processing method of the application code provided in the embodiments of the present invention includes:

step 301: and the terminal acquires a hot reloading code file corresponding to the application program.

Wherein the hot reload code file is generated based on the source code of the modified application program.

Here, the terminal is provided with an application program, such as a video playing client, an instant messaging client, and the like. During the development process of the application program, a developer needs to run the developed application program on a terminal to view the effect. In practical application, a developer edits and modifies a source code of an application program to develop functions, interface display and the like of the application program, and specifically, the developer modifies and edits the source code of the application program through a code editing tool to obtain a modified source code, and then compiles the modified source code to obtain a hot reloading code file for the application program.

The terminal acquires a hot reloading code file corresponding to the application program, and specifically, the terminal can receive the hot reloading code file through a USB interface connected to a developer code editing terminal.

Step 302: and analyzing the hot reloaded code file, and generating an executable code based on an analysis result.

After the terminal acquires the hot reloading code file corresponding to the application program, the hot reloading code file is analyzed to obtain an analysis result, and then an executable code capable of being executed by the application program is generated based on the analysis result. Specifically, when the application program is an iOS client, the hot re-loadable code file may be in a bytecode format, and a Mach-O file for the iOS system to execute may be generated by parsing.

Step 303: and establishing an association relation between the executable code and the source code of the application program in the running state.

Here, in the embodiment of the present invention, when the executable code is called to update the interface effect of the application program, the application program may be in a running state, so as to ensure that the effect after the source code is modified can be viewed in time. In order to realize the calling of the executable code, after the terminal analyzes the hot reloading code file and generates the executable code, the association relation between the executable code and the source code of the application program in the running state is established.

In some embodiments, the terminal may establish the association relationship by: determining a class contained in the executable code; registering a class contained in the executable code to a class manager, wherein the class manager is used for calling the executable code based on the class manager when an application program runs; based on the class manager registered with the class included in the executable code, an association relationship between the executable code and the source code of the application program in the running state is established.

In practical application, because the executable code cannot be directly communicated with the built-in source code of the application program, that is, the association relationship cannot be directly established, at this time, the executable code cannot be seamlessly fused with the source code of the application program. In order to implement communication between the executable code and the source code of the application program, in the embodiment of the present invention, a class included in the executable code needs to be registered to a class manager, so that the application program can call the executable code based on the class manager when running. Thereby establishing an association between the executable code and the source code of the application program based on the class manager registered with the class included in the executable code. Referring to fig. 4, fig. 4 is a schematic diagram of an association relationship between executable code and source code of an application program provided by an embodiment of the present invention; here, the executable code (i.e., ObjC code) is located in the JIT engine, which, as shown in fig. 4(1), may be aware of the built-in source code of the application, but the built-in source code of the application may not be aware of the executable code in the JIT engine; then, the class included in the executable code is registered in the class manager (i.e. ObjC-Runtime), and the communication between the source code of the application and the executable code is realized through the class manager, as shown in fig. 4 (2).

The registration of classes contained in executable code to the class manager is described in detail below. In some embodiments, the terminal may register the class contained by the executable code with the class manager by: acquiring class inheritance relationships among classes contained in the executable codes; and registering various types contained in the executable code to the class manager according to the registration sequence of the parent class, the child class and the parent class based on the acquired class inheritance relationship.

In practical application, when a terminal registers classes contained in an executable code to a class manager, class inheritance relationships among the classes contained in the executable code need to be acquired and analyzed; and then determining the registration sequence of each type based on the class inheritance relationship among the types, and specifically registering the types contained in the executable code to the class manager according to the registration sequence of a parent type after a child type.

Here, in the process of registering a class included in the executable code to the class manager, the class originally existing in the class manager needs to be analyzed. In some embodiments, the terminal may analyze the originally existing class in the class manager by: comparing the class contained in the executable code with the class in the class manager to obtain a comparison result; and when the comparison result represents that the same class exists in the class manager as the class contained in the executable code, taking the same class as the target class.

In practical application, in the process of registering a class included in an executable code in a class manager, an originally existing class in the class manager needs to be analyzed, specifically, the class included in the executable code is compared with the class in the class manager to obtain a comparison result, so as to determine whether a class identical to the class included in the executable code exists in the class manager. And when the comparison result obtained by comparison represents that the class manager has the same class as the class contained in the executable code, taking the same class as the target class.

Based on this, registering the target class included in the executable code to the class manager is equivalent to registering an existing class registration in the class manager, and in some embodiments, the terminal may register the target class included in the executable code to the class manager in the following manner: acquiring a code field of a member variable corresponding to a target class in the executable code; updating the code field of the member variable of the target class in the class manager according to the acquired code field; and replacing the member method of the target class in the class manager with the member method of the target class contained in the executable code.

In practical application, when an existing class is registered in the class manager, member variables and member methods of the classes need to be processed respectively. And aiming at the member variables of the target class, acquiring code fields of the member variables of the target class corresponding to the executable code, and covering the acquired code fields one by one on the corresponding code fields of the member variables of the target class in the class manager to realize the registration of the member variables of the target class. Referring to fig. 5A, fig. 5A is a schematic diagram of registration of member variables provided by the embodiment of the present invention, where code fields of unregistered member variables in an executable code corresponding to a target class are "start", "size", and "ivar _ layout", and corresponding code fields of member variables of the target class in a class manager are "ivar _ layout", "ivar _ list", and "we _ ivar _ layout", respectively, and the code fields of member variables of the target class in the executable code are used to cover corresponding code fields of member variables of the target class in the class manager one by one, so as to obtain registered member variables "start", "size", and "ivar _ layout".

In actual implementation, since it is found that before the subclass is unregistered, the related information of the parent class is not known, the offset of the member variable of the subclass after registration is incorrect, and thus the operation of the application program is affected. Based on this, in some embodiments, the terminal may register the member variables of the class into the class manager by: registering a parent class contained in the executable code to the class manager; acquiring offset and size of a member variable of a parent class; determining the offset and the size of the member variable of the corresponding subclass based on the offset and the size of the member variable of the parent class; registering the child class to the class manager based on the determined offset and size of the member variables of the child class.

For the member method of the target class, the member method of the target class in the class manager may be replaced with the member method of the target class included in the executable code, so as to register the target class included in the executable code. In some embodiments, the terminal may register the member method of the target class in the class manager by: when the class manager does not have the member method of the target class, adding the member method of the target class contained in the executable code to the class manager; and when the class manager has the member method of the target class, updating the pointer of the member method of the target class in the class manager based on the pointer of the member method of the target class contained in the executable code.

In some other embodiments, the terminal may further register the member method of the target class in the class manager by: acquiring a target member method which is different from the member method of the target class contained in the executable code in the member methods of the target class of the class manager; when the target member method is the heavy load method, updating the pointer of the target member method to the pointer of the member method of the corresponding parent class; when the target member method is not the override method, the target member method is kept unchanged.

In actual implementation, replacement of member methods of the target class can be done through the class _ replayethod API. Specifically, referring to fig. 5B, fig. 5B is a schematic registration diagram of a member method according to an embodiment of the present invention. Here, a registration scenario including member methods of four target classes (a _ class): a, when the class manager does not have the member method of the target class, adding the member method of the target class contained in the executable code to the class manager, such as method _ d; b, when the class manager has the member method of the target class, updating the pointer of the member method of the target class in the class manager based on the pointer of the member method of the target class contained in the executable code, namely covering the pointer of the member method of the target class contained in the executable code with the pointer of the member method of the target class in the class manager, such as method _ a; c, aiming at the member methods which exist in the class manager but do not exist in the executable code, when the member methods are heavy-load methods, the pointers of the member methods are updated to the pointers of the member methods of the corresponding parent classes, so that the member methods are deleted in a simulated mode, such as method _ b; and d, aiming at the member method which exists in the class manager but does not exist in the executable code, when the member method is not the reloading method, keeping the member method unchanged without processing, such as method _ c.

It should be noted that, for a class that does not exist in the class manager, that is, when registering a new class, an empty class may be generated in the class manager first, and then the empty class is converted into a mode of registering an existing class to register the new class; the attributes, protocols, classification methods, etc. of the executable code may be registered in the same manner as the above-described registration manner, and are not described herein again.

Because the code modification is performed on the running application program, attention needs to be paid to the establishment timing of the incidence relation between the executable code and the source code of the application program, namely, the timing of calling the executable code by the application program is controlled, so as to avoid causing the running problem of the application program.

In some embodiments, the terminal may determine the establishment timing of the association between the executable code and the source code of the application by: monitoring the state change of a main thread of an application program; and when the main thread of the application program is determined to be in the starting state, triggering the operation of establishing the association relation.

Here, the terminal may control to establish an association relationship between the executable code and the application source code in a state where the main thread is running. Specifically, the state change of a main thread of an application program is monitored in real time; when the main thread of the application program is monitored to be in a starting state (namely a running state), the operation of establishing the association relationship is triggered.

In some embodiments, the terminal may also determine the establishment timing of the association between the executable code and the source code of the application program by: monitoring the release state change of an object corresponding to the modified source code; and when determining that the object corresponding to the modified source code is in the released state, triggering the operation of establishing the association relation.

Here, the terminal may also wait for the release of the object corresponding to the modified source code, and then establish the association between the executable code and the application source code. In practical application, the creation and release conditions of the object may be monitored in real time through the instance object counter, specifically, the release state changes of all the objects may be monitored, or only the release state change of the object corresponding to the modified source code may be monitored, and when it is determined that the object corresponding to the modified source code is in the released state, the operation of establishing the association relationship is triggered.

In some embodiments, the terminal may further determine the establishment timing of the association between the executable code and the source code of the application program by: identifying source code of the modified application; an operation to establish an association is triggered when it is determined that the modified source code does not involve modification to the member variable.

Here, since some objects are never released during the running process of the application, it is necessary to identify the source code of the modified application and determine whether the modification of the member variable is involved. When it is determined that the modification does not involve modification of a member variable, an operation of establishing an association relationship is forcibly triggered.

In some embodiments, after registering the class included in the executable code with the class manager, the terminal may establish an association relationship based on the class manager registered with the class included in the executable code by: the executable code, the references to classes contained by the executable code, are redirected to the references to classes registered with the class manager to establish an association between the executable code and the source code of the application in a running state.

Here, since the internal part of the executable code is still a reference to the unregistered class after the class registration is completed, in order to implement the invocation of the executable code, the reference of the executable code to the class included in the executable code needs to be redirected to the reference to the class registered to the class manager. Referring to fig. 6, fig. 6 is a schematic diagram of code redirection provided by an embodiment of the present invention; here, __ obj _ class, __ obj _ c _ super, __ obj _ class, or ZQTestClass in the executable code conforming to the Mach-O format in the JIT engine, actually the previous steps have registered the structure of these unregistered classes in the class manager (i.e., ObjC-Runtime), and the classes managed by ObjC-Runtime are not usable at this time, so that the classes referred to by these several related sections all point to the ZQTestClass registered in ObjC-Runtime.

Step 304: and calling the executable code based on the association relation so as to update the interface content corresponding to the application program.

In some embodiments, after establishing the association between the executable code and the application source code is achieved, the terminal may call the executable code by: and when the application program is in a running state, calling the executable code by calling the class registered to the class manager.

After the mutual communication between the executable code in the JIT engine and the built-in code of the application program is realized and the redirection of class reference in the ObjC-Runtime is completed, the application program calls the class registered to the class manager in the running process to realize the calling of the executable code, namely, the process of injecting the modified source code into the application program is realized, and at the moment, the application program updates the interface content corresponding to the application program by running the modified source code.

Continuing to describe the processing method of the application program code provided in the embodiment of the present invention, referring to fig. 7, fig. 7 is a schematic flowchart of the processing method of the application program code provided in the embodiment of the present invention; in some embodiments, the processing method of the application code may be implemented by a server or a terminal alone, or implemented by a server and a terminal in a cooperation manner, taking the terminal as an example, the processing method of the application code provided in the embodiments of the present invention includes:

step 701: and the terminal presents the source code of the application program in a code editing interface.

Step 702: and in response to the modification operation aiming at the source code of the application program, updating the source code of the presented application program based on the content corresponding to the modification operation.

Step 703: and generating a hot reloading code file corresponding to the application program in response to the determination operation for the updated source code.

Step 704: and sending the hot reloading code file to the application program in the running state.

The hot reloading code file is used for updating the interface content corresponding to the application program based on the hot reloading code file in the running state of the application program.

Referring to fig. 8A-B, fig. 8A-B are schematic diagrams of updating application interface content provided by an embodiment of the invention. Here, as shown in fig. 8A, the source code of the application program is modified, and the hot reloading code file corresponding to the application program is saved; and sending the obtained hot reloading code file to a terminal side for running the application program, so that the interface content corresponding to the application program is updated by calling the hot reloading code file in the running process of the application program, as shown in fig. 8B, the function suspension page of 'treasure box gift grabbing for the first article' is realized by modifying the source code.

By applying the embodiment of the invention, the hot reloaded code file of the application program is analyzed, the executable code is generated based on the analysis result, then the incidence relation between the executable code and the source code of the application program in the running state is established, and the executable code is called in the running process of the application program based on the incidence relation so as to update the interface corresponding to the application program; the hot reloading code file is generated based on the modified source code, the application program can call the executable code corresponding to the hot reloading code file through the established incidence relation in the running process so as to immediately present the interface content corresponding to the modified source code, so that the whole engineering code of the application program does not need to be compiled again, the application program does not need to be restarted to check the effect of the modified code, the debugging waiting time is saved, and the development efficiency of the application program is greatly improved.

An exemplary application of the embodiments of the present invention in a practical application scenario will be described below.

Before describing the processing method of the application program code provided by the present invention, first, a solution selection attempt performed before obtaining the method provided by the present invention is described. First, an improvement on injectioniii is firstly attempted, and the injection task of the modified source code is completed by using a way that dlopen loads a dynamic library, but all dynamic libraries can only be loaded from a bundle directory (read-only) of an application, the dynamic libraries are prohibited from being loaded from a sandbox directory (read-write) of the application, and dlopen does not support loading from a memory, so that the generated dynamic libraries cannot be loaded successfully even if being transmitted to an application program. Secondly, the method is realized through virtual machines, including a JSPatch virtual machine and an OCS virtual machine, but both cannot complete automatic code conversion, and syntax is not completely equivalent, so that the development efficiency of the application program cannot be improved.

Therefore, the premise that the code can be dynamically executed when the application program runs is to dynamically load the code into the application program process, and two ways for achieving the purpose are a virtual machine-based way and a traditional way for loading a dynamic library, but the two ways are not feasible. In fact, the code is not only compiled into a binary machine code in advance and then loaded into the application program memory, but also can be dynamically generated in the application program memory and then executed, which is called just-in-time (JIT). In the Xcode integrated development environment adopted in the development of the iOS application program, the LLVM/Clang tool set is used for compiling, and a JIT engine is contained in the LLVM tool set through research. Referring to fig. 9A-B, wherein fig. 9A is an architecture diagram of the LLVM provided by the embodiment of the present invention, and fig. 9B is a workflow diagram of the LLVM-JIT provided by the embodiment of the present invention; here, the front-end may be compiled using any language, and the back-end may also be compiled using any target device; in the compiler based on LLVM-JIT, the JIT front end is used for resolving, verifying and diagnosing code errors, translating the code resolved by the front end into LLVM IR (i.e. bytecode) and loading, improving the code through a series of optimization processes and analysis, sending the improved code to a code generator to generate a native machine code, and then performing operations of relocating, setting code and executing authority so as to enable an application program to call the generated machine code.

Based on this, the processing method of the application program code of the present invention is proposed, and reference is now made to fig. 10 and fig. 11, where fig. 10 is a system architecture diagram of the processing method of the application program code provided in the embodiment of the present invention, fig. 11 is a flowchart illustrating the processing method of the application program code provided in the embodiment of the present invention, and the processing method of the application program code provided in the embodiment of the present invention includes:

step 1101: and the Mac client presents the source code of the application program in the code editing interface.

Step 1102: and in response to the modification operation aiming at the source code of the application program, updating the source code of the presented application program based on the content corresponding to the modification operation.

Here, the developer makes the modification of the source code of the application program at the Mac client by the Xcode. And the Mac client responds to the modification of the source code of the application program by the developer, and presents the modified source code of the application program based on the content corresponding to the modification operation.

Step 1103: and in response to the saving operation aiming at the updated source code, compiling to generate a hot reloading code file corresponding to the application program, and sending the hot reloading code file to the IOS client.

Here, the Mac client receives a save operation for the modified source code, compiles the modified source code, and generates a hot reloaded code corresponding to the application program. Specifically, a source code to be compiled is obtained through operations such as type filtering, duplicate removal, minimum interval and the like; and then, extracting compiling parameters from a constructed log corresponding to the source code, generating a hot reloading code file, namely a bytecode, by Clang, and finally sending the hot reloading code file to the iOS client in a USB transmission mode, namely developing and modifying the application program.

Step 1104: and the iOS client receives the hot reloading code file, analyzes the hot reloading code file, and generates an executable code based on an analysis result.

After receiving the hot reloaded code file corresponding to the application program, the iOS client analyzes the hot reloaded code file to obtain an analysis result, and further generates an executable code which can be executed by the application program and conforms to the Mach-O format based on the analysis result. Here, the parsing engine may be attached to the LLVM-JIT engine, or may be another JIT engine.

Step 1105: and analyzing and acquiring class inheritance relationships among classes contained in the executable code.

Here, the application may be in a running state when it calls the executable code to update the application effect. In order to realize the calling of the executable code, after the terminal analyzes the hot reloaded code file and generates the executable code, the incidence relation between the executable code and the source code of the application program in the running state is established, namely the direct communication between the executable code in the JIT engine and the built-in source code is realized. When the executable code contains an ObjC class, we must know the object model of ObjC first before registering the ObjC class in ObjC-Runtime. ObjC is a dynamic language, method calls are determined at runtime, the implementation of the mechanism relies on an object model, and a typical ObjC object structure is shown in FIG. 12.

Since the executable code is located in the JIT engine and cannot be directly connected with the built-in source code of the application program, that is, the association relationship cannot be directly established, at this time, the class included in the executable code needs to be registered to the class manager (i.e., Objc-Runtime). In actual implementation, because the code of the running application program is modified, attention needs to be paid to the establishment timing of the association relationship between the executable code and the source code of the application program, that is, the registration timing of the executable code is controlled, so as to avoid causing the running problem of the application program. In practical application, the method can control the class of the executable code to be registered to the class manager in the running state of the main thread or after the release of the related objects is waited; for objects that are never released, registration may occur at any time if the modified code does not involve modification of the member variables.

Specifically, when classes included in the executable code are registered in the class manager, class inheritance relationships among the classes need to be obtained to determine the registration order of the classes.

Step 1106: and registering various types contained in the executable code to the class manager based on the acquired class inheritance relationship.

Here, after the class inheritance relationship is analyzed and obtained, the classes included in the executable code are registered in the class manager in the order of the parent class before and the child class after.

In practical applications, since some class in the executable code may or may not already exist in the class manager, during the registration process, the class manager is divided into a registered existing class and a registered new class. When registering an existing class, the simplest way is to delete the existing class and then register it as a new class. However, there is no method for deleting the existing class in ObjC-Runtime, and it is highly likely that the deletion of the existing class will occur to the access of the wild pointer and crash, so this scheme is not feasible, see fig. 13A, where fig. 13A is a schematic diagram of class registration provided in the related art. Another way is to update the registered classes, including member variables (ivar and waak, strong, atomic properties), instance methods (including classification methods), class methods, etc. Based on this way of updating classes, we have two alternative schemes: firstly, the ro pointer is directly assigned (updated); second, member variables and member methods are handled separately. The ro pointers are directly assigned, the scheme completes updating of member variables and member methods at one time, but the scheme proves to be infeasible in practice, various random crash occurs during operation, the cache refreshing problem of the method is also faced, the classification method is lost in the process, and the method is shown in fig. 13B, wherein fig. 13B is a registration schematic diagram of the classes provided in the related art.

Based on this, in order to avoid crash occurring when the application program runs, in the embodiment of the present invention, when the existing class is registered, the member variables and the member methods of each class need to be processed respectively.

Aiming at the member variables, the related code fields of the member variables of the corresponding target class in the executable code need to be acquired, and the acquired related code fields are used for covering the corresponding code fields of the member variables of the target class in the class manager one by one so as to realize the registration of the member variables of the target class. In actual implementation, since it is found that before the subclass is unregistered, the related information of the parent class is not known, the offset of the member variable of the subclass after registration is incorrect, and thus the operation of the application program is affected. Based on this, when registering the member variable of the subclass, the offset and the size of the member variable of the parent class need to be acquired; and determining the offset and the size of the member variable of the corresponding subclass based on the offset and the size of the member variable of the parent class, so as to realize offset correction of the member variable of the subclass.

For member methods, the replacement of member methods is done through the class _ replayethod API. Specifically, referring to fig. 5B, here, a registration scenario involving member methods of four target classes (a _ class): a, when the class manager does not have the member method of the target class, adding the member method of the target class contained in the executable code to the class manager, such as method _ d; b, when the class manager has the member method of the target class, updating the pointer of the member method of the target class in the class manager based on the pointer of the member method of the target class contained in the executable code, namely covering the pointer of the member method of the target class contained in the executable code with the pointer of the member method of the target class in the class manager, such as method _ a; c, aiming at the member methods which exist in the class manager but do not exist in the executable code, when the member methods are heavy-load methods, the pointers of the member methods are updated to the pointers of the member methods of the corresponding parent classes, so that the member methods are deleted in a simulated mode, such as method _ b; and d, aiming at the member method which exists in the class manager but does not exist in the executable code, when the member method is not the reloading method, keeping the member method unchanged without processing, such as method _ c.

Step 1107: the executable code, references to classes contained by the executable code, are redirected to references to classes registered with the class manager.

Here, since the internal part of the executable code is still a reference to the unregistered class after the class registration is completed, in order to implement the invocation of the executable code, the reference of the executable code to the class included in the executable code needs to be redirected to the reference to the class registered to the class manager. Referring to fig. 6, __ obj _ c _ classlst, __ obj _ c _ superfrefs and __ obj _ classls in the executable code conforming to the Mach-O format in the JIT engine refer to or are not registered class ZQTestClass, and actually the previous steps have registered the structure of these not registered classes in the class manager (i.e., obj c-Runtime), and the classes managed by obj c-Runtime are not usable at this time, so that the classes referred to by several relevant sections all refer to the registered class zqtclass in obj c-Runtime.

Step 1108: and when the application program is in a running state, calling the executable code by calling the class registered to the class manager so as to update the interface content corresponding to the application program.

Here, the above approach can be used for code hot-reloading of the ObjC dynamic language; referring next to fig. 14, fig. 14 is a schematic diagram of a hot reload of a C/C + + function according to an embodiment of the present invention, where, when a language required for hot reload of code is C/C + +, the first several bytes of machine instructions, such as a hook function, at the entry of an objective function (i.e., the a _ func function shown in fig. 14) may be modified to unconditionally jump to a corresponding new function (i.e., the a _ fun' function shown in fig. 14) in the JIT engine to achieve hot reload of the code.

Therefore, after the Xcode modifies the source code, developers only need to save the lower source code file, and can see the effect of the modified code in the application program after several seconds, so that the development efficiency is greatly improved.

Continuing with the description of the application code processing device 255 provided by the embodiments of the present invention, in some embodiments, the application code processing device may be implemented as a software module. Referring to fig. 15, fig. 15 is a schematic structural diagram of the processing device 255 for application program codes according to the embodiment of the present invention, where the processing device 255 for application program codes according to the embodiment of the present invention includes:

an obtaining module 2551, configured to obtain a hot reloading code file corresponding to an application program, where the hot reloading code file is generated based on a modified source code of the application program;

an analysis module 2552, configured to analyze the hot reloaded code file, and generate an executable code based on an analysis result;

an establishing module 2553, configured to establish an association relationship between the executable code and the source code of the application program in a running state;

a calling module 2554, configured to call the executable code based on the association relationship, so as to update interface content corresponding to the application program.

In some embodiments, the establishing module 2553 is further configured to determine a class included in the executable code;

In some embodiments, the establishing module 2553 is further configured to obtain class inheritance relationships between classes contained in the executable code;

In some embodiments, the establishing module 2553 is further configured to register a parent class included in the executable code with the class manager;

acquiring the offset and the size of the member variable of the parent class;

In some embodiments, the apparatus further comprises:

correspondingly, the establishing module 2553 is further configured to obtain a code field of the member variable corresponding to the target class in the executable code;

In some embodiments, the establishing module 2553 is further configured to add the member method of the target class included in the executable code to the class manager when the class manager does not have the member method of the target class;

In some embodiments, the establishing module 2553 is further configured to obtain a target member method of the member methods of the target class of the class manager, which is different from the member method of the target class included in the executable code;

In some embodiments, the establishing module 2553 is further configured to redirect the executable code, the reference to the class included in the executable code, to the reference to the class registered to the class manager, so as to establish an association relationship between the executable code and the source code of the application program in the running state.

In some embodiments, the calling module 2554 is further configured to call the executable code by calling the class registered to the class manager when the application program is in a running state.

In some embodiments, the apparatus further comprises:

In some embodiments, the triggering module is further configured to monitor a release state change of an object corresponding to the modified source code;

In some embodiments, the trigger module is further configured to identify modified source code of the application;

Continuing with the description of the application code processing apparatus 1600 provided by the embodiments of the present invention, in some embodiments, the application code processing apparatus may be implemented as a software module. Referring to fig. 16, fig. 16 is a schematic structural diagram of an application code processing apparatus 1600 according to an embodiment of the present invention, where the application code processing apparatus 1600 according to the embodiment of the present invention includes:

a presenting module 1610 configured to present source code of the application program in a code editing interface;

an update module 1620, configured to, in response to a modification operation on a source code of an application program, update a source code of the application program presented based on content corresponding to the modification operation;

a generating module 1630, configured to generate a hot reloading code file corresponding to the application program in response to the determination operation for the updated source code;

the sending module 1640 is configured to send the hot reloaded code file to the application program in the running state;

An embodiment of the present invention further provides an electronic device, where the electronic device includes:

a memory for storing executable instructions;

In some embodiments, the storage medium may be memory such as FRAM, ROM, PROM, EPROM, EEPROM, flash memory, magnetic surface memory, optical disk, or CD-ROM; or may be various devices including one or any combination of the above memories. The computer may be a variety of computing devices including intelligent terminals and servers.

In some embodiments, executable instructions may be written in any form of programming language (including compiled or interpreted languages), in the form of programs, software modules, scripts or code, and may be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.

By way of example, executable instructions may correspond, but do not necessarily have to correspond, to files in a file system, and may be stored in a portion of a file that holds other programs or data, such as in one or more scripts in a hypertext markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, sub-programs, or portions of code).

By way of example, executable instructions may be deployed to be executed on one computing device or on multiple computing devices at one site or distributed across multiple sites and interconnected by a communication network.

The above description is only an example of the present invention, and is not intended to limit the scope of the present invention. Any modification, equivalent replacement, and improvement made within the spirit and scope of the present invention are included in the protection scope of the present invention.

Claims

1. A method for processing application code, the method comprising:

2. The method of claim 1, wherein said establishing an association between the executable code and source code of the application in a running state comprises:

determining a class contained by the executable code;

3. The method of claim 2, wherein registering the class included in the executable code with a class manager comprises:

acquiring class inheritance relationships among classes contained in the executable codes;

4. The method of claim 3, wherein registering the classes contained in the executable code to the class manager in an order of registration with a parent class followed by a child class comprises:

registering a parent class contained in the executable code to the class manager;

acquiring the offset and the size of the member variable of the parent class;

5. The method of claim 2, wherein after determining the class included in the executable code, the method further comprises:

comparing the class contained in the executable code with the class in the class manager to obtain a comparison result;

correspondingly, registering the target class contained in the executable code to a class manager includes:

acquiring a code field of the member variable corresponding to the target class in the executable code;

6. The method of claim 5, wherein replacing the member method of the target class in the class manager with the member method of the target class included in the executable code comprises:

when the class manager does not exist the member method of the target class, adding the member method of the target class contained in the executable code to the class manager;

7. The method of claim 5, wherein replacing the member method of the target class in the class manager with the member method of the target class included in the executable code comprises:

acquiring a target member method which is different from the member method of the target class contained in the executable code in the member methods of the target class of the class manager;

8. The method of claim 2, wherein establishing an association between the executable code and source code of the application program in a running state based on a class manager registered with a class included in the executable code comprises:

redirecting the executable code, the reference to the class contained in the executable code, to the reference to the class registered to the class manager to establish an association between the executable code and the source code of the application program in a running state.

9. The method of claim 8, wherein said invoking said executable code based on said incidence relation comprises:

and when the application program is in a running state, calling the executable code by calling the class registered to the class manager.

10. The method of claim 1, wherein prior to establishing the association between the executable code and the source code of the application in a running state, the method further comprises:

monitoring a change in state of a main thread of the application;

11. The method of claim 1, wherein prior to establishing the association between the executable code and the source code of the application in a running state, the method further comprises:

monitoring the release state change of an object corresponding to the modified source code;

12. The method of claim 1, wherein prior to establishing the association between the executable code and the source code of the application in a running state, the method further comprises:

identifying source code of the application that is modified;

13. A method for processing application code, the method comprising:

presenting source code of an application program in a code editing interface;

14. An apparatus for processing application code, the apparatus comprising:

15. An apparatus for processing application code, the apparatus comprising: