uni-app开发微信小程序,《小程序隐私协议开发指南》开发方案,wx.getPrivacySetting,wx.onNeedPrivacyAuthorization方法使用。

弹窗 代码插件已集成,即插即用,五分钟集成进项目,下方链接免费下载,欢迎大家评论交流 

---

微信小程序用户隐私保护协议弹窗插件下载

一.隐私协议开发

关于小程序隐私协议开发， 官方最近给出了3个Demo，3种实现方式根据业务流程选择：

Demo1: 演示使用 wx.getPrivacySetting 和 <button open-type=“agreePrivacyAuthorization”> 在首页处理隐私弹窗逻辑 https://developers.weixin.qq.com/s/gi71sGm67hK0

Demo2: 演示使用 wx.onNeedPrivacyAuthorization 和 <button open-type=“agreePrivacyAuthorization”> 在多个页面处理隐私弹窗逻辑，同时演示了如何处理多个隐私接口同时调用。 https://developers.weixin.qq.com/s/4X7yyGmQ7EKp

Demo3: 演示 wx.onNeedPrivacyAuthorization、wx.requirePrivacyAuthorize、<button open-type=“agreePrivacyAuthorization”> 和 <input type=“nickname”> 组件如何结合使用 https://developers.weixin.qq.com/s/jX7xWGmA7UKa

Demo1

以上几种情况就可以使用demo1, 在小程序启动时做检查，没授权就弹窗，用户不同意就退出；

或者对于极简小程序，比如就一个页面点击按钮选个图片，可以在处理按钮事件时调用wx.getPrivacySetting。弹窗后用户不同意就啥也不干或给个toast，下次用户再点按钮就再检查再弹窗。

• 这个是最简单的。调用的隐私协议接口最少，只有一个wx.getPrivacySetting。（wx.openPrivacyContract不算）。
  其逻辑就是在调用任何隐私接口之前检查授权状态，已授权则啥也不做，未授权则弹窗。

• 特点：开发者主动检查后弹窗，而不是隐私接口调用触发。

• 简单，代码量最少。

• 流程：主动检查->弹窗->用户同意->调用隐私接口

• 适用场景：
• 小程序启动过程没有调用隐私接口，换句话说，隐私接口需要由用户动作才会调用，如用户点击按钮选择图片。
• 强隐私需求小程序，用户不给授权就不能用，直接退出那种。
• 极简小程序，比如就一个页面，或者就只调用一个隐私接口。   

Demo2

• demo2就复杂一些了，需要用到wx.onNeedPrivacyAuthorization接口了，和demo1的区别就是，弹窗是由调用隐私接口触发的，而不是开发者主动检查触发

  • 特点：
• 弹窗是由调用隐私接口触发。
• 复杂，代码量多。
• 流程：调用隐私接口->弹窗（同时隐私接口pending）->用户同意/不同意->隐私接口返回成功或失败
• 适用场景：
• 普遍场景，多个页面，多个隐私接口。
• 被动触发，无需关心隐私接口何时被调用。

Demo3

• demo3在demo2的基础上，就多了wx.requirePrivacyAuthorize调用，官方说法是这个接口用来模拟隐私接口调用。

• 特点：

1. 弹窗可以由调用隐私接口触发，也可以由wx.requirePrivacyAuthorize触发
2. 复杂，代码量多。
3. 流程：调用隐私接口（wx.requirePrivacyAuthorize）->弹窗（同时隐私接口pending）->用户同意/不同意->隐私接口返回成功或失败
4. 相较于demo1，相同的地方在于开发者可主动触发隐私弹窗，不同的地方在于demo3更复杂一些
5. 相较于demo2，相同的地方在于其逻辑和调用真实隐私接口是一致的，不同之处在于给开发者提供了一种更灵活的可主动触发弹窗的模式
6. 你可以认为 demo3=demo1 + demo2

• 适用场景：

1. 同demo2。
2. 无接口的隐私组件，如<input type=“nickname”>
3. 比demo2更灵活的需求.

对于wx.requirePrivacyAuthorize接口，大家不要把这个接口局限于仅在开发时调试用。这个接口也是可以用在线上的。可以用来实现更灵活的逻辑。

以上就是我对这3个demo的理解，大家有什么样的想法欢迎在评论区留言大家一起讨论。