6. About Xamarin android APK packet size processing

The size of the APK package is very sensitive to everyone, although the performance and storage of the Android phone is becoming more and more powerful now. With a little bit less of an attitude, we're going to have a deep understanding of what's in the APK package that Xamarin generates.

Originally from: https://developer.xamarin.com/zh-cn/guides/android/advanced_topics/application_package_sizes/

This paper studies the Xamarin. Android application packages and related policies that can be used for efficient package deployment during the debug and release phases.

Overview

Xamarin.android uses a variety of mechanisms to minimize the APK package while ensuring an efficient commissioning and release process. In this article we will discuss the debug and release workflow of Xamarin.android and how the Xamarin.android platform ensures that we build a minimized apk package.

Publish a Package

To host a complete application, an APK package must contain an application set, dependent libraries, resource content, the Mono runtime, and some dependent base class libraries (BCL). For example, one of the "Hello World" compiled packages created by our default template contains the following:

15.8 MB is a much larger size than we want. The cause of this problem is the base Class library, which includes mscorlib, System, and Mono.android, which provide the components necessary to run the application. However, they also provide a lot of functionality that your application doesn't have, so it's best to exclude these components.

When we build an application for distribution, we execute a process called linking, which examines the application and removes any code that is not used directly. This process is similar to the functionality provided by the GC for allocating memory to the heap, but the difference is that one is acting on the object and one is acting on the link code. For example, there is a namespace in the system that is used to send and receive messages, but your application does not use this functionality, so this part of the code is a waste of space. When we run the link on the Hello World program, our package now looks like this:

as we have seen, this eliminates a large number of BCL that are not being used. Note that the final BCL size depends on what the application actually uses. For example, if we look at a more important example application Apidemo, we can see that the size of the BCL component has increased because Apidemo uses more BCL than Hello World:

, your application packages and dependencies will typically be larger than 2.9MB.

Debug Package

There are different ways of handling a build package for debugging. When you repeatedly deploy the APK to device debugging, the application needs to be as fast as possible, so we optimize the debug package for rapid deployment rather than control the size of the package. Android is relatively slow in copying and installing packages, so we want the size of the package to be as small as possible. As we discussed earlier, one way to minimize packet size is through the linker. However, the links are slow we typically only want to deploy parts of the application that have changed since the last deployment. To achieve this, we have separated the core xamarin.android components. When we first debugged the Android device, we copied 2 very large installation packages named shared Runtime and shared Platform. The Shared Runtime contains the Mono runtime and bcl,shared Platform contains specific assemblies for Android API levels:

Replicating the 2 core components only needs to be done once, because it takes a very long time, but allows subsequent applications to run in debug mode. Finally, the applications we actually replicate are small and fast:

Rapid deployment

Fast Assembly Deployment The (Rapid Deployment) compilation option will further reduce the size of the installation package in debug, not including the application set in the package. The installation package will only be installed once on your Android device, and only files that have been modified since the last deployment are copied.

To turn on fast Assembly Deployment (Quick Deploy), operate as follows:

1. Right-click on the Android project selection Properties under your solution

2. Select the Android option from the Properties dialog box:

3. Tick check Fast assembly deployment (using a shared Mono runtime checkbox) with the Share runtime (use Quick Deploy):

4. Click Save above to

The next time the application is built for debugging, the Assembly will be installed directly on the device (if it is not installed) and a smaller application package (excluding assemblies) will be installed on the device. This will shorten the time required to change the application and run the tests. By deploying shared runtimes and shared platforms for the first time, we can quickly and easily deploy new versions whenever we make changes to our applications, and we can have a quick change / Deploy / run cycle.

Summarize

This article only discusses some of the basic processing logic for packages. About signing and publishing is described in the next article.

6. About Xamarin android APK packet size processing