2017混合应用开发现状

混合应用的概念是相对于原生应用而来的，也就是部分采用了web前端技术所开发的应用，曾经的混原之争也是相当热闹了一阵，如今已经尘埃落定，他们的各种利弊都经过了充分的讨论和验证，相信大部分开发者都已经清楚自己需要的是什么了，那么2017年的今天，混合应用开发到底是怎样一个状况呢？

背景知识

破”壳”而出

一切都得有个源头。

前端同学应该还记得曾经大名鼎鼎的phonegap，当年的phonegap对前端圈的影响力不亚于今天的nodejs，因为他们都做了同一件事：拓展前端的开发能力。phonegap后来有了一个叫cordova的分支，其实都是一个东西，它能让一名前端开发者，在几乎不需要额外技术的情况下开发APP，而且跨平台！

要知道，对于处在程序员鄙视链底端的前端工程师来说，对新技能的渴求可以用嗷嗷待哺来形容，这种不自信的影响是深远的，直到今天仍然随处可见，但至少有一个影响是正面的，那就是全行业广泛的、时刻保有的、旺盛的好奇心，这使phonegap/cordova这种拥有恰当题材和恰当质量的项目，能够迅速积累起足够体量的第一批用户，后面就如你所知道的那样，铺天盖地的上手体验、技术讨论、野教程迅速填满了大部分的前端技术博客，让后来人想学不会都难。

混合应用的本质

混合应用的本质是一个原生的”壳”里跑着web的芯，通常这个”壳”有两方面作用，一是提供跑web页面的webview，二是充当一个桥梁，将操作系统的原生功能嫁接给webview里的js调用，这样，就可以用web的方式去开发APP，效率和能力兼得。phonegap/cordova是一个存粹的”壳”，除了一个webview之外只提供少数几样原生功能，这样开发出来的混合应用更像是一个Web APP Plus，但混合应用不限于这一种形式，哪怕一个APP大部分都是原生，只有一个页面是web的，理论上这也算混合应用。

速度为王

快速开发快速迭代是做产品的永恒追求，新产品验证需求需要快，成熟产品甩掉竞争对手也需要快。

混合开发模式最突出的优点就是开发速度快，比起原生开发，本来web开发速度就很快，再加上一次开发多端发布，那就不是一般的快，而是快上加快，省下一个人的同时，开发进度还能提前，何乐而不为。

当然，”省下一个人”这个说法并不准确，实际上除了少数简单项目，多数情况的APP项目即使采用混合开发模式，也不能完全摆脱掉原生开发，因为通用”壳”的功能是有限的，很多时候还是需要针对”壳”做原生开发。

成也速度，败也速度。混合应用最为人诟病的缺点就是运行”慢”，受限于前端语言表现力和webview的能力，混合应用在精致和流畅方面恐怕永远也达不到原生水准，复杂动画的实现往往只能停留在理论层面，另外嫁接过来的功能肯定不如直接调api来的效率高，这些问题积累起来，导致混合应用整体”慢”的印象。

现实世界中原生同学的抵制也算是混合应用的一大缺点吧，这里就不展开了，默哀一分钟。

混合应用的现状

机遇与挑战

如今很多大厂APP也都是混合应用了，毕竟不是所有项目都需要那么极致的效果，尤其偏”内容类”的项目，如果没有大的技术变革，混合模式将是这类APP开发的首选。

针对混合应用”慢”的问题，目前最有效的方法是通过自定义”壳”，将重要的部分用原生实现，其他部分用web实现，从而灵活的避免web性能短板，总有一个混合程度是你的项目能接受的。

自制”壳”说起来简单，运行一个webview，为js和系统做嫁接，顺便还可以做做静态资源缓存之类的功能，甚至可以针对不同平台区别对待，但实际开发下来，需求点还是挺多的，这样一来各平台的原生开发成本就都回来了，而且如果遇到经常改需求的试水项目，一旦需求改到了原生头上，那混合的意义就不大了。

混合应用还有一个业界难题就是页面转场动画，css3不是不能实现动画，无奈的是不同配置的机器跑起来的差别太大，低端安卓机下的效果令人泪奔，完全无法用于商业项目，这个问题目前只能在”壳”的层面解决，可以为每个页面跑一个webview，页面切换即webview切换，这样就可以实现原生的转场效果了，这个思路已经在Appcan/APICloud这些产品上实现了。

“壳”的演进

总结起来，开发一个混合应用目前有三种”壳”可以选。

一是phonegap/cordova，已经更新到7.x版本了，但只对兼容平台做调整，核心插件始终是那几样，铁了心只做底层。这个方案我个人不太看好，在一个webview里跑整个web应用，基本上就只能定位在玩具级了，长远来看性能问题没有解决的希望，因为操作系统没有动力去为webview做更多优化，人家图什么？

二是自己开发原生外壳，功能要啥有啥，从结果上来说是最佳方案，就是整体开发效率不高，适合成熟的团队，做成熟的项目，个人认为绝大多数项目到了后期应该都是奔着这个方向去的。

第三种就是Appcan/APICloud之流，可以说介于前两者之间，既是通用框架，功能又比phonegap/cordova多，一定程度上解决了转场问题，还集成推送、更新、诊断之类的常用功能，一般的项目基本就不需要原生介入了，目的就是一个，把开发一个各方面都还差不多的APP的成本降下来。

云开发平台

着重说一下Appcan/APICloud这类云平台，他们最初能吸引到用户最大的噱头是多webview机制，一举解决了混合应用页面转场性能问题，再针对多webview机制推出一整套完善的api，满足开发中的大多数基础需求，使基于平台的开发可以做到”开箱可用”，加上本土化的官方插件生态，基本上常见需求都可以在没有原生开发介入的情况下实现，这对很多小团队或者说试水项目还是很有吸引力的。

之所以叫云平台，是因为他们的所有服务都在云端，包括最核心的应用引擎也就是原生外壳，我们得上传web代码然后在云端编译，然后下载APP安装包。这种模式就很敏感了，首先开发者会感觉不安全，因为我们的代码不可避免的暴露了；然后引擎不在自己手里，引擎的开发和维护就只能完全依靠平台，当遇到bug或特殊需求时，开发者除了求助就只能摊手坐等，开发进度在一定程度上是失控的。这些问题可以通过购买他们的企业服务解决，企业用户可以部署本地打包，也将得到更好的技术支持。Appcan/APICloud这两个平台我都深度使用过，其中Appcan就是个纯坑，bug多到令人发指，拜其所赐，”开发进度失控”的情况真的发生过，那个项目结束后果断转到APICloud，几个项目体验下来基本没bug，不过除此以外，他们在功能和服务上也就没啥区别了。

如果对云平台这种模式不是特别敏感的话，就很有可能成为他们的目标用户，因为这种模式还是颇有一些优点的，从APP的名称、图片、证书等各种设置开始，到代码管理、调试机制、插件生态、云端打包、版本管理，整个开发周期里能用到的功能一应俱全，概括起来至少有以下几个优点：