iosswiftaccelerometergyroscopecmmotionmanager

System performance and battery use when using the accelerometer and gyroscope


I’m working on a project that incorporates the use of the accelerometer and gyroscope.

In the specific app I’m working on, I turn on (e.g. .startGyroUpdatesToQueue) the accelerometer and gyroscope when required and off (e.g. .stopGyroUpdates()) when not needed similar to Apple's documentation recommendations.

However, I’ve noticed that there can be a slight delay when turning the accelerometer and gyroscope back on which the user notices every now and then. So the preference is to keep the accelerometer and gyroscope always on so the user gets a uninterrupted experience.

Questions:

1 - How efficient is the accelerometer and gyroscope on the system performance and battery use when these are enabled in an app?

2 - Is there evidence/data of the system performance and battery use when the accelerometer and gyroscope are on?

3 - Is there a way to pause the accelerometer and gyroscope instead of completely turning it off?


Solution

  • Answering number 3 first, on modern iPhones (5S and later) the accelerometer is never really turned off and resides in a special motion coprocessor. On these devices, the energy cost for creating the data is constant, but getting the data is expensive. It requires a timer to routinely wake up the main processor, read the data, wake up your application and execute an event on one of your threads. The closest thing to what you're asking would be for a way to have the timer turned on but not have it feed into your app. There does not appear to be a way to do this and the energy savings would probably not be that great if there were.

    With that in mind, 1 is going to be fairly subjective. The processor and your app are both going to spend more time running, but if you were already doing work on the CPU will it add that much? Similarly, if users only spend 5% of their time in a screen where you don't need the accelerometer versus 50% of their time, the overall energy impact of having it constantly on will be a lot less. That really brings us to the heart of the question, number 2.

    If you want to see what energy costs are associated with constantly polling the accelerometer versus only turning it on when needed, you should profile your app. When debugging your app, you can view CPU, energy, and other impacts of your app directly in Xcode using the Debug Navigator (6). This is explained in Apple's Energy Efficiency Guide of iOS Apps: Measure Energy Impact with Xcode. You can also get a more detailed analysis with Instruments. Apple provides full details in their Energy Efficiency Guide of iOS Apps: Measure Energy Impact with Instruments.

    Using the above tools, you should be able to get a feel for how much more energy will take to keep your accelerometer always on, and be able to make a reasoned decision about what to do.