1：用户扫码进入公众号 2：然后微信通知到我的接口 3：我在我写的接口里怎么回复小程序卡片？

总体描述问题: 移动端微信分享公众号网页出现纯网址,没有卡片,没有标题,描述和图片的情况 pc端网页分享目前为止均为卡片且能正常分享图片,描述和标题 此外,通过成功分享的卡片进入页面后再次分享也均为卡片(分享成功的卡片来自pc端分享), 通过链接进入页面分享却无一例外均为链接 =========================================================== 详细情况描述: 1.公众号已经授权域名,开放平台也绑定了公众号 2.公众号有分享成功的网页,但同样的网页也会出现分享只有链接的情况(连卡片也没有,就只有链接) 3.通过分享成功的卡片进入网页似乎不会出现分享只有链接的情况 4.pc端分享目前为止均为正常的卡片形式 5.jweixin版本:1.6 安卓微信客户端: 8.0.16.2040 安卓版本: 11 6.微信开发者工具内不论使用新版本接口或旧版本接口均显示成功 ============================================================ 如图: 1.代码情况如下,不论新旧接口均会产生上述现象, 也试过单独使用新接口和旧接口的写法, 未生效 使用新接口分享给qq和qq空间均能正常显示卡片,微信和朋友圈却不行 [图片] [图片] -------- 2.如图所示,微信开发者工具内console如下 [图片] -------------- 3.由网址进入页面进行分享的异常情况 [图片] 4.由分享成功的卡片进入分享的正常情况 [图片] ----------------- 5.pc端内分享展示的情况,其中白色的网址信息为上述异常分享,绿色的网址信息为单纯的复制链接 [图片] ------------- 6.微信安卓端内展示的分享情况 [图片]

https://m.yijiadc.com/lianxiwomen/

原因是H5用旧的方式申请JSAPI分享权限，后台返回无权限，因此分享的时候不能自定义，建议开发者接入新的分享方式：https://developers.weixin.qq.com/doc/offiaccount/OA_Web_Apps/JS-SDK.html ，使用新的wx.updateAppMessageShareData和wx.updateTimelineShareData接口来设置分享数据。

我使用手机端分享文章发送给朋友，之前是正常，今天发现标题，图片，描述都没有了，但我用PC端微信分享又是正常的，这是什么原因啊？？？ 图1是手机端分享的，图2图3是电脑端分享的 [图片] [图片] [图片]

微信小程序开发调用腾讯地图接口（如图所示），是免费使用的吗? [图片]

目前收到电话通知地图要收费，但是收费是全部收费，还是部分功能收费。如果只是调用wx.getLocation、wx.chooseLocation这2个接口也是收费项目吗？

[图片] 小程序中没有使用key调用腾讯地图api，腾讯打电话说检测到我们使用他们的服务，商用需要交钱，想咨询一下，如果是微信小程序第三方平台和插件引入了腾讯位置服务，是会影响商用吗？

我们是一家新加坡科技公司。有自己的App，主要业务是通过App，面向来新加坡的外籍观光客代理销售新加坡国内各热门景点门票，如新加坡环球影城等。 为拓展中国市场，面向来新加坡的中国大陆籍观光客销售新加坡本地的景点门票，希望在微信上开发自己的小程序。现在有两个问题： 经了解自去年九月开始，微信要求新上架小程序必须完成备案，但在这个社区搜索看到，对于境外主体，暂时不需要备案，可正常上架运营。请问到现在为止(24年6月份)，对境外主体开发运营的小程序关于备案方面的要求，是否有变化？如果现在境外主体的小程序也需要备案的话，需要提供哪些相关材料？我们和各个景点是代理销售的关系，我们的App和小程序并非入驻平台，所售旅游产品均为自营，需要用到微信支付，请问在这种情况下，在注册和运营小程序时，是否需要提供ICP经营许可证？谢谢

实测现提供小程序是面向普通用户开放的，请补充提供适用员工登陆并获取资金的转账场景所在APP/小程序/公众号名称及appid、网站链接（如需登录，请提供测试账号、密码），原因是这个，不知道要怎么样才能调整，有些看不太懂了，还是说要放一些购物网站什么的？

请问大家微信商户平台的商家转账到零钱功能，在转账过程中产生的个人所得税怎么缴纳呀？是让用户自己缴纳还是商户缴纳又或是微信商户平台代扣呢？

场景：目前做了分销的功能，然后将奖励统一发放到定制化小程序的佣金账户里，分销员可进行提现，提现后，使用商家转账到微信零钱的API直接给分销员将佣金打到微信钱。 问题：想问下这种形式，需要商家给用户代缴税吗？

小程序认证主体和网站ICP备案主体不一致，会不会影响小程序的备案？

场景： 移动应用对应的开放平台的open账号由open账号A变更为open账号B后，这个移动应用的appid除了关联open账号A下的微信商家商户号外，还关联了新的open账号B下的微信商家商户号，那支付的时候要怎么切换商户号？

根据业务情况，想实现从不同产品由不同的微信商户号进行收单，现有渠道服务商合作，请问可行吗？要怎么实现？

一个微信小程序可以绑定多少个商户号，主体不同的商户号可以实现分开支付么？

[图片][图片][图片][图片][图片] [图片][图片] 问一下各位大佬这是怎么回事啊，想要的链接，无法传到另一个网页上

公众号已经与小程序进行关联，现在想咨询一下小程序可以直接跳转关联号的公众号吗？

大家有遇到业务场景是 在给用户推送订阅消息后，需要通过点击订阅消息可以直接跳转到外部【非本小程序】的H5网页链接吗？ 例如下方的订阅消息，用户在点击订阅消息后，可以直接进入外部的H5链接？ [图片] 因为在查看订阅消息的开发文档后发现，对于跳转的控制是限制在【本小程序】才行的，这样是不是意味着不能够完成这个场景？ [图片] 或者大家有其他的能达到相应场景的配置吗？

业务场景是这样的 我们集团公司 每个分公司都有一个主体和对应的公众号 我们现在要统一开发一个小程序服务每个分公司的公众号 这样就 涉及到了用户统一的问题业务场景是这样的 我们集团公司 每个分公司都有一个主体和对应的公众号 我们现在要统一开发一个小程序服务每个分公司的公众号 这样就 涉及到了用户统一的问题

智能名片小程序创建名片页的表单校验使用正则表达式整理[图片] 正则表达式数据来源常用数字校验数字:^[0-9]*$ n位的数字:^\d{n}$ 至少n位的数字:^\d{n,}$ m-n位的数字:^\d{m,n}$ 零和非零开头的数字:^(0|[1-9][0-9]*)$ 非零开头的最多带两位小数的数字:^([1-9][0-9]*)+(\.[0-9]{1,2})?$ 带1-2位小数的正数或负数:^(\-)?\d+(\.\d{1,2})$ 正数、负数、和小数:^(\-|\+)?\d+(\.\d+)?$ 有两位小数的正实数:^[0-9]+(\.[0-9]{2})?$ 有1~3位小数的正实数:^[0-9]+(\.[0-9]{1,3})?$ 非零的正整数:^[1-9]\d*$ 或 ^([1-9][0-9]*){1,3}$ 或 ^\+?[1-9][0-9]*$ 非零的负整数:^\-[1-9][]0-9"*$ 或 ^-[1-9]\d*$ 非负整数:^\d+$ 或 ^[1-9]\d*|0$ 非正整数:^-[1-9]\d*|0$ 或 ^((-\d+)|(0+))$ 非负浮点数:^\d+(\.\d+)?$ 或 ^[1-9]\d*\.\d*|0\.\d*[1-9]\d*|0?\.0+|0$ 非正浮点数:^((-\d+(\.\d+)?)|(0+(\.0+)?))$ 或 ^(-([1-9]\d*\.\d*|0\.\d*[1-9]\d*))|0?\.0+|0$ 正浮点数:^[1-9]\d*\.\d*|0\.\d*[1-9]\d*$ 或 ^(([0-9]+\.[0-9]*[1-9][0-9]*)|([0-9]*[1-9][0-9]*\.[0-9]+)|([0-9]*[1-9][0-9]*))$ 负浮点数:^-([1-9]\d*\.\d*|0\.\d*[1-9]\d*)$ 或 ^(-(([0-9]+\.[0-9]*[1-9][0-9]*)|([0-9]*[1-9][0-9]*\.[0-9]+)|([0-9]*[1-9][0-9]*)))$ 浮点数:^(-?\d+)(\.\d+)?$ 或 ^-?([1-9]\d*\.\d*|0\.\d*[1-9]\d*|0?\.0+|0)$ 常用字符校验汉字:^[\u4e00-\u9fa5]{0,}$ 英文和数字:^[A-Za-z0-9]+$ 或 ^[A-Za-z0-9]{4,40}$ 长度为3-20的所有字符:^.{3,20}$ 由26个英文字母组成的字符串:^[A-Za-z]+$ 由26个大写英文字母组成的字符串:^[A-Z]+$ 由26个小写英文字母组成的字符串:^[a-z]+$ 由数字和26个英文字母组成的字符串:^[A-Za-z0-9]+$ 由数字、26个英文字母或者下划线组成的字符串:^\w+$ 或 ^\w{3,20}$ 中文、英文、数字包括下划线:^[\u4E00-\u9FA5A-Za-z0-9_]+$ 中文、英文、数字但不包括下划线等符号:^[\u4E00-\u9FA5A-Za-z0-9]+$ 或 ^[\u4E00-\u9FA5A-Za-z0-9]{2,20}$ 可以输入含有^%&',;=?$\"等字符:[^%&',;=?$\x22]+ 禁止输入含有~的字符:[^~\x22]+ 一些套路Email地址:^\w+([-+.]\w+)*@\w+([-.]\w+)*\.\w+([-.]\w+)*$ 域名:[a-zA-Z0-9][-a-zA-Z0-9]{0,62}(\.[a-zA-Z0-9][-a-zA-Z0-9]{0,62})+\.? InternetURL:[a-zA-z]+://[^\s]* 或 ^http://([\w-]+\.)+[\w-]+(/[\w-./?%&=]*)?$ 手机号码:^(13[0-9]|14[5|7]|15[0|1|2|3|4|5|6|7|8|9]|18[0|1|2|3|5|6|7|8|9])\d{8}$ 电话号码("XXX-XXXXXXX"、"XXXX-XXXXXXXX"、"XXX-XXXXXXX"、"XXX-XXXXXXXX"、"XXXXXXX"和"XXXXXXXX):^(\(\d{3,4}-)|\d{3.4}-)?\d{7,8}$ 国内电话号码(0511-4405222、021-87888822):\d{3}-\d{8}|\d{4}-\d{7} 电话号码正则表达式(支持手机号码,3-4位区号,7-8位直播号码,1-4位分机号): ((\d{11})|^((\d{7,8})|(\d{4}|\d{3})-(\d{7,8})|(\d{4}|\d{3})-(\d{7,8})-(\d{4}|\d{3}|\d{2}|\d{1})|(\d{7,8})-(\d{4}|\d{3}|\d{2}|\d{1}))$) 身份证号(15位、18位数字),最后一位是校验位,可能为数字或字符X:(^\d{15}$)|(^\d{18}$)|(^\d{17}(\d|X|x)$) 帐号是否合法(字母开头,允许5-16字节,允许字母数字下划线):^[a-zA-Z][a-zA-Z0-9_]{4,15}$ 密码(以字母开头,长度在6~18之间,只能包含字母、数字和下划线):^[a-zA-Z]\w{5,17}$ 强密码(必须包含大小写字母和数字的组合,不能使用特殊字符,长度在 8-10 之间):^(?=.*\d)(?=.*[a-z])(?=.*[A-Z])[a-zA-Z0-9]{8,10}$ 强密码(必须包含大小写字母和数字的组合,可以使用特殊字符,长度在8-10之间):^(?=.*\d)(?=.*[a-z])(?=.*[A-Z]).{8,10}$ 日期格式:^\d{4}-\d{1,2}-\d{1,2} 一年的12个月(01~09和1~12):^(0?[1-9]|1[0-2])$ 一个月的31天(01~09和1~31):^((0?[1-9])|((1|2)[0-9])|30|31)$ 钱的输入格式: 有四种钱的表示形式我们可以接受:"10000.00" 和 "10,000.00", 和没有 "分" 的 "10000" 和 "10,000":^[1-9][0-9]*$ 这表示任意一个不以0开头的数字,但是,这也意味着一个字符"0"不通过,所以我们采用下面的形式:^(0|[1-9][0-9]*)$ 一个0或者一个不以0开头的数字.我们还可以允许开头有一个负号:^(0|-?[1-9][0-9]*)$ 这表示一个0或者一个可能为负的开头不为0的数字.让用户以0开头好了.把负号的也去掉,因为钱总不能是负的吧。下面我们要加的是说明可能的小数部分:^[0-9]+(.[0-9]+)?$ 必须说明的是,小数点后面至少应该有1位数,所以"10."是不通过的,但是 "10" 和 "10.2" 是通过的:^[0-9]+(.[0-9]{2})?$ 这样我们规定小数点后面必须有两位,如果你认为太苛刻了,可以这样:^[0-9]+(.[0-9]{1,2})?$ 这样就允许用户只写一位小数.下面我们该考虑数字中的逗号了,我们可以这样:^[0-9]{1,3}(,[0-9]{3})*(.[0-9]{1,2})?$ 1到3个数字,后面跟着任意个 逗号+3个数字,逗号成为可选,而不是必须:^([0-9]+|[0-9]{1,3}(,[0-9]{3})*)(.[0-9]{1,2})?$ 备注:这就是最终结果了,别忘了"+"可以用"*"替代如果你觉得空字符串也可以接受的话(奇怪,为什么?)最后,别忘了在用函数时去掉去掉那个反斜杠,一般的错误都在这里 xml文件:^([a-zA-Z]+-?)+[a-zA-Z0-9]+\\.[x|X][m|M][l|L]$ 中文字符的正则表达式:[\u4e00-\u9fa5] 双字节字符:[^\x00-\xff] (包括汉字在内,可以用来计算字符串的长度(一个双字节字符长度计2,ASCII字符计1)) 空白行的正则表达式:\n\s*\r (可以用来删除空白行) HTML标记的正则表达式:<(\S*?)[^>]*>.*?|<.*? /> ( 首尾空白字符的正则表达式:^\s*|\s*$或(^\s*)|(\s*$) (可以用来删除行首行尾的空白字符(包括空格、制表符、换页符等等),非常有用的表达式) 腾讯QQ号:[1-9][0-9]{4,} (腾讯QQ号从10000开始) 中国邮政编码:[1-9]\d{5}(?!\d) (中国邮政编码为6位数字) IP地址:((?:(?:25[0-5]|2[0-4]\\d|[01]?\\d?\\d)\\.){3}(?:25[0-5]|2[0-4]\\d|[01]?\\d?\\d))

背景：在接触过上百家头部客户中，诊断和参与了数百次的数据体系搭建工作。几乎80%的App都没有科学的埋点规划，只采集显性数据，而更深层的与事件、参数相关的隐性数据，都没有采集到。埋点规划并不难！但为什么大部分企业都做的不太好？埋点规划需要整合产品、运营、技术和业务等跨部门的需求，运营同学不太懂技术、技术同学不太懂业务、产品同学不太懂埋点，这问题该如何解？在友盟+《战疫求生，开发者的危与机》直播公开课上，友盟+业务专家张跃梳理一套方法论。带你从埋点的坑、结构化的埋点方案、高效的事件管理入手进行结构化埋点。   一、           在埋点前，先带你避开埋点的深坑   第一坑：遗漏，指的是埋点采集不全面，有可能重要的数据并没有采集到，会对数据分析造成比较直接的影响，出现这个问题的原因是前期数据分析需求不清晰。   第二坑：杂乱。指的是数据采集比较零散，可以理解为前期并没有进行事件结构化的设计，通常是想到一个需求，就把这个需求提供给技术进行埋点。这种称之为“扁平化”的埋点方式，例如：某一个位置或者某一个功能的点击行为，就当做一个事件进行采集，看上去采集和查看很容易，但随着时间跟需求的增加，当采集了大量零散的事件之后，需要在统计工具中通过分组分析时，就会比较麻烦。   第三坑：低效。不同于杂乱，杂乱是任何行为数据都会直接当事件去进行采集，没有利用参数去进行结构化的设计。低效指的是在事件设计的时候，会去做结构化处理。但事件设计的参数逻辑会有问题，通常都是以大的页面这种框架的思维去进行设计。   举个例子：部分客户在设计时，会按照页面的思路去进行事件采集，页面上有推荐位，还有很多功能按钮的点击，那么就会把这个页面所有的点击行为都归到一个事件，并且点击具体的按钮和内容都当做参数传回来。但这里埋着两个雷区：1、在分析数据时，例如想了解整个用户浏览内容的情况，或者是想了解某个功能（搜索引擎）整体使用情况，按照如上设计，内容和功能的采集都分布在每一个事件中了，这样后面再归类、分析就非常不方便。2、当产品结构产生变化时，原有事件调整概率会比较大，因为之前都是按页面结构去设计，页面的调整直接影响事件采集。   第四坑：无用。指的是数据虽然采集了，但分析时根本用不上，这个问题主要有2个原因导致，一是前期需求不太清晰，另一个是之前的采集需求都是由不同人提出的，由于中间人员变动，很多采集需求就不清楚了，并且也不敢下掉，因为并不清楚这个事件是否还有人使用。   第五坑：复用。指的是事件重复采集，或者是需求重复，这个同样是与多个人提需求有关，并没有一个人去做整合管理，或者是说，没有一个工具去帮忙我们做管理。   二、如果想要避免这些坑，就需要坚守五个原则： 1、需求清晰。 2、合理设计。 3、实施规范。 4、结果可验 5、规范管理。     三、                    埋点方法论——五步一全（ODEIIC），需要多角色参与统筹决策   第一、需求梳理。在梳理埋点设计的时候，通常会以产品、运营和市场以及KPI三个视角去切入。通常，产品关注的核心业务点会聚焦在内容和功能上，运营和市场关注的业务点在拉新、留存、促活和转化上，KPI视角会聚焦在转化与收入上，但也需要根据客户的实际情况而定。   同时，会把不同视角的业务需求再转化成需要关注的核心数据，如产品运营在内容上所需要关注用户浏览、内容的转发或者是偏好，针对功能使用会关注注册、登录、搜索等这些功能的使用情况。 [图片]   业务需求拆解成核心数据后，针对每一个核心数据进行维度的细分，如内容方面：会按照标题、频道或者是标签，进行拆分分析。那么我们针对功能方面，会按照功能使用情况以及步骤的转化去进行分析。通过要分析的关键点，就可以把细分维度拆出来，最后还会再加上一些通用的维度，例如可以对单个用户或者某一个地区的用户进行深度分析。   以产品视角的需求样例，产品通常情况下会聚焦内容与功能上的使用，但在需求收集时都是分散和抽象的，例如：业务需要分析内容偏好和推荐效果以及内容受欢迎的程度。那在这个环节就需要先做需求拆解，也就是说要去找到能分析这个需求的核心数据与能够帮助判断业务变化的一些指标，细分维度在这里的作用更多的是做需求详细的拆解，可以理解为是去做核心数据的多维度明细展示，那么目的就是从更细的维度去满足业务分析需求；   总结：先要找到能满足这个需求的核心数据，再找到核心数据分析时所需要涉及的细分维度，如图：   [图片]   第二、事件设计。可以通过这3个步骤去完成事件的结构化设计，第一个步骤是要了解产品结构，也就是先要了解分析的范围是什么，例如需要知道对哪些页面或者哪些功能有分析需求；第二步，就是要针对这些锁定的范围，去明确我们要分析用户的行为有哪些；第三步，要把这些行为，落实到具体的分析维度上；   后面会通过指标体系、分析需求、分析方法这3个角度，在去结合这三个步骤，进行事件结构化设计的详细说明。   [图片] 在介绍按照指标体系去进行结构化事件设计前，我们先看下指标体系的样例，通常会按照这几个模块去搭建指标体系，分为：概况、营销、用户价值、运营和核心功能。 1、概况可以理解日常关注的核心数据，比如：新增、启动、日活、周活、月活以及会员数据、注册数据以及使用黏性、使用时长、留存等，还包括技术、产品较为关注的稳定性数据。总的来说：就是将核心或常看的数据放在概况的大板块中。   [图片] 2、营销。通常会把广告数据，例如：广告的曝光、点击率以及广告点击排行，媒体排行、展示排行信息会放在第二个板块。 3、用户价值。通常会把新用户的次留、成本以及用户回本周期模型和生命周期模型放在用户价值模块。   4、运营。主要关注内容与转化，通常会分析内容的热度，任务的交互与会员的转化，针对会员还会分析会员新增、会员累计、会员续费等维度。                                                                                                                                                                                                                                         5、核心功能。是产品岗位较为关注的，例如：导航位、导航按钮，被用户点击的情况、使用的情况，对应核心功能，比如说搜索功能或者是注册功能，整个功能的入口、被点击的情况和转化率等相关的这些数据会放到这个板块。   从指标体系到事件设计   [图片] 如何通过指标体系去进行结构化设计？指标体系可以理解为指标与报表的一个组合，整个指标体系对应到产品结构上，可以分为对产品页面和产品功能的分析需求。下面先从产品页面的角度去进行事件设计说明： [图片]   第一步，会先锁定页面的范围，比如产品里有活动页、内容页、如果是视频App的话会有播放页，小说App会有阅读或者是听书页面。   第二步，范围圈定后就需要找分析行为，用户看到内容是否有点击行为，进入页面后的浏览行为，以及是否有分享、评论等行为。 第三步，确定了要分析的行为后，就需要进行分析维度的细化，如要分析用户浏览（浏览完成行为）内容都有哪些，还想分析用户是哪个入口（来源）进入到页面等等，这些都是针对用户行为要分析的维度； 按照这三步梳理清楚后，事件设计中与产品页面相关的事件和参数就能整理出来了，如页面范围对应的“内容页”和分析行为对应的“点击”行为，就能够清楚我们要采集的事件为“内容点击”，在根据这个事件需要分析的维度是页面名称、页面分类以及页面来源，这个事件所需要的参数也就找到了。 下图中是以内容页和活动页梳理的结构化事件样例。   [图片]   以产品功能的角度去进行事件设计说明： [图片] 同样，第一步先找到要分析哪些功能。比如：搜索、登录、注册、会员、付费、签到等，第一步找到监测功能的范围。 第二步在找行为，功能层面的行为比内容会稍微简单一些，主要是点击行为或者是完成状态。 第三步是维度，例如：搜索功能，想分析搜索入口的点击情况，搜索的关键词是什么，针对登录与充值的话，需要分析帐号登录的类型、充值的方式等等。   页面功能所产出的结构化事件样例[图片] 以搜索引擎为例：搜索引擎监测的行为是点击和完成，通常会用两个事件进行监测，搜索引擎功能在很多页面都会有入口， 通常会建议在这里增加一个参数叫搜索位置，可以辨识用户点击哪些搜索位的按钮，另外可增加参数叫用户ID，去了解具体是哪些用户进行的点击。 重点说一下功能按钮点击事件。通常情况下，会将核心要分析的功能都抽离成单独的事件进行统计。如登录、注册、付费或者是会员购买等，这些属于核心要关注的功能，并且会为这些核心功能事件单独设计要分析的参数； 但如扫一扫、加载更多以及一些Tab键，只需要监测用户点击即可 ，不需要监测功能背后的参数信息。通常会将这些点击行为放在一个事件下，定义名称叫功能按钮点击，会通过“按钮名称“与“所属页面”等参数去锁定用户点的具体按钮是哪个。   小结，通过指标体系去进行事件设计，就能够把大部分需要采集的页面与功能都能覆盖到，并且可以满足后期看数据的需求。   从分析需求到事件设计 [图片] 先引用小说行业的一个需求举例，近期上架了新书，要分析新书对用户的吸引力如何。那么第一步，就要把需求进行转义，也就是需要知道哪些数据和维度，能证明用户对新书的吸引力。   针对这个需求，分析思路是：今天新上架的小说，用户看了多少章节和时间，明天会不会继续来看，可以通过这几个维度去判断出新书吸引力。那么在落实到事件设计的三个步骤中，第一步采集的页面范围是小说页面，第二步采集的行为就是阅读，这两步对应出我们需要采集的事件就是小说阅读，第三步需要分析的维度就是阅读章节、阅读时长、小说名称以及上线日期，这些维度就可以转化成参数在事件中设计进来。 另外，一般做内容事件时，通常还会增加来源参数，比如：来源页面、来源版块、来源位置，这些参数可以帮我们定位到用户是从那些入口获取到内容的，便于后期去分析各入口的导流效率。   从分析方法到事件设计 [图片] 这部分指的是根据核心目标，在利用一套分析方法去解决问题时，如何找到解决问题环节中所需要采集的事件。   比如，目标锁定是要提升用户留存或者是提升付费转化率，那么，首先要找到不同的人群，针对人群找差异（功能使用、内容偏好的差异），找到不同的人群在功能使用、以及转化路径的差异后，在去找问题，如某一些功能对于非留存用户或者是非付费用户体验不好或推荐的内容用户不感兴趣，找到问题后，就需要进行优化，并进行验证；针对分析方法中的每个环节，其实都能对应到需要分析的事件，如找问题的环节会对入口的点击、完成的情况，内容浏览的来源等等进行事件采集，在分人群环节，会对用户的付费行为进行事件采集等等。   通过每个环节找到对应需要分析的行为后，就可以把相关信息以事件或者是参数的形式，补充到现有结构化埋点方案中了。 按照指标、需求、方法这3个角度去做了事件设计方法的介绍，总体可归纳为：有了指标体系与分析需求，整个结构化埋点方案的框架就能设计出来了。分析方法更多的作用是做分析思路上的贯穿，可以帮我们发现埋点设计中缺少或者遗漏的环节，整体上我们就可以理解为，指标体系+分析需求+分析方法这三部分的结合，才能得到一个非常贴合业务的埋点方案。 [图片]    小结：“事件采集“就是要知道谁在什么时候做了什么事情，设计思路可以分为三步，首先，了解产品结构（产品结构的范围，页面结构、功能结构）其次，了解用户行为（点击行为、完成行为、曝光行为等）最后，行为可以细分哪些维度，按照三步结构化事件就可以设计完成了。   同时，总结三个避坑的Tips： 一，需求。如果前期需求不是很明确时，可以先把这个指标体系梳理起来，比如：核心关注的指标，采集方案是可以满足暂时看数的需求，后期可以根据对分析需求的升级再去补充。 二，归类。在事件设计时要合理的进行归类，尽量用一个事件满足多个分析需求。比如，了解用户都是从哪些入口获取内容的，和内容浏览的热度排行。是可以通过一个事件来实现的，只需要通过内容名称和来源页面两个参数，就能够满足这两个需求了。 三，范围，在参数设计中两个范围需要注意，即来源和点击按钮，内容采集会涉及三个来源：来源页面、来源板块和来源位置，是为了去锁定到底内容从哪里点过来，开发也会要求将入口信息梳理清楚，从而进行埋点的开发工作。点击按钮，将按钮都归属到一个事件中，将参数设置为按钮名称，梳理出具体的按钮采集的范围给到开发，才能去进行后续的埋点。 埋点设计不是简单的事件与参数的结合，而是需要贴合业务、贴合分析场景去进行设计。   结构化事件设计完成后，下一步就是要交付给技术进行开发，下图为一个资讯行业的事件埋点模版，可以参照这个模板去进行梳理并提交给技术。友盟+开发者数据银行产品中的智能采集平台就可以按照这个模板，直接帮我们生成对应的埋点方案，并协助我们进行后续的事件管理。 [图片] 三、埋点实施 市场上主流支持的四种埋点方式，分别是代码埋点、服务端埋点、可视化埋点和全埋点。 代码埋点，支持事件与参数这种结构化的使用方式，弊端是想增加或修改事件，都需要重新发版，用户更新后才能采集。 服务端埋点，通常用于业务数据的采集，例如：付费成功、用户注册等，这个场景会选择用服务埋点进行采集。 可视化埋点和全埋点，都是解决整个App前端操作的一些点击行为，例如说某些按钮、页面，每一个点击都能监测。但差异点在于可视化埋点只能看到圈定后的数据，那么全埋点则是在圈定时，历史数据也能去追溯。 但这两个埋点的弊端是散点采集，每一个点击行为都是一个事件，在数据分析时，事件的量级会较大，不易于分析，而且它只能是取这种点击行为的事件，并不能把参数带过来，你可以理解为它就是一个纯扁平化的一个事件采集。 针对需求的不同，数据采集方式应该是结合使用的，以友盟+为例，友盟+现在支持两种埋点方式，代码埋点和可视化埋点，开发者可以结合使用，去满足事件方案的采集需求。   [图片] 四、看板校验。埋点后可通过三种方式验证，一、打印日志，开启debug去打印Log，去验证触发事件log是否有上报，这种方式需要技术来配合验证。 二、集成测试，以友盟+为例，只需要让技术注册一个测试设备，就可在你这个测试设备上去启用你的App，在去触发事件，产品、运营的同学就可直接测试埋点情况。三，也可以使用市场上智能验证的工具，以友盟+为例，可先注册设备，自动去识别整个埋点的情况，且日志是实时的，可产出事件的验证报告。 五、智能验证，可以帮您智能验证这些事件的点是否采集了，是否有遗漏，最后会定期给出体检报告，详细的明细都会有。在友盟+的智能采集页面就可以智能验证埋点，只需要注册一个测试设备，这个测试设备填加完之后会实时把客户这些埋点的数据进行验证，到底是成功还是异常，以及测试的时间是什么都会有详细的数据。 综上所述：一个公司的埋点要可见、可控、可管，如果一家公司不清楚自己的埋点结构，便是在错误的数据上长期持续经营业务，越走越错。合理的埋点方案，可以使埋点能够智能调试和验证，大幅降低埋点采集的成本，从而最终达成数据质量的根本性提升。

遇到一个业务相关的问题，我们一家公司作为第三方代开发方，服务很多家公司的小程序和微信公众号，这时需要拿unionID去做唯一关联，但是unionID需要在微信开放平台进行绑定相关的公众号和小程序后才返回，想问问是不是如果是这样的情况下，服务的公司都需要去进行【公众号的认证】以及微信开放平台的【开发者资质】的认证，两个认证流程，这样才可以拿到unionID？ [图片] [图片]

https://api.weixin.qq.com/cgi-bin/user/info?access_token= openId调用这个接口返回没有获取到uinonId

https://api.weixin.qq.com/cgi-bin/user/info?access_token=ACCESS_TOKEN&openid=OPENID&lang=zh_CN 微信公众号获取用户基本信息接口没有获取到用户unionid，微信公众号已经绑定了开放平台，而且有的用户可以获取到有的用户获取不到，是什么原因？

背景 我们发现大部分小程序都会使用 [代码]wx.getUserInfo[代码] 接口，来获取用户信息。原本设计这个接口时，我们希望开发者在真正需要用户信息的情况下才去调取这个接口，但很多开发者会直接调用这个接口，导致用户在使用小程序的时候产生困扰，归结起来有几点： 开发者在小程序首页直接调用 [代码]wx.getUserInfo[代码] 进行授权，弹框获取用户信息，会使得一部分用户点击“拒绝”按钮。 在开发者没有处理用户拒绝弹框的情况下，用户必须授权头像昵称等信息才能继续使用小程序，会导致某些用户放弃使用该小程序。 用户没有很好的方式重新授权，尽管我们增加了[代码]设置[代码]页面，可以让用户选择重新授权，但很多用户并不知道可以这么操作。 此外，我们发现开发者默认将 [代码]wx.login[代码] 和 [代码]wx.getUserInfo[代码] 绑定使用，这个是由于我们一开始的设计缺陷和实例代码导致的（[代码]wx.getUserInfo[代码] 必须通过 [代码]wx.login[代码] 在后台生成 [代码]session_key[代码]后才能调用）。同时，我们收到开发者的反馈，希望用户进入小程序首页便能获取到用户的 [代码]unionId[代码]，以便识别到用户是否以前关注了同主体公众号或使用过同主体的App 。 为了解决以上问题，针对获取用户信息我们更新了三个能力： 1.使用组件来获取用户信息 2.若用户满足一定条件，则可以用[代码]wx.login[代码] 获取到的[代码]code[代码]直接换到[代码]unionId[代码] 3.[代码]wx.getUserInfo[代码] 不需要依赖 [代码]wx.login[代码] 就能调用得到数据 获取用户信息组件介绍 [代码][代码] 组件变化： [代码]open-type [代码]属性增加 [代码]getUserInfo[代码] ：用户点击时候会触发 [代码]bindgetuserinfo[代码] 事件。 新增事件 [代码]bindgetuserinfo[代码] ：当 [代码]open-type[代码]为 [代码]getUserInfo[代码] 时，用户点击会触发。可以从事件返回参数的 [代码]detail[代码] 字段中获取到和 [代码]wx.getUserInfo[代码] 返回参数相同的数据。 示例： [代码]<button open-type="getUserInfo" bindgetuserinfo="userInfoHandler"> Click me button>[代码]和 [代码]wx.getUserInfo[代码] 不同之处在于： 1.API [代码]wx.getUserInfo[代码] 只会弹一次框，用户拒绝授权之后，再次调用将不会弹框； 2.组件 [代码][代码][代码][代码] 由于是用户主动触发，不受弹框次数限制，只要用户没有授权，都会再次弹框。 通过获取用户信息的组件，就可以解决用户再次授权的问题。 直接获取unionId开发者申请 [代码]userinfo[代码] 授权主要为了获取 [代码]unionid[代码]，我们鼓励开发者在不骚扰用户的情况下合理获得[代码]unionid[代码]，而仅在必要时才向用户弹窗申请使用昵称头像。为此，凡使用“获取用户信息组件”获取用户昵称头像的小程序，在满足以下全部条件时，将可以静默获得 [代码]unionid[代码]： 1.在微信开放平台下存在同主体的App、公众号、小程序。 2.用户关注了某个相同主体公众号，或曾经在某个相同主体App、公众号上进行过微信登录授权。 这样可让其他同主体的App、公众号、小程序的开发者快速获得已有用户的数据。 不依赖登录的用户信息获取某些工具类的轻量小程序不需要登录行为，但是也想获取用户信息，那么就可以在 [代码]wx.getUserInfo[代码] 的时候加一个参数 [代码]withCredentials: false[代码] 直接获取到用户信息，可以少一次网络请求。 这样可以在不给用户弹窗授权的情况下直接展示用户的信息。 最佳实践 1.调用 [代码]wx.login[代码] 获取 [代码]code[代码]，然后从微信后端换取到 [代码]session_key[代码]，用于解密 [代码]getUserInfo[代码]返回的敏感数据。 2.使用 [代码]wx.getSetting[代码] 获取用户的授权情况  1) 如果用户已经授权，直接调用 API [代码]wx.getUserInfo[代码] 获取用户最新的信息；  2) 用户未授权，在界面中显示一个按钮提示用户登入，当用户点击并授权后就获取到用户的最新信息。 3.获取到用户数据后可以进行展示或者发送给自己的后端。 One More Thing 除了获取用户方案介绍之外，再聊一聊很多初次接触微信小程序的开发者所不容易理解的一些概念： 1.关于OpenId和UnionId [代码]OpenId[代码] 是一个用户对于一个小程序／公众号的标识，开发者可以通过这个标识识别出用户。 [代码]UnionId[代码] 是一个用户对于同主体微信小程序／公众号／APP的标识，开发者需要在微信开放平台下绑定相同账号的主体。开发者可通过[代码]UnionId[代码]，实现多个小程序、公众号、甚至APP 之间的数据互通了。 同一个用户的这两个 ID 对于同一个小程序来说是永久不变的，就算用户删了小程序，下次用户进入小程序，开发者依旧可以通过后台的记录标识出来。 2.关于 getUserInfo 和 login 很多开发者会把 [代码]login[代码] 和 [代码]getUserInfo[代码] 捆绑调用当成登录使用，其实 [代码]login[代码] 已经可以完成登录，[代码]getUserInfo[代码] 只是获取额外的用户信息。 在 [代码]login[代码] 获取到 [代码]code[代码] 后，会发送到开发者后端，开发者后端通过接口去微信后端换取到 [代码]openid[代码] 和[代码]sessionKey[代码]（现在会将 [代码]unionid[代码] 也一并返回）后，把自定义登录态 [代码]3rd_session[代码]返回给前端，就已经完成登录行为了。而 [代码]login[代码] 行为是静默，不必授权的，用户不会察觉。 [代码]getUserInfo[代码] 只是为了提供更优质的服务而存在，比如展示头像昵称，判断性别，开发者可通过 [代码]unionId[代码] 和其他公众号上已有的用户画像结合来提供历史数据。因此开发者不必在用户刚刚进入小程序的时候就强制要求授权。 可以在官方的文档中看到 [代码]login[代码] 的最佳实践： [图片] Q & A Q1: 为什么 login 的时候不直接返回 openid，而是要用这么复杂的方式来经过后台好几层处理之后才能拿到？ A: 为了防止坏人在网络链路上做手脚，所以小程序端请求开发者服务器的的请求都需要二次验证才是可信的。因为我们采取了小程序端只给 [代码]code[代码] ，由服务器端拿着 [代码]code[代码] 和 [代码]AppSecrect[代码] 去微信服务器请求的方式，才会给到开发者对应的[代码]openId[代码] 和用于加解密的 [代码]session_key。[代码] Q2: 既然用户的[代码]openId[代码] 是永远不变的，那么开发者可以使用[代码]openId[代码] 作为用户的登录态么？ A: 不行，这是非常危险的行为。因为 [代码]openId[代码] 是不变的，如果有坏人拿着别人的 [代码]openId[代码] 来进行请求，那么就会出现冒充的情况。所以我们建议开发者可以自己在后台生成一个拥有有效期的 [代码]第三方session[代码] 来做登录态，用户每隔一段时间都需要进行更新以保障数据的安全性。 Q3: 是不是用户每次打开小程序都需要重新[代码]login[代码]？ A: 不必，可以将登录态存入[代码]storage[代码]中，用户再次登录就可以拿[代码]storage[代码] 里的登录态做正常的业务请求，只有当登录态过期了之后才需要重新[代码]login[代码] 。这样子做一则可以减少用户等待时间，二则可以减少网络带宽。 目前微信的[代码]session_key[代码] 有效期是三天，所以建议开发者设置的登录态有效期要小于这个值。

[图片]现在平台出现二十多万微信公众号用户无法与小程序用户统一，问题就unionid无法统一确认导致，但用户如果通过主动授权的方式 却又可以拿到unionid，现在通过单个获取用户基础信息和批量获取用户基本信息都拿不到unionid数据，请问这是什么情况？

游戏圈UI官方提供了4种案例，但是和游戏内容不太契合，是否可以自己设计UI样式呢 [图片]

先调用wx.login 在从微信后端换取到 session_key了 然后小游戏里，调用getUserInfo，参数withCredentials:true, 请问这种下还要弹窗提示？还是说 直接就有success结果了？ 我再开发工具里，还是有弹窗提示的， 所以不清楚规则是什么？wx.login 在从微信后端换取到 session_key了 然后getUserInfo ，那么这个过程 和弹窗是个什么关系？ 改怎么样实现 不弹窗 能得到用户昵称头像的操作过程呢？ 是否能实现吗？

有不少开发者肯定纠结过，到底开局要不要就弹窗授权。弹吧，用户一看唰唰唰一堆信息授权就吓跑了，不弹吧，会不会就进行不了游戏，没法保存玩家关卡、道具相关数据了呢？ 其实，登录和授权是两回事： 如果只是单纯想要获取用户唯一标识，然后保存该用户相关的游戏数据（关卡、道具等），只需要通过wx.login接口完成微信登录即可。此过程是完全静默，不需要用户参与的。 如果开发者想在游戏的某些场景中使用其他用户的头像和昵称信息（比如全局排行榜，PVP匹配），这时候就需要先获取用户的授权在游戏后台保存好昵称和头像URL，在对应的场景中就可以展示相关用户的头像昵称了。 [图片] [图片] [图片] 因此，建议开发者可以在需要的时候再获取用户的信息，而在用户刚进来的时候，不要急吼吼就弹授权吓跑他们哟~ 还想知道更多？可以看看来自微信团队关于“获取用户信息”能力的分享（很长·干货版·建议收藏）： 小程序•小故事(4)——获取用户信息 最后，我们欢迎开发者们来互撩，你的问题可以能会变成下一个经验分享贴的开始~

“你们的留存多少？” “活跃用户次日留存最高接近70%，三日留存是60%，七日留存50%。” “这么高？” “是的。其实我们还有一组数据：活跃用户的每天活跃时长90多分钟。到现在，我们的小游戏已经上线8个多月，很多用户都是一开始就跟到了现在。” 就在小程序创业者们忧虑留存时，有一款产品的活跃用户留存数据和时长，已经比肩，甚至超越了APP。 我们都知道，微信生态拥有超强裂变、用户迅速新增的特点，如果留存问题也能被解决，当下创业者最关心的问题就迎刃而解。那么，这款产品的超高留存到底怎么实现的？ “小游戏说”为你揭开谜底。这一次，答案将由创意小游戏“英雄爱三国”来给。 1 留不下来的新流量，不叫流量 产品刚上线的时候，“英雄爱三国”的留存也很糟糕：活跃用户次日留存只有28%，七日留存更是在10%以内。 这是他们玩着玩着玩出来的项目，没有谁想要轻易放弃。 对这个项目的高期望，来自于长达五年，近5500个小时的游戏经验—— “在这之前，我们团队玩这类游戏就将近五年，每天都要打两到三个小时。我们那时候就想，既然这么爱玩，干脆自己做一款吧。于是就有了现在的‘英雄爱三国。”创始人姜小白回顾说。 “英雄爱三国”上线3个月后，就获得了首期创意认证，它是一个由兴趣爱好变成创业项目的典型案例。 [图片]（图为曾报道的创意小游戏案例） 但是，对到底怎么留下新用户，姜小白一开始也摸不着头脑。 “英雄爱三国”团队出身大厂，很少需要考虑市场和运营的事。他们一开始觉得，做产品“根本不用去考虑别人怎么想，把它做到自己喜欢就行”。 早期他们只专注产品的核心玩法，即设计好卡牌本身，以及如何让卡牌之间各种组合成为一种考验策略、输出爽感的深度玩法。为此，甚至连产品的美术都没怎么好好做，第一版美术还被吐槽为“灵魂画风”。 但这种只做产品不考虑平台属性的想法，让产品一开始遭遇了惨淡的留存数据。 [图片] （第一版的“灵魂画风”美术，还吸引了不少越吐槽越来劲的铁粉） 小白和他的团队又一次坐到了一起。他们开始认真思考，到底微信的用户是一群什么样的人？他们和小白团队这群卡牌游戏的重度玩家有什么区别？ 从分类上，“英雄爱三国”所处的种类是集换式卡牌游戏。让小白他们着迷了五年之久的，是这类游戏的开山之作“万智牌”。用户会利用手上的卡牌，组合出不同的策略去赢得游戏，“组卡”和“策略”是这类游戏的基础核心。 不过，喜欢这类产品的人群比较小众，泛用户人群从上手到喜欢会有一定的门槛。而面对微信平台上的新用户们，任何一个不够简约的操作都自带“劝退”效果。 为了降低上手门槛，大部分产品会采用新手教程。但，在试图扩大用户群体的时候，他们头疼地发现，“大家都在用”的新手引导里也有门道。 “我们一开始以为，做好了产品，新流量自然就会到来。但事实并不是。新流量来了也不一定是你的。你需要像新东方的老师一样，研究他们上手的规律，通过引导教学，快速去除用户留下的障碍。” “这样，他们才有喜欢产品的可能性。” 第一个新手流程版本上线时，团队恨不得在一场战斗中教会用户所有。而用户可能只能记住60%。有用户开玩笑说，“我眼睛学会了，但是手还不会。可能再教我两次才能记得住。” 为此，团队开始全员研究从没接触过这类游戏的新用户，以查看他们的使用习惯，摸索用户的“学习规律”。 [图片] （图为新手教程界面） 在后面几次改版中，他们增加了新手语音，将一次教学战斗拆解为三场，还引入两场复习学习成果的“巩固型”教学战斗，将留存一下子提升到48%，前后差了20%。 这其中还有许多细节，如一些细微的调整是在新手流程中不让用户失败，而在第一个版本时用户很有可能失败。同样，系统还会在这个过程中自动漏出不同牌的弱项，让用户从中学会攻击策略。但实际上，这些调整并没有改变核心玩法。 “除了核心玩法，任何细节出现‘劝退’，用户就会很容易转到其他地方。” 留存，真的是一件细致活。让更多用户喜欢自己的产品，需要把自己当成新手。只有体验上不“劝退”，才有留下用户的进一步可能。 [图片] （图为现在的游戏界面） 2 用好社群“大招”：让用户“秀”起来 “有社区在，用户质量和参与高了不止一个数量级。” 从一开始，姜小白就觉得自己踩对了宝：“这是个忠诚度很高的人群，找到了你的目标人群，聚焦核心玩法，进来的用户就很难流失”。 如何维护好你的目标用户，让留存更高？——社区。 那么，让你的用户在社区里讨论什么呢？在“英雄爱三国”的社区里，每天，都会有大量重度核心用户在参与讨论。包括每一次的产品迭代，他们都在收集和整理用户们的预期。 据姜小白评估，深度用户的建议对卡牌的核心玩法贡献度超过了10%。按照预期，这个人群对核心玩法的影响会越来越大。 “他们很热衷设计和DIY这些卡牌，也非常热衷于在社区里讨论、分享。” [图片] （图为核心用户讨论玩法的调整） 将核心用户挖掘并串联起来，正是从一开始他们就坚持做起来的用户社区。姜小白说，有了社区这个功能，团队能明显感觉到，这里的用户质量和参与热情比其他没有社区的渠道高出了不止一两个数量级。在早期的时候，他们就感受到社区对用户的“磁力”。 除了产品与用户的深入沟通，社区还带来了用户之间的高积极互动。 人都有一种“秀”和深度沟通的欲望，遇到“同好”，炫耀能产生更大的满足。在这里，“围绕每张牌放下去后的组合效果，和别人进行互动都是很有戏剧性的，大家会很热烈地跟帖、刷段子”。 “用户在社区里不断分享战报和讨论攻略，有的攻略写的特别长，一万多字的也有。” 这些攻略和战报，观看量多超过几万，评论量和点击量也都成百上千；在社交网络上，只有大型产品和热门事件才能持续获得这样的数字。而这些数字，都是社区里的真实用户产生的。 [图片] （图为玩家DIY设计） 社区也出乎意料地帮产品延续了用户的成长性。 很多开发者都注重用户能不能长久地留在自己的产品里，能不能反复地想起、并回到产品中来。这时候，你需要一个钩子——对“英雄爱三国”来说，就是要让用户在他们的产品里持续“有惊喜”。 目前这款产品只有70多张卡牌，一名活跃用户——尤其是每天90分钟以上重度用户，很容易在一段时期中用完大部分组合。因此，一方面团队需要不断更新和推出更多组合策略，如让某些卡牌搭载一些自由度很高的功能。另一方面，也希望用户能主动挖掘并分享。 社区中用户已经形成了“发现+分享”的正循环，自然解决了这个问题。通常，一种新策略能让用户开心玩一两个月，这种正循环也因此带来了用户停留时间的提升。 “现在，我们一直在控制，让20%用户能够接触到更多新策略”。姜小白说。 团队也一直不断在调整内容迭代的节奏，他们发现，当有6成玩家把新内容玩的差不多时，再马上更新，会让用户的留存和活跃最高。固定的更新也慢慢成为一种用户的预期。 3 留存好的产品长什么样？ “在微信中调整的产品功能，也会让APP留存同样受益”。 产品生长的过程，有太多决策要做，很多甚至是很小很细微的决策。姜小白的感触是：如何判断增加、修改和优化某个玩法？哪些又是需要坚持的？这背后需要几个灵魂。具体到“留存”上，不管小游戏还是小程序，都可以参考这些基本的规则： - 用好关系这件事情 用户之间关系越亲密，留存越高。同样，在团队和用户之间形成、递进更亲密的关系，会让用户在产品中投入更多心力，获得更多成就感和参与感。因此，“英雄爱三国”从一开始就设计好让用户参与的方式，每次迭代都和核心用户进行沟通。 而且，在社群中深度讨论的用户越多，留存越好；有时，重要的不是产品覆盖的用户数，而是将自己在产品中的体验、发现，用各种方式分享出来的用户数，这些分享还会覆盖到微信之外的社交网络。如姜小白就发现大量用户在特别中也有深度讨论这款产品，这也同样带来更活跃的留存数据和新增用户量。 - 关注策略性和深度 让核心玩法保持可变性和新鲜感，让核心人群时时有新东西可以发现、时时有新玩法和新策略可以探讨。这会帮助产品构建一个动态的成长体系。这款产品中看到了用户活跃90分钟，堪比APP的超长时长，和这个成长体系不无关系。 [图片] （图为游戏界面） - 站在专业角度上，聆听新人反馈 “英雄爱三国“早期犯了一个错误，即通常专业的人做事会太过专业，反而将更多潜在用户挡在外面。这时要做的是和新用户，尤其是非专业用户泡在一起，看他们的需求和反馈、观察他们使用产品的行为习惯，再去持续优化产品。正是经过新手用户的教育，“英雄爱三国”的留存才第一次实现大跃升，现在，定期观察新用户已成为团队的必修课。 “找到一个自己足够热爱的细分领域，做一款这个领域独一无二的、达到自己极致的产品，这是在微信生态中创业的最佳状态。如果说做一款高留存产品能有什么给大家的参考和建议，这是我想说的。”姜小白说。 - 关于小游戏说 “小游戏说”是为小游戏开发者而设计的实战课程，将深度对话并梳理优质小游戏关于增长、留存和变现的心得。这不仅仅是在聊一款小游戏如何从0到1，如何爆发，更是在聊当企业切入微信互联网、创业者们用好小程序时值得借鉴的方法论。 我们希望带给开发者们启发，同时也欢迎每一位开发者加入到小游戏开发与创作的行列，共同探索更多游戏形式，做出有价值的小游戏。 此外，感谢作者见实团队的共同投入。

还在纠结该怎么做小游戏吗？到底什么样的小游戏利于传播？什么样的小游戏能留住玩家？怎样才能让玩家有更好的游戏体验？什么样的设计能增加创收？ 小游戏入门N连问，在这里你都能得到解答。令人烦恼的夏日，送上一份清凉解暑的快速设计指南！ [图片] 在以下的四个章节里，我们将通过案例，为大家分享以下几个话题。现在，让我们先来看看一些基础的知识点： 体验——《升级游戏体验》 分享——《分享的玩法》 留存——《留存的“套路”》 收入——《变现和收入》 准备好上课了吗？翻开手中的指南，我们开始～ 本指南为第一次进行小游戏开发的开发者提供快速的设计指引。它能让你快速的避免一些常见的产品设计错误，并能让你了解微信在小游戏上的价值主张。 什么是小游戏 微信小游戏是微信小程序的一个新增类目。 和所有小程序一样，小游戏无需下载、安装与卸载，即点即玩，体验轻便优秀。 同时，小游戏与微信关系链捆绑，可以方便的邀请微信好友、群好友进行PK、围观等，充分享受与朋友同玩的乐趣。 小游戏之于APP手游，是相对更轻松休闲的一种模式，而重度的APP手游，是以富有挑战性的玩法、沉浸式参与感等方式给玩家带来更极致的体验和深度的娱乐。 二者带来的用户体验差异不小，两者在整个游戏产业中分别扮演着不同的角色，没有直接竞争的关系。 如何找到小游戏 你可以在微信主界面上下拉，呼出最近使用的小程序，也可以找到最近玩过的小游戏； 除此之外，你还可以在微信「搜一搜」搜索小程序的名称，如「跳一跳」； 小游戏的官方入口在微信 - 发现 - 游戏 功能中。

**这是小蚂蚁游戏开发公众号原创的第37篇。 本篇内容包括微信小游戏开发工具中的表格的使用。重点学习表格中的数据的设置，遍历和查找操作，以及如何使用“调试场景”来验证游戏中的逻辑是否正确。 如果你没有任何的游戏开发经验，欢迎阅读我的“人人都能做游戏”系列教程，它会手把手的教你做出自己的第一个小游戏。 上一节中讲过使用表格来存储和处理游戏中的数据。这一节我们直接上手，学习表格中的数据处理，我们将会实现以下的内容： 创建一个10行10列（10x10）的表格，默认值都设置为0随机的在表格中插入一行数据1逐行遍历，找到满足条件的行（即整行的数据都是1）# 创建表格 在“数据区”中点击“新建表格”按钮，创建一个叫做“网格”的全局变量。 [图片] [图片] 会看到一个表格编辑的窗口，点击“新增行”和“新增列”创建一个10行10列的表格。 [图片] 将所有格子中的数据都设置为“0”，最后看起来应该是这样。 [图片] 这样一个10x10的所有默认数据为0的表格就创建好了。 # 随机在表格中插入一行数据1 为了方便演示，我在场景中增加了两个按钮，一个叫做“加入一行”，一个叫做“查找匹配”。我们会把插入逻辑和查找逻辑分别放在对应的按钮对象上。 你可以对照着下图添加你的素材。 [图片] 在“加入一行”对象上创建两个局部变量：行号和列号。 [图片] 接着，我们直接看代码逻辑。 [图片] 如果一下看不明白，也无需着急。对着下面的分析再多看几遍。 因为我们的表格一共10行，所以这里我们取了1～10之间的随机整数，作为将要设置的行，并且将这个数字保存在了局部变量“行号”中（通常对于后续需要用到的数据，都会用局部变量来存储）。循环开始前将列号设置为1，因为要从第1列开始依次向后设置，直到第10列。假设随机到了第1行后，开始进入循环，首先会将表格中第1行第1列的数字设置为1，接着第1行第2列，直到第1行第10列后，循环结束。这样第1行中所有的10个数字就都从0变为了1。 接下来，我们验证一下，点击预览场景右侧的下拉小箭头，选择“调试场景”。 [图片] 调试场景像下面这样，你以后会经常用到。点击“系统全局”可以看到我们创建的全局变量“网格”，鼠标移动网格的数据上，会显示当前网格的数据。 [图片] 接着点击“加入一行”，可以看到我们为它创建的两个局部变量，“行号”和“列号”。 [图片] 现在，点击一下场景中的“加入一行”按钮，你会看到“行号”和“列号”的局部变量发生了变化，当前“行号”为9，意味着我们随机到了数字9，即将表格中第9行的所有数据设置成了1。 [图片] 看一下系统全局中的网格数据，是否是第9行被设置为了1。 [图片] 第9行的数据确实都被设置为了1，证明了我们逻辑没有问题。你可以多点击几次“加入一行”按钮，多设置几行表格数据，在全局变量中查看。 # 查找满足条件的行 我们的查找逻辑是这样的：从上往下，依次查找表格中的每一行，如果一行中所有的数据都是1，那么记录一下这一行的行号，直到表格查找结束。 首先，我们创建4个局部变量。 [图片] “行号”和“列号”用于循环，“都是1”用来表示当前一行的数据是否都是1，如果满足条件的话设置为1，不满足的话设置为0， 新建一个列表局部变量“匹配行”，用于记录当前满足条件的行号，因为表格中可能会有多行满足条件，所以这里我们使用列表来记录所有满足条件的行号。 下面我们来看一下查找匹配的逻辑： [图片] 这里有一个难点就是“双重循环”，如果你遍历的数据只有一行的话，那么只需要一个循环就可以了，但是，当你要遍历10行10列的数据时，就需要用到“双重循环”。一个循环用于行，一个循环用于列。它只是看上去复杂，认真的分析一下其实不难理解。 我们从表格的第一行开始检查，想象一下我们从表格中拿出了第一行数据，然后从这一行数据的第一个一直检查到最后一个，看看是否有数字不为1，只要有一个数字不为1，就证明这一行不符合条件，就没有必要接着往下检查了。检查完一行后，如果它符合条件我们就把这一行的行号记录下来，放到“匹配行”的列表中。接下来再取出第二行，进行同样的操作，直到取完第十行为止。 点击“调试场景”，检查一下逻辑是否有问题，先点击几次“加入一行”按钮，随机的在表格中加入几行数据。 [图片] 接着点击“查找匹配”按钮，选择“查找匹配”，看一下“匹配行”局部变量的数据。 [图片] 如图，找到了第7，6，1行是满足条件的。 小提示：因为我们总是在列表中的第1项插入数据，所以最后的结果是[7,6,1]，是倒序。真实过程是这样的，检查到第1行满足条件，插入列表，列表变为[1]，接着检查到第6行满足条件，插入列表，列表变为[6,1]，接着第7行满足条件，插入列表，列表变为[7,6,1]。总结一下： 这一节我们学习了表格的创建，设置，遍历和查找操作。并且学习了使用“调试场景”在游戏运行时查看全局变量和局部变量，来验证逻辑是否正确。 练一下： 试着实现在表格中随机加入一列数据的功能，并且在查找时将所有满足条件的行和列都找出来。  如果你对游戏开发感兴趣，欢迎关注我的公众号：小蚂蚁游戏开发。了解更多与小游戏开发有关的内容。 [图片]

在游戏中我们经常需要统计一些信息，然后根据这些信息来分析玩家玩游戏的一些情况，并以此指导我们对游戏进行优化，或者根据这些数据来决定下一步的方向。 举个简单的例子，一个游戏中有两个不同的主题，一个是简约清新的，一个是炫彩斑斓的，那么此时，作为一个游戏的制作者，如果想要知道，到底玩家更喜欢那种风格的主题呢？就可以通过统计玩家选用不同主题的次数，来得出判断，到底玩家玩家更喜欢哪一个主题。 例如，在“精致1010”中我做了 6 种不同的主题，然后通过数据统计，我就可以在小程序的后台看到每种主题的使用次数，然后以此来判断哪个主题更受欢迎。 [图片] 猜一下，哪个主题最受欢迎呢？ 好了， 言归正传。 小游戏端的处理 为你的小游戏增加数据统计能力，其实非常的简单。如果你使用的是“微信小游戏制作工具”的话，那么只需要使用一块积木就可以了。 这块积木位于“小游戏”类别中。 [图片] 这个积木块有三个选项，第一个是 branchId，第二个是类型，曝光还是点击，第三个是一个可选择的参数 branchDim。稍后呢，我们会讲解如何使用这 3 个选项。 [图片] 这块积木的使用方式也非常的简单，你只需要把它放到任何你想要统计数据的地方就可以了。例如，当前你想要统计游戏中的一个按钮到底被点击了多少次，就可以这样使用。 [图片] 如果你使用的不是小游戏制作工具的话，可以直接使用对应的 API 进行数据的上报：https://developers.weixin.qq.com/minigame/dev/api/data-analysis/wx.reportUserBehaviorBranchAnalytics.html好了，小游戏端并不需要做太多的工作，接下来我们就来看一下如何的配置小程序的数据统计后台。 小程序后台的设置 打开小程序后台，在“统计”，“基础数据”，找到“场景分析”。我们在小游戏中上报的数据，未来都会显示在这里。 [图片] 点击“新建场景”按钮，创建一个新的数据场景。 [图片] 注意图中的“参数设置”选项，默认是没有勾选的。如果勾选的话，就可以在上报数据的时候额外的上传一个参数（branchDim），这个参数只能是 int 类型，并且数值只能是 1~100。 [图片] 如果不使用“参数设置”，那么可以直接忽略积木块中的这个参数 branchDim。 新建完场景之后呢，就能够在“场景管理”中看到你创建的场景了。接下来，点击“获取代码”。 [图片] 然后点击“复制代码”，你可以选择复制“曝光”的代码，也可以选择复制“点击”的代码。 [图片] 复制出的代码是这个样子的，我们重点获取的是 branchId。 [图片] [图片] 将获取到的 branchId 填入积木块中的“branchId”中，然后选择是统计“曝光”，还是统计“点击”。 这里普及一下“曝光”与“点击”的区别。举个例子，当前你的游戏中有一个“看视频广告复活”的按钮，每当玩家在游戏中挂了时，就会弹出这个复活按钮，点击后，观看一段视频广告就能复活。在这样的一个场景中，每当复活按钮显示时，就是一次“曝光”。如果玩家点击了复活按钮，就是一次“点击”。所以，“曝光”的次数一定是大于等于“点击”的次数的，因为“曝光”了不一定会引起“点击”。 我们如何根据这个数据去分析游戏中的情况呢？比如说游戏中的观看广告复活按钮“曝光”了 100 次，但是只有 1 次“点击”。那就证明这个观看广告复活的方式对于玩家没有任何的吸引力。你就需要去寻找为什么会出现这样的情况，是游戏本身的吸引力有问题呢？（死了之后大家都不想复活继续玩了）还是广告的问题呢？还是其它的什么问题呢？ 调试上报数据 当你配置好后台，并在小游戏中配置好对应的参数后，就可以进行“调试”了。 在开启调试前，必须先将小游戏上传，发布“体验版”。然后在真机上进行调试。 [图片] [图片] 实时的日志中会打印出实时的数据上报情况。 调试没有问题的话，就可以将你的小游戏提交，审核，发布了。 发布之后，你就可以在“场景分析”中的“数据分析”中看到你的小游戏中所统计的数据了。 [图片] *注意这里的统计数据并不是实时的，会延迟一天，也就是说你在明天才能够看到今天的数据。 了解更多与场景分析有关的内容，可以查看微信小程序官方文档：https://developers.weixin.qq.com/minigame/analysis/selfanalysis.html#%E5%8A%9F%E8%83%BD%E6%A6%82%E8%BF%B0 今天的分享就到这里了，希望它能够帮助你得到你想要得到的小游戏中的数据，然后借用这些数据进行分析，优化，决策，从而让你的小游戏变得更好。 **建议收藏这篇文章，因为你迟早会在你的小游戏中的用到的！ ----- 我做的小游戏“精致1010”在这里，不去看看吗～ [图片] 另外，如果你想学习做游戏的话，关注我的公众号就对了。 [图片]

在应用开发过程中，我们会遇到各种各样的分享场景，例如邀请、拉新、分享内容等。分享链接是 Web 时代常见的分享形式，实现也相对容易。但是现在人们时间大都花在了 APP 上，所以应用之间的分享越来越重要，然而应用之间分享链接却不是那么顺利和有效果。往往受以下制约： 纯文字链接，依靠文字向外界传达信息，信息量小、可信度低。群里丢了一个链接进来，什么描述都没有，大多数人都不会去点。链接的描述一般也不会太长，信息不会太多。分享的目标应用的外链策略。淘宝购物链接不能分享到微信、营销链接容易被微信封禁，都是受微信外链策略的影响。平台分享机制限制。小程序的转发功能允许用户直接将小程序分享到联系人中，却无法分享到朋友圈。若开发者希望用户可以分享小程序到朋友圈中，通常需要生成分享海报图片，分享图片到朋友圈中。所以 APP、H5、小程序等应用中分享功能，除了实现分享链接以外，还需要生成分享海报图片，在图片上展现更丰富的内容，一图胜千言。 如何低成本地生成内容丰富的海报图片，就是我们想要解决的问题。 常见技术方案从生成图片的位置划分，可以将方案划分为两种：客户端生成、服务端生成。 在客户端生成图片是将图片中的元素都下载到本地，然后使用绘图 API 进行绘制，典型方案就是使用 Canvas 来绘制图片。 在服务端生成图片，又可以分为两种，一种是在服务端使用绘图库绘制，然后返回图片或图片链接给客户端；另一种是在服务端使用HTML + CSS 生成带有样式的网页，然后使用无头浏览器截图，返回图片或图片链接给客户端。 简而言之，一般会使用下面这三种方式： 在客户端使用 Canvas 生成图片在服务器上使用网页完成样式渲染，然后截图返回给客户端使用后端绘图库绘制，然后返回给客户端下面逐一分析各种方案生成海报图片的优缺点。 客户端使用 Canvas 生成海报图片优点： 渲染过程在每个客户端中完成，渲染相对独立，基本上不需要考虑并发的问题。Canvas 特性丰富，可以实现样式复杂的图片渲染。缺点也很明显： 上手门槛高，需要灵活使用 Canvas API代码可读性差，调试过程复杂。代码复用程度低，每个端都需要重新编码。客户端型号众多，用户设备上的表现还可能与在开发机上的表现存在差异。兼容性太差，这是客户端渲染最大的痛点。如果有远程图片，可能会因跨域，无法下载，导致绘制失败。推荐阅读：小程序canvas绘制海报 服务端浏览器，网页截图在服务器上使用 HTML + CSS 在无头浏览器中完成网页样式布局与内容填充，然后使用无头浏览器提供的截图 API，将生成的网页截图保存。无头浏览器一般会选用 [代码]Puppeteer[代码]。 [代码]Puppeteer[代码] 是谷歌官方团队开发的一个 Node.js 库，它提供了一些 API 用来控制浏览器的行为，比如打开网页、模拟输入、点击按钮、屏幕截图等操作，通过这些 API 可以完成很多有趣的事情，比如本文要讲的海报渲染服务，就会用到屏幕截图功能。 这种方案的优缺点也很明显。 优点： 上手简单，只需要了解 HTML 、CSS 就可以代码可读性高，易于调试得力于HTML、CSS，表达力强。只要在网页上能实现，就可以应用到海报图片中。返回给客户端的是图片链接，不用考虑兼容性。服务端生成图片带来的最大好处是多端兼容。但这也会引入一个问题，成本高。 在后端需要运行一个 Node 服务来跑[代码]Puppeteer[代码] 控制一个浏览器，性能太低。一个4核16G内存的服务器生成图片，峰值QPS只有 10-20，在较差情况下每秒只能生成10张图片。 推荐阅读：使用 Puppeteer 搭建统一海报渲染服务 服务端绘图库绘制图片在服务端中，使用绘图库，绘制图片，然后将图片保存至 CDN 中，再返回图片链接给客户端。常用编程语言都有绘图库，例如 PHP 的 GD 库。相较于控制浏览器截图，这个方案的性能更高，也具有服务端渲染的好处，但灵活性却没有使用CSS控制样式高。 优点： 性能高服务端架构统一，开发者不用单独维护一个Node.js 服务。代码可读性高缺点： 复杂样式，开发时间长，需要微调。自适应布局困难。推荐阅读：PHP 使用GD库合成带二维码的海报步骤以及源码实现 上面介绍了三种生成分享海报图片的常用方案，了解了实现原理。开发者在实现这些方案时都需要进行独立的开发，维护复杂的样式代码，每增加一种海报，就需要维护一份样式代码。 海报只是业务中很小的一环，自己维护一个海报渲染服务，付出的成本与收益之间不成正比。所以我们更推荐使用第三方海报/图片渲染服务，来完成实现我们的想法。 imgrender.cn 动态图片渲染服务Imgrender 是一个免费的图片渲染服务，通过一个API，根据配置动态渲染图片，快速生成不同内容的图片。渲染模板配置简单，特别适合拥有不同分享海报的应用，快速、动态地生成分享海报。Imgrender 支持「文本」、「图片」、「二维码」、「矩形」、「线段」五种组件，可满足绝大多数海报的渲染需求。 👏 免费📝 API 优先🛣 动态渲染，内容可动态调整🖥 易于配置，方便调试📱 兼容性高，渲染结果只与配置有关⚡️ 快速、稳定，平均响应时间 400msImgrender 只有一个核心 API，通过 API 传递海报内容，就可以动态生成不同内容的图片。海报内容完全配置化，在完成设计稿后，按照设计尺寸和位置生成配置即可。 使用服务也很简单，只需要请求 [代码]POST https://api.imgrender.net/open/v1/pics[代码]。将下面的 curl 命令复制到终端请求一下，就可以得到渲染好的海报图片链接。 curl 命令中 Apikey 是临时的，可能会失效，你可以在 imgrender 中免费获取 API Key。 curl -X "POST" "https://api.imgrender.net/open/v1/pics" \ -H "Authorization: Apikey 183666749185461475.PLbfIpBpeMkpgbj1Tr+177Mv3Jo3wIIySyf8V5ZeDhs=" \ -H "Content-Type: application/json; charset=utf-8" \ -d '{   "width": 640,   "height": 1050,   "backgroundColor": "#d75650",   "blocks":[       {           "x": 15,           "y": 268,           "width": 610,           "height": 770,           "backgroundColor": "#fff",           "borderColor": "#fff"       }   ],   "texts":[       {           "x": 320,           "y": 185,           "text": "Davinci Li",           "font": "jiangxizhuokai",           "fontSize": 22,           "color": "#fff",           "width": 320,           "textAlign": "center"       },       {           "x": 320,           "y": 220,           "text": "邀请你来参加抽奖",           "font": "jiangxizhuokai",           "fontSize": 22,           "color": "#fff",           "width": 320,           "textAlign": "center"       },       {           "x": 30,           "y": 640,           "text": "奖品: 本田-CB650R 摩托车",           "font": "jiangxizhuokai",           "fontSize": 22,           "color": "#000",           "width": 580,           "textAlign": "left"       },       {           "x": 30,           "y": 676,           "text": "01 月 31 日 18:00 自动开奖",           "font": "jiangxizhuokai",           "fontSize": 18,           "color": "#9a9a9a",           "width": 580,           "textAlign": "left"       },       {           "x": 320,           "y": 960,           "text": "长按识别二维码，参与抽奖",           "font": "jiangxizhuokai",           "fontSize": 22,           "color": "#9a9a9a",           "width": 580,           "textAlign": "center"       }   ],   "lines":[       {           "startX": 30,           "startY": 696,           "endX": 610,           "endY": 696,           "width": 1,           "color": "#E1E1E1",           "zIndex": 1       }   ],   "images":[       {           "x": 248,           "y": 25,           "width": 120,           "height": 120,           "url": "https://img-chengxiaoli-1253325493.cos.ap-beijing.myqcloud.com/bikers_327390-13.jpg",           "borderRadius": 60,           "zIndex": 1       },       {           "x": 108,           "y": 285,           "width": 400,           "height": 300,           "url": "https://img-chengxiaoli-1253325493.cos.ap-beijing.myqcloud.com/cb650R.jpeg",           "zIndex": 1       }   ],   "qrcodes":[       {           "x": 208,           "y": 726,           "size": 200,           "content": "http://weixin.qq.com/r/yRzk-JbEbMsTrdKf90nb",           "foregroundColor": "#000",           "backgroundColor": "#fff",           "zIndex": 1       }   ] }' 请求返回内容： { "code":0, "message":"OK", "data":"https://davinci.imgrender.cn/c3037d467c163bd903760f96a34f3bcd.jpg?sign=1616722062-plQZQ4xtth9tEthx-0-2a98ba98e5fd44cc6dffb3aec6d3398f" } [代码]data[代码] 字段就是动态渲染好的海报图片链接，下载或打开链接就可保存图片。查看详细使用方法。 [图片] imgrender.net 推荐按以下最佳实践来使用海报生成服务： [图片] 所有的海报配置全都管理在服务端中，服务端只需要提供一个 API 给客户端。客户端通过这个 API 请求不同的分享图，服务端接收到请求后，先检查服务端是否缓存分享图。若没有缓存图片，则使用海报配置去 imgrender 动态生成海报，然后将生成的图片链接返回给客户端，供用户下载保存。 使用 imgrender 动态渲染海报，在满足需求的同时，可以大幅度降低开发成本，提高多端兼容性。无论是开发小程序海报，还是原生应用中的海报，一套代码即可搞定。 [图片] 原文链接：https://mp.weixin.qq.com/s/6ss1D4wneNDuhUfplualQQ 关键词：海报图、海报分享图、海报生成、图片生成、小程序海报生成

订阅号付费能力功能介绍目前微信灰度测试订阅号付费能力，符合条件的运营者可以前往公众平台开通付费功能。成功开通后，运营者可对原创文章的部分或全部内容设置收费，用户购买文章后方可阅读全文。 Q：为什么要开通付费阅读功能？ A：好的内容创作者，值得更好的受益，微信平台努力为优质的内容创作者提供更多能力，让创造价值的人体现价值。 Q：什么样的内容可以设置付费？ A：注册超过 3 个月、近 3 个月内无严重违规记录、已发表至少 3 篇原创文章的订阅号可以开通付费功能。目前付费功能正在灰度测试，符合以上开通条件的订阅号即有机会被灰度。 成功开通后，运营者可对原创文章的部分或全部内容设置收费，用户需要购买后才能阅读全部内容。 通过订阅号列表右上角“…”进入“我的付费内容”， 用户可查看自己曾经付费过的订阅号和对应的付费内容。 Q：付费文章有规定价格吗？ A：目前，运营者可在 1~208 元里的 35 个价格档位选择合适的定价，暂时不支持运营者自定义价格。 Q：如何设置付费阅读比例？ A：运营者可以在公众号后台编辑器底部的“图文类型”里选择“付费图文”，根据指引设置文章可试读的比例，以及购买定价。 Q：目前哪些帐号有灰度测试资格？ A：目前，付费功能仅对部分符合条件的个人订阅号进行灰度，暂不开放申请。后续将陆续为更多帐号提供该能力，敬请期待。 Q：iOS 端和安卓端都支持购买吗？ A：订阅号付费内容支持 iOS 端与安卓端用户购买，iOS 端通过苹果 IAP支付，安卓用户则通过微信支付进行付费。 Q：收入是否全部给到运营者？平台会抽成吗？ A：依据苹果公司《Apple Developer Program》条款规定，微信先与苹果公司结算，其余款项将配合苹果结算周期提供给运营者。      安卓端款项暂无渠道成本，每月结算给运营者。灰度期间平台暂不抽成。 Q：付费阅读的文章可以被删除吗？ A：运营者可以自行删除付费阅读文章。如文章违反《微信公众平台运营规范》，平台将依据规定进行相关处罚。      对文章付费，是用户对订阅号的信任。我们建议运营者对付费阅读文章质量进行严格把关，对用户负责。如因运营者自行删文导致了用户投诉或纠纷，平台会视情况进行相关处罚。 Q：文章设置为付费后是否还能使用赞赏功能？ A：付费文章暂时不支持使用赞赏功能。 Q：媒体和政府、企业帐号是否可以开设付费阅读？ A：灰度期间暂不支持。 Q：我支付过的文章，能否转发给朋友看？ A：付费文章仅付费用户可查看，其它用户无论从什么途径获得文章，都需要购买后才能阅读。 Q：是否有包年/包月等选择？ A：目前仅对单篇文章提供阅读付费能力。 付费功能的运营规范： 好的内容创作者，值得更好的受益，平台愿意为优质的内容创作者提供付费功能，让创造价值的人体现价值。 如果公众号利用付费功能进行赌博、募捐、抽奖等违反《微信公众平台运营规范》的行为，平台将依据规定进行相关处罚，处罚手段包括但不限于禁止文章继续收费、封禁公众号的付费功能、冻结公众号未结算资金等。

小程序 ios 正式版调起支付api出现这个错误，但是体验版和开发板都能正常调起支付是什么原因？

报错信息： requestPayment:fail jsapi has no permission, 具体在开发调试时可以支付，体验可以支付，就是发布版本不能支付 商户号： 1573122611 权限都已授权了 [图片] [图片] 体验版本和开发版本都可以正常支付 [图片]

[图片] [图片]

微信小游戏，用户进入客服会话会在右下角显示"可能要发送的小程序"提示，用户点击后可以快速发送小程序消息，客服这边要自动回复图片二维码等一系列自动回复功能。这个需要在后台开启消息推送功能吗？

wx.openCustomerServiceConversation()， 这个中的参数sendMessagePath（会话内消息卡片路径），是什么格式，怎么填写？

您好，想请教个问题，为什么我们小游戏注册新增的用户来源，会有“最近使用”这个来源。最近使用不应该是老用户么~ 请指教，谢谢！

[图片]

为什么我的访问来源总数加起来与新增注册不一样，总是会少一些

请问，小游戏统计后台新增注册用户来源里的“第三方APP”（如截图），具体是从哪里来的新增用户呢，谢谢 [图片]

是进入游戏就算注册，还是开始游戏才算一个注册。有些导出需要允许，有点广告不需要。 比如玩家点击广告/导出跳转，loading页加载未完成即退出，是否算新增？ loading页加载完成，出现开始游戏按钮，但是不点击游戏开始就退出，是否选新增 ？

请问小游戏数据助手上显示的注册来源中的 “会话”和“H5” 是分别从哪里进来的用户呢？谢谢~

我昨天从mp后台投放的微信广告。首屏留存率只有32%。其中我的首包只有565k，云测试上的“启动性能”也是94分。但是从微信广告买来的用户的代码包留存率和首屏留存率都特别低。请问我应该怎么优化，才能让首屏留存率提高？ [图片]图1：首包体积565k [图片]图2：云测试结果：启动性能94分 [图片]图3：从微信广告买的量，首屏留存率32.9% 重复一遍问题：我怎样优化，才能提高首屏留存率？？？？？

[图片] 启动耗时大概2秒， 下载代码包的启动留存率是100%， 但是不下载代码包的启动留存率只有75%？ 安卓上也有类似的问题， 不过好像没有这么严重

[图片][图片] 以上是最近通过mp导入了约几千用户后，每天的普遍情况 安卓端平均加载3秒多点，但代码包留存率始终维持在35%-40%，首屏打开留存率始终在20%左右 苹果端前者好些，90%上下，首屏打开留存率在60-90之间浮动 我们的疑问：为什么冷启动总耗时只有3秒多的情况下，约80%的用户都没有来到首屏渲染阶段？ 另外据微信后台统计，“微信广告”来源的用户，这几天平均在线时长始终都在几秒，十几秒，二十几秒范围内，而主动进入的活跃用户平均时长普遍在700秒-1000秒。是否可以认为广告来的用户基本都是点了一下广告就走了？

[图片]

小程序代码包是哪个文件，微信开发者工具-项目基本配置中显示主包3042.5kb，但仍可以预览....

前言 微信小游戏云测试服务的开放之后，越来越多的开发者使用该功能测试自己的小游戏的性能。但是大部分小游戏的测试结果显示，启动性能得分很低，远远达不到80分的标准线，甚至难以达到60分。 [图片] 根据微信小游戏文档中的启动优化最佳实践，优化思路一共有6种： 精简首包资源 分包加载 引擎插件 预下载能力 降低首屏渲染资源 尽快渲染。 常规的优化思路往往是两步： 拆分代码包，精简首包资源，使得首包只存首屏图片和一个加载进度条及相关代码； 使用分包加载。 根据小游戏的启动时序，会发现，降低代码包资源会减少了代码包下载，以及在某种程度下降低JS注入耗时。 [图片] 然而，即使启动优化到这一步，很多小游戏依旧得不到理想的分数。因为使用引擎开发的小游戏，即便只留首包必要资源，也会保留引擎代码，这无非会增加很长时间的JS注入耗时，以及首屏渲染耗时也未得到优化。此时很多开发者已经非常苦恼：我该如何优化呐？ 自然而然，解决思路无非是，1. 降低注入代码的大小来减少JS注入耗时; 2. 简化首屏渲染逻辑，比如不依赖第三方引擎进行轻量渲染。但是，怎么做呐？ 本文，将结合上面的两个解决思路，提供一套不依赖引擎(WebGL/Canvas2D直接渲染首屏)的小游戏首包加载套路，即减少了引擎代码注入耗时，又避免了第三方引擎的重度渲染。该方式可以直接套用，使用后的小游戏的启动性能在云测试报告下的启动性能得分能达到90及以上。 背景 目前微信官方文档、微信小游戏社区和各个引擎社区已经有很多篇关于启动优化的文章。除了微信官方文档，在微信小游戏社区和cocos 社区下有两篇非常优秀的使用WebGL渲染首屏的文章： 小游戏首屏启动优化 Cocos Creator 微信小游戏平台启动与包体优化（首屏渲染耗时降低 50%） 尤其是第二篇，很多开发者都查资料时查到这一篇文章，按照这篇文章的逻辑来优化小游戏能够达到很理想的效果，本文的思路也是基于该文章之上进一步优化。这两篇文章均是直接使用WebGl渲染首屏，能够达到很理想的效果。强烈先去看一眼这两篇文章及下面的评论，基本上遇到的所有问题都有解答。 但是二者有着各自的缺陷： 第一篇文章简练地介绍了优化思路，但是直接使用的话需要理解WebGL的逻辑并进行改造，存在难度； 第二篇文章是一片很优秀的文章，大家可以先学习一下。该文章中的代码虽然可以直接使用套用，但是代码逻辑和gl渲染的使用方式存在一定的错误，比如重复创建图片，未使用rAF渲染等，这些错误会导致微信客户端统计启动耗时出现异常。然而，因为对gl改写的难度比较大，所以，本文基于第二篇文章中的WebGL渲染首屏的代码进行了改造，附上了正确的使用方式，并额外新增了一份使用Canvas2D渲染首屏的代码。 代码片段 话不多说，附上代码片段： 1. WebGL渲染 webGL代码理解起来还是有难度的，所以代码中的 [代码]webgl_first_render.js[代码]可以直接使用，使用方式可以参考[代码]game.js[代码]。这段代码解决了文章二中的云测启动耗时统计错误、启动黑屏、横屏渲染错误、内存泄漏、屏幕闪烁等异常情况。 代码片段如下： https://developers.weixin.qq.com/s/tknkPjmr7Glg 2. Canvas2D渲染 Canvas2D渲染使用CanvasRenderingContext2D对象 直接渲染。实现上很简单，改造起来也很容易。其实现逻辑是和webgl是一样的。 代码片段如下： https://developers.weixin.qq.com/s/QWno6jmW7Ylx

一、优化启动的意义 衡量一个游戏好坏的一个很重要的标准就是留存，而启动时间直接决定了第一波玩家的流失率。当用户打开游戏，满怀期待的等待游戏开始。最好的情况是游戏在1-2秒内给与反馈，或者能让用户进行下一步操作。一般首次打开，由于首包需要从服务器下载，都会有一个等待过程。在这个等待的过程中，用户的忍耐度是慢慢降低的。如果游戏在2-5秒之后才进入可用的状态，首屏留存就会受到影响。最后如果游戏超过5秒甚至更久才显示首屏，这时用户的耐心可能完全消失，有一部分用户可能会退出重新进入，但更多的用户会放弃使用。 根据小游戏整体启动留存率分析，Android玩家的首屏打开留存率约为85%。这是什么意思呢，就是玩家从点击小游戏到能看到首屏的渲染界面大约有15%的玩家流失。对于首次玩某款小游戏的玩家，由于本地没有版本缓存，留存率会明显低很多。据统计，仅代码包加载阶段新玩家流失率就达到20%。（以上数据来源微信小游戏性能优化指南） 二、晒数据 以下数据来自我们游戏优化前后的数据对比 [图片] 三、启动性能优化 小游戏启动加载时序 以下是官方给出的启动时序图和优化建议 [图片] [图片] 1.首包优化上面，我们可以完全按照官方的建议，尽量减少首包的大小，由于我们对引擎有定制，所以暂未使用引擎插件能力，我们首包中只存放了引擎及基础的启动代码，大小为1.5M。如果使用引擎插件功能，这个大小可以缩减到300K。 2.我们在首包中仅放入了游戏引擎的代码和一些必要的资源。这时候游戏尚不能完整运行，因为游戏的逻辑代码在子包中，需要进一步的加载。但是这时我们要尽快让游戏给出反馈，也就是显示首屏。首屏的内容绘制我们有两种方案：1）依赖游戏引擎绘制 2）不依赖引擎直接绘制。 1）依赖游戏引擎进行绘制 我们利用引擎进行绘制，要做到资源尽量少，能够满足绘制一个启动图和一个进度条就可以了。 a.对于使用CocosCreator制作的游戏：我们可以在游戏启动的时候， 对于第一个场景那里使用动态创建场景的方式， [图片] 这个动态创建的场景，只使用放在首包里的一些资源。 b.对于使用Laya制作的游戏：我们把原本放在工程代码里的入口代码提取出来，完成Stage的初始化。这样我们就可以做绘制了。 [图片] 2）不依赖引擎直接绘制 在第一种方案中，优化的方向也是尽量减少第一个场景的资源。但是忽略了一个很耗时的过程，引擎初始化。这一步经测试，iOS在100ms以内，安卓在1-2s。如果能把安卓这1-2s的时间优化，想想都兴奋。 为了使首屏等待时间减少到极致，在引擎初始化之前，我们自己来渲染第一帧。我们的游戏使用的Cocos Creator引擎，默认使用WebGL。我们绘制了一个最简单的黑色三角形作为游戏的第一帧。 [代码]//顶点着色器程序 var VSHADER_SOURCE = "attribute vec4 a_Position;" + "void main() {" + //设置坐标 "gl_Position = a_Position; " + "} "; //片元着色器var FSHADER_SOURCE = "void main() {" + //设置颜色 "gl_FragColor = vec4(0.0, 0.0, 0.0, 0.0);" + "}";//获取canvas元素 GameGlobal.dycc = wx.createCanvas();//获取绘制二维上下文 var gl = dycc.getContext('webgl'); //编译着色器 var vertShader = gl.createShader(gl.VERTEX_SHADER); gl.shaderSource(vertShader, VSHADER_SOURCE); gl.compileShader(vertShader); var fragShader = gl.createShader(gl.FRAGMENT_SHADER); gl.shaderSource(fragShader, FSHADER_SOURCE); gl.compileShader(fragShader); //合并程序 var shaderProgram = gl.createProgram(); gl.attachShader(shaderProgram, vertShader); gl.attachShader(shaderProgram, fragShader); gl.linkProgram(shaderProgram); gl.useProgram(shaderProgram); //获取坐标点 var a_Position = gl.getAttribLocation(shaderProgram, 'a_Position'); var n = initBuffers(gl,shaderProgram); if(n<0){ console.log('Failed to set the positions'); } // 清除指定<画布>的颜色 gl.clearColor(0.0, 0.0, 0.0, 1.0); // 清空 <canvas> gl.clear(gl.COLOR_BUFFER_BIT); gl.drawArrays(gl.TRIANGLES, 0, n); function initBuffers(gl,shaderProgram) { var vertices = new Float32Array([ 0.0, 0.5, -0.5, -0.5, 0.5, -0.5 ]); var n = 3;//点的个数 //创建缓冲区对象 var vertexBuffer = gl.createBuffer(); if(!vertexBuffer){ console.log("Failed to create the butter object"); return -1; } //将缓冲区对象绑定到目标 gl.bindBuffer(gl.ARRAY_BUFFER,vertexBuffer); //向缓冲区写入数据 gl.bufferData(gl.ARRAY_BUFFER,vertices,gl.STATIC_DRAW); //获取坐标点 var a_Position = gl.getAttribLocation(shaderProgram, 'a_Position'); //将缓冲区对象分配给a_Position变量 gl.vertexAttribPointer(a_Position, 2, gl.FLOAT, false, 0, 0); //连接a_Position变量与分配给它的缓冲区对象 gl.enableVertexAttribArray(a_Position); return n; } [代码] 有了第一帧的绘制，用户可以很快进入到游戏内，不会长时间的在官方白色的加载进度屏那里等待。我们还需要做一些其他处理，不然玩家看到的将是一个黑屏。后续的处理也有两种方案，一种就是如果你对WebGL比较熟悉，可以自行完成更复杂的绘制。另外一种方案就是巧妙利用官方提供的功能。我们这里详细说下后面一种方案。 为了盖住黑屏，我们需要绘制一张启动图。这时候我们使用官方提供的接口[代码]wx.createUserInfoButton[代码]来创建一个满屏的按钮，按钮的背景图就是我们的启动图。但是这时候如果用户点击屏幕，就会造成提示用户授权，这不是我们想要的。接着我们使用官方的另外一个接口[代码]wx.showLoading[代码]，创建一个模态加载弹窗就可以解决这个问题了。有了这样一个首屏，剩下的就是尽快加载子包，开始真正的游戏内容。 四、Demo 希望大家也都能探索一下首屏加载的过程。我们提供了一个简单的demo示例，通过链接即可下载到。打开demo中的index.js文件，里面有操作步骤说明。 laya的例子： 链接: https://pan.baidu.com/s/18RS9HWpmp5l0V3WGQdNvzw 提取码: bdji cocos的例子： 链接: https://pan.baidu.com/s/1c_UPwdlEFuqprmG-QGMvpQ 提取码: jggt 五、结语 以上就是我们的启动优化方案，欢迎各位游戏开发者交流或提出宝贵的建议,对游戏充满热爱的小伙伴也可以选择加入我们大禹网络。HR邮箱：guyifen@dayukeji.com

首屏时间是指用户从打开小程序看到第一屏主要内容的时间，首屏时间太长会导致用户长时间看到的都是白屏，影响使用体验。 优化首屏时间，可以分为以下几种情况： 首屏渲染的内容较多，需要集合多份数据进行渲染。这种情况需要开发者把内容分优先级，把优先级高的内容做优先展示，缩短白屏时间；首屏内容依赖的数据从服务端请求的时间太长。开发者需要从服务端侧具体分析服务端数据返回的时间长的原因；一次性渲染数据太大或依赖的计算过于复杂。减少渲染的数据量、优化渲染相关数据的算法可以解决这类问题。这里想问下，第一屏指的具体是什么呢？是指 initial data 被渲染的那一刻吗？还是指 DOM 元素铺满屏幕那一刻呢？

校友会小程序启动是用户体验中极为重要的一环，启动耗时过长会造成校友会小程序用户流失   开发者代码注入（逻辑层）校友会小程序启动时需要从代码包内读取小程序的配置和代码，并注入到 JS 引擎中。 在校友会主包代码注入过程中，会触发小程序的 [代码]App.onLaunch[代码] 和首次 [代码]App.onShow[代码] 生命周期。 在校友会开发者代码注入完成后，框架侧会根据校友会用户访问的页面进行一些页面数据初始化工作，触发首页的 [代码]Page.onLoad[代码], [代码]Page.onShow[代码] 事件。   对启动耗时的影响 校友会开发者代码的注入耗时直接影响小程序的启动耗时。 在主流的 JS 引擎中，代码注入耗时包括编译和执行等环节，代码量、同步接口调用和一些复杂的计算，都会影响注入耗时。 由于校友会首页渲染需要使用逻辑层发送的数据，如果开发者代码注入耗时过长，也会延迟首页渲染开始的时间。 在部分平台校友会上，微信客户端会使用 V8 引擎的 Code Caching 技术对代码编译结果进行缓存，降低二次注入时的编译耗时    开发者代码注入（渲染层）校友会开发者的 wxss 和 wxml 会经过编译注入到渲染层，包含页面渲染需要的页面结构和样式信息。 渲染层的注入耗时主要和校友会页面结构复杂度和使用的自定义组件数量有关。 渲染层和逻辑层的校友会开发者代码注入是并行进行的。 对启动耗时的影响 由于校友会首页渲染需要使用渲染层的页面结构和样式信息，如果开发者代码注入耗时过长，会延迟校友会首页渲染开始的时间。     首页（初次）渲染在校友会开发者代码注入完成后，结合逻辑层得到的数据和渲染层得到的页面结构和样式信息，校友会小程序框架会进行小程序首页的渲染， 展示小程序首屏，并触发首页的 [代码]Page.onReady[代码] 事件。[代码]Page.onReady[代码] 事件触发标志小程序启动过程完成。   对启动耗时的影响 校友会首页渲染耗时主要受页面结构和参与渲染的数据量影响   小程序首屏渲染完成从开发者角度看，校友会小程序首屏渲染完成的标志是首页 [代码]Page.onReady[代码] 事件触发。 从框架的角度来说，校友会小程序的首屏的内容是基于小程序的初始数据，以及在渲染开始前到达的 setData 数据渲染的。 首屏渲染完成不表示小程序页面一定有完整内容，开发者触发的 [代码]setData[代码]（例如通过 [代码]wx.request[代码] 异步请求数据）不一定能参与到首屏渲染中。 由于框架和启动流程的差异，小程序定义的首屏渲染完成不等同于浏览器的 load 事件。   小程序启动阶段从校友会用户点击访问小程序到小程序首屏渲染完成（首页 [代码]Page.onReady[代码] 事件触发）。   打开率/到达率校友会小程序首屏渲染完成 PV 与 用户点击访问小程序 PV 的比值。[代码]流失率 = 1 - 打开率[代码]   小程序代码包优化代码包优化的核心手段是降低代码包大小，校友会小程序代码包大小直接影响了下载耗时，影响用户启动校友会小程序时的体验。 开发者可以采取以下手段优化校友会小程序代码包大小 1 校友会小程序分包加载2 校友会小程序代码重构和优化3 控制代码包内图片等资源4 及时清理没有使用到的校友会小程序代码和资源

[图片] 一、基本信息 引擎版本cocos creator 2.3.3 二、参考文章 1、最佳实践: https://developers.weixin.qq.com/minigame/dev/guide/performance/perf-action-start2.html 2、Cocos Creator 微信小游戏平台启动与包体优化（首屏渲染耗时降低 50%）: https://forum.cocos.org/t/cocos-creator-50/94999 三、优化结果对比 3.1 优化前加载速度: 8605ms [图片] 3.2优化后加载速度:4366ms [图片] 四、优化前资料准备 根据微信官方文档启动优化最佳实践图示: [图片] 优化启动速度主要有6点: 1.精简包内资源: 本项目已优化过 2.分包加载: 可以尝试，具体步骤见5.2 3.引擎插件能力: 可以尝试，打包时选择允许引擎分离即 4.预下载能力: 仍处于内测中 5.降低首屏渲染所需资源数目: 可以尝试，具体步骤见5.1 6.尽快渲染: 可以尝试，具体步骤见5.3 五、优化实践 有了思路之后根据复杂度由简入繁按照如下步骤开始优化 5.1 降低首屏渲染所需资源数目 启动页只放一张背景图，除了跳转至加载页不做其他处理，减少启动页的资源加载和逻辑处理 [代码]cc.Class({ extends: cc.Component, properties: { }, // LIFE-CYCLE CALLBACKS: // onLoad () {}, start () { cc.director.loadScene("LoginScene"); }, // update (dt) {}, }); [代码] 修改完后加载速度如图 [图片] 5.2 分包加载 除了启动页以外，其他所有代码都放到子包中加载(官方文档)，启动页代码稍作修改 [代码]cc.Class({ extends: cc.Component, properties: { }, // LIFE-CYCLE CALLBACKS: // onLoad () {}, start () { cc.loader.downloader.loadSubpackage('subpackage', function (err) { if (err) { return console.error(err); } cc.director.loadScene("LoginScene"); }); }, // update (dt) {}, }); [代码] 修改完后: 5.3 尽快渲染-引擎加载前自绘制启动页 根据参考文档(https://forum.cocos.org/t/cocos-creator-50/94999)进行操作 1.自定义微信发布模板（定制项目构建流程），将首屏渲染代码及图片放到发布模板中,按照文档操作，项目根目录想创建目录build-templates，然后创建wechatgame目录 2.在 wechatgame 目录下新建 first-screen.js 脚本，拷贝以下内容： [代码] // Vertex shader program var VSHADER_SOURCE = 'attribute vec4 a_Position;\n' + 'attribute vec2 a_TexCoord;\n' + 'varying vec2 v_TexCoord;\n' + 'void main() {\n' + ' gl_Position = a_Position;\n' + ' v_TexCoord = a_TexCoord;\n' + '}\n'; // Fragment shader program var FSHADER_SOURCE = '#ifdef GL_ES\n' + 'precision mediump float;\n' + '#endif\n' + 'uniform sampler2D u_Sampler;\n' + 'varying vec2 v_TexCoord;\n' + 'void main() {\n' + ' gl_FragColor = texture2D(u_Sampler, v_TexCoord);\n' + '}\n'; /** * Create a program object and make current * @param gl GL context * @param vshader a vertex shader program (string) * @param fshader a fragment shader program (string) * @return true, if the program object was created and successfully made current */ function initShaders(gl, vshader, fshader) { var program = createProgram(gl, vshader, fshader); if (!program) { console.log('Failed to create program'); return false; } gl.useProgram(program); gl.program = program; return true; } /** * Create the linked program object * @param gl GL context * @param vshader a vertex shader program (string) * @param fshader a fragment shader program (string) * @return created program object, or null if the creation has failed */ function createProgram(gl, vshader, fshader) { // Create shader object var vertexShader = loadShader(gl, gl.VERTEX_SHADER, vshader); var fragmentShader = loadShader(gl, gl.FRAGMENT_SHADER, fshader); if (!vertexShader || !fragmentShader) { return null; } // Create a program object var program = gl.createProgram(); if (!program) { return null; } // Attach the shader objects gl.attachShader(program, vertexShader); gl.attachShader(program, fragmentShader); // Link the program object gl.linkProgram(program); // Check the result of linking var linked = gl.getProgramParameter(program, gl.LINK_STATUS); if (!linked) { var error = gl.getProgramInfoLog(program); console.log('Failed to link program: ' + error); gl.deleteProgram(program); gl.deleteShader(fragmentShader); gl.deleteShader(vertexShader); return null; } return program; } /** * Create a shader object * @param gl GL context * @param type the type of the shader object to be created * @param source shader program (string) * @return created shader object, or null if the creation has failed. */ function loadShader(gl, type, source) { // Create shader object var shader = gl.createShader(type); if (shader == null) { console.log('unable to create shader'); return null; } // Set the shader program gl.shaderSource(shader, source); // Compile the shader gl.compileShader(shader); // Check the result of compilation var compiled = gl.getShaderParameter(shader, gl.COMPILE_STATUS); if (!compiled) { var error = gl.getShaderInfoLog(shader); console.log('Failed to compile shader: ' + error); gl.deleteShader(shader); return null; } return shader; } function initVertexBuffers(gl, vertices) { var verticesTexCoords = vertices || new Float32Array([ // Vertex coordinates, texture coordinate -1, 1, 0.0, 1.0, -1, -1, 0.0, 0.0, 1, 1, 1.0, 1.0, 1, -1, 1.0, 0.0, ]); var n = 4; // The number of vertices // Create the buffer object var vertexTexCoordBuffer = gl.createBuffer(); if (!vertexTexCoordBuffer) { console.log('Failed to create the buffer object'); return -1; } // Bind the buffer object to target gl.bindBuffer(gl.ARRAY_BUFFER, vertexTexCoordBuffer); gl.bufferData(gl.ARRAY_BUFFER, verticesTexCoords, gl.STATIC_DRAW); var FSIZE = verticesTexCoords.BYTES_PER_ELEMENT; //Get the storage location of a_Position, assign and enable buffer var a_Position = gl.getAttribLocation(gl.program, 'a_Position'); if (a_Position < 0) { console.log('Failed to get the storage location of a_Position'); return -1; } gl.vertexAttribPointer(a_Position, 2, gl.FLOAT, false, FSIZE * 4, 0); gl.enableVertexAttribArray(a_Position); // Enable the assignment of the buffer object // Get the storage location of a_TexCoord var a_TexCoord = gl.getAttribLocation(gl.program, 'a_TexCoord'); if (a_TexCoord < 0) { console.log('Failed to get the storage location of a_TexCoord'); return -1; } // Assign the buffer object to a_TexCoord variable gl.vertexAttribPointer(a_TexCoord, 2, gl.FLOAT, false, FSIZE * 4, FSIZE * 2); gl.enableVertexAttribArray(a_TexCoord); // Enable the assignment of the buffer object return n; } function initTextures(gl, n, imgPath) { var texture = gl.createTexture(); // Create a texture object if (!texture) { console.log('Failed to create the texture object'); return false; } // Get the storage location of u_Sampler var u_Sampler = gl.getUniformLocation(gl.program, 'u_Sampler'); if (!u_Sampler) { console.log('Failed to get the storage location of u_Sampler'); return false; } var image = wx.createImage(); // Create the image object if (!image) { console.log('Failed to create the image object'); return false; } // Register the event handler to be called on loading an image image.onload = function () { loadTexture(gl, n, texture, u_Sampler, image); }; // Tell the browser to load an image image.src = imgPath; return true; } function loadTexture(gl, n, texture, u_Sampler, image) { gl.pixelStorei(gl.UNPACK_FLIP_Y_WEBGL, 1); // Flip the image's y axis // Enable texture unit0 gl.activeTexture(gl.TEXTURE0); // Bind the texture object to the target gl.bindTexture(gl.TEXTURE_2D, texture); // Set the texture parameters // gl.texParameteri(gl.TEXTURE_2D, gl.TEXTURE_MIN_FILTER, gl.LINEAR); gl.texParameteri(gl.TEXTURE_2D, gl.TEXTURE_MIN_FILTER, gl.LINEAR); gl.texParameteri(gl.TEXTURE_2D, gl.TEXTURE_MAG_FILTER, gl.LINEAR); gl.texParameteri(gl.TEXTURE_2D, gl.TEXTURE_WRAP_S, gl.CLAMP_TO_EDGE); gl.texParameteri(gl.TEXTURE_2D, gl.TEXTURE_WRAP_T, gl.CLAMP_TO_EDGE); // Set the texture image gl.texImage2D(gl.TEXTURE_2D, 0, gl.RGB, gl.RGB, gl.UNSIGNED_BYTE, image); // Set the texture unit 0 to the sampler gl.uniform1i(u_Sampler, 0); gl.clear(gl.COLOR_BUFFER_BIT); // Clear <canvas> gl.drawArrays(gl.TRIANGLE_STRIP, 0, n); // Draw the rectangle } function drawImg(imgPath) { const vertices = new Float32Array([ -1, 1, 0.0, 1.0, -1, -1, 0.0, 0.0, 1, 1, 1.0, 1.0, 1, -1, 1.0, 0.0, ]); // Retrieve <canvas> element // var canvas = document.getElementById('webgl'); // Get the rendering context for WebGL // var gl = getWebGLContext(canvas); const gl = wx.__first__canvas.getContext("webgl"); if (!gl) { console.log('Failed to get the rendering context for WebGL'); return; } // Initialize shaders if (!initShaders(gl, VSHADER_SOURCE, FSHADER_SOURCE)) { console.log('Failed to intialize shaders.'); return; } // Set the vertex information var n = initVertexBuffers(gl, vertices); if (n < 0) { console.log('Failed to set the vertex information'); return; } // Specify the color for clearing <canvas> gl.clearColor(1.0, 1.0, 1.0, 1.0); // Set texture if (!initTextures(gl, n, imgPath)) { console.log('Failed to intialize the texture.'); return; } exports.drawImg = drawImg; [代码] 3.拷贝首屏图片到同目录下，重命名为 bg.png 4.创建一个脚本 game-backup.js ，拷贝以下内容： “use strict”; [代码] // 渲染首屏（开发者工具执行有渲染问题，所以开发者工具上不渲染） wx.__first__canvas = wx.createCanvas(); const data = wx.getSystemInfoSync(); if (data.platform != "devtools") { const first_scene = require("./first-screen.js"); first_scene.drawImg("bg.png"); } // 加载引擎代码写在这后面 [代码] 5.打开 Cocos Creator，点击右上角的编辑器进入编辑器安装目录 6.找到 builtin 目录，再依次进入adapters/platforms/wechat/wrapper/builtin 目录，打开 Canvas.js 文件入修改如下代码: [代码]// 修改前 export default function Canvas() { const canvas = wx.createCanvas() // 修改后 let first = true export default function Canvas() { [代码] 8.先试一下能否正常运行，可以的话把 game.js 删除，用 game-backup.js 替换 game.js,game.js在替换的时候注意远程服务器地址配置(remoteDownloader.REMOTE_SERVER_ROOT = “”)需要根据实际情况修改 至此完成优化。

[图片] ------------------------------------------------------------------------------------------------------------------------- 想明确一下，咱们微信小游戏数据助手中注册用户的统计，是在何时判定用户的注册行为呢？ 注意到小游戏启动流程图上，标识了初始用户，那么用户的注册新增统计数据，是否是在环境加载完成后进行的上报？

[图片] 这两个指标都是最近使用，聊天往下拉里面有最近使用，两个方面，具体是对应什么场景？ 没有对上

[图片]

[图片]

在查看整体来源打开次数时，发现一周里（5月31日至6月6日）长按二维码为419次，单独选取一天查看时，发现6月4日打开次数为417次，6月3日打开次数为415次。截图如下。 [图片][图片][图片] 这里是打开次数啊，不应该去重的啊，为什么会这样？ 而且分场景访问趋势里显示长按二维码发生在6月4号，只有413次。截图如下。 [图片] 麻烦解答一下哦 另外文章里如果带二维码，用户看了文章长按二维码，那来源分析算文章还是长按二维码啊？

微信小程序官方指标定义： 打开次数：打开小程序的总次数。用户从打开小程序到主动关闭或超时退出小程序的过程，计为一次。 访问次数：访问小程序页面的总次数。多个页面之间跳转、同一页面的重复访问计为多次访问。 按照微信定义的指标来看，小程序访问次数应该大于等于打开次数，实际出现打开次数大于访问次数的现象，这种情况会是什么原因造成的？

我们对比了数据助手的新增和活跃用户，人均时长等指标，跟我们自己统计的指标相差不大。 这种情况下代码包加载留存率和首屏打开留存率只有40%-50%，这就很不解了：如果是没打开首屏，我们自己的统计应该比小游戏数据助手的新增和活跃人数应该减半才对。所以想问一下代码包加载留存率和首屏打开留存率是统计了所有的活跃用户吗，还是采样的是一部分的而已？

问题一：看图1和图2， 调用打开比是 接口调红次数/小程序打开次数， 而且上限是 2。 那不就是说 wx.login 调用次数，用户打开微信，最多调用两次？ 问题二：图3 说 ，wx.login 的规范，一天的调用总次数不多于该小程序pv 的两倍，如果按照图一、图二的结果，是不是说 pv 就是小程序打开次数？ [图片][图片][图片]