小程序也属于App的一种,那么它和我们现在流行的原生App(iOS、Android)相比,有什么区别和优势呢?
首先,从技术上来讲,目前App的主流开发方式有三种:Web App、Native App和Hybrid App。我们举几个例子来看看:
·Web App
在微信“发现”里面有一个“购物”入口,点击进去打开的是京东的移动购物页面,这个页面实际上就是一个Web App。支付宝的众多小服务也是Web App,还有“海底捞”在微信中的排号应用,这类App其实就是我们经常在PC上浏览的网页,只不过加入了响应式的设计让它适合在移动端显示和运行,所采用的技术依然是JavaScript、CSS和HTML。相对于其他两种App,Web App具有开发简单、高效,更新灵活、跨平台,大量的网页应用稍作调整即可放在移动端运行。但缺点与优点并存,Web App性能、体验极差(对,是极差),无法使用照相机、系统通知、本地缓存等原生特性。
·Native App
也称为原生App。这种App不是采用JavaScript、CSS及HTML开发,而是使用Objective-C(iOS)或者Java(Android)开发。微信、支付宝、斗鱼TV等都属于这类App,是目前主流的开发方式。Native App具有性能、体验非常良好,组件支持完善、接口丰富等特点。但Native App最大的缺点在于,不能跨平台,有多少个平台就要开发多少个版本,现在主要有iOS和Android两个主流平台,还好Windows Phone已没了踪影。
·Hybrid App
也称为混合式App。Hybrid App看上去像一个 Native App,但实质上 Native技术在这里只是作为一个容器,将 Web App包裹了起来,在容器内部实质上运行的还是网页。 Hybrid App更像是Web App与Native App的混合体。与纯粹的Web App相比,Hybrid App会有一部分访问原生组件(相机、加速器)的能力。事实上,目前主流的应用中,纯粹的原生App很少,绝大多数都属于混合式App。比如,我们常见的京东、淘宝等电商类App,由于商品及业务变化非常频繁,需要经常调整,所以这类App的主要页面都是采用Web技术来构建,只是用Native包装了一下。那我们如何界定,哪些App属于“原生”哪些App属于“混合”呢?答案是:看Web页面在App中所占的比例,如果绝大多数页面都采用Web技术构建,那么我们称为混合式App;而如果只有少数页面采用Web技术,我们称为原生应用。举个例子,今日头条这类新闻应用中绝大多数页面都采用原生技术实现,我倾向于称它为Native App;而对于淘宝、京东等App,更倾向于是Hybrid App。Hybrid App具有接近于 Native App的体验、开发效率高、跨平台等特性。
有一些开发者认为微信服务号里的网页应用也属于Hybrid App,这种说法也不无道理。因为这些网页应用也属于微信这个Native应用的一部分,同样运行在微信内置的浏览器中,但这是一个App所有者的问题。对于微信,确实是Native App中加入了部分“网页”,具有Hybrid App的特点。但我们上面讲到,目前主流App里很少有纯粹的Native App,是不是算作Hybrid App,应该看Web页面在App中的所占比例。微信是一个以社交为主要业务的App,微信中的绝大多数核心社交与聊天功能都是原生的,所以我们还是称微信为Native App。但是,对于服务号应用的开发者,微信并不是开发者开发的,开发者只拥有其服务号。而且服务号应用所用到的所有技术都只局限在Web技术里,从这一点来讲,服务号的应用应该归属于Web App的范畴。
此外,我们说Hybrid App具有一部分可以访问原生设备组件的能力。微信的JS-SDK确实提供了一些如拍照、录音、扫一扫等功能的接口,但相比于其他Hybrid App能调用的原生功能,实在是有限。从这个角度来讲,也应该将这些服务号的应用归属到Web App中。
其实,到底归属于什么并不重要。互联网技术中的概念层出不穷,对很多事物的定义本来就不是很明确。这里用一些篇幅解释3种主流类型的App,是希望大家在对比小程序和其他类型App时,能有一个较完整的知识背景。
那么小程序属于以上3种的哪一种?严格意义上来说,它不属于以上3种中的任何一种,在实现技术上小程序同传统的Hybrid还是有很大的不同的。小程序采用Java Script和CSS这类常见的Web技术开发,但它又不使用HTML,它同Web没有直接的联系。小程序实际上是将一系列自己定义的组件编译成了对应平台(iOS、Android、PC)的相应可运行组件,以提高运行性能。如果一定要将小程序归并到以上3类App中,可能Hybrid App更合适:非原生,但使用到了Web技术(JavaScript和CSS)。
相比于Native App,小程序具有Hybrid App的一些优势:
·跨平台(对于iOS和 Android两个平台只需要开发一套程序)。
·具备接近于Native App的体验(注意只是接近)。
·对原生组件有访问能力。
·具备缓存能力。
·上手容易,开发逻辑较为简单。
同时,小程序还具有一些它独有的特点:
·小程序在设计时就做了很多约定式的规范:比如简单的文件结构、默认的文件命名、内置好的Tab栏与导航栏等,这让小程序的初学者更容易上手和理解。
·开发环境很干净,你无须安装任何除开发工具外的其他软件。当然现在这个工具简陋的可怕,很多常见的IDE功能都不具备,但相比于其他Hybrid App的环境要求,小程序这点真的很棒。
·发布和部署流程非常简单,几乎是“傻瓜式”,点击几下就可以将应用发布到腾讯云。
·小程序之所以在公布后引起了互联网圈儿和开发者们极高的关注度,原因并不在技术上,无数开发者、创业者看中的是微信天然的关系链与获客能力。这也是小程序最大的优势。
但是,世间没有完美的事物,计算机世界里也没有完美的技术,你以为的优势在另一方面却成了缺点。我们一起来看下:
·小程序为了简化复杂性,做了一些UI上的设计规范,确实方便了很多对UI要求不高的应用。但这也限制了那些对UI要求极高的产品发挥。
·小程序很遗憾地不支持现有的HTML DOM结构,而是自己给出了一系列的组件,造就了一个封闭的开发环境,这直接导致了现有的经典Java Scripti框架、类库都无法使用。小程序现在的生态几乎是荒芜一片,等待着开发者们去耕耘(挑战与机遇并存,正因为没有,才有机会)。如果你想用小程序实现一组图形来展现股票或者天气的曲线,目前来看,相当烦琐。你无法使用经典的eckart或者highchart,你只能自己用Canvas来一点点地绘制。
·截至至今,小程序还不支持Web View,这是相当头疼的一个问题。现在很多新闻类型的应用,都是将文章数据静态化成HTML存储在服务器或者是CDN中,然后再利用Web View直接加载这个HTML来显示。不支持Web View直接导致了很多内容型应用没办法加载已存在的大量HTML页面。内容型应用现在大量的静态化页面需要被转化(已有一些第三方的组件实现了HTML转WXML,基本思路是用正则表达式替换HTML,但效果并不能让人满意)。至于微信会不会官方支持,这个很难抉择。不支持Web View对现在的静态化HTML页面是致命的打击;但兼容Web View就意味着在小程序里你还可以运行Web App,而Web App很难去监管,性能体验也不够好,这对于小程序的发展是不利的。也许开放一个只解析CSS不允许运行JavaScript的Web View可能是个不错的选择,微信如何平衡这个问题,我们拭目以待。
·小程序只实现了模板化并没有实现自定义组件,这是最令人不满意的地方。如果我们想实现一个自定义逻辑的组件,通常希望把这个组件的标签、样式以及业务逻辑打包在一起,然后可以放在项目中多个地方使用。外部客户端调用组件时,只需要传入组件所需要的参数,由组件自己来完成数据获取、转化、绑定并和UI层通信等操作。但小程序里的template只能将标签和样式(WXML和WXss文件)提取出来作为一个模板”,却无法把组件的业务逻辑(js文件)放在一起。也就是说,组件的业务逻辑不能够写在组件的模块儿中,只能写在“调用”组件的业务代码中,这就无法很好地复用组件的业务代码。
我们用表格来对比小程序和现在主流App的优劣势。