未启动时更新
开发者在管理后台发布新版本的小程序之后，如果某个用户本地有小程序的历史版本，此时打开的可能还是旧版本。微信客户端会有若干个时机去检查本地缓存的小程序有没有更新版本，如果有则会静默更新到新版本。总的来说，开发者在后台发布新版本之后，无法立刻影响到所有现网用户，但最差情况下，也在发布之后 24 小时之内下发新版本信息到用户。用户下次打开时会先更新最新版本再打开

启动时更新
小程序每次冷启动时，都会检查是否有更新版本，如果发现有新版本，将会异步下载新版本的代码包，并同时用客户端本地的包进行启动，即新版本的小程序需要等下一次冷启动才会应用上。

• 灵活可扩展，可以任意添加头字段实现任意功能

• 拥有成熟的软硬件环境，应用广泛，是互联网的基础设施

• 是可靠传输协议，基于TCP/IP协议，"尽量"保证数据送达

• 是应用层协议，比 FTP、SSH 等更通用功能更多，能够传输任意数据

• 使用了请求 - 应答模式，客户端主动发起请求，服务器被动回复请求

• 本质上是无状态的，每个请求都是互相独立、毫无关联的，协议不要求客户端或服务器记录请求相关的信息。可以轻松实现集群，扩展性能

• 是明文传输，数据肉眼可见，方便研究分析，容易被窃听

• 不安全，无法验证通信双方的身份，不能判断报文是否被篡改

1.小程序初始化

微信会初始化小程序环境，比如逻辑层的js引擎，视图层的WebView，并且注入公共基础库

⬇️

2.下载小程序代码包
进行业务小程序代码包的下载

1.确认开发者工具是否开启不验证合法域名,先关闭不校验合法域名
⬇️

2.查看工具的报错域名信息
⬇️

3.小程序后台的服务器域名填写处添加工具里报错的域名

# wx:if

有更高的切换消耗

• 条件值切换，有一个局部渲染的过程，因为它会确保条件块在切换时销毁或重新渲染
• 惰性的，在隐藏的时候不渲染，如果在初始渲染条件为 false,则在条件第一次变成真的时候才开始局部渲染

适用场景：运行时条件不大可能改变

商业模式考量

灵感的诉求与竞品分析

• 保持对同类型产品，或者同领域竞品的产品的持续关注度。（对大多数情况，市面上已经有可以借chao鉴xi的产品或者部分模块，不要想着发明原创的产品模型，很大可能是对产品的研究还太少。）

产品设计

• 5个模块左右在设计阶段尽量在2个月以上（再穷也要有至少1个产品经理，把时间拉长，UI可以让产品经理招外包）