微信小程序系统 第1篇
做过小程序的铁汁们应该对这张图不陌生了：
图中过程主要是为了获得微信用户的唯一 openid 与 session_key，之后开发者服务器可以根据用户标识来生成自定义登录态，用于后续业务逻辑中前后端交互时识别用户身份。
调用 () 获取临时登录凭证 code，并回传到开发者服务器。
调用 接口，换取用户唯一标识 openid 、用户在微信开放平台帐号下的唯一标识 UnionID（若当前小程序已绑定到微信开放平台帐号）和会话密钥 session_key。
微信小程序系统 第2篇
通过上面的内容，你应该大致了解小程序诞生的情况和所处的环境了，下面我们就来聊聊小程序的整体设计构架情况。
整个小程序系统构架分成两个部分：视图层(WebView) 和 逻辑层(App Service)，这两个部分分别由两个独立线程管理。
视图层：也称为渲染层，渲染层用来渲染页面结构，主要由 WebView 进行渲染，一个小程序可以存在多个界面，所以渲染层可能存在多个 WebView 线程。
逻辑层：逻辑层采用 JSCore 线程运行 JS 脚本。逻辑层主要用来逻辑处理、数据请求、接口调用等。
视图层和逻辑层之间的沟通则需要借助 系统层(WeixinJsBridage) 进行通信，逻辑层把数据变化通知到视图层，触发视图层页面更新，视图层把触发的事件通知到逻辑层进行业务逻辑处理。
页面渲染大致过程为：我们把项目进行编译会把 WXML 转化成对应的 JS 对象（Virtual DOM），在逻辑层发生数据变化的时候，我们会通过 setData() 方法把数据从逻辑层传递到视图层，视图层在接收到数据后，会内部进行差异对比，把差异应用在原来的 Dom 树上，再正确的渲染出 UI 界面，完成页面的渲染过程。
通过上面的分析，你是否能理解开头放置的架构图了
上面的分析还提及到了一个 系统层(WeixinJsBridage)，一般简称为 JSBridge，它起到了一个中间桥梁的作用，非常重要。它不仅让视图层与逻辑层两个单独线程能进行通信，而且也架起上层开发与系统底层功能（Native）的桥梁，使得小程序可以通过调用 API 使用原生功能，且部分组件用原生组件实现，从而有良好体验。
逻辑层还有一个重要的操作，发送网络请求，它也是经由 系统层 转发的。
讲到这里，希望你对小程序的整体架构有一定认识了，下面我们开始就讲一下小程序内部的一些机制情况了。
微信小程序系统 第3篇
微信小程序的宿主环境为微信客户端，它是依赖于微信客户端上运行的，并且跟小程序 基础库 版本有重大关联关系。
我们可以把 微信客户端 以及 小程序基础库 简称为微信小程序的宿主环境。
微信小程序可以调用宿主环境提供的微信客户端的能力，可以完成许多普通网页无法完成的功能，这就使得小程序比普通网页拥有更多的能力。小程序会运行在不同版本（不同的微信客户端+不同基础库）的宿主环境下，因此针对各个版本的宿主环境做程序上的兼容也是在所难免的。
微信小程序系统 第4篇
Web 技术来渲染小程序是存在一些不可控因素和安全风险的。这是因为Web技术是非常开放灵活的，我们可以利用JavaScript 脚本随意地跳转网页或者改变界面上的任意内容。这个时候安全问题摆到了微信团队的台面上。如果微信小程序可以离线浏览，只需要小程序开发者把一些应用数据缓存到本地，然后通过javascript脚本把小程序渲染的webview跳转到其他的在线网页，那么这个体验就非常的糟糕。想必前端开发者会非常熟悉这个操作。
除此之外，javascript还可以通过操作DOM，直接获取小程序内部的一些敏感数据，比如用户的信息，商家信息等等，那么小程序将毫无安全可言。
为了解决安全管控问题，小程序阻止开发者使用一些浏览器提供的比如跳转页面、操作DOM、动态执行脚本的开放性接口。如果这些东西一个一个地去禁用，那么势必会进入一个糟糕的循环，因为javascript实在是太灵活了，浏览器的接口也太丰富了，很容易就遗漏一些危险的接口，而且就算是禁用掉了所有感觉到危险的接口，也势必防不住浏览器内核的下次更新。指不定又会出现一些漏洞。
因此，要彻底解决这个问题，必须提供一个沙箱环境来运行开发者的JavaScript 代码。这个沙箱环境不能有任何浏览器相关接口，只提供纯JavaScript 的解释执行环境，那么像HTML5中的ServiceWorker、WebWorker特性就符合这样的条件，这两者都是启用另一线程来执行 javaScript。但是考虑到小程序是一个多 webView 的架构，每一个小程序页面都是不同的webView 渲染后显示的，在这个架构下不好去用某个webView中的ServiceWorker去管理所有的小程序页面。
微信小程序系统 第5篇
微信公众号主要是基于HTML5实现的网页应用，而微信小程序是以微信为基座实现的一种轻应用。 传统的HTML5运行是要依赖于浏览器环境的，在微信的Web View组件内即可运行HTML5的网页应用，微信小程序的运行环境并非完整的浏览器，微信基于浏览器内核并且针对小程序的运行重构了一个内置的解析器，搭配自定义的WXML、WXSS等开发语言标准，实现以微信为基座的内置应用开发。小程序是微信内的云端应用，通过Web Socket双向通信、本地缓存以及微信底层技术优化实现了接近原生App的体验。
微信小程序系统 第6篇
微信小程序的性能流畅度可以和系统原生App相媲美，这一点是HTML5 Web应用可望而不及的。小程序也借助微信这个强大的后台，能够拥有比HTML5更多的系统权限，比如缓存能力、重力感应、网络状态等，而且这些系统权限能够与小程序进行无缝衔接。
小程序的前身是“应用号”，对于微信来说，“应用号”与微信公众平台上的订阅号、服务号、企业号（现更名为企业微信）更匹配。由于苹果公司对“应用”两个字的限制，这也使推出的“应用号”微信没能在App Store通过审核，微信本身就是一款手机App，它的成长需要依赖IOS（苹果手机操作系统）和Android（安卓手机操作系统）两大移动端系统平台，苹果对应用市场的监管很严格，所以在应用的命名上，微信也做出了一定的让步，把“应用号”更名为“小程序”。 小程序是微信公众平台的组成部分，与订阅号、服务号和企业微信（原企业号）共同组成微信公众平台的生态圈，如图4所示。 图4 微信公众平台账号分类
服务号给企业和组织提供更强大的业务服务与用户管理能力，帮助企业快速实现全新的公众号服务平台；订阅号为媒体和个人提供一种新的信息传播方式，构建与读者之间更好的沟通与管理模式。订阅号的申请主体可以是组织、个人、社会机构，但是服务号不支持个人主体申请，只对组织、企事业单位、其他社会机构开放。而且在推广方面，订阅号可以每天群发一次消息，服务号每个月只能群发4次，而且服务号提供了比订阅号更多的开放能力，例如只有服务号才能申请微信支付。企业微信是面向企业提供的办公管理工具，提供丰富的办公应用，并与微信消息、小程序、微信支付等互通，助力企业高效办公和管理。
微信小程序是一种全新的连接用户与服务的方式，它可以在微信内被便捷地获取和传播，同时具有出色的使用体验。微信公众号是生产内容的，而小程序是生产应用的，并且生产“小应用”没有太多的成本压力，给开发者提供了更广阔的想象空间，可以更快更高效开发一款小程序。
自微信小程序推出以来就备受关注，这离不开小程序自身独特的优势，下面对小程序的优势做具体的介绍。
微信小程序最大的特点就是“即用即走，无须下载”，微信对小程序做了很多的限制，不会主动向用户推送消息，客户不会被营销信息打扰，也不会过度黏住用户，而且无须下载的特点也免去了安装卸载这些繁琐的步骤，不会占用手机系统空间，也不会浪费流量和残留系统垃圾。
“即用即走，无须下载”这一点对用户来讲还是很有吸引力的，随着人们使用手机产生的数据越来越多，再加上手机本身的存储空间不够富裕，有了微信小程序就可以解决这些用户痛点。微信小程序几乎不占用系统空间，这就免去了用户不能安装新应用的尴尬，不用担心小程序驻留在手机给系统带来的资源消耗。
如果要开发一款与原生App具有相同功能的小程序，在人力成本和时间成本上，开发微信小程序都要比开发相同的原生App成本低很多。而且开发的原生App要同时适用于IOS、Android等多个操作系统这就加大了原生App的开发难度，微信小程序基于微信的强大的用户基数，可以快速实现跨平台开发，极大的降低了开发与市场推广的成本，降低了创业者的门槛。
微信推出订阅号和服务号，其目的是让订阅号为用户提供内容，让服务号为用户提供各种服务，从而让微信逐渐成为了一个生态圈，用户无须离开微信就可以完成阅读、社交和获取资讯服务。但是，目前服务号为用户提供的功能较为简单，很多用户的使用服务号的场景仅限于接收通知消息，服务号的其他功能很少被用到，因此，服务号没有完成为用户提供服务的历史使命。
微信创始人张小龙曾这样评价服务号：“我们的本意并不是要做成一个只是传播内容的平台，我们一直说要做一个提供服务的平台，所以后面我们甚至专门拆分出一个服务号出来，但是服务号还没有达到我们的需求，说服务号可以在里面提供服务为主，所有的服务号还是基于一个诉求，这不是我们想看到的。”
服务号有很多缺点，例如体验差、层级多、接口少、内容参差不齐、过度营销等，这也使服务号被用在低频使用场景中，即使有这么多的缺点，用户毕竟使用服务号的机会也是很少的，而且根本满足不了用户的需求。于是，微信便推出了小程序来弥补服务号无法解决的高频使用问题。
微信小程序基于微信体系开发，同时也被微信限制和监控，防止微信自身或开发者利益受到损害。微信要求开发者严格按照微信的规范进行开发和操作小程序，即使是小程序的上线，也需要通过微信官方的审核。只要是不符合微信要求的小程序是不能发布的，甚至有可能会被直接封杀。用户在使用小程序时，小程序也只能获取到用户的昵称、头像等非隐私数据和信息，这些数据都停留在微信平台，而非小程序平台，所以小程序开发者也无权获取用户的隐私数据，这就保证了微信小程序在开发和使用过程中的安全性。
小程序不具备调整的功能，包括调整外部网站、外部链接等，如果需要在小程序的Web View组件内打开外部链接，需要提交URL备案，只有通过审核才能在小程序内使用Web View打开外部链接。在保护开发者方面，各项小程序都有属于自己的App ID，用来防止恶意开发者伪造、仿制安全的小程序进行诈骗行为。但是，这些特点在保证小程序安全性的同时，也约束了小程序的功能性，使原生的系统应用有一些小程序无法到达的能力。
作为一个独立的应用生态系统，需要具备以下几个特点：
微信小程序就是以微信为核心的一个独立应用生态圈，它的官方平台是微信，以微信作为应用的统一入口，利用微信制定的语言和开发标准进行微信小程序的应用设计与开发，而且微信对小程序开发、运营、审核等各方面也做出了严格的规范和限制，开发者借助微信公众平台进行开发和推广，这也为微信官方获取更多小程序提供了渠道。这样一个应用生态系统，就相当于在微信平台上实现了一个全新的App Store。
小程序是微信推出的一个全新的概念，为了帮助大家更好地认知小程序这个新生事物，更快的开发小程序，微信官方创建了微信小程序社区（如图5所示），通过社区帮助小程序开发者、创业者和中小企业主提供一个相互交流的专业平台。在这个社区中，大家不仅可以自由分享小程序的开发经验，还可以在上面学习小程序开发、推广、运营等方面的技术。 图5 微信小程序社区
微信小程序开发者和创业者都可以在微信小程序社区上查找、交流、分享微信小程序的一切问题。除了社区，微信官方还创建了微信小程序官方文档（如图6所示），为开发者提供一个简单、高效的应用开发框架和丰富的组件及API，帮助开发者在微信中开发具有原生App体验的服务。 图6 微信小程序官方文档
微信小程序的重点体现在一个“小”字上，小程序更适合开发那些非刚需、轻量级、功能单一、不需要调动太多系统能力的应用，而对一些高频刚需的应用场景，小程序还是有一定的弱势的，高频场景服务依然适合以独立App作为阵地。 对于使用频率不高、功能单一的应用，可以把微信小程序作为一个不错的切入口，而且这种需求也只需要使用HTML5就可以实现，迁移小程序的成本较低，也就成了很多商家一个不错的选择。
微信已经成为人们不可缺少的社交工具，随着微信支付的普及，微信除了提供社交聊天的能力之外，还提供了更多的金融服务。依托于微信的小程序，使用也越来越普及。微信小程序的高效、便捷，功能不断完善，用户对微信小程序的未来也充满了期待。
微信小程序是一个生态圈，将来能够更好地借助于扩展差距进行微信小程序的开发，为微信小程序用户开放更多权限，未来所发挥的空间也越来越大。微信小程序在发展过程中不断完善自己，其开放能力越来越强，能够匹配多种场景。微信小程序现在积累了大量的用户，让其他行业与微信用户有更好的链接，与微信更好的结合。因此微信小程序的发展空间是无限的。
微信小程序的诞生，即弥补了HTML5和原生App的不足，也带来的巨大的商机，提供了更多的就业机会，在新一轮移动互联网变革中创造了无限的机遇。其轻量级、即用即走等优势，为用户提供了便利，同时也为功能单一和低频使用的应用提供了新的开发场景，降低了创业者的成本，而且还能实现App的功能，用户使用起来更加方便。微信小程序会带来千亿市场，未来，每个线下门店不一定会拥有自己的App和网站，但是都可能拥有自己的微信小程序。所以，微信小程序是非常值得大家关注并投入到开发者行列中。
微信小程序系统 第7篇
通过学习了小程序的架构原理，我们再来用底层架构的眼光来简单分析一下常见的小程序性能问题是如何产生的。
频繁调用setData()
频繁调用 setData()，这个问题相信已经是很常见的，比如在定时器中调用、在监听页面滚动的钩子中调用，这些场景很容易就会引起小程序的性能问题，容易出现页面卡顿、页面数据更新不及时的情况。
前面在 数据通信机制 中我们讲过小程序是基于双线程的，那就意味着任何在视图层和逻辑层之间的数据传递都是线程间的通信，频繁的去调用 setData()，会使得线程之间一直处于忙碌状态，逻辑层通知到视图层耗时就会上升，视图层收到消息的时候可能已经距离发出的时间超过一定时间了，渲染页面就不够及时了。
庞大的数据量去调用setData()
还是在前面的 数据通信机制 中，我们说过传输的数据需要转换成转换为字符串的形式传递，且通过 JS 脚本的形式去执行，当数据量大时，执行脚本的编译执行时间也会上涨，占用线程。
页面复杂繁多的DOM结构
当一个页面 DOM 结构复杂并且非常多的时候，这必定带来页面显示不及时，页面卡顿，甚至可能会出现页面奔溃的情况，这其中的原因可想而知，是过于 DOM 绘制、计算都是需要时间的，这将使得线程过渡的工作，带来客户端内存占用上升，从而触发系统回收小程序页面。
上面我提到说，对 “逻辑层运行在 JSCore 中” 这句话有点疑问，是因为我在看到表格中列举的逻辑层运行的环境应该是按系统环境区分的才对，那这句话是不是就太笼统了？还是说这句话就是指 IOS 的情况呢？因为是官方文档写的话语，所以我没有直接就否决是写错了，或者单指IOS 的情况。
经过一翻查证，证实其实这句话是没有问题的，要追寻结果的过程，我们需要写了解一下浏览器的大致情况：
浏览器中最核心的部分则是浏览器内核，每个浏览器都有其各自的内核，而对移动领域影响最深的则当属 WebKit。
WebKit 就是一个页面渲染以及逻辑处理引擎，HTML/CSS/JavaScript 经过它的处理，成为可见且可操作的Web页面。
WebKit 由多个重要模块组成
WebKit 由四个部分组成，分别是：
WebKit Embedding API：负责浏览器 UI 与 WebKit 进行交互的部分。
Platform API（WebKit Ports）：让 Webkit 更加方便的移植到各个操作系统、平台上，提供的一些调用Native Library的接口。
WebCore：整个 WebKit 中最核心的渲染引擎。
JavascriptCore：JSCore 是 WebKit 默认内嵌的JS引擎，由苹果使用 C 开发。
我们来重点来关注 JSCore 部分，JSCore 是 WebKit 默认内嵌的JS引擎，之所以说是默认内嵌，是因为很多基于 WebKit 分支开发的浏览器引擎都开发了自家的JS引擎，其中最出名的就是 Chrome的V8 引擎。
V8 引擎，相信前端的小伙伴应该不会很陌生了，既然它是基于 WebKit 的，那底层默认也是内嵌 JSCore 的，而 Android 的逻辑层是运行在 V8 上的。
而 IOS 的浏览器引擎则是 WebKit，内部则就是 JSCore。
最后 开发工具 的逻辑层是运行在 , 上它的官网，看到怎么一段话：
我相信它应该也和 WebKit 扯上关系了。
以上就是微信小程序架构原理基础详解的详细内容
微信小程序系统 第8篇
小程序开发框架的逻辑层使用 JavaScript 引擎为小程序提供开发 JavaScript 代码的运行环境以及微信小程序的特有功能。
逻辑层将数据进行处理后发送给视图层，同时接受视图层的事件反馈。
开发者写的所有代码最终将会打包成一份 JavaScript 文件，并在小程序启动的时候运行，直到小程序销毁。这一行为类似 ServiceWorker，所以逻辑层也称之为 App Service。
在 JavaScript 的基础上，我们增加了一些功能，以方便小程序的开发：
增加 App 和 Page 方法，进行程序注册和页面注册。
增加 getApp 和 getCurrentPages 方法，分别用来获取 App 实例和当前页面栈。
提供丰富的 API，如微信用户数据，扫一扫，支付等微信特有能力。
提供模块化能力，每个页面有独立的作用域。
注意：小程序框架的逻辑层并非运行在浏览器中，因此 JavaScript 在 web 中一些能力都无法使用，如 window，document 等。
微信小程序运行在多种平台上：iOS/iPadOS 微信客户端、Android 微信客户端、Windows PC 微信客户端、Mac 微信客户端、小程序硬件框架和用于调试的微信开发者工具等。
不同运行环境下，脚本执行环境以及用于组件渲染的环境是不同的，性能表现也存在差异：
在 iOS、iPadOS 和 Mac OS 上，小程序逻辑层的 JavaScript 代码运行在 JavaScriptCore 中，视图层是由 WKWebView 来渲染的，环境有 iOS 14、iPad OS 14、Mac OS 等；
在 Android 上，小程序逻辑层的 JavaScript 代码运行在 V8 中，视图层是由基于 Mobile Chromium 内核的微信自研 XWeb 引擎来渲染的；
在 Windows 上，小程序逻辑层 JavaScript 和视图层都是用 Chromium 内核；
在 开发工具上，小程序逻辑层的 JavaScript 代码是运行在 中，视图层是由 Chromium Webview 来渲染的。
JavaScriptCore 无法开启 JIT 编译 (Just-In-Time Compiler)，同等条件下的运行性能要明显低于其他平台。
尽管各运行环境是十分相似的，但是还是有些许区别：
JavaScript 语法和 API 支持不一致：语法上开发者可以通过开启 ES6 转 ES5 的功能来规避（详情）；此外，小程序基础库内置了必要的Polyfill，来弥补API的差异（详情)。
WXSS 渲染表现不一致：尽管可以通过开启样式补全来规避大部分的问题，还是建议开发者需要在各端分别检查小程序的真实表现。
开发者工具仅供调试使用，最终的表现以客户端为准
基于安全考虑，小程序中不支持动态执行 JS 代码，即：
不支持使用 eval 执行 JS 代码
不支持使用 new Function 创建函数new Function('return this') 除外
小程序的 JS 执行环境 在不同平台上的执行环境存在差异，因此导致不同平台对 ECMAScript 标准的支持存在差异。
小程序基础库为了尽量抹平这些差异，内置了一份 core-js Polyfill。core-js 可以将平台环境缺失的标准 API 补齐。
需要注意的是，平台对 ECMAScript 语法的支持差异无法抹平，当你需要使用一些高级语法时，如 async/await 时，则需要借助 代码转换工具 来支持这些语法。
以下 API 在部分低版本客户端中无法使用，请注意尽量避免使用
Proxy 对象
由于实现原因与 iOS JavaScriptCore 限制，iOS 环境下的 Promise 是一个使用 setTimeout 模拟的 Polyfill。这意味着 Promise 触发的任务为普通任务，而非微任务，进而导致 在 iOS 下的 Promise 时序会和标准存在差异。
关于普通任务和微任务的区别可以查看这篇文章
特定的小程序基础库版本有最低微信客户端版本要求，如基础库 要求安卓最低版本 ，iOS 最低版本 。
而特定的客户端版本有最低操作系统版本要求，如 iOS 要求最低 iOS 10。
从而，当指定特定小程序基础库版本时（可以在 小程序管理页 【设置】-【基本设置】-【基础库最低版本设置】中设置），我们能够得到最低需要支持的执行环境。
具体数据可以从 这个开源库 中获得。
小程序从启动到最终被销毁，会经历很多不同的状态，小程序在不同状态下会有不同的表现。
从用户认知的角度看，广义的小程序启动可以分为两种情况，一种是冷启动，一种是热启动。
冷启动：如果用户首次打开，或小程序销毁后被用户再次打开，此时小程序需要重新加载启动，即冷启动。
热启动：如果用户已经打开过某小程序，然后在一定时间内再次打开该小程序，此时小程序并未被销毁，只是从后台状态进入前台状态，这个过程就是热启动。
从小程序生命周期的角度来看，我们一般讲的「启动」专指冷启动，热启动一般被称为后台切前台。
小程序启动后，界面被展示给用户，此时小程序处于「前台」状态。
当用户「关闭」小程序时，小程序并没有真正被关闭，而是进入了「后台」状态，此时小程序还可以短暂运行一小段时间，但部分 API 的使用会受到限制。切后台的方式包括但不限于以下几种：
微信小程序系统 第9篇
当涉及到创建微信小程序时，注册和认证过程相当直接。以下是需要注意的关键步骤：
重要的是要注意，注册和认证过程的每一步对于确保微信小程序的成功都至关重要。通过仔细遵循这些步骤，您可以创建一个高质量的小程序，吸引用户并推动业务成果
开发一个微信小程序的费用取决于您的需求和开发方式。一般来说，微信小程序的开发费用范围在1000元（基于模板）到十几万（高度定制）之间。
除非您是一家拥有大量资源、已在中国知名且有非常具体项目的公司，否则我们建议您选择模板小程序开发。
请注意，以上费用仅供参考，实际费用可能会因为项目的具体情况而有所不同。在决定开发微信小程序之前，建议您充分考虑自己的需求和预算，并选择合适的开发方式。