引子:
手中维护了一个历史项目,该项目因为历史原因,从设计到实现,并不是很好.加之该项目为支线项目,在得到了老大的批准后,它不幸的被我作为了试验田...
为此,我重新开启了一个工程,引入了AOP,MVVM,Swift等.仅仅是初体验,并没有特别高深的应用以及所谓的"最佳实践".
混编:
项目仍然以OC为主,用来编写大量的UI代码,原因为:一则对Swift掌握程度不如OC,二则UI代码使得Swift无法发挥其优势,三则担心Swift版本变动.
我选择Swift作为逻辑的处理.所以首先需要做混编的支持.
在工程中新建一个Swift文件,工程会自动询问你(仅询问一次)是否建立一个bridge文件,选择是,则会出现一个名为XXX(工程名)-Bridging-Header.h的文件
这个文件主要用于OC->Swift.即在该h文件中import的类,Swift均可以自由调用.在Build Settings中输入Bridging进行搜索,可以看到有一个属性叫做
Objective-C Bridging Header,在这里可以设置XXX-Bridging-Header.h文件的路径.
通过设置,我们可以在Swift里面调用OC的相关代码,但是我们的目标并没有实现.我们希望使用Swift进行运算处理,将最终的结果返回给OC(UI)加以显示.
那么我们还需要进行Swift->OC的桥接.
编译带有Swift文件的项目后,项目会生成一个XXX(项目名)-swift.h的文件,我们只需要import这个文件,即可调用所有Swift的代码.理所当然,我将该文件
import到了PrefixHeader.h中.BTW,XCode6新项目已经不会初始化一个PrefixHeader文件了,需要我们手工创立.
到现在为止,我们既可以在Swift中调用OC,也可以在OC中调用Swift了.
起飞:
准备工作做好了以后,就开始享受Swift带来的快感了.
- 它没有mutable,只有var和let
- 它有强大的?和!,不过上手挺有难度
- 它有泛型,也同样类似OC一般,拥有Any和AnyObject
- 它有元组,终于可以像红宝石一样写出类似于(a,b) = (b,a)的代码了.
- 它有强大的struct,强大的switch
- 它有简洁的closure,c like的block见鬼去吧...
- 他还有更加强大的func以及奇奇怪怪的小东西,什么柯里化拉等等.
我用它实现大部分的M和VM,小部分的V,其乐无穷.例如:
正则(自定义/重载操作符):
infix operator =~{
}
func =~(lhs: String,rhs: String) -> Bool{
let regex: NSRegularExpression = NSRegularExpression(pattern: rhs, options: NSRegularExpressionOptions.CaseInsensitive, error: nil)!
let range: NSRange = regex.rangeOfFirstMatchInString(lhs, options: NSMatchingOptions.ReportProgress, range: NSMakeRange(0, count(lhs)))
return range.length > 0
}
更强大的enum
enum SWButtonImageLoadingStatus{
case Success(UIImage)
case Failure(NSError?)
}
class SWImageSelectorButton: UIButton {
var url: String = ""
func loadButtonImage(url: String,handler : (status: SWButtonImageLoadingStatus) -> ()){
SWTemplateCenter.sharedInstance().runAction("getImage", params: params, success: {
(data) -> Void in
if let image = UIImage(data: data as! NSData){
let status = SWButtonImageLoadingStatus.Success(image)
handler(status: status)
}
else{
let status = SWButtonImageLoadingStatus.Failure(nil)
handler(status: status)
}
}) {
(error) -> Void in
let status = SWButtonImageLoadingStatus.Failure(error)
handler(status: status)
}
}
}
坑:
天下哪有不停的爽点.坑当然有.
混编机制导致了他们的通信依赖2个文件:XXX-swift.h和XXX-Bridging-Header.h.随着交互的越深,XXX-Bridging-Header.h文件中所引入的头文件
会爆炸,难以管理,很是丑陋.有时候为了实现一个小功能,要不然引入OC的类作为全局引用,要不然自行重写一遍.那么此时,我的选择是...还是使用OC吧...
Swift版本变动是一个深坑.Swift还太年轻,版本变动会非常剧烈.而每一次版本变动,带来的直接结果就是大量的编译错误.需要重新修改代码.尽管Apple会
提供迁移工具,但是,这并没有什么用.人工检查和修改是一定套不了的.Swift2.0发布在即,变的更成熟,更科学,更美好.而我,也到时候会迎来一次全面的检查
和修复,痛并快乐着.
在混编的过程中,有部分Swift的威力无法发挥.比如方法中无法定义参数的var,inout等,因为这样的话无法翻译成OC.这当然不算Swift的坑,不过也蛮遗憾的.
iOS8以下并未含有Swift库,所以使用Swift后会把Swift相关库也打成包并入App中.由此带来的问题是:即使你只写了一行Swift代码,App也会增大8m左右,
不过新版本的iOS已经解决.
在实际应用中,我曾经出现过偶尔的Swift调用UIKit的错误:同样的代码,得出的结果就是不一样.换成OC重写一遍就OK了(在做转场动画,实现UIViewControllerAnimatedTransitioning协议的时候).我虽然认为这应该是我对Swift了解不足的原因,但是Swift还是给我造成了一定的困惑.
结语:
Swift具备先进的语法,现代化语言的特征,苹果爸爸的运营,相信有着非常光明的前途.加之2.0即将到来并开源,一反苹果封闭的常态,野心也是极大的.目前使用Swift开发项目,虽然有一定的风险,有版本变动带来的额外工作量,但是跟随一门语言的演化,也算是值了.