网站h1标签用在哪里,公司网站平台的作用,武侯区旅游网站建设,全国高速公路施工建设有没有网站作者|刘镇夫#xff08;小鱼#xff09; 出品|阿里巴巴新零售淘系技术部 本文是知名 ios 开发者 NSHipster中文译者-刘镇夫#xff08;小鱼#xff09;#xff0c;在云栖大会上为大家带来的分享#xff0c;本文主要介绍几点#xff0c;第一、Swift 5 代表什么#xff1…
作者|刘镇夫小鱼 出品|阿里巴巴新零售淘系技术部 本文是知名 ios 开发者 NSHipster中文译者-刘镇夫小鱼在云栖大会上为大家带来的分享本文主要介绍几点第一、Swift 5 代表什么第二、Swift 5 在社区中应用的情况和我们真实开发环境中是什么样的过程和现状第三、在实际开发中我们应该怎样面对 Swift 5 的决定性因素第四、基于上面三个话题的讨论结果来看在新时代下有什么新的路线和发展方向值得我们去探索。 01、Swift 5 带来了什么
▐ 稳定的 ABI Swift 5 带来了什么最重要的一点是稳定的 ABI 5.1 版本后我们可以用不同Swift 支持的第三方框架最终编译成同一个 APP 这是成熟语言的标志只有这样才能让不同的框架和代码为你所用大家使用时也不会有那么多的顾虑。
▐ 共享 Runtime 库 除 ABI 外 Swift 5 也带来了共享 Runtime 库上图中 66.6MB 和 30.1 MB 都是以前的现状Swift 出来后再配合新的编译工具现在这些库都能够共享会显著减少我们的包体大小因为共享的 Runtime 让使用时间减少 5% 左右用户在下载和使用时代码构建量会减少 10% 左右开启“optimize for size”构建量会减少 15% 这是大家采用三方 Swift 5 的一个关键性因素。
▐ Objective-C 混编调用效率更高 现在大部分都是自建的当不在纯 Swift 环境下开发时这里面写出来的一些数据是开发过程中不可避免的一个问题 Swift 5 更新后在第一程度调动方面有 1.6 倍的提高在 NSString 方面有 15 倍的提高。 ▐ Swift Package Manager 随着 Swift 5 的发布我们还能看见一些新工具产生这在 IDE 和 Xcode 里可以直接看到哪些地址有高依赖引用了哪些库相对以前没有官方的支持好处非常明显以前使用时第一次缩影下要下载大量的内容这是非常痛苦的一点。Swift Package Manager 虽然没有这样的问题但他的步骤也比较复杂不是简单一个包的名字安装上去就可以苹果新出的 Swift 5 manger 相对于官方的指导意见同时支持后台直接登录一些账号包括企业自己的项目管理地址这个相当于node 的环境有 npm 的环境是官方推荐的包管理工具整个过程变的非常简单他是可以和第三方工具并用的切上来之后也不用担心没有支持的问题。
▐ Swift UI SwiftUI 大家应该比较了解简单来说就是用上图只有五行左右的核心代码去完成右侧页面的简单操作过程估计大家都已经玩过下面也会展开讲一下这个功能上可以探索的一些新路线。 02、Swift 在实际研发中的使用情况
相对来说现在国内实际研发中有真正用到 Swift 的同学较少但是 Swift 本身的发展已经没有几年前滞后的情况现在的发展是飞速的。
▐ Swift 发展进程 Swift 在 2010 年开始立项第一个版本是 2014 年 9 月的 1.0 版本2.0 版本在2015 年 4 月 这里面变成了基本的调动速度后面是每一年发布大的更新所有基本的类型都是 Swift 自己不用调动的现在是一个重要的时间点可以看到 Swift 的前景广阔不用再依赖别的语言实现2019 年 6 月发布的 Swift 5 让他成为现代化的成熟语言为我们所用。
▐ 社区表现对比
Swift Kanban我收集的数据有 11159 个有 6474 个标记已经被处理剩下的不清楚对话是怎么产生通过这个数据可以看到官方一直在非常努力的推进开发以及与开发者交流可以看到每天官方的情况大概 3 到 4 个小时就会有官方来回复开发者告诉大家最新的 bug 。 对比来说一个开发的官方社区维护不太好的语言做不到这样的响应速度官方的态度是非常快速的修复这些问题大家也不用担心在开发过程遇到什么问题上图是我在网上收集到的一些数据Y轴是 Pull Request 数量蓝色的线是 Objective-C 橙色的线是 Swift 。
从 2016 年开始Swift 的数据已经超过了 Y 轴现在有一种取而代之的快速发展趋势这个说明社区中更多的开发者习惯把精力放在 Swift 上而不是放在 Objective-C 上这对大家的 APP 也是一个相关的提醒。如果你坚持只用 Objective-C 那么你可能会面临一个风险——你所依赖的第三方开发库已经不愿意去维护他们。 上图是两个在社区中最著名的第三方库一个是 AFN 一个是 Swift 上做的左边是 Objective-C 上做的这都是一个开发团队同一套开发团队库就目前状况来说他们在 stars 上面的数量是差不多的关注度和使用量也是差不多的情况但是 opening issues 上面的 afn 已经积累了 322 个未处理ALAM 只有 32 个这里面有各种各样的问题官方不管 issues 的同时 Alamofire 只有 9 个没有处理而 AFN 有 83 个没处理最后一次 Swift 版本其实前一面就有新的肯定的出现而 Objective-C 要往前推 6 个月才有一个 commit 最后一个版本需要往前推一年半才可以找到。
举个实际的例子比如大家都是做 HTTP 请求的3.0 协议已经发出如果未来的开发者更愿意把精力放在 Swift 上面现在 SSL Certificate Verify 的验证是可以把证书链从上至下全部验证一遍这在 Alamofire 里已经支持的非常好大家在此领域目前是缺失的所以目前而言的现状是有一些不能带来了这是老框架不能做到的个人建议如果大家想转到 Swift 可以尽快实行以避免在未来时间点你所依赖的第三方非常重要的开发框架有严重问题时可能会跟不上进度。
▐ Objective-C 的发展史 为了打消大家对 Swift 应用前景的疑虑Objective-C 1981 年开始创建至今已有 20、30 年的时间1988 年乔布斯创建了 iOS 并买下授权这个语言用了 20 多年的时间才成为苹果平台的一个专属主流的语言Swift 只用了 5 年的时间就达到现在的结果。2007 年 Objective-C 2.0 操作的版本也就是现在手动管理内存的版本 2007 年发布现在大家都在使用这个版本至今相当于过了30 多年的时间才处理了他在系统上的地位。 Objective-C 的发展历史也不是没有问题他出来时比 Swift 的问题更多在 2005 年才有垃圾回收机制并且是没有命名空间的大家都知道系统的数据是 NS 开头如果写一个很大的数据就没有办法编译了没有运算副重在他出来时作为 C 语言的扩展机制所以刚出来时面临的问题要比 Swift 现在面临的问题要多的多但苹果还是吸收了他作为主流的开发语言这里面不但有技术性的一些挑战和考量也有在整个生态中开发环境的开发者对于语言喜好的一个考量。当时有五大平台Java 在苹果生态里可以继续开发但是最后苹果还是选择了 Objective-C 一个重要的原因是在苹果生态内部经过 20 多年的内部工程师的使用更喜欢这个语言所带来的感觉并不是 Java 不好才没有选择而是社区的人的喜好大家在选择的时候要考虑一下团队的情况和大家对新语言的兴趣和努力方向在哪里而不是要不要接受新的语言使用新的框架以确定在未来的情况下不会作出错误的决定。
03、项目引入 Swift 的考量因素
回归到实际问题项目开发中到底要不要引入 Swift 的考量因素我主要将其分为五大模块目标、成本、过程、结果和反馈。
首先看目标是什么为什么要考虑在项目中是否引入 Swift 的新语言希望大家不是单纯为了使用新语言而用是要节省开发效率、还是提升运行效率、或者是要减少包的大小还是让整个团队的技术跟上新的潮流去做一个提升都是有一个目标这也也会产生一个成本这里面的考量是为了达成新的目标这个成本是否值得付出以及是否会造成一些 APP 不稳定的情况这里会有一些负面的影响而你能否在实际开发和实际交付的过程去承担
如何把新的语言、新的框架应用到业务的 APP 里面去分模块开发还是分页面开发都是要考虑的过程这对于APP开发的风险还是比较大的业界也有一些比较失败的案例他们在使用 Swift 后又全部换回来了这都是大家不想看到的比如在引入 Swift 作为其中几个模块的开发是否真正产生了你想要的结果是不是真的节省时间了
如果你的 APP 过于复杂里面有互相嵌套的地方那可能不太适合你们团队的现状所以不要觉得引入之后在交付上面就是适合的反馈过程也很重要因为 APP 开发是持续的过程不是交付这一版就结束了仍然要考虑下一个迭代中是否要用新语言做开发或已经开发的模块适不适用新语言去做扩展。 举个例子我实际参与的项目第一是某区块链客户端在密码选用时选了 Swift 做实践其他的基础层面用了 Objective-C原因非常简单这两部分在应用中隔离的比较好和谐的比较开互相没有太多搀杂在一起的地方并且有一个好处Swift 编译出来的包在逆向工厂和反编译中目前是属于比较困难的状态所以他非常适合密码和区块链顶层的应用能够保证 APP 安全的运行在客户的手机上。 日程管理类的 APP 需要记录你要做的事所涉及到的文本类会较多为了避免 Swift 处理方面出现问题所以保留了 Objective-C 的实践各种细碎的页面较多团队内部有人想要尝试新语言时会建议他在新的页面上尝试这个语言核心部分依旧保留 Objective-C并且在对应的 ReactiveCocoa 上用 Swift 对应的 2.0 版本。
总的来说如果企业有新的项目区建议用新的语言在新项目上有技术的实践在新项目中把功能训练的比较完善去解决一些问题个人项目还是完全使用 Swift 去开发这样会提高个人能力当你真正去大项目中部署这个问题时在大部分问题已经预见过后不至于束手无策。
04、新的机遇与挑战 随着 Swift 5 语言慢慢发生我们可以看到一些新的变化第一是 Project Catalyst 一键生成酷炫的功能第二是 SwiftUI第三是 Combine 这是苹果官方发出的消息队列机制第四随着 Swift 4.0 版本发出的 Swift for Tensorflow 在 AI 方面都搞一些涉猎这是社区对这个方面的侧重目的是用这些新的功能去吸引最顶尖的开发者去加入。 Dropbox结合 Swift 是做文件同步的他不像 Telegram 在重写 Swift 的客户端时所说的原因那么简单所谓都重写原因很简单重写后用电量明显减少以前一些隐藏的 bug 解决之后都不见了完全没有考虑性能他有一个 C 的代码在各种平台都可以用同一套客户端去做这件事现在放弃了 C 去做原商代码的开发目的很简单很多移动工程师对学习 C 毫无兴趣以及他们在移动端互相配合的过程中产生了极大的问题这样就导致了优秀的开发者想用 Swift 开发时已经没有太多的用武之地因为核心功能都不是这个语言写的最后导致很多优秀的工程离开了这个团队。
拥抱新技术也是挑战在应用 Swift 的开发之后一定会遇到一些原来没有的问题高效率的问题可能也会遇到我觉得优秀的开发者就是这样当你拥抱新技术的时候、新的挑战所带来的问题你也能够承担也能够把他解决这才是正确的态度。
有的同学可能说 Objective-C 并不是阻止我们使用 Swift 的最重要的原因我们的应用全是动态内容分发或者一些常见的框架即使 Swift 再好可能也没办法去处理那些动态页面的交付这个问题不在于 JavaScript 和 Swift 他们的执行效率没有原生的那么快好处是这些动态内容的交付有了一个可交付的结果如果你的 APP 里要求动态内容、动态页面、动态布局其实是很难实现这么高的切合度的。 基于 Swift 目前的发展现状Swift UI 之所以能够这么简洁、高效的开发是基于 Function Builde 的开发现在看到的 Swift 其实是可以做简化的包括一些名字都是可以简化掉的一些单行的 return 都可以不用写了我觉得未来有一个方向就是你可以把 Swift UI 写成右面那种形式我们可以和 Function Builder 做对比包括他的逻辑可以让你去做一些相关的 DSL 的书写。 左边的 DSL 可以通过社区目前正在研发的 Builder 他的语法和表现形式变的更加简洁和方便如果所有的 UI 层面和逻辑层面的代码都能够写的像左边这样的话差异就不是特别大在所有平台动态里内容分发也不会有太大的问题上图是我在开源社区翻的到的一个可能的实践这个人基于 Function Builder 做了 HTML 由左边这种形式直接转化成页面当你收到服务器语言时直接将其绘制出来附着上去对我们来说还是有进一步的研发和众多可能性对比目前这些动态环境来说动态内容造成的环境像左边几个大多数是用 JS 做基础语言去做编写的运行时依赖 JS 的用户用这个框架去做一次解释和翻译才能完成最后的结果。 ▐ 跨平台解决方案 有人说我们的这个是跨平台的如果大家仔细观察右面的形式会发现他非常像 Swift 5 的 DSL所以安装新的开发框架有 Jetpack Compose 的一个东西像 Swift UI DSL 一样可以完成同样语法的简便形式这样大家要达成统一时在双平台都可以用原生语言去实现而不再依赖 DSL 的翻译整个研发和运行效率都会大大的提升。 未来新的挑战和机遇是我们都用自己平台的语言不依赖 JS 去解析非常建议 DSL 动态内容由服务端分发十分简洁。APP 前端的一些界面在使用 Swift 生成前的 Swift 前端最方便的方式是什么就是后端也是用Swift 写的。Swift 用 Swift ServerSide 生成的前端也是 Swift 这个语言生成的 DSL 可以给移动开发者用也可以给安卓开发者用作为一个非常酷的 APP例如换脸可能会依赖 tensorflowAI相关的部分也是用 Swift 5 写的所以我觉得前景是大家只会去学Swift 的语言把这种语言用好你们就可以成为前平台的开发者上市。
05、总结
稳定的 ABI 是我们最基本的运营保护运行状态相对稳定、成熟对我们来说非常重要接下来是 Runtime 和 Objective-C 混编调用效率更高可以保证大家在使用的时候不会遇到太多的问题后面是社区的支持和开发者对 Swift 的喜爱还有以 DSL 为基础的动态方向上的预想这件事情在官方社区里已经提到最高日程大家可以去社区关注一下刚才的设想图也并不是完全幻想出来的而是会在短时间内得以实现。
原文链接 本文为云栖社区原创内容未经允许不得转载。
