共计 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 标梵互动