애플리케이션 패키지 크기Application Package Size

이 아티클에서는 배포의 디버그 및 릴리스 단계에서 효율적인 패키지 배포에 사용할 수 있는 관련 전략과 Xamarin.Android 애플리케이션 패키지의 구성 요소를 살펴봅니다.This article examines the constituent parts of a Xamarin.Android application package and the associated strategies that can be used for efficient package deployment during debug and release stages of development.


Xamarin.Android는 다양한 메커니즘을 사용하여 패키지 크기를 최소화하는 한편 효율적인 디버그 및 릴리스 배포 프로세스를 유지합니다.Xamarin.Android uses a variety of mechanisms to minimize package size while maintaining an efficient debug and release deploy process. 이 아티클에서는 Xamarin.Android 릴리스 및 디버그 배포 워크플로를 살펴보고, Xamarin.Android 플랫폼으로 소형 애플리케이션 패키지를 빌드하고 릴리스하하는 방법을 살펴봅니다.In this article, we look at the Xamarin.Android release and debug deployment workflow and how the Xamarin.Android platform ensures that we build and release small application packages.

릴리스 패키지Release Packages

완전히 포함된 애플리케이션을 제공하기 위해 패키지에는 애플리케이션, 관련 라이브러리, 콘텐츠, Mono 런타임 및 필요한 BCL(기본 클래스 라이브러리) 어셈블리가 포함되어야 합니다.To ship a fully contained application, the package must include the application, the associated libraries, the content, the Mono runtime, and the required Base Class Library (BCL) assemblies. 예를 들어 기본 "Hello World" 템플릿을 사용할 경우 전체 패키지 빌드의 콘텐츠는 다음과 같이 표시됩니다.For example, if we take the default “Hello World” template, the contents of a complete package build would look like this:

링커 실행 전 패키지 크기Package size before linker

15.8MB는 예상보다 더 큰 다운로드 크기입니다.15.8 MB is a larger download size than we’d like. 문제는 BCL 라이브러리입니다. mscorlib, System 및 Mono.Android를 포함하고 있고, 애플리케이션을 실행하는 데 필요한 많은 구성 요소를 제공하기 때문입니다.The problem is the BCL libraries, as they include mscorlib, System, and Mono.Android, which provide a lot of the necessary components to run your application. 그러나 사용자가 애플리케이션에서 사용하지 않을 수 있는 기능도 제공하므로 이러한 구성 요소는 제외하는 것이 좋습니다.However, they also provide functionality that you may not be using in your application, so it may be preferable to exclude these components.

배포용 애플리케이션을 빌드할 때는 애플리케이션을 살펴보고 직접 사용되지 않는 코드를 제거하는 연결이라고 하는 프로세스를 실행합니다.When we build an application for distribution, we execute a process, known as Linking, that examines the application and removes any code that is not directly used. 이 프로세스는 가비지 수집에서 힙 할당 메모리에 제공하는 기능과 유사합니다.This process is similar to the functionality that Garbage Collection provides for heap-allocated memory. 단, 연결 프로세스는 개체를 통해 작동하지 않고 코드를 통해 작동합니다.But instead of operating over objects, linking operates over your code. 예를 들어 System.dll에 이메일을 주고받는 데 사용되는 완전한 네임스페이스가 있지만 애플리케이션에서 이 기능을 활용하지 않는 경우 해당 코드는 공간 낭비일 뿐입니다.For example, there is a whole namespace in System.dll for sending and receiving email, but if your application does not make use of this functionality, that code is just wasting space. Hello World 애플리케이션에서 링커를 실행한 후 패키지의 모습은 다음과 같습니다.After running the linker on the Hello World application, our package now looks like this:

링커 실행 후 패키지 크기Package size after linker

보시다시피 이는 사용하지 않는 BCL 공간을 상당 부분 제거해 줍니다.As we can see, this removes a significant amount of the BCL that was not being used. 최종 BCL 크기는 애플리케이션에서 실제로 사용하는 구성 요소에 따라 달라집니다.Note that the final BCL size is dependent on what the application actually uses. 예를 들어 ApiDemo라는 좀 더 견고한 샘플 애플리케이션을 살펴보면 ApiDemo가 Hello, World보다 BCL을 더 많이 사용하기 때문에 BCL 구성 요소의 크기가 증가한 것을 알 수 있습니다.For example, if we take a look at a more substantial sample application called ApiDemo, we can see that the BCL component has increased in size because ApiDemo uses more of the BCL than Hello, World does:

연결 후 ApiDemo 패키지 크기

여기에 설명된 것처럼 애플리케이션 패키지 크기는 일반적으로 애플리케이션과 종속성보다 큰 약 2.9MB가 됩니다.As illustrated here, your application package size will generally be about 2.9 MB larger than your application and its dependencies.

디버그 패키지Debug Packages

디버그 빌드에서는 처리 방식이 약간 달라집니다.Things are handled slightly differently for debug builds. 디바이스에 반복적으로 재배포하는 경우 애플리케이션의 속도가 가능한 빨라야 하므로 디버그 패키지는 크기보다는 배포 속도에 맞게 최적화됩니다.When redeploying repeatedly to a device, an application needs to be as fast as possible, so we optimize debug packages for speed of deployment rather than size.

Android는 상대적으로 패키지를 복사하고 설치하는 속도가 느리므로 패키지 크기를 가능하면 작게 유지하는 것이 좋습니다.Android is relatively slow to copy and install a package, so we want the package size to be as small as possible. 위에서 설명한 것처럼 패키지 크기를 최소화할 수 있는 한 가지 방법은 링커입니다.As we discussed above, one possible way to minimize package size is via the linker. 하지만 연결은 속도가 느리고, 일반적으로 마지막 배포 이후에 변경된 애플리케이션의 일부만 배포하는 것이 좋습니다.However, linking is slow and we generally want to deploy only the parts of the application that have changed since the last deployment. 이를 위해서는 핵심 Xamarin.Android 구성 요소와 애플리케이션을 구분합니다.To accomplish this, we separate our application from the core Xamarin.Android components.

디바이스에서 처음 디버깅할 때는 공유 런타임공유 플랫폼이라는 대규모 패키지 두 개를 복사합니다.The first time we debug on device, we copy two large packages called Shared Runtime and Shared Platform. 공유 런타임에는 Mono Runtime 및 BCL이 포함되고, 공유 플랫폼에는 Android API 수준별 어셈블리가 포함됩니다.Shared Runtime contains the Mono Runtime and BCL, while Shared Platform contains Android API level specific assemblies:

공유 런타임 패키지 크기Shared runtime package size

이러한 핵심 구성 요소를 복사하는 작업은 시간이 상당히 오래 걸리므로 한 번만 수행하며, 그래도 디버그 모드에서 실행 중인 모든 후속 애플리케이션이 이러한 구성 요소를 활용할 수 있습니다.Copying these core components is only done once as it takes quite a bit of time, but allows any subsequent applications running in debug mode to utilize them. 마지막으로, 작고 빠른 실제 애플리케이션을 복사합니다.Finally, we copy the actual application, which is small and quick:

실제 애플리케이션은 작습니다.

빠른 어셈블리 배포Fast Assembly Deployment

빠른 어셈블리 배포 빌드 옵션은 애플리케이션의 패키지에 어셈블리를 포함하지 않고, 디바이스에 한 번만 바로 어셈블리를 설치하고, 마지막 배포 이후로 수정된 파일에만 복사하여 디버그 설치 패키지의 크기를 더 줄이는 데 사용할 수 있습니다.The Fast Assembly Deployment build option can be used to further decrease the size of the debug install package by not including the assemblies in the application's package, installing the assemblies directly on the device only once and only copying over files that have been modified since the last deployment.

빠른 어셈블리 배포를 활성화하려면 다음을 수행합니다.To enable Fast Assembly Deployment, do the following:

  1. 솔루션 탐색기에서 Android 프로젝트를 마우스 오른쪽 단추로 클릭하고 옵션을 선택합니다.Right click on the Android Project in the Solution Explorer and select Options.

  2. 프로젝트 옵션 대화 상자에서 Android 빌드를 선택합니다.From the Project Options dialog select Android Build :

    프로젝트 옵션 Android 빌드

  3. 공유 Mono 런타임 사용 확인란과 빠른 어셈블리 배포 확인란을 선택합니다.Check the Use shared Mono runtime checkbox and the Fast assembly deployment checkboxes:

    패키징 탭 아래에서 선택된 확인란

  4. 확인 단추를 클릭하여 변경 내용을 저장하고 프로젝트 옵션 대화 상자를 닫습니다.Click the OK button to save the changes and close the Project Options dialog.

다음에 애플리케이션이 디버그용으로 빌드될 때 어셈블리가 디바이스에 바로 설치되고(아직 설치되지 않은 경우) 소형 애플리케이션 패키지(어셈블리를 포함하지 않는)가 디바이스에 설치됩니다.The next time the application is built for debug, the assemblies will be installed directly on the device (if they haven't already been) and a smaller application package (that does not include the assemblies) will be installed on the device. 따라서 테스트를 위해 실행 중인 애플리케이션에 변경 내용이 적용되는 데 걸리는 시간이 단축됩니다.This will shorten the time it takes to get changes to the application up and running for testing.

공유 런타임 및 공유 플랫폼의 긴 첫 배포를 완료하면 애플리케이션을 변경할 때마다 새 버전을 쉽고 빠르게 배포할 수 있으므로 변경/배포/실행 주기가 단축됩니다.By enduring the long first deploy of the shared runtime and shared platform, every time we make a change to the application, we can deploy the new version quickly and painlessly, so we can have a fast change/deploy/run cycle.


이 아티클에서는 Xamarin.Android 릴리스 및 디버그 프로필 패키징의 패싯을 살펴보았습니다.In this article we examined the facets of Xamarin.Android Release and Debug profile packaging. 또한 Android 플랫폼용 Mono에서 배포의 디버그 및 릴리스 단계에서 효율적인 패키지 배포를 촉진하기 위해 사용하는 전략도 살펴보았습니다.Additionally, we looked at the strategies that the Mono for Android platform uses to facilitate efficient package deployment during debug and release stages of development.