面对功能复杂数据庞大的APP开发工作时，几乎所有的软件公司在做APP架构设计时都会面临技术选型的抉择，不同的技术方案架构也可能完全不同。比如App是纯原生开发，还是Web App，抑或混合APP(混合APP)？如果是iOS开发选择Objective-C还是Swift？架构模式用MVC，还是MVP，或者MVVM？下面根据陕西弈聪软件公司就APP开发架构设计一些经验对某些方面 做点总结分享。

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

开发语言选Objective-C/Swift的问题

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

APP开发技术选型，决策关键不在于每种技术方案的优劣如何，而在于团队的水平、资源的多寡，要根据实际情况选择最适合当前阶段的架构方案。当团队拓展了，资源也充足了，肯定也是需要再重构的，到时再思考其他更合适更优秀的方案。