Unless you’re super interested in the comparison, or in hiking recording or whatever, I wouldn’t fuss to much in doing it. It’s more a matter of understanding the “classes” of apps out there and what they do and don’t do, in terms of what you’re comparing.
In a sense Arc sits in a class of its own, in that other apps are either designed to record only Visits / Places (eg Life Cycle, Rond, Marauder), or only Trips / Paths (eg AllTrails, BikeMap), with the third class being app that record both, but only with low detail for the Trips / Paths (eg Move X, Google Timeline, Quantified Map). Arc instead records both Visits / Places and Trips / Paths in highest possible detail. So there’s no single app-to-app comparison that quite makes sense.
That said, when I was still doing daily comparison testing, Arc was still beating all of the latter two classes of apps (complete Trips/Paths, and low detail Trips/Paths + Visits/Places) in terms of energy consumption. If your testing shows up that that’s no longer the case, then I’ll dig back in and do comparison testing again.
It’s been probably a year or two since I stopped doing those daily comparisons, because it was really no contest, and not worth the daily effort. But if Arc has fallen behind, then I’ll dig in again and find out why.
Yeah at this point that’s still my main concern. If Arc is draining excessively during extended stationary periods, something is wrong. Assuming these are places where Arc (and iOS) has already seen a bunch of visits, it should be already recording at or near peak efficiency during those stationary periods.
Hmm. These segments look really clean. Perhaps the stationary segment radiuses are a bit large, indicating that there’s a fair bit of drift going on. The classifier is doing a good job of recognising that drift as still being stationary though, which could be hiding the underlying problem. Ironically, when the classifier used to do a worse job of correctly identifying stationary from drifting data it made it easier to spot cases of spurious wakeups.
To see the actual recorded samples within a stationary segment, on the Individual Segments view tap on the stationary segment in the list and choose “Not stationary”. That next view will then add a map annotation to show the actual path of the samples within the stationary segment. It’s not what the view is actually designed for, but I use it as a handy debug method, to see what’s inside stationary segments when they don’t feel right (eg radius looks too large).
My guess is that the jagged mess of samples within the stationary segment will indicate drift over perhaps 100 metres, at a guess of the map scale. That amount of drift shouldn’t be causing extended energy expensive wakeups.
Although if it’s sustained drift over more than 100 metres for long periods of time (which has been a recurrent iOS bug that’s come and gone with iOS versions), then it can be significant enough to look very much like sustained walking around the neighbourhood. That would definitely cause higher energy drain. Though I’m not convinced from your screenshots that that’s what we’re seeing (depending on the map scale, I guess).
Here’s an example of sometimes sustained drift over about 100 metres inside a large hotel:
That’s actually as good as it ever got inside that building - iOS’s wifi hotspot triangulation had finished doing the best it could, and Arc’s Trust Factor was by that point well trained to entirely distrust iOS’s reported “horizontal accuracy” (which is the crux of the above described transient iOS bug - iOS periodically lies, in big ways).
The top left prominent bit of drift likely indicates a period where the location data was impressively faking an extended walk around the neighbourhood. That would’ve almost certainly caused an extended wakeup, with active recording. The rest of the messy samples would I think possibly have been within bounds, such that the recording engine stayed in sleep mode.
Here’s an example of one of my first days at that hotel, with significantly worse drift, such that I decided to manually classify a bunch of it as bogus, to stop the visit radius being too absurdly large.
Each of those bogus segments would have caused an extended wakeup, with one of them being over 2 hours. grumbles. That there is the more extreme example of the “iOS lies” problem, in that iOS would have been reporting wildly wrong “horizontal accuracy” during those periods, insisting that it was achieving 10 metres or better accuracy, while providing location data that was more than 100 metres from the real location.
Here’s what that two hour bogus segment looked like:
That kind of bogus data looks very convincingly like sustained walking (aside from the lack of accelerometer data, which is something the recording engine can’t use for sleep mode, due to it being too energy expensive to power up the accelerometer).
Anyway, that’s all just to demonstrate what the extreme end of the problem looks like. (Though in previous years / previous iOS versions / some locations still now, it can get much more extreme than that, with drifting up to a kilometre or more away, all while still reporting accuracy of 10 metres or so. Bain of my existence, that one!)
I don’t think your screenshot is showing anything that extreme, so I’m not seeing an obvious clue for the excess energy use yet. Just thinking what to check next…
Well, a screenshot of the actual path/samples of the stationary segment within the visit will tell us a little bit more (ie the trick I mentioned above about choosing “not stationary”, just to see the extra map annotation). But I’m not convinced it will reveal the smoking gun, unless perhaps I’m quite wrong about the map scale in your screenshots.
I’ve got a bunch of performance profiling work scheduled to do before the next update ships. So as part of that I’ll be hunting for anything that might’ve snuck in as an extra energy drain.
I think I’ll also do a week of comparison testing again too. Though frustratingly there isn’t really any definitive comparison app at the moment. I might focus on Move X, Google Timeline, and Quantified Map. (Though frustratingly, Move X only offers 3 day trials, and their pricing is almost as high as / higher than Arc’s! I wonder if their recording quality has stepped up considerably since I last checked, or whether they’re just capitalising on the influx of users they no doubt got when Arc dropped its free tier last year).
Google Timeline in the past hasn’t been worth the comparison effort, because its results are far too low quality to compare on a qualitative level. From memory, Move X and Quantified Map achieved decent recording quality, albeit at significantly less detail than Arc’s. Oh there’s also Gyroscope - I almost forgot them. Can’t remember what level of detail they were recording.
Anyway, I’ll do some comparison testing. And will see if anything shows up in the profiler when I get to that this week, before shipping the next update. Oh and if you could send a screenshot of that map annotation for the actual path inside the stationary segment, that’ll tell us a bit more too. Hopefully we can get to the bottom of this!
