標籤:模板 and data- 運行 工作流程 sys 相關 demo android平台
apk 包的大小對大家都是很敏感的,雖然現在安卓手機的效能和儲存越來越厲害了。本著能少一點是一點的態度,我們還是要深入理解下xamarin 產生的apk包裡面有那些內容。
原文來自於:https://developer.xamarin.com/zh-cn/guides/android/advanced_topics/application_package_sizes/
本文研究了Xamarin.Android應用程式套件組合和相關策略,可用於在調試和發布階段進行高效的包部署。
概述
Xamarin.Android 使用了多種機制來最小化apk包,同時保證高效率的調試和發布過程。在這篇文章中我們將討論Xamarin.Android的調試和發布工作流程以及Xamarin.Android平台如何確保我們構建最小化的apk包。
發布包
要承載一個完整的應用程式,一個apk包裡面必須包含應用程式集,相關依賴庫,資源內容,Mono運行時,以及一些依賴的基礎類庫(BCL)。比如說,我們預設範本建立的一個“Hello World” 編譯後的包就包含如下:
15.8 MB是一個比我們想要的大得多的尺寸。 造成這個問題的原因是基礎類庫,其中包括 mscorlib, System, 和Mono.Android,等提供運行應用程式所必須的組件。但是,它們也提供了很多你應用程式用不到的功能,因此最好排除掉這些組件。
當我們構建一個用於分發的應用程式時,我們執行一個名為Linking的過程,它檢查應用程式並刪除不直接使用的任何代碼。這個過程類似於GC為堆分配記憶體提供的功能,但是不同的地方在於一個是作用於對象,一個是作用於連結代碼。 例如,系統中有一個命名空間是用於發送和內送郵件的代碼,但是你的應用程式並沒有使用這個功能,那麼這個部分的代碼就是浪費空間。當我們在Hello World程式上運行連結後,我們的包現在看起來如下:
正如我們所看到的,這消除了大量不被使用的BCL。注意,最終的BCL大小取決於應用程式實際使用的內容。 例如,如果我們查看一個更重要的應用程式範例ApiDemo,我們可以看到BCL組件的大小增加了,因為ApiDemo使用的BCL比Hello World多得多:
,通常您的應用程式套件組合和依賴項都會大於2.9MB。
調試包
對於調試構建包而言,處理的方式會有所不同。當重複部署APK到裝置調試時,應用程式需要儘可能快,因此我們最佳化調試包以實現快速部署而不是控制包的大小。Android在複製和安裝包方面相對較慢,所以我們希望包的大小儘可能小。正如我們前面討論的,最小化包大小的一種方法是通過連結器。但是,連結很慢我們通常只想部署自上次部署以來已經更改的應用程式的部分。為了實現這個,我們分離了核心的Xamarin.Android組件。當我們第一次調試安卓裝置的時候,我們會複製2個非常大的安裝包名叫 Shared Runtime 和 Shared Platform。Shared Runtime 包含了 Mono Runtime 和BCL,Shared Platform 包含了Android API 層級的特定的程式集:
複製這2個核心的組件只需要完成一次,因為它需要非常長的時間,但是允許後續應用程式在偵錯模式下運行使用。最後我們實際複製的應用程式是小而快的:
快速部署
Fast Assembly Deployment (快速部署)編譯選項將進一步減少調試中安裝包大小,不包括程式包中的應用程式集 。安裝包只會在安卓裝置中安裝一次,並且只複製上次部署以來修改過的檔案。
開啟 Fast Assembly Deployment(快速部署), 操作如下:
滑鼠右鍵點擊你解決方案裡下的安卓項目選擇屬性
從屬性對話方塊中選擇Android 選項 :
勾選使用共用運行時(Use shared Mono runtime checkbox )同時勾選 Fast assembly deployment(使用快速部署) :
點擊上方的儲存即可
下次為調試構建應用程式時,程式集將直接安裝在裝置上(如果還沒有安裝的話)和一個較小的應用程式套件組合(不包括程式集)將安裝在裝置上。這將縮短更改應用程式和運行測試所需的時間。通過首次較長時間部署共用運行時和共用平台,這樣每次我們對應用程式變更時,我們就可以快速輕鬆地部署新版本,我們就可以有一個快速的變更/部署/運行周期。
總結
本文只討論了關於包的一些基本處理邏輯。關於簽名與發布在下一篇文章中進行介紹。
6.關於Xamarin Android對APK包大小的處理