[TOC]
### 4.3.1 发布前最后的检查
开发者在发布前常常遗漏的点:
1. 如果小程序使用到Flex布局,并且需要兼容iOS8以下系统时,请检查上传小程序包时,开发者工具是否已经开启“上传代码时样式自动补全”。
2. 小程序使用的服务器接口应该走HTTPS协议,并且对应的网络域名确保已经在小程序管理平台配置好。
3. 在测试阶段不要打开小程序的调试模式进行测试,因为在调试模式下,微信不会校验域名合法性,容易导致开发者误以为测试通过,导致正式版小程序因为遇到非法域名无法正常工作。
4. 发布前请检查小程序使用到的网络接口已经在现网部署好,并且评估好服务器的机器负载情况。
当体验版进行充分的检查和测试后达到发布状态,项目管理者可以在小程序平台进行提交审核的操作,提交审核后,微信审核团队会根据相关的运营规范进行提审小程序的审核。审核通过之后,管理者可以随时发布自己的小程序。
### 4.3.2 发布模式
小程序提供了两种发布模式:全量发布和分阶段发布。
`全量发布`:是指当点击发布之后,所有用户访问小程序时都会使用当前最新的发布版本。
`分阶段发布`:是指分不同时间段来控制部分用户使用最新的发布版本,分阶段发布我们也称为灰度发布。
一般来说,普通小程序发布时采用全量发布即可,当小程序承载的功能越来越多,使用的用户数越来越多时,采用分阶段发布是一个非常好的控制风险的办法。因为随着程序的复杂度提高以及影响面的扩大,新版本的代码改动或多或少会带来Bug,作为服务方当然不希望异常的服务状态一下子扩散到整个用户群体,此时应该通过分阶段发布来逐步观察服务的稳定性,再决定是否进行全量发布。
还需要留意一点,并非全量发布之后,用户就会立即使用到最新版的小程序,这是因为微信客户端存有旧版本小程序包缓存。用户在使用小程序时会优先打开本地的小程序包,微信客户端在某些特定的时机异步去更新最新的小程序包。
一般我们认为全量发布的24小时后,所有用户才会真正使用到最新版的小程序。
### 4.3.3 小程序码
很多场景下用户会通过扫码快速进入一个小程序,在小程序设计的初期,小程序平台提供的二维码的形式。我们发现用户在扫一个二维码时,他并不知道当前这次扫码会出现什么样的服务,因为二维码的背后有可能是公众号、小程序、网页服务、支付页面、添加好友等不同的服务。为了让用户在扫码之前就有一个明确的预期,因此微信设计了小程序码,如图5-11所示。
:-: ![”小程序数据助手”的小程序码](https://box.kancloud.cn/c71c2f996e737e52a46ba4b1e0f99b0b_433x436.png)
:-: 图5-11 “小程序数据助手”的小程序码
小程序码在样式上更具辨识度和视觉冲击力,相对于二维码来说,小程序主题的品牌形象更加清晰明显,可以帮助开发者更好地推广小程序。在发布小程序之后,小程序管理平台会提供对应的小程序码的预览和下载,开发者可以自行下载用于线上和线下的小程序服务推广。
- 微信
- 小程序
- 1. 代码组成
- 1.1 JSON配置--'*.json'文件
- 1.2 WXML模板--'*.wxml'文件
- 1.3 WXSS样式--'*.wxss'文件
- 1.4 JavaScript脚本--'*.js'文件
- 2. 客户端运行
- 2.1 逻辑层和渲染层
- 2.1.1 逻辑层--App Service
- 2.1.2 渲染层/视图层--View
- 2.1.3 通信模型
- 2.1.4 数据驱动
- 2.1.5 双线程下的界面渲染
- 2.2 程序与页面
- 2.3 组件
- 2.4 API
- 2.5 事件
- 2.6 兼容
- 3. 应用设计
- 3.1 Flex布局
- 3.2 界面常见的交互反馈
- 3.3 发起HTTPS网络通信--wx.request
- 3.4 微信登录
- 3.5 本地数据缓存
- 3.6 设备能力
- 4. 小程序的协同工作和发布
- 4.1 协同工作
- 4.2 用户体验审视
- 4.3 发布
- 4.4 运营
- 5. 底层框架
- 5.1 双线程模型
- 5.2 组件系统--Exparser框架
- 5.3 原生组件
- 5.4 小程序与客户端通信原理
- 6. 运行和性能优化
- 6.1 启动--代码加载
- 6.2 页面准备
- 6.3 数据通信
- 6.4 视图层渲染
- 6.5 原生组件通信
- 7. 小程序基础库的更新迭代
- 8. 微信开发者工具
- 腾讯云支持
- wafer
- Wafer2 快速开发 Demo - PHP
- WXAPI
- api列表