Swift之路（1）为什么应该现在就选择用Swift开发代码而不是Objec
|
? 最近和很多开发聊天，发现不少Objective C（一般简称OC）开发还没有尝试Swift，理由有很多，最重要的一个理由是学习成本。 ? “已经很熟悉Objective C开发了，经验已经很丰富，没有必要学习一门新语言吧？再说了，Objective C效率也不低，语言只是工具而已，没有必要了”。 ? 抱着这个想法的人，真的是不少。 ? 在Swift刚出来的时候，我也抱着类似的想法，但是自从开始尝试、熟悉，并且亲自应用到项目后，我成了Swift的忠实拥护者，历史总是这样，当你接触到更进步的事物时，你就再也不会想回到过去了。就好像从传统手机到智能手机，从马车到汽车一样。 ? 以下我想试着阐述一下，为什么OC程序员值得花时间去学习并实践swift，而不是死守着过去的编写习惯。 ? 1. ? 更少的代码量。在Swift里，当你创建一个类时，你不再需要像OC一样创建.h和.m文件，你只要创建一个.swift文件即可，这意味着同样的工程里，按正常编写，用swift所需要的文件个数更少，工程看起来自然更加简洁。有人可能会问，在同一个文件里不就意味着声明和实现没有分离吗，是的，在自己编写的代码里确实如此。如果你想要隐藏实现，你可以选择把代码打包成framework，这并不是严重的问题。? 在语法上，Swift已经像脚本语言一样简洁。 ? 比如，配置一个Label的颜色，在OC里的代码是这么写的： UILabel* label = [[UILabel alloc] init]; label.textColor = [UIColor redColor]; ? 而在Swift里，是这么写的： let label = UILabel() label.textColor = .red ? 类似的这类“语法糖”数不胜数，极大的节省了开发者的击键量。 ? 2. 更强的可读性。Swift的语言和脚本语言相当接近，它使用了 对象.函数() 的调用方式，抛弃了OC的 [对象 方法] 的调用方法。这对于熟悉C、java等语言的学习者显然更加自然（已经不止一个人跟我说过OC语法“怪异”了）。另外，由于swift在语法机制上的改进，即使同样的SDK，swift语言的表达会更加简洁有效，并会裁剪掉大量不需要的单词，下面举一个”将文件里的字符串赋值给str“的代码为例。 ? 以下是OC代码： NSString* str = [NSString stringWithContentsOfFile: @"/data/content" encoding: NSUTF8StringEncoding error: nil]; ? 而swift代码调用同样的SDK，代码是这样的 let str = try? String(contentsOfFile: "/data/content",encoding: .utf8) ? 是不是代码更加简练，可读性更强？ ? 3. 代码更健壮。Swift的异常捕捉机制比OC更加成熟健全。另外，在OC中让程序员头痛的空引用问题（尽管比起java已经好了很多），在swift中得到了更好的处理。我下面用一段代码来指出Swift处理空引用问题的优越性。 var a: String? = nil // 定义一个String?类型的变量a a?.append("hello,") // 因为a此时运行时值为空，所以本段代码执行无效 a = "hello," // a被重新赋值为hello a?.append("world") // 因为a此时运行时值不为空，所以本段代码执行 var array: [String] = [] // 定义一个元素是字符串的数组 if let safeA = a { // 由于a可能为空，所以需要判断是否为空，如果非空，把非空值赋值给String类型的saveA array.append(safeA) } var b: String = "hello," // 定义一个值为hello的String类型变量b b.append("world") array.append(b) // 由于b是String类型，语法保证了该值绝对不为空，所以可以安全的添加到数组中 ? 在以上代码中，由于Swift的语言机制允许我们申明一个类型是否”可能为空“，使我们可以灵活的处理空引用问题，而在OC中，因为任何对象都可能为空，我们将不得不编写大量代码做安全监测，或者编写大量nullable申明来规避该问题，相较之下，swift代码更有效，也更健壮。 ? 4. 无缝安全的桥接OC。如果你担心用swift你必须抛弃以前写的OC代码，包括辛辛苦苦积累的代码库，那大可不必担心。因为swift可以非常自由安全的调用OC代码，同样的，OC代码也可以调用swift提供的接口。也就是说，如果必要的话，我们可以让两份代码”混编“。这意味着我们可以现在就在我们的OC工程里加入swift代码，比如当我们要添加新的类代码的时候，我们可以选择提供一个swift类，这也意味着，当我们建立一个swift工程时，我们只要做点简单的工作，就可以把过去积累的OC代码库植入进去。具体方法参见我之前写的文章：Swift 4 和 Objective-C 在同一个工程里的混搭编程的方法 ? 那么，是不是用Swift编写的工程就一定比OC的好呢？也不全是这样，用Swift代码编写的工程，也存在着一些值得关注的问题。第一，对于低版本的iOS操作系统，Swift编译出来的包可能不兼容，也就是说如果你要编写的软件是面向老机型，那么Swift很可能不适合你。第二，用Swift代码编译出的安装包，会比OC的要大好几兆，对于目前大部分苹果市场的app动辄容量上百兆的现状来说，这几兆似乎无足轻重。但是如果你的产品把安装包容量看做是关键因素的话，那么Swift也可能不适合你。 ? 总的来说，Swift是一门非常优秀，并且到目前始终处于发展期的语言，过了4.0后，开始趋于成熟，适合投入使用。加上苹果的大力支持，我们没有理由不从纯OC阵营转移到以Swift为主，OC为辅的开发策略里来。个人建议每个OC程序员都应该从现在开始学习Swift，每天进步一点点，很快就可以掌握并且从中获得益处。 （编辑：李大同） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |