0%

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的名称、图片、证书等各种设置开始,到代码管理、调试机制、插件生态、云端打包、版本管理,整个开发周期里能用到的功能一应俱全,概括起来至少有以下几个优点:

  1. 多webView + 原生动画转场,提升页面切换流畅度;
  2. 多webView可以取代前端路由,降低开发门槛;
  3. 官方提供插件和第三方扩展,进一步降低开发门槛;
  4. 官方定制IDE集成调试、预览、同步等功能,开发体验非常好。

为了让一名前端就能搞定APP开发,他们真做了不少工作,可以说是一种颇具性价比的混合应用开发方案。

后记

介绍了目前几种混合应用开发方案后,不得不说这就是个理想与现实的较量,势单力薄的我只好选择了云平台方案,但即便平台做的再好,仍然有很多问题需要自己解决,近期将更新一个姊妹篇,讲讲基于云平台的混合应用开发框架HybridStart

前端路上原创技术文章,转载请注明出处:https://refined-x.com/2017/06/23/2017混合应用开发现状/

看风景-公众号

不甘平庸的你,快来跟我一起充电吧,关注看风景,获取更多精彩内容。