oc已全部翻译完成视频总4个视频免费下载
公司主营业务：网站建设、成都做网站、移动网站开发等业务。帮助企业客户真正实现互联网宣传，提高企业的竞争能力。成都创新互联是一支青春激扬、勤奋敬业、活力青春激扬、勤奋敬业、活力澎湃、和谐高效的团队。公司秉承以“开放、自由、严谨、自律”为核心的企业文化，感谢他们对我们的高要求，感谢他们从不同领域给我们带来的挑战，让我们激情的团队有机会用头脑与智慧不断的给客户带来惊喜。成都创新互联推出锡林郭勒盟免费做网站回馈大家。
链接:
提取码:64s9
oc已全部翻译完成视频 总4个视频|OC教程04：速建+讲解.mp4|OC教程03：如何给机器人添加纹理与着色.mp4|OC教程02：场景管理.mp4|OC教程01：涂鸦的投射原理与应用.mp4
Key-Value Coding 俗称"键值编码"，苹果官方简称这个模式为KVC编码模式，也就是说可以通过一个Key去访问某一个属性，或者给对象去赋值，而不需要去明确存取方法，这样就可以动态的访问和修改对象的属性，而不是在编译的时候去确定，这也是iOS开发中的一大便利，其实有很多的框架和功能是用KVC去实现的，这个技术存在已经很长时间了，在网上也有很多相关的教程去教童鞋们如何去使用KVC，在这里，我们就只是简单的介绍一下KVC的底层实现和使用方法。
从苹果官方对KVC的解释来看，其实KVC在Fundation框架中占有很高的地位，诸如Core-Data之类的框架都使用到了KVC技术，我们在开发中可能常见的API有：
NSKeyValueCoding类别中还有其他的一些比较重要方法，如下:
说起KVC的执行流程，我们有很多初级工程师都不大清楚，只知道KVC是如何使用的，而不知道KVC是怎么Key的寻找策略的。下图我们借鉴了MJ老师的两幅PPT来解释
上图我们可以看到
简单说KVC机制在设值的时候会按照 setKey: 》_setKey 》_key 》_isKey 》key 》 isKey 顺序搜索成员并进行赋值操作，但是如果开发者重写了类方法+ (BOOL)accessInstanceVarialbesDirectly并且让其返回NO，这样在搜索的时候会直接从步骤 1跳转到步骤5 。
举一个例子,我们先创建一个Person类
然后用KVC赋值
最终在控制台打印的结果是
当调用valueForKey:方法时，KVC对key的搜索顺序有点不同于setValue:forKey:方法，大致步骤如下：
如
最终打印为
上述可以看出，当Key查找不到值的时候会走 valueForUndefinedKey 方法中抛出异常
类的成员变量有可能是自定义类或其他复杂数据类型，对这种成员变量可以先用KVC获取该属性，然后再用KVC来获取这个自定义类的属性，这样一层层去获取，但这样比较繁琐。对此KVC提供一个解决方案，就是键路径keyPath，顾名思义就是按照路径寻找key。主要有两个以下两个方法：
在上述Person中我们创建一个Cat类
在Cat类中我们创建一个属性 name
我们如果需要用KVC对Person对象中Cat对象赋值的话，我们就必须用到KeyPath了
KVC对于keyPath的搜索机制第一步就是分离key，用小数点.来分割key，然后再像普通key一样按照上面介绍的顺序搜索。
使用KVC过程中最常见的异常就是不小心使用了错误的key，或者在设值中不小心传了nil的值，KVC有专门的方法处理这些异常。
该方法返回一个可变有序数组。对于无序的容器，可以用以下方法：
该方法返回一个可变的无序集合。同时他们也有对应的keyPath版本：
当NSDictionary对象使用KVC时，valueForKey:的表现行为和objectForKey:一样，使用valueForKeyPath:可访问多层嵌套的字典会方便点，在KVC中有两个关于NSDictionary的方法：
当开发者需要验证能不能用KVC设定某个值时，就需要在进行KVC赋值前验证值value的有效性，API文档里面提供下面的方法进行判断值的有效性。
该方法的工作原理：先找一下你的类中是否实现了方法-(BOOL)validateKey:error:，如果实现了就会根据实现方法里面的自定义逻辑返回NO或者YES，如果没有实现这个方法，则系统默认返回就是YES。
输出结果为
这里首先调用方法 [self validateValue:value forKey:key error:error] ;，这里，由于我实现了方法- (BOOL)validatePersonName:(id *)value error:(out NSError * _Nullable __autoreleasing *)outError ，所以就在这里进行值value有效性的判断，这里 [name isEqualToString:@"小明"] 我就给返回YES，否则就返回NO。
KVC在iOS开发中非常的灵活，提供了开发者更多的赋值和取值操作的选择，它的有点明显，缺点也有，如果key只写错，编写的时候不会报错，但是运行的时候会报错，在实际开发中需要开发者时刻小心自己输入的键值，也时刻提醒着开发者一旦使用KVC就要做容错处理。
iOS开发就是为装有iOS系统的设备完成应用软件或游戏软件的开发，ios开发的设计模式有代理模式、观察者模式、MVC模式、单例模式、策略模式和工厂模式。
先来看看官方的文档，是这样写的：In a multithreaded application, notifications are always delivered in the thread in which the notification was posted, which may not be the same thread in which an observer registered itself.翻译过来是：在多线程应用中，Notification在哪个线程中post，就在哪个线程中被转发，而不一定是在注册观察者的那个线程中。也就是说，Notification的发送与接收处理都是在同一个线程中。为了说明这一点，我们先来看一个示例：代码清单1：Notification的发送与处理@implementation ViewController- (void)viewDidLoad {[super viewDidLoad];NSLog(@"current thread = %@", [NSThread currentThread]);[[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(handleNotification:) name:TEST_NOTIFICATION object:nil];dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{[[NSNotificationCenter defaultCenter] postNotificationName:TEST_NOTIFICATION object:nil userInfo:nil];});}- (void)handleNotification:(NSNotification *)notification{NSLog(@"current thread = %@", [NSThread currentThread]);NSLog(@"test notification");}@end其输出结果如下：2015-03-11 22:05:12.856 test[865:45102] current thread = {number = 1, name = main}2015-03-11 22:05:12.857 test[865:45174] current thread = {number = 2, name = (null)}2015-03-11 22:05:12.857 test[865:45174] test notification可以看到，虽然我们在主线程中注册了通知的观察者，但在全局队列中post的Notification，并不是在主线程处理的。所以，这时候就需要注意，如果我们想在回调中处理与UI相关的操作，需要确保是在主线程中执行回调。这时，就有一个问题了，如果我们的Notification是在二级线程中post的，如何能在主线程中对这个Notification进行处理呢?或者换个提法，如果我们希望一个Notification的post线程与转发线程不是同一个线程，应该怎么办呢?我们看看官方文档是怎么说的：For example, if an object running in a background thread is listening for notifications from the user interface, such as a window closing, you would like to receive the notifications in the background thread instead of the main thread. In these cases, you must capture the notifications as they are delivered on the default thread and redirect them to the appropriate thread.这里讲到了“重定向”，就是我们在Notification所在的默认线程中捕获这些分发的通知，然后将其重定向到指定的线程中。一种重定向的实现思路是自定义一个通知队列(注意，不是NSNotificationQueue对象，而是一个数组)，让这个队列去维护那些我们需要重定向的Notification。我们仍然是像平常一样去注册一个通知的观察者，当Notification来了时，先看看post这个Notification的线程是不是我们所期望的线程，如果不是，则将这个Notification存储到我们的队列中，并发送一个信号(signal)到期望的线程中，来告诉这个线程需要处理一个Notification。指定的线程在收到信号后，将Notification从队列中移除，并进行处理。官方文档已经给出了示例代码，在此借用一下，以测试实际结果：代码清单2：在不同线程中post和转发一个Notification@interface ViewController ()@property (nonatomic) NSMutableArray *notifications; // 通知队列@property (nonatomic) NSThread *notificationThread; // 期望线程@property (nonatomic) NSLock *notificationLock; // 用于对通知队列加锁的锁对象，避免线程冲突@property (nonatomic) NSMachPort *notificationPort; // 用于向期望线程发送信号的通信端口@end@implementation ViewController- (void)viewDidLoad {[super viewDidLoad];NSLog(@"current thread = %@", [NSThread currentThread]);// 初始化self.notifications = [[NSMutableArray alloc] init];self.notificationLock = [[NSLock alloc] init];self.notificationThread = [NSThread currentThread];self.notificationPort = [[NSMachPort alloc] init];self.notificationPort.delegate = self;// 往当前线程的run loop添加端口源// 当Mach消息到达而接收线程的run loop没有运行时，则内核会保存这条消息，直到下一次进入run loop[[NSRunLoop currentRunLoop] addPort:self.notificationPortforMode:(__bridge NSString *)kCFRunLoopCommonModes];[[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(processNotification:) name:@"TestNotification" object:nil];dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{[[NSNotificationCenter defaultCenter] postNotificationName:TEST_NOTIFICATION object:nil userInfo:nil];});}- (void)handleMachMessage:(void *)msg {[self.notificationLock lock];while ([self.notifications count]) {NSNotification *notification = [self.notifications objectAtIndex:0];[self.notifications removeObjectAtIndex:0];[self.notificationLock unlock];[self processNotification:notification];[self.notificationLock lock];};[self.notificationLock unlock];}- (void)processNotification:(NSNotification *)notification {if ([NSThread currentThread] != _notificationThread) {// Forward the notification to the correct thread.[self.notificationLock lock];[self.notifications addObject:notification];[self.notificationLock unlock];[self.notificationPort sendBeforeDate:[NSDate date]components:nilfrom:nilreserved:0];}else {// Process the notification here;NSLog(@"current thread = %@", [NSThread currentThread]);NSLog(@"process notification");}}@end运行后，其输出如下：2015-03-11 23:38:31.637 test[1474:92483] current thread = {number = 1, name = main}2015-03-11 23:38:31.663 test[1474:92483] current thread = {number = 1, name = main}2015-03-11 23:38:31.663 test[1474:92483] process notification可以看到，我们在全局dispatch队列中抛出的Notification，如愿地在主线程中接收到了。这种实现方式的具体解析及其局限性大家可以参考官方文档Delivering Notifications To Particular Threads，在此不多做解释。当然，更好的方法可能是我们自己去子类化一个NSNotificationCenter，或者单独写一个类来处理这种转发。NSNotificationCenter的线程安全性苹果之所以采取通知中心在同一个线程中post和转发同一消息这一策略，应该是出于线程安全的角度来考量的。官方文档告诉我们，NSNotificationCenter是一个线程安全类，我们可以在多线程环境下使用同一个NSNotificationCenter对象而不需要加锁。原文在Threading Programming Guide中，具体如下：The following classes and functions are generally considered to be thread-safe. You can use the same instance from multiple threads without first acquiring a lock.NSArray...NSNotificationNSNotificationCenter我们可以在任何线程中添加/删除通知的观察者，也可以在任何线程中post一个通知。NSNotificationCenter在线程安全性方面已经做了不少工作了，那是否意味着我们可以高枕无忧了呢?再回过头来看看第一个例子，我们稍微改造一下，一点一点来：代码清单3：NSNotificationCenter的通用模式@interface Observer : NSObject@end@implementation Observer- (instancetype)init{self = [super init];if (self){_poster = [[Poster alloc] init];[[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(handleNotification:) name:TEST_NOTIFICATION object:nil]}return self;}- (void)handleNotification:(NSNotification *)notification{NSLog(@"handle notification ");}- (void)dealloc{[[NSNotificationCenter defaultCenter] removeObserver:self];}@end// 其它地方[[NSNotificationCenter defaultCenter] postNotificationName:TEST_NOTIFICATION object:nil];上面的代码就是我们通常所做的事情：添加一个通知监听者，定义一个回调，并在所属对象释放时移除监听者;然后在程序的某个地方post一个通知。简单明了，如果这一切都是发生在一个线程里面，或者至少dealloc方法是在-postNotificationName:的线程中运行的(注意：NSNotification的post和转发是同步的)，那么都OK，没有线程安全问题。但如果dealloc方法和-postNotificationName:方法不在同一个线程中运行时，会出现什么问题呢?我们再改造一下上面的代码：代码清单4：NSNotificationCenter引发的线程安全问题#pragma mark - Poster@interface Poster : NSObject@end@implementation Poster- (instancetype)init{self = [super init];if (self){[self performSelectorInBackground:@selector(postNotification) withObject:nil];}return self;}- (void)postNotification{[[NSNotificationCenter defaultCenter] postNotificationName:TEST_NOTIFICATION object:nil];}@end#pragma mark - Observer@interface Observer : NSObject{Poster *_poster;}@property (nonatomic, assign) NSInteger i;@end@implementation Observer- (instancetype)init{self = [super init];if (self){_poster = [[Poster alloc] init];[[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(handleNotification:) name:TEST_NOTIFICATION object:nil];}return self;}- (void)handleNotification:(NSNotification *)notification{NSLog(@"handle notification begin");sleep(1);NSLog(@"handle notification end");self.i = 10;}- (void)dealloc{[[NSNotificationCenter defaultCenter] removeObserver:self];NSLog(@"Observer dealloc");}@end#pragma mark - ViewController@implementation ViewController- (void)viewDidLoad {[super viewDidLoad];__autoreleasing Observer *observer = [[Observer alloc] init];}@end这段代码是在主线程添加了一个TEST_NOTIFICATION通知的监听者，并在主线程中将其移除，而我们的NSNotification是在后台线程中post的。在通知处理函数中，我们让回调所在的线程睡眠1秒钟，然后再去设置属性i值。这时会发生什么呢?我们先来看看输出结果：2015-03-14 00:31:41.286 SKTest[932:88791] handle notification begin2015-03-14 00:31:41.291 SKTest[932:88713] Observer dealloc2015-03-14 00:31:42.361 SKTest[932:88791] handle notification end(lldb)// 程序在self.i = 10处抛出了"Thread 6: EXC_BAD_ACCESS(code=EXC_I386_GPFLT)"经典的内存错误，程序崩溃了。其实从输出结果中，我们就可以看到到底是发生了什么事。我们简要描述一下：当我们注册一个观察者是，通知中心会持有观察者的一个弱引用，来确保观察者是可用的。主线程调用dealloc操作会让Observer对象的引用计数减为0，这时对象会被释放掉。后台线程发送一个通知，如果此时Observer还未被释放，则会向其转发消息，并执行回调方法。而如果在回调执行的过程中对象被释放了，就会出现上面的问题。当然，上面这个例子是故意而为之，但不排除在实际编码中会遇到类似的问题。虽然NSNotificationCenter是线程安全的，但并不意味着我们在使用时就可以保证线程安全的，如果稍不注意，还是会出现线程问题。那我们该怎么做呢?这里有一些好的建议：尽量在一个线程中处理通知相关的操作，大部分情况下，这样做都能确保通知的正常工作。不过，我们无法确定到底会在哪个线程中调用dealloc方法，所以这一点还是比较困难。注册监听都时，使用基于block的API。这样我们在block还要继续调用self的属性或方法，就可以通过weak-strong的方式来处理。具体大家可以改造下上面的代码试试是什么效果。使用带有安全生命周期的对象，这一点对象单例对象来说再合适不过了，在应用的整个生命周期都不会被释放。使用代理。
加上Android生态中纷繁复杂的各种奇葩尺寸，现在APP设计开发必须考虑适配大、中、小三种屏幕。所以如何做到交付一套设计稿解决适配大中小三屏的问题？设计和开发之间采用什么协作模式？一个基本思路是：
1、选择一种尺寸作为设计和开发基准；
2、定义一套适配规则，自动适配剩下两种尺寸；
3、特殊适配效果给出设计效果。
手机淘宝的iPhone 6/iPhone 6 Plus适配版本即将提交App store审核。先晒一下我们采用的协作模式，再慢慢说明原委。
第一步，视觉设计阶段，设计师按宽度750px（iPhone 6）做设计稿，除图片外所有设计元素用矢量路径来做。设计定稿后在750px的设计稿上做标注，输出标注图。同时等比放大1.5倍生成宽度1125px的设计稿，在1125px的稿子里切图。
第二步，输出两个交付物给开发工程师：一个是程序用到的@3x切图资源，另一个是宽度750px的设计标注图。
第三步，开发工程师拿到750px标注图和@3x切图资源，完成iPhone 6（375pt）的界面开发。此阶段不能用固定宽度的方式开发界面，得用自动布局（auto layout），方便后续适配到其它尺寸。
第四步，适配调试阶段，基于iPhone 6的界面效果，分别向上向下调试iPhone 6 plus（414pt）和iPhone 5S及以下（320pt）的界面效果。由此完成大中小三屏适配。
为什么选择iPhone 6作为基准尺寸？
当面对大中小三种屏幕需要适配的时候，很容易想到先做好一种屏幕，再去适配剩下两种屏幕。第一个决定是到底以哪种屏幕作为设计和开发的基准尺寸。我们选择中间尺寸的iPhone 6（750px/375pt）作为基准，基于几个原因：
1、从中间尺寸向上和向下适配的时候界面调整的幅度最小。375pt下的设计效果适配到414pt和320pt偏差不会太大。假设以414pt为基准做出很优雅的设计，到320pt可能元素之间比例就不是那么回事了，比如图片和文字之间视觉比例可能失调。
2、iPhone 6 plus有两种显示模式，标准模式分辨率为1242x2208，放大模式分辨率为1125x2001（即iPhone 6的1.5倍）。可见官方系统里iPhone 6和iPhone 6 plus分辨率之间就存在1.5倍的倍率关系。很多情况下这两种尺寸可以用1.5倍直接等比适配。
3、1242x2208这个奇葩的数值是苹果官方都不愿意公开宣传的一个分辨率，不便于记忆和计算栅格。640x1136虽然是广泛应用的一个分辨率，但是大屏时代依然以小尺寸为设计基准显然不合时宜，设计师会停留在小屏的视角做设计。
所以，iPhone6的750x1334是最适合基准尺寸。
只交付一套设计稿，默认用什么规则来适配？
前文提到适配策略是先选择iPhone 6作为基准设计尺寸，然后通过一套适配规则自动适配到另外两种尺寸。这套适配规则总结起来就一句话：文字流式，控件弹性，图片等比缩放。
控件弹性指的是，navigation、cell、bar等适配过程中垂直方向上高度不变；水平方向宽度变化时，通过调整元素间距或元素右对齐的方式实现自适应。这样屏幕越大，在垂直方向上可以显示更多内容，发挥大屏幕的优势。
按照上述默认适配规则，大中小三种屏幕显示效果均相同。有时候想在大屏幕显示更多内容，需要设计出特殊适配效果。比如App store首页焦点图，从iPhone 6适配到iPhone 6 plus时焦点图尺寸和排版做了特殊处理。底下应用列表也从一排3+个变成一排4+个，真正实现了大屏幕显示更多内容的理念。这些就需要设计师给出相应设计稿。
1.什么是蓝牙4.0，蓝牙其它标准又是什么？
详细描述：低功耗蓝牙(Low Energy; LE)，又视为Bluetooth Smart或蓝牙核心规格4.0版本。其特点具备节能、便于采用，是蓝牙技术专为物联网(Internet of Things; IOT)开发的技术版本。所以它最主要的特点是低功耗，普及率高。现在所说的蓝牙设备，大部分都是在说4.0设备，ble也特指4.0设备。 在4.0之前重要的版本有 2.1版本-基本速率／增强数据率(BR/EDR) 和 3.0 高速蓝牙 版本，这些统称为经典蓝牙。4.0还有4.1和4.2的小版本，其中4.2版本对传输速率做了进一步他提升，提高了2.5倍，苹果从iphone6开始使用4.2，最新的蓝牙标准为蓝牙5.0，其中最大的特点连接范围扩大了4倍，速度又提高了2倍，无连接数据广播能力提高了8倍，增加了蓝牙组网的能力。
2.蓝牙开发必须知道的概念。
2.1.1 central和peripheral：
蓝牙应用开发中，存在两种角色，分别是central和peripheral(pə’rɪfərəl) ,中文就是中心和外设。比如手机去连接智能设备，那手机就是central，智能设备就是peripheral。大多时候都是central去连接peripheral的场景。
2.1.2 广播和连接:
peripheral会发出广播,central扫描到广播后，可以对设备进行连接，发出connect请求，peripheral接收到请求后，同意连接后，central和peripheral就建立了连接。
2.1.3 连接后的操作:
write，read，notify，indecate， response or not …
indecate和notify的区别就在于，indecate是一定会收到数据，notify有可能会丢失数据（不会有central收到数据的回应），write也分为response和noresponse，如果是response，那么write成功回收到peripheral的确认消息，但是会降低写入的速率。
2.1.4 协议:
每个具体的智能设备，都约定了一组数据格式，这个就是数据协议，例如手环中获取到数据0X001023，其中第2位到第5位表示步数，那么就2310就是步数的16进制的数据，转换成10进制就是8976步，需要注意的是，设备端都是小端模式，所以取4位时候，高字节在前低字节在后。
3. iOS蓝牙应用的一般开发流程。
4. 蓝牙的数据交互。
write，read，notify，indecate， response or not … 都是容易理解的，indecate和notify对应的是长连接，建立indecate后，peripheral可以随时往central发送数据。
indecate和notify的区别就在于，indecate是一定会收到数据，notify有可能会丢失数据（不会有central收到数据的回应），write也分为response和noresponse，如果是response，那么write成功回收到peripheral的确认消息，但是会降低写入的速率。
对于一个charateristic，他的读写订阅的权限是peripheral决定的，熟悉可以被同时设置，一般会根据外设的功能来决定。
5.蓝牙ota DFU。
蓝牙ota,DFU（Device Firmware Update）指的是蓝牙设备的固件升级，其实是一整套流程，不同的蓝牙芯片，ota的流程有不同之处，我这里用ti的芯片举例。步骤为：切系统(bootloader mode)，重启，传输数据，验证数据，切系统，重启，完成。
其中数据传输也会分成很多节去发送，没法送一段数据，做一次数据校验。
6.ota存在的问题。
每个智能设备的速率，功耗，存储都会有很多限制，导致很多设备会自己去实现ota的功能，自定义流程和数据传输方式，导致许多设备都是有自己私有的ota模式和协议，所以在做开发的时候，要仔细阅读设备协议中对ota的描述。
7.如何做自动重连。
只需要在设备断开连接的委托方法中，重新调用gatt.connet或者是centralManager.connet方法就可以了，无论当时设备是否有点，是否在周围，当设备再次开会或者连接到可连接范围内，都会自动被连上。
8.连接失败处理。
分两个平台来说，iOS端也有连接失败的委托，但是好像几乎不会发生这种情况，而对于同款设备，android常常会出现连接失败的情况，status != BluetoothGatt.GATT_SUCCESS，android端开发请不要把连接失败和断开连接放在一块处理，因为断开连接可以直接尝试重新连接，而连接失败后尝试重新连接，需要加一些延时，并且需要gatt.close，清空一下状态，否则会把gatt阻塞导致手机不重启蓝牙就再也无法连接任何设备的情况 。
9.后台运行。
iOS后来运行，需要设备中info.Plist权限，key:Required background modes ,value: bluetooth-central(手机作为central) , bluetooth-peripheral。
10.同时连接多个设备。
使用同一个CBCentralManager，通过进入委托的peripheral的identifier区分不同的设备，进行不同的操作和处理。
11.扫描广播包。
所有外设，只有在发出广播包的情况下，才能被central发现，绝大多数情况下，外设被连接后就不会发出广播（也有例外），很多人遇到无法找到设备的问题，大多属于这种情况。
12.提高蓝牙连接速度。
无论是iOS，还是android，都可以通过已绑定的设备，在不开启扫描的情况下进行快速连接，iOS需要的参数是peripheral的identifier，android需要mac地址。但android和iOS还是有一些区别的，比如iOS不能拿到已绑定的设备list，但是可以通过UUID去拿到peripheral的实例。而android可以拿到已绑定的设备list。android绑定过程需要手动调用createBond的方法，而iOS在连接成功一次后会自动绑定。 android在处理createBond时，常常会应为不同手机平台，不同设备，会产生兼容性的问题，这点需要注意。
13.定向扫描。
在扫描时候可以传入serviceUUID，这样可以扫描到特定条件的设备，提高扫描的速度，排除干扰。
14.如何获取mac地址。
而iOS出于苹果的安全策略问题，无法直接获得mac地址，只能得到一个mac地址换算出来的identifier。
重庆分公司
重庆分公司
