App架構設計經驗談:介面的設計
App架構設計經驗談:技術選型
App架構設計經驗談:資料層的設計
App架構設計經驗談:業務層的設計
App架構設計經驗談:展示層的設計
當你做架構設計時，必然會面臨技術選型的抉擇，不同的技術方案，架構也可能完全不同。有哪些技術選型需要做決策呢？比如，App是純原生開發，還是Web App，抑或Hybrid App？iOS開發，語言上是選擇Objective-C還是Swift？架構模式用MVC，還是MVP，或者MVVM？下面根據我的一些經驗對某些方面做點總結分享。
原生/H5
關於用原生好，還是用H5好的爭論從沒間斷過。但我覺得，脫離了實際場景來討論孰好孰壞意義不大。就說我們目前正在做的專案，先說明下背景：
- 不止要做Android和iOS App，也要做微信公眾號；
- H5人員缺乏，只有一兩個兼職的可用，而且不可控因素很高；
- 我們對原生比較熟；
- 開發時間只有半個月。
首先，需求上來說，大部分頁面用H5實現，可以減少很多工作量。但因為不可控因素太高，而時間又短，風險太大。而我們對原生比較熟，開發效率比較高，很多東西我也控制得了，風險相對比較低。而且，我們的主推產品是App，微信屬於輔助性產品，所以，微信要求也沒那麼高。因此，我決定以原生為主，H5為輔，App大部分頁面用原生完成，小部分用WebView載入H5。
另外，WebView載入H5也有兩種模式，一種是載入伺服器的H5頁面，一種是載入本地的H5頁面。載入伺服器的H5頁面比較簡單，WebView只要load一下URL就可以了。載入本地的H5頁面，則需要將H5檔案存放在本地，包括關聯的CSS和JS檔案。這種方式相對比較複雜，不過，載入速度會比第一種快很多。我們當前專案基於上面考慮，只能選擇第一種方案。
如果人員和時間資源充足的話，那又如何選型呢？毫無疑問，我會以H5為主，微信和App都有的頁面統一用H5，App專有的部分，比如導航欄、標題欄、登入等，才用原生實現。另外，WebView裡的H5有點選事件時，也許是URL連結，也許是呼叫JS的，都不會讓它直接在該WebView裡做跳轉，需要攔截下來做些原生處理後跳轉到一個新的原生頁面，原生頁面也許嵌入另一個WebView，用來展示新的H5頁面。這是簡單的例子，關於Hybrid App詳細的設計，以後再講。另外，關於H5，絕對是大趨勢，強烈建議所有App開發人員都去學習。
Objective-C/Swift
我在專案中選擇了Swift，主要基於三個原因：
- Swift真的很簡潔，生產效率很高；
- Swift取代Objective-C是必然的趨勢；
- 目前iOS只有我一個人開發，不需要顧慮到團隊裡沒人懂Swift。
如果你的團隊裡沒人懂Swift，那還是乖乖用Objective-C吧；如果有一兩個懂Swift的，那可以混合開發，並讓不懂的人儘快學會Swift；如果都懂了，不用想了，直接上Swift吧。
當語言上選擇了Swift，相應的一些第三方庫也面臨著選型。比如，依賴庫管理，Objective-C時代大部分用CocoaPods，Swift時代，我更喜歡Carthage。Carhage是用Swift寫的，和CocoaPods相比，輕耦合，也更靈活。我個人也不太喜歡CocoaPods，使用起來比較麻煩，耦合性也較高，我使用過程中也經常出問題，而且還總是不知道該怎麼解決，要移除時也是非常麻煩。
再推薦幾個關於Swift的第三方庫：
- Alamofire：Swift版本的網路基礎庫，和AFNetworking是同一個作者
- AlamofireImage：基於Alamofire的圖片載入庫
- ObjectMapper：Swift版本的Json和Model轉換庫
- AlamofireObjectMapper：Alamofire的擴充套件庫，結合了ObjectMapper，自動將JSON的Response資料轉換為了Swift物件
MVC/MVP/MVVM
先分別簡單介紹下這三個架構模式吧：
- MVC：Model-View-Controller，經典模式，很容易理解，主要缺點有兩個：
- View對Model的依賴，會導致View也包含了業務邏輯；
- Controller會變得很厚很複雜。
- MVP：Model-View-Presenter，MVC的一個演變模式，將Controller換成了Presenter，主要為了解決上述第一個缺點，將View和Model解耦，不過第二個缺點依然沒有解決。
- MVVM：Model-View-ViewModel，是對MVP的一個優化模式，採用了雙向繫結：View的變動，自動反映在ViewModel，反之亦然。
架構模式上，我不會推崇說哪種模式好，每種模式都各有優點，也各有極限性。越高階的模式複雜性越高，實現起來也越難。最近火熱的微服務架構，比起MVC，複雜度不知增加了多少倍。
我在實際專案中思考架構時，也不會想著要用哪種模式，我只思考現階段，以現有的人力資源和時間資源，如何才能更快更好地完成需求，適當考慮下如何為後期擴充套件或重構做準備。就說我前段時間分享的Android專案重構之路系列中講的那個架構，確切地說，都不屬於上面三種架構模式之一。
寫在最後
技術選型，決策關鍵不在於每種技術方案的優劣如何，而在於你團隊的水平、資源的多寡，要根據實際情況選擇最適合你們當前階段的架構方案。當團隊擴充了，資源也充足了，肯定也是需要再重構的，到時再思考其他更合適更優秀的方案。