有了微信公众号为什么还要做微信小程序呢?

发表日期:2017-08-16文章编辑:善微科技浏览次数:2800 标签:    

有人说小程序是原生应用,不知道是现在什么立场这样说的,微信内嵌web view 控件,本质上就是一个定制化的web浏览器,与普通浏览器相比只是增加了一些丰富的内部交互,比如可以轻松用户信息等等,虽然站在前端的角度,小程序和H5应用有一点区别,但是虚拟机永远是虚拟机,跟原生永远差了一个解释执行的鸿沟。还提到了自更新,只要你是基于HTTP协议的那就是古老的HTTP REQUEST 和 RESPONSE方式,没有什么值得吹捧的。如果答主稍微对Native了解深一点,可能就会拿application stream来说了,这才是目前解决Native程序分发方式的一大方向,ctrix 有application 虚拟化,Google有dynamrio,微软有drawbridge,这些技术含量可比react或者codepush技术含量高多了。一个是接近OS级别的革新,一个是虚拟机里面的优化,层次高低,技术深度不言自明。虚拟机永远是虚拟机,玩不出花来。不过如今的CPU架构也是发展了几十年而没有大的改变,这也制约了native程序的基本运行原理。-----------------技术上没什么区别,但是在意义上小程序是腾讯实现“成为互联网的水和电”这一企业愿景的坚实而正确的一步。很普通的技术,但是放到腾讯的平台中,都可以因为量变引起质变。比如公众号,其实就是增加了主动Push的RSS订阅一样的技术。应该没有什么下载不下载,最多是给你在手机桌面添加一个自定义scheme的hyper link的快捷方式,打开以后也是直接切换到微信内置的Webview控件。


 

首先明确几个概念:

Runtime,运行时环境。

所谓 runtime 就是能够运行我们写的代码的代码。说来很绕,理解起来很简单——我们写的代码是要运行在一个特定的环境中的,这个环境负责具体执行代码所表示的指令,也就是说代码最终能有什么样的能力、能实现什么样的效果,不取决于怎么写,而取决于 runtime 怎么理解和执行。

比如,你用 console.log('Hello World'); 想在控制台里输出「Hello World」,如果 runtime 就是要把「Hello World」转换成「Vote for Trump」你也没有任何办法。HTML,特指符合 W3C HTML Specification 的标记语言,包括 4.01、5、5.1 等等众多版本。并不是用「< 」和「>」符号包起来的就都叫 HTML,比如 <吃饭></吃饭>。CSS,特指符合 W3C Cascading Style Sheets Specification 的样式描述语言,包括 Level 1、2、3、4 等众多版本。网页技术、web 技术——随便怎么叫,特指用 JavaScript、HTML、CSS 几种技术构建应用,最终运行在「浏览器」这个特定 runtime 中的技术。浏览器(中的 JavaScript 引擎)和 Node.js(中的 JavaScript 引擎) 都只是 runtime 的一种——它们决定了我们的 JavaScript 代码能做什么,有什么样的能力供我们使用。window.alert('Hello World') 就只有浏览器能理解,同样 require('fs').readFile('/'); 也只有 Node.js 能明白是什么意思。微信小程序是众多实现了 JavaScript(MAYA、3DS MAX、Nginx 以及某些游戏引擎也有) runtime 的环境中的一种。浏览器作为一个 runtime 的另一个重要特点是有 UI 绘制和用户交互行为的捕获能力——(曾经)只有浏览器能识别用 HTML 和 CSS 描述的 UI 结构和样式,并捕获用户的输入传递给 JavaScript 进行相应的处理。小程序也有 UI 绘制和用户交互行为的捕获能力,但严格来讲,它并不能识别 HTML 和 CSS,对应的,它使用 WXML 和 WXSS 两种标准来解释标记语言和样式描述,而标准由微信小程序自己制定。HTML 和 WXML 有交集、CSS 和 WXSS 有交集,但他们是不同的。Runtime 能理解我们写的标记语言、样式描述和业务代码了,接下来需要去执行它们。而问题里提到的当年 Facebook 的客户端,使用的是 Hybrid 解决方案——就是在平台原生应用的外壳里嵌入一个 webview,它能提供基于 HTML、CSS 和 JavaScript 这些技术构建的应用所需的 runtime,因为它其实就是一个阉割的浏览器,不提供前进后退按钮、书签管理等等,只提供运行环境和绘制 UI 的能力。Hybrid 解决方案继承了所有 web 技术的优点——跨平台、易维护、易部署和开发成本低等,同时也继承了所有缺点,而其中最为人诟病的缺点就是——安装包体积大(由于兼容性问题,很多应用不想使用用户设备自带的浏览器环境,而选择打包一个浏览器核心在自己安装包里),以及 UI 绘制效率低。严格来讲,所有最终放弃 Hybrid 解决方案的公司,都不是由于过分相信 HTML 5 和 JavaScript,而是对移动设备上的浏览器的核心部分(webview)的性能,特别是 UI 绘制性能,过分乐观了。时间推移到 2015 年前后,开始出现了以 ReactNative 和 Weex 等技术方案为代表的新型技术解决方案,而小程序单纯从技术实现角度来讲,同这些技术方案差异不大——提供 JavaScript 的 runtime,用某种同 HTML 相似的结构化标签语言来描述 UI 结构,用某种类似 CSS 的语言来描述 UI 样式,然后将这些代码直接绘制为原生 UI。这个过程中已经没有 webview 什么事情了,所以微信小程序并不是我们平时所说的 web 技术,他们只是使用一样或类似的语言而已(总不能说在 MAYA 里写 JavaScript 脚本也叫 web 开发吧?)。客户端开发的核心是通过 runtime 来调度和控制 runtime 之下的平台能力,浏览器这个 runtime 下面的平台是操作系统(Windows、macOS、iOS、Android、*nix 等),而小程序这个 runtime 下面的平台是微信,这是二者的本质区别。再说下载。以前,网页的所有内容必须要先下载再执行,而近些年浏览器提供了离线缓存的相关功能,让网页应用的非数据部分可以离线使用,但这样会把问题复杂度直接拉成指数级提升——以前默认所有东西都要连网才能使用,现在要区分哪些可以连、哪些必须连、连上怎么处理、连不上怎么处理、要缓存的话缓存策略怎么设置,产品和技术上面临的问题都太多,收益也未必有多大,如果离线使用是刚需还不如索性直接做 app,所以浏览器内的离线应用发展一直不温不火,但如果你真心想做,还是可以实现首次下载后再次使用速度得到质的提升的。所以问题描述的慢,下载慢并不是症结,UI 绘制慢、交互响应慢(得益于 JavaScript 引擎本身的性能提升,连 JavaScript 执行都不是瓶颈了,但占用 UI 线程导致整体卡顿是另外一个话题)才是根本问题,而这是浏览器本身的实现原理导致的。小程序也需要在首次加载的时候把应用相关的代码(当然资源大小可能有差异)下载下来,这同网页没区别,而性能的提升体现在后面同 UI 相关的效率上,从这个角度讲也不是什么新鲜事儿了,ReactNative、Weex 都是类似的原理和诉求。

所以需不需要下载,并不是两种技术之间相比在性能上的主要差异。小程序的价值不是在技术上,而是在能否通过它来 leverage 整个微信生态及附属其上的相关资源。这就要涉及到小程序作为 runtime 到底给接入商提供什么样的能力、多大程度的把微信生态的资源暴露给开发者、入口位置、限制上等等,这就取决于微信自己的生态策略了。浏览器作为开放标准的中立技术,厂商对生态的控制其实非常有限,因为大家不希望互联网的入口被某一家商业公司所完全掌控,这是为什么当年微软选择在操作系统捆绑 IE,也是为什么会被起诉垄断。作为开发者,(大多数情况下)不需要考虑用户用什么浏览器,因为各品牌的浏览器(通常情况下)遵循同样的标准。过去十几年不停有公司想基于浏览器做封闭的生态和标准,比较成功的也就只有 UC 一家了,但是大家可以问下作为 web 开发者对 UC 浏览器的平价是如何的 =。=...强化微信的「入口」能力才是小程序的野心。入口就是个门,既然是门就是双向的——作为用户,从什么途径获取到我需要的信息/服务(从哪扇门进去?)?作为内容/服务提供商,从什么途径能够接触到我的目标和潜在用户(在哪扇门后等候或者直接出去?)?

目前从官方发布的信息来看,微信描绘的图景对于用户确实还是很美好的,装了微信,扫下二维码就可以方便的交水电费;而对于服务商,现在还看不到太多的好处,没有高曝光的入口,不能推送等等,直接限制了服务商 touch 用户的能力,但如果你天然是个自带流量的大 V 服务商,小程序能提高现有流量在某些场景(现在看线下可能是主要)的转化率,则是能马上实现的,但想从微信的生态拿流量可能就没那么简单,微信成貔貅把大 V 流量都转化成自己的倒是很有可能。有微信全球 7 亿月活的用户(2015 年底数据)资源,至于是不是基于所谓的 web 技术来实现,who cares?

=========补充一下关于小程序最终使用 webview 渲染的事情。目前的小程序最终还是使用 webview 渲染,这是之前表述不严谨的地方。而我所说的 runtime 差异,是指开发者的运行环境依赖于什么。小程序的环境,就是开发者所能接触到的最底层环境,开发者只依赖小程序给大家提供的环境。而这个环境再下层如何处理,并不受开发者控制,也没有任何办法 access,这意味小程序的开发并不依赖 webview,开发的目标平台也不是 webview。

这样实现的原因,可能有很多,比如综合考量研发成本和收益、最大化利用现有技术等等。而可能性同样很多,比如他可以随时把渲染换成原生 UI,而不需要现有的接入商做任何调整。无论开发体验多像浏览器,它都不是浏览器,即使它现在最终使用 webview 来渲染,开发者同这个 webview 中间还是有个中间件的,就像你不能说我在一个跑在 Windows 上的浏览器里做 web 开发就是在做 Windows 开发一样。它是微信自己规定的一个新环境,只能同微信允许访问的资源互动。

二十几年 web 开发所积累的经验,能复用到其中的除了语言层面之外,并不多,当然目前它的复杂度也不高。只要它定义好的 API、标准不变,作为 runtime 如何理解、执行就同开发者无关,更重要的是我们无法控制。WXML 转成 HTML 再给 webview 渲染,这是 runtime 的行为,对开发者是透明的。

某个版本如果把 WXML 直接绘制成原生 UI 了,他不说用户和开发者可能都是无法感知的事情。


如没特殊注明,文章均为善微网络原创,转载请注明来自https://www.sanways.cn/news/378.html