Code practice of background positioning upload

[[141852]]

Preface

In the previous article, I mentioned that I am currently working on a social APP based on LBS positioning. One of its main functions is to be able to locate the location of each member in the social circle in real time. Uploading the location in real time in the background is a very important technical point. Next, let me talk about my practical experience in this regard.

need

Let's first look at the specific requirements for implementing this function. Since we are a real-time positioning social app, we need to do the following:

1. If the user's location is constantly changing, report it once in a while

Since we hope to be able to feedback the user's location changes in real time in the APP, regular reporting is a necessity

2. If the user's movement speed is very slow, report once every certain distance

If the user is in a low-speed state (for example, the walking speed is about 1m/s), then if we still report it in the way of (1), the points on the map will be very dense because the change is too small, and this data is not very meaningful (and if we want to provide trajectory services, these dense points must be spent). So at this time, we report it according to the distance interval.

3. If the user's location does not change after arriving at a certain place, do not continue to report

We only care about the change of location. If the user's location does not change or changes very little, there is actually no need to report their location (such as entering a company or waiting for a long time at a red light). In this case, we will not report it (to save power).

4. Switch to the backend and be able to report location

Background reporting is required. Users cannot always run our app (supported since iOS 4)

5. After the APP stops running for various reasons (user actively closes, system kills), it must also be able to report the location

The chances of users actively closing the app are small, but it is very common for the app to be killed due to system scheduling. At this time, we must also be able to report it (iOS7 has supported waking up after being killed)

After analyzing the requirements, we will start to introduce how to implement

Prepare

First, do some preparation

In the Capabilities section of the target, turn on Background Modes and check Location updates.

Then add a key of NSLocationAlawaysUsageDescription in plist and type anything in value

After completing these two steps, our preliminary work is completed. Background Modes is a new feature introduced in iOS7, and NSLocationAlawaysUsageDescription is a prompt description introduced to enhance the permission mechanism. If you don't add this, the positioning function will not be used.

Code

Positioning must deal with CLLocationManager, so we first define a subclass of CLLocationManager and define three variables according to the requirements.

 @interface MMLocationManager : CLLocationManager 
 
 + (instancetype)sharedManager; 
 
 @property (nonatomic, assign) CGFloat minSpeed; //Minimum speed  
 @property (nonatomic, assign) CGFloat minFilter; //Minimum range  
 @property (nonatomic, assign) CGFloat minInteval; //Update interval   
 
 @end  

Here are some explanations of these parameters:

• minSpeed ​​If the current speed is greater than this value, the requirement is met (1) Update based on time (minFilter) If the current speed is less than this value, the requirement is met (2) Update based on range (minInteval)
• minFilter The minimum trigger range for the requirement (1)
• minInteval update interval for requirements (2)

Next is the initialization function

 - (instancetype)init
 {
 self = [ super init];
 if ( self )
 {
 self.minSpeed ​​= 3 ;
 self.minFilter = 50 ;
        self.minInteval = 10 ; 
 
 self.delegate = self;
        self.distanceFilter = self.minFilter;
        self.desiredAccuracy = kCLLocationAccuracyBest;
 }
 return self;
 }

The default value here can be adjusted according to needs

Then the processing logic after the location update is actually very simple.

 - ( void )locationManager:(CLLocationManager *)manager didUpdateLocations:(NSArray *)locations
 {
    CLLocation *location = locations[ 0 ]; 
 
 NSLog(@ "%@" ,location); 
 
 //Adjust the trigger range according to the actual situation  
    [self adjustDistanceFilter:location]; 
 
 //Upload data  
    [self uploadLocation:location];
 }

The adjustDistanceFilter function is the core of the entire code and will dynamically adjust the distanceFilter parameter according to the current speed to meet our needs.

 /**
 * Rule: If the speed is less than minSpeed ​​m/s, set the trigger range to 50m
 * Otherwise, set the trigger range to minSpeed*minInteval
 * At this time, if the speed changes by more than 10%, update the current trigger range (the limitation here is because the distanceFilter cannot be set continuously,
 * Otherwise uploadLocation will be triggered continuously)
 */  
 - ( void )adjustDistanceFilter:(CLLocation*)location
 {
 // NSLog(@"adjust:%f",location.speed);   
     
 if (location.speed < self.minSpeed)
 {
 if ( fabs(self.distanceFilter-self.minFilter) > 0 .1f )
 {
            self.distanceFilter = self.minFilter;
 }
 }
 else  
 {
        CGFloat lastSpeed ​​= self.distanceFilter/self.minInteval; 
         
 if ( (fabs(lastSpeed-location.speed)/lastSpeed ​​> 0 .1f) || (lastSpeed ​​< 0 ) )
 {
            CGFloat newSpeed ​​= ( int )(location.speed+ 0.5f );
            CGFloat newFilter = newSpeed*self.minInteval; 
             
            self.distanceFilter = newFilter;
 }
 }
 }

It should be noted here that the distanceFilter parameter cannot be set all the time because each time it is set, the didUpdateLocations callback will be triggered immediately after the next second (the system's standard shortest update interval is 1 second, that is, the update frequency is 1hz). Therefore, the distanceFilter will be reset only when the change exceeds 10%.

#p#

Next, in order to be able to be awakened correctly when being killed, we have to do the last step and add the following code to AppDelegate's didFinishLaunchingWithOptions

 if ([launchOptions objectForKey:UIApplicationLaunchOptionsLocationKey]) { 
     
 if ( [[MMLocationManager sharedManager] respondsToSelector: @selector (requestAlwaysAuthorization)] )
 {
        [[MMLocationManager sharedManager] requestAlwaysAuthorization];
 } 
 
 //This is a new property for background positioning in iOS9. If it is not set, a blue bar will appear at the top (similar to hotspot connection)  
 if ([self respondsToSelector: @selector (allowsBackgroundLocationUpdates)])
 {
        [MMLocationManager sharedManager].allowsBackgroundLocationUpdates = YES;
 } 
 
    [[MMLocationManager sharedManager] startUpdatingLocation];
 }

This is because when the killed APP is awakened by the system in the background, launchOptions will contain the UIApplicationLaunchOptionsLocationKey** field for identification. At this time, we can restart the positioning function.

At this point, the positioning function that meets our needs is completed. For this purpose, I wrote a demo to verify (use the simulator and select Debug->Location->Freeway Drive) The result is as follows

Next we will discuss several related issues

discuss

Why not use a timer to control the positioning interval?

There are many tutorials on the Internet that use NSTimer to achieve this, but this is not very good. Although the positioning interval is fixed, the problem of power consumption cannot be solved. The background will continue to update the positioning regardless of whether the current location is updated. Of course, if your usage scenario is to upload at regular intervals, you can use a timer to handle it.

What are the problems with using distanceFilter?

Since distanceFilter = currentSpeed ​​* minInteval, the interval time will fluctuate due to the change of speed, but this fluctuation is within the acceptable range. If the speed increases or decreases, the next update time will be shortened or lengthened accordingly. However, because we are in a real life environment, the speed change cannot be so fast, so this error is acceptable. In addition, we correct the speed of distanceFilter, so the interval will generally remain within our range.

Why not use allowDeferredLocationUpdatesUntilTraveled:timeout:

allowDeferredLocationUpdatesUntilTraveled is a new API introduced in iOS 6. From the name, we can know that the function of this function is to delay the location update until the movement is xx meters or the time exceeds xx seconds. So doesn't this function just meet all our requirements? But I never expected that this is not the case. This function is not easy to use

Next is the time to complain ლ(⁰⊖⁰ლ)

Why is this function not easy to use? First of all, this function has many requirements. Let's see what conditions must be met for this function to work.

• Only iPhone 5 and later hardware devices are supported
• desiredAccuracy must be set to kCLLocationAccuracyBest or kCLLocationAccuracyBestForNavigation
• distanceFilter must be set to kCLDistanceFilterNone
• It only takes effect when the APP is running in the background. There will be no delay when the APP is running in the foreground.
• This function is only effective when the system is in low power state.

Regarding the description of Low Power State in iOS, I only found some definitions in the documents on Apple's official website.

iOS is very good at getting a device into a low power state when it's not being used. At idle, very little power is drawn and energy impact is low. When tasks are actively occurring, system resources are being used and those resources require energy. However, sporadic tasks can cause the device to enter an intermediate state—neither idle nor active—when the device isn't doing anything. There may not be enough time during these intermediate states for the device to reach absolute idle before the next task executes. When this occurs, energy is wasted and the user's battery drains faster.

As far as I know, this "Low Power State" can only be triggered when the screen is black (not just locked). Any operation on the screen with any power (even push notifications) will cause the APP to exit this state. At the same time, it cannot be entered when the APP is charging.

I tried to use this API on a real device and a simulator, but the app still locates at 1HZ (because kCLDistanceFilterNone is set)
Although locationManager:didFinishDeferredUpdatesWithError: was successfully called back after the specified time, the result was still not deferred. So I checked and found that this function cannot be debugged directly because:

• The simulator is not supported. deferredLocationUpdatesAvailable is used to detect whether the device supports the simulator and returns NO.
• Real device debugging is not supported because Xcode will prevent the program from sleeping during debugging, causing the program to be unable to enter a low-power state

The conclusion is... this thing can't even be debugged, so I don't have that much time to go out and test it... Besides, the method I mentioned above can basically meet the needs... So I have given up on continuing to study this API because even if I use this thing, it's just icing on the cake.

If any of you know how to use this correctly, please leave a message to tell me. Thank you very much!