APP开发工作的功能复杂数据庞大，几乎所有的软件公司在做APP架构设计时都会面临技术选型的抉择，不同的技术方案架构也可能完全不同。

关于用原生好，还是用H5好的争论从没间断过。我们觉得脱离了实际场景来讨论孰好孰坏意义不大。例如项目不止要做Android和iOS App，也要做微信公众号；需求上来说，大部分页面用H5实现，可以减少很多工作量。因为不可控因素太高而时间又短，风险太大。如果APP开发技术人员对原生比较熟，开发效率比较高，很多东西也控制得了，风险相对比较低。如果客户主推产品是App，微信属于辅助性产品，所以微信要求也没那么高。因此可以以原生开发为主，H5为 辅，App大部分页面用原生完成，小部分用WebView加载H5。

在项目中选择了Swift，主要基于两个原因：

1. Swift真的很简洁，生产效率很高；

2. Swift取代Objective-C是必然的趋势；如果你的团队里没人懂Swift，那还是乖乖用Objective-C吧；如果有一两个懂Swift的，那可以混合开发，并让不懂的人尽快学会Swift；如果都懂了，不用想了，直接上Swift吧。当语言上选择了Swift，相应的一些第三方库也面临着选型。比如，依赖库管理，Objective-C时代大部分用CocoaPods，Swift时代，我更喜欢Carthage。Carhage是用Swift写的，和CocoaPods相比，轻耦合，也更灵活。我个人也不太喜欢CocoaPods， 使用起来比较麻烦，耦合性也较高。

MVC：Model-View-Controller，经典模式，很容易理解，主要缺点有两个：1.View对Model的依赖，会导致View也包含了业务逻辑；2.Controller会变得很厚很复杂。

MVP：Model-View-Presenter，MVC的一个演变模式，将Controller换成了Presenter，主要为了解决上述第一个缺点，将View和Model解耦，不过第二个缺点依然没有解决。

MVVM：Model-View-ViewModel，是对MVP的一个优化模式，采用了双向绑定：View的变动，自动反映在ViewModel，反之亦然。

架构模式上每种模式都各有优点，也各有极限性。越高级的模式复杂性越高，实现起来也越难。最近火热的微服务架构，比起MVC，复杂度不知增加了多少倍。

在实际APP开发项目中思考架构时，也要想着要用哪种模式只思考现阶段，以现有的人力资源和时间资源，如何才能更快更好地完成需求，适当考虑下如何为后期扩 展或重构做准备。