I currently develop an hybrid app based on Cordova. My main target is Android devices with at least 2.3 support.
I face performance issues, particularly scrolling which is not really smooth and more generally navigation inside app. So I implemented several tips to increase my app speed such as:
Hardware acceleration
Use the fastest scroller I found (FTScroller)
Use hogan.js for view rendering with pre-compiled template
I tried Famousjs and CocoonJS but it didn't help. I look to crosswalk-cordova, but it increase the size of the app by 15-20mb and I have to keep the size as light as possible.
The app performs pretty good on powerful devices such as my Nexus 5, but it become slow on older/less powerful devices.
So what other tips could I use to increase the speed of my app ?
Many thanks.
"but it become slow on older/less powerful devices", does this issue happens when you are using crosswalk?
I guess on older/less powerful devices, if the performance drops dramatically, it maybe related the the GPU blacklist, Which means on some old devices GPU are blacklisted. To resolve this issue, you can pass '--ignore-gpu-blaclist' option,
see: https://crosswalk-project.org/#wiki/Use-Chromium-command-lines-in-your-apps-on-Android
Related
I have been playing with optimizing my app, and I see that there are some general ideas on how much memory it should use... I'm running between 70-80Mb right now, is that a crazy number or just a little on the heavy side?
My second question is about the memory I am using. About 42Mb is taken up by graphics, whether I run the app with the layout graphics or run it without setting any views... any ideas on where to look? I feel like it is the theme, but I am not sure how to test that.
I've been searching for days to figure out why it uses so much and cannot figure it out. It remains constant regardless of which activity I am on, any ideas are welcome!
UPDATE:
I ended up running it on an emulator and got about 26Mb, more what I was expecting, but it runs at 70Mb with the 42Mb of graphics on the actual device.
The emulator allows for a 384Mb app after getting memoryclass information, while the device only allows 256Mb... the emulator has more storage and runs more efficiently.
The emulator is Android 8.1 27api while the device is Android 7.0 24api.
Tried on an older Android 5.1.1 api 22 below also.
Any ideas?
I have another question with about why the emulators have a such a difference in performance here if you know the answer on that, but I wanted to keep these questions separate: Other Question
Android Studio has an awesome tool called Memory Profiler. It helps you analyze possible memory leaks and see which calls are using up the most memory. You can even pause the processor and 'zoom in' to deep dive on the call stack.
You can use LeakCanary A memory leak detection library for Android and Java. Maintain by Square. This is one of the best developer's Tool for memory optimization and detecting leaks.here
In my app, I want to include a webview containing for example a simple HTML 5 game. On a new phone with Android 5.0, this works great, but on an older phone, running Android 4.4.2, the performance is terrible. In the chrome browser, the game is performing perfectly, but in the webview of my app, it is very slow and laggy.
I have tried some performance optimizations like enabling hardware acceleration, but nothing resulted in a better performance. Therefore, I looked for alternatives to the webview, and using Crosswalk resulted in a very good performance. But now, the problem is that Crosswalk adds 18MB to the apk size and 45MB to the phone memory usage. As that is simply too much for just a simple app like mine, Crosswalk unfortunately turned out to be no option.
Is there a way that improves webview performance, but does not increase the memory usage as drastically as Crosswalk does?
The core problem that you will face with using the stock WebView built into Android is that it is terribly inconsistent in terms of performance and what it supports regarding HTML5/CSS. While CrossWalk may add 18MB to the size of your app, it is worth it if your concern is performance and compatibility across devices and Android variants.
Your other alternative is CocoonJS, however without knowing more about your app, it's hard to say if this will benefit you or not.
https://www.ludei.com/cocoonjs/
I'm developing a webbapp for iOS and Android, primarily. The problem is that it tends to run slow on the android phone (testing made on Samsung Galaxy S2). I've tried a couple of different frameworks together with PhoneGap without any good result.
My experience this far (on android):
Dojo toolkit: (v1.7.1)
Pretty good but flickers alot when doing transitions between different views and the input forms performs badly.
Sencha Touch: (v1.1)
Not very responsive and flickers a bit during transitions. Changing orientation takes awfully long.
JQTouch: (beta 4)
Runs smooth but the layout is broken on android (back-buttons etc that uses CSS transform rotate and translate)
My question is:
Have any of you found a framework that works well on both iPhone and Android devices? or is the only solution to develop native?
On a side note I've noticed that Sencha touch 2.0 has focused on Android performance but there's only a developer preview available at this time and is not going to be release before Q2 2012.
What I have found is that many of the frameworks work just great but the root cause of the problems is earlier versions of Android's support for CSS3 style transitions. You are probably better off avoiding or disabling these transitions.
Developed a application of size 40MB. I need to test it for all screen support but the android emulator really a bad choice(I feel... ). It gives Insufficient memory error almost every time). How developer test their application?
One more Question
I have designed app for four different layout(normal,small,large and xlarge). Will every device(In future) satisfy these layout params?
And i faced a real problem that i tested my app in Sony xperia minpro(Small screen 240*320 2.4inch) and in Samsung galaxy 5(smallscreen 240*320, 2.8inch) but the layout is overlapping in samsung device. This can be a serious problem , actually we cant check our app in every device.. that is impossible too.
TIA
40MB is way too big for an Android application. Many users will have problems installing the app on their devices. You should consider moving some resources out of the application and downloading them either on demand or on first app run.
The list of layout types (normal, small, large, xlarge) is definitely not final, for there quite possibly will be even larger screens (xxlarge) or tiny ones (xsmall?).
Developed a application of size 40MB. I need to test it for all screen
support but the android emulator really a bad choice(I feel... ). It
gives Insufficient memory error almost every time). How developer test
their application?
You can configure the emulator with any amount of memory you wish, including an emulated SD card so memory shouldn't be a problem. However, 40MB is quite big so you may be hitting the package size limit.
One more Question I have designed app for four different
layout(normal,small,large and xlarge). Will every device(In future)
satisfy these layout params?
You're asking us to predict the future - there's no way we can know what Google are planning if they haven't already announced it though I would suggest that there will never be a commitment to keep screen sizes or resolutions static - technology constantly evolves and specs that are OK for today, will not be OK for tomorrow.
I have seen dictionaries weighing in at 40Mb, best practise is to download the database as a separate file. Some graphically intensive games approach that size. If you want to emulate many Android devices make sure your PC is up to snuff and you have the latest SDK.
How developer test their application?
You do not have so many choices: you have to use as many (and different) physical devices as you can, from different vendors and technical specifications (screen, etc), to try to detect as many specific bugs as possible.
This is difficult, as you are often limiten to a few physical devices.
To give you examples, I recently struggled with the Camera, for a bug happening with Motorola Defy only. I am currently struggling with the Camera, but only for Samsung Galaxy this time.
When you find a specific bug, try to fix it "the general way": instead of detecting the vendor/version of the device to write specific code for it, try to enhance your code in a way it will work for all tested phones. So far, I never had to write anything specific to a given device. The bugs I encountered were always tied to a permissivities or particular cases that could be handled by making the common code more complete or resiliant. Let's say by "making as less assumptions as possible" knowing that we tend to make assumptions without meaning it.
On top of testing on as many physical devices as possible, create emulators. You can parameter them to have different screen layouts, different embedded hardware, memory, etc. And on top of the default emulator that comes with the Android distribution, you also have emulators provided by the devices vendors and that reproduce the specificity of these devices. For example, Samsung released a Galaxy Tab emulator. Sony Ericsson released a EDK Cellphone emulator. You can get them thru the regular android distribution update workflow.
Will every device(In future) satisfy these layout params (normal,small,large and xlarge)?
Yes, as Android distributions are backward compatible. Any of these layout will still be supported in the future, but may become 'deprecated' (so not recommended, but still working), and new layout types will certainly be created.
Recently myself and a small group of friends became interested in developing a game for a mobile platform. Originally we considered the iPhone but none of us use macs, so we decided Android would be a more realistic platform to use. Before we get started, I was hoping that I might find some answers to a couple questions so we don't waste our time if this project isn't feasible. Any help is appreciated!
I can't seem to find out how many programming languages Android supports. Java is obvious, but what about C+? It seems that Android supports C and C++ through Eclipse, but is that it? (I'm not the programmer for the project which is why I'm asking this. He's comfortable in C+).
Our game involves the use of two digital analog sticks (it's not a twin-stick shooter but it's a similar concept). It would seem that most Droid devices unfortunately don't use multi-touch though... Are there many devices out there right now which support this functionality and I'm just not seeing them, or should we possibly consider the development of a different game that would only use a single input?
Assuming there's no snags following those first two questions, what would you consider the best screen resolution to develop in? It seems like there are a variety of resolutions out there right now and we can't decide which is the best to use.
Again, any answers are appreciated!
You will have to use at least some Java, though you can call C++ with the newly released NDK.
To my knowledge at least the Droid and Nexus One support multitouch. Not sure about the newer ones.
I would develop for multiple screen sizes.
Chris Pruett did two very good presentations on writing real time games for android you may want to look into, they were a huge help for me.He also lightly touches on the NDK in the second one, linked below. I can only post one link since I'm a new member, but a google search for "writing real-time games for android" should turn it up.
http://bit.ly/checYY
1) Java is the language of the SDK. The majority of apps are and should be written in Java. The only reason for the NDK is for apps previously written in C++ that are to be ported to Android. There are downsides - it only supports compiling to 2 different CPUs (one is the Nexus one's CPU, can't remember what the other is). So if you do use C/C++ in the NDK, you are seriously limiting the number of devices you can ship to.
2) If you want to use dual analog sticks, why not display the sticks in the corners of the screen and allow the user to place their thumbs on them? You don't need hardware support.
3) Android SDK supports multiple screen resolutions so you don't necessarily need to worry about it immediately. I would aim for WVGA to start with (800x480 - Nexus One / HTC Desire).
Your first question has been answered by others already. The SDK is based on Dalvik, you're going to have to speak Java to the Android framework to do things like set up your activity, handle events, etc. You can call into a native code module built with the NDK for other things.
The multitouch situation on Android is dependent on hardware. Android >= 2.0 supports it in the framework, and you can use the PackageManager to query for what kind of multitouch functionality the device supports. The two you care about are FEATURE_TOUCHSCREEN_MULTITOUCH and FEATURE_TOUCHSCREEN_MULTITOUCH_DISTINCT. Some screens that only offer FEATURE_TOUCHSCREEN_MULTITOUCH have problems distinguishing precise movement when both fingers are along or near the same X or Y coordinate. This is fine for things like zoom gestures, but you might have problems doing dual-analog style controls on a device without FEATURE_TOUCHSCREEN_MULTITOUCH_DISTINCT.
Plan on supporting multiple resolutions. If you provide low and high resolution assets the resource system can select the appropriate ones for you automatically at runtime. More details on this here. You will still need to deal with different resolutions that do not necessarily share an aspect ratio. For example, the Droid is 480x854 while the Nexus One is 480x800.