Skip to content
This repository has been archived by the owner on Jul 19, 2024. It is now read-only.

Will these libraries increase the app size? #5

Open
abdu292 opened this issue Dec 27, 2016 · 11 comments
Open

Will these libraries increase the app size? #5

abdu292 opened this issue Dec 27, 2016 · 11 comments

Comments

@abdu292
Copy link

abdu292 commented Dec 27, 2016

I am now re-writing one of my existing apps to use the animation, dialogs and other cool features of this BikeSharing app. However seeing the amount of libraries I had to install I am a little bit concerned/worried as to how much will be size of the app when I ship it on to the store (all the three platforms, mainly android). Will all these libraries (acr, unity, plugin, user dialogs, ffimage, fonts, etc) will be too much in size even after performing linking & ProGuard etc..? Did we already try release build for Bikesharing app? May I know what is the size of installation package on each platform?

@jerinjohnk
Copy link

Am in the process of creating a framework like Template10 using this as base. Since I started Xamarin few weeks ago only and this is a great reference.
When I ran Droid version the release package size (with unchecked Use Shared Runtime option found in Android Options of Properties) was almost 35 mb.
I made some changes removed almost all images along with Card.io from component and some pages reduced the size to 25mb(with unchecked Use Shared Runtime).
And (with checked Use Shared Runtime) size became 10mb.

These Nuget packages are only KB in size so don't contribute much to appsize(except Card.io).

Here is the current nuget packages being used in Droid version 10mb one.

<?xml version="1.0" encoding="utf-8"?>
<packages>
  <package id="Acr.Support" version="2.1.0" targetFramework="monoandroid51" />
  <package id="Acr.UserDialogs" version="6.2.3" targetFramework="monoandroid51" />
  <package id="AndHUD" version="1.2.0" targetFramework="monoandroid51" />
  <package id="CommonServiceLocator" version="1.3" targetFramework="monoandroid60" />
  <package id="Plugin.CurrentActivity" version="1.0.1" targetFramework="monoandroid60" />
  <package id="Splat" version="1.6.2" targetFramework="monoandroid51" />
  <package id="Xam.Plugins.Settings" version="2.5.1.0" targetFramework="monoandroid60" />
  <package id="Xamarin.Android.Support.Animated.Vector.Drawable" version="23.3.0" targetFramework="monoandroid51" />
  <package id="Xamarin.Android.Support.Design" version="23.3.0" targetFramework="monoandroid51" />
  <package id="Xamarin.Android.Support.v4" version="23.3.0" targetFramework="monoandroid51" />
  <package id="Xamarin.Android.Support.v7.AppCompat" version="23.3.0" targetFramework="monoandroid51" />
  <package id="Xamarin.Android.Support.v7.CardView" version="23.3.0" targetFramework="monoandroid51" />
  <package id="Xamarin.Android.Support.v7.MediaRouter" version="23.3.0" targetFramework="monoandroid51" />
  <package id="Xamarin.Android.Support.v7.RecyclerView" version="23.3.0" targetFramework="monoandroid51" />
  <package id="Xamarin.Android.Support.Vector.Drawable" version="23.3.0" targetFramework="monoandroid51" />
  <package id="Xamarin.FFImageLoading" version="2.1.8" targetFramework="monoandroid60" />
  <package id="Xamarin.FFImageLoading.Forms" version="2.1.8" targetFramework="monoandroid60" />
  <package id="Xamarin.FFImageLoading.Transformations" version="2.1.8" targetFramework="monoandroid60" />
  <package id="Xamarin.Forms" version="2.3.3.152-pre2" targetFramework="monoandroid70" />
</packages>

I know this doesn't answer your question completely but since its been 15 days so thought of sharing my view. Probably a contributor would answer this much better.

@abdu292
Copy link
Author

abdu292 commented Jan 12, 2017

Thank you @jerinjohnk for taking time to let me know this. Much appreciated. Happy to know these packages are lightweight.

I understand the size you end up is after "Linking" and "ProGuard" ing. Let me know if that is that correct.

@jerinjohnk
Copy link

Yes linking was set to SDK Assemblies only but proguard wasn't enabled.
I tried enabling proguard just now but unluckily no .cfg or proguard files were generated. So I think proguard didn't run.

@abdu292
Copy link
Author

abdu292 commented Jan 14, 2017

@jerinjohnk Thank you. I have only read about Linking & ProGuard and have not used it yet, that's why I did not get right a way from your first post. Sorry about that.
Thank you for taking time to respond. Much appreciated. I believe after "ProGuard" it may come down a little more.
(Sorry for the late response, was too busy)

@abdu292
Copy link
Author

abdu292 commented Mar 28, 2017

@jerinjohnk I think for release build we need to uncheck "Use Shared Runtime". Do you know if that's correct? If so, the size is still bigger. Isn't it?

After all the hard work when I tried to create the release package I found it as 24mb after linking (where it was only 5mb apk in debug).
Everything like performance, development are good, however size is the only once concern for me right now. Users tent to avoid such bulky apps. Any one knows if Microsoft is already working to get the app size reduced?

@jerinjohnk
Copy link

jerinjohnk commented Mar 28, 2017

Even the app that I built was 23MB usually we use it for B2B apps and not for store apps.(trying react native to compare size).
You can check out this Post to reduce app size.
It depends on your app, resources inside, etc. 23mb is pretty normal. Anything under 50mb is pretty normal. You can inspect your APK using a tool like windirstat or similar to see what inside your APK is taking up the most space. There's also a great guide on this Here

@abdu292
Copy link
Author

abdu292 commented Mar 29, 2017

Thank you @jerinjohnk . The posts are very much beneficial. I actually did almost all the things in the first post. Linking SDK & User Assembly does reduce a few more MBs, however it doesn't seem to be working. App crashes all the time. Trying to find a way to debug this.

Let us know what you find with React Native. A quick googling reveals that the minimum size will be 4mb as RN has to include JSRuntime with the package. I am a full stack developer, and I have been working on AngularJS for years now.. I personally WILL NEVER go with any JS frameworks for development other than web development, given it is a massive mess to develop, debug & maintain the app. I love JavaScript and TypeScript to develop web apps. However C# is much better than JS/HTML/CSS for anything other than web. Ignore if you are a grounded JS dev. I just thought to share something from experience.

@jerinjohnk
Copy link

jerinjohnk commented Mar 29, 2017

I think I had used "link sdk only" as it was the safest and it was running perfectly without any crashes.
I have been a windows app developer from beginning. So C# and VS are something that I live by.
So Xamarin Forms feels much easier than React Native. But one thing I like about react native is Live Reload saves a lot of time.

@abdu292
Copy link
Author

abdu292 commented Mar 29, 2017

@jerinjohnk Agree. However Xamarin.Forms previewer - this is yet to be stable I think, Gorilla Player (if you are using forms), Xamarin.Workbook are doing very similar thing to save us a lot of time. I think it is a nice idea to use Windows Mobile first (though Android & iOS may be our primary focus) as I think it gives very descriptive error message, great debug deploy cycles etc. while working on Xamarin.Forms. Also I believe debugger in UWP environment provides Edit & Continue feature (not yet tried, but remember seeing a demo somewhere).

@jerinjohnk
Copy link

Hi looks like its turning into a discussion now here is my email id we can discuss it further there.

@abdu292
Copy link
Author

abdu292 commented Mar 29, 2017

Sure. Thanks a bunch!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants