當(dāng)你做架構(gòu)設(shè)計時，必然會面臨技術(shù)選型的抉擇，不同的技術(shù)方案，架構(gòu)也可能完全不同。有哪些技術(shù)選型需要做決策呢？比如，App是純原生開發(fā)，還是Web App，抑或Hybrid App？iOS開發(fā)，語言上是選擇Objective-C還是Swift？架構(gòu)模式用MVC，還是MVP，或者M(jìn)VVM？下面根據(jù)我的一些經(jīng)驗對某些方面做點(diǎn)總結(jié)分享。

原生/H5

關(guān)于用原生好，還是用H5好的爭論從沒間斷過。但我覺得，脫離了實際場景來討論孰好孰壞意義不大。就說我們目前正在做的項目，先說明下背景：

1. 不止要做Android和iOS App，也要做微信公眾號；
2. H5人員缺乏，只有一兩個兼職的可用，而且不可控因素很高；
3. 我們對原生比較熟；
4. 開發(fā)時間只有半個月。

首先，需求上來說，大部分頁面用H5實現(xiàn)，可以減少很多工作量。但因為不可控因素太高，而時間又短，風(fēng)險太大。而我們對原生比較熟，開發(fā)效率比較高，很多東西我也控制得了，風(fēng)險相對比較低。而且，我們的主推產(chǎn)品是App，微信屬于輔助性產(chǎn)品，所以，微信要求也沒那么高。因此，我決定以原生為主，H5為輔，App大部分頁面用原生完成，小部分用WebView加載H5。

另外，WebView加載H5也有兩種模式，一種是加載服務(wù)器的H5頁面，一種是加載本地的H5頁面。加載服務(wù)器的H5頁面比較簡單，WebView只要load一下URL就可以了。加載本地的H5頁面，則需要將H5文件存放在本地，包括關(guān)聯(lián)的CSS和JS文件。這種方式相對比較復(fù)雜，不過，加載速度會比第一種快很多。我們當(dāng)前項目基于上面考慮，只能選擇第一種方案。

如果人員和時間資源充足的話，那又如何選型呢？毫無疑問，我會以H5為主，微信和App都有的頁面統(tǒng)一用H5，App專有的部分，比如導(dǎo)航欄、標(biāo)題欄、登錄等，才用原生實現(xiàn)。另外，WebView里的H5有點(diǎn)擊事件時，也許是URL鏈接，也許是調(diào)用JS的，都不會讓它直接在該WebView里做跳轉(zhuǎn)，需要攔截下來做些原生處理后跳轉(zhuǎn)到一個新的原生頁面，原生頁面也許嵌入另一個WebView，用來展示新的H5頁面。這是簡單的例子，關(guān)于Hybrid App詳細(xì)的設(shè)計，以后再講。另外，關(guān)于H5，絕對是大趨勢，強(qiáng)烈建議所有App開發(fā)人員都去學(xué)習(xí)。

Objective-C/Swift

我在項目中選擇了Swift，主要基于三個原因：

1. Swift真的很簡潔，生產(chǎn)效率很高；
2. Swift取代Objective-C是必然的趨勢；
3. 目前iOS只有我一個人開發(fā)，不需要顧慮到團(tuán)隊里沒人懂Swift。

如果你的團(tuán)隊里沒人懂Swift，那還是乖乖用Objective-C吧；如果有一兩個懂Swift的，那可以混合開發(fā)，并讓不懂的人盡快學(xué)會Swift；如果都懂了，不用想了，直接上Swift吧。

當(dāng)語言上選擇了Swift，相應(yīng)的一些第三方庫也面臨著選型。比如，依賴庫管理，Objective-C時代大部分用CocoaPods，Swift時代，我更喜歡Carthage。Carhage是用Swift寫的，和CocoaPods相比，輕耦合，也更靈活。我個人也不太喜歡CocoaPods，使用起來比較麻煩，耦合性也較高，我使用過程中也經(jīng)常出問題，而且還總是不知道該怎么解決，要移除時也是非常麻煩。

再推薦幾個關(guān)于Swift的第三方庫：

1. Alamofire：Swift版本的網(wǎng)絡(luò)基礎(chǔ)庫，和AFNetworking是同一個作者
2. AlamofireImage：基于Alamofire的圖片加載庫
3. ObjectMapper：Swift版本的Json和Model轉(zhuǎn)換庫
4. AlamofireObjectMapper：Alamofire的擴(kuò)展庫，結(jié)合了ObjectMapper，自動將JSON的Response數(shù)據(jù)轉(zhuǎn)換為了Swift對象

MVC/MVP/MVVM

先分別簡單介紹下這三個架構(gòu)模式吧：

• MVC：Model-View-Controller，經(jīng)典模式，很容易理解，主要缺點(diǎn)有兩個：
  1. View對Model的依賴，會導(dǎo)致View也包含了業(yè)務(wù)邏輯；
  2. Controller會變得很厚很復(fù)雜。
• MVP：Model-View-Presenter，MVC的一個演變模式，將Controller換成了Presenter，主要為了解決上述第一個缺點(diǎn)，將View和Model解耦，不過第二個缺點(diǎn)依然沒有解決。
• MVVM：Model-View-ViewModel，是對MVP的一個優(yōu)化模式，采用了雙向綁定：View的變動，自動反映在ViewModel，反之亦然。

架構(gòu)模式上，我不會推崇說哪種模式好，每種模式都各有優(yōu)點(diǎn)，也各有極限性。越高級的模式復(fù)雜性越高，實現(xiàn)起來也越難。最近火熱的微服務(wù)架構(gòu)，比起MVC，復(fù)雜度不知增加了多少倍。

我在實際項目中思考架構(gòu)時，也不會想著要用哪種模式，我只思考現(xiàn)階段，以現(xiàn)有的人力資源和時間資源，如何才能更快更好地完成需求，適當(dāng)考慮下如何為后期擴(kuò)展或重構(gòu)做準(zhǔn)備。就說我前段時間分享的Android項目重構(gòu)之路系列中講的那個架構(gòu)，確切地說，都不屬于上面三種架構(gòu)模式之一。

寫在最后

技術(shù)選型，決策關(guān)鍵不在于每種技術(shù)方案的優(yōu)劣如何，而在于你團(tuán)隊的水平、資源的多寡，要根據(jù)實際情況選擇最適合你們當(dāng)前階段的架構(gòu)方案。當(dāng)團(tuán)隊拓展了，資源也充足了，肯定也是需要再重構(gòu)的，到時再思考其他更合適更優(yōu)秀的方案。