本人iOS菜鳥一枚,最近遇到了關(guān)于deviceToken的一些問題,將解決問題的思路記錄下來,也算是一種知識(shí)的沉淀吧,或許能幫助到同樣遇到問題的你,那就再好不過了.
閑話不說,直接進(jìn)入主題.
一.介紹一下問題的背景
最近在搞遠(yuǎn)程推送的時(shí)候,忽然發(fā)現(xiàn),有時(shí)候,當(dāng)某一臺(tái)機(jī)器需要推送一條信息的時(shí)候,這臺(tái)機(jī)器可能會(huì)收到同樣的信息若干條.就去找問題所在.然而更換了證書,或者配置文件之后,故障依然存在.我就認(rèn)為這不是我的問題,是后臺(tái)服務(wù)器的問題(后臺(tái)的兄弟們,無辜躺槍),就去了解了一下后臺(tái)推送的相關(guān)流程.之前只是了解一下蘋果遠(yuǎn)程推送的原理,不是很了解我們后臺(tái)服務(wù)器端需要做些什么事情.
簡(jiǎn)述一下我目前的理解.當(dāng)app啟動(dòng)時(shí),我們?cè)赼ppDelegate里面注冊(cè)遠(yuǎn)程通知,然后蘋果服務(wù)器返回一個(gè)deviceToken給我們,在appDelegate的其中一個(gè)代理方法
- (void)application:(UIApplication *)application didRegisterForRemoteNotificationsWithDeviceToken:(NSData *)devToken
在該方法里,我們獲取到的NSData類型的devToken就是蘋果服務(wù)器根據(jù)我們這一臺(tái)設(shè)備的UDID和app的bundleID混編而成的deviceToken,我們需要將這個(gè)deviceToken傳送給我們的服務(wù)器端,或者登陸用戶的時(shí)候作為參數(shù)傳給服務(wù)器.這樣一個(gè)用戶對(duì)象就綁定了一個(gè)deviceToken.當(dāng)需要給這個(gè)用戶推送消息的時(shí)候,我們自己的后臺(tái)服務(wù)器,就會(huì)找這個(gè)用戶對(duì)應(yīng)的deviceToken和要發(fā)送的推送內(nèi)容,直接發(fā)送到蘋果的apns服務(wù)器,然后由蘋果的apns服務(wù)器將消息推送到該deviceToekn對(duì)應(yīng)的手機(jī)上.
后來我就讓后臺(tái)的兄弟查到該用戶竟然對(duì)應(yīng)了多個(gè)deviceToken,不過當(dāng)這一賬號(hào)同時(shí)在多個(gè)設(shè)備上登陸的時(shí)候,可能會(huì)綁定多個(gè)deviceToken的,但問題是測(cè)試機(jī)一共就兩個(gè),不會(huì)存在綁定八九個(gè)deviceToken的.我就在想這個(gè)deviceToken會(huì)不會(huì)發(fā)生變化.
二.問題所在
在網(wǎng)上搜索到一些知識(shí),也查詢了一下官方文檔里面對(duì)deviceToken的解釋,deviceToken會(huì)發(fā)生變化,但是僅僅在用戶在新的設(shè)備上登陸或者更新設(shè)備操作系統(tǒng)的時(shí)候會(huì)發(fā)生變化.更重要的是,我的上司領(lǐng)導(dǎo)也很肯定的告訴我,同一臺(tái)設(shè)備,同一款軟件,而且還是在沒有修改軟件的bundleID的情況下,deviceToken是不會(huì)發(fā)生變化的.
后來測(cè)試時(shí)候就無意中發(fā)現(xiàn),每當(dāng)我將運(yùn)行在真機(jī)上的demo卸載再重新運(yùn)行的時(shí)候,deviceToken竟然會(huì)是發(fā)生變化的,而且還是無規(guī)律的發(fā)生變化.這讓我發(fā)現(xiàn)了故障的所在.竟然卸載重裝會(huì)讓deviceToken發(fā)生變化.后來我分別用iOS7.0系統(tǒng)和iOS8.0的真機(jī)測(cè)試,發(fā)現(xiàn)在這兩款系統(tǒng)上,卸載重裝,蘋果返回的deviceToken不會(huì)發(fā)生變化.而只有iOS9.0以后的系統(tǒng)版本會(huì)發(fā)生變化.而且如果每次啟動(dòng)都請(qǐng)求注冊(cè)的話,只要你沒有卸載重裝,那么返回的deviceToken是不會(huì)發(fā)生變化的.只有當(dāng)你卸載重裝的時(shí)候才會(huì)發(fā)生變化.
三.解決方案
先說我嘗試過的一種解決方案吧,我將第一次安裝軟件時(shí)候所獲得的deviceToken,存儲(chǔ)在鑰匙串(keychain)內(nèi).以后不論什么時(shí)候卸載重裝軟件,只有軟件一啟動(dòng),那么就從keychain內(nèi)讀取保存的deviceToken.然后利用這個(gè)deviceToken去進(jìn)行推送服務(wù).但是我自己在用網(wǎng)絡(luò)上的那個(gè)可以模擬推送的mac小demo(名字叫做PushMeBaby)時(shí),發(fā)現(xiàn)如果卸載重裝軟件后,keychain內(nèi)保存的舊的deviceToken竟然是無效的,而新獲得的deviceToken才是有效的.這讓我感到很無奈,保存在keychain的方法沒有奏效.
后來考慮到在傳遞給自己后臺(tái)服務(wù)器時(shí)候,怎么才可能保證用一個(gè)用戶下,一個(gè)設(shè)備下僅僅保存一個(gè)deviceToken,每當(dāng)這個(gè)設(shè)備的deviceToken發(fā)生變化的時(shí)候,就替換該設(shè)備對(duì)應(yīng)的deviceToken.
最終的解決方案就是,獲取設(shè)備的UUID(被蘋果禁用的是UDID) + keychain + DeviceToken來解決這個(gè)問題.
當(dāng)軟件第一次安裝時(shí)候,獲取設(shè)備的UUID 存儲(chǔ)到keychain中,那么只要你不刷機(jī),那么這個(gè)保存在keychain中的UUID一直存在,即使你升級(jí)操作系統(tǒng)也會(huì)存在(我正好升級(jí)試了一下),這樣我們就能保證設(shè)備編碼的唯一性,在向我們自己的后臺(tái)服務(wù)器傳參數(shù)時(shí),將這個(gè)UUID和獲得的deviceToken一起傳遞過去,讓后臺(tái)做個(gè)校驗(yàn),查詢?cè)撚脩魧傩韵碌腢UID設(shè)備對(duì)應(yīng)的deviceToken是否發(fā)生變化,如果發(fā)生變化,就替換.這樣保證了該用戶在這一臺(tái)設(shè)備上綁定了一個(gè)deviceToken,這樣推送的時(shí)候就不會(huì)造成可能會(huì)推送多條信息的bug.
四.下面附上封裝的UUID和keychain的代碼,稍微修改一下即可使用.(注意:必須需要導(dǎo)入Security.framework框架)
// UuidObject.h
#import@interface UuidObject : NSObject
+ (NSString *)getUUID;
@end
// UuidObject.m
#import "UuidObject.h"
#import "KeyChainStore.h"
@implementation UuidObject
+(NSString *)getUUID
{
NSString * strUUID = (NSString *)[KeyChainStore load:@"your_app_bundleID"];
//首次執(zhí)行該方法時(shí)，uuid為空
if ([strUUID isEqualToString:@""] || !strUUID)
{
//生成一個(gè)uuid的方法
CFUUIDRef uuidRef = CFUUIDCreate(kCFAllocatorDefault);
strUUID = (NSString *)CFBridgingRelease(CFUUIDCreateString (kCFAllocatorDefault,uuidRef));
//將該uuid保存到keychain
[KeyChainStore save:KEY_USERNAME_PASSWORD data:strUUID];
}
return strUUID;
}
@end
//KeyChainStore.h
#import@interface KeyChainStore : NSObject
+ (void)save:(NSString *)service data:(id)data;
+ (id)load:(NSString *)service;
+ (void)deleteKeyData:(NSString *)service;
@end
//KeyChainStore.m
#import "KeyChainStore.h"
@implementation KeyChainStore
+ (NSMutableDictionary *)getKeychainQuery:(NSString *)service {
return [NSMutableDictionary dictionaryWithObjectsAndKeys:
(id)kSecClassGenericPassword,(id)kSecClass,
service, (id)kSecAttrService,
service, (id)kSecAttrAccount,
(id)kSecAttrAccessibleAfterFirstUnlock,(id)kSecAttrAccessible,
nil];
}
+ (void)save:(NSString *)service data:(id)data {
//Get search dictionary
NSMutableDictionary *keychainQuery = [self getKeychainQuery:service];
//Delete old item before add new item
SecItemDelete((CFDictionaryRef)keychainQuery);
//Add new object to search dictionary(Attention:the data format)
[keychainQuery setObject:[NSKeyedArchiver archivedDataWithRootObject:data] forKey:(id)kSecValueData];
//Add item to keychain with the search dictionary
SecItemAdd((CFDictionaryRef)keychainQuery, NULL);
}
+ (id)load:(NSString *)service {
id ret = nil;
NSMutableDictionary *keychainQuery = [self getKeychainQuery:service];
//Configure the search setting
//Since in our simple case we are expecting only a single attribute to be returned (the password) we can set the attribute kSecReturnData to kCFBooleanTrue
[keychainQuery setObject:(id)kCFBooleanTrue forKey:(id)kSecReturnData];
[keychainQuery setObject:(id)kSecMatchLimitOne forKey:(id)kSecMatchLimit];
CFDataRef keyData = NULL;
if (SecItemCopyMatching((CFDictionaryRef)keychainQuery, (CFTypeRef *)&keyData) == noErr) {
@try {
ret = [NSKeyedUnarchiver unarchiveObjectWithData:(__bridge NSData *)keyData];
} @catch (NSException *e) {
NSLog(@"Unarchive of %@ failed: %@", service, e);
} @finally {
}
}
if (keyData)
CFRelease(keyData);
return ret;
}
+ (void)deleteKeyData:(NSString *)service {
NSMutableDictionary *keychainQuery = [self getKeychainQuery:service];
SecItemDelete((CFDictionaryRef)keychainQuery);
}
@end
