當(dāng)你做架構(gòu)設(shè)計(jì)時(shí),必然會(huì)面臨技術(shù)選型的抉擇染坯,不同的技術(shù)方案均芽,架構(gòu)也可能完全不同。有哪些技術(shù)選型需要做決策呢单鹿?比如掀宋,App是純?cè)_(kāi)發(fā),還是Web App,抑或Hybrid App布朦?iOS開(kāi)發(fā)囤萤,語(yǔ)言上是選擇Objective-C還是Swift?架構(gòu)模式用MVC是趴,還是MVP涛舍,或者M(jìn)VVM?下面根據(jù)我的一些經(jīng)驗(yàn)對(duì)某些方面做點(diǎn)總結(jié)分享唆途。
原生/H5
關(guān)于用原生好富雅,還是用H5好的爭(zhēng)論從沒(méi)間斷過(guò)。但我覺(jué)得肛搬,脫離了實(shí)際場(chǎng)景來(lái)討論孰好孰壞意義不大没佑。就說(shuō)我們目前正在做的項(xiàng)目,先說(shuō)明下背景:
不止要做Android和iOS App温赔,也要做微信公眾號(hào)蛤奢;
H5人員缺乏,只有一兩個(gè)兼職的可用陶贼,而且不可控因素很高啤贩;
我們對(duì)原生比較熟;
開(kāi)發(fā)時(shí)間只有半個(gè)月拜秧。
首先痹屹,需求上來(lái)說(shuō),大部分頁(yè)面用H5實(shí)現(xiàn)枉氮,可以減少很多工作量志衍。但因?yàn)椴豢煽匾蛩靥撸鴷r(shí)間又短聊替,風(fēng)險(xiǎn)太大楼肪。而我們對(duì)原生比較熟,開(kāi)發(fā)效率比較高佃牛,很多東西我也控制得了淹辞,風(fēng)險(xiǎn)相對(duì)比較低。而且俘侠,我們的主推產(chǎn)品是App象缀,微信屬于輔助性產(chǎn)品,所以爷速,微信要求也沒(méi)那么高央星。因此,我決定以原生為主惫东,H5為輔莉给,App大部分頁(yè)面用原生完成毙石,小部分用WebView加載H5。
另外颓遏,WebView加載H5也有兩種模式徐矩,一種是加載服務(wù)器的H5頁(yè)面,一種是加載本地的H5頁(yè)面叁幢。加載服務(wù)器的H5頁(yè)面比較簡(jiǎn)單滤灯,WebView只要load一下URL就可以了。加載本地的H5頁(yè)面曼玩,則需要將H5文件存放在本地鳞骤,包括關(guān)聯(lián)的CSS和JS文件。這種方式相對(duì)比較復(fù)雜黍判,不過(guò)豫尽,加載速度會(huì)比第一種快很多。我們當(dāng)前項(xiàng)目基于上面考慮顷帖,只能選擇第一種方案美旧。
如果人員和時(shí)間資源充足的話,那又如何選型呢窟她?毫無(wú)疑問(wèn)陈症,我會(huì)以H5為主,微信和App都有的頁(yè)面統(tǒng)一用H5震糖,App專(zhuān)有的部分,比如導(dǎo)航欄趴腋、標(biāo)題欄吊说、登錄等,才用原生實(shí)現(xiàn)优炬。另外颁井,WebView里的H5有點(diǎn)擊事件時(shí),也許是URL鏈接蠢护,也許是調(diào)用JS的雅宾,都不會(huì)讓它直接在該WebView里做跳轉(zhuǎn),需要攔截下來(lái)做些原生處理后跳轉(zhuǎn)到一個(gè)新的原生頁(yè)面葵硕,原生頁(yè)面也許嵌入另一個(gè)WebView眉抬,用來(lái)展示新的H5頁(yè)面。這是簡(jiǎn)單的例子懈凹,關(guān)于Hybrid App詳細(xì)的設(shè)計(jì)蜀变,以后再講。另外介评,關(guān)于H5库北,絕對(duì)是大趨勢(shì)爬舰,強(qiáng)烈建議所有App開(kāi)發(fā)人員都去學(xué)習(xí)。
Objective-C/Swift
我在項(xiàng)目中選擇了Swift寒瓦,主要基于三個(gè)原因:
Swift真的很簡(jiǎn)潔情屹,生產(chǎn)效率很高;
Swift取代Objective-C是必然的趨勢(shì)杂腰;
目前iOS只有我一個(gè)人開(kāi)發(fā)垃你,不需要顧慮到團(tuán)隊(duì)里沒(méi)人懂Swift。
如果你的團(tuán)隊(duì)里沒(méi)人懂Swift颈墅,那還是乖乖用Objective-C吧蜡镶;如果有一兩個(gè)懂Swift的,那可以混合開(kāi)發(fā)恤筛,并讓不懂的人盡快學(xué)會(huì)Swift官还;如果都懂了,不用想了毒坛,直接上Swift吧望伦。
當(dāng)語(yǔ)言上選擇了Swift,相應(yīng)的一些第三方庫(kù)也面臨著選型煎殷。比如屯伞,依賴(lài)庫(kù)管理,Objective-C時(shí)代大部分用CocoaPods豪直,Swift時(shí)代劣摇,我更喜歡Carthage。Carhage是用Swift寫(xiě)的弓乙,和CocoaPods相比末融,輕耦合,也更靈活暇韧。我個(gè)人也不太喜歡CocoaPods勾习,使用起來(lái)比較麻煩,耦合性也較高懈玻,我使用過(guò)程中也經(jīng)常出問(wèn)題巧婶,而且還總是不知道該怎么解決,要移除時(shí)也是非常麻煩涂乌。
再推薦幾個(gè)關(guān)于Swift的第三方庫(kù):
Alamofire:Swift版本的網(wǎng)絡(luò)基礎(chǔ)庫(kù)艺栈,和AFNetworking是同一個(gè)作者
AlamofireImage:基于Alamofire的圖片加載庫(kù)
ObjectMapper:Swift版本的Json和Model轉(zhuǎn)換庫(kù)
AlamofireObjectMapper:Alamofire的擴(kuò)展庫(kù),結(jié)合了ObjectMapper骂倘,自動(dòng)將JSON的Response數(shù)據(jù)轉(zhuǎn)換為了Swift對(duì)象
MVC/MVP/MVVM
先分別簡(jiǎn)單介紹下這三個(gè)架構(gòu)模式吧:
MVC:Model-View-Controller眼滤,經(jīng)典模式,很容易理解历涝,主要缺點(diǎn)有兩個(gè):
View對(duì)Model的依賴(lài)诅需,會(huì)導(dǎo)致View也包含了業(yè)務(wù)邏輯漾唉;
Controller會(huì)變得很厚很復(fù)雜。
MVP:Model-View-Presenter堰塌,MVC的一個(gè)演變模式赵刑,將Controller換成了Presenter,主要為了解決上述第一個(gè)缺點(diǎn)场刑,將View和Model解耦般此,不過(guò)第二個(gè)缺點(diǎn)依然沒(méi)有解決。
MVVM:Model-View-ViewModel牵现,是對(duì)MVP的一個(gè)優(yōu)化模式铐懊,采用了雙向綁定:View的變動(dòng),自動(dòng)反映在ViewModel瞎疼,反之亦然科乎。
架構(gòu)模式上,我不會(huì)推崇說(shuō)哪種模式好贼急,每種模式都各有優(yōu)點(diǎn)茅茂,也各有極限性。越高級(jí)的模式復(fù)雜性越高太抓,實(shí)現(xiàn)起來(lái)也越難空闲。最近火熱的微服務(wù)架構(gòu),比起MVC走敌,復(fù)雜度不知增加了多少倍碴倾。
我在實(shí)際項(xiàng)目中思考架構(gòu)時(shí),也不會(huì)想著要用哪種模式掉丽,我只思考現(xiàn)階段影斑,以現(xiàn)有的人力資源和時(shí)間資源,如何才能更快更好地完成需求机打,適當(dāng)考慮下如何為后期擴(kuò)展或重構(gòu)做準(zhǔn)備。就說(shuō)我前段時(shí)間分享的Android項(xiàng)目重構(gòu)之路系列中講的那個(gè)架構(gòu)片迅,確切地說(shuō)残邀,都不屬于上面三種架構(gòu)模式之一。
寫(xiě)在最后
技術(shù)選型柑蛇,決策關(guān)鍵不在于每種技術(shù)方案的優(yōu)劣如何芥挣,而在于你團(tuán)隊(duì)的水平、資源的多寡耻台,要根據(jù)實(shí)際情況選擇最適合你們當(dāng)前階段的架構(gòu)方案空免。當(dāng)團(tuán)隊(duì)拓展了,資源也充足了盆耽,肯定也是需要再重構(gòu)的蹋砚,到時(shí)再思考其他更合適更優(yōu)秀的方案扼菠。
來(lái)源:Keegan小鋼