用户
 找回密码
 立即注册

QQ登录

只需一步,快速开始

扫一扫,登录网站

小程序社区 首页 教程 新手教程 查看内容

小程序运行机制以及相关知识点

Rolan 2020-5-27 00:09

可能今天在很多人眼中,小程序已经成为别人印象中的app,功能齐全,且可以完成各种功能以及业务。但是个人从小程序的诞生使用至今,在我眼中他依然是个轻量级应用,虽逐步的壮大,一些功能还是有所限制,但是从功能 ...

可能今天在很多人眼中,小程序已经成为别人印象中的app,功能齐全,且可以完成各种功能以及业务。但是个人从小程序的诞生使用至今,在我眼中他依然是个轻量级应用,虽逐步的壮大,一些功能还是有所限制,但是从功能上的角度却无法与app相媲美。以微信小程序为例,也许今天大小限制8M,页面栈已经是15层,大小可开发约50~70个页面,的确已经很好的支持业务的开发以及功能的扩张。但是在小程序开始之初,页面栈仅为5,包大小限制1M,很多业务的确无法扩展。小程序也因业务的扩展,逐步逐渐支持工程化,如当前支持npm包。但我们从小程序的产品整体设计上,还是不能忘记这个限制,无止境的叠加页面以及业务。

小程序的编译原理

简单的借助大神的思路,描述一下小程序的编译原理。 我们都知道,小程序页面由View(视图层),App Service(逻辑层)组成。它们在两个线程中运行(我们传统的h5,是单线程运行)。他们之间是由系统的JSBridage(常用于原生与h5交互的工具,可自行百度)进行交互的。

视图层使用 WebView 渲染,iOS 中使用自带 WKWebView,在 Android 使用腾讯的 x5 内核(基于 Blink)运行。 逻辑层使用在 iOS 中使用自带的 JSCore 运行,在 Android 中使用腾讯的 x5 内核(基于 Blink)运行。

以上原理借鉴来自大神yck。

看到这里,是否明白,为什么小程序不支持直接获取dom跟bom了吧?因为不像h5在同一个层级,在逻辑层时间上压根没有dom,只有通过官方的写法,通过系统层去操作dom。

小程序的常用第三方框架

原生

官方概念:官方自带

笔者观点:只有原生代码,才能在对应的小程序环境跑起来。任何第三方框架,都是经过自己的bable编译成原生支持代码才能运行。因此,在不考虑多端的情况下,强烈推荐使用原生,这样可以绕过第三方的坑。

Taro

官方概念:官方命名解释为多端统一开发解决方案。京东研发

笔者观点:这在多端中的需求中,相比原生的优势。此外,个人实践的应用中,taro是个人觉得为数不多兼容性较好的,坑相对较少。此外,官方还提供了taro-ui,ui从性能还有从外观,个人都是觉得写得非常的不错。 此外,他是利用React的方式开发小程序的框架。 使用 React的方式开发小程序的框架,同时支持生成多端应用,此外还支持转换rn等,如果同一项目需求有多个终端的要求。可以建议使用。

kbone

官方概念:Web 与小程序同构解决方案,腾讯研发。曾有这么一句话:kbone,十分钟让 Vue 项目同时支持小程序

笔者观点:如果有当前vue项目,急需支持微信小程序的话,可以考虑。这是一个求快不求精的选择。为腾讯官方出品,但是时间上的沉淀并不长,坑位估计不会少。有兴趣继续深入可查看: wechat-miniprogram.github.io/kbone/docs/…

mpvue

官方概念:基于 Vue.js 的小程序开发框架,从底层支持 Vue.js 语法和构建工具体系

笔者观点:小程序第三方中较早起家的框架。这是曾经vue开发者非常喜欢的框架,无成本的从vue的开发者,成为小程序开发者。植入了很多vue的概念,重写了babel,支持vuex,vue常用api等。不过貌似已经停止迭代了,使用慎重。

uni-app

官方概念:使用 Vue 语法开发小程序、H5、App的统一框架

笔者观点:历史悠长,从hridyapp的时代就有了uni至今。将微信的api二次讽刺,用自己的uni-对象替换了wx对应去转移成对应的api。目前还是有部分使用者,部分培训机构也有提到(毕竟培训的都是重点)。

WePY

官方概念:支持组件化的小程序开发框架,腾讯原生框架

笔者观点:只是略有了解,身边以及个人无人使用,不评论。

chameleon

官方概念:一套代码运行多端,一端所见即多端所见,滴滴研发

笔者观点:同上。

megalo

官方概念:基于 Vue 的小程序开发框架,网易考拉研发

笔者观点:同上。

小程序如何工程化

我们都知道,当前前端项目都有自己的脚手架,可随时更改自己的编译,如create-react-app,vue-cli等都自带webpack。而小程序的编译器属于内置编译器,我们没法对进行编译处理,当我们需要对整个项目进行编译或者工程化处理的时候,就会遇到瓶颈。这时候我们只能考虑自己嵌入工程化。

实际上,今天的小程序工程化的意义不是特别大。我们曾经有很多需要工程化小程序的需要,比如:支持npm包,支持es7,支持代码压缩,支持自定义指令,支持typescript等。

但是,小程序在长达几年的迭代中,也逐步支持着一些(但是总是慢前端架构一段很长的时间,比如es7到2019年才支持,前端早几年就可以用)

那当前工程化可以解决什么问题呢?

1)我们前端框架是否都用了css预处理。如less,sass。小程序由于自身定位是一个“小”项目,所以,官方可能认为不需要。但是我们实际业务中,或者手写代码的习惯,都习惯了less或者sass。

2)植入eslint 等代码检查工具

可能当前从这两个角度出发意义不大。但是,就跟上边所说,如再有什么新的技能点,是否还是要慢个几拍等官方支持?我们可提前做好准备。

使用gulp支持多页面打包到对应的位置,相信对前端来说不是很困难吧?晚点可上传demo。

小程序特别说明

尺寸单位换算

rpx换算px (屏幕宽度/750)
px换算rpx (750/屏幕宽度)
复制代码

小程序bug

转发(分享)小程序不能拿到成功结果
复制代码

小程序优化建议

代码压缩,分包加载,控制图片源文件,首屏优化。
复制代码

小程序官方优势(相比web)

1.支持服务通知推送。
2.支持缓存数据推送。
3.开放能力
4.支持云端开发
5.无需考虑兼容性
6.成本较低,体验较好(相比web)
复制代码
鲜花
鲜花
鸡蛋
鸡蛋
分享至 : QQ空间
收藏
原作者: weizhan 来自: 掘金