有时候我们使用一个小程序会遇到以下情形： 我们打开一个小程序，就看见提示“分享到5个群，可以获得一张20元的优惠券”，吸引我们去无脑分享到不同的群里； 打开某个小游戏，提示我“一定要分享到xx个群，才能继续玩游戏”； …… 而我们在群里打开这类小程序，仍然是提示我分享的信息，这类功能无疑打断了我们对小程序/小游戏正常的功能使用。 我们收到了很多用户对这类小程序/小游戏的抱怨。这类分享并非是用户主动自发的，而是受到了某类利益的诱惑，或是被迫分享。这样的内容充斥在群里、小程序里，对用户造成了骚扰，是对分享功能的滥用。 在原来的分享接口中，用户发起分享动作之后，可以通过 success 、fail、complete等回调来判断用户是否完成了最后的分享动作。通过这个能力，开发者是可以将产品交互在分享这个能力上做得比较自然和顺畅。但却被上述情形的小程序滥用。在我们权衡了分享功能带来的利弊后，我们打算回收这个能力。调整为：我们将不再支持分享回调参数 success 、fail 、complete 。即开发者无法判断用户最终是否完成了分享动作，也无法获取到分享成功后的回调参数shareTicket 。 接下来将与大家介绍此次分享功能调整后，小程序的调整建议。 对应小程序调整建议 此次调整可能影响到两种分享功能的用法。 第一种：通过判断用户最终是否有分享来做分支逻辑的小程序。 例如，通过判断 success 回调触发，来判断用户是否分享出去了，进而给奖励，如果用户没有分享出去则不给奖励。这类功能是我们平台不倡导的，后续将没有办法实现。 如果是需要在分享完成后变更当前页面的状态，可以适当调整交互方案。例如过去赠送代金券后显示“等待领取”等应用场景，可以改成在分享后继续保留“赠送”按钮，但提示用户一个代金券只能被一人领取，重复赠送无效。 第二种：获取用户分享之后的 shareTicket ，换取群唯一标识 openGId ，进而显示对应群的相关信息的小程序。 例如，部分小程序实现了群内的排行信息，通过分享小程序到某个群里，可以查看该群内成员的排行榜。 此次调整后，用户分享完成后无法立刻显示该群的排行榜信息，但仍可在用户从群消息点击进入小程序时显示该群的排行榜信息。 因此建议适当修改产品流程，在用户分享小程序之时，提示用户可进入群内查看群排行等信息。避免调整策略生效之后带来的交互不完整影响。 调整覆盖范围提示 近期新提交的版本中将会受到此策略的影响。 除此之外，调整策略在即将发布的基础库版本 2.3.0 生效，该基础库版本对应本月即将发布的微信客户端版本（暂定版本号 6.7.2）。即：近期提交审核的小程序版本，在基础库版本 2.3.0 以下的环境中仍不受此策略影响，仅在基础库版本 2.3.0 以上的环境受影响。 开发者需要注意，近期提交审核的版本都需要考虑兼容上述调整带来的影响，请各位开发者及时调整分享能力。

小程序和小游戏内的用户登录，我们推荐使用以下两种方式获取用户信息： ▷ 按钮组件的登录方式，用户主动点击按钮可以拉起用户授权弹框，获取用户头像、昵称等信息； ▷ 在不获取用户信息的情况下，可展示用户头像昵称。 用户在没有任何操作的情况直接弹出授权的登录方式将逐渐不再支持，受影响的有 wx.getUserInfo 接口，以及 wx.authorize 接口传入 scope="scope.userInfo" 的情况。 1 为什么平台要做接口调整？ 我们提供了 wx.login 和 wx.getUserInfo 接口，用于获取用户的 openID 和基本信息。 推出这两个接口的初衷是希望：当用户使用小程序时，只有访问到真正需要登录的页面，才需要授权并登录。 但在实际应用中，我们发现很多开发者在打开小程序时直接弹出授权框，如果用户点击拒绝授权，无法使用小程序。 在没有任何提示和背景的情况下，直接弹框想要获得用户信息授权，用户脑子里可能会闪过几个哲学问题： 你是谁？ 我在哪里？ 我为什么要同意？ …… 相当一部分用户下意识会点击“拒绝“授权——这样不合理的登录流程既造成了用户的困扰，还使得用户流失。 用户通过小程序可以快速获取服务，因此在访问小程序的第一个页面非常重要。 对于一个互联网产品而言，第一个页面决定了用户对这个产品的认知，用户会选择是否继续使用这个产品。 一个优秀的互联网产品，能够给用户留下一个好的第一印象，用户可以快速了解你的产品，接收到你想要传递的服务信息，从而产生相应的操作行为。 一个优秀的小程序会吸引用户在小程序里进行探索，完成你期望他们去做的事，比如会员注册、商品购买等。 试想一下如果一个品牌的商品官网，一进入要求用户登录才能查看产品信息是什么感觉呢？ 因此良好的用户登录体验非常重要。 2 如何设计登录流程？ 用户打开小程序时，看第一眼的时候，开发者需要专注以下两个目标： ▷ 精准快速地传达产品理念，开发者要让用户能够快速了解自己的产品和服务； ▷ 将用户流量进行转化，让用户能方便操作或者交易。 一般而言，用户打开小程序后看到的第一个页面，先不要直接弹出授权框，第一个页面可以包含以下内容： ▷ 展示你的小程序功能（如产品、服务、活动等） ，让用户清晰地知道小程序是做什么用的，这些内容可以是你的精选内容； ▷ 激发用户的探索欲，通过描述或者图片吸引用户注意力； ▷ 按照自己的产品目标，给用户提供清晰明确的下一步操作（查看详情、购买等）。 如果某些特殊小程序在使用前一定需要用户登录，或者已经进行到需要用户登录的操作时，可以将 button 组件（其中 open-type 属性指定为 getUserInfo）放置到页面中，页面上可以大致说明以下要点： 为什么需要我授权？ 需要我什么信息？ 授权后我得到什么好处呢？ 接下来在页面上放置一个明显的登录按钮， 建议这个页面上不要有额外的点击区域，以免分散用户注意力，让用户专注于登录这件事情。 3 简单的开发建议 1 当用户打开小程序时访问第一个页面时，先通过 wx.login，获取用户 openID 。这时无需弹框授权，开发者拿到 openID 可以建立自身的帐号 ID。 2 在第一步中，拿到 openID 后，判断是新用户还是老用户。如果是老用户，可以直接登录；如果是新用户，可先在小程序首页展示你的信息服务，让用户对这个小程序有大概的了解，再引导用户进行下一步的操作。 3 当需要获取用户头像昵称的时候，对用户展示一个登录页面，这个页面只有一个最重要的操作，引导用户进行登录。 小程序中，在页面中加入一个 button 按钮，并将 open-type 属性设置为 getUserInfo 。 以小程序为例： 微信登录 对于功能较简单的小程序或者小游戏而言，如果不是必须要获得用户的头像昵称，建议可先通过wx.login 拿到 openID 后，使用 open-data 方式或者开放数据域的方式展示用户信息，整个过程都无需用户授权。 Tips： 1、在用户登录后，开发者需要存储用户的 unionID，而且建议只把 unionID 作为互通的用户标识，不要直接使用 unionID 作为用户 ID。因为一旦小程序迁移到其他的开放平台下，unionID 是会改变的，而 openID 是不变的。 2、用 button 组件的方式获得用户授权后，调用 wx.getUserInfo 就可以直接获取用户信息。这个的意义在于获取过一次之后，用户有可能改昵称头像，因此为了及时同步，最好是定期获取用户信息。 这里两个小提示： ▷ 定期使用 wx.getUserInfo 获取并更新用户的信息； ▷ 如果用户授权过一次之后，又在设置中关掉了授权（或者本地删除了小程序），那这时再调用 wx.getUserInfo 也是不会成功的，需要重新获得授权。 相关开发文档参考： ▷ 小程序 1、小程序 wx.login 2、button 组件，并将 open-type 指定为 getUserInfo 类型，获取用户基本信息 3、open-data 展示用户基本信息 ▷ 小游戏 1、小游戏 wx.login 2、用户信息按钮 UserInfoButton 3、开放数据域下的展示用户信息

小程序的界面是由一系列组件构成的。小程序基础库提供了一组基础组件来满足开发者的基本需求。但随着小程序开发变得越来越复杂，单纯使用基础组件来进行开发也变得越来越不方便。 例如，较为复杂的小程序中常常会有一些通用的交互模块，比如“下拉选择列表”、“搜索框”、“日期选择器”等。这些界面交互模块可能会在多个页面中用到，逻辑也相对独立。然而，用传统的小程序开发方法来实现这样的模块是非常繁琐的。 面对这个情况，小程序基础库提供了让开发者自己创建界面组件的特性，称之为“自定义组件”。通过这个特性，开发者就能够将这样的交互模块抽象成界面组件，使界面代码组织变得非常灵活。 01 [图片]开发者可以将一些复用性强的代码抽象成自定义组件，它们的使用方法与基础库内置的 view 、 button等基础组件非常相似。这样的组件化非常有利于代码逻辑的解耦合。 02 [图片]自定义组件局部更新时的性能相比页面的局部更新要小很多，在必要时可以利用这个特点进行性能优化。 03 [图片]自定义组件是相对独立的功能模块，开发者可以将自己的自定义组件代码开源出来，与其他开发者共享开发成果。 如何编写一个自定义组件？ 每个自定义组件由四个代码文件组成：  json文件    用于于放置一些最基本的组件配置  wxml 文件    组件模版  wxss 文件    组件的样式，只在组件内部节点上生效（这个文件是可选的） js 文件  组件的 JS 代码，承载组件的主要逻辑 这四个文件与编写一个页面时用到的四个文件非常类似，但也有区别。下面将介绍如何利用这四个文件编写一个简单的自定义组件。 1.组件配置 编写一个自定义组件，首先应在小程序代码目录中合适的位置创建一个 json 文件。这里我们把文件放置在小程序的 components目录下，名为 custom-checkbox.json 。 [图片] 这个文件中包含以下内容： [图片] 2.组件模板 在同一目录下，创建一个模版文件 custom-checkbox.wxml 。这个文件的写法与页面模版很类似： [图片] 这个模版将在组件中渲染出一个 checkbox 和一个 label 。 3.组件样式 同样类似于页面， wxss 文件中可以指定组件节点的样式。其中的样式仅在组件内部生效。需要注意的是，样式只能通过类选择器（如 .the-class-name ）来指定： [图片] 4.组件定义 组件的 JS 文件中必须包含组件定义。定义时使用 Component 构造器： [图片] 简单的 Component 构造器调用包含3个定义段： methods 中的方法可以用来包含组件的事件回调函数； data 是组件的内部数据，可以用 this.setData 方法来改变； properties 中声明这个组件的属性，上例中声明了 title 属性，这样，组件外部在使用组件时就可以指定这个属性的值。 这样我们就编写好了 custom-checkbox 这个组件。 如何使用自定义组件？ 使用上面这个自定义组件的方法很简单。 Step 1 在需要使用这个组件的页面所对应的 json 文件中，添加下面的自定义组件声明： [图片] Step 2 在页面对应的 wxml 文件中使用了： [图片] 这样，在页面上最终呈现的效果如下： [图片] 在自定义组件中也是可以引用其他自定义组件的，方法与在页面中引用的方法类似。 高级特性与注意事项 除了上述的基本功能外，自定义组件还提供了一组基础接口，用来实现各种各样的功能。 01 [图片]在页面和自定义组件间通信时，最常用的方法是事件机制，自定义组件可以使用 triggerEvent 接口向页面发送事件，页面 WXML 中使用 bind 或者 catch 就可以监听到。 02 [图片]如果事件机制还不足以满足组件间通信需要的话，可以使用  selectComponent 接口。 03 [图片]如果同时建立了好几个有相互关联关系的组件，可以使用组件间关系接口 relations 。 04 [图片]组件间可能需要共享部分代码，这时可以使用behaviors 。 有关它们的详细文档，请参考 开发者文档 - 框架 - 自定义组件 章节。 还需要注意的是，一些与 WXML 节点相关的接口，如wx.createSelectorQuery  、 wx.createCanvasContext ，在自定义组件中使用时有一定的变化，使用时请再次阅读一下相关的文档。