[图片] 首先，根据官网文档可以知道 只有非个人 的小程序才可以使用web-view组件，如果你的个人开发者，可以跳过这篇文章。 [图片] 一、使用web-view以及它的好处 1、己方账号（第三方）与小程序openId/UnionId的关联绑定，实现免登陆 比如你是某门户网站S，你要识别自己小程序上的用户与网站用户的关系，你可以通过三种方法绑定关系，公众号，小程序源生，小程序web-view内嵌跳转三种方法 2、内嵌H5的富文本，减少重复开发 比如你是门户网站，社区，以往有大量的新闻和帖子，里面带了各种css样式的富文本，小程序源生是无法直接读取的，需要大量转化，这时候直接内嵌这些H5新闻，大大降低开发成本 3、热更新，减少发布审核 某些需要经常更新的内容、公告、活动页，内嵌H5可以减少频繁提交小程序审核 二、小程序功能赋权 为H5提供各种小程序才有的功能，比如录音，扫一扫等。 注意事项 多场景判断，建议使用官方API： wx.miniProgram.getEnv H5唤醒一些小程序API有一定的延时，0.3~1秒 请调用小程序专用的JSSDK，同一个jssdk，但是webview的功能收到限制，和之前微信打开H5有所不同 小程序自动获取加载H5的title H5中iframe的url必须也是业务域名 web-view一定是撑满全屏的，自定义顶部菜单，悬浮的都没用 三、小程序和H5之前的互相通讯 1、 从小程序 ==>> h5 小程序控制H5，可以直接用src路径传参的形式，比如 [代码]<!-- 小程序端 HTML --> <web-view src="//URL?a=param1&b=param2"></web-view> [代码] 避免在链接中带有中文字符，在 iOS 中会有打开白屏的问题，建议加一下 encodeURIComponent。 2、 从 H5 ==>> 小程序 [图片] 这里我们知道bindmessage是小程序用来监听H5的推送的内容，但是这里不大不小的坑！就是它的三个出发场景： 小程序后退：使用接口名 wx.miniProgram.navigateTo，wx.miniProgram.navigateBack，wx.miniProgram.switchTab 等切换小程序页面/场景的API时候都会出发 分享：这个就是当你点分享小程序的时候，会接受到H5之前发送的postMessage 组件销毁，web-view组件销毁，类似 wx.miniProgram.redirectTo 都会触发。 [代码]<!-- 小程序端 HTML --> <web-view bindmessage="handleGetMessage" src="{{openUrl}}"></web-view> [代码] [代码]// 小程序端 JS --> Page({ /** * 页面的初始数据 */ data: { openUrl: "", }, /** * 获取请求数据 */ handleGetMessage: function (e) { console.log(e.detail.data); } }, }) [代码] [代码]<!-- h5端 HTML和JS --> <script type="text/javascript" src="https://res.wx.qq.com/open/js/jweixin-1.3.2.js"></script> <script> wx.miniProgram.postMessage({ data: { link: "//test.com", title: "一起学习，一起进步" } }); //wx.miniProgram.redirectTo({ // url:"/pages/inner/index?source=123" //}) wx.miniProgram.navigateBack({delta: 1}) </script> [代码] 注意事项 那些H5控制小程序的跳转路径必须是“/”开头，如 “/pages/xxx/xxx”，且路径必须在app.json里有，地址错误的话，有时不报错。 postMessage的json必须是data开始，不然接收不到数据。 [图片] 四、bindmessage接收到消息有3个重要特性(重点) 接收可以是H5之前几分钟前发送postMessage，不一定是即刻发出的。 之前发出的 postMessage的DATA信息会累加，当触发bindmessage接收的时候是一个数组。 [图片] 当bindmessage 再次 接收到数据，之前发送的数据不会被清空，将累加一起返回，获取时要判断好数组的角标 [图片] 五、Tips 1、在IDE工具中如何调试H5 [图片] 可以在 web-view 组件上通过右键 - 调试，打开 web-view 组件的调试。 2、内嵌H5缓存问题 web-view加载的H5具有很重的缓存，如果需要调试，可以通过在url后面加时间戳的方式解决。 3、小程序关闭，H5背景音乐仍然在播放问题 小程序已经关闭，但是H5自带的背景音乐仍然在手机后台播放的问题。这里可以利用一个属性： visibilitychange：页面可见性状态 简单的说，浏览器标签页被隐藏或显示的时候会触发visibilitychange事件。 [代码]var statusBeforeHide = true; //初始化页面的状态 var music = document.getElementById("xxx"); // 更改音乐播放状态 function setChangeMusic() { if (document[hiddenProperty]) { // 页面隐藏 if (statusBeforeHide) { music.pause(); // 暂停 } } else { // 页面显示 if (statusBeforeHide) { music.play() //如果statusBeforeHide是true, 继续播放 } } } let hiddenProperty = ('hidden' in document) ? 'hidden' : ('webkitHidden' in document) ? 'webkitHidden' : ('mozHidden' in document) ? 'mozHidden' : null; if (hiddenProperty) { let visibilityChangeEvent = hiddenProperty.replace(/hidden/i, 'visibilitychange'); let onVisibilityChange = () => { //console.log('visibilityChange'); setChangeMusic(); }; document.addEventListener(visibilityChangeEvent, onVisibilityChange); } else { console.log("不支持这个api"); } [代码] 总结，web-view还是非常实用的组件，且用且珍惜~ 往期回顾： 小程序自定义头部导航栏“完美”解决方案 小程序Canvas生成海报（一） 小程序新版订阅消息+云开发实战与跳坑

开篇 我第一次接触小程序时，还清楚的记得是在2017年的春节期间。当我升级最新版的微信后，开始摸索着新的功能变化。在发现页有一个叫小程序的入口，点进去有一列的“应用”。当我打开一个叫“亲戚关系计算器”的小程序后，简单的使用，然后退出，再去寻找其他的小程序，猫眼电影，自选股，滴滴出行…… 当我尝试着去探索更多小程序的过程中，我突然发现，微信正在发展为一个超级的应用流量入口。而微信中的小程序也可以轻松的坐拥10亿的可用用户人群。 那时候过年，我做的唯一一件事情就是细细的读了小程序的开发文档，心想他可以具有多大的活力与动力，能够引发多大的改变。而我能不能适应他，去随着他的发展，带动自己的腾飞。 很遗憾，当时的小程序并不对个人开发者开放，没有办法注册一个小程序，只能在开发者工具上写一些小的应用，去熟悉小程序的开发。 3月27日，小程序重要更新，其中之一就是支持个人开发者注册小程序。那时候的我，在学校上大一，用一个运营公众号的微信号注册了第一个小程序，并做了一些实验性的开发，并上线。 从这个过程中，我开始细细的体会小程序的优势以及不足，小程序适用于那些领域，小程序适合怎么推广。小程序适合那些行业领域的应用。现在看来，其实从小程序提供的能力，就可以依稀端详出小程序所致力的场景与应用领域。 2018年1月，在我历经半年多的思考和衡量下，做出第一款真正属于自己的小程序——GS比赛计分。去尝试探索线上小程序和线下场景的交融，在这过程中有顾虑，有大胆创新，但都为我更深层次理解小程序有很大的帮助。 目前，自己已经做过10余款小程序，除了GS比赛计分开发时间很长，其他的小程序都是一个月左右的时间完工。比如2019年2月的高校课程助手；2019年3月的数据查询助手；2019年4月的数据汇总助手。 我接下来会从小程序的需求分析与应用设计，小程序的开发，小程序的运营3篇来讲述我对于微信小程序的独自见解与经验。希望能为更多的学生开发者有所启发和借鉴。 需求分析与应用设计 要清楚的认识到小程序对自己需求的最大赋能，需要从最初去理解小程序的定位，微信团队对于小程序的定义是这样的： 微信小程序是一种全新的连接用户与服务的方式，它可以在微信内被便捷地获取和传播，同时具有出色的使用体验。 通过对小程序提供能力的分析，不难看出。小程序相对于APP来说，在降低开发门槛的同时能够满足最普遍的应用需求，适合生活服务类线下商铺以及非刚需低频应用领域。使得微信通过小程序作为生态的建立者和维护者，赋能商家和应用者。以一种生态触角的状态来迅速的捕捉最大化生态红利。 当清楚的理解小程序的定位后，那么就需要合理的筛选需求并进行应用的功能设计。我将会使用【GS比赛计分】作为例子进行分析说明。 1.用实质的问题引出明确需求，并确定解决问题的功能边界 首先思考的是，自己需要做的功能都有哪些，使用人群是谁？使用场景是什么？需要数据的实时性吗？ 一开始设计【GS比赛计分】的时候，目的是为了解决现在的中小型比赛使用人工计分的失效性差，出错率高，人工和时间成本昂贵的问题。程序的目的是将比赛计分的相关人员用互联网工具联系起来，以提升计分效率。 [图片] 当明晰了产品目标后，开始考虑使用人群。一般来看，大多数的比赛计分都是由两种角色构成的，一个是评委（分数确定者），另一个是工作人员（分数汇总者）。 传统的计分过程是通过现场工作人员将评委的分数以纸质的形式送达计分人员。在这一过程中就有大量的成本浪费了（一个是人力成本，另一个是时间成本）。另外，计分人员以Excel或计算器和笔记的形式进行比分汇总，在这一过程中又存在大量的成本浪费（人力成本和时间成本甚至还有错误风险）。 [图片] 所以横观所有的主观评分的线下比赛，无一例外都存在比赛结束后有长时间的节目或视频热场环节，其实这都是在为人工计分的缓慢争取时间。 所以，【GS比赛计分】的使用人群和使用场景就确定下来了，与传统人工计分的过程类似，只不过需要互联网赋能，解决时间和人力成本。需要数据的实时交互。 【GS比赛计分】作为解决现象问题的工具，首先需要做的就是不要违背现象中事件的发生次序。所以功能完全参照比赛计分过程来设计。具体功能如下，提交成绩，撤回成绩，弃权处理，实时的选手分数，实时的选手名次，清楚评委数据，解绑评委，重启比赛，结束比赛，比赛内置会话。 2.对程序平台进行横向比对，明确小程序的优势和劣势 当程序的功能确定好后，不要着急着手界面设计，功能模块的组合，交互设计这些过程。当你在进行这些过程之前，需要认真的去考虑你的应用是不是适合在小程序上开发。 小程序的火爆，注定有许多人盲目的进入这一领域，但不是所有的应用都适合小程序的推广模式，也不是所有应用都能吃得起小程序的运行效率的。所以在确定开发小程序之前，正确的认识的合适与不合适，避免让自己的成本白白的付出。 如何确定适不适合用小程序来做呢？我们可以让小程序作为一个互联网平台，把应用带入到互联网的每一个平台中去，进行横向的对比，去找出各自的优点与不足，当做出客观的判断后，应用在小程序上相比于其他平台有没有优势就很明显了。 还是以【GS比赛计分】举例。我所横向对比平台包括PC、原生APP、Web平台、轻应用、小程序。首先从满足功能来说，比赛计分需要很稳定的实时性，所以我将Web平台排除（因为复杂的比赛环境，不同的设备浏览器难免会有问题）。 然后将剩下的平台做分析。PC平台使用可能性太小（原因：比赛现场成本太高昂，租借笔记本可能都不是现实的）；原生APP不适合（原因：评委评分前需要下载APP，比赛结束后没什么用了，需要把这个APP卸载。而且IOS和安卓两大平台增加了研发成本）；轻应用有阻碍（原因：百度轻应用由于装机量小，覆盖人群不多。支付宝小程序没有社交关系链，无法有效的推送给需要的人。产业联盟轻应用，苹果用户怎么考虑？） [图片] 经过一系列的对比，很明显。对于【GS比赛计分】来讲，微信小程序是最好的应用平台。同时微信小程序仍然可以和不同的平台进行联系，所以可扩展性，功能延展性都是最佳的。 3.应用设计要满足即用即走的理念 当确定小程序是最理想的应用平台时，我们需要对小程序进行便利化的设计。这就需要抛弃一部分原生应用开发或Web开发的一些设计理念。追求“极致、简约”的风格设计。 在【GS比赛计分】的详细设计时，我考虑到，以个人账户的形式去下发比赛的流程是行不通的，既然服务于比赛，那么就以比赛为最基本的账户组成单元，明确一个比赛ID。而同一个比赛的不同角色，以不同的IK进行区别，而角色的设置包含在比赛设计中，由比赛创建者在创建比赛时自行创建。 那么小程序的使用场景就出来了。以比赛现场的告知或者微信聊天的分享，告知比赛参与角色其ID和IK，就可以让角色快速的进入绑定角色并使用程序。免去注册的一系列烦恼。 同时在微信用户面前，这个账户体系是平权的，任何用户在得知ID和IK的情况下都可以进入（账户绑定情况下不可以进入），一定程度上免除密码和忘记密码，注销账户这一系列的麻烦。 当完成比赛后，程序已经完成了自己所有的任务时，使用者可以直接退出程序，不需要注销比赛等操作。真正做到即走。 在使用过程中，要清楚的考虑用户的使用过程，从而做一些保险机制。微信小程序运行在微信上，微信是社交工具，就免不了用户会退出小程序甚至微信去做一些其他的事情。所以【GS比赛计分】在设计时要保证用户回来要用到自己想要的，在程序设计中有中间状态界面能够保证用户可以迅速进入使用状态。 4.对于很大的系统，要把最适合小程序部分拿出来，而不是全部 现在的【GS比赛计分】其实是一个大的生态系统，结合有线下的网络接口，展示接口，线上小程序，web平台。每一个部分都承载着自己独特的应用价值。 比如Web平台就承载比赛管理的任务，创建比赛，上传比赛文件，选手图片，设置选手（名称、介绍、手机号、图片、出场顺序），设置评分项（名称、权值、预置分数），设置评委（名称、权值，IK）。从实际的分析来看，比赛管理最适合在PC端进行，不管是文件还是图片，公认都是PC上传比较容易。 在最初设计的时候，我错误的把系统分成了多个小程序进行系统搭建，在实际使用过程中造成了重大的缺陷和用户流失。最大的表现是，我开发了【GS比赛创建】小程序，作为比赛的入口程序。从而造成比赛数量增速缓慢，大的使用场景无法突破，老用户意见上升等一系列问题。不得不注销了【GS比赛创建】小程序，并进行很大的架构调整。【GS比赛计分】暂停使用，造成大量的用户流失。 [图片] 所以，当设计多场景，前后联动性很强的应用时，需要将功能进行使用划分，每一个划分需要找最适合的平台。最适合小程序的部分，就做好与其他平台的无缝结合。 5.小程序的应用场景和机会 目前来看，小程序的应用场景主要包括支付场景，比如扫码支付、快消餐饮、移动购物、交通出行等等，工具类小程序能更碎片化、垂直化地满足细分的应用场景需求。 根据微信的最近更新变化来看，公众号和小程序的协同作用将越发明显，公众号的作用也将进一步放大，因此未来发展的机会可能在这几方面。 内容营销，小程序能通过更完善更精准的服务进而提高用户黏性。具体来看包括各大知识付费的小程序以及在教育风口上的小程序。当然，这些小程序也可同时开发APP（按微信对小程序的开发步骤来看）从而实现用户沉淀。 具有支付场景的各类商家。包括传统的已有一定客户群的商家提供更方便的服务或者实现线上线下联动以及新零售。 工具类小程序。包括共享经济领域，这类小程序即用即走，轻量化，便捷化。 天生具有社交属性的小程序。比如抽奖、互赠礼品、拼团减价、社交性的小游戏以及帮拿快递等。 小程序的开发经验 1. 微信小程序开发文档是最好的学习文档 很多同学喜欢看视频教程，或者买一本小程序开发书来学习。觉得这么学会加深理解更加容易上手，而官方文档干巴巴不好学。现在的微信小程序能力更新速度很快，当一个教程或书出来的时候，其实已经过时了。建议同学去微信公开课中学习微信小程序的入门教程，开发入门后，根据自己的开发需要，自行阅读官方文档来学习。 [图片] 2. 必须了解小程序的运行原理 微信小程序是运行在微信中的，所以运行速度并不能和原生媲美。但是在开发小程序的过程中，可以用良好的编程思路来追求程序的高效运行水平。但前提是，你需要对小程序的运行环境有所理解，需要知道在开发环境和真实环境（IOS和Android）下的运行差别。大部分的开发坑都是因为不同运行环境造成的。 官方的声明：微信小程序运行在三端：iOS、Android 和 用于调试的开发者工具；在 iOS 上，小程序的 javascript代码是运行在JavaScriptCore中；在Android上，小程序的javascript代码是通过 X5 内核来解析；在开发工具上，小程序的javascript代码是运行在nwjs（chrome内核）中。 微信小程序的运行环境类似 ReactNative ，而不是纯 Html5。两者最大的不同在于，ReactNative 的界面是由原生控件渲染出来的，而 Html5 的界面是由浏览器内核渲染出来的。两者在性能上有较大的差异，从而表现出来微信小程序要比h5页面好很多。 3.安利小程序云开发 云开发为开发者提供完整的云端支持，弱化后端和运维概念，无需搭建服务器，使用平台提供的 API 进行核心业务开发，即可实现快速上线和迭代，同时这一能力，同开发者已经使用的云服务相互兼容，并不互斥。目前提供三大基础能力支持： 云函数：在云端运行的代码，微信私有协议天然鉴权，开发者只需编写自身业务逻辑代码 数据库：一个既可在小程序前端操作，也能在云函数中读写的 JSON 数据库 存储：在小程序前端直接上传/下载云端文件，在云开发控制台可视化管理 云开发使得小程序开发门槛进一步降低，甚至偏前端的开发人员也可以独立开发小程序了。另外，云开发中云函数支持去请求第三方服务接口。所以云开发最大程度上提供了小程序所需基本API的构建，另外可以通过第三方服务请求能力扩展API能力。 [图片] 而且云开发的数据库和存储完全可以与云函数构建一个小型的后端平台。并发能力中等，适合大部分的小程序业务API的构建。 4. 养成良好的小程序代码习惯 微信小程序的代码文件分为4种，WXML、WXSS、JS、JSON。 JSON文件是小程序的配置文件，APP.JSON是小程序全局配置，另外每个页面也会有配置文件。建议页面中的JSON文件只填写页面需要配置的（比如页面标题），而不变化的不要写到里面（比如标题风格，背景颜色等等）。 JS主要是javascript语法，建议以模块的形式对通用的方法进行封装，尽可能的利用好代码，不要有大量重复的方法语句。如果多个页面需要，可以单独建立js文件，在需要的页面进行引入。 WXSS是样式文件，遵从css的编写规则，尽可能的少些样式表，多多利用已经写过的样式，如果多个页面需要，可以单独建立wxss或者写到app.wxss中 WXML是页面结构文件。如果多个页面中有相同的结构，可以单独封装为模块，而模块中的逻辑方面也尽可能遵从代码最大效益化。 总之，开发代码简洁，会使得编译后的小程序包很小，使加载速度更加快速。 5. 小程序填坑总结： 首先，微信开发者社区是好的小程序开发交流平台，从中可以获得大多数问题的解决方法： https://developers.weixin.qq.com/community/develop/question 另外，许多人常用搜索引擎来直接搜索问题的解决方法，一般大部分的错误或者问题都会在开发文档上写的很清楚，只不过很少有人去注意到，推荐几个小程序填坑的集合文章： https://blog.csdn.net/weixin_42448956/article/details/82414225 https://www.cnblogs.com/shaoting/p/6051261.html https://www.imooc.com/article/36148 https://www.cnblogs.com/wangking/p/6946438.html https://www.jianshu.com/p/4362e52f5c49 小程序的运营 小程序运营属于软件产品运营的一种类别。从产品生命期来看，小程序运营分别为研发期、种子期、成长期、成熟期、衰退期。另外由于小程序在运行模式和定位的不同，表现在推广形式上与平常的软件产品有很大的差别。接下来，我会用【GS比赛计分】【数据查询助手】小程序为例子佐证分享小程序的运营经验。 1. 小程序研发期，搞清楚产品的定位以及目标用户 当你不是运营小程序的产品策划者，你需要首先要搞清楚产品的定位以及目标用户。（这也是多数互联网公司将产品策划和运营作为一个岗位的原因）。在整个产品的研发期，需要跟进产品的每一个细微功能点，要明晰产品的使用用户；还要时刻去观察产品的领域有没有竞品的出现，用户习惯有什么改变；要时刻去衡量产品的竞争优势，为之后的发布运营做好准备。 【数据查询助手】是提供自定义信息查询服务的小程序。任何微信用户均可以上传自定义的数据（报表，成绩单等任何表格数据）建立查询。 [图片] 当在产品研发的一个月，我不断的探索小程序领域，APP领域，Web领域有没有相同的功能产品或服务。甚至将问卷系统（腾讯问卷、问卷星、问卷网）作为潜在的竞争对手。 另外我还制作了web版和原生APP的Demo去体验他们与小程序体验的不同。去确定微信小程序是很好的适应平台。从而为之后的运营做足了准备，提升了自己的信心。 2. 小程序种子期，要充分利用体验版过程 小程序体验版相当于其他应用平台的内测版。体验版可以更高层次的模仿真实的用户环境。在这一阶段更容易发现用户间连接要求高的应用缺陷。同时可以在安全的范围内去聆听用户的真是使用反馈。 【GS比赛计分】开展了长达1个月的体验版。邀请了20个核心用户去体验。由于应用需要与服务端建立实时连接。用户不同的设备，不同网络环境对程序的稳定性做出了很大的考验。在这一阶段修复了不少场景不同导致的错误或者效率低下问题。 另外一开始推出的小程序界面设计只遵从了功能设计，没有很好的考虑真实的使用场景。所以在这一阶段，我最大程度上听取体验用户的建议，对整个界面进行改版，使交互更加的亲近用户。 3. 小程序成长期，明晰获取用户的手段和推广手段，最大化的成长： 当小程序功能稳定后，到了成长阶段，用户使用是最核心的任务。获取用户的时候，必须先让对方了解自己的产品，建立认知，将产品介绍给用户，让用户进入小程序之后，想方设法让产品与用户产生交互，让用户不断体验产品，让活动始终覆盖用户，让用户对产品认可，要完成产品与用户的关系构建。 从现在许多小程序的运营手段来看，基本上都围绕着社交裂变和线下推广的方式来提升小程序的获客表现。而小程序由于较低的开发成本，较快的更新速度，以及较低的试错成本，使得多数很强势的小程序都采用功能矩阵发展模式，快速实现功能及迭代。 小程序获取用户的手段主要由下： 朋友圈分享（包括图片二维码、广告直接进入）； 聊天好友推荐转发； 线下二维码（包含商家推广、广告推广）； 微信搜索（一般由其他社交平台或者用户需求引起）； 线上识别二维码（线上推广，文章推广，或其他社交平台的推广）； 其他小程序的跳转（互相推荐） 公众号跳转（公众号运营推广） APP跳转（一般是APP延展的简洁功能推广，或者轻量级触达用户形式的推广） 小程序发掘社交推广的手段主要由下： 社交立减金，实现社交裂变； 社交比拼玩法，引导社交裂变； 互动加入分享按钮，提醒用户转发； 设计同伴环境，鼓励社群传播； 设计任务玩法，领取奖励； 设计福利，鼓励好友助力； 聚焦核心功能，促进口碑传播； 【数据查询助手】从产品定位上就自带社交裂变的元素，当查询创建者创建了一个查询后，他可以根据要分享的人群情况选择多种分享方法。如果是企业微信或者微信工作群，那么可以直接分享小程序到聊天窗口。其他的用户可以直接进入小程序进行查询。如果是线下的查询（推广会，现场发布等），可以通过小程序二维码的方式进入查询界面查询。对于其他社交平台来讲，可以用二维码来做分享，如果是常用用户（添加到我饿小程序或者桌面作为常用工具的用户），可以直接通过复制文字（含查询码）然后进入应用的方式快速开始查询。 同时每一个查询者，都可能是潜在的查询创建者和程序推广者。所以要在这一阶段不断的优化体验流程，尽可能做更多事情覆盖多场景的查询（比如微信搜一搜直接搜索查询码，直接查询），去吸引用户，留住用户。 由于小程序用完即走的理念，导致许多工具类小程序（不含深度融合线下和社交的）用户的留存普遍较低。既然工具类就是服务用户，那么就把小程序慢慢的做成一种用户习惯，从习惯的养成变为行业应用的转化。从转化中寻找切入点，进而挖掘可以创造价值的功能产品。 所以，做小程序不要过分贪图大规模的使用率，大批量的用户。他本身是一种服务理念的触达和养成，你需要在用户心里养成使用习惯，而不要上来糖衣炮弹把用户打蒙，甚至反感。这样小程序的生态就被搞乱了。 4. 小程序成熟期，稳定期最重要的就是小版本的迭代更新： 刚才讲到，小程序有较低的开发成本，较快的更新速度，以及较低的试错成本。所以在小程序成熟期需要根据用户数据不断的去更正调整功能，去保持较高的运营分数。在产品功能中，适时的进行用户付费转化。 付费转化一方面可以拉开用户层次，对小程序的用户是一种活水作用，提升用户的使用粘性，容易过滤最核心的用户，提供更加好的产品服务。如果在成长期很好的进行用户习惯的养成，这个过程会更加自然。反之，应用将会更快的进入衰退期。 付费转化的方式主要由几类： 电商类：主要靠活动、优惠刺激（现实抢购、秒杀、预约、限时满减、显示商品库存和抢购人数）； 游戏类：游戏道具（向朋友求助、每日签到、社区活动等方式免费获得，但数量有限，且都是一些级别较低的道具）高价值道具付费、皮肤售卖、游戏币购买； 内容类：付费文章、阅读币购买、付费课程； 5.小程序衰退期：适时舍弃，进行新产品开始推出 小程序开发周期短，很多时候应用分析不够透彻，更多的是一些商业或推广试错。导致许多小程序还没有进入成长期就进入晚期了。这一类小程序直接舍弃就好，不需要什么转化了，这也不算小程序的衰退期（没有盛何来衰）。 对于经历过成熟期的产品主要有几个原因导致进入衰退期： 市场中有新的创新型产品，导致冲击衰退。 自身功能设计有缺陷，导致用户流失。 对用户了解不透彻，付费转化失败，用户迁移到同类产品。 产品质量下降，不能适应用户行为的变化。 由于运营组织的原因，产品运营出现危机。 在这一阶段，运营已经无能为力。那么就进行产品的复盘，积极的去投入到新产品或者新领域的探究上面去。小程序的开发成本较低，所以可以有很多机会去重新塑造一个好的产品。 6.总结，谈谈自己的想法： 现在多种多样的互联网产品不断产生，产品竞争异常激烈。互联网产品的运营手段也是推陈出新，花样繁多。在这里我不给大家分享一些运营花样，因为每个小程序都是独特的，应该有自己独特的运营手段，具体是什么，希望产品者和运营者本身用热爱小程序的心去发现和实践。 永远保持对产品的尊重，对用户的尊敬是每个产品人最重要的事情。如果对应用足够热爱，你会厌恶他被污染，他被别人嫌弃；你会尽自己的可能让他变得更加本真，你会合理的去运营突破，去帮助产品走向更高的位置。 如果你没有爱你的产品，再出色的产品也只是昙花一现而已，并不能给你带来任何长远的意义。 这是最好的小程序运营指南：https://developers.weixin.qq.com/miniprogram/product。 [图片]

双生日记开发经验分享 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，欢迎大家来访交流~