The essence of performance optimization: Delete as many packages as possible. Performance optimization method of installation package:
1. Image compression
- SVG pictures: Some image description, sacrifice CPU computing power, save space. Rule of thumb: Simple ICONS.
- Webp: Google is now very much advocating the use of. Saving images is small. VP8 is derived from VP8. Webp lossless compression is about 45% less than PNG files, even though PNG files are compressed by other compression tools, they can still be reduced to 28% of PNG files.
- Facebook, Tencent, Taobao. Cons: Loading is much slower than PNG. But the configuration is high. Image compression tool: tinypng.com/ Image compression tool: isparta.github. IO /
2. Dynamic resource loading
For example: emoji, skin change, dynamic download resources, some module plug-in dynamic addition
3. Use the Lint tool provided with AS to delete unnecessary resources
1) Detect unused layout and delete 2) unused resources such as images - delete 3) Suggest string. XML has some unused characters.Copy the code4. Ultimate compression
7zZip tool use.
5. Lib resource optimization
(1) Dynamically downloaded resources. (2) Plug-in dynamic addition of some modules. (3) Clipping and compression of so files.
6. Optimize assets
(1) It is best to use lossless compression format for audio files, such as OPus, MP3, etc., but it is best not to use lossless compression format for music. (2) To compress TTF font files, you can use FontCreator to extract only the text you need. For example, when doing date display, you only need digital fonts, but using the original font library might need 10MB size. If you just extract the font you need, the font file will only be 10KB.
7. Proguard confusion
7.1 concept
Resource obfuscation in simple terms, we want to implement res/drawable/icon, PNG to res/drawable/a.png, or we can even obfuscate the file path at the same time, to r/ S /a.png.
Note: the obfuscation is compressed after the obfuscation of AS. The obfuscation that comes with AS is the obfuscation of the content of the code, in this case the file name.
7.2 APK Compilation Principle
7.2.1 Compiling schematic diagrams
Android applications are made up of two main parts: code and resources. Resources are mainly those related to the UI, such as UI layouts, strings, images, etc. The separation of code and resources allows the application to organize the UI according to actual needs at run time. This allows the application to be compiled once to support different UI layouts. This feature allows applications to run in different screen sizes and densities, as well as in different countries and languages.
7.2.1 aapt compilation
Aapt is the Android Asset Packaging Tool in the BUILd-Tools directory of the SDK. This tool can view, create, and update document attachments in ZIP format (ZIP, JAR, APK). Resource files can also be compiled into binaries.
As can be seen from the figure: a. Assets and RES/RAW resources are packaged into APK unchanged, all other resources are compiled or processed. B. All assets except assets are assigned a resource ID. C. The packaging tool is responsible for compiling and packaging resources. After compiling, it generates a resources.arsc file, which holds a resource index table, and an R.java, which defines each resource ID constant. D. The application configuration file Androidmanifest.xml is also compiled into binary XML files and packaged into APK. E. The application accesses resources at run time through AssetManager, by resource ID, or by file name.
The resources.arsc file records information about all application resource directories, including the name, type, value, ID, and configured dimension information for each resource. We can think of the resources.arsc file as a resource index table that can quickly find the best match in an application’s resource catalog given a resource ID and device configuration information.
7.2.3 Resources. Arsc file parsing
(1) Resource. Arsc file format diagram
Apk decompression
Arsc contains five chunk types: TYPETABLE, TYPEPACKAGE, TYPE_STRING,TYPETYPE, TYPECONFIG.
– Table is the start of the entire reousces table, and its chunksize is the size of the entire file. — Package refers to the beginning of a package. In fact, in resources, ARSC can have multiple packages. PackageID is the highest eight bits of resource resID. Generally speaking, android system resID is 1(0x01), common ones such as com.tencent. Mm will be 127(0x7f), and the rest will start from 2. Of course, we can specify this in AAPT (1-127 is the legal space of eight bits, some mixed compilation is to change this packageID). – String stands for stringBlock, and there are three types of stringblocks. The values are table StringBlock, Typename StringBlock, and specsName stringBlock. — type: typename chunk: attr, drawable, Layout, ID, color, anim, etc. The Type ID follows the Package ID. – config, which is used by Android to describe resource dimensions, such as vertical and horizontal screens, screen density, language, etc. For each type, there are as many config chunks as there are config chunks. For example, if we define drawable-mdpi,drawable-hdpi, there will be two Config chunks.
Read the contents of the Resource. Arsc file as follows:
7.3 Confusion Process
PNG — > 0x7F020000 after the apK file is compiled: res/drawable/ic_launcher
/drawable/ic_launcher. PNG file name = a. PNG drawable file name = String file name = layout R.string.description — > r.string. a res/drawable/ic_launcher
Res /drawable – >r/d res/value – >r/v res/drawable/ic_launcher. PNG
Read the resources.arsc binary and modify the bytes of each segment. PNG: res/drawable/ic_launcher. PNG: res/drawable/ic_launcher. PNG: res/drawable/ic_launcher. PNG: res/drawable/ic_launcher. PNG: res/drawable/ic_launcher.
8. The zipalign optimization
We know that APK is actually a Zip compressed file. In principle, it is to improve the speed of system parsing by formatting the sequence of binary files in the Zip folder. Just as formatting the code before reading it makes it easier to understand what it means. On The Android platform, data files are stored in APK files, which can be accessed by multiple processes. If you have developed Win32, you probably know the granularity alignment problem of the application. Although not PE format files, in the same way as Zip, resource access can be better optimized for it. Zipalign, on the other hand, uses 4-byte boundary alignment to reflect memory, improving execution efficiency by swapping space for time.
What I understand is: generally speaking, it is to arrange the resource files in APK according to the arrangement way that is conducive to system processing, so as to improve the speed of resource search, so as to improve the operation efficiency of the application.
Sign and then align; otherwise, align and then sign will damage alignment
use
release {
// Do not display Log
buildConfigField "boolean"."LOG_DEBUG"."false"
/ / confusion
minifyEnabled true
/ / the Zipalign optimization
zipAlignEnabled true
// Remove useless resource files
shrinkResources true. }Copy the code9. Optimize with ReDex
ReDex is an open-source tool for reducing the size of Android apps to improve performance. Optimizations such as embedding and zombie code removal to reduce bytecodes are mainly optimized for Dex, which makes APK run faster, but requires a lot of testing to see if it crashes. After Redex conversion, APK becomes smaller and faster. Redex optimizes Android’s.dex file in a piped manner. A source.dex file is piped through a series of custom transformations to get an optimized.dex file.
We know that the Android compilation process first uses the Javac tool to compile.java files into.class files, and then merges all.class files into the executable file.dex of the Dalvik vm. Finally, compress APK files together with other resources and other files, and the general process is as follows:
Timing of conversion
Redex chose to optimize based on bytecode files rather than Java source because bytecode allows for more global, class-to-class optimization than Java source, rather than local optimization of individual class files. Optimization based on DEX bytecode rather than Java bytecode was chosen because some optimizations can only be done in dex files.
The idea of pipes
As time goes by, developers may constantly get new optimization ideas. In order to conveniently add new optimization points into existing codes and facilitate parallel development of optimization points by different developers, Redex chooses the idea of pipeline to realize optimization of DEX. In this way, each optimized idea can be integrated into the pipeline in the form of plug-ins to achieve plug-and-play without affecting other optimized plug-ins. The overall optimization process is as follows:
Github address: github.com/facebook/re…