写点什么

教主:做第一个吃螃蟹的人

  • 2019-09-22
  • 本文字数:3714 字

    阅读完需:约 12 分钟

教主:做第一个吃螃蟹的人

“VR 看房、VR 讲房、VR 带看是贝壳找房上 VR 系三大核心功能。到 2018 年底,我们将实现全国 30 多个城市、70 万套二手和租房房源、3500 个新房楼盘的 VR 呈现,这将是 VR 三维重建技术在中国不动产领域的首次大规模应用。”

——鸟哥


4 月 27 日,贝壳找房如视事业部的 VR 看房揭开了神秘的面纱。惠新宸(鸟哥)介绍了贝壳如视团队自主研发的 VR 看房,这是国内首次在不动产领域大规模应用三维实景和虚拟现实技术。


正因为是首次,产品的扩展性及不确定性给了研发团队更多自由想象的空间,同时也带来很多从未遇过的问题。于是,我们找到了负责将 VR 看房呈现到大家眼前的“教主”:杨永林。



在 VR 看房项目中,我主要做的是工程部分,将硬件团队和算法团队的产出变成一套业务流程将结果展示给用户。你可以理解为肉眼能看到的东西,比如,标签、标尺、展示优化以及在各个客户端 app 上传播……这些都是我们做的。


我们的 VR 看房是什么?

VR 看房是通过 VR(Virtual Reality 虚拟现实)技术让客户看到房子的户型和内部细节,实现不受时间、空间等条件限制的看房。


以前市面上的线上看房产品,仅有一套房子的全景图,并不能称之为真正的 VR 看房。我们的 VR 看房不但能看房,还有 VR 讲房和 VR 带看,让用户拥有沉浸式、互动性、实时性的 VR 看房体验。

1 沉浸式

VR 看房的虚拟现实技术让用户可以从房间中的一个点慢慢移动到另一个点,实现多角度看房,给用户带来身临其境的看房感受。再配上专业经纪人的 VR 讲房,让用户通过影像形式了解房源。

2 互动性、实时性

用户与经纪人能够实时互动。VR 带看结合客户端的 IM 即时通讯产品,使用户与经纪人能够在虚拟房间中同时移动,看到相同的房源画面;通过语音的方式,经纪人也能及时解答客户的各种疑问。

一套 VR 看房如何产出?

教主团队需要服务 7 个业务方,包括二手房、新房、租赁、旅居、海外、德佑、百川,每个业务方具体的操作流程不一样,目前业务量最大的是二手房。那么以二手房为例,一套二手房的 VR 看房是如何实现的呢?

1 经纪人 LINK 下单

一套房源录入到后台后,经纪人(一般为房源维护人)会在 LINK 中预约实勘。

2 摄影师拍摄

每一个区域都有对应的实勘摄影师,如果是拍摄 VR 的摄影师,他就会根据 VR 看房拍摄的标准流程,使用自主研发的扫描设备对房源进行扫描拍摄并将数据上传至相应的服务器上。

3 原素材优化处理生成模型

在基础三维数据上做半自动标注,比如,匹配上户型图、添加户型分析信息、做截图操作提供图片传播资料等。这部分在数据量起来以后,结合机器学习会完成全自动化。

4 添加标注

在基础三维数据上做半自动标注,比如,匹配上户型图、添加户型分析信息、做截图操作提供图片传播资料等。这部分数据量起来以后,结合机器学习会完全自动化。

5 人工审核

一套 VR 看房处理完成后会先进行展示,如果用户有问题反馈或者审核团队发现问题,就可以要求驳回展示。

6 功能添加

在 VR 看房场景中打上经纪人的标签、添加讲房及带看等功能。


教主回忆道:“2018 年 2 月 28 日 VR 看房功能上线,3 月 15 日正式开始拍摄,3 月已经覆盖了成都 10%的房源,到 4 月底一共拍摄了一万多套房源。”


未知是最大的困难

在整个 VR 看房技术研发的过程中,教主团队遇到了太多的难题,但“未知”才是最大的困难。


“很多开发者的常态是在一个已有的、成型的业务基础上进行改进和创新,有可参考的产品。但 VR 看房没有任何可以参考的先例,很多功能我们不知道有没有人实现过。在这个过程中出现过什么问题、会出现什么问题都是未知的,只有开发到了那个节点才发现还有这样一个问题。这是我们做这件事的时候比较困难的,但也正因为这些未知,才有这些人乐意去做这件事,乐意去解决未知的问题。”对于 VR 看房的难点教主这样说道。

1 找到核心价值

教主说:“面对整个行业里没有做过的产品,做第一个吃螃蟹的人,只能自己想办法把这些事情做得靠谱,做得有价值。”


在产品层面,团队没有可借鉴的产品,当时思考的主要是产品的功能是否有价值。VR 看房能给业务带来什么?是否是解决了痛点?能否实现多赢?然后思考的是这些价值体现在哪?如何表达?切入点有哪些?从哪个点切入是多方容易接受的?所以,最终产品看起来像是虚拟一个线下的看房场景,但思考的过程是价值导向的。


教主分析说:“首先,我们生成了房源的三维模型和全景图,并在看房场景中打上了标签,增加经纪人的头像、联系方式等。后来我们想到,既然有了对房源全量信息展示的空间,房间任何一个角度的画面都有,那么就可以介绍这个房子,于是有了声音与画面同步的 VR 讲房。经纪人跟用户之间经常需要互动,不止经纪人自己说,还希望能得到用户的反馈,用户能提问经纪人能回答,基于这样的考虑,我们想能否让用户和经纪人同时看一套房,所有就有了 VR 带看。”

2 实战积累 合理预判

在 VR 看房产品的研发中,对细节的把握和对效果的检测比较重要。


首先,要知道所有的产品细节是否能实现。因为功能之间是紧密联系的,如果有一个功能点无法实现,整个技术方案就要修改。


其次,产品功能是否能达到预期的效果。由于没有先例,教主团队甚至没有任何可参考的先验数据,而数据有问题时,无法得知具体是哪个因素引起的,这时就考验团队的经验与能力了。


要掌控以上两点,要求工程师们有过硬的实战经验,对产品整体规划进行合理的预判。教主认为面对未知要做的第一步就是把经验部分固化:“拆解整个项目,把自身经验验证过的部分固化下来,变成常量,减少其带来的不确定性。比如,我们用的架构方案都是自身最熟悉最拿手的,以此来减少问题。”

3 拥抱变化 快速迭代

“变”是教主一直以来在架构设计上的原则,他曾说过:“可变化的代码才是有生命力的代码,在架构设计上我也会趋向于让项目的代码可以一点一点的变化演进,而不是一言不合就重构。”


架构设计要能“变”,开发中遇到问题也要能“变”。教主说:“因为未知太多,所以要多做预案,做最坏打算。实际上我们的产品有最基础的功能版本,会思考如果某些不确定点出现问题,怎么降级产品功能。对于项目关键点我们会尝试各种手段攻破,尽量不修改主开发路线。当然定方案前的调研也是少不了的,做到起码心里有八分谱。”


  • VR 讲房录音


做 VR 讲房时,教主团队原本想在网页里做录音,但是发现苹果机型无法使用网页访问麦克风,最后改成客户端提供 API(应用程序编程接口)。这时就需要快速的修改方案,从不依赖客户端发版变成了依赖客户端发版。


  • VR 讲房录屏


在设计 VR 讲房录屏时,最开始参考了游戏上的录屏功能:一局游戏可以通过录屏的方式保存下来,后期随时播放。VR 讲房和游戏录屏看起来很像,但实际开发中却发现了问题。游戏版本往往是经过很多内测,产品非常完备后才对外发布的,一个版本可能会使用几年。比如 CS,版本升级后操作有变化,之前的录屏可能就无法播放了。


“这对于游戏来说可能不是大问题,但是对于我们的产品却是致命的。”教主分析道:“我们的业务是需要持续升级迭代的,VR 讲房不是一个快照,不应该是一个包袱,不能一次升级后所有的 VR 讲房都不能使用了。应该在满足需求的情况下,不影响产品整体升级,并且还具备一定的扩展性。”


  • VR 带看


规划 VR 带看之初,团队想的很简单,只要建立一个虚拟空间,经纪人与用户进入就可以进行互动。在实际开发中遇到特别麻烦的问题:怎么确保经纪人与用户进入的是同一个房间?比如,经纪人从 IM 给用户发起了领秀新硅谷一套房源的 VR 带看,进入虚拟房间后发现用户没有进入,于是又给用户发了一条链接,此时就有了两条链接。如果经纪人进了第一个链接的虚拟房间,用户进了第二个链接的虚拟房间,那么他们永远都不可能进入同一个虚拟房间。


为了解决这个问题,教主团队迅速转变思路,将虚拟的带看房间与房源、经纪人、用户的 ID 绑定,只要进入这个房间,双方就能建立连接。



贝壳的工程师不止有超强的逻辑,还有超强的应变能力和“比心还大”的脑洞。产品开发过程中,针对一个技术点,大家会给出多种解决方案,然后从逻辑上、场景上分析每个方案的优劣,选择一个方案快速去试,如果试出问题就迅速更换方案。每个工程师都有对自己方案的坚持,而“互怼”也成了常态,“怼”出来的解决方案才能更完美的解决问题。


自动标尺、打标签……每一个技术点都会遇到大大小小的问题,教主团队依靠超强的应变能力,打败通往胜利道路上的小怪兽和大 boss,一关一关升级前进。


“目前我们上线了两个版本——基础版本和带看版本。产品上线只是从 0 到 1 的过程,未来还有更多功能需要去实现,很多细节需要去打磨精细。”教主说,“比如经纪人端的优化、摄影师效率的提高、交互细节的优化等,虽然不会有肉眼所见的翻天覆地的变化,但一定会让产品的体验越来越好。”


5 个客户端、7 条业务线、楼盘字典、IM 团队……VR 看房的上线是公司多个团队合作的产物。教主团队要跟很多团队对接,在这个过程中得到了很多帮助,也产生过摩擦,但大家都有统一的目的地,到达让所有的过程都成为美丽的风景。


作者介绍:


杨永林(教主),2015 年底加入链家任链家网前端总架构师,2017 年 11 月调至如视软件工程部参与 VR 看房项目。


本文转载自公众号贝壳产品技术(ID:gh_9afeb423f390)。


原文链接:


https://mp.weixin.qq.com/s/DFF8YFknZzrOA1ulHdTcog


2019-09-22 23:49847

评论

发布
暂无评论
发现更多内容

详解 Serverless 架构的 6 大应用场景

阿里巴巴云原生

阿里云 Serverless 云原生

平均110万个漏洞被积压,企业漏洞管理状况堪忧

SEAL安全

DevSecOps 漏洞修复 软件供应链安全 漏洞管理 漏洞优先级匹配

云转售是什么意思?哪家好?理由是什么?

行云管家

云计算 企业上云 云资源 云转售

三位技术大咖的「研发效能」实践干货

万事ONES

研发效能 课程笔记

软件测试面试真题 | 面试时被问到知识盲区,该怎么办呢?

测试人

软件测试 面试题 测试开发

SOFARegistry | 大规模集群优化实践

SOFAStack

开源 SOFA SOFARegistry'

Go语言躲坑经验总结

百度Geek说

Go 企业号十月 PK 榜

「文本检测与识别白皮书-3.2」第三节:常用的文本识别模型

合合技术团队

人工智能 机器学习 深度学习 模型 文字识别

图数据 3D 可视化在 Explorer 中的应用

NebulaGraph

可视化 图数据库 3D

ModelBox姿态匹配:抖抖手动动脚勤做深呼吸

华为云开发者联盟

人工智能 华为云 企业号十月 PK 榜

详解AQS中的condition源码原理

华为云开发者联盟

开发 华为云 企业号十月 PK 榜

DevData Talks | 让效能度量产生真正的价值,要避开多少“坑”?

思码逸研发效能

研发效能 研发管理工具 企业研发管理

2022世界互联网大会 | VoneCredit为中小企业纾困解忧

旺链科技

区块链 产业区块链 世界互联网大会 企业号十月PK榜

【重磅】Serverless Devs 进入 CNCF 沙箱,成首个入选的 Serverless 工具项目!

阿里巴巴云原生

阿里云 Serverless 云原生

【愚公系列】2022年11月 Go教学课程 040-字符串处理

愚公搬代码

11月月更

软件测试面试真题 | 说一下常用的控件定位方法

测试人

软件测试 面试题 web测试 元素定位

NGINX Sprint 年度线上会议:报名通道已开启,立即预定您的 NGINX 深潜之旅

NGINX开源社区

nginx

3层结构+7大特点,带你认识华为云IoTEdge

华为云开发者联盟

云计算 物联网 华为云 企业号十月 PK 榜

拥抱“大信创”浪潮,优博讯开启成长新曲线

Geek_2d6073

分布式锁实战:基于Zookeeper的实现

小小怪下士

Java zookeeper 分布式

量化合约对冲挖矿app软件开发案例(支持测试)

开发微hkkf5566

Spring Boot「22」使用 Hibernate & JPA 持久化 Java 对象

Samson

Java hibernate Spring Boot 学习笔记 11月月更

Serverless Developer Meetup 杭州站精彩回顾!【附赠PPT】

阿里巴巴云原生

阿里云 Serverless 云原生

HummerRisk V0.5:新版云合规报告、资源风险联动、拓扑展示等内容

HummerCloud

云安全 云原生安全 11月月更

EMQ《物联网平台大规模数据接入和处理性能评测方法》成功入选“可信边缘计算推进计划”

EMQ映云科技

物联网 IoT 边缘计算 边云协同 11月月更

NFTScan 与 Bitizen 钱包达成战略合作,双方将在 NFT 数据层面进行深度合作

NFT Research

NFT 数据基础设施

知象光电完成过亿元C轮融资,加速发力全球市场

硬科技星球

为什么要用CSS精灵图

源字节1号

软件开发 前端开发 后端开发 小程序开发

字节跳动开源数据集成引擎BitSail的演进历程与能力解析

字节跳动数据平台

数据库 开源 数据开发 数据集成 企业号十月 PK 榜

IM消息ID技术专题(七):网易严选分布式ID的技术选型、优化、落地实践

JackJiang

网络编程 即时通讯 IM 开源im

堡垒机按什么收费?大概多少钱?有一个标准吗?

行云管家

网络安全 堡垒机 IT安全

教主:做第一个吃螃蟹的人_文化 & 方法_杨永林_InfoQ精选文章