Through the comments from the great God in the comment section, I found that there was a big problem with my idea of packing before. I had thought that an APK could be a dynamic library containing several major CPU architectures. In fact, the best way is to type corresponding APK for different architectures, apK also contains only one architecture type SO. These APKs are then uploaded to the app store, which delivers apKS of the corresponding architecture according to users’ mobile phones.

The following content is mainly for Android apps. Want to understand the Ios related content of the left turn to find…. . In this article, the main method to slim down is to remove libflutter. So and libapp.so from the CPU architecture directory that is not needed in APK and use a sub-architecture package. Those who have mastered this method can also go out and turn left… .

Flutter packaging

Flutter build apk this should be our simplest Android package command

Dart is a release package with an entry of main.dart. Here’s what I saw when I decompiled a simple project into a release package.

x86_64
arm64-v8a
armeabi-v7a

X86_64 is generally used for emulators and tablets, arm64-V8A is the arm 64-bit, and it should be used for new phones now, but Android seems to support 64-bit after L, specific information can be searched by yourself (I will not mislead). As for Armeabi, although it is not the mainstream CPU architecture, it is compatible with higher versions, so mainstream apps can only use it if they only want to release one version. So we can remove the so files in the x86_64 and arm64-V8a directories when we launch the app.

But we want it to run on the emulator during development, so we can configure a different release and debug environment.

Optimization scheme

Configure build.gradle for Android

This approach, while effective, is not recommended unless you really want an APK with multiple so architectures.

(File location: Flutter project -> Andriod ->app->build.gradle)

 buildTypes {
        release {
           ...
            ndk{
                Armeabi = armeabi = armeabi = armeabi
                abiFilters "armeabi-v7a"
            }
        }
        debug {
	        ...
            ndk {
                // It is recommended to add or decrease the value of the simulator according to personal needs
                abiFilters  "armeabi-v7a"."arm64-v8a"."x86"}}}Copy the code

By executing the flutter build apk command, we can see that the whole flutter project has changed from around 24MB to 10MB and the x86_64 and arm64-v8a folders in the lib directory have been removed.

Note: armeabi-v7a cannot be written as armeabi. The first time I configured Armeabi, the package I typed was only 3MB, decompiled and there was no SO typed at all. Made me think it wasn’t going to work.

Shell command

How do I know this method? The flutter is telling you:

fat

You are building a fat APK that contains binaries for Android-ARM, Android-ARM64, and Android-X64. If you are deploying applications to the Play Store, it is recommended to use application bundles or split APK to reduce the size of the APK.

Here’s how to split according to the ABI (regardless of app bundle, just look at APK) :

flutter build apk --target-platform android-arm,android-arm64,android-x64 --split-per-abi
Copy the code

I made the packet after executing the above command:

--target-platform

We can also specify aemeabi-v7A only:

flutter build apk --release  --target-platform android-arm
Copy the code

This will type just as I configured it in build.gradle.

Hybrid project

This can also be used to reduce the AAR size when a FLUTTER needs to be packaged as a plug-in in a mixed development project.

flutter build aar --release  --target-platform android-arm
Copy the code

Bottom line: Flutter has a long way to go to slim down, and Android is very different from ios. Here is the record I stepped into the pit, is the simplest effect of the most direct method.