小程序即时通讯模板，目前已提供WebSocket通信功能示例。 [图片]

为更好地保护用户隐私信息，优化用户体验，平台将会对小程序内的帐号登录功能进行规范。本公告所称“帐号登录功能”是指开发者在小程序内提供帐号登录功能，包括但不限于进行的手机号登录，getuserinfo形式登录、邮箱登录等形式。具体规范要求如下： 1．服务范围开放的小程序 对于用户注册流程是对外开放、无需验证特定范围用户，且注册后即可提供线上服务的小程序，不得在用户清楚知悉、了解小程序的功能之前，要求用户进行帐号登录。 包括但不限于打开小程序后立即跳转提示登录或打开小程序后立即强制弹窗要求登录，都属于违反上述要求的情况； 以下反面示例，在用户打开小程序后立刻弹出授权登录页； [图片] 建议修改为如下正面示例形式：在体验小程序功能后，用户主动点击登录按钮后触发登录流程，且为用户提供暂不登录选项。 [图片] 2．服务范围特定的小程序 对于客观上服务范围特定、未完全开放用户注册，需通过更多方式完成身份验证后才能提供服务的小程序，可以直接引导用户进行帐号登录。例如为学校系统、员工系统、社保卡信息系统等提供服务的小程序；  下图案例为正面示例：校友管理系统，符合规范要求。 [图片] 3．仅提供注册功能小程序 对于线上仅提供注册功能，其他服务均需以其他方式提供的小程序，可在说明要求使用帐号登录功能的原因后，引导用户进行帐号注册或帐号登录。如ETC注册申请、信用卡申请； 如下反面示例，用户在进入时未获取任何信息，首页直接强制弹框要求登录注册ETC，这是不符合规范的。 [图片] 建议修改为如下正面示例所示形式：允许在首页说明注册功能后，提供登录或注册按钮供用户主动选择点击登录。 [图片] 4．提供可取消或拒绝登录选项 任何小程序调用帐号登录功能，应当为用户清晰提供可取消或拒绝的选项按钮，不得以任何方式强制用户进行帐号登录。 如下图所示反面示例，到需要登录环节直接跳转登录页面，用户只能选择点击登录或退出小程序，这不符合登录规范要求。 [图片] 建议修改为下图正面示例形式，在需帐号登录的环节，为用户主动点击登录，并提供可取消按钮，不强制登录。 [图片] 针对以上登录规范要求，平台希望开发者们能相应地调整小程序的帐号登录功能。如未满足登录规范要求，从2019年9月1日开始，平台将会在后续的代码审核环节进行规则提示和修改要求反馈。

在小程序生态中，基于苹果运营规范，小程序内暂不支持iOS端虚拟支付业务。为此小编为大家整理了一份虚拟支付业务指南，希望大家在做虚拟业务时有所帮助： [视频] 那么，到底什么是虚拟支付业务呢？ 虚拟支付业务是指购买非实物商品。比如：VIP会员、充值、录制课程、录制音频视频等虚拟产品。目前iOS端暂不支持虚拟支付业务。   我们常见iOS虚拟支付的不合规示例有哪些呢？ 示例一 ：小程序内存在付费购买虚拟内容或道具。商品多体现为提前编辑好的、录制好的虚拟商品。如录制视频课程、游戏道具。 整改建议 ：建议去除小程序内所有付费购买虚拟服务，并根据提示修改相关内容及文案，文案可参照“由于相关规范，iOS功能暂不可用”。 [图片]   示例二 ：付费解锁优质服务。多体现为提供虚拟商品的小程序可通过支付购买、开通虚拟会员等形式，体验小程序付费服务。比如：支付阅读章节小说、同城生活服务平台付费发帖/付费置顶等。 整改建议 ：建议可以关闭iOS端虚拟支付通道，并将【马上充值】更改为【由于相关规范，iOS功能暂不可用】，并不再提供iOS端会员服务。 [图片]   示例三 ：关闭iOS端虚拟支付功能后，虚拟商品页面仍然保留货架价格标签展示、购买/付费/订阅等功能或按钮。 整改建议 ：建议去除小程序中的虚拟商品的价格展示，并更改为【免费】；并将【订阅 ¥128】更改为【由于相关规范，iOS功能暂不可用】，并不再提供iOS端虚拟商品购买服务。 [图片]   示例四 ：关闭iOS端虚拟支付功能后，提供引导用户前往其他支付的路径/文案，完成虚拟支付闭环。 整 改建议 ：建议去除iOS端小程序内引导用户前往其他支付路径/文案，并不再提供iOS端虚拟商品购买服务。 [图片]   示例五 ：小程序含需要付费的虚拟商品，并设置限时免费的服务，限时免费结束后需付费才能继续提供服务。 整改建议 ：建议将iOS端小程序中所有虚拟付费内容更改为免费，并不再提供iOS端虚拟商品购买服务。 [图片]   示例六 ：关闭iOS端虚拟支付功能后，小程序中虚拟产品页面不可以含有付费性质的关键字（如：购买、已购、付费、支付等），包括但不限于功能按钮、功能页面、支付提示及任何商品介绍等。 整改建议 ：建议将小程序iOS端虚拟产品页面中的文案/按钮/功能tab含有限制的关键字更改为【免费】或删除。并不再提供iOS端虚拟商品购买服务。 [图片] 如小程序内存在以上不合规的虚拟支付内容，请开发者重视并及时整改。对于首次违规的小程序，平台将下发站内信整改通知，并给予三天整改时间，请开发者按照提示在限期内完成整改。平台将会对到期未完成整改的小程序进行搜索策略调整，并在小程序功能使用上进行一定的限制，直到小程序完成内容整改。

再次开始之前先问几个问题： 你是否知道[代码]Page[代码]生命周期 与 [代码]pagelifetimes[代码] 生命周期执行顺序? 你是否知道[代码]behaviors[代码]中的生命周期与组件生命周期执行顺序? 你是否知道[代码]Page[代码]生命周期 与 组件[代码]pagelifetimes[代码]生命周期执行顺序? 要回答上面的问题，首先我们看看小程序生命周期有哪些： App onLaunch onShow onHide Page onLoad onShow onReady onHide onUnload Component created attached ready moved detached 想一下加载一个页面（包含组件）的加载顺序，按照直觉小程序加载顺序应该是这样的加载顺序（以下列子中[代码]Component[代码]都是同步组件）： App（onLaunch） -> Page(onLoad) -> Component(created) 但其实并不然，小程序的加载顺序是这样的： 首先执行 [代码]App.onLaunch[代码] -> [代码]App.onShow[代码] 其次执行 [代码]Component.created[代码] -> [代码]Component.attached[代码] 再执行 [代码]Page.onLoad[代码] -> [代码]Page.onShow[代码] 最后 执行 [代码]Component.ready[代码] -> [代码]Page.onReady[代码] 其实也不难理解微信这么设计背后的逻辑，我们先看下官方的的生命周期： [图片] 可以看到，在页面[代码]onLoad[代码]之前会有页面[代码]create[代码]阶段，这其中就包含了组件的初始化，等组件初始化完成之后，才会执行页面的[代码]onLoad[代码], 之后页面[代码]ready[代码]事件也是在组件[代码]ready[代码]之后才触发的。 下面我们来看看 [代码]Behavior[代码], [代码]Behavior[代码] 与 [代码]Vue[代码]中的 [代码]mixin[代码] 类似，猜想下其中的执行顺序： Behavior.created => Component.created 测试下来和预期相符，其实在[代码]Vue[代码]的文档中有一段这样的描述： 另外，混入对象的钩子将在组件自身钩子之前调用。 这样的设计和主流设计保持一致。接下来我们看看 [代码]pageLifetimes[代码],有[代码]show[代码]和[代码]hide[代码]生命周期对应页面的展示与隐藏，预期的执行顺序： pageLifetime.show => Page.onShow 测试下来也和预期相符，那么我们可以推断出如下的结论： 当页面中包含组件时，组件的生命周期(包括pageLifetimes)总是优先于页面，[代码]Behaviors[代码]生命周期优先于组件的生命周期。但其实有个例外：页面退出堆栈，当页面[代码]unload[代码]时会执行如下顺序： Page.onUnload => Component.detached 看了以上的分析你应该知道了答案，最后做个总结（demo）： [图片] 最后的最后布置个作业 异步组件（异步渲染的组件，通常是通过if条件判断是否渲染）的生命周期执行顺序是怎样的，pagelifetimes会不会执行？