前言
社交分享作为移动APP传播途径之一, 其重要性不言而喻, 那么在众多分享形式中 图片的分享转化可以说是名列前茅, 用户不需要打开不需要点击, 眼睛一扫即可获取到上面的信息, 可以轻易达到很高的展现率, 嗯 分享的重要性我就不说了, 网上一搜一大把, 下面准备进入正题.
在开始之前, 我要说明一下 为什么分享图要做到动态可配置, 举个场景, 比如每逢佳节 运营和产品团队需要产品可以体现节日气氛, 从而提升用户体验和好感, 那么就需要精心准备各式各样对应节日气氛的设计, 比如APP整体UI视觉的变化, 当然社交分享也在其中, 难道每一次新的设计变动都要客户端重新发版?? NO! 客户端发版的代价可想而知, 开发成本, 更新率... 无一不是问题, 那么可以让用户在不更新的情况下可以做到变化 就是动态存在的意义, 这里先不说换肤这些 (换肤感兴趣可以看一下我的LEETheme), 只谈分享图.
其实要做到动态可配的分享图方案有很多种, 但都各有利弊, 我这里主要讲解我个人认为最优的一种解决方案, 其他方案会在文章结尾简单概述.
需求场景
一个邀请好友的分享图片, 图片中包含了我的邀请码, 下载的二维码 (二维码链接中带有我的ID用于识别埋点等操作), 我的头像昵称, 我在这个APP里做了些啥 为啥要邀请你来等类似这样与业务相关的信息.
再丧心病狂一点, 产品: "我们加个AB测试吧, 这个分享我要随时可以加几种新样式, 看看用户们更喜欢那种样式." 程序员: "#$@%#^#@#!@.. 好的".
需求分析
首先可以确定 点击分享时需要生成一张图片, 图片上要添加很多元素, 最后分享出去.
从"几种新样式" 可以看出这个分享的图片是多种样式的, "随时添加新的"则需要做动态配置的分享, 而"AB测试" 就需要控制这个用户应该用哪种样式的分享图 具体如何的分配规则是需要控制的.
综上我们可以得出几个重点:
- 多样式分享图
- 可动态调整样式
- 可控制单用户样式
控制方面肯定是要服务端来做, 那么客户端就需要请求接口来询问服务端应该使用哪种样式? 由于不同样式可能显示的信息内容也不同, 所以服务端既要控制哪一种样式, 又要控制某个样式上的内容, 这样才能符合需求.
最优方案
核心思想
静态动态资源分离, 避免多余请求.
通过分离优化数据传输, 再次合并组装获取最终样式->截图->分享.
减少请求数量, 避免截图时由于某些请求出现问题.
定义
静态资源:
- HTML模板代码
- JS/CSS代码
- 图片 (例如背景图或其他该样式的固定元素)
动态资源:
- 分享的信息 (例如 用户相关的信息, 或者业务相关信息)
- 图片 (例如二维码图或其他该样式的非固定元素)
流程
客户端请求服务端, 获取静态资源URL和动态资源数据等(统称分享配置), 请求静态资源, 成功后使用WebView加载HTML模板, 同时通过统一的JS接口添加动态数据, 数据添加后 通过JS截图获取最终图片, 图片的传输可以通过转成Base64编码的形式实现, 客户端得到Base64字符串后转成Image类型执行分享处理.
流程中任何部分失败可直接走默认分享处理, 网络请求失败存在一定概率, 剩余部分失败原因基本为前端 服务端问题.
注意
- 秉着核心思想 避免多余请求, HTML模板中所有图片都应该使用Base64方式写在HTML源代码中.
- 同上 所有JS和CSS应该避免外链引用, 全部写在HTML源代码中.
- 客户端WebView无需显示在屏幕中, 可以将WebView的位置设置在屏幕外, 在用户无感知的情况下加载HTML页面.
- 客户端WebView的大小通常可以以iPhone Plus为准
414*768, 值得注意的是JS截图页面内容必须要完全显示出来, 打个比方, WebView大小设置为100*100, 实际页面内容大小确是200*200, 那么就可能造成截取的图片只有部分内容 超出WebView无法截取到, 所以必须要保证WebView大小大于内容大小, 内容大小可以和前端童鞋协定好. - HTML模板的URL需要增加版本号, 防止模板修改后CDN缓存导致的无法更新.
- 原则上客户端只需要告诉服务端要进行什么类型的分享, 具体的样式内容完全由服务端控制.
- 一种样式对应一个HTML模板, 一个模板对应一套JSON数据结构.
- 动态数据的内容和结构完全由前端和服务端根据样式需求约定, 其形式最好为JSON字符串.
- 前端需要做好HTML版本兼容问题, 保证低级系统的WebView对于HTML的兼容性
条件
- 美丽大方的前端一只
- 好说话的服务端一只
- 疯狂出图的设计一只
- 丧心病狂的产品一只
QA
Q: 为什么要用HTML?
A: HTML的好处我就不多说了, 这么多年的发展谁都懂, 相比于制定某些新样式标准来说, HTML更通用, 开发成本更低.
Q: 为什么HTML中的图片不用URL 而是要使用Base64?
A: 加载HTML页面就是为了截取整个页面的图片, 过多的请求会导致失败的概率, 并且假如某一个图片加载失败, 会影响最终的截取, 所以要尽可能减少请求次数, 最理想的状态是一次请求就完成, 在请求HTML过程中增加缓存处理, 除了第一次, 后续就可以做到只请求一次了.
Q: 为什么要做静态动态分离? 服务端直接把最终的的HTML返回给客户端不好吗?
A: 那确实是最好的, 一步到位, 但是要问问服务器的带宽能不能抗住如此大的数据量, 要知道所有图片的数据可都是在里面的, 如果你们的带宽够厉害, 那也可以尝试, 静态资源相对固定, 可以部署在OSS服务器上, 并不会占用接口服务器带宽, 通过CDN可以大大提高加载速度, 动态数据非常小, 并且可以和分享配置请求同时传输.
Q: 如何提高分享速度 减少用户等待时间?
A: 要动态就必定会牺牲一些体验, 我们能做的就是尽可能降低对体验的影响, 在静态资源请求中增加缓存处理, 分享配置中的HTML地址作为Key, 存储HTML源数据(其实就是String), 每次请求前查找一下本地缓存, 可避免多余的请求节省大量时间.
其他方案概述
方案一
客户端根据服务端下发的配置搭建原生页面 截取图片 分享.
优点: 生成速度快, 生成过程几乎无感知.
缺点: 开发成本高, 需要制定一整套新的样式配置标准 客户端根据该标准绘制原生页面, 每次添加变化较大的新样式需要发版解决, 动态性一般.
方案二
客户端工程中内置HTML模板框架和相关资源文件, 动态内容客户端拼接生成, 根据服务端下发的样式配置选择使用哪一种模板.
优点: 动态性较方案一有一定提升, 速度差别也不会差很多.
缺点: 同方案一, APP包过大, 添加新的变化较大的样式可能需要发版补充相关资源文件等, 动态性中等.
方案三
客户端只需请求服务端并告知分享类型, 最终HTML页面由服务端生成后直接返回, 通过WebView加载获取截图.
优点: 动态性高, 只需等待一次请求时间, 完全由服务端控制.
缺点: 如我之前所说, 带宽流量占用问题, 服务端开发成本大.
方案X
客户端只需请求服务端并告知分享类型, 由服务端合成图片返回给客户端.
优点: 对于客户端来说简单粗暴, 但加载图片等待时间过长.
缺点: 服务器压力 数据量 带宽...
总结
一个需求的解决方案有无数种, 重要的是相互平衡, 找出最优的, 最适合的方案, 同时有效的利用资源, 平衡开发成本, 这样才能更有效地解决问题.
如果你有更好的想法 欢迎评论留言讨论, 我是LEE, 下个方案见
