西安微信小程序和网页版程序的区别在哪里？

西安微信小程序和网页版程序的区别在哪里？下面我们就来一起了解一下西安微信小程序和网页版程序的区别在哪里。以下就是西安微信小程序和网页版程序的区别，希望对您有所帮助。

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