至今,客户端/移动端/前端(Client)市面上出现了各种各样的开发技术,让开发者应接不暇,用一个词语形容,就是“混乱”。从Node.js将黑手伸向后端、到HTML5的兴起和风靡、再到微信小程序的问世,至今市面上已出现各种形似的小程序,以及如今的Flutter,技术更新可说是层出不穷,令人兰花缭乱,在繁荣的背后,是开发者的迷茫与无奈。在此写这篇文章,算是这一段时间的总结归纳,也算做是2019年的收官。

开发史话:Web App、Hybrid App、Native App、React Native、小程序等技术的对比与总结

当前的APP开发模式主要有以下几大类型:

  • Web App 即移动端的网站,将页面部署在服务器上,然后用户使用各大浏览器访问。一般泛指**SPA(Single Page Application)**模式开发出的网站。体验最差。但是现在有了PWA技术,性能上得到了一定的补充。
  • Hybrid App 即混合开发,由Native通过JSBridge等方法提供统一的API,然后用HTML5+JS来写实际的逻辑,调用操作系统API,这种模式下,最终的页面也是在webview中显示,达到跨平台效果。
  • Native App 即传统的原生APP开发模式,Android基于Java或Kotlin语言,底层调用Google Android的API;iOS基于Objective C或者Swift语言,底层调用App官方提供的API。体验最好。
  • React Native App Facebook发起的开源的一套新的APP开发方案,使用JS+部分原生语法来实现功能。初次学习成本较高,但是在入门后,经过良好的封装也能够实现大部分的跨平台。而且用户体验不亚于Native App。
  • Weex App Weex最底层的原理是和React-Native相同的,就是将JS代码渲染成原生组件。只不过在代码实现层面,Weex和React-Native有差别。
  • Flutter 这是一个新兴的技术,不知为什么2019年就突然火了,也是业界大佬Google的佳作,使用Dart语言开发,但是由于刚兴起不久生态并不完善,仍然有很多问题,学习成本高,开发效率不算高(由于其嵌套语法简直令人难以忍受)。用户体验不亚于Native App。

可以参考脑图:常见的集中App开发模式

Web App

即移动端的网站,将页面部署在服务器上,然后用户使用各大浏览器访问,不是独立APP,无法安装和发布

Web网站一般分两种,MPA(Multi-page Application)和SPA(Single-page Application)。渲染模式也有两种:SSR(Server Side render)和CSR(Client Side render),而目前的开发以CSR模式为主。Web App一般泛指后面的CSR模式下以SPA形式开发出的网站(因为可以模仿一些APP的特性),有如下优点和缺点

优点

  • 开发成本低,可以跨平台,调试方便。web app一般只需要一个前端人员开发出一套代码,然后即可应用于各大主流浏览器(特殊情况可以代码进行下兼容),没有新的学习成本,而且可以直接在浏览器中调试
  • 维护成本低。同上,如果代码合理,只需要一名前端就可以维护多个web app
  • 更新最为快速。由于web app资源是直接部署在服务器端的,所以只需要替换服务器端的文件,用户访问是就已经更新了(当然需要解决一些缓存问题)
  • 无需安装App,不会占用手机内存。通过浏览器即可访问,无需安装,用户就会比较愿意去用

缺点

  • 性能低,用户体验差。由于是直接通过的浏览器访问,所以无法使用原生的API,操作体验不好
  • 依赖于网络,页面访问速度慢,耗费流量。Web App每次访问都需要去服务端加载资源访问,所以必须依赖于网络,而且网速慢时访问速度很不理想,特别是在移动端,如果网站优化不好会无故消耗大量流量
  • 功能受限,大量功能无法实现。只能使用Html5的一些特殊api,无法调用原生API,所以很多功能存在无法实现情况
  • 临时性入口,用户留存率低。这既是它的优点,也是缺点,优点是无需安装,确定是用完后有时候很难再找到,或者说很难专门为某个web app留存一个入口,导致用户很难再次使用

PWA

Progressive Web App, 中文名叫做渐进式网页应用,简称 PWA,是提升 Web App 的体验的一种新方法,能给用户原生应用的体验。

PWA 以及构成 PWA 的一系列关键技术的出现,终于让我们看到了彻底解决这两个平台级别问题的曙光:能够显著提高应用加载速度、甚至让 web 应用可以在离线环境使用的 Service Worker 与 Cache Storage;用于描述 web 应用元数据(metadata)、让 web 应用能够像原生应用一样被添加到主屏、全屏执行的 Web App Manifest;以及进一步提高 web 应用与操作系统集成能力,让 web 应用能在未被激活时发起推送通知的 Push API 与 Notification API 等等。

PWA 可以将 Web 和 App 各自的优势融合在一起:渐进式、可响应、可离线、实现类似 App 的交互、即时更新、安全、可以被搜索引擎检索、可推送、可安装、可链接。

详情可以参考我的另一篇文章 网站 PWA 化开发实践

JSSDK

比如在进行微信网页开发时,可以调用一些微信的特殊jsapi,这其实就是算是微信的Hybrid模式,但仍然是运行在浏览器中(只不过是腾讯的X5内核)

除了微信网页开发可以使用到JSSDK,支付宝也有自己的Alipay JSSDK,也是将网页内嵌在支付宝内

当然了,微信在这方面做了很多限制,比如权限认证等等,所以导致开发起来效果不是很完美。这里不再赘述其功能

Hybrid App

即混合开发,也就是半原生半Web的开发模式,有跨平台效果,当然了,实质最终发布的仍然是独立的原生APP(各种的平台有各种的SDK),有如下优点和缺点

优点

  • 开发成本较低,可以跨平台,调试方便。Hybrid模式下,由原生提供统一的API给JS调用,实际的主要逻辑由HTML和JS来完成,而由于最终是放在webview中显示的,所以只需要写一套代码即可,达到跨平台效果,另外也可以直接在浏览器中调试,很为方便。最重要的是只需要一个前端人员稍微学习下JS api的调用即可,无需两个独立的原生人员。一般Hybrid中的跨平台最少可以跨三个平台:Android App,iOS App,普通webkit浏览器
  • 维护成本低,功能可复用。如果代码合理,只需要一名前端就可以维护多个app,而且很多功能还可以互相复用
  • 更新较为自由。虽然没有web app更新那么快速,但是Hybrid中也可以通过原生提供api,进行资源主动下载,达到只更新资源文件,不更新apk(ipa)的效果
  • 针对新手友好,学习成本较低。这种开发模式下,只需要前端人员关注一些原生提供的API,具体的实现无需关心,没有新的学习内容,只需要前端人员即可开发
  • 功能更加完善,性能和体验要比起Web App好太多。因为可以调用原生api,所以很多功能只要原生提供出就可以实现,另外性能也比较接近原生了
  • 部分性能要求的页面可用原生实现。这应该是Hybrid模式的最多一个好处了,因为这种模式是原生混合web,所以我们完全可以将交互强,性能要求高的页面用原生写,然后一些其它页面用JS写,嵌入webview中,达到最佳体验

缺点

  • 相比原生,性能仍然有较大损耗。这种模式受限于webview的性能桎梏,相比原生而言有不少损耗,体验无法和原生相比
  • 不适用于交互性较强的app。这种模式的主要应用是:一些新闻阅读类,信息展示类的app;但是不适用于一些交互较强或者性能要求较高的app(比如动画较多就不适合)

JSBridge

JSBridge是广为流行的Hybrid开发中JS和Native一种通信方式,各大公司的应用中都有用到这种方法

简单的说,JSBridge就是定义Native和JS的通信,Native只通过一个固定的桥对象调用JS,JS也只通过固定的桥对象调用Native,基本原理是:

H5->通过某种方式触发一个url->Native捕获到url,进行分析->原生做处理->Native调用H5的JSBridge对象传递回调。

Native App

即原生开发模式,开发出来的是原生程序,不同平台上,Android和iOS的开发方法不同,开发出来的是一个独立的APP,能发布应用商店,有如下优点和缺点

优点

  • 直接依托于操作系统,交互性最强,性能最好。相比于其它模式的交互,原生APP体验是最优的
  • 功能最为强大,特别是在与系统交互中,几乎所有功能都能实现。得益于原生是直接依托于系统的,所以可以直接调用官方提供的api,功能最为全面(比如本地资源操作,通知,动画等)

缺点

  • 开发成本高,无法跨平台,不同平台Android和iOS上都要各自独立开发。Android上基于Java和Kotlin开发,iOS上基于OC或Swift开发,相互之间独立,必须要有各自的开发人员
  • 门槛较高,原生人员有一定的入门门槛,相比广大的前端人员而言较少。原生的一个很大特点就是独立,所以不太容易入门,不像web前端一样那么广泛,而且Android,iOS都需要独立学习
  • 更新缓慢,特别是发布应用商店后,需要等到审核周期。原生应用更新是一个很大的问题,Android中还能直接下载整包APK进行更新,但是iOS中,如果是发布AppStore,必须通过AppStore地址更新,而每次更新都需要审核,所以无法达到及时更新
  • 维护成本高。同开发一样,项目上线后,维护起来也很为麻烦

React Native

Facebook发起的开源的一套新的APP开发方案,Facebook在当初深入研究Hybrid开发后,觉得这种模式有先天的缺陷,所以果断放弃,转而自行研究,后来推出了自己的“React Native”方案,不同于H5,也不同于原生,更像是用JS写出原生应用,有如下优点和缺点

其实很多大公司都已经都有研究React Native开发了,整体技术方案已经相对比较成熟了

优点

  • 虽然说开发成本大于Hybrid模式,但是小于原生模式,大部分代码可复用。相比于原生模式,这种模式是统一用JS写代码,所以往往只需要一名成员投入学习,即可完成跨平台app的开发,而且后续代码封装的好,很多功能可复用
  • 性能体验高于Hybrid,不逊色与原生。这种模式和Hybrid不一样,Hybrid中的view层实际上还是dom,但是这种模式的view层是虚拟dom,所以性能要高于Hybrid,距离原生差距不大。可以认为是用JS写原生,即页面用JS写,然后原生通过Bridge技术分析JS,将JS内容单独渲染成原生Android和iOS,所以也就是为什么性能不逊色原生
  • 开发人员单一技术栈,一次学习,跨平台开发。这种模式是统一由JS编写,有着独特的语法,所以只需要学习一次,即可同时开发Android和iOS
  • 社区繁荣,遇到问题容易解决。这应该是React Native的很大一个优势,不像Hybrid模式和原生模式一样各自为营,这种模式是Facebook统一发起的,所以有一个统一的社区,里面有大量资源和活跃的人员,对开发者很友好

缺点

  • 虽然可以部分跨平台,但并不是Hybrid中的一次编写,两次运行那种,而是不同平台代码有所区别。这种模式实际上还是JS来写原生,所以Android和iOS中的原生代码会有所区别,如果需要跨平台,对开发人员有一定要求。当然了,如果发展了有一定时间,组件库够丰富了,那么其实影响也就不大了,甚至会比Hybrid更快
  • 开发人员学习有一定成本。虽然社区已经比较成熟了,但是一个新的普通前端学习起来还是有一定学习成本的,无法像Hybrid模式一样平滑。不要小瞧这一点,对于一些传统的大规模低阶程序员的公司而言,这成为了选用React-Native的最大一个障碍,因为无法要求每一个人都能够会这个开发,推广起来有很大问题。当然,对于一些相对精英公司来说,这点倒是影响不大

Weex

weex是阿里开源出来的一套APP开发方案,底层原理和React-Native一致,都是通过核心引擎将代码编译成原生组件。达到原生APP的体验效果。性能体验要优于Hybrid模式。

它与Hybrid相比,大部分优缺点都是React-Native中有提到的,但与React-Native相比,它又有如下的优缺点:

优点

  • 一套代码跨平台,只要遵循特定的语法规则,完全可以达到一套代码多个平台运行。核心就是在web环境下,将源码编译成web中显示的HTML DOM等,在原生环境下编译成原生组件。而React-Native中,它是JS写原生代码,不同平台代码是不一样的,虽然有大部分可以复用,但并不是完全一套代码多个平台。
  • 语法接近H5,基本用法和H5一致,特别是后来改成了支持VUE.JS后,使用起来更是很方便。

缺点

  • 目前来说,社区相比React-Native不足,是一个比较大的缺点
  • 目前相比React-Native是新生,坑更多一点

Flutter

Flutter 是今年突然火起来的技术,由Google开发,使用Dart语言编写,编写一套代码即可编译到Android和iOS两端,性能媲美原生。

优点

  • 一套代码即可编译到Android和iOS两端。
  • 内置Meterial UI,界面美观,内置组件丰富。
  • 性能媲美原生。

缺点

  • 由于使用Dart语言,增加了学习成本。
  • 开发成本也不低,虽然一套代码可以编译到多端,但是代码量不少,特别是其嵌套地狱,简直让人难以忍受。
  • 生态不完善,缺少很多轮子,大部分时候还得自己写原生代码实现。

小程序

微信小程序是微信新推出的一种新的app方案,2016年9月开始进行内测,2016年11月准备全面面向开发者

需要注意的是,这种模式是“反HTML5”的,相当于是微信提供的一套封闭开发模式,有自己的语法和IDE,有的类似于iOS开发的感觉。

随着时间的推进,目前已出现多种App,其共同性都是内嵌于一个“超级App”中,比如:微信小程序、支付宝小程序、QQ小程序、头条小程序、百度小程序等

从归类的角度,我将 快应用流应用 也归属到这一类,只不过快应用依赖的的是国内十大手机厂商的操作系统(内置快应用框架),而流应用依赖的是DCloud的流应用基座

杂合性

最近有很多团队出了一些非常不错的技术,比如DCloud的uni-app,大有一统江山的味道。

uni-app

uni-app 采用 Vue 的语法形式,组件使用微信小程序的基础组件形式,API 统一为 uni 前缀的接口,目前可以编译到Android、iOS、H5、各种小程序。

针对不同的编译目标,uni-app提供条件编译,可以为特定平台添加专属代码,调用特定平台的API和其他特性。

uni-app还可以使用nvue进行原生开发,编译模式可以指定为原生编译,性能上也是非常棒的。

其实uni-app团队算是很不错的了,将大部分差异性都掩藏,而暴露给开发者的是一个个统一的接口

除了uni-app外,还有众多的其他跨端开发技术,比如:

  • taro
  • wepy
  • chameleon
  • capacitor
  • ...

总结

在移动端/前端繁盛的今天,选用什么技术,这是个问题,为什么要给我那么多选项?就不能给个默认选项吗?从技术选型,到工具链选择,到周边插件选择,到业务代码的实现,每一步,都有无数的选项,困扰着开发者。

但是,我相信,就像《三国演义》中说的“分久必合,合久必分”,这种局面最终应该也会有所改变。就像当初浏览器之争,开发者不得不为每一种浏览器做一些单独的开发(多亏了当时的jquery),然而,现在大家也不是那么关注浏览器适配了,因为市面上大都是Chromium内核的浏览器,Chrome独占鳌头。

uni-app是一个不错的开端,形式上统一了大部分技术,为开发者屏蔽了大部分差异性,可以预见,这样的趋势会将持续下去,越来越完善。

参考资料

MIT Licensed | Copyright © 2018-present 滇ICP备16006294号

Design by Quanzaiyu | Power by VuePress