I am using a remote desktop having configured Win 8.1, 3gb ram DDR2, 15gb HDD free space, latest Xamarin Studio Starter version with api 21 packages. When I try to debug a simple "Hello World" solution on studio, the manually created AVD loads too slow, even android home screen does not appear after 1 hour. What should I do to speed up the process ?
I don't know if your IDE supports it but you should really try out Genymotion, it changed my development time and testing significantly.
https://www.genymotion.com/
Considering your configuration, 1 hour is too much, try restarting first.
If not go for your Android device(physical), I debug on my mobile(you don't have to wait for your mobile to start).
You Can also go for Genymotion . Many find difficulty in genymotion setup. it is pretty simple though, follow this video If you'll understand once about VirtualBox and IP, it'll be easy for next time
I would recommend 6GB Ram and i5 processor for performance lag problem. So if it is possible, you should upgrade your machine.
Thanks for your responses. Finally I have resolved the issue by creating a low resolution Android Virtual Device (Nexus One) by Xamarin Studio.
But another problem arises, the published apk file is too large.Which steps need to be done to make it perfect ?
You should try the Xamarin Android Player. In my experience it's the fastest option over Genymotion and Android's AVD images even with Intel's HAXM installed.
https://www.xamarin.com/android-player
Related
I am trying to make an Android app in Unity that uses some heavy computation, when I tried to publish it to the google developer console I got an error "This release is not compliant with the Google Play 64-bit requirement"
After some digging around I found that I need to change the Scripting Backend to IL2CPP Instead of Mono and un-select x86
Now Google lets me publish the app, but when I build and run it on my phone it is significantly slower, should I be worried about this? If so is there any way to fix this? (when I change Scripting Backend back to Mono and build and run the app doesn't lag any more when it's running, perhaps there are some different settings that I need to use?)
What I read so far was that the Scripting Backend IL2CPP is supposed to be faster as far as when the app is run, but at least on my phone this doesn't seem to be the case
The phone I'm using to test this is a ZTE Blade, Model number Z965 (I think it's called ZTE Blade X but I'm not sure)in case that's useful
I (might have) found the reason for the lag from this post:
https://forum.unity.com/threads/huge-fps-drops-from-60fps-armv7-to-25-30-fps-arm64-unity-2017-4-20.682018/
It seems that any logging operations take a long time using the ARM64 architecture(I ran the app using the ARMv7 and ARM64 architecture and the ARMv7 didn't lag that much) now that I changed every logging setting to "none" the app seems to run more smoothly(anyway at least I hope that was the only problem)
As many other videos, this official video from Microsoft and James Montemagno casually demonstrates an Android emulator that runs on Windows without any noticeable lag. It's just fast.
To keep the experiment undistorted, today I tried to run a "Hello World" Xamarin.Forms app on a top-spec Surface Book (i7, 16GB RAM, NVidia GPU, 1TB SSD) with the latest Windows 10 and Visual Studio 2019 Enterprise.
The emulator runs very, very slow. It takes forever to start. It takes forever to wait until the app gets installed on it and meanwhile Android complains about unresponsive System UI process and suggests to kill it. Once it finally gets deployed, it takes forever to click through the Android UI to actually launch the app.
The question is: how can I configure an Android emulator to run as fast and responsive as official Microsoft and Xamarin videos demonstrate? ("nice and superfast")
As recommended here, I have tried both to run it with HyperV and with Intel HAXM.
I have also tried to force the emulator to use the 'host' GPU and use more virtual RAM.
I know that you can set up the emulator to save state, but this only makes it to start faster while it still remains very unresponsive.
Update 1:
Microsoft officially recommends to use Google's emulator and I am not sure it's the one promoted by James Montemagno in a recent blog post (thanks #TonyMkenu).
I was dealing with similar issues on my PC and I found that the emulator ran much faster if I started it up and waited a minute after the emulator appeared before trying to run my app.
I'm using MSVS2015Pro with C#/Xamarin.
I have a laptop that doesn't support Hardware Acceleration.
Then I have a question: can I develop for mobiles without having to spend too much time when deploying?.
I could deploy to my real android phone, but I don't know if that's slower than deploying to an AVD. Is it?
What Can I do? I don't wanna do things in a very slow manner.
Do I have to buy a another laptop that supports Hardware Acceleration?
If that's the case, what other requirements I need for that other laptop?
We are running windows 10 with VS 2015 Pro and no hardware acceleration available on the CPU. There is indeed a solid state drive and 16gig ram (The ram doesn’t really assist in running the emulator though. More ram doesn't make the emulator faster. It is rather the processor and or GPU. The ram does assist with running multiple emulator instances.)
Doing both xamarin.iOS and xamarin.android development. I would agree that with hardware acceleration things would be much faster but it is possible to dev on an enterprise level without it. The deployment to emulator (once emulator has started up and is running) vs actual device is much the same. It is indeed faster running the app on an actual device.
I would suggest using actual device to test functionality and the user experience of the app for quick feedback cycles while using the emulator to test different OS versions for compatibility.
I'm working with maintenance of .NET 3.5 application. During application startup a number of fonts are read from working directory and registered in Windows. We use a pinvoke calls to AddFontResource(string lpFileName) (Gdi32.dll) for each font file.
The code has always been fast, that is until I upgraded to Win10 Anniversary Update (before that, there were no problems with Win10). Now a call can take half a second, which has increased startup time with 90 seconds.
Any idea what can cause the problem? And how to fix it?
Windows 10 anniversary update destroyed performance of the AddFontResource and RemoveFontResource APIs. We're dealing with fallout from it at PortableApps.com now. It's only an issue on Windows 10 after the anniversary update is applied. It's so bad that my old slow ASUS T100 convertible runs code from a USB drive faster than my i7 desktop does from an internal SSD.
I have also observed this problem, but in our case I found a solution: Call AddFontResourceEx().
The full change in our code was:
// from this
AddFontResource(pFont);
// to this
AddFontResourceEx(pFont, FR_PRIVATE, 0);
This solved the slowness problem in at least one of the machines I've personally tested.
We have a near complete application, and are trying to squeeze under the 50MB download limit for Google Play.
When inspecting our APK to try to find ways to drop our file size, I noticed the lib\x86, lib\armeabi, and lib\armeabi-v7a directories that are described here. They correspond to the 'Supported architecture' option in project options of a Mono for Android project.
If I remove x86, I save around 1.1 MB on our APK size. (This is almost enough to get us under 50MB)
What are the drawbacks for removing x86?
Will my APK still run on x86 devices?
Is there any substantial market share on Google Play for x86 devices?
If it will not work on x86, will Google Play prevent my APK from being installed on x86 devices?
Note that the following answers are for general Android development and do not reflect anything specific to Mono:
What are the drawbacks for removing x86?
Your app will not run on x86 devices. Intel may cry.
Will my APK still run on x86 devices?
No.
Is there any substantial market share on Google Play for x86 devices?
IMHO, not presently. A few handsets were released in 2012 that are Intel-powered (e.g., Motorola RAZR i), and the first generation of Google TV devices were powered by Intel CPUs. But Google TV has switched to ARM, and it will be some time before Intel CPUs make up a substantial portion of the Android device ecosystem (again IMHO).
If it will not work on x86, will Google Play prevent my APK from being installed on x86 devices?
It should. If not, the Play Store has serious issues. While I have a RAZR i sitting here, I don't off the top of my head know an app that uses native code that does not ship with x86, to see if the app in question is indeed filtered out of the Play Store.
are trying to squeeze under the 50MB download limit for Google Play
If a 1.1MB savings "is almost enough to get [you] under 50MB", you are already in trouble. Apps tend to grow, not shrink, over time. If you expect that you will be able to switch to some other distribution architecture (e.g., use APK expansion files) eventually and just need a short-term stop-gap solution, cutting x86 may be OK. But you really need to have a plan for dealing with app size growth that takes you back over the 50MB barrier, and you may be better served addressing that now rather than shipping something and finding yourself painted into a corner as a result.