小程序技术发展历史

时间 2019-11-10

原文原文链接

1.2.1 小程序技术发展历史

从技术的维度看，小程序并不是凭空冒出来的一个概念。当微信中的 WebView 逐渐成为移动 Web 的一个重要入口时，微信就有相关的 JS API 了。javascript

一些开发者应该对下面的代码有印象：前端

代码清单1-1 使用 WeixinJSBridge 预览图片java

WeixinJSBridge.invoke('imagePreview', {
    current: 'http://inews.gtimg.com/newsapp_bt/0/1693121381/641',
    urls: [ // 全部图片的URL列表，数组格式
        'https://img1.gtimg.com/10/1048/104857/10485731_980x1200_0.jpg',
        'https://img1.gtimg.com/10/1048/104857/10485726_980x1200_0.jpg',
        'https://img1.gtimg.com/10/1048/104857/10485729_980x1200_0.jpg'
    ]
}, function(res) {
    console.log(res.err_msg)
})

这是一个调用微信原生组件浏览图片的JS API，相比于额外引入一个JS图片预览组件库，这种调用方式显得很是简洁和高效。小程序

实际上，微信官方是没有对外暴露过如此调用的，此类 API 最初是提供给腾讯内部一些业务使用，不少外部开发者发现了以后，依葫芦画瓢地使用了，逐渐成为微信中网页的事实标准。数组

2015年初，微信发布了一整套网页开发工具包，称之为 JS-SDK，开放了拍摄、录音、语音识别、二维码、地图、支付、分享、卡券等几十个API。给全部的 Web 开发者打开了一扇全新的窗户，让全部开发者均可以使用到微信的原生能力，去完成一些以前作不到或者难以作到的事情了。浏览器

一样是调用原生的浏览图片，调用方式如代码清单1-2所示。缓存

代码清单1-2 使用 JS-SDK 调用图片预览组件安全

wx.previewImage({
  current: 'https://img1.gtimg.com/10/1048/104857/10485726_980x1200_0.jpg',
  urls: [ // 全部图片的URL列表，数组格式
    'https://img1.gtimg.com/10/1048/104857/10485731_980x1200_0.jpg',
    'https://img1.gtimg.com/10/1048/104857/10485726_980x1200_0.jpg',
    'https://img1.gtimg.com/10/1048/104857/10485729_980x1200_0.jpg'
  ],
  success: function(res) {
    console.log(res)
  }
})

JS-SDK是对以前的 WeixinJSBrige 的一个包装，以及新能力的释放，而且由对内开放转为了对全部开发者开放，在很短的时间内得到了极大的关注。从数据监控来看，绝大部分在微信内传播的移动网页都使用到了相关的接口。微信

JS-SDK 解决了移动网页能力不足的问题，经过暴露微信的接口使得 Web 开发者可以拥有更多的能力，然而在更多的能力以外，JS-SDK 的模式并无解决使用移动网页遇到的体验不良的问题。网络

--注：JSSDK的问题是体验不良。（对于产品型公司（或者一些大公司）来讲，因为用户众多，用户体验是产品很是重要的一方面)

用户在访问网页的时候，在浏览器开始显示以前都会有一个的白屏过程，在移动端，受限于设备性能和网络速度，白屏会更加明显。咱们团队把不少技术精力放置在如何帮助平台上的Web开发者解决这个问题。所以咱们设计了一个 JS-SDK 的加强版本，其中有一个重要的功能，称之为“微信 Web 资源离线存储”。

如下文字引用自内部的文档（没有最终对外开放）：

微信 Web 资源离线存储是面向 Web 开发者提供的基于微信内的 Web 加速方案。

经过使用微信离线存储，Web 开发者可借助微信提供的资源存储能力，直接从微信本地加载 Web 资源而不须要再从服务端拉取，从而减小网页加载时间，为微信用户提供更优质的网页浏览体验。每一个公众号下全部 Web App 累计最多可缓存 5M 的资源。

这个设计有点相似 HTML5 的 Application Cache，但在设计上规避了一些 Application Cache的不足。

在内部测试中，咱们发现离线存储可以解决了一些问题，可是对于一些复杂的页面依然会有白屏的问题，例如页面加载了大量的 CSS 或者是 JavaScript 文件，这些文件的执行时间占用了大量的 UI 线程，这种时候，即便经过离线存储快速的加载资源，可是依旧会有页面的白屏现象，同时这样分文件的 Cache 在处理代码文件更新的时候操做较为繁杂，对开发者的要求较高。

除了白屏，影响 Web 体验的问题还有缺乏操做的反馈，主要表如今两个方面：页面切换的生硬和点击的迟滞感。

对于一些有经验的 Web开发者而言，会使用一些 SPA 的框架，来模拟客户端原生的页面切换过渡。一般的方式是在一个 WebView 中去模拟多个页面，经过 CSS 处理，加之精细化的脚本代码作到点击反馈和页面切换，得到较好的体验。然而并非全部的开发者都有足够的时间和精力来使得页面的体验变得出色。

微信面临的问题是如何设计一个比较好的系统，使得全部开发者在微信中都能得到比较好的体验。这个问题是以前的 JS-SDK 所处理不了的，须要一个全新的系统来完成，它须要使得全部的开发者都能作到：

- 快速的加载

- 更强大的能力

- 原生的体验

- 易用且安全的微信数据开放

- 高效和简单的开发

这一系统就是本书中须要详细阐述的小程序。

1.2.2 小程序与普通网页开发的区别

小程序的主要开发语言是 JavaScript ，因此一般小程序的开发会被用来同普通的网页开发来作对比。二者有很大的类似性，对于前端开发者而言，从网页开发迁移到小程序的开发成本并不高，可是两者仍是有些许区别的。

网页开发渲染线程和脚本线程是互斥的，这也是为何长时间的脚本运行可能会致使页面失去响应（这个是根本缘由），而在小程序中，两者是分开的，分别运行在不一样的线程中。网页开发者可使用到各类浏览器暴露出来的 DOM API，进行 DOM 选中和操做。而如上文所述，小程序的逻辑层和渲染层是分开的，逻辑层运行在 JSCore 中，并无一个完整浏览器对象，于是缺乏相关的DOM API和BOM API。这一区别致使了前端开发很是熟悉的一些库，例如 jQuery、 Zepto 等，在小程序中是没法运行的。（因为没法操做DOM，如何解决这个问题，新的技术架构带来什么问题。）同时 JSCore 的环境同 NodeJS 环境也是不尽相同，因此一些 NPM 的包在小程序中也是没法运行的。

网页开发者须要面对的环境是各式各样的浏览器，PC 端须要面对 IE、Chrome、QQ浏览器等，在移动端须要面对Safari、Chrome以及 iOS、Android 系统中的各式 WebView 。而小程序开发过程当中须要面对的是两大操做系统 iOS 和 Android 的微信客户端，以及用于辅助开发的小程序开发者工具，小程序中三大运行环境也是有所区别的，如表1-1所示。

表1-1 小程序的运行环境

运行环境	逻辑层	渲染层
iOS	JavaScriptCore	WKWebView
安卓	X5 JSCore	X5浏览器
小程序开发者工具	NWJS	Chrome WebView

网页开发者在开发网页的时候，只须要使用到浏览器，而且搭配上一些辅助工具或者编辑器便可。小程序的开发则有所不一样，须要通过申请小程序账号、安装小程序开发者工具、配置项目等等过程方可完成。