为什么要用Swift而不是Ojbective-C
背景
- 2014年Apple官方推出Swift语言到现在已经6年了，而今Swift的占有率已经超过Objetive-C。
- 而我们公司还在用上个世纪的编程语言，那新语言有哪些好处呢，我们是不是应该更换开发语言呢？
- 我想，只有用过之后，才知道区别；于是我花了大概6天的时间去学习Swift和SwiftUI。
学习链接
区别
- 增加可选类型（使用时必须强制解包，在语法层面上控制数据必须有值，否则直接编译不通过，使用起来更加安全可靠。）。
- 更少的文件，不再需要创建一个.h和一个.m文件（更简洁可读性更强）。
- 字面量，可以根据值的类型推算出变量的额类型。
- 强大的结构体（除继承外几乎和类无差别、根据默认成员合成构造器）。
- 简洁的而又强加的属性（可观察、设置、获取属性）。
- 灵活而有方便的闭包（但表达式隐式返回、自动推断参数和返回值、尾随闭包、快速访问参数
1 $2..）。
- 更加健全并且直观的访问控制（public、internal、fileprivate、private）。
- 简便的下标脚本语法（快捷地访问对象、集合或者序列）。
- 属性包装器（@propertyWarppe、@State @EnviromemntObject @bindingObject @Bindin，将常用并且重复的操作封装城属性包装器）
- 不透明返回类型(Some View)
- Swift Style DSL/Function Builder(可以使表达式语句隐含的返回在函数返回值中， 这样可以在嵌套逻辑和返回值表达式的 DSL 中十分具有表现力)
- 值类型和引用类型（当你设计一个数据结构时，优先选择结构体或者枚举，它们都是值类型）
1.值类型在栈上分配，性能要远远大于引用类型，且 Swift Runtime 有 COW 优化。
2.值类型没有引用计数，不会引起奇怪的多线程安全问题。
3.值类型的存储属性是扁平化的，避免在类继承情况下一个子类继承过多的存储属性导致实例在内存中过大，如 SwiftU
- 声明式编程、函数式编程(View Modifier)
在命令式布局系统中，你要做以下事情，
初始化一个 ImageView 实例
设置它的位置信息
设置它的缩放级别
把它添加到当前的视图树中
如果有事件，设置下事件的代理或者回掉
开发者要做的事情繁多且易错，开发效率极为原始低下，但在声明式时代你只需要描述一下信息。
屏幕上有个图片，在什么位置，是什么缩放比例即可， 至于怎么布局，一切交给框架，Coder do less, Framework do more。
- 数据流 - Data Flow
@State @Binding
BinableObject @ObjectBinding
@Evironment @EnvironmentObject
- SwiftUI 的布局算法
1、父视图为子视图提供预估尺寸
2、子视图计算自己的实际尺寸
3、父视图根据子视图的尺寸将子视图放在自身的坐标系中
比较重要的是第二步，对于一个视图描述，通常有三种设置尺寸的方式。
无需计算，根据内容推断，如 Image 是和图片等大，Text 是计算出来的可视范围，类似 NSString 根据字体计算宽高。
Frame 强制指定宽高
设置缩放比例 如 Image 设置 aspectRatio。
- 包括且远不止如此的更深层的区别，日后才能发。
絮絮叨叨
通过这六天的学习，我觉得Swift作为21二十一世纪被推出的语言，相比Objective-C更加严谨、更加智能化，尤其是SwiftUI的设计，函数式、声明式编程、MVVM的设计模式使得原本繁琐的UI设计变得更有表现力、更直观、更简单易用；强大的属性修饰器让很多重复且枯燥的工作得到简化，我了解Swift的时间还很少，在日后的使用中我一定能够体会到Swift更多的优点。
