Android performance optimization-apk slimming

1. Code
2. Resources
3. Dynamic library

APK structure

Contains the following directories:

• assets/: Contains the resources of the application, which can be obtained through the AssetManager object.
• lib/: Contains the compiled code for the processor level. This directory has a subdirectory for each platform type, such as armeabi, armeabi-v7a, arm64-v8a, x86, x86_64 and mips.
• res/: contains resources that have not been compiled into resources.arsc.
• META-INF/: Contains CERT.SF and CERT.RSA signature files, as well as MANIFEST.MF files. (Annotation: Verify whether this APK has been changed by others)

Contains the following files:

• classes.dex: Contains classes in the dex file format that can be understood by the Dalvik/Art virtual machine.
• resources.arsc: Contains the compiled resources. This file contains the xml content of all configurations in the res/values ​​directory. The packaging tool compiles the xml content into binary form and compresses it. These contents include language strings and styles, as well as those contents that are not directly stored in the resources.arsc file, but the path to the contents is given, such as layout files and pictures. So called resource mapping table
• AndroidManifest.xml: Contains the main Android configuration files. This file lists the application name, version, access permissions, and referenced library files. The file is stored in binary xml format. (Annotation: The file can also see the minSdkVersion, targetSdkVersion and other information of the application)

Use SVG vector graphics

SVG import

SVG (Scalable Vector Graphics), scalable vector graphics. SVG does not degrade image quality due to scaling like bitmaps. The advantage is that it can reduce the size of the APK (for example, if you use png images, you need to place multiple sets of images with different resolutions in directories such as drawable and drawable-xhdpi, otherwise the png image will become blurred due to zooming). It is often used for simple and small icons. The official recommendation is to use SVG when the picture is smaller than 200*200. When the picture is large, the drawing time of the SVG picture will be longer. For large images such as the background image of the app's startup page, SVG cannot be used, and webp images can be used to reduce the image size.

svg is defined by xml, and the standard svg root node is <svg>.

Android only supports <vector>, we can vector the root node svg <svg>convert <vector>.

Open the project in Android Studio, right-click in the res directory -> new -> Vector Asset

SVG batch conversion

If there are multiple svgs that need to be converted to android vectors, you can use the third-party tool svg2vector to perform batch conversion.

Execute the conversion command:

java -jar svg2vector-cli-1.0.0.jar -d . -o a -h 20 -w 20

-d Specify the directory where the svg file is located
-o output the android vector image directory
-h set the height of the
converted svg -w set the width of the converted svg

Unsupported SVG

If the SVG file contains unsupported functions, an error message will be displayed at the bottom of Vector Asset Studio, as shown in the figure:

Examples of unsupported functions:
Filter effects: Projection, blur and color matrix effects are not supported.
Text: It is recommended to use other tools to convert text into shapes.

Vector graphics are backward compatible

Versions prior to Android 5.0 (API 21) do not support vector graphics. There are two ways to adapt using Vector Asset Studio: generating PNG and using support libraries.

Method 1: Generate a picture in png format

Vector Asset Studio can convert vector graphics into bitmaps of different sizes for each screen density during construction. The configuration in build.gradle is as follows:

SVG is applicable to Gradle plugin 1.5 and above;

android{ defaultConfig{ // Version 5.0 (API 21) and below, generate png images of specified dimensions from svg images generatedDensities = ['xhdpi','xxhdpi'] } }

Method 2: Support library

The configuration in build.gradle is as follows, which is suitable for Gradle plugin 2.0 and above:
android{ // Gradle Plugin 2.0+ defaultConfig{ // Use the VectorDrawableCompat class in the support library to support VectorDrawable vectorDrawables in version 2.1 and later . useSupportLibrary = true } } dependencies { // Support library version needs to be 23.2 or higher compile'com.android.support:appcompat-v7:23.2.0 ' }

At this time, you must use the app:srcCompat attribute instead of the android:src attribute to use the vector graphics, as follows:

Vector color modification

We can individually modify the color of a certain part of the vector diagram, as shown in the figure:

Tint shader

Although we said before, you can modify the color of the vector diagram directly in the xml file, but it is not recommended to modify it directly. We generally make the vector black and then use the Tint shader to modify the color of the vector diagram.

Modify the color:

What if we want to achieve a click effect?

Tint shader-click to change color

Create two selectors and use them normally.

drawable selector battery_selector.xml

color selector battery_tint_selector.xml

use

ABI-Application Binary Interface

The early Android system almost only supported the ARM v5 CPU architecture, but now do you know how many types it supports? 7 kinds!

The Android system currently supports the following seven different CPU architectures: ARMv5, ARMv7 (from 2010), x86 (from 2011), MIPS (from 2012), ARMv8, MIPS64 and x86_64 (from 2014), Each one is associated with a corresponding ABI.

ABI is the abbreviation of Application Binary Interface, which defines how binary files (especially .so files) run on the corresponding system platform, from the instruction set used, memory alignment to the available system function library.

On the Android system, each CPU architecture corresponds to an ABI: armeabi, armeabi-v7a, arm64-v8a, x86, x86_64, mips, mips64.

HELP	Supported Instruction Set(s)	Notes
armeabi	ARMV5TE and later，Thumb-1	No hard float
armeabi-v7a	armeabi，Thumb-2，VFPv3-D16，Other，optional	Incompatible with ARMv5,v6 devices
arm64-v8a	AArch-64
x86	x86(IA-32)，MMX,SSE/2/3，SSSE3	No support for MOVBE or SSE4
x86_64	x86-64，MMX，SSE/2/3，SSE3，SSE4.1，SSE4.2，POPCNT
mips	MIPS32r1 and later
mips64	MIPS64r6

The analysis of each version is as follows:

• mips / mips64: rarely used in mobile phones and can be ignored
• x86 / x86_64: Mobile phones with x86 architecture will include an instruction set dynamic transcoding tool called Houdini provided by Intel to achieve compatibility with arm.so, and then consider the x86 market share below 1%, and x86 related two. so can also be ignored
• armeabi: ARM v5 is a fairly old version, lacks hardware support for floating-point calculations, and has performance bottlenecks when a lot of calculations are required
• armeabi-v7a: The current mainstream version of ARM v7
• arm64-v8a: 64-bit support

ps: ARM v8 related information:

ARM itself does not have 64-bit chip design technology. In November 2011, he passed the acquisition of part of the technology use rights of the MIPS64 processor architecture and designed it in conjunction with some features of ARM. That is to say: Among the three major architectures of MIPS, ARM, and X86, the only ARM without 64-bit technology has obtained 64-bit through the acquisition of MIPS.

The so-called ARMv8 architecture is developed by adding the TrustZone technology, virtualization technology and NEON advanced SIMD technology that are already in the ARMv7 architecture to the MIPS64 architecture.

The 64-bit ARMv8 architecture contains two execution states: AArch32 (also known as ARMv7) and AArch64 (ARMv8). The AArch64 execution state introduces a new instruction set A64 (based on the acquired MIPS64 architecture) for 64-bit processing technology, and the AArch32 execution state will support the existing ARM instruction set. Therefore, the 64-bit ARM processor contains both 32-bit ARMv7 and 64-bit ARMv8 architectures. Therefore: seeing this, you must understand that ARM64-bit processors and computer 64-bit processors are two completely incompatible concepts. It is not that 64-bit can be natively backward compatible with 32-bit programs, but through 64-bit The 32-bit architecture integrated in the processor runs 32-bit programs. To put it plainly, it does not run 32-bit programs in 64-bit form, but in 32-bit form to run 32-bit programs.

Since the new 64-bit processor contains two architectures and the process technology has not been improved (28nm), at the same time, on mobile phones and tablets, the chip area is strictly limited and cannot be increased excessively, which leads to an even distribution of 64-bit ARM processors The number of transistors in each architecture has dropped sharply, that is to say, from the 32-bit architecture in the 64-bit processor, for the 32-bit processor of the same specification, not only has the performance not improved, but the performance has decreased to a certain extent. But processor manufacturers must give consumers an explanation to better promote 64-bit, so manufacturers must improve performance in other areas to make up for the loss caused by the reduction in the number of CPU transistors. For example: replace GPU with stronger performance, increase memory bandwidth, multi-core virtual single core to improve single-core performance, joint running software vendors to modify running score weight (increasing GPU score, reducing CPU score weight) and so on. In this way, the strengths and weaknesses are maximized, and finally reached the hands of consumers, running with the running software, it is indeed improved, the users are happy, and the manufacturers' pockets are bulging.

To sum up, the ARM64-bit processor is more appropriate to call it ARM32+64 in the strict sense. Compared with the ARM32-bit processor, there is room for retrogression and room for improvement. However, it is precisely because of the retrogression that ARM has inspired the advancement of ARM. The determination to make it drastically change forward, it has to be said to be a kind of progress. But is ARM64 really useful on mobile phones? I can only say that it is really useless at the moment, but it may be in the future.

Google officially said that Android has supported 64-bit a long time ago. This is true. From Android 4.0 to Android 4.4, Android systems support 64-bit hardware, but this only means that the underlying driver supports 64-bit and can run. On 64-bit hardware, nothing more. However, the upper layer running the software, whether it is the Dalvik virtual machine or the ART virtual machine, is 32-bit. In other words, as long as your mobile phone system is Android4.0-4.4, even if your processor is 64-bit, you can only run 32-bit programs under a 32-bit virtual machine, even if the real 64-bit programs are in front of you, It cannot be installed either.

Android L started to support 32-bit and 64-bit ART virtual machines, with a 64-bit processor, running 64-bit software justifiably. But the problem comes again, no software vendor is willing to develop 64-bit programs.

ARMv8 is a good instruction set. It supports future 64-bit programs and is backward compatible with existing 32-bit programs. With the support of ARMv8, future 64-bit mobile phone operating systems, such as Android L 64bit, can simply and efficiently support existing 32-bit apps without worrying about compatibility issues.

Big and small

Big-endian mode means that the high byte of data is stored in the low address of the memory, and the low byte of data is stored in the high address of the memory. This storage mode is a bit similar to processing the data as a string: The address increases from small to large, and the data is placed from high to low; this is consistent with our reading habits.

Little-endian mode means that the high byte of data is stored in the high address of the memory, and the low byte of data is stored in the low address of the memory. This storage mode effectively combines the high and low addresses of the address and the data bit weight. The high address part has a high weight, and the low address part has a low weight.

Why is there a distinction between large and small endian models? This is because in computer systems, we use bytes as the unit, and each address unit corresponds to a byte, and a byte is 8 bits.

For example, such a data: 0x11223344 converted to binary is 00010001 00100010 00110011 01000100

After big-endian storage, what we see is 00010001 00100010 00110011 01000100, which is 11 22 33 44 in hexadecimal.

After little-endian storage, what we see is 01000100 00110011 00100010 00010001 which is 44 33 22 11 in hexadecimal

Current situation

At present, Intel’s 80x86 series chips are the only chips that still insist on using little-endian. ARM chips use little-endian by default, but can be switched to big-endian; while MIPS and other chips either use all big-endian storage or provide options to support big-endian—— You can switch between large and small ends. In addition, the processing of large and small endian is also related to the implementation of the compiler. In C language, the default is little endian (but in some implementations of microcontrollers, it is based on big endian, such as Keil 51C). Java is platform-independent. It's big endian. Big endian is generally used to transmit data on the network