小程序pc端后台控制（如何让PC桌面端应用具备小程序运行能力）
小程序pc端后台控制（如何让PC桌面端应用具备小程序运行能力）虽然大家都默认在智能设备中运行小程序的能力是一线互联网企业的“专利”，事实上，已经有小程序容器技术可以实现，FinClip能够跑在手机、Windows、Mac、Linux、统信、麒麟等智能设备操作系统上。这意味着，移动端、PC 端、IOT等智能终端都能运行小程序了。从2017年微信首次推出小程序开始，经过四年发展，各大互联网巨头纷纷推出自己的小程序应用平台，小程序成为真正意义上的“互联网新技术标准”。截至2021年上半年，全网小程序数量突破700万个，其中，微信小程序是行业主流，数量超过430万个，占比高达约61.43%。不得不说，小程序无论在技术标准还是业务生态发展，经历过近几年的发展，都已经有质的飞跃。相比于十几年前的HTML5技术和生态，有过之而无不及。从Web 1.0进化到2.0之后的十几年间，移动App都是各大软件提供商用于争夺消费者碎片化时间的主战场。HTML5这种标准化的、普
众所周知的小程序，都知道其诞生地是微信。最开始的愿景，是希望通过自定义一套全新的界面开发模式，来实现将微信能力安全、可控的开放使用。与此同时，微信团队也希望能够通过小程序规避掉之前用 Web 开发会遇到的各种问题，比如渲染卡顿、加载白屏时间长等问题，提供类似于原生的体验、安全易用的微信数据开放、更多端能力的提供、简单高效的开发方式。
其核心是前端容器化，分为UI和数据两个层面。
- UI层面容器化，微信的解决方案很简单，就是重新创建一套组件，完全抛弃 DOM 的标准组件。这样就可以做到 UI 上的完全可控和安全。
- 数据层面容器化，本质上就是 JS 的沙盒，避免开发者直接拿到 UI 及其数据，这也就诞生了小程序和别的差别最大的地方——双线程架构。
这个架构简单科普一下，分为：
- 逻辑层: 运行在端内创建的 JS 线程中，用户的业务代码在该线程中执行，如你的 js 代码
- 渲染层: 运行在端创建的 WebView 中，用户的模板和样式代码在其中执行，如你的 wxml、wxss 代码
那么为什么要如此设计呢？其实最最主要地目的就是为了"安全"（并不是为了保障渲染的更顺畅）是的，这是一个加了引号的安全，这里的安全是对小程序的平台方来说的。任何软件平台都有它的游戏规则，比如 UI 界面的一致性，网络请求域的收敛，平台功能限制等，只是小程序稍有不同的是虽然是基于 web 技术，但并不想让开发者使用到全量的 web技术。所以把用户的代码放到一个脱离 web 的线程中去运行就是一个最稳妥的方案了。
技术标准及业务生态的演变不得不说，小程序无论在技术标准还是业务生态发展，经历过近几年的发展，都已经有质的飞跃。相比于十几年前的HTML5技术和生态，有过之而无不及。
1、先说说技术标准从Web 1.0进化到2.0之后的十几年间，移动App都是各大软件提供商用于争夺消费者碎片化时间的主战场。HTML5这种标准化的、普适的文本化内容编码格式，被广泛应用，并最终成为了互联网的基石之一。Web2.0向3.0的进化过程中，软件技术标准的扩展，小程序类技术的编码和内容格式，整体基于HTML5基础上，更加轻量，也更加开放有生命力。
从标准的角度看，当前互联网上的小程序类技术，几乎都借鉴了这个领域的先行者微信的规范。可以说，微信小程序就是这个领域的“既成事实”标准。故此互联网系列全球标准的制定者W3C，也正在通过其Mini-Apps工作组制定国际标准。
2、再说说小程序业务生态从2017年微信首次推出小程序开始，经过四年发展，各大互联网巨头纷纷推出自己的小程序应用平台，小程序成为真正意义上的“互联网新技术标准”。截至2021年上半年，全网小程序数量突破700万个，其中，微信小程序是行业主流，数量超过430万个，占比高达约61.43%。
虽然大家都默认在智能设备中运行小程序的能力是一线互联网企业的“专利”，事实上，已经有小程序容器技术可以实现，FinClip能够跑在手机、Windows、Mac、Linux、统信、麒麟等智能设备操作系统上。这意味着，移动端、PC 端、IOT等智能终端都能运行小程序了。
跨端框架，在一些大厂的小程序平台中，有开始出现框架反制小程序引擎的问题。比如开发者想要对小程序自定义组件的时序进行一些优化，让其更加符合现代框架标准，却发现强依赖了这个框架的时序，导致开发者根本无法将优化立马上线，因为一旦优化，用了跨端框架的小程序几乎全部无法运行。
一直都认为桌面应用中的浏览器是HTML5的“天下”，事实上，技术的进步，会给我们技术人带来持续不断的惊喜。小程序的技术及生态，似乎在重复着HTML5当初繁盛一时的技术景象，未来发展如何，让我们拭目以待。
