小程序使用view标签而不使用div的底层原因

本文探讨了小程序为何采用自定义标签,主要目标是解决Web渲染带来的管控和安全问题。通过限制JavaScript权限,防止数据泄露和页面跳转,采用双线程模型——逻辑层与渲染层,确保小程序的安全性和离线浏览体验。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

记一下为什么小程序非要使用自己封装的标签

核心原因就是为了解决管控与安全问题

基于Web技术来渲染小程序存在一些问题

  • 不可控因素
  • 安全风险

Web技术是非常开放灵活的,我们可以利用JavaScript脚本随意地跳转网页或者改变界面上的任意内容。

小程序原本定义了一套内置组件以提供统一的体验,用户进入小程序时,小程序代码包会被拉到本地使得小程序可以离线浏览(只要小程序开发者把一些应用数据缓存到了本地),但要是开发者通过JavaScript 把渲染小程序的 WebView 跳转到其他在线网页,这个体验就变得非常糟。

提供一种可以展示敏感数据的组件(这些数据只能被展示,开发者并不能拿到数据),若开发者可以通过JavaScript 操作界面(DOM树),从而直接获取这些敏感数据,那小程序毫无安全可言。

这就导致必须阻止开发者使用一些浏览器提供的,诸如跳转页面、操作DOM、动态执行脚本的开放性接口。一个一个禁止势必会进入一个攻防战,因为 JavaScript 的灵活性以及浏览器接口的丰富性,很容易遗漏一些危险的接口,而且就算被我们找到所有危险的接口,也许在下一次浏览器内核更新而新增了一个可能会在这套体系下产生漏洞的接口,这样还是无法完全避免。

要彻底解决这个问题,我们必须提供一个沙箱环境来运行开发者的JavaScript 代码。这个沙箱环境不能有任何浏览器相关接口,只提供纯JavaScript 的解释执行环境,那么像HTML5中的ServiceWorker、WebWorker特性就符合这样的条件,这两者都是启用另一线程来执行 JavaScript。但是考虑到小程序是一个多 WebView 的架构,每一个小程序页面都是不同的WebView 渲染后显示的,在这个架构下我们不好去用某个WebView中的ServiceWorker去管理所有的小程序页面。

得益于客户端系统有JavaScript 的解释引擎(在iOS下是用内置的 JavaScriptCore框架,在安卓则是用腾讯x5内核提供的JsCore环境),我们可以创建一个单独的线程去执行 JavaScript,在这个环境下执行的都是有关小程序业务逻辑的代码,也就是我们前面一直提到的逻辑层。而界面渲染相关的任务全都在WebView线程里执行,通过逻辑层代码去控制渲染哪些界面,那么这一层当然就是所谓的渲染层。这就是小程序双线程模型的由来。

<think>好的,我需要处理用户关于小程序面试题的请求。首先,用户希望得到结构清晰的回答,分点说明,并且使用中文。同时,他们提到了系统级指令,需要确保数学表达式的格式正确,使用$...$和$$...$$,并且LaTeX语法无误。 首先,我需要确定用户的具体需求。他们可能正在准备小程序开发的面试,需要了解常见的面试题及其解答。因此,我应该整理常见的小程序面试问题,涵盖基础概念、框架使用、性能优化、安全等方面,确保内容全面且实用。 接下来,考虑如何组织回答结构。按照常见的分类方式,将问题分为几个大类,如基础概念、框架使用、性能优化、安全等,每个类别下列举典型问题并给出简洁解答。这有助于用户逐步理解,符合用户要求的结构清晰。 在编写每个问题和解答时,需要注意使用正确的中文表达,同时检查是否有数学表达式需要处理。例如,如果有关于计算或公式的地方,要使用$...$包裹,如版本号比较$1.2.3 > 1.1.9$。如果有独立公式,比如性能优化的计算公式,可能需要使用$$...$$,但根据常见问题,可能这类数学内容多,但需保持警惕。 还需要确保LaTeX语法正确,比如积分符号\int的正确使用,上下标的位置等。同时,用户要求回答真实可靠,因此需要基于小程序开发的常见面试题和最佳实践来组织内容,避免错误信息。 可能的问题点包括:是否覆盖了主要的小程序平台(如微信、支付宝),是否涉及最新的API或更新,是否涵盖常见的性能优化策略等。需要确保每个解答简洁准确,冗长,但信息完整。 最后,检查整个回答是否符合用户提供的系统级指令,特别是数学表达式的格式是否正确,以及结构是否清晰。确保没有使用任何Markdown格式,纯文本分点,使用数字和缩进层次分明。</think>以下是小程序开发常见面试题及解答,按类别整理,帮助您系统准备: --- ### 一、基础概念 1. **小程序与H5的区别** - **运行环境**:H5运行在浏览器,小程序运行在专属环境(如微信JSCore) - **性能**:小程序加载更快,支持原生组件(如地图、摄像头) - **权限**:小程序需通过平台审核,调用系统API更直接(如支付、扫码) 2. **小程序生命周期函数** - `onLoad()`:页面加载时触发 - `onShow()`:页面显示时触发 - `onReady()`:页面初次渲染完成 - `onHide()`:页面隐藏 - `onUnload()`:页面销毁 --- ### 二、框架与语法 3. **WXML与HTML差异** - WXML使用`<view>`替代`<div>`,支持数据绑定`{{}}` - 特有指令:`wx:if`, `wx:for`, `wx:key`实现条件渲染与列表循环 - 示例:渲染列表 ```html <view wx:for="{{list}}" wx:key="index">{{item.name}}</view> ``` 4. **WXS的作用** - 在WXML中执行JavaScript逻辑,如过滤数据: ```javascript // 过滤价格超过100的商品 function filterPrice(products) { return products.filter(p => p.price > 100) } ``` --- ### 三、性能优化 5. **首屏加载优化方案** - 分包加载:主包≤2MB,总包≤20MB(微信规则) - 代码压缩:开启`minify`选项,删除无用代码 - 数据预拉取:使用`wx.request`提前获取数据 6. **setData的正确使用** - **问题**:频繁调用导致渲染卡顿 - **解决**:合并数据更新,避免单次传输超过$1024\text{KB}$ ```javascript // 错误写法:多次调用 this.setData({ a: 1 }) this.setData({ b: 2 }) // 正确写法:合并更新 this.setData({ a: 1, b: 2 }) ``` --- ### 四、网络与安全 7. **如何防止请求被劫持?** - 启用HTTPS协议 - 敏感数据加密(如AES加密用户ID) - 校验服务器证书指纹 8. **登录流程设计** 1. 调用`wx.login()`获取临时`code` 2. 发送`code`到服务端换取`openid`和`session_key` 3. 服务端返回自定义登录态(如Token) 4. 客户端存储Token用于后续请求 --- ### 五、调试与发布 9. **版本号规范** - 格式:`主版本.次版本.修订号`(语义化版本控制) - 示例:修复BUG时升级为$1.0.1 \rightarrow 1.0.2$ - 比较规则:$1.2.3 > 1.1.9$ 10. **灰度发布流程** - 上传代码后,在管理后台设置“体验版” - 选择特定用户或百分比逐步开放 - 监控错误率与性能指标,确认稳定后全量发布 --- ### 六、开放能力 11. **如何调用摄像头扫码?** ```javascript wx.scanCode({ success(res) { console.log('扫码结果:', res.result) } }) ``` 12. **订阅消息实现步骤** 1. 在后台配置订阅模板 2. 调用`wx.requestSubscribeMessage()`请求用户授权 3. 通过服务端API发送消息(需模板ID和用户openid) --- **建议准备方向**: - 重点掌握微信小程序API(如路由、存储、设备API) - 理解小程序底层原理(双线程模型、通信机制) - 准备实际项目经验描述(优化案例、技术难点)
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

薛定喵君

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值