Why are android applications created by Xamarin so much bigger? Like my app took 40 MB of my SD card, and when I deleted that 40 MB the app didn't work, I had to reinstall the app. Even without the 40 MB there were still 7 MB of the app, while in java, the same simple app took only 3 MB, am I missing something or doing something wrong that my apps are deployed huge?
Xamarin apps have to package the .NET runtime with each individual app. Debug versions of the app are by default bigger; release versions should be smaller, and there are techniques you can use to minimize their size further.
This is discussed in detail here.
In order to build and deploy your application faster, Xamarin are packaging the mono runtime and storing it on the SD Card. This can be turned on or off from Project options -> Android Build -> Use Shared Mono Runtime. Additionally, when you build for release, the linker will strip unused code and will trim the size down.
Nevertheless, despite all the optimizations, there is an inevitable 2-3 MB overhead due to the Mono runtime and BCL packages. Still, once your application gets sufficiently complex, this overhead becomes negligible compared to the total application size.
Related
So I have got a Xamarin.Android application and a Sencha application.
Both are exactly the same application just developed on two different frameworks.
Now the Sencha application consumes around 60mb - 100mb RAM and the Xamarin app, on the other hand, takes 100mb - 250mb of RAM.
I understand that due to Mono.Android runtime the Xamarin App is supposed to take much memory, so I created a blank app on Xamarin.Android and it takes approx 90mb - 100mb memory.
So my question is how can I reduce the memory usage by the Xamarin app? Or is it normal to have this kind of RAM usage on a Xamarin Application?
Is there any reference point which I can consider in order to benchmark my application's RAM usage?
What is the general RAM usage by Enterprise applications, developed on Xamarin?
Please note that all these RAM usage statistics are collected using the Android Studio Profiler.
To reduce Xamarin android application memory usage, do followings:
1- Use liker (Link All is better) to reduce loaded assemblies into memory.
2- Use AOT/LLVM to remove JIT overhead including memory usage.
I have a Xamarin Forms app that is currently on the App Store that I built and submitted in October 2016 (with what I assume was the latest versions of Xamarin Studio and Xamarin.iOS back then). The app has a size of 50 mb on the App Store.
After doing a few updates to the app, I build it now (AppStore config, then Archive) and the size is 82 mb. Confused by this balloon in size, I switched back to the git tag of the version that is currently in the App Store. I can build the same exact tag/version/code for that October 2016 release and it's App Store size is now 80 mb.
I am using the latest Xamarin Studio (6.3 build 863), Xamarin.iOS (10.8.0.175), etc.
Why has the size grown by 60%? No application code or libraries have changed, only newer versions of Xamarin Studio and Xamarin.iOS. How do I figure out what is going on here? I can do an Add-Hoc build on my device and see that is only taking up ~55 mb, very close to what I see from the App Store.
Also, note that I am not comparing the .ipa size. I am comparing the "Estimated App Store Size" shown from the archive screen in Xamarin Studio after archiving a build. The same size difference is reflected after submitting the signed build via application loader to iTunes Connect and verifying from iTunes Connect > Activity > All Builds > App Store File Sizes.
Update Sept 5th 2017
Not sure what changed but now with the latest version of Xamarin iOS, Version: 10.12.0.20 (just updated), my app size is now back down in the 60mb range... Didn't change anything else.
I can do an Add-Hoc build on my device and see that is only taking up ~55 mb,
You likely have some different options between your configuration, e.g.
managed linker settings, e.g. Don't link versus Link SDK;
targeted architectures, e.g. armv7+arm64 versus armv7+armv7s+arm64;
How do I figure out what is going on here?
Compare your build logs, in particular the options given to the mtouch tool. That will generally pinpoint the difference quickly.
I am comparing the "Estimated App Store Size"
Always compare the IPA (file) size. The algorithm to guess the final size is known to be often (very) wrong. The estimation also comes from Apple's tools so they will vary with the version of Xcode you're using (which is unlikely to be identical to the one you used last fall).
Side note: the final size is even trickier to guess when bitcode is enabled (which is only for tvOS and watchOS builds right now).
My guess is that xamarin is packing a lot of unneeded stuff, maybe old images or similar that you are no longer using. I have experienced that myself.
Go to you project folder and delete everything in the obj folder
<myproject>/iOS/obj/
Usually you will see two folders in there: iPhone and iPhoneSimulator.
Delete those and build everything again, there's a good chance that will solve it
Are you using the same version of Xamarin to build your code. I am willing to bet that is the issue. Something changed in how Xamarin builds apps since the last time you released it and is blowing up your app build size.
If you actually have the same code you released back then do you know what version of Xamarin you used back then? Honestly since the only thing that's changed is the Xamarin compiler it is most definitely the issue.
There are four things to do:
DELETE bin and obj folder from client project
CHANGE architecture to only support 64
CONFIGURE the linker.
Best is to try and build your app with linker active, but the more nuget packages you use, the less likely this is
and most importantly:
Set your build config to RELEASE and not DEBUG
(if you forget that, stores will accept your app but size can easily be doubled or even trippled)
This is how the minimal setup should look like:
Then dont forget that XAMARIN adds libraries like crazy to your app. I once read that the smallest app with NO content at all is at least 7 MB. This only gets larger with each package and each new dependency.
I am planning to develop an app for emerging market with low internet bandwidth. The app heavily requires an internet connection to function.
I need this app to have a small apk size (not more than 10mb) and work on 3G network.
Based on my research if I remove x86 JS binary files from React Native the apk size could be as small as 4mb. I suppose the 4mb does not include the JS files and images so client needs to download that first time when he/she opens the app, is that correct?
Would it in general be a good idea for me to use React Native if I want an app with less than 10mb apk size that works on 3G and what are the best practices to make it efficient?
Instead removing js which have very less impact you should go after binary resources such as font and embedded images.
Apart from that these are following techniques that may work for you:
1) Enabling Proguard:
To enable Proguard, edit android/app/build.gradle:
def enableProguardInReleaseBuilds = true
Generate Separate Builds:
2) In your app/build.gradle set
def enableSeparateBuildPerCPUArchitecture = true
3) Remove x86 from abiFilters
Following are references to links that you may find useful:
Blog on decreasing size of apk:
https://realm.io/news/reducing-apk-size-native-libraries/
Link one of smallest RN app on play store:
https://github.com/sonnylazuardi/ziliun-react-native
Useful discussion on React Native Issue regarding apk size:
https://github.com/facebook/react-native/issues/5037
If you just want the app with lower app size, Use native platform itself. Minimum size of the native android app will be 1 MB. You can't reduce the size of the react native app lesser than 4 MB.
Currently our Xamarin Android app (PCL) is huge in my opinion, even in release mode. I suspect it is due to supported architectures. Currently we have them all selected. Does anyone know if we have to select all of these? We are not using the Android NDK at all as well.
I will copy part of my answer from here.
Make sure you are at least checking the following architectures: armeabi-v7a and x86. You could do the other three but we do not since we use LLVM compiling in release mode, which is not compatible with the 64 bit architectures (except for armeabi, which is deprecated). The good thing about that is that all of the 64 bit architectures can still use 32 bit builds so they all still get covered if you check those 3.
So I would just check those 3 unless you have a specific reason to check the other ones. We have had 0 problems installing our app on devices using those 3 only.
On a side note, turning on LLVM compiling and optimizing your icons/images will help with the final APK size.
*Edit: Since writing this we ran into a bug only on certain devices (Android Nexus 9) which leads to app crashes when launching the app. The solution is to check the arm64-v8a architecture. This will probably increase app size so weigh the pros and cons and see how much of a difference it makes in your APK size after including the architecture or split your APK for each architecture if necessary.
No you do not have to select all of them. You can create an .apk per ABI if you wanted to to reduce the size of your .apk. Note: The encouraged method is that you develop and publish a single .apk. However this is not always practical, and sometimes it's better to create separate ones. Although this answer only goes into depth about different CPU Architectures (ABI), you could also create different .apk for screen size, device features, and API levels.
https://developer.xamarin.com/guides/android/advanced_topics/build-abi-specific-apks/
http://developer.android.com/google/play/publishing/multiple-apks.html
I would recommend grabbing a tool like WinDirStat(https://windirstat.info/) or Disk Inventory X(http://www.derlien.com/) to investigate why your .apk is so large. You might find other reasons why your .apk is large such as resources(images, raw files), assemblies, etc.
I am using Xcode 4.2 on a relatively large project (a few ten thousand lines of code) and it is horribly slow. Editing is ok, but whenever I try to compile the project (in Xcode, or with xcodebuild on the command line), my machine (quad core i7 MacBook Pro, 4 GB RAM) crawls to a halt. I have noticed that directly after starting xcodebuild, it spawns more than 8 clang processes, without the "real" compile processes starting. No xcodebuild output is so far seen on stout. I've tried reducing the number of parallel build processes, but still lots of clang processes are launched at the beginning. The project uses 6 or 7 direct dependent external projects and has maybe 120 source files. Under Xcode 3.2 the project used to be compiled very quickly. What's happening? And how can I make Xcode fast again?
Most of us have three primary options:
Revert to Xcode 3 for daily development.
Throw more hardware at it.
Change your projects' structures and apply large scale development tricks (even though 20-30 KSLOC is not large).
The easiest solution is revert to Xc3. Yes, Xc4 requires a lot more than Xc3; memory, CPU, and disk space and I/O. You will have to determine where your biggest problems are to reduce the amount it affects you.
I recently bought a new MBP with twice the physical cores and twice the physical memory, upgraded to Lion and upgraded Xc4 at the same time. The compilation times did improve, but much of the rest is actually slower, and far more resource hungry. That's not at all what one would expect from an IDE which also disallows multiple open projects and also uses a unified workspace view.
The move to Lion + Xc4 more than doubled my hardware demands in all of the following categories:
Memory
4GB is now too little for most nontrivial projects using Xc4 and Lion. You can still reduce this. I have 8GB and 10GB on my main 2 machines, Xc4 consumes it all quite easily (but my projects are more complex than yours, unless you write reeaeaaaally long lines). Anyways, You can reduce this problem by:
Buying more memory.
Disable indexing if you are building out huge projects in Xcode. This can halve Xcode's memory consumption.
Running Xcode in 32 bit. This is not an option for everyone, because it will exceed 4 GB in larger projects.
Reduce the number of build processes (again).
Restarting Xcode often (It doesn't do a very good job cleaning up after itself).
Use clang as your compiler. Clang instances in general use less memory than Apple's GCC 4.2.
Offload dependent targets which do not change often. Example: You will not need to rebuild third party libraries daily in most cases.
CPU
Xcode 4 uses a new (more accurate) completion parser.
Pare down your include dependency graphs, and dependencies. This is quite easy to with Obj-C, since every Obj-C instance is a pointer. Example: remove loosely dependent framework includes from your headers.
Separate your dependencies and modules properly. Develop libraries, but try to make them fairly small and be aware of the dependencies they will add. Example: I lead a project where a dev added a small feature (less than 1% of the app), but due to the number of dependencies it required (e.g. Three20 and then a few more), the binary size of the final executable doubled (and the build times went up, and the parser had a lot more work to do). Most of this was not needed for the feature - they just could not be stripped because they were objc symbols.
Reduce translation counts, if possible.
Optimize how you use prefix headers. You can share them, and you can create them for no good reason. This benefits the compiler more than the IDE.
Minimize memory usage. GC work (including all NSObject allocs) consumes over 1/3 of the CPU usage in larger projects, but it still spends a lot of time collecting when its heap is huge.
Use external text editors and VC clients. Pretty obvious because Xc4 displays the SBBOD rather often in large projects.
Minimize language complexity. In order of complexity: C, ObjC, C++, ObjC++. The more complex the translations, the longer it will take to parse and compile your sources, especially when your dependencies are high. If you can easily set up language barriers in your dependencies, do so.
You can disable code sense indexing via defaults (also reduces memory demands).
Hard Disk
This can be a speed/size balance.
Buy a faster one (e.g. SSD).
Cleanup and minimize your header dependencies.
Use a RAM Disk, such as Make RAM Disk.
Buy more memory. With the amount Xc4 consumes, it ends up swapping out to disk often in large projects.
Optimize your builds to use pch files appropriately. This is not always the obvious direction: I have not used them for several years in large projects.
Clear out the temp files Xcode and Instruments leave behind, they can be huge. In some cases, you can save them in customized locations. If they do consume tens of GB and your build dir is the same as your boot dir, then you will make your disk work a lot less by cleaning them up regularly.
Builds
In Xc4, xcodebuild parallel to Xcode now doubles the work (separate build dirs by default). In Xc3, the default was to build to the same destination. Verify your settings - Xcode will do a ton of redundant building, if you allow it (e.g. one target per workspace/config, rather than Xc3's flat build model).
Or just fill a drawer with quad core MacMinis and use that as a dedicated or distributed builder.
File Bugs
(self explanatory)
One more possible solution that in some cases might help speed up Xcode 4: In my case, the main problem seems to have been that accidentally four files from my build/ folder had been checked in with my git repository. During compilation Xcode notices that the build folder changed, and triggers git. Since the build folder contains thousands of files in my case, the performance went down. Removing the build/ folder completely from git (shouldn't have been checked in anyway) reduced the compilation times and system load massively. Performance is still slower than with Xcode 3, but much better than before.
You can switch on Distributed Building in XCode Preferences, and find some friendly person who will help you build your app by forming compilation machines cluster with you.
The funny thing is that even he is off, your compiler still uses different algorithm/mechanism to build you app in a blazing speed if compared to the problems before ;)
So, that means that they at Apple have forgotten about lonely programmers who don't work in teams and therefore lonely compilation scenario is purely tested in versions 4.0 - 4.2
Quick Note Regarding 'Throw more hardware at it' approach..
SUMMARY: I experienced a SMALL speed increase from making a SIGNIFICANT hardware upgrade
Test: Build/Run the exact same project on cloned macbooks (where the only difference should be their hardware)
Old Macbook Air (1.86GHZ Core 2 Duo ONLY 2GB RAM)
vs
Brand New Macbook Pro (2.3GHZ Core i7 8GB RAM)
BUILDING ON IPHONE 3GS
Macbook Air 1:00 - 1:15
Macbook Pro ~1:00
=> 0 to 0:15 of speed increase
BUILDING ON IPHONE 4S
Macbook Pro ~0:35
Macbook Air ~0:50
=> ~15 seconds of speed increase
**Partially tested: There DOES apear to a significant difference between build times for the SIMULATOR between the 2 machines
Another culprit for slowness is plugins. The Subversions plugin was absolutely killing my Xcode performance. I followed the instructions in this SO post to disable it. WHEW!