Recently, when I was researching APP slimming, I happened to come across some ABI related knowledge points like ArmeABI, ArmeABI-V7A, ARM64-V8A, etc. I decided to write them down and share them.

At present the status quo

First of all, let’s analyze the ABI used by Taobao and wechat in China, as well as Facebook and Twitter in foreign countries.

We conduct Analyze on these 4 APKs, and it can be found that Facebook and Twitter only use Armeabi-V7A, while wechat and Taobao only use Armeabi. The analysis results are shown in the figure below:

Knowledge review

First, let’s take a look at how Google Big Brother introduces the ABI.

Different Android phones use different cpus and therefore support different instruction sets

Each combination of CPU and instruction set has its own application binary interface (or ABI)

The ABI defines very precisely how the application’s machine code interacts with the system at run time

You must specify an ABI for each CPU architecture that your application will use

Table 1. ABI and supported instruction set.

  • MIPS/MIPS64: Rarely used on mobile phones
  • X86 / X86_64: X86 mobile phones will include an instruction set dynamic transcoding tool called Houdini provided by Intel, which is compatible with ARM. So. Considering the market share of x86 is less than 1%, the two x86 related
  • Armeabi: ARM V5 This is a fairly old version that lacks hardware support for floating-point calculations and has performance bottlenecks when a large number of calculations are required
  • Armeabi-v7a: The current mainstream version of ARM V7
  • Arm64-v8a: 64-bit support

Specific meaning

If you are familiar with the basics, read the Introduction of Google Big Brother, you know: different cpus support different instruction sets. When we need our APP to support as many different cpus as possible, we only need to place different versions of SO files in different directories, and APK will be installed and run according to their own needs.

One problem with this, however, is that APK files are too large for users to download.

Can we just put a few?

Of course it can!

Let’s move on to what Google Big Brother has to say:

  • For best performance, compile directly against the main ABI. For example, a typical device based on ARMv5TE defines only the main ABI: the ArmeABI
  • In contrast, a typical ARMV7-based device defines the primary ABI as ArmeABI-V7A and the secondary ABI as armeABI because it can run the application’s native binaries generated for each ABI
  • Many x86-based devices also work with Armeabi-V7A and Armeabi NDK binaries
  • For these devices, the primary ABI will be x86 and the secondary ABI will be ArmeabI-V7A
  • A typical DEVICE based on MIPS defines only the main ABI: MIPS
  • When an application is installed, the Package manager service scans the APK for any shared libraries of the following form: 
    lib/<primary-abi>/lib<name>.so
Copy the code
  • If it is not found, and you have defined a secondary ABI, the service scans for shared libraries of the following form: 
    lib/<secondary-abi>/lib<name>.so
Copy the code
  • When the required libraries are found, the package manager copies them to /lib/lib.so under the application’s data directory (data/data/<package_name>/lib/)

Analysis of the

It says that if there is no shared object file at all, the application will also be built and installed, but will crash at run time. So sometimes we run into

Exception: Java. Lang. UnsatisfiedLinkError: dlopen failed: library "/ * * *. So" not foundCopy the code

The first thing we need to think about is whether the so file is not placed, or a.soo and B.soo are placed in Armeabi, but only B.soo is placed in Armeabi-v7a, not A.soo.

Arm64-v8a is backward-compatible, but there are limitations to arm64-V8A compatibility:

Below it is Armeabi-V7A, Armeabi; Armeabi-v7a is backward compatible with Armeabi. For a phone whose CPU is arm64-V8A, when running app, enter JNilibs to read library files, first look for arm64-v8A folder, if not, go to armeabi-v7a folder, if not, go to Armeabi folder. If not, throw an exception; If you have an arm64-V8A folder, look for a.so file with a specific name. If you have the arm64-v8a folder, look for the.so file with the specific name. Note: if you don’t find it, you don’t look down (armeabi-v7a) and throw an exception.

Note:

  1. If it is not found, it does not look further down (the Armeabi-v7a folder) and throws an exception.
  2. If your project uses third-party dependencies, it is recommended to include ndK. abiFilters in your Build if you only have one ABI
  3. Such as: Third party AAR files, if the SDK fully supports the ABI, may include armeabi, ArmeabI-v7A, x86, ARM64-V8A, and x86_64, while the other SO in your application only supports armeABI, Armeabi-v7A, and x86. An AAR that directly references the SDK automatically compiles packages that support the five ABI’s. However, the other SO of the application lacks support for the other two ABI’s, so if the application runs on devices with arm64-V8A and x86_64 as the preferred ABI, it will crash==.
defaultConfig {  
    ndk {  
        abiFilters "armeabi"// Specify that the NDK requires a compatible ABI(so that x86,armeabi, ARM-V8 and other dependencies are filtered out)}}Copy the code

conclusion

  1. If you want different versions of APK for different cpus, you can use fat binary and place different so files under different directories. This has wider compatibility and better performance, but larger APK;

  2. If you want a small APK, you can like Taobao, wechat, FaceBook, Twitter, one API to break the world, as to choose Armeabi, Armeabi-v7a depends on your market users. At present, the CPU of mainstream mobile phone mostly belongs to ArmeabI-V7A.

  3. Of course, you can also check the system environment dynamically, download the relevant library if it is x86, and then load…… This can reduce the APK volume.

Add an official account – programmers walking dogs, or scan the qr code below to follow relevant technical articles.