共计 4153 个字符，预计需要花费 11 分钟才能阅读完成。
对于一个产品来说，分享的重要性显而易见。
前言
小程序的顶部有一个胶囊按钮，点击第一个按钮便会在屏幕下方弹出菜单列表，其中变蕴含了分享相干的操作，如下图所示：
null
当咱们创立一个小程序工程之后运行，进行如上操作之后会发现，此时底部菜单中的分享性能是被禁用的。
一、启用分享性能
旁边的扫地大爷微笑道：小朋友，这问题好解决，只有传递给 Page 的 Object 对象中提供了 onShareAppMessage 办法，那么运行以后页面便可点击右上角菜单按钮进行分享，并且如果要反对分享到朋友圈的话，只须要提供 onShareTimeline 办法即可！
Page({
// 定义此办法之后，点击右上角按钮弹出的菜单中 "发送给敌人" 菜单变为可点击
onShareAppMessage: function (param) { },
// 定义此办法之后，点击右上角按钮弹出的菜单中 "分享到朋友圈" 按钮变为可点击
onShareTimeline:function(){}})
这问题的确很简略，连扫地的大爷都会，不过说的对也不全对，但总感觉这大爷深藏不露，得好生招呼。
“哇塞，大爷您真棒，一看您就是深藏功与名，您能多说一点分享性能方面的吗？”
“小伙子，看你人不错，挺好学的，大爷我就多跟你唠嗑几句。”
1、发送给敌人（分享）
官网材料[1]
只有定义了 onShareAppMessage 处理函数，右上角菜单才会显示“转发（发送给敌人）”按钮
该函数接管一个 Object 对象参数, 对于参数字段的介绍如下表：字段名 | 类型 | 阐明 | |——|————|————| | from | String | 转发事件起源。button：页面内转发按钮；menu：右上角转发菜单 | | target | Object | 如果 from 值是 button，则 target 是触发这次转发事件的 button，否则为 undefined | | webViewUrl | String | 面中蕴含 web-view 组件时，返回以后 web-view 的 url |
从 from 和 target 两个字段中咱们能够看到，除了通过右上角胶囊菜单入口处进行分享外，咱们还能够通过页面内的 button 进行分享操作。
能够通过该事件处理函数返回一个对象，用于形容自定义的分享内容，从根底库 2.8.1 版本开始，分享图片反对云图片；
对于返回的对象介绍如下表 字段名 | 阐明 | 默认值 | |——|————|————| | title | 转发题目 | 以后小程序名称 | | path | 转发门路 | 以后页面 path，必须是以 / 结尾的残缺门路 | | imageUrl | 自定义图片门路，能够是本地文件门路、代码包文件门路或者网络图片门路。反对 PNG 及 JPG。显示图片长宽比是 5:4。| 应用默认截图 |
以下示例代码自定义了分享内容的题目和点击之后关上的门路：
`Page({
onShareAppMessage: function (res) {
if (res.from === 'button') {
// 来自页面内转发按钮
console.log(res.target)
}
return {
title: '自定义分享题目',
path: '/page/user?id=123'
}}
})`
运行截图：
null
其中红色框为指定的自定义题目，蓝色框封面图因为咱们没有指定分享的图片门路，因而会依据以后界面进行截图作为分享内容的封面图。
对于默认截图: 不自定义转发图片的状况下，默认会取以后页面，从顶部开始，高度为 80% 屏幕宽度的图像作为转发图片。
2、分享到朋友圈
官网材料[2]
只有定义了 onShareTimeline 处理函数，右上角菜单才会显示“分享到朋友圈”按钮
根底库 2.11.3 开始反对；Beta 版本，暂只在 Android 平台反对;
留神：如果要反对分享到朋友圈，则必须同时提供 onShareAppMessage 事件处理函数的定义，否则此性能有效。
能够通过该事件处理函数返回一个对象，用于形容自定义的分享内容，不反对自定义页面门路，返回内容如下: 字段名 | 阐明 | 默认值 | |——|————|————| | title | 转发题目 | 以后小程序名称 | | query | 自定义页面门路中携带的参数，如 path?a=1&b=2 的“?”前面局部 | 以后页面门路携带的参数 | | imageUrl | 自定义图片门路，能够是本地文件或者网络图片。反对 PNG 及 JPG，显示图片长宽比是 1:1。| 默认应用小程序 Logo |
3、页面内分享
官网介绍[3]
根底库 1.2.0 开始反对, 通过给 button 组件设置属性 open-type=”share”，能够在用户点击按钮后触发 Page.onShareAppMessage 事件获取自定义分享内容进行转发。
示例代码：
//index.wxml
<button open-type=”share”> 点击进行分享 </button>
留神：
•只能应用 button 组件，而不能是其余组件。
•经测试在 Page 中未提供 onShareAppMessage 事件也能执行页面内转发。
•只反对分享敌人而不容许分享到朋友圈
装逼常识补充：小游戏是没有页面的概念的，所以分享的时候大多是分享不同的 query 参数而非门路地址。
二、动静分享
后面应用分享的形式比拟固化，也就是要嘛在页面中定义好分享事件处理办法，要嘛通过指定的按钮实现指定的分享行为，无奈更灵便的解决一些场景；比方如下场景：
1、某个界面 A 用户能够分享给敌人，B 用户能够分享给敌人和分享到朋友圈
2、用户须要达到肯定条件之后才可启用分享特定内容（比方与用户推广业绩挂勾的分享内容，比方用户达到条件之后，以后界面分享进来的内容就是以后用户绑定的分享海报，通过海报增长的用户会给对应的用户减少业绩，而如果用户没有达到条件时，只是分享进来的是一般内容或者是不能分享）
3、分享动静内容：官网地址[4]
当然，以上场景为杜撰，只是想表白分享的灵活性的需要，那么如果真的有上述需要，有没有方法能够实现呢？
答案是有的，只是我没摸透，理论运行后果与我所猜想的后果产生了一致，并且模拟器上运行的成果与真机预览的成果也产生了差别，因而不敢妄自推测这部分内容，所以只是做个记录，待前面进一步了解，如果有对这一部分理解的敌人，也心愿不吝赐教。
API 官网地址[5]
三、分享内容的图片解决方案探索
咱们先看一下之前我那个界面的分享内容：
null
这是一个没有灵魂的分享，封面是整个分享内容的灵魂所在，分享内容在没有设置自定义图片门路时，会采纳页面的默认截图作为封面，所以咱们页面内容的难看与否，间接影响最终的默认截图成果，然而即使以后的界面设计的再难看，作为分享内容的封面图也不肯定失当。
官网反对将分享图片设置成网路图片地址，那么这一问题在某些层面上来讲也失去了很好的解决，然而是提供固定的云端图片地址，还是提供专门用于分享封面的云端服务，亦或者其余计划，毕竟每一种封面图计划都有其存在价值。
当初看来对于分享的图片起源就两个路径，要嘛小程序外部解决，要嘛通过服务端提供分享的图片起源；
1、本地计划
即不依赖服务器解决分享内容封面图问题；
•默认截图计划 即分享时不提供自定义图片地址，默认会取以后页面，从顶部开始，高度为 80% 屏幕宽度的图像作为转发图片。此计划的弊病因为是依据页面内容进行生成，无奈进行定制化，比拟适宜对分享没什么要求或者页面内容比拟合乎分享的内容场景。
•本地图片计划 即应用本地文件门路、代码包文件门路作为分享的图片地址，此办法的弊病在于无奈动静更新，只能提供无限的分享图片资源，并且还会减少小程序体积。对于分享场景比拟固化的自定义图片场景比拟适宜。
•本地动静生成分享图的计划 即本地生成所须要的分享图片进行分享，也就是应用 canvas 绘图并生成所需分享的图片，此计划可能解决内容动静展现的问题，毛病就是技术要求高一些，并且也要解决生成的模板多样性问题，不过此计划可能应答绝大部分场景，所以重点在于钻研这个计划。
2、云端计划
•云端固定图片地址 即服务器提供分享所需图片内容地址，此计划相比于本地图片计划来讲更为灵便，能够更新分享的图片源从而提供分享时更多的款式。但此计划的毛病就是无奈对内容进行动静生成，即后端提供的是固定图片地址，此计划比拟适宜固化分享场景，又稍微会进行图片更新的场景，比方中秋节提供的是与中秋节主题相干的图片地址，春节提供的是春节相干的图片地址，而如果是小程序本地图片计划的话，要实现此成果就必须进行降级。
•云端动静内容反对 即后端动静生成所需内容返回给前端应用，此计划实践上是可行的，毕竟有条件的公司齐全能够创立独立的多媒体库反对，然而对服务端的开发人员和服务器的要求都颇高。
四、动静分享内容生成解决方案
在找这方面的轮子的时候，找到如下一些计划（具体还未进一步钻研，整顿本文内容已消耗很多工夫）：
1、wxml-to-canvas
此方按是官网提供的计划（官网介绍[6]）
小程序内通过动态模板和款式绘制 canvas，导出图片，可用于生成分享图等场景。
反对 view、text、image 三种标签，通过 class 匹配 style 对象中的款式。
尽管有人诟病说此计划反对的标签品种太少，然而其实对于一个分享图来说，组成的元素不外乎就是文本和图片，所以实践上此计划已足够应答大部分场景。至于是否有其余什么坑，还未探，不敢瞎说，后续会专门钻研。
2、开源计划 Painter
Github[7]
因为挂载在 github page 上，关上速度会慢一些，请急躁期待或自行解决 git 网速问题。
如果厌弃关上太慢，能够先查看下微信小程序社区外面的介绍地址[8]
据说还有基于此计划的可视化海报生成计划; 介绍地址[9], 至于好用不好用，我还未体验过。
社区有人介绍了用此计划实现的案例，想要学习的能够参考一下; 链接地址[10]。
3、第三方服务 - 快海报
切实懒得折腾的，花点钱应用第三方服务即可，据说不贵，比本人搭建服务器来的划算。附上官网地址，自行理解[11]
以上三种计划是目前关注的计划，其实计划到底是怎么实现的我目前还不分明，鉴于曾经花去比拟多的工夫做这方面的理解，目前只想先尽快完结目前阶段，调整一下，后续进一步做深入研究。
文章编辑:Biaofun 标梵互动