内含开店指引、店铺运营和平台规则，帮你快速掌握小商店经营秘诀。

在前端圈中最不缺少的就是新技术，几乎每个月都会出现一些新的 npm 包、新框架、新名词。当一篇流行框架发布新版本时，或者当一篇文章解释某个新即使时，下面的评论往往都是： 求求你别更新了，我已经学不动了。或者 ​来人啊，扶我起来，我还能学。亦或者 能不能直接出 v999 啊，让我一次学完得了。只有一张图能描述前端开发者此时此刻的心情： [图片] 2020 年初的一场疫情让我们有了更多宅在家里学习的时间了。前不久我也受邀担任了腾讯主办的「协力抗疫，码力全开」线上公益黑客马拉松的嘉宾评委。这次黑马大赛和以往不同之处在于全程都是线上，自由组队，通过 2 天时间开发一款和抗击疫情相关的微信小程序。2 天时间有近 200 人提交了 80 多个参赛作品。 这次大赛还有一个技术上的两点就是“云开发”。 提到云开发，我们自然会想到另一个概念，那就是 Serverless。毫无疑问 2019 年是 Serverless 大规模推广的一年，无论是 Serverless 相关书籍和文章，还是各种大会上关于 Serverless 相关的主题，都是非常热门的。甚至有很多文章称 Serverless 为前端 3.0。 以 ajax 为代表的前端 1.0以 Node.js 为代表的前端 2.0以 Serverless 为代表的前端 3.0Node.js 更是把前端 JavaScript 的能力带到了服务器端，使得前端开发者可以方便的搞 Full Stack 或者 (BFF)Backends for Frontend。很多前端开发者也把自己的职业目标定义为了全栈工程师。显然这与主流软件开发的理念是违背的：让专业的人做专业的事。很多开发者也慢慢从“全栈工程师”变成了“全干工程师”——什么都会干，却什么都干不好。 你作为前端开发者，还懂如何配置 nginx。但是你配的 nginx 真的是最优的吗？为什么不交给专业的人去做呢？ 你作为前端开发者，还懂如何配置 mysql。但是你配的 mysql 真的是最优的吗？为什么不交给专业的人去做呢？ 你作为前端开发者，真的懂并发、网络、扩容、容灾、监控、日志吗？为什么不交给专业的人去做呢？ 通过本次黑马大赛期间我和几名开发者聊天，大概了解到了云开发的概念。基本上可以认为是一套构建于 Serverless 的最佳实践和解决方案，涵盖了 FaaS（Function as a service，函数即服务）和 BaaS（Backend as a service，后端及服务）的综合体。 具体实现为下图所示的模型： [图片] 以云开发体系提供的功能和服务为基础支撑，前端开发者的关注点除了 UI 和交互逻辑以外，能够以很小的成本接入以云函数为承载的业务逻辑层和以云数据库、云存储为支撑的数据存储层。简而言之，前端的关注点为：交互逻辑 + 业务逻辑（云函数）+ 数据（云数据库/云存储）。 [图片] 很多将 Serverless 的文章都会提到 CDN（Content Delivery Network，内容分发网络），这也是大多数前端开发者接触到的第一个 Serverless 服务，即使在 Serverless 这个名词诞生之前我们就已经使用了很久了。使用 CDN 开发者不需要关心文件的私密性、安全性、鉴权机制，不需要了解 CDN 服务器的状态、文件存储的具体位置，只需要部署文件即可，CDN 对于前端开发者来说就是 Serverless 的。 [图片] 在本次黑马大赛中 80% 多的开发者使用了云开发，而其中使用最多的功能则是云函数。云函数类似 AWS Lambda，开发者只需使用平台支持的语言编写核心代码并设置代码运行的条件，即可在腾讯云基础设施上弹性、安全地运行代码。 [图片] 云函数带来的最明显的优势就是用户只需编写最重要的“核心代码”，不再需要关心周边组件，极大地降低了服务架构搭建的复杂性。无需任何手动配置，云函数即可根据请求量自动横向扩缩。不管您的应用每天的请求数处于波峰还是波谷，SCF 均可自动安排合理的计算资源满足业务需求。 本次黑马大赛采用云开发还有一个最大的优势就是“零部署，零维护”，因此参赛者都是开发者，没有专业的运维工程师。而任何一个小程序的上线，除了大家看到的小程序，背后还有网关、计算服务、基础设施管理、数据库、文件服务、缓存服务等等。云开发提供了较完整的服务器架构，并且能够保证服务的稳定性。 在已经到来的 2020 年，Serverless 还有更多的可能性。最后还是那句老话： 来人啊，扶我起来，我还能学。

各位微信开发者： 以下是微信团队邀请开发者参与iOS微信内部体验及上周我们在社区收到的问题反馈、需求的处理进度，希望同大家一同打造小程序生态。 微信团队邀请开发者参与iOS微信7.0.15.18内部体验微信团队邀请开发者参与内部体验，本次更新概要如下： 小程序与小游戏： 小程序弱网优化，支持回退到本地代码，请关注启动流程是否正常；video、live-player 功能升级，请关注功能是否正常；小游戏添加插件权限校验流程，请关注启动流程是否正常。* 体验需长按下方二维码报名，若报名成功，则一天内会收到内测推送，内测名额8000人 [图片] 请基于以上提供的资源体验。使用过程中若发现问题，欢迎点击进入微信开放社区 #微信客户端内测 主页发表标题包含「微信iOS 7.0.15.18」的问答帖子反馈交流，发帖时建议提供以下信息方便定位问题： 手机型号手机操作系统版本必要时可提供代码片段如有需要，可访问社区#微信客户端内测 主页原公告：《微信团队邀请开发者参与iOS微信7.0.15.18内部体验》 上周问题反馈和处理进度（07.13-07.17）已修复的问题订阅号助手出现异常情况 查看详情 1.4版最新版开发者工具更新后调试器不能正常使用的问题 查看详情 微信开发者工具问题 查看详情 修复中的问题上传视频总提示离开网页，然后就无法上传的问题 查看详情 微信小游戏视频播放出现解码失败的问题 查看详情 FileSystemManager.statSync在真机无法使用recursive的问题 查看详情 websocket在手机上发不出消息的问题 查看详情 安卓端微信7.0.16版本运行小游戏问题 查看详情 自定义组件数据监听器的官方示范码上的标准库默认2.6.0，不符合最低要求的2.6.1，导致错误结果的问题 查看详情 上传代码和预览都失败，只提示错误信息 ，没有错误出处的问题 查看详情 小程序安卓选择图片（原图）后显示图片处理中并且得到的图片被压缩处理过的问题 查看详情 腾讯视频插件播放一部分视频不成功的问题 查看详情 Worker线程PostMessage数据ArraBuffer，在iPhone手机接收异常的问题 查看详情 小程序发布报错的问题 查看详情 运营者账号和管理员微信扫码都登陆不了，提示没有可登陆账号的问题 查看详情 iOS 手机上不能播放视频 查看详情 消息分析-消息关键词暂无消息的问题 查看详情 readFile api在pc端使用异常的问题 查看详情 Error:wxss编译错误的问题 查看详情 wx.saveVideoToPhotosAlbum 调用失败的问题 查看详情 连续的input adjust-position 不生效的问题 查看详情 小程序注册无法预览服务协议的问题 查看详情 卡劵领取页面深色模式下显示问题 查看详情 BackgroundAudioManager 通过顶部状态栏或浮标操作暂停 播放 停止 不出发事件的问题 查看详情 小程序真机调试及开发环境提示：HTTP/1.1 404 Not Found 的问题 查看详情 开发工具调试器报HTTP/1.1 404 Not Found 的问题 查看详情 【文档纠错】公众号打开小程序文档笔误 查看详情 chooseMedia 文档示例代码误导性错误 查看详情 文档标点错误 查看详情 小程序开发文档 onShareTimeline 错别字的问题 查看详情 需求反馈需求评估中wxBindCanvasTexture 这个 api 什么时候能支持安卓的需求 查看详情 可视化平台实现玩家之间的简单交互，比如捐赠道具的需求 查看详情 强烈建议：页面模板置顶的三个图片可以直接链接“专辑”的页面的需求 查看详情 微信公众号能不能开发标题修改的需求 查看详情 小程序直播 未来会有禁止分享的新功能吗 查看详情 页面模板添加新的文章后，建议能自动排在第一个，而不需要手动排序 查看详情 公众号的文章只能修改文字，不能修改排版吗？内容不变，修改排版不行吗 查看详情 区分未读文章与已读文章 查看详情 能不能在订阅号页删除已群发消息中，已删除的内容 查看详情 上传视频受限 查看详情 视频号的热门评论弹幕能不能让他一句话弹完整 查看详情 已删除的贴，想删除界面 查看详情 小程序什么时候能支持TCP Socket接口 查看详情 source map是否会合并 查看详情 希望可以给web开发者工具后面的收藏夹添加分组+备注 查看详情 微信小程序地图支持聚合显示吗 查看详情 公众号菜单什么时候才可以跳转专辑链接 查看详情 公众号发出后还发现标题有错能改正的需求 查看详情 付费功能里增加免费名单的需求 查看详情 可以直接通过房间id跳转到其他小程序的直播间的需求 查看详情 小程序直播插件增加打赏功能的需求 查看详情 能不能开放公众号发布图文消息中内容摘要修改功能 查看详情 公众号文章单篇收藏量如何浏览 查看详情 公众号群发定时时间可以开放至两天以上的需求 查看详情 相关阅读功能是否能关闭的需求 查看详情 摘要写错了能修改的需求 查看详情 开通留言功能的需求 查看详情 能否增加修改文章题目中错别字功能 查看详情 在PC端无法选择Excel等附件上传，后续是否会提供 chooseFile的API 的需求 查看详情 个人微信公众号删除的已群发图文，能不能在系统里同时删除图标呢?不要只是划一下,仍然占着页面位置 查看详情 自动回复功能上限问题进行调整的需求 查看详情 ​ 微信团队 ​ 2020.07.21

前言(写给入坑的小白) 本文不涉及任何需要资质的小程序（如：视频类目）。小程序流量主是个人和小微企业主要变现途径之一，满1000人即可开通流量主（登录mp.weixin.qq.com，左侧边栏-推广-流量主-开通即可）。开通后，开发者可从流量主-广告位管理添加广告位，目前有6种广告位。 [图片] 正文（本文约很多字，分为四大主类，手里有1-10个小程序建议全部看完；手里有10个以上小程序，可跳过1、2、3，均为个人观点，不喜使劲喷） 一、小程序定位 小程序定位目前有以下四种，均不需要任何资质，个人(商城除外)/小微企业都可以做，由于本人不擅长文字表达，每个类型只选择一个做分析，谅解。 1、工具类 工具类有很多可以做：题库、技术文档、教程、去水印等。目前最火爆的应该属于疫情相关类的工具，关于疫情数据类小程序不做分析，没资质也没权利，主要说疫情周边可运营的工具。头像口罩，代表小程序：头像加口罩、戴个口罩吧、戴上口罩(每日搜索量约等于2000)，可参考以下做法： [图片] 以下为近7日访问数据量 [图片] 盈利方式：流量主 延伸参考：如果仅做头像加口罩的话，那么疫情过后，这个小程序会直线下降，将无任何作用。如果开发者手里目前有类似小程序，可参考“头像加口罩”做法，逐渐去延伸头像周边功能，例： ①、头像加字：头像+数字、头像加V、头像加字、头像加圣诞帽、新年头像边框、头像加福、头像加明星等 ②、聊天背景图、壁纸：武汉加油、卡通、美女（不要漏点太多）、二次元、跑车、科技等 ③、趣味九宫格配图：类似朋友圈9张图，中间获取用户自己头像，周围8张图弄点能吸引用户的等 ④、文字秀：微信昵称下标、上标、个性昵称等 运营分析：如果参考以上4点做法，首先你的程序再疫情结束后，不至于直线下滑，最起码能留住一些用户（UI很重要） 个人建议：工具类的好处就是不需要去长时间盯着后台，建议有想法的开发者，可以入门5-10个左右工具类小程序（功能不要相同）。 推广方式：参考本文第四大板块内容 2、返利类 主流返利平台：淘宝、天猫、拼多多、京东、蘑菇街、唯品会、网易考拉，以下参考 [图片] 盈利方式：返利(主)+流量主(辅) [图片] 基础分析：每个人微信里都会有一个或多个微信群是给你们购物优惠券链接的，他们盈利方式主要是靠每个平台的返利，比如淘宝天猫的叫“阿里妈妈”、拼多多的叫“多多进宝”等 运营分析： ①、平台功能：提供所有优惠券、商品返利、代理入驻、提现（个人可做收款码、企业可对接微信支付到零钱） ②、招代理商、可以给代理商(兼职、宝妈)50%以上的返利 ③、除了商品优惠券之外，可以把返利分给一部分给到用户。首先，用户会花更少的钱买到商品；其次，用户买完东西还会赚点小钱，每个月可提现到微信零钱。这样用户会发生裂变，省钱+赚钱。 个人建议：开发者至少有一个类似的返利小程序，每个月只需运营一天，工作内容一是把用户的返利发给用户&代理商，二是自己去各大平台领取每个月的“工资” 推广方式：参考本文第四大板块内容 3、商城类(个人开发者可跳过) 商城类，本人运营的比较少，每天就10-20单左右，卖啥就不做广告了 盈利方式：差价 基础分析：如果自己手里有一些商品低价资源，可以做一个“综合服务商城类目”，然后去试着用广告主去推一下 运营分析： ①、平台功能：砍价、返利、拼团、回购、入驻、积分、抽奖、游戏营销 ②、广告主曝光&点击报价不要最低，也不要最高，理由就是最低的话，80%的钱会给你推到一些质量很差的微信用户，比如我。 ③、对接圈子，虽然圈子刚起步，不确定能不能做大，万一呢？ 个人建议：企业一定要有一个自己的商城，哪怕没人买。这种东西怎么说呢，就好比一个企业站，虽然没什么用，但是得放那儿，万一客户要看呢？ 推广方式：参考本文第四大板块内容 4、游戏类（非小游戏） 答题、成语、找茬等类似运营的比较多，可自行搜索，不要认为这是游戏，开发者就望而却步，在线教育类目是可以通过的，这个开发者很多都不知道。以下可参考： [图片] 盈利方式：流量主 基础分析：基本所有的模式都是闯关类型，这种类型的小程序，基本都是用户消磨时间用 运营分析：关卡尽量多，入门、初级、中级、高级，高级模式可以做类比循环，形成无限关卡模式，闯关奖励机制，签到机制等。这种类型的小程序比较方便运营，裂变起来也快。 个人建议：裂变模式一定要有，虽然微信会严格把控这方面功能，但是开发者可以做一些技巧，不要让用户强制或者主动去触发，这样微信对开发者还是很友好的。 推广方式：参考本文第四大板块内容 二、小程序开发 有实力的开发者，自己开发，云开发很快，会前端就可以了，没实力的去正规平台买源码，论坛源码也很多，有部分论坛还是嵌入了比特币勒索，自己做好防护。个人建议：开发者能开发尽量自己开发，后期迭代方便，不要像我一样，50多个小程序80%是买现成去运营的。反正各有各的好处，开发者可自行决定，运营者可选择直接购买源码直接上线运营，前提是自己看好功能是不是和自己要的一样。有些SAAS平台的开发者实力还是可以的，支持定制功能。此处不做广告，自行搜索或者询问朋友。 三、广告位位置及利润 开发者的每个页面广告位一定要分开！一定要分开！一定要分开！这样做的目的是为了分析每个广告位的利润，好去做调整，把收益最大化。 失败案例举例：小程序的主页、个人中心页用同一个banner广告位，这样做出来一点好处都没有，后台只能看到banner收益是多少，看不到是哪个页面收益。极端情况，收益全部再首页，个人中心页没有广告收益，这种情况开发者是不知道的，如果把广告位分开，这种情况可以去优化个人页面，或者主页面换成视频banner。广告位分析页面：流量主--数据统计--广告数据--广告指标明细--细分数据 [图片] [图片] 1、很多人表示，疫情期间流量主收入下滑。这个原因不是因为微信调整流量主收益，根本问题是自己的用户质量。举个例子，当你开通流量主之后，你的用户还是这1000个，假如你第一天收益为100，你很开心，1000用户就能赚100，你第二天就放弃推广了，这样的话，你的用户质量是会逐渐下滑，微信方完全可以认定为你这1000人都是自己的号，去刷广告费的。长此以往下去，你的流量主利润会无限趋向于0。举个栗子： [图片] 2、广告位位置一定要合理好看，但是不代表“流氓”，比如全明星代言的某游戏“元宝无限收一刀999”点哪儿哪充值。开发者需要注意的是小程序的质量，需要用户在每个页面停留的时长最起码30秒，这样一个完整的视频广告才能曝光完。 3、banner广告收益是按有效点击计算的。很多人好几千曝光，但是点击只有几个、十几个，这种情况需要不断去优化接入的场景/位置，提高用户点击意愿。个人技巧：banner广告位尽量不要太多，1-2个就可以。尽量多放几个视频广告位，这样曝光也有收益。格子广告没试过，用过都说不好~ 4、激励广告作为流量主最高收益是有一定道理的，用户为了获取某些奖励是必须观看完整的，所以给开发者建议：用户如果可以获得小程序内某些奖励，可以适当多放一些激励广告位。 5、所有的广告位都是根据用户年龄、爱好等参数去调取相应的广告，开发者不需要去考虑 6、广告收益个人认为：激励》视频》插屏》前贴》banner》格子(格子没试过，暂放倒数第一) 四、小程序推广 尽量做成年人主打的小程序，有些开发者觉得好玩儿，做一些儿童益智类的小程序，你是认为儿童有手机，还是认为家长愿意让孩子玩儿手机呢？这个很不解。没有鄙视的意思，也许是情怀吧~~毕竟我做小程序比较俗，就是为了赚钱。 主流推广方式：公众号引流、截流，由于涉及一些不合常规的内容，本文只说常规操作，剩下的自己领悟，或者可以联系我~ 首先小程序的名字至关重要，一个好的名字可以带来无限的流量，再加上裂变功能（邪恶的微笑）。起名字的时候可以用到的工具：搜索小程序-微信指数，查询关键字，尽量找稳定再1000万以上的搜索量，从关键字中摸索自己的小程序名字。这样用户搜索到你的小程序几率会很高~ 1、工具类核心玩儿法（适用于所有小程序推广）：文章引流，截取关键字，火爆主题，比如2019年12月19日庆余年全集泄露、2020年疫情(不要发疫情数据内容，要发一些正能量的有内容文章去引流），我阅读过的文章最低的阅读量8000左右，最高的10万+，据说有好几百万的阅读量。如果你的文章写的好，结尾放一个小广告：为防止疫情蔓延，请给您的头像带上口罩~，啪，一个卡片小程序（或二维码），流量自己想~ 推广对象：18-30岁 2、返利类核心玩儿法： ①、可以参考工具类玩儿法 ②、各大微信群、QQ群，去推广，招代理等方式，或者去买一些基础流量，进行裂变，实际运营看下效果，好继续针对用户群体去推广，建立自己的群体系，群内发商品返利链接。微信好友没人？给你举个例子，我这篇文章发完，如果加个我的二维码，最起码能有100人加我，不是我文章写的有多好，是你永远不知道用户有什么样的目的和需求~ 推广对象：18-60岁 3、商城类核心玩儿法 ①、可参考返利类核心玩儿法，拥有自己的客户群体系，发一些自己的商品还是可以的，一定要带分销体系，你懂得~(最高3级，再高就是传销了) ②、广告主、目前效益个人感觉不明显，每次花1000块钱做广告，利润基本没有，和发广告的钱持平，而且用户留存也不是很高，可能是我的商品比较单一等各方面因素吧，不过赚流量还是不错的。 推广对象：18-30岁(以我的商城为例，还需看商城出售的内容) 4、游戏类核心玩儿法（非小游戏） ①、一个好的名字就够了。举例：精选商品橱窗（腾讯官方），微橱窗（我朋友的）。不得不说，这波流量很高，遗憾的是，他不是火爆的游戏类小程序~ [图片] ②、参考工具类玩儿法，文章引流截流 推广对象：18-40岁 五、小程序矩阵 矩阵一定要有，矩阵一定要有，矩阵一定要有，防截流，底配10个小程序。不是纯矩阵，是微信开发规定，每个小程序可以跳转10个小程序，开发者可以利用这个功能去添加自己的矩阵来获取更多的流量收益，保证自己的用户在自己的矩阵圈活动。 [图片] 写这篇文章主要是给大家传授经验，希望小白能学到点东西，入门后的朋友可领悟到更多运营方法，江湖之大，附月账单有缘再见 [图片]

在小程序中，常常有些数据需要在几个页面或组件中共享。对于这样的数据，在 web 开发中，有些朋友使用过 redux 、 vuex 之类的 状态管理 框架。在小程序开发中，也有不少朋友喜欢用 MobX ，说明这类框架在实际开发中非常实用。 小程序团队近期也开源了 MobX 的辅助模块，使用 MobX 也更加方便。那么，在这篇文章中就来介绍一下 MobX 在小程序中的一个简单用例！ 在小程序中引入 MobX 在小程序项目中，可以通过 npm 的方式引入 MobX 。如果你还没有在小程序中使用过 npm ，那先在小程序目录中执行命令： [代码]npm init -y [代码] 引入 MobX ： [代码]npm install --save mobx-miniprogram mobx-miniprogram-bindings [代码] （这里用到了 mobx-miniprogram-bindings 模块，模块说明在这里： https://developers.weixin.qq.com/miniprogram/dev/extended/functional/mobx.html 。） npm 命令执行完后，记得在开发者工具的项目中点一下菜单栏中的 [代码]工具[代码] - [代码]构建 npm[代码] 。 MobX 有什么用呢？ 试想这样一个场景：制作一个天气预报资讯小程序，首页是列表，点击列表中的项目可以进入到详情页。 首页如下： [图片] 详情页如下： [图片] 每次进入首页时，需要使用 [代码]wx.request[代码] 获取天气列表数据，之后将数据使用 setData 应用到界面上。进入详情页之后，再次获取指定日期的天气详情数据，展示在详情页中。 这样做的坏处是，进入了详情页之后需要再次通过网络获取一次数据，等待网络返回后才能将数据展示出来。 事实上，可以在首页获取天气列表数据时，就一并将所有的天气详情数据一同获取回来，存放在一个 数据仓库 中，需要的时候从仓库中取出来就可以了。这样，只需要进入首页时获取一次网络数据就可以了。 MobX 可以帮助我们很方便地建立数据仓库。接下来就讲解一下具体怎么建立和使用 MobX 数据仓库。 建立数据仓库 数据仓库通常专门写在一个独立的 js 文件中。 [代码]import { observable, action } from 'mobx-miniprogram' // 数据仓库 export const store = observable({ list: [], // 天气数据（包含列表和详情） // 设置天气列表，从网络上获取到数据之后调用 setList: action(function (list) { this.list = list }), }) [代码] 在上面数据仓库中，包含有数据 [代码]list[代码] （即天气数据），还包括了一个名为 [代码]setList[代码] 的 action ，用于更改数据仓库中的数据。 在首页中使用数据仓库 如果需要在页面中使用数据仓库里的数据，需要调用 [代码]createStoreBindings[代码] 来将仓库中的数据绑定到页面数据中，然后就可以在页面中直接使用仓库数据了。 [代码]import { createStoreBindings } from 'mobx-miniprogram-bindings' import { store } from './store' Page({ onLoad() { // 绑定 MobX store this.storeBindings = createStoreBindings(this, { store, // 需要绑定的数据仓库 fields: ['list'], // 将 this.data.list 绑定为仓库中的 list ，即天气数据 actions: ['setList'], // 将 this.setList 绑定为仓库中的 setList action }) // 从服务器端读取数据 wx.showLoading() wx.request({ // 请求网络数据 // ... success: (data) => { wx.hideLoading() // 调用 setList action ，将数据写入 store this.setList(data) } }) }, onUnload() { // 解绑 this.storeBindings.destroyStoreBindings() }, }) [代码] 这样，可以在 wxml 中直接使用 list ： [代码]<view class="item" wx:for="{{list}}" wx:key="date" data-index="{{index}}"> <!-- 这里可以使用 list 中的数据了！ --> <view class="title">{{item.date}} {{item.summary}}</view> <view class="abstract">{{item.temperature}}</view> </view> [代码] 在详情页中使用数据仓库 在详情页中，同样可以使用 [代码]createStoreBindings[代码] 来将仓库中的数据绑定到页面数据中： [代码]import { createStoreBindings } from 'mobx-miniprogram-bindings' import { store } from './store' Page({ onLoad(args) { // 绑定 MobX store this.storeBindings = createStoreBindings(this, { store, // 需要绑定的数据仓库 fields: ['list'], // 将 this.data.list 绑定为仓库中的 list ，即天气数据 }) // 页面参数 `index` 表示要展示哪一条天气详情数据，将它用 setData 设置到界面上 this.setData({ index: args.index }) }, onUnload() { // 解绑 this.storeBindings.destroyStoreBindings() }, }) [代码] 这样，这个页面 wxml 中也可以直接使用 list ： [代码]<view class="title">{{list[index].date}}</view> <view class="content">温度 {{list[index].temperature}}</view> <view class="content">天气 {{list[index].weather}}</view> <view class="content">空气质量 {{list[index].airQuality}}</view> <view class="content">{{list[index].details}}</view> [代码] 完整示例 完整例子可以在这个代码片段中体验： https://developers.weixin.qq.com/s/YhfvpxmN7HcV 这个就是 MobX 在小程序中最基础的玩法了。相关的 npm 模块文档可参考 mobx-miniprogram-bindings 和 mobx-miniprogram 。 MobX 在实际使用时还有很多好的实践经验，感兴趣的话，可以阅读一些其他相关的文章。

[图片] 上周参加了“上海微信开放社区”的沙龙活动，看到现场大家回答问题都很踊跃，回去自己也思考了下，先看下10月24日（1024如此重要的节日发布。。。emmm。。。）官方公布的内容： 《社区突出贡献者激励计划》。 首先有点必须值得肯定，官方正在努力做出改变，并且把平台建设的更好，基于“人人都是产品经理”的思想，我这里也给到一些整理后的建议。 免责申明：由于可以拿到的关键数据有限，作为一个数据控，略感无奈，很多时候做决定或给建议只能通过个人主观认知来判断，但本人会尽力秉承理性和客观来给出一些看法。 1、奖励机制 1.1、“全周期”评价，积分系统 积分是一个累加的概念，它表明你对这个平台付出的总额。个人觉得这个是重要的奖励机制，为什么呢？ 打个比方，现在的奖励机制是按照月度来的，展示的是单月的贡献，那么就会有个问题： A同学：5月份非常积极，为平台贡献了1000，获得月度突出贡献奖，但后面就再没有贡献了，一年贡献总额为1000 B同学：每个月都有贡献，每月100点，坚持了一年，那么总额就是1200 可以看到，其实是B同学对整个平台总体贡献大，但按照现在的机制只有A同学能获得奖励~ 这样或多或少都会打击B同学这类贡献者，他们或许因为工作满或者没有那么多连续的大量时间，平台就忽略他们的贡献~~~ 结论：建立全周期评价体系，加入积分机制、年度，季度贡献者的评选。 1.2、贡献者评价的一些基础数据 用户点赞 用户收藏 评论 浏览次数&分享 投币：类型于B站的投币机制，可以每个月给用户5个币，投完为止，限量才能突出用户选择的谨慎性和投币对象的价值。 投诉：这类反馈要更加谨慎和细致 关于是否需要赞对应的“踩” ？ 回答问题类：一定需要，因为有这种情况，一个回答能解决当前问题，但可能引起“次生灾害”导致其他的问题，但由于先前点赞数过高，一直排名靠前，可能出现误导~ 文章类：不建议有“踩”，因为写文章的成本较高，更多的是提供一个全流程解决方案，而非简单的对错判定，当然也不需要所有人满意~ 结论：这里 每个数据的权重 是最为关键的，官方到时候是否公布，也是要细致考虑，个人认为：投币 = 投诉 > 收藏 > 点赞 = 评论 > 浏览次数 1.3、最终奖励 建立周边商城，利用获得的积分或者虚拟货币兑换各类物品（开放社区都是实名制的，不用担心刷子薅羊毛） 1.3.1、虚拟奖励 特有头像、头环 专属徽章，如“九月社区突出贡献个人开发者” 加快小程序审核时间 发表的文章/回答的问题 能优先被“置顶、推荐、加精”等 云函数、云服务等器免费使用额度 兑换一些腾讯系的虚拟物品 个人小程序开发，给予更大的权限，比如个人小程序可以使用web-view 优先参与“内测”的机会，观看付费教学视频等~ 核心：可以在回答问题和发文章一眼看出此类“专业用户”，要有一定区分度 1.3.2、实物奖励 特色周边，比如企鹅毛绒玩具，手机壳等 徽章、勋章 里程碑奖品：类似B站，10W粉丝会给一个银色奖杯牌，100w会给一个金色的 可以优先参加一些分享会或者现场培训 google的做法，参与互动就有奖励，如图： [图片] 实物奖励核心：一定要突出实用性并且可反复展示，人一定是会有虚荣心的，但这不一定是负面的，而可能成为持续性的鼓励，比如每当你看到桌面上的“奖杯”。。。想起。。。~~~ 结论：专家级用户一定是少数，但他们反而是最重要的，他们提供了正确率和解决问题效率！奖励的核心是让真正的贡献者获得“荣耀感”，建立“忠诚度”，让他们能为建立强大的微信开放社区持续性投入。 2、社区交互和界面优化 2.1、页面交互优化 2.1.1、将“我的关注”修改成“我的” [图片] “我的”我的模块可以加入三个标签： 我的提问（默认第一个显示），根据观察，这个平台上用户更关心自己的问题是否得到解决，围绕“我的问题”是第一需求。 我的关注：保持不变 我的状态/积分：包括评论，点赞等信息，现在是最上面，且单独打开窗口，不太友好，切换起来也不方便~ 建议去掉头部的“全部、文章、问答”这一栏，改成“推荐，我的，疑问/BUG”，将文章和问答加入到筛选Label中。 2.1.2、搜索和筛选排序优化 [图片] 添加其他几个筛选选项，比如点赞数最高的回答，收藏数最高的文章等等 2.1.3、个人提醒小优化 比如这种情况，有十几个未读信息，但是点击进去后，需要一个个点开，才能去掉红色的“未读状态”，逼死强迫症啊~ 建议：点进去，就直接把16个未读状态归零，但是可以在“详情页面”中看到标记~ [图片] 2.1.4 小程序核心 小程序发布文章肯定不方便，个人觉得更多的是简单回答问题和评论，所以小程序端的核心应该是“资讯的接收和BUG修复的提醒”，这里小程序的订阅功能会变得更加强大，比如，某某BUG官方已修复的订阅推送~~~ 2.2、奖励栏优化+ 荣誉墙页面 [图片] 个人贡献者只有10个能入选太少了！！！ 建议增加至20/50个奖励名额，让更多的人可以上榜，一定不会是件坏事，这里可以设置前1-3名特殊的ICON，前4-10名一个标签，首页隐藏其他11-50名，但是有一个荣誉墙页面，里面可以查到以往所有的“优秀贡献者”~~~ 荣誉墙未来可以添加其他排行榜，作为小程序开发者的一种荣耀~ 2.3、BUG的整理、追踪和反馈 从目前看来用户最关心的是： BUG的处理方法和是否解决！！！！！！ 同类问题的归类合并，避免反复提问，消耗回答者精力 BUG解决追踪和及时反馈，这里建议添加“关注或者订阅”功能，解决后能及时反馈给用户。（这里对应小程序的优化） [图片] 顶部建议添加 “疑问/BUG” 选项,为用户提供的处理方法（包括绕过BUG或者hack的方法）和分类。 侧面的“已知问题与需求反馈”，个人觉得很棒，没有问题~ [图片] 3、提问模板+降低沟通成本 3.1、增加提供代码片段的Tips 我之前提了一个问题，就遇到一个情况，官方回答需要我提供 代码片段，当时是一脸懵逼，好在看完教程，知道如何使用了，从此对这个功能喜欢的不得了。 [图片] 个人认为官方给到的代码片段对于用户反馈和解决问题非常有用，所以在官方模板中建议加上代码片段使用方法的tips 小问号ICON~ 3.2、引导/教会 提问者 很多时候“专家用户”想回答一些提问者的问题，但是发现没看明白问题的意思或者误解了问题的内容，这里我认为官方有必要引导提问者更好的描述问题。 一个好的提问者，会让回答者更加省心，所以官方如果能提供一个提问的demo，必然大大降低沟通成本，减少用户抱怨。 [图片] 4、“微信学院”的传道受业解惑 4.1、官方视频指导 首先，需要肯定一点，微信学院这个项目感觉很棒，可以帮助到很多小程序的参与者。 说下问题，现在的界面部分略感凌乱，不同岗位的人进来找于自己相关的教程比较吃力，建议添加分类功能Tab选项~ [图片] 现有的行业分类可以保持（根据你们官方自己的计划来） 功能性分类：产品，开发，运营来区分现在不同种类的视频，因为比如PM过来，他们完全对技术这块视频不敢兴趣，目前就会产生干扰+阅读成本。 建立专辑和连续性：官方的教学视频做的更加“线性”，比如一期二期这种，有规律且连续，类似于专辑/系列视频，这样用户学起来更加持续且扎实，官方教学的效果也更好 增加一些实战类视频（包括技术和运营），目前的视频更多讲的是概念，有点虚，实战较少，比如如何通过云函数生成一个二维码，其实很多人都在问这类问题，这个可以帮助中小企业减低开发成本且更好的社交裂变，对于平台方是双赢的~ 4.2、“文章和问答”的思考 个人觉得文章是传道受业，问答更多是解惑，哪个更重要呢？ 短期肯定是问答，长期的话文章的价值更大，文章凸显的是持续性的知识输出，给开发者提供一个完整的学习路径，比起做到哪里遇到问题再问来说，文章的引导意义更加彻底。 个人觉得官方未来可以考虑鼓励更多的用户去写一些“项目实战和技术贴”，做持续性的内容输出和知识科普~ 5、服务商/插件 5.1、插件接入标准模板 现阶段第三方开发的插件，接入方式和教程参差不齐，有的甚至需要二次开发，但是往往说明不清，给使用者造成很大的困惑。反正本人之前想用一个插件，搜了下各家文档写得各种风骚外加“脑补”，完全被整懵逼~ [图片] 建议官方提供一个标准化的接入模板或者教程，最好带示例，而不是开发者自己想着填，这样可以帮助使用者更方便的接入和使用。 5.2、收不收费的问题 5.2.1、收费 提供“人工服务”的一定要收费，以保持服务的品质 持续性的支持，偏向于收费 需要占用其他资源的，比如地图，服务器，AI算力等 收费的初衷一定是为了提供更好的服务，但希望官方提供一个标准，避免乱定价，或者一锤子买卖坑人的问题。 5.2.2、免费 一次性使用的组件类，不需要其他资源支持，纯粹的代码提供 开源项目 插件，这个有争议，但是插件可能很多情况下，没有“售后”，恐怕出现收费后，撒手不管的情况，容易造成纠纷~ 5.2.3、微信官方支持/支付费用 那些长期维护的项目，或者优秀的开源框架/插件，为了鼓励开发者坚持优化和改进，官方可以提供一笔基金支持日常维护迭代，类似 apache基金会、Nginx社区、React/VUE项目这种，由机构/大公司/基金会维持的项目~ 5.3、建立评价体系 简单的评分和赞踩系统 提供试用/DEMO，上来试用，可以避免买了后发现和自己的需求不匹配的问题 退货/钱功能 谁都不想上来就做小白鼠嘛，花了钱还踩坑~~~ 所以必须建立一个有效的评价体系，也能督促和规范服务商/插件开发者。 以上就是本人的一些拙见，写的比较仓促，如有内容错误和阅读疑惑欢迎各位同行留言评论，觉得不错也可点个赞，让更多人看见，感谢 ^_^ ~

本月份的组件分享，事件效果由 wxs事件完成，注释在代码片段里有。 按钮可拖动，子菜单上没有点击事件，是根据touchend位置来判断点击的谁。有bug欢迎反馈 代码片段：https://developers.weixin.qq.com/s/9BNYnhmG7tcl 社区这会儿效果图gif上传不了。。不是我的错 图标iconfont下的，没版权问题吧。。

前言 10月12日夜晚社区发了公告小程序模板消息能力调整通知，正式发布了 一次性订阅消息 这一能力，所以第一时间进行了体验。 本文主要是补充一下官方未提供的使用方法，和使用中与模板消息用法的不同。 文档地址 https://developers.weixin.qq.com/miniprogram/dev/framework/open-ability/subscribe-message.html 使用方法 [代码]wx.requestSubscribeMessage({ tmplIds: ["模板id1","模板id2"], success: function (res) { //成功 }, fail(err) { //失败 console.error(err); } }) [代码] 第一个坑 如果不勾选红色方框内的内容，用户每次触发订阅消息功能都会弹出授权窗口，如果用户勾选了则不会出现弹窗。 [图片] 第二个坑 目前开发者工具（v1.02.191012）不支持调试，只能通过真机调试。 [图片] 第三个坑 微信不会为开发者保存订阅次数，需要自己在后台记录用户触发的次数。 超过次数调用接口下发订阅消息会返回失败。 [图片] 第四个坑 发送模板格式和原来的模板消息格式不一致，特别是data内的内容，订阅消息的字段key是和数据类型有关，value的参数需要严格按照设置的类型提交，具体使用参考后台的模板详情。 模板消息的格式： [代码]"data": { "keyword1": { "value": "内容", "color": "#000" }, "keyword2": { "value": "内容", "color": "#000" } } [代码] 订阅消息的格式： [代码]"data": { "thing1": { "value": "内容" }, "number2": { "value": 20 } [代码] 第五个坑 订阅消息申请模板的时候，需要选择所属类目，而且只能是自己小程序相关类目，模板消息是不需要选择对应类目的。 如果删除小程序类目，则会把订阅消息模板一起删除，需谨慎操作。 [图片] 第六个坑 长期订阅消息只针对特定行业开放，所以普通开发者并无法使用。 结束 暂时就先总结这些，有其它坑再补充。

经过一段时间对微信小程序的研发后 总结出以下三种授权登录的方式，我给他们命名为‘一次性授权’‘永久授权’‘不授权’ 1.一次性授权 常规写法，需要获取用户公开信息（头像，昵称等）时，判断调取授权登录接口，但是此方法如果不经处理的话 用户如果拒绝授权或者删除该微信小程序后 需要重新调取并获取用户公开信息（头像，昵称等），此方法用户体验较差，不建议使用； 2.永久授权 在不必要使用用户公开信息（头像，昵称等）时，不调取授权登录接口，只有在必要的时候再去判断调取授权登录接口并把获取到的用户公开信息存入数据库，这样在每次登录时直接先运行指定函数从数据库索取需要的用户公开信息（头像，昵称等）即可，此方法在删除小程序后不用再次去授权登录（因为在用户第一次授权登录时已经把用户的公开信息存入数据库了以后直接向数据库索取即可），建议使用； 3.不授权 不需要授权登录获取用户公开信息（头像，昵称等），使用wx.login获取用户code并传入后台，后台可以通过用户的code值向微信要一个值（具体需要问后台，我只是个小前端，后台的东西不是很懂，只是知道一些逻辑而且也已经成功实现）然后通过这个用code换取的值就可以识别到指定用户，如果需要的话，前端要显示的头像、昵称等这些信息可以使用自定义可编辑的功能，当然，也可以通过<open-data type=“userAvatarUrl”></open-data><open-data type=“userNickName”></open-data>小程序提供的这个组件显示用户的头像及昵称（不过这个组件只有显示功能），用户如果想直接使用自己的头像昵称，也可以自行授权（比如添加个引导按钮什么之类的），建议使用； [图片][图片] 文中使用的微信自带接口、组件及函数： <open-data type=“userAvatarUrl”></open-data> <open-data type=“userNickName”></open-data> wx.login({ success(res){ console.log(res.code) } }) 微信授权登录 以上三种方式可以灵活运用，也可以把需要的结合到一起，并不冲突； 当然，大佬很多，我也只是个小前端而已，第一次发表技术方面的帖子，希望互相学习，互相指导，如有说的不对的地方还望大佬们及时指出！！！ 谢谢

[图片] 扫小程序码立即报名 [图片] 为了更好的提供服务，我们邀请你参与以下用户调查，希望得到你的宝贵意见和真实想法。 点击立即参与，成功提交即有机会优先获得本次活动门票哦～

自媒体布局电商业务，应该怎么做？「菜菜美食日记」（以下简称「菜菜」）可以回答你。 作为 2014 年开始自媒体创业的元老级选手，如今的菜菜已经不仅仅是一个超过 160 万粉丝的公众号，还拥有月均销售额近千万的「一口幸福」有赞店铺。一路走来积攒的经验，菜菜今天全盘分享。 [图片] 一、谨慎尝试电商收获惊喜，定制+跑产地促成交 2014 年，5 个对美食怀揣热爱且拥有文案、制图等专业能力的年轻人聚在一起，创建了微信公众号「菜菜美食日记」。2016年，菜菜开始团队化运营。到 2017 年，菜菜的粉丝数突破百万，眼看着社交电商和公众号变现的风潮越来越旺，菜菜决定抓住红利期尝试电商转型，但他们的起点非常谨慎： 菜菜先是提前在粉丝微信群中做了一个调查，询问粉丝能不能接受他们卖货。结果显示，大部分粉丝愿意为他们推荐的美食买单，之前优质内容所打下的基础，让粉丝相信菜菜的眼光。 接着，考虑到业内口碑和稳定性，菜菜选择了有赞提供技术支持，成立了店铺「一口幸福」。 最后，他们选择了一家口碑较佳、和自己调性相符的供货商，并把第一份商品定为非生鲜类、运输风险较小的绿豆糕。出乎意料地，绿豆糕推文的阅读量竟超过了平时最火的菜谱推文，销量在当时高达几百份。如此，菜菜更加坚定了电商转型之路。 [图片] 从 2017 年的第一个商品，到现在近千个 SKU，都是菜菜通过有赞分销市场等方式不断寻找的。为了提升商品销量，菜菜还利用「菜菜」这个已具有一定流量的 IP 创建了 2 款栏目： 栏目一：菜菜跑团。 水果和食材是用户的刚需品，但因为不能提前见到实物，用户会对商品质量、口感保持疑虑。为此，菜菜成立了「菜菜跑团」深入原产地帮粉丝「探地」，通过亲身考察确保食物质量，并附上菜菜员工或栏目名卡片在原产地的照片，促使粉丝放心购买。近期菜菜跑团栏目中售卖的广东荔枝、山东樱桃都纷纷爆单。 栏目二：菜菜定制。 考虑到将 IP 更大化地利用，菜菜成立了「菜菜定制」栏目，用品牌附加值和性价比更高的商品吸引粉丝到店购买。比如去年年底定制的富平柿饼，一天就产生了近 30 万销售额。 [图片] 二、开通小程序，引流到店效果惊人 菜菜的公众号中每天都会有商品推荐文章，而这些文章中的商品卡片以及最后的店铺引流全部都链接到了有赞小程序店铺。这么做主要有 3 个好处： 首先，菜菜作为订阅号，不能在文章中添加超链接，但小程序商品卡片可以直接插入文中。这样一来，用户在看到心动商品时，能够直接点击进入商品购买页面，一篇文章可以有多个引流触发点，可抓住每一个用户产生购买欲的时刻。 [图片] 其次，小程序入口更多。微信小程序有包括我的小程序、扫码、发现、附近小程序等十几个不同的入口，方便用户进店。比如菜菜的粉丝如果想要进入「一口幸福」小程序店铺，直接搜索或在聊天界面下拉中找到「一口幸福」的小程序即可。 [图片] 最后，小程序更利于与用户产生长久的连接。菜菜还设置了小程序收藏有礼³，让用户将菜菜的小程序添加到「我的小程序」中，时不时就能进店看看。至今已累积 7 千多人添加了「一口幸福」小程序到常驻入口，每日进店的顾客稳定在 1 万人左右。 三、店铺活动+社群运营，销量黏性两不误 除了公众号文章每日推送商品外，菜菜还给有赞小程序店铺设置了一系列活动： 1、进店有礼：针对第一次进店的新人，菜菜会发放 4 张不同面额的新人优惠券，针对老客，则会在 618、母亲节、吃货节等特殊节点发放进店优惠券。进店有礼⁴使许多老客养成进店习惯并带动新客进店，促进店铺的活跃度； 2、2人拼团：菜菜把每周一、周四定为「菜菜拼团日」，每次上新 3 到 5 款应季、常用、客单价较低的食品或日用品，比如龟苓膏、驱蚊水等，发起2人拼团活动。拼团吸引顾客进入商城，2 人的设置让成团简单、快速，效果较好的商品在推文当天可以创造上千的销量。 [图片] 另外，像秒杀、满减/送等有赞微商城营销插件，菜菜也会经常使用，促进粉丝活跃度。 除商城活动外，菜菜还会让粉丝加入各类主题社群，例如瘦身群，品茶群等，持续和用户互动，并经常在群内调查用户对商品的意见以及对新品的期望，不但增加了粉丝的参与感，也增强了粉丝黏性，为同品类商品的推广积累了核心用户群。据悉，菜菜的月平均复购率已接近 70%。 如今，菜菜越来越重视商品的选择和有赞店铺的经营，因为只有拥有了更好的产品和更有竞争力的活动，才能获取更多的顾客，从而产生更好的销量。 [图片] 「敲黑板啦」 担心有些小伙伴没有耐心看完整篇文章，但是又迫切的希望流量变现。所以特意整理了「菜菜美食日记」小程序每日客流近1万的绝招如下，记得拿笔记录下来哟~ 1、前期调研，了解粉丝的意愿，以及选品方向 2、选择稳定的开店系统，当然推荐自家有赞啦~微商城+小程序，双管齐下 3、如果前期没有自己的供应链，可以先从有赞分销市场选品 4、优质内容的定时更新，不要单纯卖货，结合有趣的内容，效果更棒哟 5、利用有赞丰富的营销工具创建一系列的活动，提升拓客、复购 6、社群运营，提升粉丝黏性

前言 在开发小程序的过程中，很多时候会需要使用富文本内容，然而现有的方案都有着或多或少的缺陷，如何更好的显示富文本将是一个值得继续探索的问题。 [图片] 现有方案 WxParse [代码]WxParse[代码] 作为一个应用最为应用最广泛的富文本插件，在很多时候是大家的首选，但其也明显的存在许多问题。 格式不正确时标签会被原样显示 很多人可能都见到过这种情况，当标签里的内容出现格式上的错误（如冒号不匹配等），在[代码]WxParse[代码]中都会被认为是文本内容而原样输出，例如：[代码]<span style="font-family:"宋体"">Hello World!</span> [代码] 这是由于[代码]WxParse[代码]的解析脚本中，是通过正则匹配的方式进行解析，一旦格式不正确，就将导致无法匹配而被直接认为是文本[代码]//WxParse的匹配模式 var startTag = /^<([-A-Za-z0-9_]+)((?:\s+[a-zA-Z_:][-a-zA-Z0-9_:.]*(?:\s*=\s*(?:(?:"[^"]*")|(?:'[^']*')|[^>\s]+))?)*)\s*(\/?)>/, endTag = /^<\/([-A-Za-z0-9_]+)[^>]*>/, attr = /([a-zA-Z_:][-a-zA-Z0-9_:.]*)(?:\s*=\s*(?:(?:"((?:\\.|[^"])*)")|(?:'((?:\\.|[^'])*)')|([^>\s]+)))?/g; [代码] 然而，[代码]html[代码] 对于格式的要求并不严格，一些诸如冒号不匹配之类的问题是可以被浏览器接受的，因此需要在解析脚本的层面上提高容错性。 超过限定层数时无法显示 这也是一个让许多人十分苦恼的问题，[代码]WxParse[代码] 通过 [代码]template[代码] 迭代的方式进行显示，当节点的层数大于设定的 [代码]template[代码] 数时就会无法显示，自行增加过多的层数又会大大增加空间大小，因此对于 [代码]wxml[代码] 的渲染方式也需要改进。 对于表格、列表等复杂内容支持性差 [代码]WxParse[代码] 对于 [代码]table[代码]、[代码]ol[代码]、[代码]ul[代码] 等支持性较差，类似于表格单元格合并，有序列表，多层列表等都无法渲染 rich-text [代码]rich-text[代码] 组件作为官方的富文本组件，也是很多人选择的方案，但也存在着一些不足之处 一些常用标签不支持 [代码]rich-text[代码] 支持的标签较少，一些常用的标签（比如 [代码]section[代码]）等都不支持，导致其很难直接用于显示富文本内容 ps：最新的 2.7.1 基础库已经增加支持了许多语义化标签，但还是要考虑低版本兼容问题 不能实现图片和链接的点击 [代码]rich-text[代码] 组件中会屏蔽所有结点事件，这导致无法实现图片点击预览，链接点击效果等操作，较影响体验 不支持音视频 音频和视频作为富文本的重要内容，在 [代码]rich-text[代码] 中却不被支持，这也严重影响了使用体验 共同问题 不支持解析 [代码]style[代码] 标签 现有的方案中都不支持对 [代码]style[代码] 标签中的内容进行解析和匹配，这将导致一些标签样式的不正确 [图片] 方案构建 因此要解决上述问题，就得构建一个新的方案来实现 渲染方式 对于该节点下没有图片、视频、链接等的，直接使用 [代码]rich-text[代码] 显示（可以减少标签数，提高渲染效果），否则则继续进行深入迭代，例如： [图片] 对于迭代的方式，有以下两种方案： 方案一 像 [代码]WxParse[代码] 那样通过 [代码]template[代码] 进行迭代，对于小于 20 层的内容，通过 [代码]template[代码] 迭代的方式进行显示，超过 20 层时，用 [代码]rich-text[代码] 组件兜底，避免无法显示，这也是一开始采用的方案[代码]<!--超过20层直接使用rich-text--> <template name='rich-text-floor20'> <block wx:for='{{nodes}}' wx:key> <rich-text nodes="{{item}}" /> </block> </template> [代码] 方案二 添加一个辅助组件 [代码]trees[代码]，通过组件递归的方式显示，该方式实现了没有层数的限制，且避免了多个重复性的 [代码]template[代码] 占用空间，也是最终采取的方案[代码]<!--继续递归--> <trees wx:else id="node" class="{{item.name}}" style="{{item.attrs.style}}" nodes="{{item.children}}" controls="{{controls}}" /> [代码] 解析脚本 从 [代码]htmlparser2[代码] 包进行改写，其通过状态机的方式取代了正则匹配，有效的解决了容错性问题，且大大提升了解析效率 [代码]//不同状态各通过一个函数进行判断和状态跳转 for (; this._index < this._buffer.length; this._index++) this[this._state](this._buffer[this._index]); [代码] 兼容 [代码]rich-text[代码] 为了解析结果能同时在 [代码]rich-text[代码] 组件上显示，需要对一些 [代码]rich-text[代码]不支持的组件进行转换[代码]//以u标签为例 case 'u': name = 'span'; attrs.style = 'text-decoration:underline;' + attrs.style; break; [代码] 适配渲染需要 在渲染过程中，需要对节点下含有图片、视频、链接等不能由 [代码]rich-text[代码]直接显示的节点继续迭代，否则直接使用 [代码]rich-text[代码] 组件显示；因此需要在解析过程中进行标记，遇到 [代码]img[代码]、[代码]video[代码]、[代码]a[代码] 等标签时，对其所有上级节点设置一个 [代码]continue[代码] 属性用于区分[代码]case 'a': attrs.style = 'color:#366092;display:inline;word-break:break-all;overflow:auto;' + attrs.style; element.continue = true; //冒泡：对上级节点设置continue属性 this._bubbling(); break; [代码] 处理style标签 解析方式 方案一 正则匹配[代码]var classes = style.match(/[^\{\}]+?\{([^\{\}]*?({[\s\S]*?})*)*?\}/g); [代码] 缺陷： 当 [代码]style[代码] 字符串较长时，可能出现栈溢出的问题 对于一些复杂的情况，可能出现匹配失败的问题 方案二 状态机的方式，类似于 [代码]html[代码] 字符串的处理方式，对于 [代码]css[代码] 的规则进行了调整和适配，也是目前采取的方案 匹配方式 方案一 将 [代码]style[代码] 标签解析为一个形如 [代码]{key:content}[代码] 的结构体，对于每个标签，通过访问结构体的相应属性即可知晓是否匹配成功[代码]if (this._style[name]) attrs.style += (';' + this._style[name]); if (this._style['.' + attrs.class]) attrs.style += (';' + this._style['.' + attrs.class]); if (this._style['#' + attrs.id]) attrs.style += (';' + this._style['#' + attrs.id]); [代码] 优点：匹配效率高，适合前端对于时间和空间的要求 缺点：对于多层选择器等复杂情况无法处理 因此在前端组件包中采取的是这种方式进行匹配 方案二 将 [代码]style[代码] 标签解析为一个数组，每个元素是形如 [代码]{key,list,content,index}[代码] 的结构体，主要用于多层选择器的匹配，内置了一个数组 [代码]list[代码] 存储各个层级的选择器，[代码]index[代码] 用于记录当前的层数，匹配成功时，[代码]index++[代码]，匹配成功的标签出栈时，[代码]index--[代码]；通过这样的方式可以匹配多层选择器等更加复杂的情况，但匹配过程比起方案一要复杂的多。 [图片] 遇到的问题 [代码]rich-text[代码] 组件整体的显示问题 在显示过程中，需要把 [代码]rich-text[代码] 作为整体的一部分，在一些情况下会出现问题，例如： [代码]Hello <rich-text nodes="<div style='display:inline-block'>World!</div>"/> [代码] 在这种情况下，虽然对 [代码]rich-text[代码] 中的顶层 [代码]div[代码] 设置了 [代码]display:inline-block[代码]，但没有对 [代码]rich-text[代码] 本身进行设置的情况下，无法实现行内元素的效果，类似的还有 [代码]float[代码]、[代码]width[代码](设置为百分比时)等情况 解决方案 方案一 用一个 [代码]view[代码] 包裹在 [代码]rich-text[代码] 外面，替代最外层的标签[代码]<view style="{{item.attrs.style}}"> <rich-text nodes="{{item.children}}" /> </view> [代码] 缺陷：当该标签为 [代码]table[代码]、[代码]ol[代码] 等功能性标签时，会导致错误 方案二 对 [代码]rich-text[代码] 组件使用最外层标签的样式[代码]<rich-text nodes="{{item}}" style="{{item.attrs.style}}" /> [代码] 缺陷：当该标签的 [代码]style[代码] 中含有 [代码]margin[代码]、[代码]padding[代码] 等内容时会被缩进两次 方案三 通过 [代码]wxs[代码] 脚本将顶层标签的 [代码]display[代码]、[代码]float[代码]、[代码]width[代码] 等样式提取出来放在 [代码]rich-text[代码] 组件的 [代码]style[代码] 中，最终解决了这个问题[代码]var res = ""; var reg = getRegExp("float\s*:\s*[^;]*", "i"); if (reg.test(style)) res += reg.exec(style)[0]; reg = getRegExp("display\s*:\s*([^;]*)", "i"); if (reg.test(style)) { var info = reg.exec(style); res += (';' + info[0]); display = info[1]; } else res += (';display:' + display); reg = getRegExp("[^;\s]*width\s*:\s*[^;]*", "ig"); var width = reg.exec(style); while (width) { res += (';' + width[0]); width = reg.exec(style); } return res; [代码] 图片显示的问题 在 [代码]html[代码] 中，若 [代码]img[代码] 标签没有设置宽高，则会按照原大小显示；设置了宽或高，则按比例进行缩放；同时设置了宽高，则按设置的宽高进行显示；在小程序中，若通过 [代码]image[代码] 组件模拟，需要通过 [代码]bindload[代码] 来获取图片宽高，再进行 [代码]setData[代码]，当图片数量较大时，会大大降低性能；另外，许多图片的宽度会超出屏幕宽度，需要加以限制 解决方案 用 [代码]rich-text[代码] 中的 [代码]img[代码] 替代 [代码]image[代码] 组件，实现更加贴近 [代码]html[代码] 的方式 ；对 [代码]img[代码] 组件设置默认的效果 [代码]max-width:100%;[代码] 视频显示的问题 当一个页面出现过多的视频时，同时进行加载可能导致页面卡死 解决方案 在解析过程中进行计数，若视频数量超过3个，则用一个 [代码]wxss[代码] 绘制的图片替代 [代码]video[代码] 组件，当受到点击时，再切换到 [代码]video[代码] 组件并设置 [代码]autoplay[代码] 以模拟正常效果，实现了一个类似懒加载的功能 [代码]<!--视频--> <view wx:if="{{item.attrs.id>'media3'&&!controls[item.attrs.id].play}}" class="video" data-id="{{item.attrs.id}}" bindtap="_loadVideo"> <view class="triangle_border_right"></view> </view> <video wx:else src='{{controls[item.attrs.id]?item.attrs.source[controls[item.attrs.id].index]:item.attrs.src}}' id="{{item.attrs.id}}" autoplay="{{item.attrs.autoplay||controls[item.attrs.id].play}}" /> [代码] 文本复制的问题 小程序中只有 [代码]text[代码] 组件可以通过设置 [代码]selectable[代码] 属性来实现长按复制，在富文本组件中实现这一功能就存在困难 解决方案 在顶层标签上加上 [代码]user-select:text;-webkit-user-select[代码] [图片] 实现更加丰富的功能 在此基础上，还可以实现更多有用的功能 自动设置页面标题 在浏览器中，会将 [代码]title[代码] 标签中的内容设置到页面标题上，在小程序中也同样可以实现这样的功能[代码]if (res.title) { wx.setNavigationBarTitle({ title: res.title }) } [代码] 多资源加载 由于平台差异，一些媒体文件在不同平台可能兼容性有差异，在浏览器中，可以通过 [代码]source[代码] 标签设置多个源，当一个源加载失败时，用下一个源进行加载和播放，在本插件中同样可以实现这样的功能[代码]errorEvent(e) { //尝试加载其他源 if (!this.data.controls[e.currentTarget.dataset.id] && e.currentTarget.dataset.source.length > 1) { this.data.controls[e.currentTarget.dataset.id] = { play: false, index: 1 } } else if (this.data.controls[e.currentTarget.dataset.id] && e.currentTarget.dataset.source.length > (this.data.controls[e.currentTarget.dataset.id].index + 1)) { this.data.controls[e.currentTarget.dataset.id].index++; } this.setData({ controls: this.data.controls }) this.triggerEvent('error', { target: e.currentTarget, message: e.detail.errMsg }, { bubbles: true, composed: true }); }, [代码] 添加加载提示 可以在组件的插槽中放入加载提示信息或动画，在加载完成后会将 [代码]slot[代码] 的内容渐隐，将富文本内容渐显，提高用户体验，避免在加载过程中一片空白。 最终效果 经过一个多月的改进，目前实现了这个功能丰富，无层数限制，渲染效果好，轻量化（30.0KB），效率高，前后端通用的富文本插件，体验小程序的用户数已经突破1k啦，欢迎使用和体验 [图片] github 地址 npm 地址 总结 以上就是我在开发这样一个富文本插件的过程大致介绍，希望对大家有所帮助；本人在校学生，水平所限，不足之处欢迎提意见啦！ [图片]

[图片] 5月31日，小程序大赛作品提交，终于告一段落。 这段时间，相信很多同学和我们一样，在项目过程中积累、收获了不少经验，或是设计，或是开发，或是其他，都能从不同角度体会到小程序大赛的意义。今天，我想分享一下，在项目过程中，是如何以一种产品的视角，去打造小程序“ddl冲鸭”。扫描下方小程序码即可体验哦~ [图片]   【写在前面】虽然本文是个人撰写，但小程序项目是团队共同完成，无论如何，在这里都应该先致谢我们“咕咕咕”队伍的指导老师和参赛队友，以及各位作为体验用户、帮忙测试程序并给予意见反馈的朋友。   本文篇幅较长，主要包括以下内容： 一、产品定位——目标用户与主要功能 二、产品灵感——为什么选择小程序“ddl冲鸭”？ 三、关注用户——从用户角度进行需求分析与功能设计 四、竞品现状——我们如何做得比他人更好？ 五、精益求精——抓住用户心理进行产品设计 六、把握细节——优化产品体验，提高用户粘性 七、创新运营——产品已从0到1，还要从1到100 八、小结   感谢阅读。   一、产品定位——目标用户与主要功能这次参赛作品是微信小程序“ddl冲鸭”，主要目标用户是高校学生，主要是为了解决大学生ddl记录、管理需求。“ddl”即“deadline”，意为“最后期限/截止时间”，相信很多同学对这个词并不陌生，甚至内心有着强烈的共鸣。大学生日常ddl：提交作业的ddl，提交社团工作方案的ddl，提交比赛作品的ddl……日常ddl任务繁多，高效记录与管理成一大需求。 然而，目前市场上并没有针对ddl推出的产品，因此，针对性地解决用户需求、并实现产品的特色化功能，可成为产品的一大亮点。  “ddl冲鸭”的主要功能有： （1）记录ddl（可设置ddl分类、使用文本或语音记录、上传相关图片、选择相关位置等）； （2）通过将ddl设为星标、设置分类，以及查看不同状态，高效地管理ddl； （3）通过分享ddl，让好友了解自己的ddl，更可将好友的类似ddl（如同班同学具有共同的班级作业）直接添加为自己的ddl，简化手动创建步骤； （4）发起群组ddl，小组好友共同为ddl努力，交流感想，促进完成； （5）消息提醒功能，如ddl过期提醒等。 [图片]     [图片]  由于介绍作品功能并非本文重点，更多详情可查看以下演示视频： [视频] 如果您看完了演示视频，相信接下来的大部分内容都更加易懂。   二、产品灵感——为什么选择小程序“ddl冲鸭”？同样作为大学生，我们深感ddl在大学日常生活中的影响，推出“ddl冲鸭”，在为自己解决需求的同时，也希望它能够给更多人带来方便。因此，我们从实际出发，着重于解决ddl记录、管理需求，并在此基础上力求创新、创意。   小程序的命名： 我们很熟悉的微信、淘宝、饿了么这些产品的命名，基本都是通过名称就可以比较直观地体现主要功能，同时又避免枯燥无味而缺乏新意。比如，微信为什么不叫“信息”，淘宝为什么不叫“购物”，饿了么为什么不叫“叫外卖”，所以产品的命名还是比较重要的。 “ddl”不仅与主题对应，同时引起目标用户内心强烈共鸣，也让用户对产品的主要功能有初步设想；“冲鸭”即“冲呀”，结合了当下的网络流行词语，符合大学生的喜好。同时，小程序命名也体现了希望用户在面对ddl时向前冲、加油努力。 小程序的出现，不是为了取代手机app，它是为了在适当的情景下，更好地为用户提供服务。如小程序官方所介绍的，它无需下载，实现了应用“触手可及”的梦想，也体现了“用完即走”的理念。相对app，小程序开发门槛较低，能够满足用户的简单需求，同时，结合微信本身为小程序奠定的基础，如“搜一搜”等，也有利于产品运营、降低引流成本。 相信使用iPhone的朋友都了解，iOS 12有个新功能，可以统计每天使用手机上各款app的时长。不难发现，对于多数人来说，微信使用时长稳居第一，且占比极大。既然如此，我们也应该思考基于微信环境下，用户的使用习惯。“ddl冲鸭”在UI设计方面，以白色为主色，绿色为辅色，与微信7.0版本设计风格基本对应，能让用户产生高度融入之感。同时，风格简洁直观，让用户易懂易操作。用户长期使用微信的习惯也为小程序的使用带来了方便的基础，比如使用微信小程序可以方便用户充分利用碎片时间，进行ddl管理。   三、关注用户——从用户角度进行需求分析与功能设计相信之前有关注过2019微信公开课的朋友，应该都对张小龙的这句话比较熟悉：“我们应该关注用户，而不是竞争对手。”作为一个产品策划的角色，应该有着“用户至上”的基本理念，同理心、善于换位思考成为了必备基本技能之一。所以我们从用户的角度出发，注重用户的实际需求，进行需求分析、管理、功能设计。 从宏观到微观，整体的功能设计都应该以解决用户实际需求为基本原则。 我们以问卷收集、用户访谈、竞品调研等多种形式，挖掘用户需求，同时也是为了针对市场上已有竞品的不足，针对性进行弥补。 [图片]  具体的调研分析，这里不进行详细介绍，但我们大致得到了如下结论： （1）用户现状：ddl记录与管理需求存在，产品开发必要性强——这充分论证了我们产品定位的合理性； （2）竞品现状：目前市场无针对ddl产品，用户个性化需求未被满足——在针对ddl主题进行产品设计的同时，我们也应该针对用户的个性化需求，打造具有特色的产品； （3）用户关联：一般在完成任务中有一定的好友互动，群组任务也较为常见——我们据此设计了好友分享ddl、群组ddl等功能，满足用户的常见需求； （4）用户习惯：存在ddl紧迫感、未完成愧疚感、已完成成就感等——便于我们抓住用户习惯与心理特点，完善产品设计； （5）用户期望：希望需求得到满足，产品体验良好——实现功能后，应该注意细节，追求为用户提供最好的产品体验。 进行需求分析、分类后，应对其进行分类管理。不可能第一个版本就解决所有的需求，也没有这个必要，因为这样会导致开发成本大、风险也高、且发展空间小。我们会着重于解决基本型需求与期望型需求，在此基础上完善魅力型需求，从各种细节优化出发，力求在满足功能需求的基础上提升用户对产品的体验好感度。   四、竞品现状——我们如何做得比他人更好？有的人会说，“ddl冲鸭”不就是一个记事本工具那样的产品吗？不是这样的，我们针对ddl主题，并对比竞品，实现了许多特色化的功能。以下谈谈“ddl冲鸭”的几个功能上的亮点： （1）ddl记录 区别于传统的文本记录，“ddl冲鸭”加入了语音、图片、位置等多种不同形式的记录，多样化完善ddl记录，满足用户的个性化需求。 比如，有时用户觉得输入大段文字记录比较麻烦，就可以用语音记录；上课时拍到老师的PPT，不方便转换为文字，就可以用图片记录；需要到某地办理港澳通行证，ddl又与位置有关等。 [图片]  （2）ddl管理 在ddl列表页面可以快速切换不同状态的ddl（全部、进行中、已完成、已删除、已过期），并可以通过设置ddl星标、分类等，快速筛选符合条件的ddl，还可以选择按最新创建时间、ddl时间为ddl列表排序，使原本繁琐的ddl列表变得一目了然； [图片]  （3）管理进行中的ddl 相信大家都很了解，许多类似产品会在待办事项右侧显示剩余时间，如3天、5天等，而“ddl冲鸭”则在此基础上，根据剩余时间的不同，给予不同颜色的文本和不同长度的进度条进行提示，时间越少时文字颜色越深（从绿色到黄色、橙色、红色）、同时进度条长度越小，从视觉上给予用户ddl紧迫之感，督促用户更快完成ddl。 [图片]  （4）便捷的创建ddl 当与好友具有共同或类似ddl时（如同班同学具有相同的课程作业ddl），可直接将好友分享给自己的ddl添加为自己的ddl，简化了用户手动创建ddl的步骤，为用户带来了方便（创建时也可对原有内容进行修改）。 [图片]  （5）群组ddl功能 为进一步增强用户互动与提高效率，设计了群组ddl功能，当一个小组具有共同的ddl（如班级课程作业小组）时，可发起群组ddl，大家在同一个ddl中共同加油努力，交流ddl感想，互相促进完成。但我们设计这个功能的定位是小组，而不是社区，因此群组上限为20人。 [图片]  以上是关于作品，在区别于其他竞品方面的几个特色功能。总体而言，“ddl冲鸭”具有以下几个特点： （1）用途明确，用户共鸣强 （2）使用便捷，用户粘性大 （3）形式新颖，用户兴趣大   五、精益求精——抓住用户心理进行产品设计根据调研结果，结合我们自身换位思考、深入体验，我们从用户心理的角度，精益求精，完善产品设计。  （1）未完成ddl的心理罪恶感——设计过期提醒功能 当有未完成的ddl时，进入小程序首页将会弹出提示，为鸭子落泪的图片，并播放“咕咕咕”的鸽子声，提醒用户已经放了自己的ddl的鸽子； 这样设计是为了与用户未完成ddl时的心理愧疚感对应，提醒用户以后要按时完成ddl任务，不能再放了自己的鸽子。 [图片]  （2）无ddl时的悠闲感——无ddl时提示相关图片 没有ddl时，显示一只正在睡觉的鸭子，表明当前没有ddl任务的悠闲感，与用户当前的心理对应。 [图片]  （3）有ddl时的紧迫感——通过不同颜色、进度条显示剩余时间 这个前面已经简单介绍过，即根据剩余时间的不同，给予不同颜色的文本和不同长度的进度条进行提示，时间越少时文字颜色越深（从绿色到黄色、橙色、红色）、同时进度条长度越小，从视觉上给予用户ddl紧迫之感，督促用户更快完成ddl。 [图片]  （4）用户懒、害怕选择——合理设置默认值、提供方便用户的功能 ①创建ddl时，默认时间为当前时间三天后的22时，默认ddl类别为“学习”。这是根据我们调研结果，得出通常在ddl剩余三天时，用户会开始重视ddl，且当下大学生面临的多数ddl为学习方面的（如课程作业）。设置默认值，用户无需选择，方便用户。 [图片]  ②记录ddl，可以粘贴文本、语音记录、将好友分享的ddl直接添加为自己的ddl，这些都是为了方便用户而推出的功能。 [图片]     [图片]  （5）用户渴望得到鼓励——弹图提示，群组交流 ①个人创建或完成ddl时，要与用户充满斗志的激情感、完成时的喜悦感与成就感对应，因此我们设计了相关的图片进行提示，而不是普通的文本模态框。 [图片]     [图片]  ②设计了群组功能，完成ddl时可以交流感想，鼓励他人；同时，群组排行榜也有利于促进用户完成ddl。 [图片]     [图片]   六、把握细节——优化产品体验，提高用户黏性产品设计过程中，充分考虑多个细节。虽然它们不一定会对产品的主要功能产生影响，但积少成多，优化了用户使用体验，有利于提高用户黏性，如：  （1）启动页展示轮播图，让未使用过的新用户初步了解小程序的功能，只有第一次进入时会显示。 [图片]  （2）不是第一次使用的用户，已经了解过小程序的基本功能，那么用户进来最想要看到的内容是什么——当然ddl列表，且是“进行中”状态（即还未完成的）的ddl列表。 就像微信，我们打开微信后最先想要看到的是什么？当然是微信的未读消息，而不是通讯录之类的页面。  （3）操作体验优化，更加易用：标签页除了点击顶部导航切换，也可以左右滑动进行切换，有利于方便用户单手操作。 [图片]  （4）操作时，必要时给予提示，避免用户误操作，如误删除 [图片]     [图片]  （5）充分考虑多种可能的不同情况，如： ①用户第一次进入小程序时，进入启动页，在启动页进行授权，授权后才可以使用小程序；但如果用户是通过他人分享ddl页面第一次进入小程序，则还需要进行授权才能使用。 [图片]     [图片]  ②前面提到，群组ddl功能的设计，是针对小组，而不是为了打造社区，因此群组上限为20人，必要时也应给予提示。这样的设计是遵循了产品的定位，与产品定位对应——即做效率类工具，而不是做社交平台。 [图片]  （6）尊重用户隐私与体验，如： ①用户只是想与他人分享自己正在忙的ddl，但没有打算让他人添加为自己的ddl——分享时可进行选择。 [图片]  ②为避免消息过多给用户带来骚扰，消息列表最多只显示最近20条消息。 [图片]  （7）在线客服、意见反馈等不可缺少，这是作为用户与我们沟通的桥梁之一，也有利于不断改进产品。 [图片]     [图片]   七、创新运营——产品已从0到1，还要从1到100由于本文主要是在讲产品策划，因此开发方面不多讲。但产品运营与产品策划密不可分，产品策划强调从0到1，产品运营强调从1到100，在产品被设计开发出来之后，还要结合运营推广，让它真正投入使用，才能体现它的价值。 这里简单提几点想法： （1）既然产品是微信小程序，那么最基本的就是结合微信进行推广，除了普通的微信群、朋友圈、公众号，还可以结合微信新功能“时刻视频”、“看一看”等。在微信环境下的推广，有利于用户快速定位到产品，减少引流成本； （2）针对目标用户：由于目标用户是高校学生，可以借助各高校相关微信公众号、微博、贴吧等进行线上宣传； （3）培养目标KOL（关键意见领袖），KOL在产品上线后发挥小范围同化辐射作用，提高其他用户对产品的信任度，也是作为用户自传播的方式之一； （4）组建线上ddl交流群或活动，在收集用户反馈的同时提高产品存在感，同时也可作为MVP产品，更好地了解用户的需求与实际情况； （5）结合当下深受年轻群体（包括目标用户即大学生在内）喜爱的短视频，可制作相关宣传短视频（要追求创意），借助腾讯微视、快手、抖音等短视频平台进行宣传； （6）结合小程序项目已有“冲鸭”系列图片设计，进一步拓展，制作微信表情包“冲鸭”系列，可申请在微信表情包商店上架，在微信聊天中进行使用，提高产品曝光、辅助产品推广。 [图片]  如果能在作品提交前上线运营，有运营数据支撑（如用户量、用户使用情况等），就说明产品的确有人用，说明产品开发的合理性、必要性。   八、小结其实我和其他的队友一样，我们队里的同学没有软件专业的，也没有计算机专业的，甚至有中文之类的文科专业同学。我们都是凭借兴趣自学了相关的技能，这也是驱动我们认真投入的重要原因之一——是为了兴趣，为了挑战，不是为了参赛，不是为了拿奖。论开发技术，我们也许并不如很多计算机专业的，但在我眼里，产品思维比技术重要，这也是我今天写文章，是以产品的角度来写、而不是以开发的角度来写的原因（当然，写得也比较简单，还望见谅）。以下是我的几点简单的参赛感想： 1、首先应该确定的问题，是产品定位、目标用户等，这些作为整个项目的基础以及方向，至关重要；在构思时应该多方面考虑（功能设计、目标用户、开发成本、运营方案等），在满足基本需求的前提下，力求创新，才能比别人做得更好（一味地实现必备需求而不追求创新，则很难突出产品亮点）； 2、开发固然占了很重要的一部分，但一个完整的项目，不是只有开发，设计、运营等都很重要，这些是共同推进一个产品成功的必不可少的因素； 3、大赛提到了“以赛促学”，个人认为对于初学者来说，不要急于使用高大上的技术以便快速做出功能很高大上的产品。技术基础要扎实，才有利于长远的发展。所以我们用的是原生开发技术，不使用任何第三方开发框架（这里说的是开发框架，但我们有一定程度地使用了UI组件库）。在WXML、WXSS、js等原生技术基础上，力求创新实践。   【写在最后】“ddl冲鸭”产品初步成形，虽已上线运营投入使用，但依然有很多不足之处，后面会尽力再继续完善。这一次做项目，同时也是为了实现个人理想。我本人是打算往互联网产品策划方向发展的，这次项目也是相当于一个伟大的尝试。 在学习、借鉴一些去年参赛作品的过程中，我发现有一些作品现在已经停止了更新维护，甚至还有作品暂停服务、无法访问、或者至今没有正式发布上线等，这也让我再次思考了大赛和作品的意义。 单纯抱着“想试试、想参与”的态度，真的容易做出一款很好的产品吗？我想起以前面试社团，其实那个部门没有很想去，尽管一开始很顺利，面到最后一轮的时候还是挂了。当时我的老师对我说：“其实你的内心根本就没有那种特别想去的决心，那么这种情况下你又怎么可能发挥出你最大的潜力呢？” 4月底，面了腾讯暑期实习产品策划岗，面了三轮后挂在了总监面，无缘HR面。但是也并不遗憾，毕竟当时面试好像是随机分配？所以我面的部门和产品，并不是我想要做的，我不怎么接触、兴趣也很一般，确实没有“非去不可”的心态。然而塞翁失马，焉知非福？印象深刻，当时面试官问我：“你为什么想要选择做腾讯的产品策划？”现在我想说：“我和腾讯一样，有着一颗想要创造出能够改变世界的产品的心。”鹅厂是我美丽羞涩的梦，祝鹅厂越来越好，也希望我和鹅厂有缘再次相遇。   文粗词浅，感谢阅读。如有意见，恳请指教，感激不尽。  

大家好，我们是来自华中赛区的 “NCHU_文体两开花”团队，意在文娱与体育，两面皆开花。 当2019年5月31日晚，距离微信小程序大赛作品提交截止时间仅剩最后10分钟时，我们几乎颤抖着手将最后一项更新的文件上传到微信小程序比赛入口，看到网页上提示“提交成功！”的字样，所有人心中的一块大石头终于都落了地。 “辛苦了，辛苦了！” “我要先睡个三天三夜！终于能先睡个好觉了。”前端小哥哥如是说。 然而这只是参加微信小程序大赛的第一阶段，未来我们还有很长的路要走。从确认选题到提交作品，这不长不短的两个月以来，我们一起拼搏，一起在实验室里不断完善作品。个中辛苦，有目共睹。 关于我们的作品“Attack足球”，就要追溯到选题时期了。 一、选题idea 我们团队大部分的成员都身在软件学院足球队，秉持着一颗热爱足球的心，积极参与日常训练和比赛，然而每当比赛前后，不只是我们学院的球队，纵观全校，都会经常出现一个问题：在教练使用战术板讲解战术时，我们一些站得远的队友经常听不清、看不着、不理解，尤其是每次教练指导完战术之后，便很难再复盘了。 为了今后战术指导更加顺利地进行，我们要改变这种现状！我们不仅是足球队的一员，还是软件学院的一名学生，具有得天独厚的优势。如果将足球战术板与软件结合到一起，会碰撞出怎样奇妙的火花呢？ 我们想要将战术记录下来，在日后能够随时随地翻看已保存的战术指导，而微信小程序能够给一些优质服务提供平台，其即用即走的特性也是我们选择将战术板与微信小程序结合的重要原因之一，这便是我们开发Attack足球微信小程序的初衷。 为什么我们要叫“Attack足球”呢？ 其实在这之前，我们有想过最普通直白的名字——“足球战术板”、“战术足球”等，也想过稍加修饰后的“战术风云”，但总感觉缺了些韵味，在一番思考后，我们定下了“Attack足球”这么一个中西结合的名字。 在足球赛场上，要想成功夺冠，离不开正确的战术，成功组织战术、巧妙运用战术是克敌制胜的关键。 “进攻是最好的防御，防御是为了更好的进攻”。 Attack取其“进击”之意，希望能借助这个名字，鼓励人们无论是在球场上还是生活中，都应该拼搏向前，锐意进取。 二、我们是如何做的？ 需求分析对于一个项目来说是一个不容怠慢的关键点，一个好的需求分析代表着整个项目已经成功了一半。确认好Attack足球的基础功能后，如下图，便到了需要仔细考虑整个项目的功能需求的时候了。 [图片] 我们团队早期的会议并非是在讨论整个项目如何具体实施，而是提出自己对项目中还不理解的地方。例如： “在我们的Attack足球的球队管理功能中，被队长指派的教练可以像微信群一样把人踢出球队吗？” 有人提出疑问，就要进行解答。经过探讨，我们的答案是否定的，教练没有必要拥有对球队成员进行管理的权限，只有创建球队的队长才可以对成员进行管理工作。 由于要将整个项目细究，不放过任何一个点，因此需求分析确实花费了我们很多时间，但是这项工作绝不是在浪费时间。通过需求分析，我们所有人都对Attack足球有了十分具象的认识，团队中人人心中都有数，会让项目进展得更加顺利。 认真确定好需求，技术方案跟着便确定下来了： [图片] 我作为团队中的UI设计师，在刚开发Attack足球时，灵感乍现设计了一套方案，但是应用起来，如下图左图，效果并没有想象中好…… [图片] 没有得到预期的效果，对于UI设计师来说是一件很沮丧的事情。好在其余的团队成员帮助我及时调整心态，加上通过这些日子我对Attack足球有了更多了解，方案二也在我心中成型了。在与团队商量后，我们果断推翻方案一，及时止损，正式启用方案二，如上图右图。方案二与方案一比起来，不仅视觉效果好很多，考虑到的用户接口也会更加细致、更加贴近用户需求。 确定好界面风格，我需要将设计稿的各部分信息，例如间距、颜色等整理出来，接下来就由我们团队的前端小哥哥将设计稿付诸实践了。不过单独只有界面没有实际的功能可不行。要让Attack足球真正运作起来，前端小哥哥和后台小哥哥的配合必不可少。 在开发阶段，并非我就闲下来了，我还需要不断跟进项目，改进交互体验。我在尝试使用我们的作品Attack足球时，会将自己的身份定位为用户而不是开发者，这时又会发现很多用户体验不好的情况，例如：提示信息不够明确（此时用户的心理状态就是：嗯？我是谁？我接下来要做什么？）、界面观感太多繁杂（颜色爆炸！）等。我在设计球队管理功能界面时，就出现了这一类型的状况： [图片] 上图是我的球队管理界面设计稿，如左图，所有的教练、球员列表后都有按钮，红叉代表将成员踢出球队，黄色带有上下箭头的标志分别代表将教练降为球员和将球员设为教练。在没有教练、球员列表旁的提示信息时，仅看带有箭头的黄色标志不足以让用户明白这个按钮代表的是什么含义；而加上提示信息，整个界面颜色又过于杂乱、显得拥挤。 经过团队探讨后，我们确定了方案二，如右图：将队长对成员的操作按钮隐藏起来，当用户对球员信息从右向左滑时，显示按钮，才可以对其进行操作。 相比之下，方案二中左滑滚出选项的交互方式无弹窗、无等待，操作简便，也避免了整个画面过于杂乱而导致的糟糕的用户体验，这也证明了交互设计应该切实用用户之所用，想用户之所想，这样才能留住我们的用户大大！ 在开发录制战术模块时，我们会毫不留情地对前端小哥哥吐槽：这些工具真的太难用了！中号铅笔太粗、橡皮擦不干净、删除界面中的球员的方式极其不友好等等，同时在我们强烈建（yao）议（qiu）下，他花了一下午的时间研究怎么将代表球员前进路径的铅笔笔划加上箭头标志，最终，他确实做到了！最终的效果如下图，完美完成我们的预期： [图片] 接下来的日子，我们一步一步将功能添加：录制战术、球队管理、战术文件管理、实时演练等。在最后的冲刺阶段，小程序的鲁棒性与用户体验是我们的重中之重，团队全员皆测试工程师，一边绞尽脑汁找BUG，一边废寝忘食改BUG，尽力将每一步都做好，每天我们的开发小哥哥们都要面临我们团队集体的灵魂拷问： “我的长昵称显示到第二行啦！怎么还没有改过来？” “有人加入了我的球队，我这边怎么还没有消息提示呢？” “这里……改改改！” 开发小哥哥们也都是先仰天长叹，不过紧接着就燃起熊熊斗志，埋头修改，最终完成的成品就是我们已上线的“Attack足球”。 不知不觉，开发Attack足球的这两个月就过去了，我也见证了在整个团队的共同努力下，Attack足球从无到有的整个过程。这过程中我们有笑有疲惫，但还好，我们相互扶持、相互鼓励，没有什么问题是齐心协力不能解决的。 虽然作品已经提交，但是我们了解Attack足球仍旧存在一些不足的地方，我们依然还在不断思考如何拓展更多功能、怎样提供更佳的用户体验。 提升专业性：添加更多与足球专业相关的词汇，使其更具专业性； 重视小细节：增加引导页，让用户第一次进入不迷茫； 完善不停歇：在Attack足球今后的版本中，可能还会出现其他不足之处，我们会不断对此进行相应的修改，Attack足球走在前进的道路上永不停歇。 三、感悟 足球作为一项体育活动，能给人带来快乐的同时，其团队协作、努力拼搏的足球精神也深深影响着每一个热爱足球人士的心。对于一个开发团队而言，不仅需要有优秀的成员冲锋陷阵，也需要卓越的领导运筹帷幄。我们的PM小哥哥带领着我们团队一步一步从设计到实践，在整个项目开发，他贯穿始终，是我们前进的导向标，是我们强而有力的领导者。 经过此次微信小程序大赛的洗礼，我们团队中的所有人不仅是编程技术上有了突破，更在心灵上经历了一次历练，这次为了同一个目标奋斗的过程也在我们的人生经历中添上了浓墨重彩的一笔。 在此，我总结了一些经验，希望可以帮到有需要的人： 对于UI设计师来说，灵感是一项很重要的东西，当灵感出现时，要及时记录，同时在实现灵感的过程中，并不需要面面俱到，因为在此期间，还可能会产生新的灵感，将灵感整理成点子，再将点子完善成作品，这个过程十分重要。 用户体验成为软件成败的关键点之一，需要在满足需求的同时不做太多繁琐的操作，化繁为简，切实照顾到用户的主观意向，用户才不易流失。 团队协作对于一个项目的开发而言尤为重要，团队的每一个人都是不可或缺的。在小团队中，每个人都清楚了解其他成员的工作任务，团队所有成员的步调一致会让项目开发更加高效。 作品是不断完善的，要想做到无论多么简单的需求，执行出来的产品都或多或少会有些缺陷。我们要做的，就是尽可能弥补这些缺陷。在实践过程中，不断积累经验，可以在今后编程时规避同种类型的缺陷。 四、愿景 在从开始到完成Attack足球的这两个月内，我们执行了完成一个项目的所有流程。微信小程序大赛是一个正式的比赛，是一个开放的平台，我们真诚地希望通过这次比赛，能让更多人了解Attack足球，同时也希望能在微信小程序大赛上我们“NCHU_文体两开花”团队能够取得一个满意的成绩。 足球所代表的是一种团队精神，而开发一个项目也需要团队成员组成的凝聚力，需要成员为团队的共同目标而齐心努力奋斗。虽然如今的Attack足球还是一款主要面向校园足球队的战术板工具，但在今后，Attack足球面向的可能不仅是校园足球队，还有可能走出校园，步入专业足球队，我们也会带着足球教会我们的团队与拼搏精神，为了这一天努力奋斗。

最近用springboot开发后台接口，但是接口开发好以后，用js请求接口json数据，遇到了烦人的跨域问题，也是找了好久才找到解决方法。下面来讲解下解决步骤。 一，编写Filter过滤器 把下面代码放到你的springboot项目中就可以了 [代码]package com.qcl; import org.springframework.stereotype.Component; import java.io.IOException; import javax.servlet.Filter; import javax.servlet.FilterChain; import javax.servlet.FilterConfig; import javax.servlet.ServletException; import javax.servlet.ServletRequest; import javax.servlet.ServletResponse; import javax.servlet.http.HttpServletResponse; /** * 处理跨域问题 * qcl：微信2501902696 */ @Component public class OriginFilter implements Filter { @Override public void init(FilterConfig filterConfig) throws ServletException { } @Override public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain) throws IOException, ServletException { HttpServletResponse response = (HttpServletResponse) res; response.setHeader("Access-Control-Allow-Origin", "*"); response.setHeader("Access-Control-Allow-Methods", "POST, GET, OPTIONS, DELETE,PUT"); response.setHeader("Access-Control-Max-Age", "3600"); response.setHeader("Access-Control-Allow-Headers", "x-requested-with"); chain.doFilter(req, res); } @Override public void destroy() { } } [代码] 二，用js做下请求验证下 如我们需要请求https://localhost:8443/pv/2048/list 获取如下数据，https://localhost:8443/pv/2048/list是我部署在服务器上的，2020年到期，你也可以访问 [代码]{ "code": 100, "msg": "成功", "data": 3 } [代码] [图片] 对应的js请求代码如下 [代码]<!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <title>js+springboot解决跨域请求</title> </head> <body> <script src="https://cdn.bootcss.com/jquery/1.10.2/jquery.min.js"> </script> <script> var baseUrl = "https://30paotui.com"; $(document).ready(function () { $("button").click(function () { $.ajax({ url: baseUrl + "/pv/2048/list", success: function (result) { document.getElementById("p1").innerHTML = result; var str = JSON.stringify(result); //将JSON对象转化为JSON字符 var obj = JSON.parse(str); //由JSON字符串转换为JSON对象 console.log(str); console.log(obj); console.log(obj.data); console.log(result.msg); console.log(result.code); } }); }); }); </script> <p id="p1"></p> <button>获取其他内容</button> </body> </html> [代码] 请求效果如下 [图片] 有任何关于编程的问题都可以留言或者私信我，我看到后会及时解答 编程小石头，码农一枚，非著名全栈开发人员。分享自己的一些经验，学习心得，希望后来人少走弯路，少填坑。

1：安装微信sdk,cnpm install weixin-js-sdk -S; 2：安装完成之后再main.js文件引入，注入到vue原型 import wx-sdk from “weixin-js-sdk”; 3：在第二个或者第三个页面去调用后台提供的接口初始化微信的sdk(最好在第二个页面去初始化，不然会遇到一个生命周期的问题) [图片] 参数说明：debug:true||false,查看初始化结果，成功与否，appID:公众号的APPID。timestamp:生成签名的时间戳。 nonceStr:生成签名的随机字符串。signature:微信生成的签名。jsApiList:需要在项目当中使用的那些方法，比如说支付chooseWXPay，直接把方法写进jsApiList里面既可。 4：我这里用微信支付演示一下 [图片] 然后调起支付的参数就和小程序是一样的道理，由后台给你传过来即可。 微信小程序开发交流群纯交流群，没有任何广告，学习微信小程序的欢迎加入，里面有性感大牛在线解决问题 [图片]

状态管理 一开始为了借鉴和复用课堂H5详情页的状态管理，引入 redux ，但由于 reducer 总是返回一个新的更新后的对象，这意味着每次 setData 时会传递全量的数据，而在小程序双线程界面渲染的数据通信模型下，传输数据量与性能正相关，因此对于数据量比较大的详情页来说，每次 action 操作都比较耗性能，体验不好。 于是改用腾讯开源的小程序状态管理方案 westore， 它利用小程序 setData 函数支持以数据路径的形式传递数据的特点，通过 update 函数先进行 diff 得到最小更新的数据路径集合，然后再调用 setData 函数传递变化的数据以达到更优的性能。 可是 westore 是基于页面路径来同步数据的，如果同时存在两个相同路径的页面，则只有最新的页面会更新；例如当前页面 A （pages/course?cid=A）打开相同路径的页面 B （pages/course?cid=B）时，由于 store 数据是共享的，这时页面 B 持有页面 A 的数据，同时页面 A、B 路径（pages/course）相同，此时 westore 已经丢掉页面 A 的引用，当 westore 更新数据时只会影响到页面 B ，页面 B 返回页面 A 后，已经无法再更新页面 A 了。 对于这个问题，只要增加一个栈来记录页面路径实例，新开页面时，重置 westore 数据，页面返回时，将旧页面实例的数据同步到 westore 即可。 [图片] 除此之外，H5详情页中很多复合的状态逻辑都放在嵌套较深的自定义组件中，可在小程序环境下就有点力不从心了，所以必须要将这部分常变状态和遍历逻辑提前计算，以便 westore diff 局部更新。 富文本 [图片] 课堂详情页中需要展示由富文本编辑器 CKEditor 生成的课程详情，里面可能包含视频，但小程序提供的 rich-text 组件无法支持 video 标签，因此用到 wxParse 来将 HTML 文本解析成 JSON 树，然后通过 view + css 来模拟 HTML 元素进行渲染。 可是 wxParse 已经很久没有更新了，在使用过程中发现它有很多问题和局限性，以下是踩坑改造优化经验： 缺少解码、解析和渲染完成等钩子：由于后台 CGI 返回的 HTML 文本存在二次编码的情况，只经过 wxParse 的一次解码后仍有部分字串没有被正确解析，同时针对某些解析后的 HTML 标签需要扩展其属性等等。 因此只能修改源码增加 beforeDiscode、afterDiscode、parsedStartTag、parsedEndTag、parsed 和 complete 等钩子来提高其灵活性。 含有较多复杂属性的 HTML 标签无法解析出来：主要是 wxParse 中 startTag 的正则表达式不够全面导致的。 [图片] 上图无法解析出第一个 p 标签。 修改一下 startTag 的正则表达式即可。 [图片] 12个相同 template：wxParse 定义了 wxParse0 到 wxParse11 共 12 个 template，这 12 个 template 除了子结构调用不同的 wxParseXX template 之外其余代码都是一样，究其原因是因为小程序 template 不能递归引用，当然这种变通的处理方式有个局限性，就是它处理不了超过 12 层的结构，超过以后就解析不了，再加上小程序的机制，这样是不会报错的，导致查 bug 很困难。要解决这个问题，除了官方支持 template 递归，可以将 wxParse 改为自定义组件（暂未尝试），或者尽可能的合并 HTML 结构。例如 [图片] wxParse 解析渲染后的结果 [图片] 这里可以发现每个 wxParse-inline 元素的样式完全可以合并，同时形如 wxParse-s 等元素是通过 css 来模拟 HTML 元素的，因此对于这样嵌套的行内元素，可以进行合并 [图片] a 标签作为块元素：由于 a 标签允许包裹其中没有交互内容的块元素，wxParse 把 a 标签视为块级元素，导致解析 a 时将其前一个行内元素提前闭合了，造成显示错误。解决办法是将 a 标签从块级元素中剔除。 不支持腾讯视频 vid：小程序 video 仅支持视频地址和云文件 ID，但课程详情会包含腾讯视频，而腾讯视频播放路径需要通过腾讯视频 SDK 将视频 vid 转换出来，由于已经引入腾讯视频组件，VID 转换这一步可以省略交给腾讯视频组件，只需要将 wxParse template 中 video 标签改为 txv-video，同时在 wxParse 解析出 video 数据时计算出 authExt ，连同 vid 等必要字段一并提供给 txv-video 即可播放视频。考虑到课程详情中的视频播放频次不高，没必要详情展示时就生成腾讯视频组件，因此使用封面 + 播放按钮来替代，等待用户点击封面时才生成。 wxParse 样式污染全局：定义了 view 样式，但没有限定在 .wxParse 作用域下生效，导致影响了页面全局。 标签内文本含有 < 则解析结束标签有误 setData含有较多与界面渲染无关的数据 … WXML WXML（WeiXin Markup Language）是小程序视图层的一套标签语言，它与 Vue 的模板语法很相似，但在实际开发过程中经常会遇到一些问题与限制。 数据绑定中的数据处理 在 WXML 中，数据绑定只支持简单的 js 表达式，不能调用方法。例如保留数据的小数点后两位 [代码]<view>{{num.toFixed(2)}}</view> [代码] 这种写法是不会生效的，为了弥补 WXML 中数据处理的短板，小程序提供了 WXS（WeiXin Script）脚本，可以这么做 [代码]<view>{{tools2.toFixed(num, 2)}}</view> <wxs module="tools2"> function toFixed(num, len) { return num.toFixed(len); } module.exports = { toFixed: toFixed } </wxs> [代码] 但要注意的是 wxs 与 javascript 是不同的语言，有自己的语法，并不和 javascript 一致，更不能使用 es6 语法。 wxs 的运行环境和其他 javascript 代码是隔离的，wxs 中不能调用其他 javascript 文件中定义的函数，也不能调用小程序提供的API。 wxs 函数不能作为组件的事件回调。 wxs 目前共有以下几种数据类型：number，string，boolean，object，function，array，date，regexp template 的 data 传参 如果只看 官方文档 template 说明，你可能不知道 template 的 data 传参有三种方式： 格式一：data="{{ …value1，…value2，… }}"，value 前面的 [代码]...[代码] 是扩展运算符。 格式二：data="{{ value1，value2，… }}"。 格式三：data="{{ key1: value1，key2: value2，… }}"。 value 可以是 boolean、number、string、null、object、array。 例如 [代码]value = { a: 1, b: 2, c: 3}[代码]，那么在 template 中的使用如下： [代码]<!-- 格式一 --> <template name="example1"> <view>{{a}}: {{b}}: {{c}}</view> </template> <template is="example1" data="{{...value}}" /> <!-- 格式二 --> <template name="example2"> <view>{{value.a}}: {{value.b}}: {{value.c}}</view> </template> <template is="example2" data="{{value}}" /> <!-- 格式三 --> <template name="example3"> <view>{{k.a}}: {{k.b}}: {{k.c}}</view> </template> <template is="example3" data="{{k:value}}" /> [代码] 如果在列表渲染时，想要将列表的索引 index 在 template 中使用，可以这样做 [代码]<template name="example4"> <view>{{index}}: {{msg}}: {{time}}</view> </template> <template is="example4" wx:for="{{items}}" data="{{index, ...item}}" /> [代码] 除此之外还可以结合 wxs [代码]<template name="example5"> <view>{{msg}}: {{time}}</view> </template> <template is="example5" data="{{...tools.getLast(items)}}" /> <wxs module="tools"> function getLast(items) { return items[items.length - 1]; } module.exports = { getLast: getLast }; </wxs> [代码] 数据缓存与自定义组件和 wx:if 在做页面数据缓存时，由于页面数据字段比较多且嵌套深，有时图方便，我们会省略嵌套深的字段定义同时将缓存赋给 data，然后直接在 wxml 中使用 [图片] 如果 wxml 中刚好使用了 wx:if 和自定义组件，那么在小程序基础库 2.4.0 及以下，从第二次进入该页面时就会报错 [代码]Expect FLOW_CREATE_NODE but get another[代码]，对于这个问题，有几种解决办法： _list 列出所有字段定义。 data 中 list 不直接赋值 _list，改在 onLoad 时通过 setData 传递。 wxml 中 wx:if 改为 hidden 处理，或者不适用自定义组件。 上述问题出现的条件比较特殊，很大部分是编码问题，但从小程序基础库 2.4.1 开始就不会出现。对比了不同版本基础库在 onLoad 阶段输出的 data 信息，发现 2.4.1 及以上 data 的初始值不再等于当前缓存的 _list 值。 2.4.0 及以下第一次和第二次进入该页面时的 data 值，第二次进入已有缓存 [图片] 2.4.1 及以上第一次和第二次进入该页面时的 data 值相同 [图片] 其他 template 模板与 component 组件 template 模块与 component 组件是小程序中组件化的方式。二者的区别： template 模块主要是展示，交互需要在使用 template 的页面中定义。 component 组件拥有自己的数据处理与交互逻辑，类似一个 page 页面。 在需要频繁更新的场景下或者在列表中涉及到列表子项独立的操作时，使用自定义组件可以只在组件内部进行更新，即实现页面局部更新，而不受页面其他部分内容的影响。 onPageScroll 与 IntersectionObserver 在做图片懒加载、元素曝光上报和元素吸顶展示时，离不开元素位置与页面滚动位置的判断，与之相关的事件或API有： onPageScroll：page 中监听用户滑动页面的事件。自定义组件无法使用，只能通过传参或事件总线来获取变化状态。 IntersectionObserver：监听某些节点与参照物边界相交状态的对象。参照物可以是指定一个节点或者页面显示区域。 从触发回调频次来看，onPageScroll 远远高于 IntersectionObserver，而且每一次事件回调都是一次视图到逻辑的通信过程。因此应该只在必要的时候才使用 onPageScroll，其他情况使用 IntersectionObserver 替代较好。

双生日记开发经验分享 Hello，我是双生日记的 Founder & Developer Airing。该项目的小程序端获得了 2018 C4——微信小程序应用开发赛的一等奖，而 iOS 端则获得了 2018 C4——移动应用创新赛的一等奖，目前累计注册用户已达 1 万+，并仍在不断开发维护中~ 本文将简要概括我们团队在产品的整个研发流程中的所做的工作，更侧重于介绍产品研发与团队管理的方法。 我将整个产品的研发分为以下四步： 立项 设计 开发 维护 [图片] 可以看到，以上四步形成了项目流程的闭环，使得产品能够良性发展。接下来我来具体谈谈这四步工作的内容。 1. 立项 项目立项是所有环节最开始的部分，我觉得也是最重要的部分，它的工作内容类似于“产品经理”的职责。虽然我是 Founder，但产品的探讨还是与大家共同完成的。具体而言，这个环节有两个内容： 产品脑暴 文档整理 1.1 产品脑暴 首先，我会先在团队中提出我的想法，并创建一个讨论区供大家讨论。我们是一个非常大的兴趣团队，虽然参与双生研发的只有寥寥三人，但是在产品脑暴的时候，团队的成员都提出了各自的见解与建议。例如，下图是我们在团队研发中讨论的内容。 [图片] 这里我们团队用的是产品是“语雀”，当然工具是随意的，用腾讯文档我觉得也非常方便，重要的是一定要形成电子版记录材料，如果只是在微信群里讨论或者线下简单聊聊，那讨论了、忘记了，那就相当低效，约等于没有讨论。 1.2 文档整理 第二步，整理脑暴的文档并撰写相关的研发文档，具体来说，包括但不限于： 需求文档 产品文档 模型文档 接口文档 [图片] PS. 这是我们团队的文档库，仅供参考：零熊 | 语雀 [图片] 2. 设计 设计工具我们用的 Sketch，但是不会把源文件直接发给研发同学，因为正版 Sketch 挺贵的，而且只支持 mac 系统。这里我们使用的工具是蓝湖，开始用的也是语雀的画板，但是发现实在是太难用了…另外，在蓝湖中的设计稿是可以分享的，并且邀请团队里的同学进行点评。 设计稿的内容具体包括： 规范 原型 UI 切图 规范重点是色彩规范、组件规范、和字体规范。原型更多的是交互说明，这里我们只是用批注的方式在 ui 上详细说明了一下交互，但如果直接用 flinto 去做也是可以的。flinto 的好处是更加直观，但是开发人员不一定能 get 到设计同学的全部内容。 [图片] 3. 开发 本部分分享的是产品研发的核心环节：项目开发。本环节我分享的内容会稍微多一些，但也略微零散，主要包含三个内容： 规划记录 开发工具 建议事项 3.1 规划记录 在开发之前，我习惯于自己先列一个 todolist 去罗列出项目中的各个需求点或技术点，从整体上会有一个直观的感受，也方便我去安排和规划自己的开发任务。这里我使用的工具是 Notion，我先按照重要的模块把产品分割成了 8 个部分，然后再在每个部分里写各自的 todolist，以免单文件 todolist 过长。 [图片] [图片] 当然，todolist 不单单记录待办事项而已，它更多的是承担一个开发日记的作用。我个人倾向于把开发中遇到的难点问题及解决方法，或者用到的资源顺手记录下来。我认为开发是一个学习和成长的过程，而不仅仅只是完成业务需求。 随手记录是方便日后整理为博客或者再遇到类似的问题可以快速定位，若不记录则很容易忘记。因此，做开发日记对学习的成效是非常大的。 [图片] 3.2 开发工具 针对微信小程序开发，我建议对开发很熟悉的同学可以尝试去使用 VS Code + 扩展 + 真机的模式进行开发，个人觉得这套流程既高效又不会出错。“高效”是 VS Code 自身的高效，而“出错”指的则是模拟器有时候效果与真机不同。 这里顺便安利一下我自己的 VS Code 配置： [图片] 我喜欢把资源管理器放在右边，有两个原因：一是左边是人的注意区，故应该放代码编辑器；二是我随时按 Cmd + B 可以隐藏资源管理器而同时不改变编辑器的位置，如果放左边，隐藏的时候编辑器会有一个位移，眼睛会很不舒服。 对于扩展，我这里用了几个比较有意思的： Color Highlight：颜色值高亮可视化为颜色本身，方便前端样式开发 TODO Highlight：高亮 TODO 与 FIXME miniapp：小程序标签与属性自动补全 Bracket Pair Colorizer：括号着色配对，这个特别方便。 Image preview：方便在代码里预览 uri 上的图片，我是用来看看自己资源路径有没有引错。 REST Client：HTTP 测试，方便开发、分享与 mock。 主题我用的是 Winter is Coming Theme + Material Icon Theme，我个人觉得黑色默认也非常好看。 3.3 注意事项 如果是协同开发我推荐搭配 Git History + Eslint 插件，当然如果自己开发，也免不了 Eslint。Git Commit 规范我们用的是这套： Commit 提交规范 [图片] 开发的时候也别忘记埋点，做一些打点统计，需要打点的地方根据项目需要检测的内容来定。如 PV、UV 这些小程序自带帮你统计了你可以不用打，但其他项目还是要统计的，或者直接规划好 Nginx 的日志，再对日志做分析也是 ok 的~ 如果前后端分离开发，前端同学可以自己接 mockjs 做一套符合接口文档规范的 mock 接口。 4. 维护 对于用户的反馈，我们智能筛选后自动提交到 github issue，再针对 issue 进行 label 和优先级分配。这是我们项目开源的主地址：oh-bear/2life。 [图片] 可以看到 issue 是比较杂乱的，所以还需要 github 的 project 去做一个任务画板。 [图片] by the way，安利一下小工具Devhub，可以很方便的检测自己负责项目的 issue。 [图片] 针对这些 issue，可以做一个阶段性的文档，回归到“立项”步骤，进行下一个小版本的开发。 [图片] 可以发现，我始终没有去选择使用甘特图软件，虽然甘特图更加直观，但是我不太喜欢把任务排的满满的、紧紧的，这样会不自觉地产生工作压力。最重要的是，我们毕竟不是工作嘛，只是一个兴趣开发，所以还是遵循自己的喜好来便好~ 好了，这次的分享就到这里。我是 Airing，我的个人博客是：https://me.ursb.me，欢迎大家来访交流~