微信官方都辟谣,技术人却用 AI、大数据实现头像添加圣诞帽了!

点击上方“CSDN”,选择关注

关键时刻,第一时间送达!

从昨天到现在,朋友圈里便持续性地见到了许多“请给我一顶圣诞帽@微信官方”,正如前文《如何从技术上实现「朋友圈@微信官方头像添加圣诞帽」?》所说,朋友们纷纷求问如何给自己的头像加上圣诞帽,然后,一场花式求圣诞帽的仪式开始刷屏了,还混入了各种奇怪的东西。但是却发现 @微信官方 并不能带上圣诞帽,才知道“被骗”了。

微信官方都辟谣,技术人却用 AI、大数据实现头像添加圣诞帽了!

而昨晚,微信官方还特地发了一篇《听说你们都在@我?》的文章就此事情进行辟谣,表示:

微信官方都辟谣,技术人却用 AI、大数据实现头像添加圣诞帽了!

然而,技术人们纷纷表示不服!“虽然微信没这个功能,但并不代表实现不了!在现有的技术环境下,这点需求都实现不了也未免太看不起我们程序员了吧?!”

阅文集团首席架构师徐海峰老师就表示,使用大数据分析+AI+图片动态处理实现能够实现“朋友圈@微信官方头像添加圣诞帽”,并为此撰文进行了架构上的分析。

而在 CSDN 文章的微信留言中,也有许多程序员小伙伴们表示“从技术上讲这个功能完全可以实现”,并为此纷纷出了主意。

微信官方都辟谣,技术人却用 AI、大数据实现头像添加圣诞帽了!

@微信官方,圣诞节就在眼前,能不能如愿就看你的了!实在不行来年也是可以的。

微信官方都辟谣,技术人却用 AI、大数据实现头像添加圣诞帽了!

接下来,我们有请徐海峰老师,从架构上分享,如何全自动无手工干预地实现“朋友圈@微信官方头像添加圣诞帽”。

以下为正文(经授权转自徐海峰老师个人公众号「94geek的大嘴」):

我们先变身为产品,分析需求,如下:

微信官方都辟谣,技术人却用 AI、大数据实现头像添加圣诞帽了!

从上图可以看出:“@”是发动者,头像更变是最后的结果。对于程序员来说,需要处理的问题点有几个:

  • 如何知道用户发起来需要戴圣诞帽的要求;

  • 如何识别出用户头像图片中的头部位置及其走向,然后尽可能正确的加上圣诞帽;

  • 如何通知微信程序更新最新头像。

首先,我们来解决第一个难点:如何知道用户发起需要戴圣诞帽的要求?

用户发一条朋友圈,微信服务器可以完整地得到该朋友圈的内容,所以微信后台可以对其进行内容解析。只要解析到朋友圈内容中带有“@微信官方”并且内容是“加/戴圣诞帽”相关的,就将该条朋友圈看做是用户需要更改头像。

在技术上,我们将其视为给微信发送了一个通知,考虑到朋友圈的发送量和改变图片的实时性需求,稍微延迟一点更改头像也没有特别大的关系,所以将处理头像设计成异步模式,最简单的办法就是将通知放入队列,缓存起来。架构图如下:

微信官方都辟谣,技术人却用 AI、大数据实现头像添加圣诞帽了!

第二步:解决图片识别问题。

鉴于头像图片识别头部的需求,我们不需要太过于精确,所以也没有必要大张旗鼓地使用很多的 AI 脸部识别技术(PS:当然有更好),目前开源的项目中 OpenCV 即可解决识别问题。OpenCV 可以识别出人脸在图片中位置,将其用坐标的形式“框”起来。考虑到有些用户头像的头部有干扰项:比如头部正好是黑色背景、头像中的人是光头……,可以适当的增加一些抗干扰的考虑项;如果要求更高一些,还可以根据眼睛、鼻子、耳朵等头部特征将头部的走向(防止有歪头的)大体计算清楚。

这样,在得到头部大体大小、坐标、走向的情况下,适当的调整圣诞帽的大小、坐标、走向,合并成一张图片即可。这部是整个技术的核心,如果需要提高正确率,可以对图片进行大数据分析,尽量的找到图片的公共点,提高识别的准确率。

最后:通知微信更新最新头像。

微信作为一个社交产品,它肯定会考虑加圣诞帽这个需求的时间效应:圣诞帽头像严格意义上说是具有极强时间效应的,所以这个头像存在的时间很短。用户更改头像的初衷并不是出于真心的喜欢,而只是图新鲜,2-5 天度过圣诞节后即没用了。

所以,微信没必要真正地去更改用户的头像,这也就意味着我们根本不需要更改任何数据库的操作,我们直接从原头像的基础上更改,将更改好的图片使用原来头像的文件名推入缓存系统、并且通知微信 App 更新即可。只要保证在 2-5 之内头像存在就可以完成任务。当然,如果需要永久保留图片,这就增加数据库标志位字段,然后将加好帽子的图片存入到图片服务器,并且更新缓存服务器的头像图片。

综上所述,整套架构如下所示:

整个架构图都画出来,但是肯定还有很多的同学会懵逼,竟然不把生成的图片都存储下来?好吧,顺便也科普一下行业内存储图片和处理图片的常用方案。

业内处理图片有一个不成文的规定: 存原图,给效果图。展开来说就是:

程序在存储用户上传图片的时候尽量不处理或者少处理用户的图片,等到用户获取的时候再由程序根据当时的需求给出不同的图片。

我们最常见的图片操作:加水印、裁剪图片、缩放图片、压缩图片大小……,很多时候我们都在上传的时候解决了。这种方案不是不可以,但是并不好。不好的地方主要有 2 个:

  • 浪费存储空间。上传的时候进行处理,也就意味着程序要存储一张原图,还有 N 张效果图。这就是存储可能被扩大了 N 倍;

  • 扩展难。目前的业务需求图片是 200200;过了 3 个月,业务方需要 400400;又过了 2 个月,业务方又需要一个 300*300 的……,纵使我们新需求可以通过更改代码来解决,老图片是不是还要创建一个 job 来遍历的跑一下才行?

所以,图片处理正确的做法应该是:在用户获取图片的时候交给图片的 HTTP 服务器处理。这种解决方案会在一定程度上增加 HTTP 服务器的压力,但我们可以使用 Varlish/Squid/CDN 等成熟的缓存系统将其做到“尽可能的一次写 N 次读”。

图片只有在第一次被访问的时候需要图片 HTTP 服务器对其进行处理,以后只要这张图片不过期/不被回收,这张图片一直存在于缓存中,根据反向代理原理,请求在缓存处已经获取文件,故不会对图片 HTTP 产生任何压力。虽然技术实现难度有所增加,但是却解决上面提到的 2 个最主要的问题。

作者声明:以上方案纯属大体方向和个人揣测,实践中还需要再根据具体的业务做具体的调整。如有雷同,纯属巧合!

欢迎大家就此进行交流,在留言中分享你的观点。也欢迎更多朋友微信联系:donyintxy 投稿,一起为程序员传播更具价值的优质内容。

相关推荐