赤峰职业技术学院
 
当前位置: 首页 > 学习交流

小程序的前世今生:app VS H5 VS 微信小程序

时间:2018年01月13日 19:25   浏览:281   来源:赤峰职业技术学院


原标题:小程序的前世今生:app VS H5 VS 微信小程序

1月9日,小程序正式上线,“微信小程序”的百度指数也坐上了过山车,达到惊人的27万+,是前一天指数的45倍、同一条“微信公众号”指数的7倍之多。

谁想到,高峰就是巅峰。1月9日开始的整整一周内,“微信小程序”的百度指数一直压制着“微信公众号”。但这样的期待也仅仅就持续了这一周,那之后,“微信小程序”的百度指数不断下滑,将近一年时间里再也没有能超过“微信公众号”。

在“微信指数”上,这样的情形也并无不同。

今天系统聊一下小程序,h5页面,app的关系与区别。

2017 年伊始,小程序在猴年的尾巴终于石破惊天。而整个互联网圈也报之以空前的热情关注它,一时间,各种“小程序”讨论群此起彼伏,各路自媒体和行业人士的评论波涛汹涌。然而这种热情似乎只持续了一天。

小程序,这个人们心目中的神和他神一般的团队用了一年磨砺出来的作品,却被人们用一天的热情消融殆尽。

但人们真的了解小程序么?

本文试图解答几个老大难问题:

我们需不需要做小程序,还需不需要做 App?

为什么一定要扫二维码才能使用小程序?

微信到底是不是想做操作系统?

为什么没有小程序应用商店?

小程序是用完即走,还是微信不让你走?

百度”直达号“和”支付宝牌“小程序将何去何从?

本文是连载文章,本次连载内容为第一章《小程序为谁而生》。

第一章 小程序为谁而生

2016 年初,张小龙在微信公开课上宣布微信将推出“应用号”。

时隔一年,2017 年 1 月 9 日,“应用号”以“小程序”的新名称正式推出。

小程序是微信允许开发者在微信 App 上面发布的一种简单应用程序,它可以调用微信的昵称和头像等账号信息,以及微信的一些基本功能,摄像头、录音、地图、扫一扫、支付等功能。

在小程序推出之前,很多人对它并不看好,这很大程度是基于对 H5 性能和体验的质疑。但小程序正式发布后,大家发现它不是一个 H5 的形式,而是以“原生”的体验出现的。

这里首先要解释一下什么是“原生”,什么是“H5”,以及它们的差别。

从原生 App 和 和 H5 说起

所谓“原生”,是英文 native 的翻译。包括微信在内,通常大家讲的 App 都是原生的 App。

严谨地讲,原生的 App 就是软件开发者开发出来,在 iOS、Android 等操作系统上能直接运行的软件应用。

而与之相对应的就是 HTML5,简称 H5,也会被叫为 TouchWeb 或者 Web App,通俗点讲就是为触屏手机设计的网页。

既然是网页,就必须运行在网页浏览器上面。 我们通过下图来了解一下原生 App 和 H5 在系统里面的区别。

在开发 H5 的时候,因为网页跟操作系统之间被隔了“浏览器”这么一层,很多事情已经由浏览器帮忙处理掉了,开发成本就可以降低,开发速度也可以加快。

也因为隔了这么一层,所以原生 App 的一些功能 H5 就实现不了了,运行速度、整体体验就没有原生 App 那么好。

我们再来详细对比一下,原生 App 和 H5 各自的优势、劣势。

上面做了这些对比,简单地概括一下:

1、原生 App 功能强大,体验好,但开发成本高,开发速度慢;

2、H5 功能少些,体验稍差,但开发成本低,开发速度快。

微信改变了什么?

微信小程序就是一个试图综合两者优点、弥补两者缺点的开发平台。而要说小程序,就不得不先说

说微信的“服务号”。请先看图:

这里我们可以看到,相对于普通浏览器,微信给服务号和小程序都提供了“微信公众平台”的一些开放功能。这些能力中比较重要的有:微信登录、微信支付、CRM 系统。

图中的“服务号 H5”跟普通 H5 的区别,就在于它能调用微信公众平台提供的这几个功能。

我们来看看这几个功能的作用是什么?

1 、微信登录

2014 年底,微信开始向第三方开发者提供“微信登录”功能。开发者在自己的 App、网页中加入这个功能后,用户可以用微信账号直接登录进去,而不再需要进行复杂的注册流程。用户完成登录后,开发者可以获取到用户的微信账号资料,如头像、昵称、性别、地区等。

短短两年的时间,这个接口已几乎是主流 App 的必备登录入口了,甚至有不少 App 指定只能通过微信进行登录,完全放弃了自己的独立账号体系。

为什么微信登录这么受欢迎?因为自建账号体系成本高,注册流程成功率低,容易造成用户流失。

对于一个 App(或者 H5)来说,一个新用户刚刚安装并打开 App 时,应该尽快让他完成注册,并体验核心功能。但过往的注册流程容易遇到下面这些问题:

密码太简单不安全,太复杂又容易忘记,这对用户是很大的苦恼,对开发者也是苦恼的事。用户还常常会忘记密码,所以还需要提供“忘记密码”功能,甚至做“安全问题”校验,还要时不时处理用户账号被盗用的情况。这些对开发者来说都是一个耗时耗脑却又不得不做的事;为了安全,开发者们也常要求用户使用邮箱或者手机注册。但邮箱验证需要用户切换 App 去查看邮件,也经常会遇到通知邮件被邮箱判定为“垃圾邮件”的情况,这些都会使得注册流程中断。而手机号注册,发送验证码也经常会有延时,需要用户有耐心等待才行。并且每发送一条验证码短信都需要向运营商交短信费,这对一些用户量比较大的平台来讲也是一笔不小的开支。

而有了微信登录,相当于微信帮开发者做了这些注册流程、身份校验和账号安全保护的工作。用户使用一个新的 App 或者 H5,点一下“微信登录”按钮,就能直接以一个注册用户的身份进入到 App 中去,

正常使用各项功能,这无疑是非常惬意的体验。

2 、微信支付

2013 年 8 月,微信推出“微信支付”功能,而到了 2016 年 9 月,微信支付的市场占有率已达到 38%(易观数据)。

微信支付功能已经成为各个需要支付功能的 App 和移动网页的标配(除了银行系、淘宝系、百度系等竞争对手外)。当然,通常开发者们会同时提供微信支付、支付宝两种支付方式。

在微信支付出现之前,无论在移动端还是 PC 端,开发者们想要让用户完成支付,都是一件非常困难的事。

最原始的办法是让用户去银行汇款,填写收款人账号、开户名、开户行分行支行信息,要确保信息不能填错,还要备注说明身份,汇款完成后再告诉收款人,然后收款人再发货或者提供服务。

这无疑是非常麻烦的过程,后来各个银行有了网银,稍微方便了一点,但还是一样要求用户填写这些复杂的信息。

因为支付难的问题,一些游戏厂商通过线下小店售卖“游戏点卡”,包括腾讯在内的很多网络服务提供商借助电信运营商的付费电话服务进行收费,拉卡拉等厂商甚至设计了可以插在手机上刷银行卡的硬件设备……但显然,这些方案都笨拙了。iPhone 手机出现后,苹果官方为开发者们提供了支付功能,用户填写信用卡信息可以完成支付。但由于中国用户过去没有用信用卡在线支付的习惯,苹果官方又没有做适当的引导和推广,而且连接苹果公司在国外的服务器通常是非常慢且不稳定的,体验不够好,所以这种支付方式也没有推广开来。在微信之前,做得最好的是支付宝。支付宝做了两个创新,第一个是“余额账户”。支付宝试图通过余额账户,让用户把钱留在线上,这件事并不成功。因为对网络的天然不信任,用户不愿意把钱放在支付宝里面。直到 2014 年支付宝找到了“余额宝”这个新的方式,才有所改观。

第二个是“快捷支付”。支付宝用了近十年的时间,终于和各个银行达成合作,推出了“快捷支付”。用户发起支付请求后,银行发送短信验证码给用户的手机,用户在支付平台上输入验证码完成授权,银行和支付平台在用户的银行卡上进行扣款。

同时,支付宝把这种支付能力提供给开发者、线上商店们,也就是成为了“第三方支付”服务商。但是,由于支付宝的支付体系主要服务于淘宝系统本身,对第三方支付的支持并不是很到位,又因为顾虑安全因素而做了大量牺牲体验和便捷性的设置,而用户的在线支付习惯尚未养成,对支付宝安全性也依然不信任……这种种的原因,让支付宝在这安全和便捷的死循环里走不出来。所以中国的第三方支付、移动支付一直没能发扬光大。

在一个开放的软件或者操作系统中集成一个支付功能,甚至打通线上线下的边界,这件事只有微信做成了。借助于支付宝对用户线上支付习惯的教育,借鉴支付宝与银行达成的“快捷支付”合作模式和产品创新,微信又在账号安全上和支付便捷体验上做了很多创新,如微信客户端的安全设备保护、微信支付 6 位密码支付、微信内网页安全保护标识等。又借助跟支付宝之间掀起打车大战、外卖大战、红包大战、线下便利店补贴大战,微信支付完成银行卡绑卡量的质的飞跃。截止 2016 年 6 月,微信支付绑卡用户已经达到了 4 亿。有了微信支付,中国网民的钱才开始流进手机,才开始有了移动电商的真正繁荣。

甚至可以说,没有微信支付的出现,就没有支付大战,没有红包大战,也没有打车大战,没有外卖大战,没有共享经济和上门服务的遍地开花,没有知识经济和付费阅读,没有“互联网+”浪潮的汹涌澎湃和中国 O2O 的繁荣,也就没有我们今天出门不需要带钱包的便利生活。

3 、CRM 系统

CRM,Customer Relationship Management,也就是客户关系管理系统。其价值是负责业务客户的拉新、留存和深度维护,这其中在线客服功能和数据分析功能无疑是最重要的。

微信公众平台给服务号提供了一个简单的 CRM 系统,包括比较简洁的后台数据分析功能、消息推送功能和客服对话管理功能。消息推送是微信的一大优势。微信允许服务商定期向用户推送推广消息(毎月最多 4 次),也可以根据业务需要给用户发送业务消息通知(在微信平台中称为“模板消息”)。通常各个服务商做消息推送的办法有:1、App 推送,2、短信推送,3、电子邮件推送。但这三种办法的“触达率”都不高。因为用户的手机中安装的 App 太多,大量的推送广告已经让用户习惯性忽略,或者干脆将其通知功能屏蔽掉;而现在大部分用户也极少使用短信进行通讯,而短信信箱里面又挤满了垃圾短信,所以短信通知也经常会被忽略;同样的道理,电子邮件就更加容易被忽略了。由于用户的大部分时间都花在微信中,所以相比以上几种推送方式,微信消息的触达率是最高的。有数据显示,微信订阅号的阅读率是 10%,微信服务号的阅读率是 15%,这是非常高的。另外,微信的业务消息通知“模板消息”功能,可以把原本纯靠文字表达的业务通知用通加简洁明了、格式化的方式显示出来。如图所示。

同时,模板消息功能也帮银行等消息推送大户节省了大量发送短信通知的成本。微信的客服对话功能,允许服务商在后台跟用户进行微信对话。在 PC 端网页,提供客服对话的办法通常是使用线上淘宝旺旺、企业 QQ,或者在网页中嵌入临时对话窗口。但在移动端 H5 中,这些办法不再适用了。可用的方式也许就只有手机短信了。但用过手机短信客服的人都知道,需要回复 1、2、3 等数字代码,然后根据下发的通知再回复 101、102 之类的二级代码,至少往复几次才能完成业务办理或者查询流程。而微信提供了“自定义菜单”,服务号开发者可以自定义配置在服务号底部的菜单,把用户常用的操作请求展示出来,这样使用起来就便捷了很多。

当然,微信公众平台对复杂的业务管理是不够的,所以微信把接口也提供给了第三方开发者,电商商家或者是线下门店可以将自己的服务号对接到第三方开发者提供的更全面的 CRM 后台上去。

再小的个体都有自己的品牌

服务号的本质,其实就是三个部分:一个聊天式的操作界面,微信登录/支付/CRM 等功能和后台,一套需要服务商自行开发的 H5 网页。也可以说服务号帮 H5 解决了交易闭环和用户驻留两大问题。对于开发者来讲,服务号让 H5 变成了一个可以替代 App 的解决方案,而且只要更低的开发成本、用户成本。

除了上面三大功能,微信还有两个得天独厚的优势:1、二维码入口;2、用户习惯及用户时间。

1、二维码入口

张小龙说过:PC 互联网的入口在搜索框,移动互联网的入口在二维码。

很多人嗤之以鼻,说因为微信已经占据了二维码这个入口,所以才押宝在二维码。这是颠倒因果了。

微信几乎是从出生到现在,都在不遗余力地推广二维码,从分享二维码名片,到群二维码,到网页版微信

扫码登录,到公众号二维码,到微信扫码支付,再到小程序的二维码入口。

这个道理其实很简单。

举一个例子,我们过去常常在地铁里的广告、海报上看到某某公司网址、客服电话 400-xxx-xxx。但我们作为路边吃瓜的群众,是不可能记住这长长的网址和电话号码的。就算是商家花了巨资去购买短小好看的域名、吉祥顺口的电话靓号,我们依然记不住。

后来有了微博,似乎好了一点了,商家开始在海报上加上微博主页网址,还有“官方微博:@XXXXX”的字样,期望用户能顺手掏出手机,关注一下微博。其实这也是一厢情愿。

再后来有了自己的 App,商家们又想到了一种“更靠谱”的办法:App 二维码。用户打开手机扫一扫海报上的二维码就能下载他们的 App 了。

显然这是更加不靠谱的方案:安装一个 App 对用户来说,是一个非常“重”的决策。况且有多少用户会在信号不好的地铁里、马路边,停下脚步去消耗流量扫描二维码,并下载一个至少几十 M 的 App 呢?

一直要等到微信公众号的出现,商家们才真正解脱了。

从此海报上、广告里,不需要再出现长长的网址和电话,只需要给出一个公众号二维码。用户如果感兴趣,扫描一下二维码关注公众号,回去可以慢慢看,可以在公众号里下单、查询,或者根据引导去下载商家的 App。这个过程用户不需要消耗多少流量,也不会有什么心理压力。微信培养了我们非常强的一个认知,看到二维码,你就会想到要用微信来扫一扫。

支付宝也是很早就在推广“二维码支付”的。后来因为微信强力推广二维码,支付宝就想搞差异化,主推“声波支付”——咻一咻,结果发现推广不起来,又调转枪头回到二维码战场上。但是此时微信已经在用户心智中种下了“二维码要用微信扫一扫”的意识了,常常出现用户用微信去扫描支付宝的各种线下业务二维码的情况。这显然非常尴尬,用微信是识别不出支付宝的业务专用二维码的。所以从这个角度上讲,张小龙的话要改一改,移动互联网的入口不是“二维码”,而是“微信的扫一扫”。

2、用户习惯及用户时间用户习惯是一个非常可怕的东西。微信的用户不只拥有“用微信扫二维码”的习惯,随着微信的深入人心,我们还养成了至少以下这些习惯:

起床第一件事是看微信消息;

睡前要打开微信翻一翻;

看到红点就想点掉;

看到有人拉群就想加进去看一看;

习惯了用语音聊天(要知道在几年前,我们拿着手机在嘴边说语音都觉得别扭的);

有事问万能的朋友圈,或者万能的群,简称万圈和万群;

看到朋友的朋友圈习惯性点赞;

看到有趣的事,或者自己觉得脸上有光的事,就想拍照发朋友圈;

进群发红包,看见红包就习惯性飞快去点开;

看到好的文章,秒转朋友圈;

……

因为对朋友圈的过度依赖,我曾经深感自责,并把微信中的朋友圈功能删除掉。在此后的一周里,每天我都会无数次无意识地点击进入扫一扫——那此前正是朋友圈的入口位置。

这是多么强大的用户依赖,大概只有烟瘾和“买买买”可以与之匹敌吧。

而从我上面提到的支付宝声波支付,还有很多其他的酷炫的技术,如 NFC、iBeacon、银联闪付、Apple Pay 的推广不成功,都反向证明了形成用户习惯是多么有价值。微信官方数据显示,2016 年 9 月份日均登录微信的活跃用户超过了 7.68 亿,其中 50%的用户每天使用微信超过 90 分钟。而又有统计显示,中国用户每天使用手机的时长中,有 70%以上的时间是在使用微信。甚至对很多小白用户来讲, 手机约等于微信。

而微信还有特别强大的一点,它成功地让“高端人士”和“老龄人”都活跃到了这个平台上,这是 QQ 过去用了十几年都没有做到的事。

所以很多开发者的用户群完全是微信用户的“子集”。对于他们来讲,在微信之外做个 App,就不如在微信之内开发一个微信第三方应用,用户在哪里,用户的时间花在哪里,就要跟到哪里去。

于是服务号一出现, 服务商蜂拥而至。

一时间,各种微商、微店,群雄并举,攻占了朋友圈和各大微信群。

而在 2014 年开始的 O2O 浪潮中,大量的新服务商开始把产品的主战场放在微信中,开发自己的服务号,很多人甚至都不开发或者不再维护自己的独立 App 了。服务号广泛应用在出行、购物、餐饮、医疗、旅游等领域……甚至连佛祖都用微信服务号代替功德箱了。

就如微信公众平台的官方口号:再小的个体,也有自己的品牌。

不敢想象,如果没有服务号大大降低了开发成本和用户成本,过去一两年这些“互联网+”的应用是如何能够百花齐放的?

小程序为谁而生?

小程序是为了弥补服务号的不足而设计的。

2016 年初张小龙在宣布“应用号”(小程序前身)的设想时,是这样说的:“我们开发公众号不是为了媒体,我们的本意不是传播内容,我们要提供服务,但服务号没有达到预期,我们在讨论一个新的形态,叫应用号。平时不发东西,他安静的存在在那,低频的需求不需要安装 App,微信尝试让更多 App 以轻量

便捷的形态在微信中存在,就是应用号。”

小程序 vs 服务号 vs 订阅号

《微信小程序平台运营规范》第一句就是:微信最核心的价值,就是连接——提供一对一、一对多和多对多的连接方式,从而实现人与人、人与智能终端、人与社交化娱乐、人与硬件设备的连接,同时连接服务、资讯、商业。我们可以理解为,微信最初的聊天功能就是一个连接人与人的工具,而朋友圈和微信群则是连接人与社交化娱乐的工具。订阅号是定位于连接资讯的工具,服务于媒体。 在资讯内容方面,微信团队做了原创保护、文章赞赏、辟除谣言等努力和尝试,已经当之无愧地成为中国最好的内容发布平台。而服务号,曾经被赋予了连接人与智能终端、硬件设备、服务和商业的职能。但很明显这对于它来

讲,是过度赋能的。

服务号存在的不足,我总结了一下,大致有以下几点:

服务号在微信中,是跟其他聊天信息排列在一起显示的,并不像操作系统里的 App 一样有固定的位

置,这样找起来会比较麻烦,只能通过搜索;

微信对服务号的定位是服务,但服务号的主体功能只能使用 H5 进行开发,不能像原生 App 一样有流畅的用户体验;

服务号在下发推送后,会占据用户的聊天列表,容易造成过度骚扰。这也导致了不少服务号一发消息推送就会掉粉。但其实取消关注的用户未必以后就不需要这个服务号,只是他们受不了这种骚扰而已;

因为服务号的文章推送功能和扫描二维码可以关注的机制,不少公众号会利用标题党或者朋友圈病毒营销的方式去吸取粉丝,造成朋友圈里刷屏,这违背了微信平台做服务号的初衷。

小程序基本都围绕着优化这些点在做设计。更宏观点来看,小程序、服务号和订阅号三者的差异,其实只是在”开发权限多样性”、“推送频次”、“推送显眼度”这三者上面做一个不同的平衡考量罢了。

如下图所示:

此消彼长,这个世界上没有完美的方案,所有的设计考虑都不过是生态全局上的一个综合考量结果。

也就是说,小程序被赋予更多的开发权限,所以必然就会被限制住其推送频次和推送显眼度,否则在微信开放生态的全局中,它的存在就不合理了。

小程序的优化我们从小程序的设计思想上,可以看到它跟 H5 有很多相似之处。比如:

寄生在浏览器或微信之上,都是靠一个特定的入口打开(网址或二维码),无需下载和安装;

用完即走,几乎不占用户的存储空间,也不驻留后台;

在开发上,都是前端开发的方式,成本低,速度快,且一次开发可以兼容所有的平台。

同时它也“继承了”服务号所具有的微信登录、微信支付、CRM 管理等功能。

而相对于服务号,小程序做了什么优化呢?

1、提供了一个固定的入口:

微信在“发现”页面为小程序提供了一个入口,用户可以在这个地方找到他使用过的所有小程序。这些小程序会按照最后一次使用的时间倒序排列,越晚使用的小程序排在越前面。这样,用户能很方便地找到最近使用的那些小程序。

2、提供了类似于原生 App 的体验:

相对于服务号打开之后先显示一个对话框,需要用户进行点击才能进入到业务界面,小程序的界面本身就跟 App 无异,流程更直接,开发的自由度也会更大。而小白用户也更容易理解。

小程序可以调用系统接口,如摄像头、重力加速器、GPS、电话、录音等。也可以访问和存储本地文件,但有大小限制(上传的程序包体积不能超过 1M,在用户手机中缓存大小不能超过 10M,永久存储不能超过 10M)。

而不需要连接服务器的小程序,还可以在没有网络的情况下离线使用,并能记住上一次使用最后停留的页面。这个特性很适合各种工具应用,这是所有 H5 都没法做到的。

3、限制推送消息:

小程序关于消息通知推送的限制是这样的:如果用户在该小程序中有支付或者提交表单的动作,那么开发者可以在 7 天之内向他推送有限条模板消息(每发起 1 次支付或提交表单的动作,可以下发 1 条消息,多次动作可以推送多条);

关于客服消息回复的限制:如果用户进入客服窗口,则小程序运营者在 1 分钟内可以向他发送 1 条消息,超时了就不能再次发送;如果用户在客服窗口内发送了消息,则运营者可以在 48 小时内向他回复 3条消息。

可以看出,这是比服务号严格很多的限制。服务号并没有限制推送模板消息的时间,也没有明确限制推送模板消息的数量。

更关键的是,服务号每个月可以推送 4 次推广文章,而小程序并没有这个能力,需要静静地等待用户来唤醒它,或者用户在线下场景需要它时,才扫描二维码来找到它。

小程序 s vs 原生 App vs H5

小程序 VS AP

一、下载

App 从应用商店(如 App Store)里下载;

小程序 通过微信(扫描二维码、搜索)直接获得;

二、安装

App 安装在手机内存中,就像自己买了辆车放在车库里随时开;

小程序 不需要安装,就像免费用嘀嘀打车,召之即来用完拜拜;

三、占用空间

App 会一直存在手机中占用空间,太多的 App 可能会导致内存不足;

小程序 因为不需要安装,占用内存空间忽略不计;

四、广告骚扰

App 会隔三差五给用户骚扰广告,太多未读提示会逼死强迫症;

小程序 不允许主动给用户发送广告,仅能回复模版消息 ;

五、机会

App 市场已经饱和,几乎所有的领域都已经被覆盖;

小程序是一片蓝海,在新的使用场景下有很多瓜分蛋糕的好机会;

六、开发

App 需要适配市场上很多款的主流手机,开发成本大;

小程序 一次开发就可以自动适配所有手机;

七、发布

App 需要向十几个应用商店提交审核,且每个应用商店要求的资料都不一样,非常繁琐;

小程序 只需要提交到微信公众平台审核 ;

八、用户群

App 面向所有智能手机用户,截止2015年约19亿台;

小程序面向所有微信用户,约9.38亿人 ;

九、开发周期

根据博大软件十三年的开发经验,一款完善的双平台 App 平均的开发周期约3个月;

小程序 平均开发周期约2周,仅为App的六分之一;

十、功能

App 可以实现完整功能 ;

小程序 仅限微信提供的接口功能;

十一、推广难度

App 需要用户主动下载十几M的程序包,在没有Wi-Fi的情况下推广艰难;

小程序 可以通过二维码、微信搜索等方式直接获得,推广难度**降低;

十二、总结

App 和 小程序 是两种很像却又不一样的技术。

一种是已经流行8年的成熟技术,它创造了无数的独角兽公司;而另一种是正被赋予期待的新技术,在这片蓝海中,风险与机会都旷阔无边。

所以,就两种技术而言,并没有哪个更好,只是看哪个更适合你。

1) 体验感强,无需下载

2) 开发成本低,APP开发成本太高

3) APP运营成本高

4) APP获取流成本高

APP

小程序

下载

从应用商店(如 App Store)里下载

小程序 通过微信(扫描二维码、搜索)直接获得

安装

安装在手机内存

无需安装,用完即走

占用空间

一直存在手机中占用空间,太多的 App 可能会导致内存不足

不需要安装,占用内存空间忽略不计

机会

市场已经饱和,几乎所有的领域都已经被覆盖

小程序是一片蓝海,在新的使用场景下有很多瓜分蛋糕的好机会

开发

需要适配市场上很多款的主流手机,开发成本大

一次开发就可以自动适配所有手机

发布

需要向十几个应用商店提交审核,且每个应用商店要求的资料都不一样,非常繁琐

只需要提交到微信公众平台审核

用户群

面向所有智能手机用户,截止2015年约19亿台

小程序面向所有微信用户,约9.38亿人

开发周期

一款完善的双平台 App 平均的开发周期约3个月

平均开发周期约2周,仅为App的六分之一

推广

需要用户主动下载十几M的程序包,在没有Wi-Fi的情况下推广艰难

可以通过二维码、微信搜索等方式直接获得,推广难度降低

小程序 VS 公众号

订阅号,以内容为主体,适合经常给用户群发消息的产品,例如媒体。目前做的比较多的KOL大号,以及一些自媒体。

服务号,以提供服务为主,比较适合做低频次(用的次数较少)使用。

企业号,拥有较强的组织架构,和隐蔽性,适用于制作内部企业CRM系统。

而小程序,放弃了传统公众号的关注、群发、分享到朋友圈功能,而在设计规范、产品体验、运营规范、都有自己的一套审核标准,旨在培养产品本身。小程序是无法分享到朋友圈的,但是发给好友和群是可以的。

公众

程序

1

语言

H5

独立(XML+JS) 趋势走向 微信平台是后盾,支付宝还没出来,需求度很大 和公众号比较广告推广,做的越早点击量越多

2

吸粉

不需要吸粉(独立排行)

3

限制

不限制(可修改)

4

数据

不实时上报

实时上报

5

接口少

接口多

小程序 VS H5

 微信小程序和h5区别:

第一条是运行环境的不同。

传统的HTML5的运行环境是浏览器,包括webview,而微信小程序的运行环境并非完整的浏览器,大家注意,我这里写的是“非完整的浏览器”,有以下几个原因:

小程序的开发过程中会用到HTML5相关的技术(并非全部)

小程序最后的发布上线需要微信审核,微信在不更新自身软件的情况下可以将小程序更新到自身软件内,这就联想到了ReactNative框架,并且已经有开发者在微信小程序的开发工具源码中发现使用了React和NodeWebkit库

官方文档中着重强调了脚本内是无法使用浏览器中常用的window对象和document对象(基于这一点,像zepto/jquery这种操作dom的库就被完全抛弃了)

所以我个人认为,小程序的运行环境很有可能是微信开发团队基于浏览器内核完全重构的一个内置解析器,针对小程序专门做了优化,配合自己定义的开发语言标准,提升了小程序的性能。

不过由于微信给开发者提供了开发工具,而开发工具中也内置了编程、调试、开发环境、发布于一身,我们也不用再探讨它的最终运行环境了,只要按照官方文档进行开发就可以了。并且从微信团队给开发者提供开发工具这一举动,让我联想到了苹果给开发者提供的X-CODE开发工具,可以想象微信的“野心”可见一斑。

第二条是开发成本的不同。

这里我提出了一个问题,当我们面对一个HTML5web开发需求时,我们需要考虑什么呢?抛去开发工具(vscode、sublimtext、Atom等)不谈,大到前端框架(Angular、react、vue、backbone等)、模块管理工具(Webpack、Browserify等)、任务管理工具(Grunt、Gulp等),小到UI库选择、接口调用工具(ajax、FetchApi等)、浏览器兼容性等都要我们一一考略,再不济用jqery插件写H5,也要在开发过程中去寻找合适的jquery插件来配合项目。

尽管这些工具可定制化非常高,并且提高了开发者的开发效率,但我相信项目开发的配置工作已经消耗了不少精力,尽管大部分开发者都有自己的配置模板,但长久以来对于项目中使用的各种外部库的版本迭代、版本升级所产生的成本应该也不低。

而当我们面对一个微信小程序的开发需求时,我们需要考虑什么呢?微信团队提供了开发者工具,并且规范了开发标准,前端常见的HTML、CSS变成了微信自定义的WXML、WXSS,WXML中尽管全部是自定义标签,但官方文档中都有明确的使用介绍,相信上手应该是非常容易的;WXSS、JSON和JS文件中的写法稍有限制,但整体相差不多。

在统一了这些标准之后,作为一个开发者,你会发现,自己只要专注写程序就可以了:

当需要调用后端接口时,调用发起请求API

当需要上传下载时,调用上传下载API

当需要数据缓存时,调用本地存储API

引入地图、使用罗盘、调用支付、调用扫码等等功能都可以直接使用

UI库方面,框架自然带有自家weui库加成

并且在使用这些API时,你不用再去顾虑浏览器兼容性,不用担心生产环境中出现不可预料的奇妙BUG,可见微信小程序的开发成本确实相比以往的web开发低很多。

第三条是获取系统级权限的不同。

微信小程序相对于HTML5web应用能获得更多的系统权限,比如网络通信状态、数据缓存能力等,这些系统级权限都可以和微信小程序无缝衔接,也就是官方宣称的拥有NativeApp的流畅性能,而这一点恰巧是HTML5web应用经常被诟病的地方,这也是HTML5的大多应用场景被定位在业务逻辑简单、功能单一的原因。

第四条便是应用在生产环境的运行流畅度。

这条无论对于用户还是开发者来说,都是最直观的感受。长久以来,当HTML5应用面对复杂的业务逻辑或者丰富的页面交互时,它的体验总是不尽人意,需要不断的对项目优化来提升用户体验。

但是由于微信小程序运行环境独立,尽管同样用html+css+js去开发,但配合微信的解析器最终渲染出来的是原生组件的效果,自然体验上将会更进一步。

H5页面由于无法被单独沉淀用户(无法直接关注),一般都是配合公众号或者APP(html5打包APP)的产品形态

某些平台制作生成的小程序,功能体验、开发速度等介于原生、Html5和小程序之间,取得了一个较好的平衡。并且免除了服务器以及运维人员的成本,非常适合非技术人员的产品首选。

在留存和唤醒上,APP可以常驻内存、通过其他方式唤醒(网页/其他APP)、全屏带图片的通知提醒、弹窗等等多种手段,故更容易提高留存,也更容易唤醒用户。

小程序 VS微店

微店

小程序

流量入口

公众号菜单、朋友圈、微信群

附近的小程序、统一的小程序入口、搜一搜、公众号图文推送、公众号菜单、朋友圈(太阳码)、微信群、支持长按二维码识别、支持发会员卡券(官方的)、支持会员卡直接打开小程序

推广

类似图文的转发效果,容易被忽略

小程序推送到聊天界面(群or个人),自带广告橱窗,展示的界面非常吸引人

搜索

不能搜索到

用户可在微“搜一搜”搜索

留存

关掉就找不到了

点击留存、领券留存、扫一扫留存、付款留存

小程序莫名其妙?

关注莫名奇妙小程序!

扩展阅读

餐饮行业小程序完美方案!

深度好文!实体对小程序的态度分析

吃饭还玩手机?那就陪你玩到底——餐饮行业小程序解决方案

玩的就是文艺——为你朗诵!

张小龙与微信,微信与小程序的“父子”关系返回搜狐,查看更多

责任编辑:


分享到:

 
相关资讯