关于设备的唯一标识符

UDID是Unique Device Identifier的简称，也就是唯一设备标识的意思。于iOS SDK中取得的方法是UIDevice的一个叫uniqueIdentifier的NSString*，由于这个ID字符串是基于设备的，应用开发人员可以通过获取此ID来用于记录区分设备。正是由于这个特性，可能会导致一些隐私等等相关的问题，Apple于iOS5中将这个UDID废掉了，SDK中被标记为了Deprecated，虽然为了兼容低版本的源代码而继续存在，但并不会再返回任何有实际意义的东西。

最近在做Flurry的统计功能时，发现还是需要用到可以识别设备的东西的，好方便分析数据，经过一段时间的研究、试验，发现了这个应该还算是比较靠谱的方法……

其实早在UDID被deprecated的消息刚出来时，就已经有很多人开始研究对策了，我也google到了各种五花八门的解决方案，最后还是觉得这个UUID的方案比较合适，毕竟是苹果官方文档里推荐的替换UDID的方法。

关于UUID的具体说明可以查看下面参考文章中给出的苹果官方文档链接。简单来说，UUID就是一个随机序列字符串生成器，有点像Microsoft Windows的COM GUID生成器的作用，比起自己随机一个字符串的好处就是这东西能够保证唯一性，适用于标记。调用方法如下：

1	CFUUIDRef uuidRef = CFUUIDCreate(kCFAllocatorDefault);

2	NSString *uuid = (NSString *)CFUUIDCreateString (kCFAllocatorDefault,uuidRef);

然后呢，官方建议的做法是用：

1	NSUserDefaults *userDefaults = [NSUserDefaults standardUserDefaults];

2	[userDefaults setObject:uuid forKey:@"UUID"];

这样的做法把生成的ID保存起来，下次再用的时候就直接读取已经保存的ID了。显然，那个UUID生成只是个“随机字符串”生成器，并不能像UDID那样保证每次取得的串都一样！保存起来虽然能保证用户再次打开这个应用时，能够获得一致的标识ID，但不能保证用户删除应用重新安装后这个ID的一致性，因为NSUserDefaults只是个像游戏存档一样的东西，游戏删了，存档也就跟着一块删了。所以，这个“存存档”的方法并不是一个比较完善的解决方案，一个更好的做法是利用keychain保存这个生成的UUID。

关于keychain这个东西的概念可以到这里学习：https://developer.apple.com/library/ios/#documentation/Security/Conceptual/keychainServConcepts/01introduction/introduction.html，简言之就是每个应用程序都有一个可以用于安全保存一些如密码、认证等信息的keychain，通过对应用签名时的一些设置，还可以利用keychain的方式实现同一开发者签证（就是相同bundle seed）下的不同应用之间共享信息的操作。比如你有一个开发者帐户，并开发了两个不同的应用A和B，然后通过对A和B的keychain access group这个东西指定共用的访问分组，就可以实现共享此keychain中的内容。而且，对比NSUserDefaults的一点不同之处就是此信息不会随应用的删除而消失！

关于Keychain的应用，Apple提供了一个叫GenericKeychain的例子程序，在这里：http://developer.apple.com/library/ios/#samplecode/GenericKeychain/Listings/Classes_KeychainItemWrapper_h.html#//apple_ref/doc/uid/DTS40007797-Classes_KeychainItemWrapper_h-DontLinkElementID_9，其中封装了一个简化Keychain操作的类：KeychainItemWrapper，可以拿来直接使用，记得加入Security.framework！

参考代码如下：

1	KeychainItemWrapper *keychainItem = [[KeychainItemWrapper alloc]

2	initWithIdentifier:@"UUID"

3	accessGroup:@"YOUR_BUNDLE_SEED.com.yourcompany.userinfo"];

4	NSString *strUUID = [keychainItem objectForKey:(id)kSecValueData];

5	if ([strUUID isEqualToString:@""])

6

{

7	CFUUIDRef uuidRef = CFUUIDCreate(kCFAllocatorDefault);

8	strUUID = (NSString *)CFUUIDCreateString (kCFAllocatorDefault,uuidRef);

9	[keychainItem setObject:strUUID forKey:(id)kSecValueData];

10

}

11	[FlurryAnalytics setUserID:strUUID];

12	[keychainItem release];

关于keychain access groups的设置，传统方法是在Xcode项目target的Build Settings的Code Signing段中加入Code Signing Entitlements的配置文件，加入group信息，详细操作搜索一下就能找到。新版本的Xcode直接整合了生成Entitlements的功能，在指定target的Summary的最后一个段Entitlements中勾选Enable Entitlements，然后在下面的Keychain Access Groups中加入”com.yourcompany.userinfo”类的共享group名。这里要注意一点，参考IDE默认生成的对应app自身id名的group可以发现，这里的group并没有加入bundle seed，看一下生成的entitlements文件中的内容可以发现group名头部被自动添加了“$(AppIdentifierPrefix)”这种替换变量！
在最开始测试Keychain读写时，参考下面”如何解决苹果公司禁止用UUID的方法”这篇文章中的方法，一直在keychainItem setObject时报异常，断点跟踪了一下，发现是封装类的writeToKeychain函数中的SecItemAdd函数返回
errSecParam                  = -50,     /* One or more parameters passed to a function where not valid. */

这个错误，最初以为是access group设置的问题，替换参数为nil后报错依旧.最后google到stack overflow上的”Storing keys in KeyChain with KeyChainItemWrapper”这篇问答后意识到原来setObject的key不能随意指定任意的string，而必须使用预定义好的一些key，替换key为kSecValueData后，问题解决。