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.
Related
I try to understand why my app has a size of more than 250Mb which is huge.
When I analyse the APK, I see that all the versions of Achitecture are embedded inside.
Which version should I choose because I can't embed the 4:
Also: I have this setup may I optimize it? I need AOT and startup tracing to improve performance at stratup.
I have developed an app using Ionic 3 framework. I would like to measure the CPU and memory usage of my app. What is the best practice to do so?
You must not use AndroidStudio and XCode to measure the memory usage of the Ionic app.
Why? Here is the comment from Ionic team member
Unfortunately we have not been able to reproduce this issue on our
end. Would you mind checking your app on your device with safari dev
tools instead of the memory tool in xcode? The reason I recommend this
is because the xcode memory tools can be misleading in the fact that
it's not actually measuring memory usage of the javascript heap of the
app, instead, it is reading the memory used by the kernel / OS itself.
So based off the same concept I described here, the OS will not free
up memory used by the JS virtual machine if it 1. thinks the action
that used that memory is going to happen often and 2. thinks that it
has plenty of memory to spare. So, while the JS heap memory will be
shrinking every time the JS engine runs garbage collection, that does
not mean that the memory that iOS has allocated to the browser will
shrink, and, if iOS did start freeing up memory when it has plenty of
memory available you would actually see performance issues. Also, it's
important to remember that high memory usage does not === a memory
leak and in fact operating systems are built to take the most
advantage of the resources (in this case ram) available to it,
especially on mobile devices.
Tools:
Safari dev tools
Chrome dev tools
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.
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.
I'm looking for a tool which can monitor a running application (Win32/COM) for a long duration (1-3 days) and detect memory leaks if any. Any suggestions?
It is a .NET Windows application calling lots of unmanaged code.
You can try Memory Validator
iJeeves, the combination of BoundsChecker and .NET memory profiling should help you with your memory analysis. DevPartner Studio 10.5 ships February 4, 2011 with 64-bit application support. Depending on your application raw memory footprint, you may run x86 build configurations with the error dectection memory tracking analysis as long as you keep below the 2gb overall process virtual address limit, 3gb if you link the exe with LARGE_ADDRESS_AWARE and run on an x64 OS with extra RAM. The x64 build configuration will let you go up as high as your system RAM allows, at least until you start paging and performance grinds to a standstill. You can run BC error dection for your native code under the .NET process, but object leaks or held references in managed code require a second pass using the .NET memory profiler. We do not yet have a single pass analysis that can handle the mixed C++ and .NET code with full mixed stack traces but we can handle managed code above the line, any PInvokes that cross the line, and all native activity below the line in two passes. Shameless plug: I work on the DevPartner team. The links above pointing to microfocus.com acurately resolve to DevPartner pages. Look for DPS 10.5 when it ships and pull down the eval to see if it meets your needs.
AQTime is nice, I used it several times and it helped me with some tricky bugs.
I used to use Bounds Checker but nowadays I either use the Micrsoft inbuilt CRT library or build my own.
If your looking for a pay$'s tool then DevPartner is well worth using. It has memory leak detection for managed, and unmanaged code.
Application Verifier is free and from Microsoft. It detects memory leaks, double frees, overwrites and many other things. I use it all the time and it has helped me track down some nasty issues.