在这个巨变的时代，技术选型是个很难做决定的事情，而移动应用技术领域在几个巨头（Google，Facebook，Apple etc.）的带动下更是日新月异。所以说要选择一个适合业务需求并且匹配开发人员能力的技术方案并不是一件简单的事情。我也只是在移动开发上做过一点微小的工作，此处仅能抛个砖，希望各位有玉的大神尽管砸过来。
做移动应用开发，说起来技术方案不外乎HTML5（没错，做Mobile Web其实也算是一种移动应用）、Native（在Android上不管是用Java、Kotlin还是Scala，iOS上不管是用Objective-C还是Swift）和使用原生UI，用JavaScript来实现逻辑的诸如React Native一类的方案。除此之外，还有结合HTML5和Native的Hybird混合方案。不同的技术方案有着不同的适应场景，至于具体如何选择，接下来我简单地谈谈自己的理解。
1、HTML5
也就是Web App的方案。这种方案最大的优点在于“Write Once, Run Everywhere”，不管你是Android还是iOS，都可以用一套代码搞定，在国内的话还能对接微信公众号，给用户提供一个方便快捷的入口，并且还有版本升级容易的优势（毕竟服务器是受自己控制的）。但是这种方案的缺点也很明显——无法使用系统级API，只能做为一个临时的入口，用户很难留存，并且因为浏览器性能的原因，很难带来很好的用户体验。
所以说Web App的主要适用场景还是在于作为对非核心业务在移动端的入口补足，或者是作为用户轻量、低频使用的体验增强。
美团移动网站引导页
美团移动网站首页
美团的移动网页就是很典型的例子，主要还是提供给不经常使用的用户一个入口，网站内部还是在尽量引导用户下载使用客户端。
2、Hybird
Hybird是一种兼顾Native与HTML的开发模式，但根据实现的不同，还可以再细分为两种实现方案：
- 在Native App中使用WebView加载远端Web资源
- 使用Cordova/PhoneGap等框架通过WebView加载本地资源进行页面渲染
第一种方案其实已经应用得非常普遍了，很多应用的展示页面都是通过这种方式实现的。因为展示页面需要的正是能够轻易更换内容及布局的格式，并且这种纯展示的页面也并不需要复杂的动画与特效，使用Web页面是一个非常合适的解决方案。
而第二种方案前一段时间非常火，因为它在跨平台，在高效开发以及快速发布上有着明显的优势，毕竟Web内容只需要开发一次就可以在各个平台使用。而且将资源打包到本地也可以在一定程度上缓解从远端加载静态资源导致UI展示延迟的问题，并且还可以通过桥接Native和Web来调用一些Device的API。但其劣势也很明显，一是通过WebView执行代码效率较低，很难实现一些炫酷的效果，并且还存在不同设备的兼容性问题；二是如果想调用相关平台的API，需要针对平台单独进行开发，如果在应用中用到了大量的Device API，那么开发的效率将大大降低；三是很难应用到平台相关的新特性，比较难做出有特色的产品。
使用HTML页面来实现纯展示页面是非常推荐的一种方案。而Cordova/PhoneGap则更适用于对Mobile预算有限的公司、创业团队，或者对App进行快速的上线验证。
正好之前有个项目就用到了这种方案，为一家业务转型的零售商提供了使用一套基本代码来完成Android和iOS两个平台的App和微信公众号的相关页面的技术方案。
零售商Android应用零售商微信端
3、React Native
把React Native单独拿出来，是因为确实不能简单的将它分到其它任意一种方案里面去。React Native确实是最近最火的跨平台App解决方案了。它脱胎于React，因为React基于Virtual DOM来进行界面渲染，所以用Native的View来替换掉原本React的HTML DOM就顺理成章的引出了React Native的概念。
它与之前的跨平台方案有一个本质的区别，在于：其它方案都在追求写一次code解决所有平台的问题，而React Native的理念在于“Learn Once, Write Anywhere”。虽然大部分代码是平台无关的，但是平台相关的代码都需要单独实现，这虽然对跨平台带来了不便，但是引入的好处也是显而易见的，View层的部分通过原生组件实现，性能比其他WebView的方案不知道高到哪去了。而且React Native整套的逻辑代码都通过JavaScript实现，这样就让跨平台应用能够方便的复用逻辑代码。另外虽然React Native没有支持使用CSS来实现样式，但是提供了类似CSS的样式表支持，有过UI开发经验的人都能够非常快的上手。由于前端React也是非常的火，很多React社区的很多产出都可以在React Native上借鉴使用。
React Native对于没有复杂动画效果的一般应用来说不失为一个很好的解决方案。而且对于一些小型的企业级应用也是非常适用的。但是，React Native对于Android平台的支持度是不如iOS平台的，而且现有的非常成熟的应用也较少，所以说如果要在一些面向用户量很大，讲求用户体验的App中使用还是要慎重考虑的。
但是，其实Facebook已经在自家的App上用起来了，而且实测效果还是很好的。不过呢，人家毕竟是自家维护的，所以说真正要在项目上用可能还是得试了才知道效果。
facebook Androidfacebook iOS
4、原生应用
原生应用的开发真的是让人又爱又恨。爱在于你可以在它上面施展拳脚、使用新特性、实现炫酷的效果。而恨则在于它跨平台性几乎为零，除了资源外几乎没有可重用的东西，即使是相似架构上的逻辑你也得再实现一遍。使用原生开发，能够方便地添加动画效果，调用底层硬件，所有的限制仅仅是来自平台的限制。但是正常情况下需要对不同的平台搭配不同的开发人员，而且如果要追求良好的用户体验，整个应用的设计还得满足相应平台的设计规范，这不仅是对Dev的考验，也是对UX的考验。不过如果真的对App的质量有很高的要求，我觉得这一切的付出也还是都是值得的。
如果针对的是要求硬件性能、讲究动画效果、追求用户体验的应用，还是建议分平台单独设计，并且都使用原生的技术方案来实现。其实这也是目前市面上大部分企业做出的选择。
使用原生开发我个人还有一个观点，就是设计上要尽量遵守原生应用的设计规范，如果想要一套设计通吃所有平台，最终只会搞一个不伦不类的应用出来。知乎算是国内在这方面做得比较好的应用了，也取得了不错的效果。
知乎
其实，在真正启动项目之前，在进行技术选型时，除了要考虑更符合业务的架构外，还要考虑开发人员的能力及技术栈。毕竟最后App还是由Dev们开发的。如果仅仅考虑业务而不考虑开发人员的技术能力来选择技术方案，不仅有一种钦定的感觉，而且最后往往坑到的还是自己。
我们常说：工具是死的，人是活的。考虑多种因素，在技术选型上做出更充分的考量，才是真正正确的选择。所以说又回到那句老话上：“It depends…”