I've been doing several opengl based games for Android recently,
and there's one issue I can't find a way to get rid of.
When system starts some process in background (checking CDMA status, updating an app, or prerry much anything else), the game suffers a whole second stutter. Once in every few minutes. It was an annoying issue, until I started a breakout-style game, which is completely wrecked by that stutter (the ball teleport right through bricks).
It there a way to give the game activity priority over background processes, or pause all those background updates and installs while the game is running?
It there a way to give the game activity priority over background processes
The game activity already has "priority over background processes", to the extent that it can. Generally, background processes run in a class that limits their CPU utilization.
Note that Android's performance in this area has improved over the years. Your symptoms feel like what I would expect from an Android 1.5 device, for example.
or pause all those background updates and installs while the game is running?
No, sorry.
Related
So, I've a Service that is important for applications logic and thus needs to be alive all the time.
First thing is first, I created it as a foreground service.
Whenever user starts to run, Service starts to do a lot of heavy things. It uses FusedLocationAPI different type of sensors and do a lot of different calculations. At this point phone starts to heat up (CPU usage is high). When running stops, heating stops and CPU drops lower.
This makes me think that the main problem is whenever these sensors are used and calculations are made, but there's a lot of possibilities that could cause this and I wanted to understand, how can I deeply analyze batter usage in this case? I read that Battery Historian should be way to go, but the information there is complicated and do not give me much information. How can I use this data to understand which class/runnable/code part is held responsible for the CPU usage? Maybe there's better ways to solve this? Thanks in advance.
Detailed analysis on what's happening using CPU profiler (after suggestion).
Image. Application is opened and few different screens are switch to and from. Nothing special. Phone does not heat up and from CPU analysis everything also looks pretty okay.
2.User starts to run and enter heavy state. The yellow (light green) rectangle shows previously mentioned "important service" that bring important role to application. Called functions does not use too much time of CPU considering the % of whole running trip - which makes me think, I've to look somewhere else..
What I saw is that CPU increases heavily whenever I lock the phone (while service is running. From CPU Bottom Up analysis I cannot understand what is causing the problem (orange rectangle) - looks like a bunch of Android stuff is happening, but it does not give me any clue.
From CPU profiler I do understand that I have a serious problem considering CPU usage, but right now I do not understand what is causing it (which piece of code/class/function). I know for the fact that whenever my important service is created (on app start) I use PARTIAL_WAKE_LOCK to not allow CPU go to sleep and also make service to be alive at all times. As I understand I need to find different solution for this, because CPU drains too much of battery.
How could I found this using only profiler? I now this fact only for code and profiler stack does not tell me much about this (maybe Im not looking at the right place?)
I found out the root cause of high CPU usage.
I did detailed investigation on threads and found out that DefaultDispatcher threads are using A LOT of CPU.
Turns out the has been a bug in Kotlin-Coroutines library and latest version provides fixes. When I did tests I used version 1.3.1, but changing version number to 1.3.3 provided me with big improvements: from 40% usage to 10% CPU usage.
It is a well known issue that many Android phones switch off the accelerometer when the screen goes off. However something seems to have changed with Android Fit (the app). Fit keeps counting steps even when the screen goes off. If Fit is installed, then events are raised for step counting within the Fit environment and I am able to capture them using
Fitness.SensorsApi.findDataSources(mClient, new DataSourcesRequest.Builder()
.setDataTypes(DataType.TYPE_STEP_COUNT_CUMULATIVE)
I have tested this on a Samsung S4 and on a Oneplus One and in both cases the steps are counted.
How do they do that? What Android classes do they use?
My understanding is that the available method introduced since Kitkat is to implement a SensorEventListener. For example theelfismike provides code that implements this. However on many phones the step counting stops when the screen goes off. Interestingly the counting does not seem to stop if the Google Fit app is installed (hence I guess they keep the accelerometer on).
Am I missing something? Is the functionality of keeping counting steps after screen off available to the mortal programmers?
Thanks!
As Ilja said, your code runs even after the screen gets turned off. But in this case I guess we need a little different answer.
They definitely use a Service that keeps a wakelock and they query the sensors for data. Important part here is holding the wakelock - you have to prevent the device from going into sleep during lifetime of your service - if you don't want to miss some data.
But this approach will be drain the battery really fast, because in order to detect steps you need to process quite a lot of data from sensors.
Thats why there is sensor batching. That allows you to get continuous sensor data even without keeping the device awake. It basically stores the sensor events in a hw based queue right in the chip itself and only sends them to your app (service,..) at predefined intervals in batches. This allows you to do a 24/7 monitoring without draining the battery significantly. Please note that only supported chipsets can do that (you can find details in Android docs), in case of older phones you need to fallback to the hideous wakelock keeping method in order to get your data.
You can also just use Google Fit APIs, but this would only work when there're both Google Fit + Google Play Services installed on the device with monitoring turned on.
Every normal Thread is keep on working when the screen goes off or when the Activity lost its focus...but when the activity gets killed then all thread are killed...
However you can use services for longrunning tasks like asking the accelerometer for example
I am working on a timer application (it's my first app to try and learn the ropes). While the timer is running, I want to offer the user the ability to prevent the screen from locking.
Since the screen is always displaying something (and refreshing the clock every second), what would the performance penalty be for doing this? The only things active on the screen are the timer (black background with just the running time) and "split" and "stop" buttons? I am mostly concerned with the battery life of the phone; e.g. if this were a long-running timer job (let's say long-distance running with split times).
I have used both an iPhone and an android for running apps in the past. The first iPhone versions couldn't 'lock' the screen because it disabled the GPS too. Leaving the screen on, even with minimal backlight, absolutely ruins battery life, because the backlight and screen-refresh operations are quite expensive. Battery life went up from ~30 minutes to ~5 hours when running with the screen off.
There are some innovative solutions to this for runners, for example RunKeeper (and I'm sure most of the other ones too) has an option to fade the music out and give you updates on your stats every n minutes.
In the Android examples, like LunarLander, and many other tutorials written on blogs across the net, game loops almost always run a separate thread to call the state updating and rendering parts of the game.
Why is this? What are the advantages and disadvantages? The only reason I can think of is just to keep the app responsive to input such as if the user presses the menu or back buttons. Other than that, the game just has to chug along in update/render cycles as fast as it can.
I'm aware this is a good reason, although one would hope that if one's game is running at a decent frame rate, the app would remain responsive enough. But, are there any other reasons?
On the other hand, I imagine it would create more headache accessing game resources, for example a game object manager or the sound system, which may live on a separate thread.
On Lunar lander and other android apps - it is important to have your surface view run on a separate thread, so that the android OS does not kill it for any long running processes.
Android keeps the main UI thread - used for the menu and home buttons among other things - avaiable to recveive user input at all times. If you app causes the main thread to slow down, the OS will kill your thread and end you game.
So running your game loop off of the Surface View thread lets you game run as fast as it can when it has focus, but it also makes it possible for android to interrupt it whenever it needs to, for instance when a call come in, or the user presses the home button.
I have some trouble achieving adequate real-time performance from my application and wondering if I've architect-ed it sub-optimally. The requirement is for the application to play a sound and draw a line on a Canvas at a user specified time interval.
I have a Thread that sleeps for the user-specified time interval, wakes up and uses a Handler and Runnable to do the required drawing and sound playback. When I run the application, the beat is steady sometimes, but other times, you can see the effect of GC and random warning conditions from the AudioFlinger.
Is having a Timer thread post back to the GUI thread via Handler/Runnable the best approach? Is there something I can do to bump up the priority of my app while it is visible so that other apps and Android activity are less likely to interrupt it? Do I need to use the NDK to access real-time features not present in the Java API?
It sounds like what you want to have going is a game loop. There are many tutorials out there on creating game loops with more consistant timing that just sleeping, for example simple java android game loop. You might try searching based on that term, see if it helps.
Also when trying to create real time applications (as in constantly dynamic applications not scientific real time system) you would want to avoid to let the garbage collector run. This takes some time and can be perceived as lag. So don't create objects you need to dispose immediately etc.