CN112099880B

CN112099880B - Method and system for reducing application program driven by scene

Info

Publication number: CN112099880B
Application number: CN202010809489.2A
Authority: CN
Inventors: 黄罡; 马郓; 景翔; 崔磊
Original assignee: Peking University
Current assignee: Peking University
Priority date: 2020-08-12
Filing date: 2020-08-12
Publication date: 2021-07-30
Anticipated expiration: 2040-08-12
Also published as: CN112099880A

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

Method and system for reducing application program driven by scene

Technical Field

The embodiment of the application relates to the technical field of computers, in particular to a method and a system for reducing a scene-driven application program.

Background

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 mobile internet.

In the prior art, after an APP is started on a terminal, an Android application program on the terminal loads a whole APK when an API interface is called, and the APK is an Android installation package.

In fact, calling the API interface only needs the support of a small part of codes and resources in the APK, and loading the entire APK occupies a large storage resource and also slows down the APP start-up speed.

Disclosure of Invention

The embodiment of the application provides a method and a system for reducing an application program driven by a scene, and aims to solve the problems that an APK occupies a large storage resource and the APP starting speed is slow.

A first aspect of an embodiment of the present application provides a method for reducing a scene-driven application, where the method includes:

acquiring stack information in an APP starting process and an API calling process to form a stack information file, wherein the stack information file comprises method parameters and return values;

analyzing the return value in the stack information file to obtain a class list; analyzing the method parameters in the stack information file to obtain a resource list and a shared library list; taking the class list, the resource list and the shared library list as first information;

analyzing an APK file to obtain second information in the APK file, wherein the second information comprises classes, resources and a shared library;

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.

Optionally, obtaining stack information in an APP start process and an API call process to form a stack information file, which specifically includes:

dividing the operation stage of the Android application program into a plurality of sub-stages based on a dynamic analysis technology and/or a static analysis technology, and acquiring stack information in the APP starting process and the API calling process in a molecular stage mode, wherein the sub-stages at least comprise the APP starting stage and the API calling stage;

dividing information generated by the Android application program into a plurality of pieces of sub information based on a dynamic analysis technology and/or a static analysis technology, and acquiring stack information in the APP starting process and the API calling process in a mode of respectively acquiring the plurality of pieces of sub information, wherein the stack information comprises the plurality of pieces of sub information;

and based on a dynamic analysis technology and/or a static analysis technology, marking information generated by the Android application program into an attention type and a non-attention type, and acquiring stack information in the APP starting process and the API calling process through the attention type or the non-attention type.

Optionally, the APK file is obtained by:

compiling a source code in an Android application program through a Java compiler to generate a plurality of class files;

compiling resource files in an Android application program to generate compiled resource files, wherein the resource files comprise a plurality of resources and a shared library;

generating a Dex file by a plurality of class files through a dx tool, wherein the Dex file comprises a plurality of classes and dependent classes related to the classes;

and packaging and compressing the compiled resource file and the Dex file to generate an APK file.

Optionally, the method further comprises:

according to each class in the class list, inquiring a dependent class related to each class in the Dex file;

and corresponding the dependent classes related to each class, and storing the dependent classes in the class list.

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

deleting the resources and the shared library which appear in the reduction set aiming at the resources and the shared library, and generating a new resource file;

for the class, reading the class in the Dex file, deleting the class appearing in the reduction set, and generating a new Dex file;

and generating the new APK file according to the new Dex file and the new resource file.

Optionally, the method further comprises:

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

starting the APP, and detecting and loading a Dex file corresponding to the APK by a terminal to expose an API (application program interface);

calling the API interface to obtain a calling result;

judging whether the new APK can support the normal calling of the API according to the calling result, and if the new APK can support the normal calling, ending the reduction work; if the Android log cannot be normally called, analyzing the Android log, and searching missing information, wherein the Android log is generated after the APP is started, and the missing information comprises classes, resources and a shared library;

adjusting the original reduction set according to the missing information to obtain a new reduction set;

and repeating the steps for testing according to the new reduction set until the new APK can support the normal calling of the API interface.

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

injecting the missing information in the original reduction set;

ignoring the missing information that is annotated while updating the original reduction set.

Optionally, analyzing the Android log and searching for missing information specifically includes:

adding a corresponding process ID identification when the application package is started to each application package name in the Android application program; mapping relations exist between all log entries in the Android log and all process ID identifications;

screening target log entries from the log entries according to the process ID identification;

matching the missing information from the reduction set according to the target log entry, including:

matching missing information from the reduction set according to the target log entry, specifically including:

matching missing information through a regular expression under the target log entry;

if the missing information cannot be matched through the regular expression, searching the reduction set through a dichotomy to determine the missing information.

Optionally, importing the repick list into the terminal;

and reserving the information in the repick list, wherein the repick list at least comprises the information of the class, the resource and the shared library.

A second aspect of the embodiments of the present application is to provide a system for reducing a scene-driven application, including:

the stack information acquisition module is used for acquiring stack information in an APP starting process and an API calling process to form a stack information file, wherein the stack information file comprises method parameters and a return value;

the stack information analysis module is used for analyzing the return value in the stack information file to obtain a class list; analyzing the method parameters in the stack information file to obtain a resource list and a shared library list; taking the class list, the resource list and the shared library list as first information;

the APK file analysis module is used for analyzing the APK file to acquire second information in the APK file, wherein the second information comprises classes, resources and a shared library;

the reduction set generating module is used for 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 the APK file generation module is used for removing the reduction set from the second information in the APK file to generate a new APK file.

By adopting the API-driven Android application program reduction method and system, the first information generated by the APP starting process and the API calling process and the second information generated by the whole APK file can be automatically obtained, the first information and the second information are reduced to obtain a reduction set, the second information and the reduction set are reduced to obtain necessary information required by calling an API interface, and a new APK is generated by using the necessary information. In the new APK, unnecessary information when the API interface is called is deleted, so that storage resources are saved, in addition, due to the deletion of the unnecessary information, the occupied size of the whole APK is smaller, and the APP starting speed is accelerated.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings needed to be used in the description of the embodiments of the present application will be briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments of the present application, and it is obvious for those skilled in the art that other drawings can be obtained according to these drawings without inventive exercise.

FIG. 1 is a flow chart illustrating steps of a reduction method according to an embodiment of the present application;

FIG. 2 is a flowchart illustrating the steps of generating an APK file according to an embodiment of the present application;

FIG. 3 is a flowchart illustrating the steps of culling a reduction set according to an embodiment of the present application;

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

FIG. 5 is a flowchart illustrating a process for parsing stack information files according to an embodiment of the present application;

fig. 6 is a flowchart illustrating steps of an API-driven Android application reduction tool according to an embodiment of the present application;

fig. 7 is a flowchart of an API-driven Android application reduction tool according to an embodiment of the present application;

FIG. 8 is a flowchart illustrating steps for finding missing information according to an embodiment of the present application;

fig. 9 is a system for reducing a scene-driven application according to another embodiment of the present application.

Detailed Description

The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are some, but not all, embodiments of the present application. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.

The method comprises the steps that an APP is started on a terminal, and when an API (application program interface) is called by an Android application program on the terminal, the whole APK is loaded. In fact, calling the API interface only needs the support of a small part of codes and resources in the APK, and loading the entire APK occupies a large storage resource and also slows down the APP start-up speed.

The applicant finds that, during research, it is far from sufficient to research only the calling process of the API interface in order to obtain the APK resource required by the API interface, because many global objects are involved in the API calling process, and the construction and modification of the global objects are not only in the API calling process but also in the APP starting process, thereby increasing the analysis difficulty.

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, the missing information cannot be located when the API interface call fails. The reason is that: if the reserved set is used as a new APK, missing information when the API interface call fails is queried during system testing, and the missing information is mixed into the reserved set, so that the missing information cannot be located.

To this end, the embodiments of the present application propose: the method comprises the steps of obtaining second information generated by the whole APK file, converting stack information generated by an APP starting process and an API calling process to form first information, reducing the first information and the second information to obtain a reduction set, reducing the second information and the reduction set to obtain necessary information required by calling an API interface, and generating a new APK by using the necessary information.

On one hand, the information generated in the calling process of the API interface and the information generated in the APP starting process are considered, the information of the API interface and the information of the APP starting process are used as first information to be reduced, and therefore all global objects are considered; on the other hand, the present application adopts "reduction set" instead of "reserved set", and can locate the missing information, because: if the information from which the reduction set is removed in the second information is used as a new APK, the program annotates the missing information in the reduction set during system testing, so that the annotated missing information can be automatically ignored during system testing, the missing information cannot be removed, the missing information can be stored in the new APK, normal operation of the new APK is guaranteed, and the missing information can be located because the missing information is annotated in the reduction set.

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

and step S1, acquiring stack information in the APP starting process and the API calling process to form a stack information file, wherein the stack information file comprises method parameters and return values.

In this embodiment, stack information in the APP start process and the API call process may be obtained through the runtime stack model and the runtime stack model, and the stack information is recorded to form a stack information file.

The runtime heap model is used for reflecting data flow in the code execution process, namely the processes of data creation, modification, recovery and the like, and is a set of initial values of a group of memory data and heap modification activities occurring in a period of time; the runtime stack model is used to reflect the control flow in the code execution process, i.e. the processes of loop, branch, method call, etc., and is a collection of one or more activities that the control flow takes place in a period of time.

In step S1, stack information in the APP start process and the API call process is obtained based on a dynamic analysis technique and/or a static analysis technique, so as to form the stack information file.

When the reduction work in the present application is performed, stack information is obtained based on a method of a static analysis technique and/or a dynamic analysis technique, where the stack information includes resources such as codes, resources, and a shared library. The static analysis technology refers to that static codes are scanned by methods such as syntax analysis, semantic analysis, control flow analysis and data flow analysis under a program non-running mode, and is mainly used for vulnerability detection, battery consumption optimization, test case generation, authority analysis, private data leakage detection and the like. The dynamic analysis technology refers to observing the running state of a program by running the program, wherein the state comprises a register, a memory, a function calling condition, stack information and the like, and is mainly used for performing code coverage rate detection, fault positioning, safety analysis, concurrent error search, program slicing and the like in the field of application analysis.

The static analysis technology is mainly used for APP with large installation package size, such as APP of game class. When the stack information management system is used, the APP does not need to be started, and the dependency relationship among the codes, the resources and the shared library is comprehensively combed by the system from the API interface so as to determine the codes, the resources and the shared library in the stack information which needs to be reserved.

The dynamic analysis technology mainly aims at the APP with a small installation package size, such as non-game APP, wherein the APP starting time is in the second order, and the API calling time is in the millisecond order. When the method is used, related codes, resources and shared libraries are directly determined according to stack information generated in the APP starting process and the API calling process, and complex dependency relationship combing and analyzing in a static analysis technology are avoided. In addition, the dynamic analysis technology reserves the actually executed code part according to the actual running condition of the code, and can achieve more thorough reduction for the APP with smaller installation package volume.

In step S1, since the APP start process and the API call process generate a large amount of stack information, if not limited, all stack information is captured, the process of capturing stack information additionally occupies the CPU and memory resources of the terminal, and the resources required for running the APP itself exceed the upper limit of the performance of the terminal, which results in the APP being stuck or even collapsing during the running process. Even if all stack information is acquired after a long wait, the subsequent analysis in step S2 is difficult because the memory occupied thereby is extremely large.

In order to ensure the smooth acquisition of the stack information, the stack information is acquired respectively in three aspects of staging, content division and classification:

a1: dividing the operation phase of the Android application program into a plurality of sub-phases, and acquiring stack information in the APP starting process and the API calling process in a molecular phase mode, wherein the sub-phases at least comprise the APP starting phase and the API calling phase.

In a1, the running process of the Android application at least includes an APP start phase and an API call phase. When carrying out to transfer stack information stage by stage, can regard APP to start and API to call into two processes, carry out the snatching of stack information respectively to two processes. For example, after opening the APP, a stack information file is generated, and then each API is sequentially called to generate another stack information file. Therefore, stack information in two processes of APP starting and API calling is recorded in the two stack information files respectively, and the stack information in the two processes does not need to be acquired at one time to be placed into one stack information file.

In addition, for the APP with large volume, slow starting process and many starting loading items, even if the stack information during starting is grabbed independently, the stack information may not be smoothly executed. At this time, the APP start process is divided into a plurality of stages, for example, a first stage before the user interface pops up the start animation, a second stage when the start animation runs, and a third stage after the start animation ends.

A2: dividing information generated by the Android application program into a plurality of pieces of sub information, and acquiring stack information in an APP starting process and an API (application program) calling process in a mode of respectively acquiring the plurality of pieces of sub information, wherein the stack information comprises the plurality of pieces of sub information.

In a2, stack information is fetched a plurality of times, each time fetching different information therein, to reduce the size of each stack information file. For example, only the sub information such as the method, the parameter and the return value used in the running process of the Android application program (including the APP starting process and the API calling process) is captured for the first time, and the sub information such as the method, the field modification information and the exception is captured for the second time.

A3: and marking the information generated by the Android application program into an attention type and a non-attention type, and acquiring stack information in the APP starting process and the API calling process through the attention type or the non-attention type.

In a3, the capture set is continuously reduced by configuring the concerned stack information and the non-concerned stack information, and finally the stack information file is limited within an acceptable range. For example, through preliminary stack information grabbing or manual analysis, it is determined that 10 pieces of stack information are to be retained, and then when the stack information grabbing is performed next time, the stack information can be configured into a non-concern type, and the runtime stack model do not record the call procedure and the instance object related to the stack information, so that the recording overhead is reduced. For another example, if it is desired to determine whether a small portion of stack information is to be used, the portion of stack information may be configured as a focus class, and since focus classes are generally fewer, the resolution process of stack information may be accelerated.

The stack information is respectively obtained in a staged, content-dividing and classifying mode through the three aspects, and the size of the stack information file is reduced, so that the APP is prevented from being blocked or even collapsing in the operation process; by dividing the stack information into a plurality of contents and setting the contents as the attention class and the non-attention class, the size of the stack information file is further reduced, so that the analysis of the stack information in the subsequent step S2 is realized.

Step S2, analyzing the return value in the stack information file to obtain a class list; analyzing the method parameters in the stack information file to obtain a resource list and a shared library list; and taking the class list, the resource list and the shared library list as first information.

In step S2, a stack information file is obtained through the runtime stack model and the runtime stack model, where the stack information file at least includes information such as a method, a parameter, and a return value, where the information such as the method, the parameter, and the return value includes stack information such as a class, a resource, and a shared library, and this step focuses on parsing the class, the resource, and the shared library from the stack information file to form first information, and specifically parses through the following three aspects, and referring to fig. 5, fig. 5 shows a flowchart of a step of parsing the stack information file specifically:

b1: and for the class, analyzing according to the return value to obtain a class list. 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, and the type of the return value can be obtained by intercepting the field before @ for example. And finally, sorting all the acquired types into a class list.

In B1, if only the class is saved in the class list and all other dependent classes are deleted, the Android application cannot operate correctly. This is because there are complex dependencies between classes, and the stack record file only retains the call relationships between classes, but not retains other relationships, and therefore, an error is generated. Both relationships, inheritance and implementation, must be considered at this time. For example, for a class a, assuming that it inherits an ancestor class B, an interface class C is implemented, and when the program actually runs, information of the ancestor class B and the interface class C is not recorded, but if the information is deleted, the Android application program may cause an error because the ancestor class B or the interface class C cannot be found.

In order to avoid that the Android application program cannot run correctly, all ancestor classes and interface classes of each class need to be iteratively inquired from the Dex file according to the class list, the ancestor classes are added into the class list after corresponding to the interface classes and each class, and the problem that the program cannot run is avoided.

B2, for the resource, according to the method parameter, analyzing to get the resource list.

The method for loading resources by the Android application needs to be researched because the stack model and the stack model only support recording of stack information during running and cannot directly obtain a resource list actually used during running of the Android application, and the resource list is obtained by obtaining parameters in the method for loading resource files.

Based on this, in step B2, the resource list is obtained through the resource under the res directory in the APK, the resource under the asset directory in the APK, and the newly added Resources class. The resources in the res directory provide a series of methods for accessing the resources, and the resource files in the res directory are compiled and generate resource IDs; the resources under the asset directory are not compiled by a Java compiler and are native resources added by a user, and the resources under the asset directory provide a reading interface for the native resources; the new Resources class replaces part of functions of the original Resources class, and a method for acquiring part of Resources is also provided. Based on the parameters in the three methods, a resource list can be obtained.

In the resources under the res directory, since the developer generally uses the ID of a resource under the res directory, not the resource file name, the Java compiler assigns an ID to the resource file name at the time of compilation. The terminal can only identify the resource file name, but cannot identify the ID. Therefore, for the resources in the res directory, a decompiler is set in the program, and through the decompiler, the corresponding relationship between the resource ID and the resource file name can be obtained, and a series of IDs are converted into the resource list which is actually used, so that the terminal can obtain the resource list through the decompiler. Wherein, the resource list comprises a plurality of resource file names.

B3, for the shared library, analyzing according to the method parameters to obtain a shared library list.

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

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

The de-duplication method comprises the following steps: removing duplication after obtaining the class list aiming at the aspect of B1 to obtain a non-duplicated class list; removing the duplicate after obtaining the resource list aiming at the aspect of B2 to obtain a non-duplicate resource list; and (4) removing the duplicate after obtaining the shared library list aiming at the aspect of B3 to obtain a non-duplicate shared library list. Finally, the reduction process in step S4 is performed using the non-duplicated class list, resource list, and shared library list as the first information.

And S3, analyzing the APK file to obtain second information in the APK file, wherein the second information comprises classes, resources and a shared library.

In step S3, according to the format of the APK file, all resource file lists under the assets and res files, all shared library file lists under the lib file, and all class lists in each Dex file are extracted, and second information is formed according to the class lists, the resource lists, and the shared library lists. The specific parsing process has been explained correspondingly in three aspects B1 to B3 in S2, and is not described herein again.

Wherein, the APK file comprises three states: before compiling, after compiling and after installing, in consideration of reduction of the code, in step S3, a compiled APK file is used, and the APK file includes the code, the resource and the shared library.

In step S3, it is considered that the code in the stack information in step S1 is obfuscated and reinforced by the processing tool, so as to be different from the source code before compiling. If the source code before the APK file is compiled is reduced, the code after confusion reinforcement in the stack information needs to be remapped into the source code before the APK file is compiled, so that the workload and the working difficulty are increased. On the other hand, the APP with the small installation package size is analyzed based on a dynamic analysis technology, only codes used in actual execution are reserved, and codes which are not executed are deleted. For example, in a selection statement, there are two branches A and B, where the A branch uses class a and the B branch uses class B. After the dynamic analysis technique is adopted, the B branch is not executed, so the class B is deleted. If the source code before compiling is deleted, when compiling is carried out, the Java compiler fails to compile because the code of the class b cannot be found. On the contrary, if the compiled Dex byte code is deleted, the compiling process is not carried out again, and the problem of compiling failure is avoided. Therefore, in view of the above two points, in step S3, the compiled APK file is used.

The compiled APK file is obtained through the following steps, referring to fig. 2, fig. 2 shows a flowchart of the steps of generating the APK file according to an embodiment of the present application:

s301, compiling the source codes in the Android application program through a Java compiler to generate a plurality of class files.

The JAVA compiler is used for compiling the JAVA source program into an intermediate code byte code file; the class file contains only one class containing operation instructions for the stack.

S302, compiling resource files in the Android application program to generate compiled resource files, wherein the resource files comprise a plurality of resources and shared libraries.

And S303, generating a Dex file by the class files through a dx tool, wherein the Dex file comprises a plurality of classes and dependent classes related to the classes.

The dx tool is d8, a command line tool, can support using JAVA8 language function in the code of the application, and can convert the class file into a Dex file; in the Dex file, there is no operation instruction for the stack, but only a register, relative to the class file, and a plurality of classes are included, whose instruction set is larger and the instruction is longer.

S304, packaging and compressing the compiled resource file and the Dex file to generate an APK file.

The compiled resource file comprises a resource and a shared library, and the Dex file comprises a plurality of classes, and the compiled APK file can be generated after the classes are packed and compressed.

In steps S1 to S3, obtaining first information generated by the APP start-up procedure and the API call procedure; in the subsequent step S4, the reduction of the first information and the second information is required, where the first information and the second information both include a code, a resource, and a shared library, and when the reduction is performed, the problem of reducing the granularity is involved.

For codes, a code packet, a class, a method or a statement can be used as a basic unit, and when reduction is performed, the class is used as the basic unit of the codes, because: if the code packet is taken as a basic unit of reduction, a large amount of redundancy is caused, and the principle of the reduction program of the application is violated; if the method and statement are used as basic units of code reduction, when stack information generated in the APP starting and API calling process is obtained, complete method calling information and statement execution information must be obtained, and byte codes of the method and statement must be finely operated in the APK reduction stage in the subsequent steps S4 and S5, so that the difficulty is greatly increased; the Android application program adopts Java language, Java is a language facing objects, and classes are basic units of the Java language, so that the classes are used as the basic units of codes, and the Android application program can be better adapted to.

For resources, a resource type, a resource file and contents of the resource file can be used as basic units, and when reduction is performed, a single resource file is often used as a basic unit when the resources are referred to, so that the single resource file is used as a basic unit.

For the shared library, a shared library file or a code in the shared library file may be used as a basic unit. In the reduction, the single shared library file is used as a basic unit because the loading of the shared library takes the single shared library file as a unit.

And step S4, 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.

When determining the reduction set, directly making a difference set between the first information and the second information to obtain a final reduction set, where the reduction set is stack information that is not used, i.e., is not used, and the reduction set is not used in the APP starting process and the API calling process.

And step S5, removing the reduction set from the second information in the APK file to generate a new APK file.

When a new APK is generated, since the first information and the second information both include a class, a resource, and a shared library, the new APK is generated through the following three steps, referring to fig. 3, fig. 3 shows a flowchart of the step of removing the reduction set according to an embodiment:

s501, deleting the resources and the shared library in the reduction set aiming at the resources and the shared library to generate a new resource file.

The resources are stored in an assets directory, the shared library is stored in a lib directory, and the resources which are not used in the assets directory are directly deleted during specific operation; and delete the shared libraries that have not been used in the reduction set under the lib directory.

S502: and for the class, reading the class in the Dex file, deleting the class appearing in the reduction set, and generating a new Dex file.

In the process of generating a new Dex file, reading the Dex file by using a jar package of a Dex2jar tool, deleting irrelevant classes in the Dex file, and then regenerating the new Dex file.

The Dex2jar tool refers to an analysis tool for a Dex file, which can conveniently convert the Dex file into a jar file for subsequent analysis and development, but the aim of modifying the Dex file in step S502 is to delete classes appearing in the reduction set, so that related operations are performed by using the existing classes and methods for analyzing and modifying the Dex file in the jar package instead of directly using the Dex2jar tool, by using the jar package of the Dex2 jar.

S503, generating 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. When a new APK file is generated, resources which are not used in res, assets and lib directories are directly deleted, classes in the Dex file are deleted, and a new Dex file is generated again; in addition, the stack information generated in the APP starting process and the API calling process also comprises part of other files, such as a signature file and a file containing the corresponding relation between the resource file and the resource ID; error checking and modification are needed to the signature file, and the signature is re-signed after correction and then is put into the APK file; and directly copying and reserving the file containing the corresponding relation between the resource file and the resource ID into a new APK file. And finally re-signing and packaging the new APK file, namely completing the reduction of the APK.

After step S503, that is, after the new APK file is generated, in order to enable the new APK file to support the normal call of the API, a new reflection type Dex file needs to be generated according to the new APK and the original code of the API, so as to support the normal call of the API.

In steps S501 to S503, since the number of shared libraries and resource files is relatively small, and the size of a single shared library file and a single resource file is relatively large, APK is reduced in sequence according to the order of shared libraries, resources, and classes, so that the size of APK can be reduced effectively and quickly, and the reduction rate is increased.

After the new APK file is generated through steps S1 to S5, if a new API is to be added, the new API-dependent code, resource, and shared library are added directly on the basis of the new APK, so that the reduction of the APK can be completed.

By the method for reducing the application program driven by the scene, the first information generated by the APP starting process and the API calling process and the second information generated by the whole APK file can be automatically acquired, the first information and the second information are reduced to obtain a reduction set, the second information and the reduction set are reduced to obtain necessary information required by calling the API interface, and a new APK is generated by using the necessary information. In the new APK, unnecessary information when the API interface is called is deleted, so that storage resources are saved, in addition, due to the deletion of the unnecessary information, the occupied size of the whole APK is smaller, and the APP starting speed is accelerated. In addition, the method and the device can accurately position the missing information when a system test of a new APK is carried out based on the thought of 'reduction set' rather than the thought of 'preservation set'.

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

In the process, after the APP is started on the terminal, the whole APK is loaded when the Android application program on the terminal calls the API interface, and the APK is an Android installation package. In fact, calling the API interface only needs the support of a small portion of codes and resources in the APK, and loading the entire APK occupies a large storage resource. Therefore, the whole APK needs to be reduced, and a new APK is obtained according to the reduced set obtained after the reduction, so as to reduce the storage resource occupied by loading the APK.

However, the applicant finds that the new APK obtained from the reduction set often cannot operate normally, and besides the error caused by the inaccuracy of the analysis process, the change of the code execution path is also an important reason, and the change of the code execution path is based on the following three reasons: 1. changes in the external environment such as network, model, etc.; 2. randomness in the code; 3. the code and resources are deleted. For the change of the external environment of the network, the model and the like of the first aspect, for example, when the network can be connected, the start of many apps can download advertisements from the network and display the advertisements on a start page, and if the network cannot be connected, the process can be skipped. For another example, when different mobile phones are used to access the same version of "driving test book" App, the millet mobile phone will display a section of starting animation, but the Nexus mobile phone will not, and the change of the external environment will cause the new APK not to operate normally. For the randomness in the code of the second aspect, in order to realize a specific function and complete a specific service, sometimes a certain randomness must be added into the code, which also results in that the execution path of the code may be different each time the code is run. For the third aspect, when the code and the resource are deleted, and the code and the resource are not reduced, the original APK is normally operated, but the new APK, i.e., the reduced APK, does not retain the code and the resource, and thus cannot operate correctly.

In order to ensure the normal operation of the new APK, the Android application program reduction tool is provided, and the Android application program reduction tool is mainly responsible for testing whether an App can be normally started and whether each API can be correctly called in the new APK according to the reference of FIG. 7. And if the normal calling cannot be carried out, analyzing the Android log, finding out the reason of the calling failure or the missing information, readjusting the reduction set, and carrying out APK reduction again. And iterating the steps until all the APIs are successfully called. In the process, after the code path is changed, corresponding calling failure reasons or missing information can be generated and stored in the Android log, the calling failure reasons or the missing information can be found out by analyzing the Android log, the reduction set is adjusted according to the calling failure reasons or the missing information, the reduction set is removed from the APK file again to obtain a new APK, and after repeated iteration tests, the normally-running APK can be obtained.

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

and S6, installing the new APK and the Dex file corresponding to the APK to the terminal to generate the APP.

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

Wherein, the Dex file is used to expose the API interface set forth in step S1, and the Dex file has no operation instruction for the stack, only operates on the register, and includes several classes in the Dex file.

Wherein the reduced APK, i.e. the new APK, is obtained by: firstly, comparing stack information generated in the Android application program running process with information in an APK file to obtain an about-reduction set, and then removing the about-reduction set from the APK file to form a new APK file. The new APK file occupies smaller storage resources through the reduction of the volume of the new APK file. The reduction set is stack information which is not used by the API interface, and the new APK file is stack information which is needed by the API interface.

And S7, starting the APP, and detecting and loading the Dex file corresponding to the APK by the terminal to expose the API interface.

After the APP is started, the terminal can call a plurality of API interfaces correspondingly, but for the reduction tool in the present application, it cannot be known through which API interface the function is implemented. Taking the payment treasured as an example, the payment treasured includes a plurality of functions such as a dripping trip, hungry how, film show, and every function corresponds an API interface respectively, and when the user clicked the dripping trip, the system can call the API interface that corresponds with the dripping trip, but the reduction tool can't learn specifically that the function of dripping the trip is realized through which API interface, correspondingly, also can't learn the reason that API interface calls the failure. Therefore, in order for the reduction tool to know whether the API interface is used, the API interface needs to be exposed so as to know the reason of the API interface call failure.

The Dex file is a reflection-type Dex file. And finally, the API interface is exposed to the reduction tool through the Dex file and the API interface operation system, the Dex file is loaded into the reflection loader, the Android system class and the Android installation package are combined, and the reduction tool can obtain the calling result according to the information fed back by the API interface.

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

And S8, calling the API interface to obtain a calling result.

The calling result comprises two conditions of normal calling or abnormal calling, wherein the condition that the calling result is abnormal calling comprises the following steps: APK installation failure, API calling failure and an API calling result are incorrect.

S9, judging whether the new APK can support the normal calling of the API interface according to the calling result, if so, ending the reduction work; and if the Android log cannot be normally called, analyzing the Android log and searching missing information, wherein the Android log is generated after the APP is started, and the missing information comprises classes, resources and a shared library.

When the APP is started, a large amount of information is generated, the information includes stack information, and the stack information includes classes, resources and shared libraries. And storing a large amount of information generated when the APP is started into an Android log, analyzing the Android log to find out missing information or calling failure reasons when a new APK cannot be normally called, and readjusting the reduction set according to the missing information and the calling failure reasons.

When the Android log is specifically analyzed, the analysis is performed based on the three cases in step S8. When the APK is failed to be installed, the Android log is analyzed, so that the re-signature of the APK is invalid. When API calling fails, firstly, information returned by an API interface needs to be analyzed, if the error type of the information returned by the API interface is DeaObject, the result shows that the APP is not correctly started or is killed, and a global object in stack information cannot be provided for the API calling process; and then, the Android log needs to be further analyzed to find out specific wrong information, wherein the specific wrong information comprises the loss of information such as classes, resources and shared libraries. When the result of the API call is incorrect, it may be stated that the resource of the terminal local database is deleted, which results in an error in accessing the local database.

Because in the whole terminal, only one APP process is running, and other APP processes can also be running, when the APPs run, information can be generated and stored in the Android log, and the information generated by the target APP can be inquired from the Android log. In step S9, analyzing the Android log to find missing information, specifically including the following steps, referring to fig. 8, where fig. 8 shows a flowchart of the step of finding missing information:

s901, adding a process ID identifier when a corresponding application package is started to each application package name in the Android application program; and mapping relation exists between each log entry in the Android log and each process ID.

The process ID identification is a process identifier, one application packet corresponds to one process ID identification, and one process ID identification is created and corresponds to each opened application program in the terminal.

S902, screening target log entries from the log entries according to the process ID identification.

In step S901, it is stated that each log entry in the Android log has a mapping relationship with a plurality of ID identifiers, that is, each application package can query, according to the mapping relationship between the ID identifiers and the log entries, which target log entry the information generated by the application package is located under.

And S903, matching the missing information through a regular expression under the target log entry.

The target log entry has multiple levels of information, and the format of the log information is relatively fixed, so that the missing information can be located through a regular expression, for example, the missing class or resource name is matched from the target log entry through the regular expression.

And S904, if the missing information cannot be matched through the regular expression, searching the reduction set through a dichotomy to determine the missing information.

In this case, for missing information that cannot be located and analyzed by the program, i.e., without a call result, there is no error-prompting information. In order to realize automation of missing information positioning, missing information is positioned based on a dichotomy. For example, the first half of the reduction set is first reduced, and if there is an error, the missing information can be located in the first half of the reduction set; if there are no errors, the missing information may be located in the second half of the reduction set. Bisection is continued until the missing class or resource is found. In the process of multiple iterations, a global dichotomy result can be generated, that is, if in the two adjacent iterations, the previous iteration process proves that the deletion of the first N classes cannot be mistaken, and the next iteration process is mistaken, the missing information is definitely not in the first N classes, so as to reduce repeated calculation.

In addition, in order to perform the bisection of the reduction set, the reduction set needs to be sorted to ensure the orderliness of the reduction set.

And S10, adjusting the original reduction set according to the missing information to obtain a new reduction set.

As stated in step S8, the failure of the API to normally call includes the following three cases: the APK fails to install, the API fails to call and the API calls are incorrect. In step S9, it is stated that the re-signature of the APK is invalid for the failure of APK installation; aiming at API call failure, judging that the APP is not correctly started or is killed, and indicating the loss of classes, resources and a shared library; and (4) for the condition that the API can not be normally called, indicating that the database resource is deleted.

Therefore, reasons for the failure of the API to make a normal call include: 1. calling a failure reason, and the re-signature of the APK is invalid; 2. the missing information, the missing of the class, the resource and the shared library, and the missing of the database resource. Therefore, in step S10, the specific adjustment of the original reduction set includes the following three cases:

and aiming at the invalidity of the re-signature of the APK, checking the signature process and adjusting the signature of the APK.

And directly injecting the corresponding class, resource and shared library from the reduction set aiming at the loss of the class, resource and shared library.

For a database resource being deleted, the corresponding database resource is also annotated directly from the reduction set.

And S11, repeating the steps to test according to the new reduction set until the new APK can support the normal calling of the API interface.

In the specific iteration, because the APK and Dex files are already installed on the terminal, the APK and Dex files do not need to be reinstalled in each iteration, and the iteration test can be performed by directly repeating the steps S7 to S11.

In this embodiment, after finding the missing class or resource from the Android log, delete it from the reduction set, and perform reduction again. To facilitate subsequent iterations and review by the developer, a new reduction set needs to be written to the original file. If the new reduction set is written into the original file again after each iteration, the efficiency will be low, and therefore, in order to avoid the occurrence of the efficiency low condition, the present embodiment writes the final new reduction set into the original APK file directly after the end of multiple iterations.

However, after many iterations, the developer cannot know the missing class, resource name and shared library name from the new reduction set, which makes it difficult to perform error analysis of the Android log. Therefore, in order to make the developer know the missing class, resource name and shared library name, in step S10, the original reduction set is adjusted according to the missing information to obtain a new reduction set, and the missing information needs to be annotated in the original reduction set; ignoring the missing information that is annotated while updating the original reduction set.

When the reduction set is removed from the information generated by the APK, namely when the reduction set is updated, the system automatically retains the annotated missing information without deleting the annotated missing information together with the reduction set, so that the missing information is retained on one hand; on the other hand, the missing information is annotated, so that the developer can know the missing information conveniently.

In this embodiment, a replay list is further included, and during specific operation, the replay list is imported into the terminal; and reserving the information in the repick list, wherein the repick list at least comprises the information of the class, the resource and the shared library.

The repick list is unconditionally reserved for code packages, resource folders and the like in the list. For example, when a reduction is made to an offline application, its local database needs to be retained to support the offline functionality of the application. And in the calling process of the API, only one or a plurality of data in the database can be used, so that all the rest data can be deleted. However, the API should support access to all data entries in the local database, so by adding the folder path of the database resource in the repick list, the entire database resource can be reserved to support the offline functionality of the application. For another example, when reducing code, if the missing classes in several iterations are all found to belong to the same code packet, the code packet may be added to the repick list, and all the contents of the code packet may be retained, so as to save reduction time.

Through the API-driven Android application program reduction tool, after a code path is changed, corresponding calling failure reasons or missing information can be generated and stored in an Android log, the calling failure reasons or the missing information can be found out by analyzing the Android log, a reduction set is adjusted according to the calling failure reasons or the missing information, the reduction set is removed from an APK file again to obtain a new APK, and after repeated iteration tests, the normally-running APK can be obtained.

Example two

Referring to fig. 9, a scene driven application reduction system includes:

The embodiments in the present specification are described in a progressive manner, each embodiment focuses on differences from other embodiments, and the same and similar parts among the embodiments are referred to each other.

As will be appreciated by one of skill in the art, embodiments of the present application may be provided as a method, apparatus, or computer program product. Accordingly, 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 embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.

Embodiments of the present application are described with reference to flowchart illustrations and/or block diagrams of methods, terminal devices (systems), and computer program products according to embodiments of the application. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing terminal to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing terminal, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing terminal to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing terminal to cause a series of operational steps to be performed on the computer or other programmable terminal to produce a computer implemented process such that the instructions which execute on the computer or other programmable terminal provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

While preferred embodiments of the present application have been described, additional variations and modifications of these embodiments may occur to those skilled in the art once they learn of the basic inventive concepts. Therefore, it is intended that the appended claims be interpreted as including the preferred embodiment and all such alterations and modifications as fall within the true scope of the embodiments of the application.

Finally, it should also be noted that, herein, relational terms such as first and second, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Also, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or terminal that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or terminal. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in a process, method, article, or terminal that comprises the element.

The method and system for reducing the application program driven by the scene provided by the application are introduced in detail, and a specific example is applied in the text to explain the principle and the implementation of the application, and the description of the above embodiment is only used to help understand the method and the core idea of the application; meanwhile, for a person skilled in the art, according to the idea of the present application, there may be variations in the specific embodiments and the application scope, and in summary, the content of the present specification should not be construed as a limitation to the present application.

Claims

1. A method for reducing a scene-driven application, the method comprising:

2. The method of claim 1, wherein obtaining stack information in an APP start process and an API call process to form a stack information file specifically comprises:

dividing an operation stage of an Android application program into a plurality of sub-stages based on a dynamic analysis technology and/or a static analysis technology, and acquiring stack information in the APP starting process and the API calling process in a molecular stage mode, wherein the sub-stages at least comprise the APP starting stage and the API calling stage;

3. The method of claim 1, wherein the APK file is obtained by:

4. The method of claim 3, further comprising:

5. The method according to claim 3, wherein the removing the reduction set from the second information in the APK file to generate a new APK file specifically comprises:

6. The method of claim 3, further comprising:

calling the API interface to obtain a calling result;

7. The method of claim 6, wherein adjusting the original reduction set to obtain a new reduction set according to the missing information further comprises:

injecting the missing information in the original reduction set;

8. The method according to claim 7, wherein analyzing the Android log for missing information specifically comprises:

9. The method of claim 6, characterized in that a repick list is imported into the terminal;

10. A scene driven application reduction system, comprising: