CN112947927A

CN112947927A - Application program running method and device, terminal equipment and medium

Info

Publication number: CN112947927A
Application number: CN201911156475.9A
Authority: CN
Inventors: 肖继伟; 窦泽飞; 王小建
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2019-11-22
Filing date: 2019-11-22
Publication date: 2021-06-11

Abstract

The embodiment of the application is applicable to the technical field of information, and provides an application program running method, an application program running device, terminal equipment and a medium, wherein the method is applicable to the terminal equipment and comprises the following steps: when detecting that an application program is started, acquiring a class list file corresponding to the application program; identifying a target class in the class list file; starting a target thread, and initializing the target class by adopting the target thread. By identifying classes which can be initialized in advance in the program, the method can generate the instruction which can be directly executed by the operating system more quickly without recompiling the application program in a designated compiler, and is favorable for improving the running performance of the application program.

Description

Application program running method and device, terminal equipment and medium

Technical Field

The present application belongs to the field of information technology, and in particular, to an application program running method, apparatus, terminal device, and medium.

Background

To improve programming efficiency, Java, Python, etc. object-oriented cross-platform programming languages are very popular. Compared with the traditional programming language which can be executed after the corresponding operating system platform is compiled, the cross-platform programming language can be executed on different operating system platforms through one-time compiling. To implement this feature, the application program is not run directly on the operating system, but is run on a designated virtual machine, such as a Java virtual machine, Python virtual machine, or the like. Fig. 1 shows a virtual frame structure in the prior art. According to the architecture shown in fig. 1, an application runs in a designated virtual machine that masks various types of information associated with a particular operating system platform. The running process of the application program in the virtual machine is shown in fig. 2, and the source code of the application program is firstly compiled into byte codes which can be understood by the virtual machine, then is converted into machine codes which can be understood by different hardware platforms by the virtual machine, and then is executed. However, the process of converting bytecode into machine code by the virtual machine results in relatively low operating efficiency. In this case, how to generate an instruction that can be directly executed by the operating system more quickly becomes a key for improving system performance. In the prior art, the running efficiency of the application program can be improved by two modes of compiling phase optimization and executing phase optimization.

And in the compiling stage, the optimization is processed in the compiling stage by identifying partial codes, so that the data volume waiting for the conversion of the virtual machine can be reduced, and the running efficiency is improved. Fig. 3 is a schematic diagram illustrating a process of compiling stage optimization in the prior art. For the original pseudo code shown in fig. 3, if it is recognized that the code corresponding to Source2 can be executed in advance during compilation, the part of the code is not compiled into byte code, but can be directly extracted and compiled into machine code that can be directly executed. When the application program runs, when the code logic corresponding to Source2 is executed, the extracted compiling result can be directly executed. The execution stage optimization does not require special processing on the codes in the compiling stage, but the codes are completely compiled into byte codes, and after the application program is installed on a corresponding operating system platform, the program is recompiled into instructions which can be directly executed by the system at a specified time. Fig. 4 is a schematic diagram illustrating a process of performing phase optimization in the prior art. For the original pseudo code shown in fig. 4, all the original pseudo code is compiled into byte code in the compiling stage, and then when the application program runs and executes the code logic corresponding to the ByteCode2, the compiled machine code is directly executed, and the overhead generated by converting the ByteCode2 into RunCode2 from a virtual machine is omitted, so that the performance is improved.

The compilation stage optimization requires a developer to compile using a specified virtual machine environment and run on a specified virtual machine to obtain a corresponding performance benefit. However, there are many different virtual machines in the market, and if developers are required to recompile by using a specific virtual machine, extra workload is increased, and the cost of compilation is increased. On the other hand, the application itself usually has the behavior of modifying the original application files by patching, hot update, etc., and also accesses the files within the application. The bytecode is compiled into the machine code by adopting an execution stage optimization mode, the original application program file still cannot be deleted, which is equivalent to the newly added file, and additional disk overhead is brought.

Disclosure of Invention

The embodiment of the application provides an application program running method, an application program running device, terminal equipment and a medium, and running performance of the application program can be improved.

In a first aspect, an embodiment of the present application provides an application program running method, which is applicable to a terminal device, and the method includes:

when detecting that an application program is started, acquiring a class list file corresponding to the application program;

identifying a target class in the class list file;

starting a target thread, and initializing the target class by adopting the target thread.

For example, the terminal device may be an Android system-based device, and may identify a static class in a source code by obtaining the source code of the application; and then generating a class list file corresponding to the application program based on the static class. The class list file may include class names of respective classes that can be initialized in advance.

It should be understood that each class capable of being initialized in advance can find out variables and code segments which are marked by preset characters in the source code by analyzing each class in the source code, and the class of the initialization code corresponding to the class, which does not include other task execution logic, is taken as the class capable of being initialized in advance.

On the other hand, in order to ensure the identification accuracy of the class which can be initialized in advance, on the basis of the steps, whether the class has a calling relationship with other classes can be judged, and if the class does not have the calling relationship, the class can be confirmed to be a static class which can be initialized in advance; if a calling relationship exists, the class can be identified as a static class which can be initialized in advance only when the class and all classes on the calling path are judged to be static classes. Through twice recognition, the accuracy of the recognized static class can be ensured.

For example, when the class list file is generated, the initialization stage of each static class may be determined, the mapping relationship between the class name of each static class and the corresponding initialization stage is established, and the mapping relationship is written in the class list file.

Because the initialization of the static classes in advance needs corresponding memory support, whether the system can initialize all the static classes in advance has a larger relation with the memory size of the system. When the system memory is not particularly sufficient, the mapping relationship between each static class in the class list file and the initialization stage thereof can be established, so that each static class is initialized in stages when the application program runs, and the occupation of the system memory and the disk is reduced.

Illustratively, the generated class list file may be uploaded to a server. When other terminal devices download the application program from the server, the server can send the corresponding class list file to other terminal devices, and when the other terminal devices start the application program, the received class list file can be directly extracted, and the initialization operation is performed on the target class in the file in advance.

In a second aspect, an embodiment of the present application provides a method for generating a category list file, including:

acquiring a source code of an application program;

identifying a static class in the source code;

and generating a class list file corresponding to the application program based on the static class.

In a third aspect, an embodiment of the present application provides an application running apparatus, which is suitable for a terminal device, and the apparatus includes:

the system comprises an acquisition module, a storage module and a processing module, wherein the acquisition module is used for acquiring a class list file corresponding to an application program when the application program is detected to be started;

the identification module is used for identifying the target class in the class list file;

and the initialization module is used for starting a target thread and initializing the target class by adopting the target thread.

In a fourth aspect, an embodiment of the present application provides an apparatus for generating a category list file, including:

the acquisition module is used for acquiring a source code of the application program;

the identification module is used for identifying the static class in the source code;

and the generation module is used for generating a class list file corresponding to the application program based on the static class.

In a fifth aspect, an embodiment of the present application provides a terminal device, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor, where the processor implements the application running method described in any one of the above first aspects when executing the computer program.

In a sixth aspect, the present application provides a computer-readable storage medium, where a computer program is stored, and the computer program, when executed by a processor, implements the application running method described in any one of the above first aspects.

In a seventh aspect, an embodiment of the present application provides a computer program product, which, when running on a terminal device, causes the terminal device to execute the application running method in any one of the above first aspects.

Compared with the prior art, the embodiment of the application has the following beneficial effects:

according to the embodiment of the application, when the application program is detected to be started, the target thread can be started and initialized by acquiring the class list file corresponding to the application program and identifying the target class in the class list file. By identifying classes which can be initialized in advance in the program, the method can generate the instruction which can be directly executed by the operating system more quickly without recompiling the application program in a designated compiler, and the application program code does not need to be compiled into a machine code file, so that the repeated occupation of the disk space is reduced, all classes which accord with the initialization condition in advance can obtain corresponding performance optimization benefits during initialization, and the method is favorable for improving the running performance of the application program.

Drawings

In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings used in the embodiments or the description of the prior art will be briefly described below. It is obvious that the drawings in the following description are only some embodiments of the application, and that for a person skilled in the art, other drawings can be derived from them without inventive effort.

FIG. 1 is a diagram of a virtual machine architecture in the prior art;

FIG. 2 is a schematic diagram illustrating a process of an application running in a virtual machine according to the prior art;

FIG. 3 is a diagram illustrating a compilation stage optimization process in the prior art;

FIG. 4 is a schematic diagram of a process for performing phase optimization in the prior art;

FIG. 5 is a diagram illustrating a process for executing a class by a thread according to the prior art;

fig. 6 is a schematic hardware structure diagram of a mobile phone to which an application program running method provided in an embodiment of the present application is applied;

fig. 7 is a schematic software structure diagram of a mobile phone to which an application program running method provided in an embodiment of the present application is applied;

FIG. 8 is a flowchart illustrating exemplary steps of a method for running an application according to an embodiment of the present application;

FIG. 9 is a flowchart illustrating exemplary steps of a method for running an application according to another embodiment of the present application;

FIG. 10(a) is a schematic diagram of a first scan parsing process for identifying static classes according to an embodiment of the present application;

FIG. 10(b) is a diagram illustrating a second scanning resolution process for identifying static classes according to an embodiment of the present application;

FIG. 11 is a flowchart illustrating exemplary steps of a method for running an application according to yet another embodiment of the present application;

FIG. 12 is a schematic diagram of a class initialization process provided by an embodiment of the present application;

FIG. 13 is a flowchart illustrating exemplary steps of a method for generating a class list file according to an embodiment of the present application;

fig. 14 is a schematic diagram of a system architecture to which an application running method according to an embodiment of the present application is applied;

fig. 15 is a block diagram illustrating an application running apparatus according to an embodiment of the present application;

fig. 16 is a block diagram illustrating a structure of a class list file generation apparatus according to an embodiment of the present application;

fig. 17 is a schematic structural diagram of a terminal device according to an embodiment of the present application.

Detailed Description

In the following description, for purposes of explanation and not limitation, specific details are set forth, such as particular system structures, techniques, etc. in order to provide a thorough understanding of the embodiments of the present application. However, it will be apparent to one skilled in the art that the present application may be practiced in other embodiments that depart from these specific details. In other instances, detailed descriptions of well-known systems, devices, circuits, and methods are omitted so as not to obscure the description of the present application with unnecessary detail.

The terminology used in the following examples is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. As used in the specification of this application and the appended claims, the singular forms "a", "an", "the" and "the" are intended to include the plural forms as well, such as "one or more", unless the context clearly indicates otherwise. It should also be understood that in the embodiments of the present application, "one or more" means one, two, or more than two; "and/or" describes the association relationship of the associated objects, indicating that three relationships may exist; for example, a and/or B, may represent: a alone, both A and B, and B alone, where A, B may be singular or plural. The character "/" generally indicates that the former and latter associated objects are in an "or" relationship.

The application program running method provided by the embodiment of the application can be used for initializing and optimizing all object-oriented and cross-platform language program classes, and the execution performance of the application program is improved. For ease of understanding, an introduction will first be made to the features of this type of language associated with the present embodiment.

In the object-oriented programming language, there is a "class" in the code, all things in the system are "objects", which are instances of "class", and the program will initialize the required "class" as "instance" when executing and then execute it.

To ensure the correctness of the execution of an object-oriented programming language, strict rules are imposed on the initialization of "classes". In JAVA for example, a class is initialized only once and follows the principle of "initialization on first active use", i.e. only when the class is used. If this principle is not followed, class a will generate an erroneous initialization result if it refers to class B during initialization, but class B has not yet been executed.

FIG. 5 is a diagram illustrating a process for executing a class by a thread. The code for class initialization is also executed after being converted by a virtual machine, and the above principle is followed, so that the part of logic is executed completely in a serial manner, and the generated performance consumption is relatively serious.

Generally, an application basically defines a "static" domain for defining constants, executing static methods, and the like, and code belonging to the "static" domain has a special word modification, generally static, and the initialization of the "static" domain is special and can not depend on a specific "instance", so that it is not necessary to wait for initialization of a certain class, and separate initialization can be required without departing from the above specification.

Therefore, the application program running method provided by the embodiment of the application program identifies classes which can be initialized independently and do not affect the correctness of the program, and then initializes the classes in a parallel manner in advance at a proper time, so that the execution performance of the application program can be improved.

The application program running method provided by the embodiment of the application can be applied to terminal devices such as Mobile phones, tablet computers, wearable devices, vehicle-mounted devices, Augmented Reality (AR)/Virtual Reality (VR) devices, notebook computers, Ultra-Mobile Personal computers (UMPC), netbooks, Personal Digital Assistants (PDA), and the like, and the embodiment of the application does not have any limitation on the specific types of the terminal devices.

For example, the terminal device may be a station (station, ST) in a Wireless Local Area Network (WLAN), and may be a cellular phone, a cordless phone, a Session Initiation Protocol (SIP) phone, a Wireless Local Loop (WLL) station, a PDA device, a handheld device with Wireless communication capability, a computing device or other processing device connected to a Wireless modem, a vehicle-mounted device, a vehicle-mounted networking terminal, a computer, a laptop computer, a handheld communication device, a handheld computing device, a satellite Wireless device, a Wireless modem card, a television Set-Top Box (STB), a Customer Premises Equipment (CPE), and/or other devices for communicating over a Wireless system and a next generation communication system, such as a Mobile terminal in a 5G Network or a Public Land Mobile Network (Public Land Mobile Network, PLMN), etc.

By way of example and not limitation, when the terminal device is a wearable device, the wearable device may also be a generic term for intelligently designing daily wearing by applying wearable technology, developing wearable devices, such as glasses, gloves, watches, clothing, shoes, and the like. A wearable device is a portable device that is worn directly on the body or integrated into the clothing or accessories of the user. The wearable device is not only a hardware device, but also can realize powerful functions through software support, data interaction and cloud interaction. The generalized wearable intelligent device has the advantages that the generalized wearable intelligent device has complete functions and large size, can realize complete or partial functions without depending on a smart phone, such as a smart watch or smart glasses, and is only concentrated on a certain application function, and needs to be matched with other devices such as the smart phone for use, such as various smart bracelets for monitoring physical signs, smart jewelry and the like.

Take the terminal device as a mobile phone as an example. Fig. 6 is a block diagram illustrating a partial structure of a mobile phone according to an embodiment of the present disclosure. Referring to fig. 6, the handset includes: radio Frequency (RF) circuit 610, memory 620, input unit 630, display unit 640, sensor 650, audio circuit 660, Wireless Fidelity (Wi-Fi) module 670, processor 680, and power supply 690. Those skilled in the art will appreciate that the handset configuration shown in fig. 6 is not intended to be limiting and may include more or fewer components than those shown, or some components may be combined, or a different arrangement of components.

The following describes each component of the mobile phone in detail with reference to fig. 6:

the RF circuit 610 may be used for receiving and transmitting signals during information transmission and reception or during a call, and in particular, receives downlink information of a base station and then processes the received downlink information to the processor 680; in addition, the data for designing uplink is transmitted to the base station. In general, RF circuit 610 includes, but is not limited to, an antenna, at least one Amplifier, a transceiver, a coupler, a Low Noise Amplifier (LNA), a duplexer, and the like. In addition, the RF circuitry 610 may also communicate with networks and other devices via wireless communications. The wireless communication may use any communication standard or protocol, including but not limited to Global System for Mobile communication (GSM), General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), Long Term Evolution (LTE)), e-mail, Short Messaging Service (SMS), and the like.

The memory 620 may be used to store software programs and modules, and the processor 680 may execute various functional applications and data processing of the mobile phone by operating the software programs and modules stored in the memory 620. The memory 620 may mainly include a storage program area and a storage data area, wherein the storage program area may store an operating system, an application program required by at least one function (such as a sound playing function, an image playing function, etc.), and the like; the storage data area may store data (such as audio data, a phonebook, etc.) created according to the use of the cellular phone, and the like. Further, the memory 620 may include high speed random access memory, and may also include non-volatile memory, such as at least one magnetic disk storage device, flash memory device, or other volatile solid state storage device.

The input unit 630 may be used to receive input numeric or character information and generate key signal inputs related to user settings and function control of the cellular phone 600. Specifically, the input unit 630 may include a touch panel 631 and other input devices 632. The touch panel 631, also referred to as a touch screen, may collect touch operations of a user (e.g., operations of the user on the touch panel 631 or near the touch panel 631 by using any suitable object or accessory such as a finger or a stylus) thereon or nearby, and drive the corresponding connection device according to a preset program. Alternatively, the touch panel 631 may include two parts of a touch detection device and a touch controller. The touch detection device detects the touch direction of a user, detects a signal brought by touch operation and transmits the signal to the touch controller; the touch controller receives touch information from the touch sensing device, converts the touch information into touch point coordinates, sends the touch point coordinates to the processor 680, and can receive and execute commands sent by the processor 680. In addition, the touch panel 631 may be implemented using various types, such as resistive, capacitive, infrared, and surface acoustic wave. The input unit 630 may include other input devices 632 in addition to the touch panel 631. In particular, other input devices 632 may include, but are not limited to, one or more of a physical keyboard, function keys (such as volume control keys, switch keys, etc.), a trackball, a mouse, a joystick, and the like.

The display unit 640 may be used to display information input by the user or information provided to the user and various menus of the mobile phone. The Display unit 640 may include a Display panel 641, and optionally, the Display panel 641 may be configured in the form of a Liquid Crystal Display (LCD), an Organic Light-Emitting Diode (OLED), or the like. Further, the touch panel 631 can cover the display panel 641, and when the touch panel 631 detects a touch operation thereon or nearby, the touch panel is transmitted to the processor 680 to determine the type of the touch event, and then the processor 680 provides a corresponding visual output on the display panel 641 according to the type of the touch event. Although in fig. 6, the touch panel 631 and the display panel 641 are two independent components to implement the input and output functions of the mobile phone, in some embodiments, the touch panel 631 and the display panel 641 may be integrated to implement the input and output functions of the mobile phone.

The handset 600 may also include at least one sensor 650, such as a light sensor, motion sensor, and other sensors. Specifically, the light sensor may include an ambient light sensor that adjusts the brightness of the display panel 641 according to the brightness of ambient light, and a proximity sensor that turns off the display panel 641 and/or the backlight when the mobile phone is moved to the ear. As one of the motion sensors, the accelerometer sensor can detect the magnitude of acceleration in each direction (generally, three axes), can detect the magnitude and direction of gravity when stationary, and can be used for applications of recognizing the posture of a mobile phone (such as horizontal and vertical screen switching, related games, magnetometer posture calibration), vibration recognition related functions (such as pedometer and tapping), and the like; as for other sensors such as a gyroscope, a barometer, a hygrometer, a thermometer, and an infrared sensor, which can be configured on the mobile phone, further description is omitted here.

Audio circuit 660, speaker 661, and microphone 662 can provide an audio interface between a user and a cell phone. The audio circuit 660 may transmit the electrical signal converted from the received audio data to the speaker 661, and convert the electrical signal into an audio signal through the speaker 661 for output; on the other hand, the microphone 662 converts the collected sound signals into electrical signals, which are received by the audio circuit 660 and converted into audio data, which are processed by the audio data output processor 680 and then transmitted via the RF circuit 610 to, for example, another cellular phone, or output to the memory 620 for further processing.

Wi-Fi belongs to short-distance wireless transmission technology, and a mobile phone can help a user to receive and send emails, browse webpages, access streaming media and the like through a Wi-Fi module 670, and provides wireless broadband internet access for the user. Although fig. 6 shows a Wi-Fi module 670, it is understood that it does not belong to the essential constitution of the handset 600, and may be omitted entirely as needed within the scope not changing the essence of the present application.

The processor 680 is a control center of the mobile phone, and connects various parts of the entire mobile phone by using various interfaces and lines, and performs various functions of the mobile phone and processes data by operating or executing software programs and/or modules stored in the memory 620 and calling data stored in the memory 620, thereby performing overall monitoring of the mobile phone. Optionally, processor 680 may include one or more processing units; preferably, the processor 680 may integrate an application processor, which mainly handles operating systems, user interfaces, application programs, etc., and a modem processor, which mainly handles wireless communications. It will be appreciated that the modem processor described above may not be integrated into processor 680.

The handset 600 also includes a power supply 690 (e.g., a battery) for powering the various components, which may preferably be logically coupled to the processor 680 via a power management system, such that the power management system may be used to manage charging, discharging, and power consumption.

Although not shown, the handset 600 may also include a camera. Optionally, the position of the camera on the mobile phone 600 may be front-located or rear-located, which is not limited in this embodiment of the application.

Optionally, the mobile phone 600 may include a single camera, a dual camera, or a triple camera, which is not limited in this embodiment.

For example, the cell phone 600 may include three cameras, one being a main camera, one being a wide camera, and one being a tele camera.

Optionally, when the mobile phone 600 includes a plurality of cameras, all of the plurality of cameras may be arranged in front of the mobile phone, or all of the plurality of cameras may be arranged in back of the mobile phone, or a part of the plurality of cameras may be arranged in front of the mobile phone, and another part of the plurality of cameras may be arranged in back of the mobile phone, which is not limited in this embodiment of the application.

In addition, although not shown, the mobile phone 600 may further include a bluetooth module, etc., which will not be described herein.

Fig. 7 is a schematic diagram of a software structure of a mobile phone 600 according to an embodiment of the present application. Taking the mobile phone 600 operating system as an Android system as an example, in some embodiments, the Android system is divided into four layers, which are an application layer, an application Framework layer (FWK), a system layer and a hardware abstraction layer, and the layers communicate with each other through a software interface.

As shown in fig. 7, the application layer may include a series of application packages, which may include short messaging, calendar, camera, video, navigation, gallery, call, etc. applications.

The Application framework layer provides an Application Programming Interface (API) and a Programming framework for the Application program of the Application layer. The application framework layer may include some predefined functions, such as functions for receiving events sent by the application framework layer.

As shown in fig. 7, the application framework layer may include a window manager, a resource manager, and a notification manager, among others.

The window manager is used for managing window programs. The window manager can obtain the size of the display screen, judge whether a status bar exists, lock the screen, intercept the screen and the like. The content provider is used to store and retrieve data and make it accessible to applications. The data may include video, images, audio, calls made and received, browsing history and bookmarks, phone books, etc.

The resource manager provides various resources for the application, such as localized strings, icons, pictures, layout files, video files, and the like.

The notification manager enables the application to display notification information in the status bar, can be used to convey notification-type messages, can disappear automatically after a short dwell, and does not require user interaction. Such as a notification manager used to inform download completion, message alerts, etc. The notification manager may also be a notification that appears in the form of a chart or scroll bar text at the top status bar of the system, such as a notification of a background running application, or a notification that appears on the screen in the form of a dialog window. For example, prompting text information in the status bar, sounding a prompt tone, vibrating the electronic device, flashing an indicator light, etc.

The application framework layer may further include:

a viewing system that includes visual controls, such as controls to display text, controls to display pictures, and the like. The view system may be used to build applications. The display interface may be composed of one or more views. For example, the display interface including the short message notification icon may include a view for displaying text and a view for displaying pictures.

The phone manager is used to provide the communication functions of the handset 600. Such as management of call status (including on, off, etc.).

The system layer may include a plurality of functional modules. For example: a sensor service module, a physical state identification module, a three-dimensional graphics processing library (such as OpenGL ES), and the like.

The sensor service module is used for monitoring sensor data uploaded by various sensors in a hardware layer and determining the physical state of the mobile phone 600;

the physical state recognition module is used for analyzing and recognizing user gestures, human faces and the like;

the three-dimensional graphic processing library is used for realizing three-dimensional graphic drawing, image rendering, synthesis, layer processing and the like.

The system layer may further include:

the surface manager is used to manage the display subsystem and provide fusion of 2D and 3D layers for multiple applications.

The media library supports a variety of commonly used audio, video format playback and recording, and still image files, among others. The media library may support a variety of audio-video encoding formats, such as MPEG4, h.264, MP3, AAC, AMR, JPG, PNG, and the like.

The hardware abstraction layer is a layer between hardware and software. The hardware abstraction layer may include a display driver, a camera driver, a sensor driver, etc. for driving the relevant hardware of the hardware layer, such as a display screen, a camera, a sensor, etc.

The following embodiments may be implemented on the cellular phone 600 having the above-described hardware structure/software structure. The following embodiment will describe an application program running method provided in the embodiment of the present application, taking the mobile phone 600 as an example.

Referring to fig. 8, a flowchart illustrating schematic steps of an application running method according to an embodiment of the present application is shown, and the method can be applied to the above-mentioned mobile phone 600 by way of example and not limitation. The method specifically comprises the following steps:

s801, when detecting that an application program is started, acquiring a class list file corresponding to the application program;

the class list file in this embodiment may be generated in advance and stored in the terminal device, and the file may record which classes that can be initialized in advance in the currently started application program.

Generally, the static classes defined in the application code do not depend on specific instantiation objects, and can be initialized individually or executed individually, and the classes capable of being initialized in advance in the embodiment can refer to the static classes.

Generally, static classes have specialized word modifiers in the code, such as static. Therefore, in a specific implementation, the information of the static classes that can be initialized in advance by the application program can be obtained by scanning and analyzing the source code of the application program, and after the class names of the static classes that can be initialized in advance are written into the file, the corresponding class list file can be obtained.

S802, identifying a target class in the class list file;

the target class in the class list file may refer to all static classes recorded in the file and capable of being initialized in advance, or may be a part of the static classes, which is not limited in this embodiment.

Because the initialization of the static classes in advance needs corresponding memory support, whether the system can initialize all the static classes in advance has a larger relation with the memory size of the system. Therefore, if the system memory is sufficient or all functional logic is expected to be used by the application program, all static classes in the class list file can be identified as target classes, and all static classes can be initialized in advance.

If the system memory is not sufficient enough, only part of the static classes may be initialized in advance, and the target class may be a part of the whole static classes. Those skilled in the art can determine which static classes are identified as the target classes in this case according to the actual situation, which is not limited in this embodiment.

And S803, starting a target thread, and initializing the target class by adopting the target thread.

In this embodiment, the target thread may refer to a new thread that can be used to initialize the static class.

Generally, the static class capable of being initialized in advance may include multiple static classes, and when the static class needs to be initialized in advance, multiple target threads may be started based on the capability of a multi-core CPU of the system, and each target class is initialized in parallel by the multiple target threads, so as to improve the running performance of the application program.

In the embodiment of the application, when the application program is detected to be started, the target thread may be started and initialized by acquiring the class list file corresponding to the application program and identifying the target class in the class list file. By identifying classes which can be initialized in advance in the program, the method can generate the instruction which can be directly executed by the operating system more quickly without recompiling the application program in a designated compiler, and the application program code does not need to be compiled into a machine code file, so that the repeated occupation of the disk space is reduced, all classes which accord with the initialization condition in advance can obtain corresponding performance optimization benefits during initialization, and the method is favorable for improving the running performance of the application program.

Referring to fig. 9, a flowchart illustrating schematic steps of an application running method according to another embodiment of the present application is shown, where the method specifically includes the following steps:

s901, acquiring a source code of the application program, and identifying a static class in the source code;

since the static class defined in the application code is usually decorated by a specific character, such as static, before identifying the static class, the source code of the application program may be first obtained, and then the source code is scanned by the scanner component to generate a class list file corresponding to the application program. The class list file is a subset of classes that the application can use to initialize in advance.

In a specific implementation, the program package of the application program may be obtained first, and then the bytecode of the application program may be obtained by parsing the program package. At present, there are many tools that can parse codes in a package into byte codes, such as decompressing jar files: jar xf jar, etc.

After obtaining the above byte code, a decompilation tool may be used to decompilate the byte code into a source code, such as a decompilation JAVA tool: class, etc.

It should be noted that, the package parsing tool and the decompilation tool described above as examples are for the JAVA language, but those skilled in the art should understand that, for packages written in different programming languages, the package parsing tool and the decompilation tool may be different, and this embodiment is not limited thereto.

Of course, the reverse compiling of the bytecode into the source code is only one way to obtain the source code, and in the case that the source code of the application program can be directly obtained, the existing source code may also be directly analyzed, which is not limited in this embodiment.

For the obtained source code, the static class of the application program can be identified by scanning the source code and analyzing each class in the source code.

In a particular implementation, identifying the static class may include a process of two scans and resolutions. First, on the first scan of the source code, an initial static class may be identified. Taking JAVA language as an example, if a source code corresponding to a certain class includes a variable and a code segment marked with a preset character, and an initialization code corresponding to the class does not include other task execution logic, the class may be identified as an initial static class, and the certain class may refer to any one of the classes. That is, for source code written in the JAVA language, the initial static class should satisfy the following condition: there are variables and code segments marked static and the initialization code contains no other task execution logic. Wherein, other task execution logic may refer to variables and code segments that are not marked with a preset character static.

Fig. 10(a) is a schematic diagram of a first scanning and parsing process for identifying static classes according to an embodiment of the present application. The method comprises the steps of analyzing various classes of source codes by scanning the source codes, finding out contained static variables and static execution segments, analyzing whether initialization codes corresponding to the static variables and the static execution segments do not comprise other task execution logics or not, and if so, preliminarily identifying the initialization codes as classes which can be initialized in advance, namely initial static classes.

Then, it may be detected whether the initialization code of the target initial static class has a call relationship with other classes, where the target initial static class is any one of the initial static classes. If the initialization code of the target initial static class has no calling relation with other classes, the target initial static class can be identified as the static class; if the initialization code of the target initial static class has a calling relationship with other classes, whether the other classes having the calling relationship are initial static classes needs to be continuously judged, the target initial static class can be identified as a static class only when a certain target initial static class is a static class and the other classes called by the initialization code are static classes, otherwise, the target initial static class is identified as a non-static class.

Fig. 10(b) is a schematic diagram of a second scanning and parsing process for identifying static classes according to an embodiment of the present application. The method comprises the steps of analyzing various classes of source codes by scanning the source codes, finding out contained static variables and static execution segments from the classes, and analyzing the inheritance relationship of initialization codes corresponding to the static variables and the static execution segments. If the parent class is inherited to some other class, whether the class belongs to the static class can be identified according to the judgment result of the parent class, and if the parent class is not inherited to some other class, whether the class refers to the other class can be judged. For a multi-level nested call, only if all classes on the call path are static classes, the call can be identified as the static classes. Taking JAVA language as an example, if it is recognized that the initialization code includes a classref.

As shown in fig. 10(b), when identifying whether or not a class belongs to a static class according to the determination result of a parent class, there are two cases: if the parent class determines that the result is a non-static class, the currently identified class should be identified as the non-static class; the other is that the result of the parent class determination is a static class, at this time, the subsequent logic can be continuously executed to determine whether the class refers to other classes, so as to determine whether the class can be initialized in advance.

S902, generating a class list file corresponding to the application program based on the static class;

after the source code of the application program is scanned and all the static classes are identified, a class list file which can be initialized in advance by the application program can be generated. The class list file may have recorded therein all the class names of static classes that can be initialized in advance.

S903, uploading the class list file to a server;

since the class list file is not related to the operating system platform, but only to the application program, the generated class list file may be uploaded to a server, which may be referred to as an application store or a cloud server. When other terminal devices acquire and install a certain application program from the server, the server may send the class list file corresponding to the application program to the terminal device together for the terminal device to use when running the application program.

S904, when the starting of the application program is detected, acquiring a class list file corresponding to the application program;

s905, identifying a target class in the class list file;

s906, starting a target thread, and initializing the target class by adopting the target thread.

After a class list file corresponding to an application program is generated, when the application program is started on the terminal device, the terminal device may first obtain the list file corresponding to the application program, and then start a thread and initialize the classes in advance according to class names of static classes that may be initialized in advance recorded in the class list file.

It should be noted that, since steps S904 to S906 of the present embodiment are similar to steps S801 to S803 of the previous embodiment, reference may be made to each other, and this embodiment is not described again.

In the embodiment of the application, the static classes capable of being initialized in advance can be identified by scanning the source codes of the application program, and after the class list file is generated according to the static classes, the class list file can be uploaded to the server for being downloaded and used by other terminal equipment, so that the use range of the class list file is expanded. Meanwhile, when the static class is identified according to the source code of the application program, the static class is identified as the static class only when the static class and other classes on the calling path are the static classes by judging whether other classes on the calling path of each static class with multi-layer nested calling are also the static classes or not, and the identification accuracy is ensured.

Referring to fig. 11, a flowchart illustrating schematic steps of an application running method according to another embodiment of the present application is shown, where the method specifically includes the following steps:

s1101, obtaining a source code of the application program, and identifying a static class in the source code;

it should be noted that step S1101 in this embodiment is similar to step S901 in the previous embodiment, and reference may be made to this embodiment, which is not described again.

S1102, determining an initialization stage of each static class, and establishing a mapping relation between the class name of each static class and the corresponding initialization stage;

In the embodiment of the application, the mapping relation between the program activity and the static class initialization can be completed in a machine learning or custom dotting mode, so that different static classes can be initialized at a proper stage, and the resource overhead caused by one-time excessive initialization is reduced.

Since human-computer interaction is most sensitive to performance, this embodiment mainly illustrates two implementation manners for establishing a mapping relationship for human-computer interaction in the Android operating system.

A starting stage: when the application program is detected to be started, recording a first static class which executes initialization operation within a preset time period from the start of the application program, and determining the initialization stage of the first static class as a starting stage.

In a specific implementation, the duration of the preset time period can be customized according to the bearing capacity of the system resources. For example, if the system memory is 2G, the first static class may be set to record that initialization is performed within 2 seconds from the start of the application. Generally, the more sufficient the memory resources, the longer the duration may be.

Take the preset time period as 2 seconds as an example. When the application program is detected to be started, the static class initialized in the process can be recorded and recorded, when the time of 2 seconds is up, the static class initialized is stopped and then all the static classes initialized in the 2 seconds are exported to be used as the first static class in the starting phase.

An application execution phase: when any interface of the application program is detected to be started, recording a second static class for executing initialization operation in a time period from the start of the interface to the completion of the interface, and determining the initialization stage of the second static class as an application execution stage.

For example, when a user opens a certain interface of an application program through a click operation, the Android system may monitor a newly opened Activity interface, record all static classes for which initialization is performed in the process, stop recording the initialized static classes after the Activity interface is started, and derive all static classes for which initialization is performed in the process as the second static class of the application execution stage.

S1103, generating a class list file corresponding to the application program according to the mapping relation;

after determining the mapping relationship between each static class and its initialization stage, the mapping relationship may be written into a class list file. The class list file records a plurality of class names of static classes capable of being initialized in advance and initialization stage information of each static class.

S1104, when detecting that an application program is started, acquiring a class list file corresponding to the application program; identifying a first static class in the class list file;

since the first static classes belong to static classes that are initialized at the start-up stage, these first static classes may first be identified from the class list file when an application start-up is detected.

S1105, starting a plurality of target threads and determining a first static class corresponding to each target thread; initializing the corresponding first static class in parallel by adopting each target thread;

generally, the first static class belonging to the startup phase may include a plurality of classes, and most terminal devices also have multi-core CPU processing capability. Therefore, based on the above-described multi-core CPU processing capability, a plurality of target threads are started, and each first static class is initialized in parallel by the respective target threads.

When the application program is detected to be started, the first static class is identified and initialized instead of initializing all the static classes in the process, so that the occupation of the initialized static classes on the memory and the disk space can be effectively reduced, and the running performance of the application program is further improved.

S1106, when any interface of the application program is detected to be started, identifying a second static class in the class list file; and starting a new target thread, and initializing the second static class by adopting the new target thread.

For the second static class which belongs to the application execution phase and only executes the initialization operation, when the Activity interface of the application program is detected to be started, a new target thread can be started to execute the initialization operation of the second static class.

Fig. 12 is a schematic diagram illustrating a class initialization process according to an embodiment of the present application. According to the process shown in fig. 12, by determining the initialization stage of each static class that can be initialized in advance, in the running process of the application program, when it is monitored that the corresponding time period arrives, the thread can be started to initialize the static class at the stage, and then other program execution processes are continued, so that the resource overhead caused by excessively initializing a plurality of static classes at one time in the running process of the application program can be reduced, and the running performance of the application program is improved more effectively.

Referring to fig. 13, a flowchart illustrating schematic steps of a method for generating a class list file according to an embodiment of the present application is shown, where the method specifically includes the following steps:

s1301, acquiring a source code of an application program;

s1302, identifying a static class in the source code;

and S1303, generating a class list file corresponding to the application program based on the static class.

It should be noted that the generation method of the class list file in this embodiment may be implemented in a terminal device, or may be implemented in a server, and this embodiment does not limit this.

If the class list file is generated in the terminal device, the terminal device can also upload the class list file to the server, when other terminal devices install the application program, the server can send the corresponding class list file to the terminal device, and the terminal device can directly identify which classes can be initialized in advance by using the class list file sent by the server.

Since steps S1301 to S1303 in this embodiment are similar to steps S901 to S902 and S1101 to S1103 in the previous embodiment, relevant details may be referred to each other, and are not described again in this embodiment.

For convenience of understanding, the following describes a generation method of the class list file and an application program running method in this embodiment, by taking an Android operating system as an example, in combination with a specific system architecture.

As shown in fig. 14, the system architecture diagram to which the application program running method of the present embodiment is applied includes a scanner, a class mapper, an application store/cloud server, an asynchronous loader, and the like according to the system architecture shown in fig. 14. Each component is described in detail below.

1. Scanner

The scanner component is responsible for scanning the source code of the application, generating a subset of classes corresponding to the application that can be used for pre-initialization, collectively referred to hereinafter as a "subset". The scanner may be deployed based on a windows/linux platform, copying the scanned subset to a class mapper or uploading directly to an application store or cloud server for JAVA language implementation.

An interface can be added on an ART (Android Runtime) virtual machine, and static classes initialized by the ART virtual machine are counted.

The process can comprise the following steps:

1.1, analyzing an application program package, and analyzing codes in the program package to obtain byte code codes;

1.2, inversely compiling the bytecode code into a source code;

1.3, all source codes are scanned for the first time, and static classes are identified. Taking JAVA language as an example, the class satisfies the following condition: variables and code segments marked by static exist, and initialization code does not contain other task execution logic;

and 1.4, scanning all source codes for the second time, calling other classes during initialization, identifying the other classes as static classes, putting the static class subsets, and requiring all classes on a calling path to be static classes for the existence of multi-layer nested calling. Taking JAVA language as an example, all the ways of calling other classes in the initialization code are in the format of classref.

And 1.5, generating a class list file which can be initialized in advance by the application program after the scanning is finished.

2. Class mapper (optional)

The method is used for establishing the mapping relation between each class in the static class subset and the application execution phase. This step can be omitted if system memory is sufficient or it is expected that the application will use all functional logic, i.e. all classes in the static class subset are loaded directly in the asynchronous loader.

The class mapper can be implemented in an Android operating system, and can monitor the starting of an application program and the opening of a certain Activity interface in a Framework layer and call an ART virtual machine corresponding interface. The class mapper is only deployed on a dedicated Android device, and a class mapping result (class list file) is generated and then uploaded to an application store or a cloud server for storage.

The mapping relation between the program activities and the initialization of the static classes can be completed in a machine learning or custom dotting mode, and the purpose is to initialize the static classes at a proper stage so as to reduce resource overhead caused by excessive initialization. Because human-computer interaction is most sensitive to performance, two implementation ways for establishing mapping for human-computer interaction in the Android operating system are mainly described below:

a starting stage: when the application program is detected to start timing, the virtual machine is informed to record all static classes for initialization in the process. The time or the number can be customized according to the bearing capacity of the system resources, for example, 2G memory system is specified to collect for 2 seconds, and generally, the more sufficient the memory resources are, the more the time can be collected. And when the acquisition time is over, informing the virtual machine to stop recording the initialized static classes, deriving all the initialized static classes from the virtual machine, and defining the subset as a 'starting class subset'.

An application execution phase: when a user clicks an open interface, the Android system monitors the newly opened Activity interface, informs the virtual machine to record all the initialized static classes in the process, informs the virtual machine to stop recording the initialized static classes after the Activity interface is started, derives all the initialized static classes from the virtual machine, and defines the subset as an application execution class subset.

After learning is completed, a class list file of an initialization phase corresponding to a different execution phase of the application program is generated.

3. Application store/cloud server

Since the subset and class mapping relation is irrelevant to the operating system platform and only relevant to the application program, the generated class list file can be uploaded to an application store or a cloud server. When other terminal equipment uses the corresponding application program, the application program can be directly downloaded from the server.

4. Asynchronous loader

The static class used for loading and initializing the stage in an asynchronous mode at the corresponding stage of the application program can fully utilize the multi-core CPU capability of the current terminal equipment and improve the running performance of the application program.

The asynchronous loader can be realized in an Android operating system, downloads class mapping results from an application store or a cloud server, compares the class mapping results with the class mapping results after the Framework layer monitors the activity of an application program, inquires a class subset which corresponds to the current activity and needs to be initialized, starts a new thread, calls an ART virtual machine reflection interface, and initializes the classes in advance in parallel.

It should be noted that, although the embodiments of the present application take the Android system and the JAVA language as examples, a solution to class initialization optimization is implemented, the present application is substantially an initialization optimization method for all object-oriented and cross-platform language program classes. Therefore, in an application scene, the application is not only directed to an Android operating system and a JAVA programming language, but also can be deployed by similar operating systems, object-oriented languages and cross-platform languages, so that the running performance of the application program is improved.

In addition, it should be understood that, the sequence numbers of the steps in the foregoing embodiments do not imply an execution sequence, and the execution sequence of each process should be determined by its function and inherent logic, and should not constitute any limitation to the implementation process of the embodiments of the present application.

Fig. 15 is a block diagram illustrating an application running apparatus according to an embodiment of the present application, which may be applied to a terminal device. For convenience of explanation, only portions related to the embodiments of the present application are shown.

Referring to fig. 15, the application running apparatus may specifically include the following modules:

an obtaining module 1501, configured to obtain a class list file corresponding to an application program when it is detected that the application program is started;

an identifying module 1502 for identifying a target class in the class list file;

the initialization module 1503 is configured to start a target thread and initialize the target class with the target thread.

In this embodiment, the apparatus may further include the following modules:

the static class identification module is used for acquiring a source code of the application program and identifying a static class in the source code;

and the class list file generating module is used for generating a class list file corresponding to the application program based on the static class.

In this embodiment of the present application, the static class identification module may specifically include the following sub-modules:

the program package obtaining submodule is used for obtaining the program package of the application program;

the program package analysis submodule is used for analyzing the program package to obtain the byte codes of the application program;

the byte code decompilation submodule is used for decompilating the byte code into a source code.

In this embodiment of the present application, the static class identification module may further include the following sub-modules:

the class analysis submodule is used for analyzing each class in the source code;

the system comprises an initial static class identification submodule and a static class identification submodule, wherein the initial static class identification submodule is used for identifying a class as an initial static class if a source code corresponding to the class comprises a variable marked by a preset character and a code segment and an initialization code corresponding to the class only comprises a constant;

the calling relation detection submodule is used for detecting whether the initialization code of the target initial static class has a calling relation with other classes or not, and the target initial static class is any one of the initial static classes;

the static class identification submodule is used for identifying the target initial static class as a static class if the initialization code of the target initial static class does not have a calling relationship with other classes; if the initialization code of the target initial static class has a calling relationship with other classes, judging whether the other classes having the calling relationship are initial static classes, if so, identifying the target initial static class as a static class, otherwise, identifying the target initial static class as a non-static class.

In this embodiment of the present application, the class list file generating module may specifically include the following sub-modules:

the mapping relation establishing submodule is used for determining the initialization stage of each static class and establishing the mapping relation between the class name of each static class and the corresponding initialization stage;

and the class list file generation submodule is used for generating a class list file corresponding to the application program according to the mapping relation.

In this embodiment of the present application, the mapping relationship establishing sub-module may specifically include the following units:

the first static class identification unit is used for recording a first static class which executes initialization operation within a preset time period from the start of the application program when the application program is detected to be started, and determining the initialization stage of the first static class as a starting stage;

and the second static class identification unit is used for recording a second static class for executing initialization operation in a time period from the start of the interface to the completion of the start of the interface when any interface of the application program is detected to be started, and determining that the initialization stage of the second static class is an application execution stage.

In this embodiment, the apparatus may further include the following modules:

and the class list file uploading module is used for uploading the class list file to a server.

In this embodiment, the identification module 1502 may specifically include the following sub-modules:

and the first static class identification submodule is used for identifying a first static class in the class list file.

In this embodiment of the application, the first static class may include a plurality of classes, and the initialization module 1503 may specifically include the following sub-modules:

the target thread starting submodule is used for starting a plurality of target threads and determining a first static class corresponding to each target thread;

and the first static class initialization submodule is used for initializing the corresponding first static class in parallel by adopting each target thread.

In this embodiment of the application, the initialization module 1503 may further include the following sub-modules:

the second static type identification submodule is used for identifying a second static type in the type list file when any interface of the application program is detected to be started;

and the second static class initialization submodule is used for starting a new target thread and initializing the second static class by adopting the new target thread.

By identifying classes which can be initialized in advance in the program, the method can generate the instruction which can be directly executed by the operating system more quickly without recompiling the application program in a designated compiler, and the application program code does not need to be compiled into a machine code file, so that the repeated occupation of the disk space is reduced, all classes which accord with the initialization condition in advance can obtain corresponding performance optimization benefits during initialization, and the method is favorable for improving the running performance of the application program.

Fig. 16 is a block diagram showing a structure of a class list file generation apparatus according to an embodiment of the present application, corresponding to the class list file generation method according to the foregoing embodiment. For convenience of explanation, only portions related to the embodiments of the present application are shown.

Referring to fig. 16, the apparatus for generating the category list file may specifically include the following modules:

an obtaining module 1601, configured to obtain a source code of an application;

an identifying module 1602, configured to identify a static class in the source code;

a generating module 1603, configured to generate a class list file corresponding to the application program based on the static class.

In this embodiment, the apparatus may further include the following modules:

and the uploading module is used for uploading the class list file to a server, and the server is used for sending the class list file to the terminal equipment when the terminal equipment installs the application program.

For the apparatus embodiment, since it is substantially similar to the method embodiment, it is described relatively simply, and reference may be made to the description of the method embodiment section for relevant points.

Fig. 17 is a schematic structural diagram of a terminal device according to an embodiment of the present application. As shown in fig. 17, the terminal apparatus 1700 of this embodiment includes: at least one processor 1710 (only one is shown in fig. 17), a memory 1720, and a computer program 1721 stored in the memory 1720 and executable on the at least one processor 1710, wherein the processor 1710, when executing the computer program 1721, implements steps in various embodiments of the application running method, such as steps S801 to S803 shown in fig. 8. Alternatively, the processor 1710 executes the computer program 1721 to realize the functions of the modules in the device embodiments, such as the modules 1501 to 1503 shown in fig. 15.

Illustratively, the computer program 1721 may be partitioned into one or more modules that are stored in the memory 1720 and executed by the processor 1710 to complete the present application. The one or more modules may be a series of computer program instruction segments capable of performing specific functions, which may be used to describe the execution of the computer program 1721 in the terminal device 1700. For example, the computer program 1721 may be divided into an acquisition module, an identification module, and an initialization module), and the specific functions of each module are as follows:

The terminal device 1700 may be a computing device such as a desktop computer, a notebook, a palm computer, and a cloud server. The terminal device 1700 may include, but is not limited to, a processor 1710, a memory 1720. Those skilled in the art will appreciate that fig. 17 is only one example of a terminal device 1700 and does not constitute a limitation of terminal device 1700 and may include more or less components than those shown, or some components may be combined, or different components, for example, terminal device 1700 may also include input-output devices, network access devices, buses, etc.

The Processor 1710 may be a Central Processing Unit (CPU), other general purpose Processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA) or other Programmable logic device, discrete Gate or transistor logic device, discrete hardware component, or the like. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like.

The storage 1720 may be an internal storage unit of the terminal device 1700, such as a hard disk or a memory of the terminal device 1700. The memory 1720 may also be an external storage device of the terminal device 1700, such as a plug-in hard disk, a Smart Media Card (SMC), a Secure Digital (SD) Card, a Flash memory Card (Flash Card), and the like provided on the terminal device 1700. Further, the memory 1720 may also include both an internal storage unit and an external storage device of the terminal device 1700. The memory 1720 is used for storing the computer program 1721 and other programs and data required by the terminal device 1700. The memory 1720 may also be used to temporarily store data that has been output or is to be output.

It will be apparent to those skilled in the art that, for convenience and brevity of description, only the above-mentioned division of the functional units and modules is illustrated, and in practical applications, the above-mentioned function distribution may be performed by different functional units and modules according to needs, that is, the internal structure of the application program running device is divided into different functional units or modules to perform all or part of the above-mentioned functions. Each functional unit and module in the embodiments may be integrated in one processing unit, or each unit may exist alone physically, or two or more units and modules are integrated in one unit, and the integrated units and modules may be implemented in a form of hardware, or in a form of software functional units. In addition, specific names of the functional units and modules are only for convenience of distinguishing from each other, and are not used for limiting the protection scope of the present application. The specific working processes of the units and modules in the system may refer to the corresponding processes in the foregoing method embodiments, and are not described herein again.

In the above embodiments, the descriptions of the respective embodiments have respective emphasis, and reference may be made to the related descriptions of other embodiments for parts that are not described or illustrated in a certain embodiment.

Those of ordinary skill in the art would appreciate that the various illustrative elements, modules, and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the implementation. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

The units and modules described as separate parts may or may not be physically separate, and parts displayed as units and modules may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.

The integrated units, modules, if implemented as software functional units and sold or used as separate products, may be stored in a computer readable storage medium. Based on such understanding, all or part of the processes in the application running method and the class list file generation method according to the embodiments of the present application may be implemented by a computer program instructing related hardware, where the computer program may be stored in a computer readable storage medium, and when the computer program is executed by a processor, the steps of the application running method and the class list file generation method according to the embodiments of the present application may be implemented. Wherein the computer program comprises computer program code, which may be in the form of source code, object code, an executable file or some intermediate form, etc. The computer readable medium may include at least: any entity or apparatus capable of carrying computer program code to a terminal device, recording medium, computer Memory, Read-Only Memory (ROM), Random-Access Memory (RAM), electrical carrier wave signals, telecommunications signals, and software distribution medium. Such as a usb-disk, a removable hard disk, a magnetic or optical disk, etc. In some jurisdictions, computer-readable media may not be electrical carrier signals and telecommunication signals in accordance with legislative and proprietary practices.

The above-mentioned embodiments are only used for illustrating the technical solutions of the present application, and not for limiting the same. Although the present application has been described in detail with reference to the foregoing embodiments, it should be understood by those of ordinary skill in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some technical features may be equivalently replaced; such modifications and substitutions do not substantially depart from the spirit and scope of the embodiments of the present application and are intended to be included within the scope of the present application.

Claims

1. An application program running method, comprising:

identifying a target class in the class list file;

2. The method according to claim 1, further comprising, before said obtaining the class list file corresponding to the application program:

acquiring a source code of the application program, and identifying a static class in the source code;

3. The method of claim 2, wherein obtaining the source code of the application comprises:

acquiring a program package of the application program;

analyzing the program package to obtain the byte code of the application program;

the bytecode is reverse compiled into source code.

4. The method of claim 2 or 3, wherein the identifying the static class in the source code comprises:

analyzing each class in the source code;

if the source code corresponding to a certain class comprises variables and code segments marked by preset characters, and the initialization code corresponding to the certain class does not comprise other task execution logic, identifying the certain class as an initial static class, wherein the other task execution logic is the variables and the code segments not marked by the preset characters;

detecting whether an initialization code of a target initial static class has a calling relationship with other classes, wherein the target initial static class is any one of the initial static classes, and the other classes are classes of all the classes except the certain class;

if the initialization code of the target initial static class does not have a calling relationship with other classes, identifying the target initial static class as a static class;

if the initialization code of the target initial static class has a calling relationship with other classes, judging whether the other classes having the calling relationship are initial static classes, if so, identifying the target initial static class as a static class, otherwise, identifying the target initial static class as a non-static class.

5. The method of claim 2, wherein generating a class list file corresponding to the application based on the static class comprises:

determining an initialization stage of each static class, and establishing a mapping relation between the class name of each static class and the corresponding initialization stage;

and generating a class list file corresponding to the application program according to the mapping relation.

6. The method of claim 5, wherein determining the initialization phase for each static class comprises:

when the application program is detected to be started, recording a first static class which executes initialization operation within a preset time period from the start of the application program, and determining the initialization stage of the first static class as a starting stage;

when any interface of the application program is detected to be started, recording a second static class for executing initialization operation in a time period from the start of the interface to the completion of the interface, and determining that an initialization stage of the second static class is an application execution stage.

7. The method of claim 2, 5 or 6, further comprising:

and uploading the class list file to a server.

8. The method of claim 6, wherein identifying the target class in the class list file comprises:

a first static class in the class list file is identified.

9. The method of claim 8, wherein the first static class comprises a plurality of classes, and wherein starting a target thread and initializing the target class with the target thread comprises:

starting a plurality of target threads, and determining a first static class corresponding to each target thread;

and initializing the corresponding first static class in parallel by adopting each target thread.

10. The method of claim 8, further comprising:

when any interface of the application program is detected to be started, identifying a second static class in the class list file;

and starting a new target thread, and initializing the second static class by adopting the new target thread.

11. A method for generating a category list file, comprising:

acquiring a source code of an application program;

identifying a static class in the source code;

12. The method of claim 11, further comprising:

and uploading the class list file to a server, wherein the server is used for sending the class list file to the terminal equipment when the terminal equipment installs the application program.

13. An application execution apparatus, comprising:

14. A terminal device comprising a memory, a processor and a computer program stored in the memory and executable on the processor, wherein the processor implements the application execution method according to any one of claims 1 to 10 when executing the computer program.

15. A computer-readable storage medium, in which a computer program is stored, which, when being executed by a processor, implements the application program execution method according to any one of claims 1 to 10.