I can't find any better wording to my question.
At some point inside my app I have set up some pretty intensive animation. Thing is, on high-end devices the animation runs smoothly and is pleasant to the eye. On the other hand, one low-end device I tested had a pretty bad performance while animating.
Trying to put user experience first, I'd like to run this stuff on devices that are computationally sufficient, and somehow "turn it off" on other devices.
I have thought for a while on how to discriminate between devices. The only thing that comes to my mind is API level: considering the platform fragmentation and manufacturers delays, I believe there should be some kind of correlation between API level and performance. But there might be something better.
Do you have any idea?
Just to clarify, the animation is not something I can lighten or simplify in any way (e.g., using smaller size drawables, worse quality bitmaps, .... ). It's mainly measuring and layout stuff.
Please feel free to edit the tags I chose.
The first time your app runs, you could run some kind of micro-benchmark that would measure the CPU performance for no more than a second or two. I would suggest not disabling the animations automatically, but warn the user if the device seems slow and ask if they'd like to disable them.
Related
Well i have read a lot of answers of similar questions (even if they are old from like 2013-2014) and i understood that it is not possible to know it exactly since android doesnt count the hardware usage as usage of the app, and some other possible problems like services etc.
At the moment I'm trying to test the perfomance of an App using a protocol to reach a goal and the perfomance of the same App using another protocol (not well known by everyone) to reach the same goal, the default android battery analyzer is good for me since both cases are like 90% the same and i know how the protocols work
My problem is that i'm not sure which one is the best to measure the mAph consumed by my App, i know that there are some external apps that shows it but i would prefer using the one of default, I believe this is something important not only for me but for other people who might have to compare different protocols.
I know that i can measure it programmatically and I've done it too, i save the percentage when the app is opened and how much has been consumed until it gets closed, but it isnt an exact measure since while the app is opened some other apps can do heavy work and add some kind of noise of what i'm measuring so i would prefer to use the android's battery analyzer.
Get a spare device. Load it completely, then run the protocol until shutdown without other interaction (no youtube or anything), note the time it lasted. Repeat with the other protocol. Imho that is a fair way to compare. Note that every device behaves differently and it may or may not be possible to transfer this result to other devices e.g. with different network chips, processors or even firmware versions.
For a more fair comparison I think you should compare how the protocols work. I.e. number of interactions, payload size etc. because the power consumption can only ever be an estimate.
I'm working on Google Cardboard Game. I have 5-10 sprites, a terrain with 15-30 pieces of bush on it(single bushes like grass),15 trees(low poly with <64 vertices),a Camera (provided by GVR Sdk).
On the Editor Framerate is good. But when I test it on my Galaxy S6, the FPS is low as 10-20(I've attached a script that gets Framerate on a Text).
Any optimization tip?
Here is detail of stats in Unity Editor:
CPU: main 6.0ms
FPS: 160(average)
Batches:117
Tris: 6.1k
Verts: 3.3k
I believe you had lot of times used methods "GameObject.Find()" and "gameobject.GetComponent()" in the runtime.
This is most common issue of unity developers.
Better do not use them at runtime at all! Only inside of awake or in start methods.
You need to make all needed GetComponent<> inside of awake or start methods and assign result to some global variables. After -- just use this variable in runtime.
This will really increase your game speed on the mobile devices.
Make sure your device is not overheating, might seem obvious but you can't always tell when it is on your face (I also own an S6).
Also, make sure you are not in energy saver mode, sounds dumb but I fell for it already ;)
Among the huge amount of things that can ruin the performance of a game on smartphone are:
Make sure you don't have a script doing too much work in Update (especially Instanciate()/Destroy()
Don't move static objects, just don't
Make sure you don't use high resolution textures (in my small experience > 512x512 is, that they are squared and have a resolution that is a power of two
As a side note, GetComponents can be an issue, the alternative was already posted by #Andrew, just use GetComponent in the Start()/Awake() method and store them to use them later on.
I'm developing an app that it functionality very similar to Facebook Android native app: social network that most of the time the user will spend in an endless ListView displaying lot's of images, entering an image gallery, and so on.
let's say for the discussion that I'm doing all the right things and best android practices to achieve smooth scroll (recycling views as it should, using different view types when needed, loading to memory only scaled bitmaps in the needed size, caching bitmaps, using ViewHolder design pattern, not blocking th UI thread when its possible and so on...)
let's say also that every thing else in my app written in the best way and following best practices (for the discussion... :->)
my app working not bad at all in that stage, but when
turning on the hardware acceleration, as described and promised in Android Developers documentation it making my app much much more smooth and fast.
let's say that it does not affect in any nagative way on the UI as can happened, and I'm not performing any of the Unsupported Operations
according to Google's document on the subject, only reason I can see not to use this feature (besides all other reasons I already mentioned above) is that it can cause my app to use more RAM. but how much RAM? a lot more? I know that when my app consumes lot's of RAM - it becoming good candidate to be destroyed by the OS when it need to free some memory.
my question is basically -
is it "ok" under my circumstances to use this feature?
what other problems can raise from using it?
TIA
To use or not to use
It is advised to use hardware acceleration only if you have complex custom computations for scaling, rotating and translating of images, but do not use it for drawing lines or curves (and other trivial operations) (source).
If you plan on having common transitions and also given that you have already considered scaling, recycling, caching etc, than it may not make sense to burden your project anymore. Also, any efforts spent reworking your code to support hardware acceleration will not effect users on versions below 3.0, which are ~36% of the market as of May 8, 2013.
Memory
Regarding memory usage (according to this article), by including Android Hardware the application loads up the OpenGL drivers for each process, takes memory usage of roughly 2MB, and boosts it to 8MB.
Other issues
Apart from API versions, I presume it will also affect battery life. Unfortunately there aren't any benchmarks on different use cases online in order to draw a line on this one. Some argue that in given cases because of multiple gpu cores, using acceleration may save battery life. Overall, I think it would be safe that the effect won't be too dramatic (or Google would have made this a major point).
UPDATE
Hardware acceleration is enabled by default if your Target API level
is >=14
I would say yes in your situation, use hardware acceleration.
Seeing that you aren't using any resource intensive controls in your app it should not be a problem to enable Hardware acceleration. As you said your app is working quite well without hardware acceleration.
When you enable hardware acceleration Android will start using your GPU and because of the increased resources required to enable hardware acceleration, your app will consume more RAM.
A frequently asked question is Will the amount of ram increase by a really big amount?
The answer to that will all be determined by :
1. Your programming ability ie. management of the recycling list, scaling of the Images ect.
2. The Device
I wrote a app a while ago that was used to edit really high res bitmaps. I ran into the same problem. I found that on different devices the max amount of ram allocated by the OS when hardware acceleration is enabled varies by device. If your device has more ram the OS will allocate more ram to your app, so you will never find a consistent amount of ram used for your app. The bigger more expensive devices will always run your app on a larger amount of ram.
What other problems can raise by using hardware acceleration?
Hardware acceleration might cause problems for some 2D drawing operations. If you experience this you can enable Hardware Acceleration for only specific activities in your app like stated on the Hardware Acceleration post in the android Developer Docs
The easiest way to enable hardware acceleration is to turn it on globally for your entire application. If your application uses only standard views and Drawables, turning it on globally should not cause any adverse drawing effects. However, because hardware acceleration is not supported for all of the 2D drawing operations, turning it on might affect some of your applications that use custom views or drawing calls. Problems usually manifest themselves as invisible elements, exceptions, or wrongly rendered pixels. To remedy this, Android gives you the option to enable or disable hardware acceleration at the following levels:
Application,
Activity,
Window,
View
This way you can also limit the hardware acceleration in your app but by the sound of it you will need it for most of your apps functions.
Hope this helps
My game uses too much battery. I don't know exactly how much it uses as compared to comparable games, but it uses too much. Players complain that it uses a lot, and a number of them note that it makes their device "run hot". I'm just starting to investigate this and wanted to ask some theoretical and practical questions to narrow the search space. This is mainly about the iOS version of my game, but probably many of the same issues affect the Android version. Sorry to ask many sub-questions, but they all seemed so interrelated I thought it best to keep them together.
Side notes: My game doesn't do network access (called out in several places as a big battery drain) and doesn't consume a lot of battery in the background; it's the foreground running that is the problem.
(1) I know there are APIs to read the battery level, so I can do some automated testing. My question here is: About how long (or perhaps: about how much battery drain) do I need to let the thing run to get a reliable reading? For instance, if it runs for 10 minutes is that reliable? If it drains 10% of the battery, is that reliable? Or is it better to run for more like an hour (or, say, see how long it takes the battery to drain 50%)? What I'm asking here is how sensitive/reliable the battery meter is, so I know how long each test run needs to be.
(2) I'm trying to understand what are the likely causes of the high battery use. Below I list some possible factors. Please help me understand which ones are the most likely culprits:
(2a) As with a lot of games, my game needs to draw the full screen on each frame. It runs at about 30 fps. I know that Apple says to "only refresh the screen as much as you need to", but I pretty much need to draw every frame. Actually, I could put some work into only drawing the parts of the screen that had changed, but in my case that will still be most of the screen. And in any case, even if I can localize the drawing to only part of the screen, I'm still making an OpenGL swap buffers call 30 times per second, so does it really matter that I've worked hard to draw a bit less?
(2b) As I draw the screen elements, there is a certain amount of floating point math that goes on (e.g., in computing texture UV coordinates), and some (less) double precision math that goes on. I don't know how expensive these are, battery-wise, as compared to similar integer operations. I could probably cache a lot of these values to not have to repeatedly compute them, if that was a likely win.
(2c) I do a certain amount of texture switching when rendering the scene. I had previously only been worried about this making the game too slow (it doesn't), but now I also wonder whether reducing texture switching would reduce battery use.
(2d) I'm not sure if this would be practical for me but: I have been reading about shaders and OpenCL, and I want to understand if I were to unload some of the CPU processing to the GPU, whether that would likely save battery (in addition to presumably running faster for vector-type operations). Or would it perhaps use even more battery on the GPU than on the CPU?
I realize that I can narrow down which factors are at play by disabling certain parts of the game and doing iterative battery test runs (hence part (1) of the question). It's just that that disabling is not trivial and there are enough potential culprits that I thought I'd ask for general advice first.
Try reading this article:
Android Documents on optimization
What works well for me, is decreasing the use for garbage collection e.g. when programming for a desktop computer, you're (or i'm) used to defining variables inside loops when they are not needed out side of the loop, this causes a massive use of garbage collection (and i'm not talking about primitive vars, but big objects.
try avoiding things like that.
One little tip that really helped me get Battery usage (and warmth of the device!) down was to throttle FPS in my custom OpenGL Engine.
Especially while the scene is static (e.g. a turn-based game or the user tapped pause) throttle down FPS.
Or throttle if the user isn't responsive for more then 10 seconds, like a screensaver on a desktop pc. In the real world users often get distracted while using mobile devices. Don't let your app drain battery while your user figures out what subway-station he's in ;)
Also on the iPhone, sometimes 60FPS is the default, throttling this manually to 30 FPS is barely visible and safes you about half of the gpu cycles (and therefore a lot of battery!).
I asked this question over in the Android Developer's user group, last week. Nobody responded, so I thought I'd ask it over here.
Does anyone have any suggestions about how to schedule video events to happen at an exact clock time? I've been thinking about an application that would require two adjacent phones to display the same thing at exactly the same time. I'm wondering what that granularity of "exactly" is going to be.
I've done some testing on a couple of devices and it seems that the delay between an invalidate and the subsequent redraw can be as much 16ms. Perhaps I can do better with OpenGL?
Ideas? Anyone?
OpenGL itself is capable of very high framerates (unless I am mistaken). What I can tell you is that plenty of games have been written to run and maintain 30 frames per second. That's one frame every 3.33ms. At that speed, the change should be imperceptible to the human eye, or so I've heard (the estimate limit is 5ms).
However, there is a major difference between what OpenGL can do, and what the device running OpenGL can do. Again, Unless I am mistaken, you should be able to instruct OpenGL to run at 200 frames per second. The caveat is that if the machine you are running the animation on can't handle that framerate, it will either frame-skip or lag, and in either case will hog the processor and GPU like no other.
Again, as I don't know the specifics, I can only guess, but I would think that this is less of an issue with OpenGL vs the other leading brand, and more of an issue of the devices you are trying to sync. With the right code, a proven framework, two powerful machines, and high-speed data transfer capability (read: LAN at the least), there is no reason why you shouldn't be able to sync up the video. If any of these things are not the case, all bets are off.
-Cody