CN112099880A - Scenario-driven application reduction method and system - Google Patents

Abstract

The embodiment of the application provides a method and a system for reducing a scene-driven application program, and belongs to the field of computers. The method comprises the following steps: acquiring stack information in an APP starting process and an API calling process to form a stack information file; analyzing the stack information file to obtain a class list, a resource list and a shared library list; taking the class list, the resource list and the shared library list as first information; analyzing the APK file to acquire second information in the APK file; comparing the second information in the APK file with the first information in the stack information file, and removing the first information from the second information in the APK file to obtain a reduction set; and removing the reduction set from the second information in the APK file to generate a new APK file. By using the method provided by the application, the original APK can be reduced to obtain a new APK so as to reduce the volume of the APK, and the APP starting speed is faster after the APK is installed.

Description

Scenario-driven application reduction method and system

technical field

The embodiments of the present application relate to the field of computer technologies, and in particular, to a scene-driven application program reduction method and system.

Background technique

In the era of mobile Internet, with the popularization of smart phones and the development of wireless networks, mobile applications have become the main way for people to access the mobile Internet.

In the prior art, after the APP is started on the terminal, when the Android application on the terminal calls the API interface, the entire APK will be loaded, and the APK is the Android installation package.

In fact, calling the API interface only requires the support of a small part of the code and resources in the APK. Loading the entire APK takes up a large amount of storage resources, and also slows down the startup speed of the APP.

SUMMARY OF THE INVENTION

The embodiments of the present application provide a scene-driven application program reduction method and system, which aims to solve the problems that the APK occupies a large amount of storage resources and the APP startup speed is slow.

A first aspect of the embodiments of the present application is to provide a scene-driven application program reduction method, the method comprising:

Acquire the stack information in the APP startup process and the API calling process, and form a stack information file, wherein the stack information file includes method parameters and return values;

The return value in the stack information file is parsed to obtain a class list; the method parameters in the stack information file are parsed to obtain a resource list and a shared library list; the class list, the resource list and all The shared library list is used as the first information;

The APK file is analyzed to obtain second information in the APK file, wherein the second information includes classes, resources and shared libraries;

The second information in the APK file is compared with the first information in the stack information file, and the first information that appears is removed from the second information in the APK file to obtain a reduction set;

The reduction set is eliminated from the second information in the APK file to generate a new APK file.

Optionally, obtain the stack information in the APP startup process and the API calling process to form a stack information file, which specifically includes:

Based on dynamic analysis technology and/or static analysis technology, the running stage of the Android application is divided into multiple sub-stages, and the stack information in the APP startup process and the API calling process is obtained by means of molecular stages, Wherein, the sub-stage includes at least the APP startup stage and the API calling stage;

Based on dynamic analysis technology and/or static analysis technology, the information generated by the Android application is divided into multiple sub-information, and the information between the APP startup process and the API calling process is obtained by separately acquiring multiple sub-information. stack information, wherein the stack information includes multiple sub-information;

Based on the dynamic analysis technology and/or the static analysis technology, the information generated by the Android application is marked into a concern class and a non-concerned class, and the APP startup process and the API are obtained through the concerned class or the non-concerned class. Stack information during the calling process.

Optionally, the APK file is obtained through the following steps:

The source code in the Android application is compiled by the Java compiler to generate multiple class files;

Compile the resource file in the Android application to generate a compiled resource file, wherein the resource file includes several resources and a shared library;

Dex files are generated by multiple class files through the dx tool, wherein the Dex files include several classes and dependent classes related to several classes;

The compiled resource file and the Dex file are packaged and compressed to generate an APK file.

Optionally, also include:

According to each class in the class list, query the dependent class related to each class in the Dex file;

The dependent classes related to each class are corresponding to each class, and stored in the class list.

Optionally, the reduction set is removed from the second information in the APK file to generate a new APK file, which specifically includes:

For the resource and the shared library, delete the resource and the shared library that appear in the reduction set, and generate a new resource file;

For the class, read the class in the Dex file, delete the class that appears in the reduction set, and generate a new Dex file;

The new APK file is generated according to the new Dex file and the new resource file.

Optionally, also include:

Install the new APK and the Dex file corresponding to the APK on the terminal to generate an APP;

Start the APP, and the terminal detects and loads the Dex file corresponding to the APK to expose the API interface;

Call the API interface to obtain the call result;

According to the call result, it is judged whether the new APK can support the normal call of the API interface. If it can be called normally, the reduction work is ended; if it cannot be called normally, the Android log is analyzed to find the missing information. The Android log described above is generated after launching the APP, and the missing information includes classes, resources and shared libraries;

According to the missing information, adjust the original reduction set to obtain a new reduction set;

According to the new reduction set, the above steps are repeated for testing until the new APK can support the normal invocation of the API interface.

Optionally, according to the missing information, adjusting the original reduction set to obtain a new reduction set, further comprising:

annotating the missing information in the original reduction set;

When updating the original reduction set, the missing information that is annotated is ignored.

Optionally, analyze Android logs for missing information, including:

Each application package name in the Android application program is added with the process ID mark when the corresponding application package is started; wherein, there is a mapping relationship between each log entry in the Android log and each process ID mark;

Filter out the target log entry from the respective log entries according to the process ID identifier;

According to the target log entry, the missing information is matched from the reduced set, including:

According to the target log entry, the missing information is matched from the reduction set, which specifically includes:

Under the target log entry, the missing information is matched through a regular expression;

If the missing information cannot be matched by the regular expression, the reduction set is searched by the binary method to determine the missing information.

Optionally, import the repick list into the terminal;

The information in the repick list is retained, wherein the repick list at least includes information of classes, resources and shared libraries.

A second aspect of the embodiments of the present application is to provide a scenario-driven application program reduction system, including:

The stack information acquisition module acquires the stack information in the APP startup process and the API calling process, and forms a stack information file, wherein the stack information file includes method parameters and return values;

The stack information parsing module parses the return value in the stack information file to obtain a class list; parses the method parameters in the stack information file to obtain a resource list and a shared library list; The resource list and the shared library list are used as the first information;

an APK file parsing module, analyzes the APK file, and obtains second information in the APK file, wherein the second information includes classes, resources and shared libraries;

The reduction set generation module compares the second information in the APK file with the first information in the stack information file, removes the first information that appears from the second information in the APK file, and obtains approximately minus set;

An APK file generation module, which removes the reduction set from the second information in the APK file, and generates a new APK file.

By adopting the API-driven Android application reduction method and system provided by the present application, the first information generated by the APP startup process and the API calling process and the second information generated by the entire APK file can be automatically obtained, and the first information can be combined with the second information generated by the entire APK file. The second information is reduced to obtain a reduction set, and then the second information and the reduction set are reduced to obtain necessary information required for calling the API interface, and a new APK is generated by using this part of the necessary information. In the new APK, unnecessary information when calling the API interface is deleted, thereby saving storage resources. In addition, due to the deletion of unnecessary information, the occupied volume of the entire APK is smaller, thereby speeding up the APP startup speed.

Description of drawings

In order to illustrate the technical solutions of the embodiments of the present application more clearly, the following briefly introduces the drawings that are used in the description of the embodiments of the present application. Obviously, the drawings in the following description are only some embodiments of the present application. , for those of ordinary skill in the art, other drawings can also be obtained from these drawings without creative labor.

1 is a flow chart of steps of a reduction method proposed by an embodiment of the present application;

Fig. 2 is a flow chart of the steps of generating an APK file proposed by an embodiment of the present application;

FIG. 3 is a flow chart of steps for culling a reduction set proposed by an embodiment of the present application;

4 is a schematic diagram of a specific APK reduction process proposed by an embodiment of the present application;

5 is a flowchart of steps for parsing a stack information file proposed by an embodiment of the present application;

6 is a flowchart of steps of an API-driven Android application reduction tool proposed by an embodiment of the present application;

7 is a flowchart of an API-driven Android application reduction tool proposed by an embodiment of the present application;

8 is a flowchart of steps for searching for missing information proposed by an embodiment of the present application;

FIG. 9 is a scene-driven application program reduction system proposed by another embodiment of the present application.

Detailed ways

The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative work fall within the protection scope of the present application.

Start the APP on the terminal. When the Android application on the terminal calls the API interface, the entire APK will be loaded. In fact, calling the API interface only requires the support of a small part of the code and resources in the APK. Loading the entire APK takes up a large amount of storage resources, and also slows down the startup speed of the APP.

During the research, the applicant found that in order to obtain the APK resources required by the API interface, it is not enough to only study the calling process of the API interface, because many global objects will be involved in the API calling process, and The construction and modification of these global objects are not only during the API call process, but also during the APP startup process, which increases the difficulty of analysis.

In addition, in order to obtain the APK resources required by the API interface in the entire APK, if the "reserved set" is used, that is, the APK resources required by the API interface are reserved, which will make it impossible to locate the missing information when the API interface call fails. The reason is: if the "reserved set" is used as the new APK, the missing information when the API interface call fails will be queried during the system test, and the missing information will be mixed into the "reserved set", so that the missing information cannot be detected. information to locate.

To this end, the embodiment of the present application proposes to obtain the second information generated by the entire APK file, convert the stack information generated by the APP startup process and the API calling process, to form the first information, and compare the first information with the second information. Reduction is performed to obtain a reduction set, and then the second information is reduced with the reduction set to obtain the necessary information required for calling the API interface, and a new APK is generated by using this part of the necessary information.

On the one hand, this application not only considers the information generated by the calling process of the API interface, but also considers the information generated by the APP startup process, and uses the information of the two as the first information to be reduced, so as to consider all global objects; On the one hand, this application adopts "reduced set" instead of "reserved set", which can locate the missing information. When performing a system test, the program will annotate the missing information in the reduction set, so that the system will automatically ignore the annotated missing information when eliminating the reduction set, and the missing information will not be eliminated. The information will be saved to the new APK to ensure the normal operation of the new APK. Since the missing information has been annotated in the reduction set, the missing information can be located.

Referring to FIG. 1, a flowchart of steps of a reduction method proposed by an embodiment of the present application is shown, which may specifically include the following steps:

Step S1: Acquire the stack information in the APP startup process and the API calling process, and form a stack information file, wherein the stack information file includes method parameters and return values.

In this embodiment, through the runtime heap model and the runtime stack model, the stack information in the APP startup process and the API calling process can be acquired, and the stack information can be recorded to form a stack information file.

Among them, the runtime heap model is used to reflect the data flow in the process of code execution, that is, the process of data creation, modification and recycling. It is a set of initial values of a set of memory data and heap modification activities that occur within a period of time; The time stack model is used to reflect the control flow in the process of code execution, that is, processes such as loops, branches, method calls, etc. It is a collection of activities that occur in one or more control flows over a period of time.

In step S1, the stack information in the APP startup process and the API calling process is acquired based on the dynamic analysis technology and/or the static analysis technology, and the stack information file is formed.

Wherein, when performing the reduction work in the present application, the method based on static analysis technology and/or dynamic analysis technology is used to obtain stack information, and the stack information includes resources such as codes, resources and shared libraries. Static analysis technology refers to scanning static code through syntax analysis, semantic analysis, control flow analysis, data flow analysis and other methods without running the program. It is mainly used for vulnerability detection, battery consumption optimization, and test case generation. , permission analysis, privacy data leakage detection, etc. Dynamic analysis technology refers to the observation of the running state of the program by running the program, including registers, memory, function calls, stack information, etc. In the field of application analysis, it is mainly used for code coverage detection, fault location, security Analysis, concurrency bug finding, program slicing, etc.

Static analysis technology is mainly aimed at APPs with large installation packages, such as game APPs. When using, there is no need to start the APP, starting from the API interface, systematically and comprehensively sort out the dependencies between the code, resources and shared libraries to determine the code, resources and shared libraries in the stack information that need to be retained.

The dynamic analysis technology is mainly aimed at APPs with small installation packages, such as non-game APPs. The APP startup time is in seconds, and the API call time is in milliseconds. When using, according to the stack information generated during the APP startup process and the API calling process, the code, resources and shared libraries involved can be directly determined, avoiding the sorting and analysis of complex dependencies in static analysis technology. In addition, the dynamic analysis technology retains the part of the code that is actually executed according to the actual situation of the code running, which can achieve a more thorough reduction for APPs with smaller installation packages.

In step S1, since the APP startup process and the API calling process will generate a large amount of stack information, if not restricted, all stack information will be captured, and the process of capturing the stack information will additionally occupy the CPU and memory resources of the terminal. The resources required for the running of the APP itself exceed the performance limit of the terminal, resulting in the APP freezing or even crashing during the running process. In addition, even if all the stack information is obtained after a long wait, it is difficult to perform the analysis in the subsequent step S2 because it occupies a large amount of memory.

In order to ensure the smooth progress of stack information acquisition, the stack information is obtained by stages, content and classification:

A1: Divide the running phase of the Android application into multiple sub-phases, and obtain the stack information in the APP startup process and the API calling process by means of molecular phases, wherein the sub-phases at least include all The APP startup phase and the API calling phase.

In A1, the running process of an Android application includes at least the APP startup phase and the API calling phase. When invoking stack information in stages, APP startup and API call can be regarded as two processes, and stack information is captured for the two processes respectively. For example, after opening the APP, a stack information file is generated, and then each API is called in turn to generate another stack information file. In this way, the two stack information files respectively record the stack information in the two processes of APP startup and API calling, instead of obtaining the stack information in the two processes at one time and putting them into one stack information file.

In addition, for apps with large size, slow startup process, and many startup add-ons, even if the stack information at startup is captured separately, it may not be able to proceed smoothly. At this time, the APP startup process is divided into multiple stages. For example, the first stage is before the user interface pops up the startup animation, the second stage is when the startup animation is running, and the third stage is after the startup animation ends.

A2: Divide the information generated by the Android application into multiple sub-information, and obtain the stack information in the APP startup process and the API calling process by separately acquiring multiple sub-information, wherein the stack information includes multiple sub-information .

In A2, the stack information is captured multiple times, and different information is captured each time to reduce the size of each stack information file. For example, for the first time, only sub-information such as methods, parameters, and return values used in the running process of the Android application (including the APP startup process and the API calling process) are captured, and the second time is to capture methods, field modification information, and exceptions. and other sub-information.

A3: Annotate the information generated by the Android application into a concerned class and a non-concerned class, and obtain the stack information in the APP startup process and the API calling process through the concerned class or the non-concerned class.

In A3, by configuring the stack information of concern and the stack information of non-concern, the continuous reduction of the grab set is realized, and the stack information file is finally limited to an acceptable range. For example, through preliminary stack information capture or manual analysis, it has been determined that 10 stack information will be retained, then when stack information capture is performed next time, these stack information can be configured as non-concerned classes, and the runtime heap model is the same as The runtime stack model will not record the calling process and instance objects related to it, which reduces the recording overhead. For another example, if you want to determine whether a small part of the stack information will be used, this part of the stack information can be configured as a class of interest. Since there are generally fewer classes of interest, the parsing process of the stack information can be accelerated.

Through the above three aspects, the stack information is obtained by stages, content and classification. By reducing the size of the stack information file, the APP is prevented from being stuck or even crashing during the running process; by dividing the stack information into Multiple contents are set as attention classes and non-attention classes, which further reduces the size of the stack information file, so that the analysis of the stack information in the subsequent step S2 can be realized.

Step S2: parse the return value in the stack information file to obtain a class list; parse the method parameters in the stack information file to obtain a resource list and a shared library list; The list and the shared library list are used as the first information.

In step S2, the stack information file is obtained through the runtime heap model and the runtime stack model. The stack information file at least includes information such as methods, parameters and return values, wherein the methods, parameters and return values include classes, resources and other information. and shared libraries and other stack information, this step focuses on parsing classes, resources and shared libraries from the stack information file to form the first information, specifically through the following three aspects for parsing, referring to Figure 5, Figure 5 shows the specific The flow chart of the steps to parse the stack information file:

B1: For classes, the class list is obtained by parsing the return value. For example, the return value field is in the form of type@address, where type indicates the type of the return value, and address is the memory address of the object. Intercept the field before @ to get the type of the return value. Finally, organize all the obtained types into a list of classes.

In B1, if you just save the class in the class list and delete all other dependent classes, the Android application will not work correctly. This is because there are complex dependencies between classes, and the stack record file only retains the calling relationship between classes, but does not retain other relationships, so errors will occur. At this time, the two relationships of inheritance relationship and realization relationship must be considered. For example, for a class A, assuming that it inherits the ancestor class B and implements the interface class C, when the program actually runs, the information of the ancestor class B and the interface class C will not be recorded, but if it is deleted, the Android application The program will cause an error because the ancestor class B or interface class C cannot be found.

In order to prevent the Android application from running correctly, it is necessary to iteratively query all ancestor classes and interface classes of each class from the Dex file according to the class list, and add the class after corresponding to the interface class and each class. list to prevent the program from failing to run.

B2: For resources, the resource list is obtained by parsing according to the method parameters.

Among them, because the runtime heap model and the runtime stack model only support the recording of stack information, and cannot directly obtain the list of resources actually used by the Android application when it is running, it is necessary to study the method of loading resources in the Android application. The parameters in the method of the resource file to get the resource list.

Based on this, in step B2, the resource list is obtained through the resources in the res directory in the APK, the resources in the asset directory in the APK, and the newly added Resources class. Among them, the resources in the res directory provide a series of methods for accessing resources. The resource files in the res directory will be compiled and resource IDs will be generated; the resources in the asset directory are not compiled by the Java compiler, but are native to the user. Resources, the resources in the asset directory provide an interface for reading native resources; the new Resources class replaces some of the functions of the original Resources class, and also provides methods for obtaining some resources. Based on the parameters in the above three methods, the resource list can be obtained.

Among the resources in the res directory above, when developers use a resource in the res directory, they generally use its ID instead of the resource file name, so the Java compiler will give the resource file name an id when compiling. . However, the terminal can only identify the resource file name, but cannot identify its ID. Therefore, for the resources in the res directory, a decompiler is set up in the program. Through this decompiler, the corresponding relationship between the resource ID and the resource file name can be obtained, and a series of IDs can be converted into a list of resources that are actually used. , so that the terminal can obtain the resource list through the decompiler. The resource list includes several resource file names.

B3: For shared libraries, the shared library list is obtained by parsing according to the method parameters.

Among them, the shared library is similar to the resource list, and cannot be directly obtained through the runtime heap model and the runtime stack model. The shared library list is obtained by obtaining the parameters in the method of loading the lib directory.

The first information obtained through the three aspects of B1, B2 and B3 may contain duplicate information. Therefore, before step S4 is performed, that is, before the reduction set is determined, the information obtained from these three aspects needs to be deduplicated respectively. to avoid duplication of information.

The deduplication method is as follows: Deduplication is performed after obtaining the class list for the B1 aspect to obtain a non-duplicated class list; Deduplication is performed after the resource list is obtained for the B2 side to obtain a non-duplicated resource list; A shared library list is obtained for the B3 aspect and then performed. Remove duplicates to get a list of non-duplicated shared libraries. Finally, the non-duplicated class list, resource list and shared library list are used as the first information to perform the reduction process in step S4.

S3: Analyze the APK file to obtain second information in the APK file, where the second information includes classes, resources and shared libraries.

In step S3, according to the format of the APK file, extract the list of all resource files under the assets and res files, the list of all shared library files under the lib file, and the list of all classes in each Dex file, according to the class list, resource list The second information is formed with the shared library list. The specific parsing process has been explained correspondingly in the three aspects B1 to B3 in S2, and will not be repeated here.

The APK file includes three states: before compilation, after compilation and after installation, considering code reduction, in step S3, a compiled APK file is used, and the APK file includes code, resources and shared libraries.

In step S3, on the one hand, it is considered that the code in the stack information in step S1 is obfuscated and reinforced by the processing tool, so that it is different from the source code before compilation. If the source code before compilation of the APK file is reduced, the obfuscated and reinforced code in the stack information needs to be remapped to the source code before compilation, which increases the workload and difficulty. On the other hand, considering that the APP with a small installation package is analyzed based on dynamic analysis technology, only the code used in the actual execution will be retained, and the code that has not been executed will be deleted. For example, in a select statement, there are two branches A and B, where the A branch uses class a, and the B branch uses class b. After using dynamic analysis technology, it is found that the B branch will not be executed, so the class b will be deleted. If the source code before compilation is deleted, when compiling, the Java compiler will fail to compile because it cannot find the code of class b. On the contrary, if the compiled Dex bytecode is deleted, it will not go through the compilation process again, avoiding the problem of compilation failure. Therefore, considering the above two aspects, in step S3, the compiled APK file is used.

Wherein, the compiled APK file is obtained through the following steps, and with reference to FIG. 2, FIG. 2 shows a flowchart of the steps of generating an APK file proposed by an embodiment of the present application:

S301: Compile the source code in the Android application through the Java compiler to generate multiple class files.

Among them, the function of the JAVA compiler is to compile the JAVA source program into an intermediate code bytecode file; the class file contains only one class, including operation instructions for the stack.

S302: Compile the resource file in the Android application to generate a compiled resource file, wherein the resource file includes several resources and shared libraries.

S303: Dex files are generated by multiple class files through the dx tool, wherein the Dex files include several classes and dependent classes related to several classes.

Among them, the dx tool is d8, a command-line tool that can support the use of JAVA8 language functions in the application code, and can convert class files into Dex files; in Dex files, compared with class files, there is no stack operation. Instructions, just operate on registers, and contain multiple classes with larger instruction sets and longer instructions.

S304: package and compress the compiled resource file and the Dex file to generate an APK file.

Among them, since the compiled resource file contains resources and shared libraries, and the Dex file contains multiple classes, after being packaged and compressed, a compiled APK file can be generated.

In steps S1 to S3, the first information generated by the APP startup process and the API calling process is obtained; and the second information in the APK file, in the subsequent step S4, the first information and the second information need to be reduced, wherein Both the first information and the second information include code, resources and shared libraries. When reducing, the problem of reduction granularity will be involved. In this application, classes are used as the basic unit of code, and resource files are used as the basic unit of resources. The shared library file is used as the basic unit of the shared library to reduce the first information and the second information.

For code, a code package, class, method or statement can be used as the basic unit, and when reducing in this application, the class is used as the basic unit of the code. The reason is: if the code package is used as the basic unit of reduction, the Causes a lot of redundancy, which violates the principle of the reduction program in this application; if methods and statements are used as the basic units of code reduction, then when obtaining the stack information generated during the process of APP startup and API calling, the complete method call must be obtained. Information and statement execution information, and in the APK reduction stage in the subsequent steps S4 and S5, the bytecode of the method and statement must be finely manipulated, which greatly increases the difficulty; while the Android application uses the Java language, and Java is a Object-oriented language, class is its basic unit, so using class as the basic unit of code can better adapt to Android applications.

For resources, the resource type, resource file and resource file content can be used as the basic units, and when reducing resources in this application, since a single resource file is often used as the basic unit when a resource is cited, a single resource file is used. as the base unit.

For the shared library, the shared library file or the code in the shared library file can be used as the basic unit. However, in the present application, since the shared library is loaded in a unit of a single shared library file, a single shared library file is used as the basic unit.

Step S4: compare the second information in the APK file with the first information in the stack information file, and remove the first information that appears from the second information in the APK file to obtain a reduction set.

Among them, when the reduction set is determined, the first information and the second information are directly subtracted to obtain the final reduction set. The reduction set means that the APP startup process and the API calling process do not need to be used, that is, they are not used. Used stack information.

Step S5: remove the reduction set from the second information in the APK file to generate a new APK file.

Wherein, when generating a new APK, since both the first information and the second information include classes, resources and shared libraries, the new APK is generated through the following three steps, referring to FIG. 3, which shows an implementation The flow chart of the steps for culling and reducing the set proposed in the example:

S501: For the resource and the shared library, delete the resource and the shared library that appear in the reduction set, and generate a new resource file.

Among them, the resources are stored in the assets directory, and the shared library is stored in the lib directory. During the specific operation, the unused resources in the assets directory are directly deleted; and the unused shared libraries in the collection are reduced from the lib directory. Just delete it.

S502: For the class, read the class in the Dex file, delete the appearing class in the reduction set, and generate a new Dex file.

Among them, in the process of generating a new Dex file, the jar package of the Dex2jar tool is used to read the Dex file, delete irrelevant classes therein, and then regenerate a new Dex file.

The Dex2jar tool refers to an analysis tool for Dex files, which can easily convert Dex files into jar files for subsequent analysis and development, but the purpose in step S502 is to modify the Dex file, that is, delete the reduction set Therefore, the Dex2jar tool is not used directly, but the Dex2jar jar package is used, and the existing classes and methods for analyzing and modifying the Dex file in the jar package are used to perform related operations.

S503: Generate the new APK file according to the new Dex file and the new resource file.

Referring to FIG. 4, FIG. 4 shows a schematic diagram of a specific APK reduction process. Among them, when generating a new APK file, directly delete unused resources in the res, assets, and lib directories, and delete the classes under the dex file to regenerate a new Dex file; in addition, during the APP startup process and API calls The process generates not only stack information, but also some other files, such as signature files, files containing the corresponding relationship between resource files and resource IDs; the signature files need to be checked and modified, and then re-signed after correction and put into the APK file; For the file containing the corresponding relationship between the resource file and the resource ID, you can directly copy it and keep it in the new APK file. And finally re-sign and package the new APK file, which completes the APK reduction.

After step S503, that is, after the new APK file is generated, in order to enable the new APK file to support the normal calling of the API, it is necessary to generate a new reflection class Dex file according to the new APK and the original code of the API, so as to support the API normal call.

In steps S501 to S503, since the number of shared libraries and resource files is relatively small compared to the class, and the volume of a single shared library file and a single resource file is relatively large, the shared library, resource, and class are in the order of Reducing the APK in turn can effectively and quickly reduce the size of the APK and speed up the reduction.

After the new APK file is generated through steps S1 to S5, if you want to add a new API, directly on the basis of the new APK, add the code, resources, and shared libraries that the new API depends on, and then the APK can be rebuilt. Reduce.

Through the scene-driven application program reduction method provided by the present application, the first information generated by the APP startup process and the API calling process and the second information generated by the entire APK file can be automatically obtained, and the first information and the second information can be automatically obtained. The reduction is performed to obtain a reduction set, and then the second information is reduced with the reduction set to obtain the necessary information required for calling the API interface, and a new APK is generated by using this part of the necessary information. In the new APK, unnecessary information when calling the API interface is deleted, thereby saving storage resources. In addition, due to the deletion of unnecessary information, the occupied volume of the entire APK is smaller, thereby speeding up the APP startup speed. Moreover, the present application is based on the idea of "reduced set" rather than "reserved set", so that missing information can be accurately located when a new APK is systematically tested.

The system testing of the new APK will be described in detail below.

In the above process, after launching the APP on the terminal, when the Android application on the terminal calls the API interface, the entire APK will be loaded, and the APK is the Android installation package. In fact, calling the API interface only requires the support of a small part of the code and resources in the APK, and loading the entire APK takes up a large amount of storage resources. Therefore, it is necessary to reduce the entire APK, and obtain a new APK according to the reduction set obtained after the reduction, so as to reduce the storage resources occupied by loading the APK.

However, during the applicant's research, the applicant found that the new APK obtained according to the reduction set often cannot run normally. In addition to the errors caused by the inaccuracy of the analysis process, the change of the code execution path is also an important reason. The change of the code execution path is based on the The following three reasons: 1. Changes in the external environment such as network and model; 2. Randomness in the code; 3. The code and resources are deleted. For the first aspect of changes in the external environment such as network and model, for example, when you can connect to the Internet, many apps will download advertisements from the Internet when they are launched, and display them on the startup page. If you cannot connect to the Internet, this will be skipped. a process. For another example, using different mobile phones to access the same version of the "Driving Test Collection" App, the Xiaomi mobile phone will display a startup animation, but the Nexus mobile phone will not. These changes in the external environment will cause the new APK to fail to run normally. Regarding the randomness in the code of the second aspect, in order to implement a specific function and complete a specific service, sometimes a certain randomness must be added to the code, which leads to a different execution path each time the code is run. For the third aspect, when the code and resources are deleted, the code and resources are deleted, and the code and resources are not reduced, the original APK is running normally, but the new APK, that is, the reduced APK will not retain these code and resources, it will not work correctly.

In order to ensure the normal operation of the new APK, the present application proposes an Android application program reduction tool, referring to FIG. 7 , which is mainly responsible for testing whether the App in the new APK can be started normally and whether each API can be called correctly. If it cannot be called normally, analyze the Android log to find out the reason for the call failure or missing information, readjust the reduction set, and perform APK reduction again. Iteratively perform the above steps until all API calls are successful. In this process, after the code path is changed, the corresponding call failure reason or missing information will be generated and saved to the Android log. By analyzing the Android log, the call failure reason or missing information can be found out. According to the call failure reason Or the missing information is adjusted to the reduction set, and the reduction set is removed from the APK file again to obtain a new APK. After repeated iterative testing, a normal running APK can be obtained.

Referring to FIG. 6 , a flowchart of steps of an Android application program reduction tool of the present invention is shown, which may specifically include the following steps:

S6: Install the new APK and the Dex file corresponding to the APK on the terminal to generate an APP.

In step S6, the APK is installed on the terminal, and the Dex file corresponding to the APK is placed in a designated folder of the terminal, thereby generating an APP.

Among them, the Dex file is used to expose the API interface described in step S1, and the Dex file does not have operation instructions for the stack, but only operates on registers, and the Dex file includes several categories.

Among them, the reduced APK, that is, the new APK is obtained through the following steps: first, compare the stack information generated during the running process of the Android application with the information in the APK file to obtain a reduced set, and then extract the information from the APK file. Eliminate the reduction set to form a new APK file. By reducing the size of the new APK file, it takes up less storage resources. The reduction set is the stack information that the API interface will not use, and the new APK file is the stack information that the API interface needs to use.

S7: Start the APP, and the terminal detects and loads the Dex file corresponding to the APK to expose the API interface.

Among them, after starting the APP, the terminal will call several API interfaces accordingly, but for the reduction tool in this application, it is impossible to know which API interface is used to implement the function. Taking Alipay as an example, Alipay includes multiple functions such as Didi Chuxing, Ele.me, and movie performances. Each function corresponds to an API interface. When a user clicks on Didi Chuxing, the system will retrieve the corresponding data from Didi Chuxing. API interface, but the reduction tool cannot know which API interface is used to realize the function of Didi Chuxing. Accordingly, it cannot know the reason why the API interface call fails. Therefore, in order for the reduction tool to know whether the API interface is used, the API interface needs to be exposed to know the reason why the API interface call fails.

Dex files are reflection class Dex files. Run the system through the Dex file and API interface, read the Dex file, load the Dex file into the reflection class loader, and combine the Android system class with the Android installation package to finally expose the API interface to the reduction tool, so that the reduction tool can The call result is known according to the information fed back by the API interface.

In addition, as explained in the subsequent step S9, a large amount of information will be generated after starting the APP, and the information will be saved in the Android log. In order to avoid the problems of slow transmission and difficult analysis caused by too many Android logs, the Android logs in the terminal system should be cleaned up before the APP is started.

S8: Call the API interface to obtain the call result.

The call result includes two cases: normal call or cannot be called normally, and the case where the call result cannot be called normally includes three cases: APK installation failure, API call failure and incorrect API call result.

S9: According to the invocation result, determine whether the new APK can support the normal invocation of the API interface, and if it can be invoked normally, end the reduction work; if it cannot be invoked normally, analyze the Android log to find the missing information, wherein , the Android log is generated after the APP is started, and the missing information includes classes, resources and shared libraries.

Among them, when the APP is started, a large amount of information is generated, and the information includes stack information, and the stack information includes classes, resources and shared libraries. A large amount of information generated when the APP starts is stored in the Android log. When the new APK cannot be called normally, analyze the Android log to find out the missing information or the reason for the call failure, and re-reduce the reduction set according to the missing information and the reason for the call failure. Adjustment.

When analyzing the Android log specifically, the analysis is performed based on the three situations in step S8. When the APK installation fails, it can be shown that the re-signature of the APK is invalid by analyzing the Android log. When the API call fails, you first need to analyze the information returned by the API interface. If the error type of the information returned by the API interface is DeadObject, it means that the APP has not been started correctly or has been killed, and the stack information cannot be provided for the API calling process. The global object of , then need to further analyze the Android log to find out the specific error information, the specific error information includes the lack of information such as classes, resources and shared libraries. If the API call result is incorrect, it can indicate that the resources of the terminal's local database have been deleted, resulting in an error in accessing the local database.

Because in the entire terminal, not only the process of one APP is running, but also the processes of other APPs may be running. When these APPs are running, information will be generated and saved in the Android log. Information generated by the target APP. In step S9, the Android log is analyzed to find missing information, which specifically includes the following steps, with reference to FIG. 8, which shows a flowchart of steps for finding missing information:

S901: To each application package name in the Android application program, add the process ID mark when the corresponding application package is started; wherein, there is a mapping relationship between each log entry in the Android log and each process ID mark.

The process ID identifier is a process identifier, an application package corresponds to a process ID identifier, and a process ID identifier is created corresponding to each application program opened in the terminal.

S902: Screen out the target log entry from the respective log entries according to the process ID.

Among them, it is stated in step S901 that each log entry in the Android log has a mapping relationship with several ID identifiers, that is, each application package can query the application package generation according to the mapping relationship between the ID identifier and the log entry. under which target log entry the information is located.

S903: Under the target log entry, use a regular expression to match missing information.

Among them, there are multiple levels of information under the target log entry. The format of these log information is relatively fixed. Therefore, the missing information can be located through regular expressions. For example, the missing classes or Resource Name.

S904: If the missing information cannot be matched by the regular expression, search the reduction set by the dichotomy method to determine the missing information.

Among them, for the missing information that cannot be located and analyzed by the program, that is, there is no call result and no error message. In order to automate the location of missing information, the missing information is located based on the dichotomy method. For example, first reduce the contents of the first half of the reduction set, if there is an error, you can locate the missing information in the first half of the reduction set; if there is no error, you can locate the missing information after the reduction set half. Continue to dichotomize until the missing class or resource is found. In the process of multiple iterations, a global bisection result can be generated, that is, if in the two adjacent iterations, the previous iteration has proved that deleting the first N classes will not cause errors, then the next iteration When an error occurs, the missing information must not be in the top N classes, thus reducing repeated computations.

In addition, in order to sort the reduced set before performing the bisection of the reduced set, to ensure the ordering of the reduced set.

S10: According to the missing information, adjust the original reduction set to obtain a new reduction set.

Wherein, as explained in step S8, the failure to call the API normally includes the following three situations: APK installation failure, API call failure and incorrect API call result. As explained in step S9, for the APK installation failure, it means that the re-signature of the APK is invalid; for the API call failure, it is judged that the APP has not been started correctly or has been killed, indicating the lack of classes, resources and shared libraries; If it is called normally, it means that the database resource is deleted.

Therefore, the reasons why the API cannot be called normally include: 1. The reason for the failure of the call, the re-signature of the APK is invalid; 2. The missing information, the lack of classes, resources and shared libraries, and the lack of database resources. Therefore, in step S10, the specific adjustment of the original reduction set includes the following three cases:

The re-signature of the APK is invalid. You need to check the signature process and adjust the APK's signature.

For the lack of classes, resources and shared libraries, the corresponding classes, resources and shared libraries are directly annotated from the reduction set.

When the database resource is deleted, the corresponding database resource is also directly annotated from the reduction set.

S11: According to the new reduction set, repeat the above steps to test until the new APK can support the normal calling of the API interface.

Among them, during specific iteration, since the APK and Dex files have been installed on the terminal, it is not necessary to reinstall the APK and Dex files for each iteration, and the iterative test can be performed directly by repeating steps S7 to S11.

In this embodiment, after the missing class or resource is found from the Android log, it is deleted from the reduction set, and the reduction is performed again. In order to facilitate subsequent iterations and developers' viewing, the new reduction set needs to be written to the original file. If the new reduction set is rewritten into the original file after each iteration, it will cause inefficiency. Therefore, in order to avoid the occurrence of inefficiency, this embodiment directly writes the final new reduction set after multiple iterations. The subtraction set is written to the original APK file.

However, after many iterations, the developer will not be able to know the missing classes, resource names and shared library names from the new reduced set, making it difficult to perform error analysis of the Android log. Therefore, in order to let the developer know the missing class, resource name and shared library name, in step S10, according to the missing information, adjust the original reduction set to obtain a new reduction set, which needs to be in the The missing information is annotated in the original reduction set; when updating the original reduction set, the annotated missing information is ignored.

Among them, when annotating missing information, such as annotating missing classes, resources or shared libraries, when the reduction set is removed from the information generated by the APK, that is, when the reduction set is updated, the system will automatically retain the annotated missing information. Instead of deleting it together with the reduction set, on the one hand, the missing information is preserved; on the other hand, because the missing information is annotated, it is convenient for developers to know the missing information.

In this embodiment, a repick list is also included. During the specific operation, the repick list is imported into the terminal; the information in the repick list is retained, wherein the repick list at least includes the information of classes, resources and shared libraries.

Among them, the repick list is to unconditionally retain the code packages, resource folders, etc. in the list. For example, when reducing an offline application, its local database needs to be preserved to support the offline function of the application. In one API call process, only one or several pieces of data in the database will be used, so all other data will be deleted. However, the API should support access to all data items in the local database, so by adding the folder path of the database resource in the repick list, the entire database resource can be preserved to support the offline functionality of the application. For another example, when reducing code, if it is found that the missing classes in several iterations belong to the same code package, the code package can be added to the repick list, and all the contents in it can be retained to save reduction time.

Through the API-driven Android application reduction tool of this application, after the code path is changed, the corresponding call failure reason or missing information will be generated and saved in the Android log. By analyzing the Android log, the cause of the call failure can be found out. Or missing information, adjust the reduction set according to the reason for the failure of the call or the missing information, and remove the reduction set from the APK file again to obtain a new APK. After repeated iterative testing, a normal running APK can be obtained.

Embodiment 2

Referring to Figure 9, a scene-driven application reduction system includes:

The stack information acquisition module acquires the stack information in the APP startup process and the API calling process, and forms a stack information file, wherein the stack information file includes method parameters and return values;

The stack information parsing module parses the return value in the stack information file to obtain a class list; parses the method parameters in the stack information file to obtain a resource list and a shared library list; The resource list and the shared library list are used as the first information;

an APK file parsing module, analyzes the APK file, and obtains second information in the APK file, wherein the second information includes classes, resources and shared libraries;

The reduction set generation module compares the second information in the APK file with the first information in the stack information file, removes the first information that appears from the second information in the APK file, and obtains approximately minus set;

An APK file generation module, which removes the reduction set from the second information in the APK file, and generates a new APK file.

The various embodiments in this specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments, and the same and similar parts between the various embodiments may be referred to each other.

Those skilled in the art should understand that the embodiments of the embodiments of the present application may be provided as methods, apparatuses, or computer program products. Accordingly, the embodiments of the present application may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, embodiments of the present application may take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein.

The embodiments of the present application are described with reference to the flowcharts and/or block diagrams of the methods, terminal devices (systems), and computer program products according to the embodiments of the present application. It will be understood that each process and/or block in the flowchart illustrations and/or block diagrams, and combinations of processes and/or blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to the processor of a general purpose computer, special purpose computer, embedded processor or other programmable data processing terminal equipment to produce a machine that causes the instructions to be executed by the processor of the computer or other programmable data processing terminal equipment Means are created for implementing the functions specified in the flow or flows of the flowcharts and/or the blocks or blocks of the block diagrams.

These computer program instructions may also be stored in a computer readable memory capable of directing a computer or other programmable data processing terminal equipment to operate in a particular manner, such that the instructions stored in the computer readable memory result in an article of manufacture comprising instruction means, the The instruction means implement the functions specified in the flow or flow of the flowcharts and/or the block or blocks of the block diagrams.

These computer program instructions can also be loaded on a computer or other programmable data processing terminal equipment, so that a series of operational steps are performed on the computer or other programmable terminal equipment to produce a computer-implemented process, thereby executing on the computer or other programmable terminal equipment The instructions executed on the above provide steps for implementing the functions specified in the flowchart or blocks and/or the block or blocks of the block diagrams.

Although the preferred embodiments of the embodiments of the present application have been described, those skilled in the art may make additional changes and modifications to these embodiments once the basic inventive concepts are known. Therefore, the appended claims are intended to be construed to include the preferred embodiments as well as all changes and modifications that fall within the scope of the embodiments of the present application.

Finally, it should also be noted that in this document, relational terms such as first and second are used only to distinguish one entity or operation from another, and do not necessarily require or imply these entities or there is any such actual relationship or sequence between operations. Moreover, the terms "comprising", "comprising" or any other variation thereof are intended to encompass non-exclusive inclusion such that a process, method, article or terminal device that includes a list of elements includes not only those elements, but also a non-exclusive list of elements. other elements, or also include elements inherent to such a process, method, article or terminal equipment. Without further limitation, an element defined by the phrase "comprises a..." does not preclude the presence of additional identical elements in the process, method, article, or terminal device that includes the element.

A scenario-driven application program reduction method and system provided by the present application has been described in detail above. The principles and implementations of the present application are described with specific examples in this paper. The descriptions of the above embodiments are only used for Help to understand the method of the present application and its core idea; meanwhile, for those of ordinary skill in the art, according to the idea of the present application, there will be changes in the specific implementation and application scope. In summary, the content of this specification It should not be construed as a limitation of this application.

Claims (10)

1. A scenario-driven application program reduction method, wherein the method comprises: Acquire the stack information in the APP startup process and the API calling process, and form a stack information file, wherein the stack information file includes method parameters and return values; The return value in the stack information file is parsed to obtain a class list; the method parameters in the stack information file are parsed to obtain a resource list and a shared library list; the class list, the resource list and all The shared library list is used as the first information; The APK file is analyzed to obtain second information in the APK file, wherein the second information includes classes, resources and shared libraries; The second information in the APK file is compared with the first information in the stack information file, and the first information that appears is removed from the second information in the APK file to obtain a reduction set; The reduction set is eliminated from the second information in the APK file to generate a new APK file. 2. The method according to claim 1, wherein the stack information in the APP startup process and the API calling process is obtained to form a stack information file, specifically comprising: Based on dynamic analysis technology and/or static analysis technology, the running stage of the Android application is divided into multiple sub-stages, and the stack information in the APP startup process and the API calling process is obtained by means of molecular stages, Wherein, the sub-stage includes at least the APP startup stage and the API calling stage; Based on dynamic analysis technology and/or static analysis technology, the information generated by the Android application is divided into multiple sub-information, and the information between the APP startup process and the API calling process is obtained by separately acquiring multiple sub-information. stack information, wherein the stack information includes multiple sub-information; Based on the dynamic analysis technology and/or the static analysis technology, the information generated by the Android application is marked into a concern class and a non-concerned class, and the APP startup process and the API are obtained through the concerned class or the non-concerned class. Stack information during the calling process. 3. method according to claim 1, is characterized in that, described APK file obtains by following steps: The source code in the Android application is compiled by the Java compiler to generate multiple class files; Compile the resource file in the Android application to generate a compiled resource file, wherein the resource file includes several resources and a shared library; Dex files are generated by multiple class files through the dx tool, wherein the Dex files include several classes and dependent classes related to several classes; The compiled resource file and the Dex file are packaged and compressed to generate an APK file. 4. The method of claim 3, further comprising: According to each class in the class list, query the dependent class related to each class in the Dex file; The dependent classes related to each class are corresponding to each class, and stored in the class list. 5. The method according to claim 1, characterized in that, from the second information in the APK file, the reduction set is removed to generate a new APK file, specifically comprising: For the resource and the shared library, delete the resource and the shared library that appear in the reduction set, and generate a new resource file; For the class, read the class in the Dex file, delete the class that appears in the reduction set, and generate a new Dex file; The new APK file is generated according to the new Dex file and the new resource file. 6. The method of claim 3, further comprising: Install the new APK and the Dex file corresponding to the APK on the terminal to generate an APP; Start the APP, and the terminal detects and loads the Dex file corresponding to the APK to expose the API interface; Call the API interface to obtain the call result; According to the call result, it is judged whether the new APK can support the normal call of the API interface. If it can be called normally, the reduction work is ended; if it cannot be called normally, the Android log is analyzed to find the missing information. The Android log described above is generated after launching the APP, and the missing information includes classes, resources and shared libraries; According to the missing information, adjust the original reduction set to obtain a new reduction set; According to the new reduction set, the above steps are repeated for testing until the new APK can support the normal invocation of the API interface. 7. The method according to claim 6, wherein, according to the missing information, adjusting the original reduction set to obtain a new reduction set, further comprising: annotating the missing information in the original reduction set; When updating the original reduction set, the missing information that is annotated is ignored. 8. method according to claim 7, is characterized in that, analyzes Android log, searches for missing information, specifically comprises: Each application package name in the Android application program is added with the process ID mark when the corresponding application package is started; wherein, there is a mapping relationship between each log entry in the Android log and each process ID mark; Filter out the target log entry from the respective log entries according to the process ID identifier; According to the target log entry, the missing information is matched from the reduced set, including: According to the target log entry, the missing information is matched from the reduction set, which specifically includes: Under the target log entry, the missing information is matched through a regular expression; If the missing information cannot be matched by the regular expression, the reduction set is searched by the binary method to determine the missing information. 9. The method according to claim 6, wherein the repick list is imported into the terminal; The information in the repick list is retained, wherein the repick list at least includes information of classes, resources and shared libraries. 10. A scenario-driven application program reduction system, comprising: The stack information acquisition module acquires the stack information in the APP startup process and the API calling process, and forms a stack information file, wherein the stack information file includes method parameters and return values; The stack information parsing module parses the return value in the stack information file to obtain a class list; parses the method parameters in the stack information file to obtain a resource list and a shared library list; The resource list and the shared library list are used as the first information; an APK file parsing module, analyzes the APK file, and obtains second information in the APK file, wherein the second information includes classes, resources and shared libraries; The reduction set generation module compares the second information in the APK file with the first information in the stack information file, removes the first information that appears from the second information in the APK file, and obtains approximately minus set; An APK file generation module, which removes the reduction set from the second information in the APK file, and generates a new APK file.

Images