Skip to content
This repository was archived by the owner on Aug 8, 2023. It is now read-only.

MGLMapView operating in the background #1892

Closed
quicklywilliam opened this issue Jul 14, 2015 · 9 comments
Closed

MGLMapView operating in the background #1892

quicklywilliam opened this issue Jul 14, 2015 · 9 comments

Comments

@quicklywilliam
Copy link

This is a strange one. Since switching to MGLMapView from MBXMapView, we've seen two new issues:

  1. Users complaining of excessive data usage while the app is in the background
  2. Lots of crashes while the app is in the background. A typical stack trace:
Thread 0 name:  Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0   libsystem_kernel.dylib          0x0000000197d928f8 0x197d78000 + 108792
1   Ride                            0x0000000100111ad0 CLSSignalHandler + 224
2   libsystem_platform.dylib        0x0000000197e51948 0x197e4c000 + 22856
3   libGPUSupportMercury.dylib      0x000000018d0beec0 0x18d0bc000 + 11968
4   GLEngine                        0x000000018603d950 0x18600c000 + 203088
5   GLKit                           0x0000000183bb4648 0x183b94000 + 132680
6   QuartzCore                      0x00000001878fb604 0x1878d4000 + 161284
7   QuartzCore                      0x00000001878ddafc 0x1878d4000 + 39676
8   QuartzCore                      0x00000001878dd7e8 0x1878d4000 + 38888
9   QuartzCore                      0x00000001878dce7c 0x1878d4000 + 36476
10  QuartzCore                      0x00000001878dcbd0 0x1878d4000 + 35792
11  QuartzCore                      0x00000001878d6348 0x1878d4000 + 9032
12  CoreFoundation                  0x0000000182a4ef40 0x182970000 + 913216
13  CoreFoundation                  0x0000000182a4ccb8 0x182970000 + 904376
14  CoreFoundation                  0x0000000182a4d0e8 0x182970000 + 905448
15  CoreFoundation                  0x00000001829797fc 0x182970000 + 38908
16  GraphicsServices                0x000000018da0716c 0x18d9fc000 + 45420
17  UIKit                           0x00000001881125e4 0x188098000 + 501220
18  Ride                            0x00000001000f938c main (AppDelegate.swift:14)
19  libdyld.dylib                   0x0000000197c768b4 0x197c74000 + 10420

In addition, some crashes show something like this in the trace buffer:

0.543912     CFNetwork                  0x00000001822462f8 TCP Conn 0x12f7eec20 started
0.949071     CFNetwork                  0x00000001822462f8 TCP Conn 0x130a4d8c0 started
1.499928     CFNetwork                  0x00000001821a5d44 TCP Conn 0x12d6991d0 SSL Handshake DONE
1.788614     CFNetwork                  0x00000001821a5d44 TCP Conn 0x13088d370 SSL Handshake DONE
1.883152     CFNetwork                  0x00000001821a5c54 TCP Conn 0x13088d370 starting SSL negotiation
1.883789     CFNetwork                  0x0000000182244e14 TCP Conn 0x13088d370 complete. fd: 49, err: 0
1.885635     CFNetwork                  0x00000001822461e4 TCP Conn 0x13088d370 event 1. err: 0
1.995114     CFNetwork                  0x00000001822462f8 TCP Conn 0x13088d370 started
1.998072     CFNetwork                  0x00000001821a5d44 TCP Conn 0x12f741d90 SSL Handshake DONE
2.110262     CFNetwork                  0x00000001821a5c54 TCP Conn 0x12f741d90 starting SSL negotiation
2.110827     CFNetwork                  0x0000000182244e14 TCP Conn 0x12f741d90 complete. fd: 39, err: 0
2.112343     CFNetwork                  0x00000001822461e4 TCP Conn 0x12f741d90 event 1. err: 0
2.138421     CFNetwork                  0x0000000182244e14 TCP Conn 0x12f770400 complete. fd: 47, err: 0
2.139916     CFNetwork                  0x00000001822461e4 TCP Conn 0x12f770400 event 1. err: 0
2.161457     CFNetwork                  0x0000000182244e14 TCP Conn 0x12f7213d0 complete. fd: 45, err: 0
2.162223     CFNetwork                  0x00000001822461e4 TCP Conn 0x12f7213d0 event 1. err: 0
2.166244     CFNetwork                  0x0000000182244e14 TCP Conn 0x12f766270 complete. fd: 43, err: 0
2.166548     CFNetwork                  0x0000000182244e14 TCP Conn 0x13082fdc0 complete. fd: 41, err: 0
2.166990     CFNetwork                  0x00000001822462f8 TCP Conn 0x12f770400 started
2.167728     CFNetwork                  0x00000001822461e4 TCP Conn 0x12f766270 event 1. err: 0
2.169764     CFNetwork                  0x00000001822461e4 TCP Conn 0x13082fdc0 event 1. err: 0
2.189276     CFNetwork                  0x00000001822462f8 TCP Conn 0x12f7213d0 started
2.212787     CFNetwork                  0x00000001822462f8 TCP Conn 0x12f766270 started
2.226379     CFNetwork                  0x00000001822462f8 TCP Conn 0x13082fdc0 started
2.244489     CFNetwork                  0x00000001822462f8 TCP Conn 0x12f741d90 started
2.702077     CFNetwork                  0x00000001821a5d44 TCP Conn 0x12d568cc0 SSL Handshake DONE
2.737114     CFNetwork                  0x00000001821a5c54 TCP Conn 0x12d6991d0 starting SSL negotiation
2.737447     CFNetwork                  0x0000000182244e14 TCP Conn 0x12d6991d0 complete. fd: 9, err: 0
2.739603     CFNetwork                  0x00000001822461e4 TCP Conn 0x12d6991d0 event 1. err: 0
2.769192     CFNetwork                  0x00000001821a5c54 TCP Conn 0x12d568cc0 starting SSL negotiation
2.769900     CFNetwork                  0x0000000182244e14 TCP Conn 0x12d568cc0 complete. fd: 10, err: 0
2.771782     CFNetwork                  0x00000001822461e4 TCP Conn 0x12d568cc0 event 1. err: 0
2.844155     CFNetwork                  0x00000001822462f8 TCP Conn 0x12d568cc0 started
2.858724     CFNetwork                  0x00000001822462f8 TCP Conn 0x12d6991d0 started
2.861874     CFNetwork                  0x000000018229b140 Creating default cookie storage with default identifier
2.861874     CFNetwork                  0x000000018229b10c Faulting in CFHTTPCookieStorage singleton
2.862774     CFNetwork                  0x00000001822ec068 Faulting in NSHTTPCookieStorage singleton

Our app runs extensively in the background using locations services. My educated guess is that something in the map view is making background requests, but I don't know how that's cause a crash. This is on the latest (0.5.1) release, across a variety of devices running iOS 8 and iOS 9.

@1ec5
Copy link
Contributor

1ec5 commented Jul 14, 2015

Part of setting up Mapbox GL is registering for background location updates that power your account’s location analytics dashboard. Enabling background metrics is required as long as you use Mapbox-hosted tiles with a free Starter plan. End users may turn off Mapbox Metrics in your application’s page in Settings.

The crash is #1460, which is fixed on master and will make it into the next release.

@friedbunny
Copy link
Contributor

We've done some fairly extreme battery testing on iOS around metrics so far, but if we're falling down on battery life or data usage that is something we'll fix. Have your users happened to give you hard numbers on background data usage, @quicklywilliam?

@mb12
Copy link

mb12 commented Jul 14, 2015

@friedbunny My understanding is that on iOS , OS terminates all network activity when the app goes to background (It consistently does this on my wifi only iPhone as well as iPad). So any data usage has to happen when the app is in foreground.
Its most likely a problem with data usage in general (rather than background data usage).

Is there some way to track data usage for an app on a wifi only iOS device? Mapbox GL test app does not even show up under "Cellular Usage" on my wifi only test device. It would be good to track this number since it might expose performance bugs with caching or just large vector tiles.

@quicklywilliam
Copy link
Author

@friedbunny we're seeing it in the form of battery drain. The numbers we track probably for cell battery usage (using this: https://gist.github.com/quicklywilliam/842859749c5d78251a77) probably won't mean a lot to you, but suffice it to say that usage went from nothing or very little to higher than I have ever seen.

@quicklywilliam
Copy link
Author

@1ec5 good to know. I'm concerned about this, mostly because CoreLocation is a black box and it is extremely difficult for us to debug background location issues (a key component of our app). For example, other apps using location or running in the background can cause our app to fail to defer GPS updates, greatly increasing battery usage.

At least for development, I'd like to turn off Mapbox background metrics to isolate the variables. I went ahead an upgraded to the basic plan. Is there anything else I need to do? Note that our app already registers for background location updates.

@1ec5
Copy link
Contributor

1ec5 commented Jul 14, 2015

At least for development, I'd like to turn off Mapbox background metrics to isolate the variables. I went ahead an upgraded to the basic plan. Is there anything else I need to do?

@quicklywilliam, please get in touch with mobile@mapbox.com for the next steps. Thanks!

/cc @sbma44 @bleege

@crazyBoat
Copy link

I will like to know the best way to turn off the metrics in background mode (we have the premium plan). We need to add the capabilities for location updates in background mode and the current api keep using the background mode forever... the client show the blue bar on the top in background mode (the app is using the location service)

@friedbunny
Copy link
Contributor

Hi @crazyBoat, please email us at mobile@mapbox.com and we'll help you out.

@robipresotto
Copy link

after upgrade to 0.5 the app keep working in background mode if you disable metrics+set showUserLocation:NO - suggestions to stop updating the user location in background mode?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants