请选择 进入手机版 | 继续访问电脑版

默认
打赏 发表评论 2
想开发IM:买成品怕坑?租第3方怕贵?找开源自已撸?尽量别走弯路了... 找站长给点建议
微信“红包照片”背后的技术难题

前言


2016年除夕夜,微信正式发布了限时功能——红包照片,这个功能与微信的其它特性相比非常小众,一是它的时效性很短(很快就下线了)、二是受限于玩法它几乎没有给普通人了解或熟悉的时间(也就间接影响了它的受众范围)。

有鉴于此,且微信红包功能深度与微信的产品理念相融合,我们从产品的角度讨论功能几乎没有意义,那么本文将着重从技术的角度为大家讲讲微信开发团队在技术实现上遇到过什么难题,以及都是如何克服并解决的。

先看UI界面


微信红包照片功能2.jpg        微信红包照片功能1.jpg

微信红包功能3.jpg        微信红包功能4.jpg

再看技术逻辑


1主要模块


红包照片逻辑.jpg

从功能实现角度看,红包照片并不复杂。主要包含图中几个模块,基本就可以实现红包照片这个功能:

  • 发表权限入口/红点控制逻辑,客户端要对所有入口,以及引导进行控制,流量导控;
  • 发表,负责红包照片资源上传,发表逻辑;
  • 小图加载,红包照片在timeline有独特的展示效果,以区别普通的朋友圈图片;
  • 大图加载,红包照片在点击大图之后会出现模糊的大图,以及随机的一个挖洞效果;
  • 支付,这是红包照片最区别与其他照片的地方,你必须为这个照片发送一个红包才能查看完整的照片;
  • 统计,客户端为依据上报的统计来发现问题,异常,数据分析。

2更多细节


如果从单独的简单的每一个模块来看,似乎都不是很难,但我们整个开发过程到发布第一个版本也才不到两个多月的时间,那么对于客户端开发,这两个月意味着什么?

  • “时间”——数着小时过日子,还要适应需求不断的变化;没有大型的灰度的途径,代码质量必须依靠开发自己来保证高质量;
  • “性能”——红包照片的独特在于模糊,挖洞,这些性能消耗在Android上都会表现得特别的突出,怎么去保证从性能角度上它的体验效果和普通照片是无差异的;
  • “安全”——既然红包照片强调了红包,任何绕过红包查看照片都是违反游戏规则的,怎么在有限的时间内花最小的代价去尽量规避这种现象的发生;
  • “控制”——朋友圈是一个很扩散的场景,春晚活动关注度高,不确定因素多,不管是发表,还是红包照片支付,我们很难预见具体的量级,怎么去做流量控制?保证系统的可用性。

紧凑的版本迭代


1基本原则


实际上最终发布的红包照片功能并不是第一个可供发布的版本,这个功能的开发是不断迭代的,产品方案不断变化; 对于客户端而言是,代码要随着产品设计不断的推倒,体验才能最终成型。

从抢照片,到照片大冒险,讨红包,红包照片。玩法不断的在变,客户端要适应这种开发方式,起码需要满足:

  • “快”——快速开发,能够应对产品不停的方案迭代,改变,快速出demo体验;
  • “稳”——在快速开发迭代的过程中,必须保证质量,对于类似一年只会有一次的项目,发布之后基本不允许有暴露严重问题再修复的机会。

2实施方法


为此,最靠谱的就是以扩展的方式来写代码;多增加,少修改;而相比其他功能模块,需要更多的:

  • 沟通、平台一致:小红屋的开发模式,直接面对面沟通,同步,类似功能必须要保证Android和iOS平台统一的体验;
  • 不断的Code Review:代码首先要过关,特别在代码层面对关键路径做仔细的评估,甚至一些关键逻辑,我们拿iOS的代码逻辑和Android进行对比,来消灭错误逻辑,理解偏差;
  • 细节梳理:不断的整理细节,梳理异常路径,保证各个模块健全,稳定;
  • 测试、体验并重复之:内部测试和不断的真实体验,来发现问题。

最后,项目在发布之前都还保持着保密的状态,内部的每一次的小规模演练就变得非常重要,抓住每一次演练的机会,进行检验。

极致的性能是用户体验之本


1初始版本性能很差


0.jpeg

如上图所示,估计这是用户对红包照片印象最深的地方,随机打开一张朋友圈红包照片,每次都会随机显示一个圆圈类型的洞,暴露图片局部的内容;而如果想看完整的照片,必须通过"发红包看照片"来实现,这是红包照片的核心玩法。

模糊图片并不是功能一开始就有的设计,而是一个个demo版本演变来的, 因此一张红包照片和一张普通照片对后台存储来说是没有什么不同的。从模块设计角度来说,一张红包照片的发表/下载流程上和一张普通图片的发表/下载几乎没有差异;那么这些表现出来的差异,模糊、挖洞就得交给客户端来做。

第一次点开朋友圈中的红包照片要经过哪些步骤呢?

红包照片性能.jpg

这些步骤的处理对Android来说都是很大的性能考验。第一个版本,第一次点击图片,从完成下载、模糊、抠洞、显示看到图片,大概花了大约4s的时间,显然这是不可接受的一个体验。 那我们是怎么做的呢?

2大图还是小图?


模糊一张朋友圈大图需要 1500ms左右,而模糊一张小图只要50ms不到,差不多30倍的差距,拿大图来做模糊其实很不划算。通过调节模糊半径,在确定显示效果ok的情况下,我们选择了用小图来做模糊效果而不是大图。

3如何“挖洞”?


但我们注意到,在模糊图出现的圆洞区域却是很清晰的画面(小图缩放达不到这种效果),给人感觉整个图片好像就是清晰的样子,这又是怎么实现的呢?

首先,挖洞的位置并不是简单的随机,而是控制有一定的规则,比如说有一定的概率出现在人脸的周围。同样的道理,拿大图来做人脸识别和小图来做人脸识别差距也是非常明显的,至少10倍以上的差距,即便小图识别效果可能没有大图的效果好,但这种换取代价还是非常值得的。因此我们也首先在小图上做人脸识别,记录对应的结果坐标,通过对图片局部解码从大图找到对应的区域,Clip出一个圆圈,画到一个ARGB_8888的面板上,再将边缘进行一定的透明度调整,盖到原始图片上即可!

4优化后的性能很满意


红包性能2.png

通过这些过程,最后我们将整体的体验缩减到1s内。

安全性至关重要


1传统做法的不足


朋友圈的图片是利用HTTP从CDN服务器直接下载,而非使用私有的协议。 同时存储在客户端本地。

红包照片安全性.jpg

朋友圈红包照片跟普通照片并无差异,而HTTP本身就很容易被监听抓包,Android操作系统APP的大数据存储也是存储在公共的存储空间上。功能一旦预演,发布定会有很多的抓包、导出资源的工具等等,破坏朋友圈红包照片的相关玩法。

2关键技术点


  • 下载安全:更改朋友圈的下载方式,从项目的时间来看这几乎是不可能的;
  • 本地存储安全保护:本地存储也要足够安全保护,否则依然很容易从本地拉取到下载后的数据。

3方案要达到的要求


  • 简单的抓包获取的数据的是无法解读的;
  • 客户端的数据是加密存储;
  • 加密的算法足够简单、快速,客户端存储的是加密数据,意味着客户端的每次读取/写入图片都是一个加解密的过程,不可能为了防止少数人破坏游戏规则而给所有的人都带来更差的体验;
  • 开发足够快、改动少,朋友圈暴露读取文件的接口很多,期望能花最小的代价完成改动。

4最终制定的方案


最后我们选择在HTTP中返回加密的数据,而加密的数据必须依赖朋友圈数据中隐藏对应的key来解密,且支持流式加解密。一张图片可以对应一个不同的密钥,允许后台从非加密切换到加密,或者加密切换到非加密。

红包照片安全性2.jpg

朋友圈暴露读取文件的接口很多,读小图、读大图、读模糊图、写大图、写小图、检查exif等等都是对图片文件的操作。要考虑密钥怎么传递,减少改动量和修改的复杂度,加密的bitmap怎么解析,怎么和普通的图片数据做到兼容?

来看看最后优化后实现方式:

红包照片安全性3.jpg

使用者通过路径生成器,来获取路径,如果是红包照片的数据,则将密钥通过一定规则隐藏在Path路径中,密钥变更会使得Path也不同。所有的文件接口聚合到FileOperataion,发现是加密的Path则返回特殊的EncInputStream/EncOutputStream,否则返回普通的InputStream/OuputStream;EncStream 则拦截了InputStream/OutputStream的 read 和 write 等方法,将数据通过加解密模块处理完再返回应用层;从整体上来看,我们的改动也只涉及到了蓝色/黄色/红色的区域模块。

实际上,在保证保密/安全的工作上我们还做了很多其他工作。比如发布的版本,为了使得项目进行保密,资源(String)等都是加密处理的,当然也犯过一些错误,比如1月26号的预热,代码暴露图片路径的接口,使得简单的通过Xposed注入替换路径就可以绕过游戏规则(关于微信红包被破解请查看此链接)。

功能上线后的可控性


朋友圈红包作为今年的一个新的尝试,本身就获取到高度的关注,但又缺少历史经验,对于在朋友圈这种环境下如此大型的活动的,一方面要控制朋友圈的质量,一方面可能带来的巨大的流量,甚至很难估算;所有的方案都不能保证是万无一失的,如何保证系统的可用性,一方面就是要可控,能够随时调整策略。

需要达到的要求是:发表权限可控,发表人数可控,发表次数可控,所有文案可控,支付金额可控等等。

举个例子,比如发红包看照片这个按钮,所谓的“可控”包含以下内容:

  • 控制,后台对客户端要有足够个控制逻辑,比如金额区间,甚至可以区分不同的人群。
  • 缓存,很多人不断的对金额随机,客户端要有一定的缓存时间,减少服务器的压力。
  • 提额,预备提额可以减少服务器的压力。
  • 彩蛋,有一定的几率出现彩蛋(中奖),同理可以减少服务端的压力。

统计数据


2016猴年春晚,朋友圈红包照片:

  • 产生了2900w红包照片
  • 互动总数超过1.92亿次

全站即时通讯技术资料分类


[1] 网络编程基础资料:
TCP/IP详解 - 第11章·UDP:用户数据报协议
TCP/IP详解 - 第17章·TCP:传输控制协议
TCP/IP详解 - 第18章·TCP连接的建立与终止
TCP/IP详解 - 第21章·TCP的超时与重传
理论经典:TCP协议的3次握手与4次挥手过程详解
理论联系实际:Wireshark抓包分析TCP 3次握手、4次挥手过程
计算机网络通讯协议关系图(中文珍藏版)
NAT详解:基本原理、穿越技术(P2P打洞)、端口老化等
UDP中一个包的大小最大能多大?
Java新一代网络编程模型AIO原理及Linux系统AIO介绍
NIO框架入门(三):iOS与MINA2、Netty4的跨平台UDP双向通信实战
NIO框架入门(四):Android与MINA2、Netty4的跨平台UDP双向通信实战
>> 更多同类文章 ……

[2] 有关IM/推送的通信格式、协议的选择:
为什么QQ用的是UDP协议而不是TCP协议?
移动端即时通讯协议选择:UDP还是TCP?
如何选择即时通讯应用的数据传输格式
强列建议将Protobuf作为你的即时通讯应用数据传输格式
移动端IM开发需要面对的技术问题(含通信协议选择)
简述移动端IM开发的那些坑:架构设计、通信协议和客户端
理论联系实际:一套典型的IM通信协议设计详解
58到家实时消息系统的协议设计等技术实践分享
>> 更多同类文章 ……

[3] 有关IM/推送的心跳保活处理:
Android进程保活详解:一篇文章解决你的所有疑问
Android端消息推送总结:实现原理、心跳保活、遇到的问题等
为何基于TCP协议的移动端IM仍然需要心跳保活机制?
微信团队原创分享:Android版微信后台保活实战分享(进程保活篇)
微信团队原创分享:Android版微信后台保活实战分享(网络保活篇)
移动端IM实践:实现Android版微信的智能心跳机制
移动端IM实践:WhatsApp、Line、微信的心跳策略分析
>> 更多同类文章 ……

[4] 有关WEB端即时通讯开发:
新手入门贴:史上最全Web端即时通讯技术原理详解
Web端即时通讯技术盘点:短轮询、Comet、Websocket、SSE
SSE技术详解:一种全新的HTML5服务器推送事件技术
Comet技术详解:基于HTTP长连接的Web端实时通信技术
WebSocket详解(一):初步认识WebSocket技术
socket.io实现消息推送的一点实践及思路
>> 更多同类文章 ……

[5] 有关IM架构设计:
浅谈IM系统的架构设计
简述移动端IM开发的那些坑:架构设计、通信协议和客户端
一套原创分布式即时通讯(IM)系统理论架构方案
从零到卓越:京东客服即时通讯系统的技术架构演进历程
蘑菇街即时通讯/IM服务器开发之架构选择
腾讯QQ1.4亿在线用户的技术挑战和架构演进之路PPT
微信技术总监谈架构:微信之道——大道至简(演讲全文)
如何解读《微信技术总监谈架构:微信之道——大道至简》
快速裂变:见证微信强大后台架构从0到1的演进历程(一)
17年的实践:腾讯海量产品的技术方法论
>> 更多同类文章 ……

[6] 有关IM安全的文章:
即时通讯安全篇(一):正确地理解和使用Android端加密算法
即时通讯安全篇(二):探讨组合加密算法在IM中的应用
即时通讯安全篇(三):常用加解密算法与通讯安全讲解
即时通讯安全篇(四):实例分析Android中密钥硬编码的风险
传输层安全协议SSL/TLS的Java平台实现简介和Demo演示
理论联系实际:一套典型的IM通信协议设计详解(含安全层设计)
微信新一代通信安全解决方案:基于TLS1.3的MMTLS详解
来自阿里OpenIM:打造安全可靠即时通讯服务的技术实践分享
>> 更多同类文章 ……

[7] 有关实时音视频开发:
即时通讯音视频开发(一):视频编解码之理论概述
即时通讯音视频开发(二):视频编解码之数字视频介绍
即时通讯音视频开发(三):视频编解码之编码基础
即时通讯音视频开发(四):视频编解码之预测技术介绍
即时通讯音视频开发(五):认识主流视频编码技术H.264
即时通讯音视频开发(六):如何开始音频编解码技术的学习
即时通讯音视频开发(七):音频基础及编码原理入门
即时通讯音视频开发(八):常见的实时语音通讯编码标准
即时通讯音视频开发(九):实时语音通讯的回音及回音消除概述
即时通讯音视频开发(十):实时语音通讯的回音消除技术详解
即时通讯音视频开发(十一):实时语音通讯丢包补偿技术详解
即时通讯音视频开发(十二):多人实时音视频聊天架构探讨
即时通讯音视频开发(十三):实时视频编码H.264的特点与优势
即时通讯音视频开发(十四):实时音视频数据传输协议介绍
即时通讯音视频开发(十五):聊聊P2P与实时音视频的应用情况
即时通讯音视频开发(十六):移动端实时音视频开发的几个建议
即时通讯音视频开发(十七):视频编码H.264、V8的前世今生
简述开源实时音视频技术WebRTC的优缺点
良心分享:WebRTC 零基础开发者教程(中文)
>> 更多同类文章 ……

[8] IM开发综合文章:
移动端IM开发需要面对的技术问题
开发IM是自己设计协议用字节流好还是字符流好?
请问有人知道语音留言聊天的主流实现方式吗?
IM系统中如何保证消息的可靠投递(即QoS机制)
谈谈移动端 IM 开发中登录请求的优化
完全自已开发的IM该如何设计“失败重试”机制?
微信对网络影响的技术试验及分析(论文全文)
即时通讯系统的原理、技术和应用(技术论文)
开源IM工程“蘑菇街TeamTalk”的现状:一场有始无终的开源秀
>> 更多同类文章 ……

[9] 开源移动端IM技术框架资料:
开源移动端IM技术框架MobileIMSDK:快速入门
开源移动端IM技术框架MobileIMSDK:常见问题解答
开源移动端IM技术框架MobileIMSDK:压力测试报告
开源移动端IM技术框架MobileIMSDK:Android版Demo使用帮助
开源移动端IM技术框架MobileIMSDK:Java版Demo使用帮助
开源移动端IM技术框架MobileIMSDK:iOS版Demo使用帮助
开源移动端IM技术框架MobileIMSDK:Android客户端开发指南
开源移动端IM技术框架MobileIMSDK:Java客户端开发指南
开源移动端IM技术框架MobileIMSDK:iOS客户端开发指南
开源移动端IM技术框架MobileIMSDK:Server端开发指南
>> 更多同类文章 ……

[10] 有关推送技术的文章:
iOS的推送服务APNs详解:设计思路、技术原理及缺陷等
Android端消息推送总结:实现原理、心跳保活、遇到的问题等
扫盲贴:认识MQTT通信协议
一个基于MQTT通信协议的完整Android推送Demo
求教android消息推送:GCM、XMPP、MQTT三种方案的优劣
移动端实时消息推送技术浅析
扫盲贴:浅谈iOS和Android后台实时消息推送的原理和区别
绝对干货:基于Netty实现海量接入的推送服务技术要点
移动端IM实践:谷歌消息推送服务(GCM)研究(来自微信)
为何微信、QQ这样的IM工具不使用GCM服务推送消息?
>> 更多同类文章 ……

[11] 更多即时通讯技术好文分类:
http://www.52im.net/forum.php?mod=collection&op=all

附录:有关QQ、微信的文章汇总


[1] 有关QQ、微信的技术文章:
微信后台团队:微信后台异步消息队列的优化升级实践分享
微信团队原创分享:微信客户端SQLite数据库损坏修复实践
腾讯原创分享(一):如何大幅提升移动网络下手机QQ的图片传输速度和成功率
腾讯原创分享(二):如何大幅压缩移动网络下APP的流量消耗(下篇)
腾讯原创分享(二):如何大幅压缩移动网络下APP的流量消耗(上篇)
微信Mars:微信内部正在使用的网络层封装库,即将开源
如约而至:微信自用的移动端IM网络层跨平台组件库Mars已正式开源
开源libco库:单机千万连接、支撑微信8亿用户的后台框架基石 [源码下载]
微信新一代通信安全解决方案:基于TLS1.3的MMTLS详解
微信团队原创分享:Android版微信后台保活实战分享(进程保活篇)
微信团队原创分享:Android版微信后台保活实战分享(网络保活篇)
Android版微信从300KB到30MB的技术演进(PPT讲稿) [附件下载]
微信团队原创分享:Android版微信从300KB到30MB的技术演进
微信技术总监谈架构:微信之道——大道至简(演讲全文)
微信技术总监谈架构:微信之道——大道至简(PPT讲稿) [附件下载]
如何解读《微信技术总监谈架构:微信之道——大道至简》
微信海量用户背后的后台系统存储架构(视频+PPT) [附件下载]
微信异步化改造实践:8亿月活、单机千万连接背后的后台解决方案
微信朋友圈海量技术之道PPT [附件下载]
微信对网络影响的技术试验及分析(论文全文)
一份微信后台技术架构的总结性笔记
架构之道:3个程序员成就微信朋友圈日均10亿发布量[有视频]
快速裂变:见证微信强大后台架构从0到1的演进历程(一)
快速裂变:见证微信强大后台架构从0到1的演进历程(二)
微信团队原创分享:Android内存泄漏监控和优化技巧总结
全面总结iOS版微信升级iOS9遇到的各种“坑”
微信团队原创资源混淆工具:让你的APK立减1M
微信团队原创Android资源混淆工具:AndResGuard [有源码]
Android版微信安装包“减肥”实战记录
iOS版微信安装包“减肥”实战记录
移动端IM实践:iOS版微信界面卡顿监测方案
微信“红包照片”背后的技术难题
移动端IM实践:iOS版微信小视频功能技术方案实录
移动端IM实践:Android版微信如何大幅提升交互性能(一)
移动端IM实践:Android版微信如何大幅提升交互性能(二)
移动端IM实践:实现Android版微信的智能心跳机制
移动端IM实践:WhatsApp、Line、微信的心跳策略分析
移动端IM实践:谷歌消息推送服务(GCM)研究(来自微信)
移动端IM实践:iOS版微信的多设备字体适配方案探讨
>> 更多同类文章 ……

[2] 有关QQ、微信的技术故事:
技术往事:创业初期的腾讯——16年前的冬天,谁动了马化腾的代码
技术往事:史上最全QQ图标变迁过程,追寻IM巨人的演进历史
开发往事:深度讲述2010到2015,微信一路风雨的背后
开发往事:微信千年不变的那张闪屏图片的由来
开发往事:记录微信3.0版背后的故事(距微信1.0发布9个月时)
一个微信实习生自述:我眼中的微信开发团队
>> 更多同类文章 ……

(本文资料整理自 WeMobileDev,感谢原作者。)

即时通讯网 - 即时通讯开发者社区! 来源: - 即时通讯开发者社区!

上一篇:移动端IM实践:iOS版微信小视频功能技术方案实录下一篇:微信程序员创业总结:如何提高Android开发效率

本帖已收录至以下技术专辑

推荐方案
评论 2
红包照片这功能看都没看到过。

文章里面有关图片的处理,还是有借鉴的地方哦,感谢
签名: 国庆长假还没有缓过来,请让我静一静,产品狗死远点...
微人这帮人整的东西,技术确实扎实。原理写的非常好,要是能有代码给参考参考那就太赞了!
打赏楼主 ×
使用微信打赏! 使用支付宝打赏!

返回顶部