双线程架构

分为 逻辑层 和 渲染层,两者通过系统层异步通信传递数据

逻辑层:独立的 JavaScript 线程(如 JavaScriptCore)

  • 处理业务逻辑(数据请求、事件响应、状态管理)。
  • 调用小程序 API(如网络请求、本地存储)。
  • 通过 setData 向渲染层传递数据。

渲染层:WebView 线程(每个页面独立实例)

  • 解析 WXML/WXSS,渲染页面结构。
  • 处理用户交互事件(点击、滑动),触发逻辑层响应。

系统层(Native):作为逻辑层与渲染层的通信桥梁,提供原生能力支持。

  • JSBridge:序列化传递数据(JSON 格式)。
  • 安全管控:拦截非法操作(如直接访问 DOM)。
  • 原生 API:调用摄像头、地理位置等硬件功能。

冷启动与热启动

对比维度冷启动热启动
触发条件首次打开或销毁后重新打开后台存活状态下重新唤醒
资源加载重新下载代码包、初始化页面直接从内存恢复页面
启动速度较慢(需完整加载)较快(无需重新初始化)
生命周期流程执行 App.onLaunch → Page.onLoad仅触发 App.onShow 和 Page.onShow
内存占用重新分配内存复用原有内存
数据状态全局数据需重新初始化保留之前的运行状态
存活时间无限制默认后台存活 5分钟
典型场景用户首次打开或主动杀死进程后重启切换回微信聊天后重新进入

组件通信方案

方案适用场景优点缺点
Properties父子简单数据传递官方推荐,类型校验单向数据流
自定义事件子向父传递操作解耦合多层传递较复杂
selectComponent父直接调用子方法快速直接破坏封装性
全局事件总线任意组件间通信灵活度高需手动管理监听/卸载
全局状态跨页面共享数据集中管理非响应式,需手动监听
页面路由传参页面间简单数据传递官方支持数据类型受限
relations存在逻辑关联的组件官方关系管理配置较复杂

如何实现下拉刷新

方案一:使用系统提供的 onPullDownRefresh

  • 通过在 app.json 中,设置 "enablePullDownRefresh": true, 开启全局下拉刷新 / 或者通过在 组件.json,设置 "enablePullDownRefresh": true, 开启单个组件下拉刷新。
  • 在 Page 中定义 onPullDownRefresh 钩子函数,到达下拉刷新条件后,该钩子函数执行,发起请求方法
  • 请求返回后,调用 wx.stopPullDownRefresh 停止下拉刷新

方案二:使用 <scroll-view> 组件

小程序登录流程

700