最近的琐事
最近在处理Swift 版本迁移所引发的一些问题，引起了我的注意！
在xCode 8.3.2中，已经不能再次编译Swift2.3了，所以所有的swift2.3 项目都要迁移到3.1。真心碎......
在之前我已经用swift3.0写过另一个关于项目，但是改动起来还是賊烦，慢慢改吧。
无可否认，swift的开发速度的确会比传统的Objective-C快许多，毕竟简化了内容，优化了性能。
此次，我还需要使用Objective-C来重写一个之前用swift写的项目，所以几天下来，项目没写完，反而写下了这篇牢骚文章。
在一个简单的赋值修改的问题上，在Objective-C上我使用了下面的方法组织了一波数据：
NSDictionary *dict1 = @{@"title":@"123456",@"image":@"aux_task"};
[_collectionArray addObject:dict1];
然后在我需要在后续的添加、或修改的时候：
_collectionArray[0][@"image"] = @"light_task_selected";
就会出现下面的情况
-[__NSCFNumber setObject:forKeyedSubscript:]:
unrecognized selector sent to instance 0xb000000000000002
2017-04-24 16:31:30.589128+0800 BleMate2[1603:771672]
*** Terminating app due to uncaught exception 'NSInvalidArgumentException',
reason: '-[__NSCFNumber setObject:forKeyedSubscript:]: unrecognized selector sent to instance 0xb000000000000002'
????
WTF?!
原因在于Objective-C是引用类型语法，在往Array里面input对象dict的时候，其实是它的整个对象的属性也放进去了，也就是说，如果是不允许修改的属性放进去了，还是一样不能修改！
于是可以通过这样的方式进行写入即可在后来继续修改：
NSMutableDictionary *dict = [NSMutableDictionary dictionary];
[dict setValue:@"123456" forKey:@"title"];
[dict setValue:@"bt_task" forKey:@"image"];
[_collectionArray addObject:dict];
_collectionArray[0][@"image"] = @"light_task_selected";
而swift对于这些就变得简单了，它采用了复制结构体的方式，也就是说当你丢进去的是这样的内容：
//先定一个结构体
struct AboutItemInfo {
var titleName:String
var image:UIImage
}
//然后定义一个值，并赋值
let aboutArray:[AboutItemInfo]! = []
let item = AboutItemInfo.init(titleName:"nihao",image:#imageLiteral(resourceName: "heart_rate"))aboutArray.append(item)
//随后如果想对其内容进行修改，只需要直接读出来修改即可
aboutArray[0].titleName = "nihuai"
为什么会可以这样呢？！
因为是复制的方式进行的运行方式，所以aboutArray里面的对象，其实已经在传进去的过程中就被复制到AboutArray里面，当再次读取修改的时候，是对AboutArray里面的值进行修改。
我想有可能是因为Objective-C使用了别的方法去代替类似于上面的那种做法。于是我去翻了翻远古时代的Objective-C 结构体
typedef struct Book{
NSString *name;
NSString *Author;
int book_id;
} book;
但是把字敲到xCode上就发现它提示了一个错误：ARC forbids Objective-C objects in Struct
突然意识到在自动释放之后，这些东西会变得不靠谱，因为如果不随之释放就会造成内存溢出，所以针对以上的问题，可以把它变成手动释放后尝试了一下。终于成功了！（但感觉好像倒退了十几年.....）
虽然官方也给出了关于ARC之后的这种类型结构体最好交给类来解决，但是相对于Swift的轻便，也显得过于臃肿了。然后细心的想了下，为什么Swift在各大测评平台上总是比Objective-C跑得快？！
管中规豹
就当前所遇到的问题，完全可以归类为结构体和类之间的战争！
在swift中，包括许多的基本类型，诸如String，Array还有Dictionary等类型都是以结构体的形式实现，这意味着被赋值给新的常量或变量，或者在这些基本类型被传入到函数或方法中的时候，他们的值是会被copy的。
而在Objective-C中，NSString，NSArray、NSDictionary类型都是作为类的形式实现，而并非结构体，他们在被赋值的时候、被传入函数或方法的时候，它们不会被拷贝，而是传递了现有实例的引用。
具体可以参考下面这个例子：
//在Objective-C中，使用下面的方式进行国际多语言化
_headTitleLab.text = NSLocalizedString(@"BLEConnect_Ble", @"");
//当应用内发生了语言设置的变更
[NSBundle setLanguage:"en"];
//那么_headTitleLab就会显示成别的语言的了，不需要重新赋值
那么如果在swift中做出同样的操作则需要重新对其进行取值赋值的操作，不然就会不刷新语言。
////在Swift中，使用下面的方式进行国际多语言化
headTitleLab.text = NSLocalizedString("BLEConnect_Ble", comment: "")
//当应用内发生了语言设置的变更
Bundle.setLanguage("en")
//如果想应用内的语言随之变更，就需要重新进行赋值才会成功
headTitleLab.text = NSLocalizedString("BLEConnect_Ble", comment: "")
另外值得一提的是：
以上是对字符串、数组、字典的“拷贝”行为的描述。在你的代码中，拷贝行为看起来似乎总会发生。然而，Swift 在幕后只在绝对必要时才执行实际的拷贝。Swift 管理所有的值拷贝以确保性能最优化，所以你没必要去回避赋值来保证性能最优化。
而Objective-C的做法是，先实例化了类，然后才做数据存储处理，所以在这里性能也是大打折扣的地方。
这里让我感觉swift其实是一个结构体语言，而Objective-C则是引用类的语言，现在想来结构体的简单赋值方式的确有利于运行速度。
另外翻看他们的编译器CLange的编译过程时，发现因为 swift 在编译时就完成了方法绑定直接通过地址调用属于强类型语言，方法调用不再是像Objective-C那样的消息发送，这样编译就可以获得更多的信息用在后面的后端优化上了，其实这样也加快的Swift的运行速度。
这里很想深入的探讨swift的闭包较Objective-C的Block如何，进行深入的研究，无奈对swift的闭包理解还是比较欠缺，还得深入的了解一番才可以有内容所写。
写在最后
今天也看到王先生的文章，应当理解为科技和开发手段是不断进步和优化的，但是解决问题，还是要从实际出发。毕竟，我们的存在只是为了解决问题。关于Objective-C和Swift也一样，其实Objective-C稳定的当了那么多年的老大哥，还是有一定的可取之处的。
另外，还是关于swift和Objective-C到底应该用什么语言进行开发，这种事情还真不好说了！如果有的选，我还是选Swift吧！当然了要在开发的流程成熟的团队才可以让Swift飞起来。
越来越发现xCode在开发的时候所提示的警告都是重要的，因为你不知道什么时候就突然不被兼容了！
