隨著移動(dòng)互聯(lián)網(wǎng)的發(fā)展富岳，移動(dòng)端iOS開發(fā)的技術(shù)選擇也劃分了好幾個(gè)方向呛哟，有用 React-Native進(jìn)行開發(fā)的苞俘，有用 Objective-C開發(fā)的，也有用 Swift開發(fā)的计维，或者 混合 著來袜香。
不同的語言存在都有其可取的優(yōu)秀之處，也有不足的地方鲫惶。也應(yīng)了那句俗話 : 金無足赤蜈首，人無完人。
我們都知道 2014 年 Swift 的橫空出世,其首要目的就是 劍指 Objective-C欠母。 但是現(xiàn)在看來也沒有完全達(dá)到其問世的目的欢策。但是大家對(duì)于 Swift 的喜愛依然是一路包容,比如從14年以來一年一學(xué)，其情況猶如一年學(xué)習(xí)一門新語言赏淌，但是 Swift 也沒有讓我們失望踩寇，一路高歌猛進(jìn)，今年也迎來了 Swift 4, 從這一路上來看猜敢，有一部分人好多放棄在 Swift 2.X 的路上了姑荷，一部分人沒有體會(huì)到 Swift 3到 Swift 4 的喜悅. 也有一些人始終徘徊在 Swift 的門口; 一只腳在里面盒延，一只腳在外面缩擂。
從始至終堅(jiān)持的人是抱著 “蘋果(Swift)” 虐我千百遍，我待 蘋果(Swift) 如初戀的執(zhí)著添寺，也正所謂: 撥開云霧見天日 守得云開見月明, 從目前來看 Swift 4 給了開發(fā)者很大的 支持與信心胯盯。
兩種語言熟悉的人都知道 Objective-C 與 Swift 底層是完全不同的機(jī)制。
Objective-C
Objective-C 的那一套跑不了 運(yùn)行時(shí), 我相信 KVC 的概念在每個(gè)面試者的腦海中都能 信手拈來。
KVC， NSKeyValueCoding统屈，一個(gè)非正式的 Protocol蚂子，提供一種機(jī)制來間接訪問對(duì)象的屬性。
KVO 就是基于 KVC 實(shí)現(xiàn)的關(guān)鍵技術(shù)之一
以類似字典鍵值對(duì)的方式存儲(chǔ)信息,以及強(qiáng)大的動(dòng)態(tài)派發(fā),與C的結(jié)合
.......
太多太多
Swift
Swif 這門語言是恰恰不同昼浦，其類型成員在編譯的時(shí)候就已經(jīng)決定,完全是一門安全性的語言。
尤其對(duì)協(xié)議的支持。比如對(duì)協(xié)議的實(shí)現(xiàn)有：
| class | struct | enum |
|---|
這里不得不提到 enum 對(duì)協(xié)議的支持：
protocol Source {}
enum Action: Source {
case handler(sender: UIButton)
case touchUp(sender: UIButton)
}
由此對(duì)協(xié)議的支持可見一斑疗杉。
蘋果在15年提出 Swift 的一種面向協(xié)議編程 (Protocol Oriented Programming)
protocol Work {}
extension Work {
func doWork() {
print("do Work")
}
}
class action { }
extension action: Work {}
action().doWork()
// 結(jié)果
：do Work
我們看到這個(gè) action 類,并沒有對(duì)協(xié)議進(jìn)行任何代碼方面的書寫，而通過 extension 可以直接為協(xié)議進(jìn)行擴(kuò)展蚕礼，并給出默認(rèn)實(shí)現(xiàn)烟具。這對(duì)于大量重復(fù)的代碼絕對(duì)是一個(gè)優(yōu)秀的解決方案。
雖然在 Objective-C的時(shí)代就有 對(duì)重復(fù)代碼進(jìn)行封裝通過繼承來實(shí)現(xiàn)也是一種解決方案奠蹬。但是這種做法是有一定的風(fēng)險(xiǎn)的.
比如通過繼承的方式來：
class Action1: base1 {
override func doWork() {
print("do Work")
}
}
class Action2: base1 {
}
Action2().doWork()
// 結(jié)果
：do Work
貌似結(jié)果是一樣的,但是面對(duì)大量的代碼的時(shí)候結(jié)構(gòu)構(gòu)造的好處是顯而易見的朝聋，尤其是協(xié)議的擴(kuò)展：根據(jù)入口提供額外實(shí)現(xiàn),也可以提供默認(rèn)的一個(gè)實(shí)現(xiàn)。往外每個(gè)類都是通過其特定的組合方式來實(shí)現(xiàn)不同的業(yè)務(wù)需求的,如果通過以往的繼承方式構(gòu)建在業(yè)務(wù)繁瑣的時(shí)候是無法很好的對(duì)業(yè)務(wù)進(jìn)行抽象封裝了,這個(gè)時(shí)候 Swift協(xié)議就可以閃亮登場啦
其實(shí)寫過 C++ 的都知道支持多繼承,其帶來的風(fēng)險(xiǎn)也是顯而易見的:
比如：
class base1 {
func doWork() {
print("do Work")
}
}
class Action1: base1 {
override func doWork() {
print("do Work")
}
}
class Action2: base1 {
override func doWork() {
print("do Work")
}
}
Action2().doWork()
class Commad: Action1,Action2 {
}
Commad().doWork()
這種性質(zhì)的繼承是致命的囤躁。當(dāng)然 Swift 與 Objective-C 是不支持多繼承的冀痕，所以上面代碼是無效的荔睹。但是很重要的是 通過協(xié)議，并對(duì)協(xié)議進(jìn)行默認(rèn)實(shí)現(xiàn)也是可以達(dá)到異曲同工的多繼承作用言蛇。
Swift 與 Objective-C 混合
上面講過兩種語言的底層是完全不同的应媚，但是我相信混合開發(fā)的時(shí)候怎么去處理呢？
尤其是在 Objective-C 代碼中調(diào)用 Swift 的時(shí)候猜极，Swift 沒有運(yùn)行時(shí)這種東西中姜，而OC調(diào)用混導(dǎo)致異常問題。這個(gè)時(shí)候我們見到的 @objc 就挺身而出了跟伏。
@objc
只有不是繼承 NSObject 的 Swift 寫的 Class 的非私有類型丢胚， 在 OC 中調(diào)用的時(shí)候都是需要加上這個(gè)標(biāo)志
Swift 的世界有太多的東西，有時(shí)間在說
......
如果你看到這里受扳，插播一條廣告：
公司需要 需要 兩名iOS開發(fā)人員
坐標(biāo)：北京望京 Soho T3 30層
要求是：Swift, OC 都在中等以上,扎實(shí)的計(jì)算機(jī)基礎(chǔ)
公司不打卡,各種補(bǔ)貼携龟，技術(shù)團(tuán)隊(duì)來自知名企業(yè)：IBM,微軟,惠普,三星,百度等等 CTO 早年跟喬布斯有過合作。
氛圍很好勘高。 簡歷這里： sirBliar@gmail.com
我直接面試峡蟋，算是內(nèi)推。??
