So I have a Sencha Touch/PhoneGap + Crosswalk app whose Android startup duration I have struggled with for a while. Baseline, on first launch is around 10 seconds on a Samsung S3. After poking around and experimenting, I've learned some stuff about app launch time but don't know what I can do with it at the moment, or if there are other techniques to improve launch time.
So far, I've found:
That completely removing all images on the app (which totals ~20mb) reduces launch time to ~5 seconds.
That gutting the Sencha framework code (generated by "sencha app build package") on top of removing images reduces launch time to 2 seconds.
Gutting only my Sencha code, however, is negligible on launch time.
Clearly, messing with app size and core Sencha impacts launch time. I've done as much as I know to reduce app size (remove unnecessary images, compress images), and it's helped some, but not much. So I guess my main questions are:
Are there other notable ways to reduce PhoneGap app package size? Are there components that get added that aren't always necessary? The only other way I've seen is code obfuscation, but going from 40mb to ~37mb would have not much impact on launch time.
Is there anything I can do about how long Sencha seems to take to get fully loaded?
Am I missing anything else I can do to significantly improve app launch time? I've done a fair amount of research but haven't been able to find anything beyond basic package size; maybe I'm just using the wrong search terms.
Thanks! Any advice here would be much appreciated.
Related
The last few days I have been building a simple platformer to be deployed on Android Phones. However, after the last deploy to my phone, the framerate was bearly at 25fps on my quite fast Samsung S8. The game in the editor is somewhere at 100 fps and works fine. The game also worked fine on my S8 just a day before. I have not really changed anything, so what could be going on here? This is absolutely unacceptable. If you need further info, tell me!
Thank you!
This is from the profiler:
I cannot tell you, why this happend but this was all I needed to do:
In any script that starts (like playermovement or what ever) add this line:
Application.targetFrameRate = 60;
E voila.
I didnt have this line before and it worked but it stopped working. Adding this line fixed it entierely. Thank you all.
First of all, try deducing number of Tries and Vertices in your Meshes, Use baked lighting to improve performance, Also try object pooling wherever possible, and generate Occlusion map to optimize your game for mobile devices. You can set quality settings from Unity for mobile devices. You will need to maintain LOD levels if you want more complex meshes to be rendered on your phone, and optimize game as much as possible to render it on mobile devices without any glitches. I will also recommend you to use this toolset, which will help you in optimization.
UPDATE
If you have recently changed anything, which made your app performance Bad, then check you haven't added any Co-routine or IEnumetaror relative code that may iterate over time in separate thread in your recent changes, try using Collab to maintain versioning, as you can restore your previous code with help of collab anytime, in case you loose something, it is totally free and very useful.
I've been trying to improve the app startup time of my app without any success. I'm using MvvmCross, but based on my logs, the slowdowns seem to occur before it even gets to the MvvmCross initialization part. Once it gets there, it seems to be quite fast. I even tried removing all my initialization code, yet that did not make any difference to the slow startup.
Based on log, I can see that time is lost when libraries/plugins are being imported and I have no idea how to improve this. I tried linking everything, but I didn't gain much in startup speed. The only significant speed up was after using AOT compiling, but that results in ridiculously large .apk with an even bigger install size of ~200-300mb, which is unacceptable.
I need help on improving the app startup time without compromising the application size.
I have the following scenario:
An app for Android devices that has a few hundred classes. I am using Flash CS5.5, developing in AS3 using AIR for Android.
The app is a puzzle game and each class represents one of the elements from the puzzle. Each class is a derivative of a base class and only holds a few specific information like unique name, category, place in puzzle. Each class also has attached an 80 x 80 px image to it. However, there's about 300 classes like this.
The application runs very smoothly ONCE IT LOADS because it takes forever for the application to publish and then for it to run on the mobile device. I have no issue with the exporting/publishing time being high and the installation time on the mobile device being quite high. But each time I run the application from the mobile device, it takes some 2 minutes for it to load which is abnormally high, not even high-end 3d FPS games load for that long. Tests are done on a HTC Sensation running Android 4.0 and, subsequently 4.1.
My question is, what can I do to help reduce this initial startup time? I mention again, the app runs smoothly once loaded since it is really not that complex nor does it use a lot of graphics aside the many 80x80 JPG images attached to each class. In early testing, when I had like 20-30 classes only implemented, everything was smooth. When I added all the elements needed for the game after the game's logic was complete, everything was slow to load.
Thank you for any answers/suggestions.
If you want to speed up compile times for an AS3 project in Flash CS5.5, go into the Actionscript 3 settings for your .fla and turn off 'Warnings mode'. Warnings mode has a bit of overhead because it tries to give you helpful warnings when migrating code from AS2 to AS3. If you know what you're doing, you can turn this off and save lots of time.
1) File > Publish Settings.
2) Click the wrench icon next to 'Actionscript 3.0'
3) Uncheck 'Warnings Mode'
This cut doing compile times on a big project for me quite a bit. Another thing that helps is to divide up your assets into smaller swfs/swcs that are just brought in during runtime.
Only a partial answer, I'm not sure how to fix up a slow load time on an Android device. Good luck!
The title says most of it. I believe packaging the basic data set into the app will result in a better user experience, rather than have people download files before they can start using the app. This is where one can start losing users. At the same time, 20MB is considered kind of a lot for Android,so I wonder if this will cause issues for some users in using the app.
I am not sure if this will cause an issue. I am an android developer who uses android phone and facebook app in my fone is almost 21MB. It does not cause any issue...However, as a developer a better approach would be to do an app that does not exceed 10MB space(Unless your app is outstanding like Facebook). You can do this by using images of smaller size,making sure you do not have any resources that you are not using(classes,layouts etc)
The size never causes issue but you may consider more:
I am a android developer and a long time Android user too. Not All Android phones have high-end processors to run app faster.
A lot of Android Phones have phone memory of 100-250MB. And the old versions of Android doesn't allow user to install app on SD card. So the user may hesitate to install your App.
Unless it is necessary try to reduce the App size.
As per my personal experience, If you are designing something astonishing and it costs even few hundred MBs on my phone, so i really wouldn't mind to give a try. Since new phones, processors and high storage capacities are continuously evolving and appearing in consumers' hands, so how can we expect applications to remain the same (tiny) in size? Let them grow (but not without any valid reason), and people would still try/buy it. There are no fixed rules or guidelines for limiting the app size, but a directly proportional relationship explains it well:
High-end graphics and feature-rich application ∝ Extra size/memory
What I think is :
The size of the app never creates issue. Again if its an extraordinary app. then surely user will surely get attracted and download your app..
But on the other side just think about the Internal Memory of the phone. There are lots of phone available that has very low internal memory(many have 150 or 180MB as internal memory). May be because of too low internal memory, they wont be able to use your application and hence you may not get big traffic.
You've got a lot of answers here so I'm just going to give you my perspective.
I would be frustrated to say the least if I downloaded a 10MB app and then opened it to find I needed to download another 10MB of necessary materials. Just make the app 20MB so I know what I'm getting into when I start the download.
Only put the bear essentials into the app if it's going to be that big. Don't require users to download high res images, language packs, etc. Just publish the bare minimum that your app requires to run if it's going to be larger than 10MB. You could even publish two versions of your app, the bare minimum at 7MB or the HOLY SH*T package at 20MB, at least users would have a choice when they went to download your app.
Spend some time looking up common practices when it comes to saving space when making an app, every little bit counts and if you can make the same app and save 5MB, your users will appreciate it. If it comes down to a lot of images, consider using this tool; http://www.getpaint.net. However I would suggest reducing the JPEG quality) rather than compress them. JPEGs aren't very squishy.
Going along with #3. Think about universally accepted methods of communication; a sideways triangle for a play button, and X for a delete button, be sneaky...save space. User's love that crap :]
I'm developing an engine and a game at the same time in C++ and I'm using box2D for the physics back end. I'm testing on different android devices and on 2 out of 3 devices, the game runs fine and so do the physics. However, on my galaxy tab 10.1 I'm sporadically getting a sort of "stutter". Here is a youtube video demonstrating:
http://www.youtube.com/watch?v=DSbd8vX9FC0
The first device the game is running on is an Xperia Play... the second device is a Galaxy Tab 10.1. Needless to say the Galaxy tab has much better hardware than the Xperia Play, yet Box2D is lagging at random intervals for random lengths of time. The code for both machines is exactly the same. Also, the rest of the engine/game is not actually lagging. The entire time, it's running at solid 60 fps. So this "stuttering" seems to be some kind of delay or glitch in actually reading values from box2D.
The sprites you see moving check to see if they have an attached physical body at render time and set their positional values based on the world position of the physical body. So it seems to be in this specific process that box2D is seemingly out of sync with the rest of the application. Quite odd. I realize it's a long shot but I figured I'd post it here anyway to see if anyone had ideas... since I'm totally stumped. Thanks for any input in advance!
Oh, P.S. I am using a fixed time step since that seems to be the most commonly suggested solution for things like this. I moved to a fixed time step while developing this on my desktop, I ran into a similar issue just more severe and the fixed step was the solution. Also like I said the game is running steady at 60 fps, which is controlled by a low latency timer so I doubt simple lag is the issue. Thanks again!
As I mentioned in the comments here, this came down to being a timer resolution issue. I was using a timer class which was supposed to access the highest resolution system timer, cross platform. Everything worked great, except when it came to Android, some versions worked and some versions it did not. The galaxy tab 10.1 was one such case.
I ended up re-writing my getSystemTime() method to use a new addition to C++11 called std::chrono::high_resolution_clock. This also worked great (everywhere but Android)... except it has yet to be implemented in any NDK for android. It is supposed to be implemented in version 5 of the crystax NDK R7, which at the time of this post is 80% complete.
I did some research into various methods of accessing the system time or something by which I could base a reliable timer on the NDK side, but what it comes down to is that these various methods are not supported on all platforms. I've went through the painful process of writing my own engine from scratch simply so that I could support every version of android, so betting on methods that are inconsistently implemented is nonsensical.
The only sensible solution for anyone facing this problem, in my opinion, is to simply abandon the idea of implementing such code on the NDK side. I'm going to do this on the Java end instead, since thus far in all my tests this has been sufficiently reliable across all devices that I've tested on. More on that here:
http://www.codeproject.com/Articles/189515/Androng-a-Pong-clone-for-Android#Gettinghigh-resolutiontimingfromAndroid7
Update
I have now implemented my proposed solution, to do timing on the java side and it has worked. I also discovered that handling any relatively large number, regardless of data type (a number such as the nano seconds from calling the monotonic clock) in the NDK side also results in serious lagging on some versions of android. As such I've optimized this as much as possible by passing around a pointer to the system time, to ensure we're not passing-by-copy.
One last thing too, my statement that calling the monotonic clock from the NDK side is unreliable is however, it would seem, false. From the Android docks on System.nanoTime(),
...and System.nanoTime(). This clock is guaranteed to be monotonic,
and is the recommended basis for the general purpose interval timing
of user interface events, performance measurements, and anything else
that does not need to measure elapsed time during device sleep.
So it would seem, if this can be trusted, that calling the clock is reliable, but as mentioned there are other issues that then arise, like handling allocating and dumping the massive number that results which alone nearly cut my framerate in half on the Galaxy Tab 10.1 with Android 3.2. Ultimate conclusion: supporting all android devices equally is either damn near or flat out impossible and using native code seems to make it worse.
I am very new to game development, and you seem a lot more experienced and it may be silly to ask, but are you using delta time to update your world? Altough you say you have a constant frame rate of 60 fps, maybe your frame counter calculates something wrong, and you should use delta time to skip some frames when the FPS is low, or your world seem to "stay behind". I am pretty sure that you are familiar with this, but I think a good example is here : DeltaTimeExample altough it is a C implementation. If you need I can paste some code from my Android Projects of how I use delta time, that I've developed following this book : Beginning Android Games.