写点什么

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

  • 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:491073

评论

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

WebGL软件系统的性能优化方法

北京木奇移动技术有限公司

软件外包公司 webgl开发 three.js开发

Web3项目的上线流程

北京木奇移动技术有限公司

区块链开发 软件外包公司 web3开发

京东API接口最新指南:店铺所有商品接口的接入与使用

tbapi

京东API 京东店铺所有商品接口 京东店铺所有商品采集

以智能运维一体化平台破局数字化转型深层挑战,湖北数产集团X嘉为蓝鲸

嘉为蓝鲸

数字化转型 AIOPS 一体化运维

AI加剧GPU短缺,解决之道在哪里?

PowerVerse

趋势 AI‘’ gpu 算力

使用 Ollama 本地模型与 Spring AI Alibaba 的强强结合,打造下一代 RAG 应用

阿里巴巴云原生

阿里云 云原生

云原生 Kafka 问卷调研启动,你的声音很重要!参与赢精美礼品!

阿里巴巴云原生

kafka 阿里云 云原生

钉钉 + AI 网关给 DeepSeek 办入职

阿里巴巴云原生

阿里云 AI 网关

秒哒首发即爆发!上线首日吸引2万用户,打造3万应用!

百度Geek说

百度

智慧园区管理系统(源码+文档+讲解+演示)

深圳亥时科技

运维人员如何抓住 AI 机遇?DeepSeek 给出的转型路线图

嘉为蓝鲸

AIOPS 智能运维 DeepSeek

分布式数据一致性场景与方案处理分析|得物技术

得物技术

分布式 事务消息 分布式一致性 业务场景分析

HarmonyOS NEXT 中级开发笔记:基于ArkTS的简易文件浏览器实现

huafushutong

HarmonyOS NEXT

HarmonyOS NEXT 中级开发笔记:基于ArkTS的消费记账应用实践

huafushutong

HarmonyOS NEXT

「通义灵码+X」公开课开讲啦!和赛博同桌一起完成开发任务 有奖励

阿里巴巴云原生

4月用友BIP行动地图发布!

用友智能财务

AI 财务 会计

不愧是高级Java开发岗,确实有点难~

王中阳Go

Java 面试 Java高级开发工程师

可观测性+AI双轮驱动!嘉为蓝鲸应用发布中心V6.0打造下一代智能发布操作系统

嘉为蓝鲸

AIOPS 智能运维 应用发布中心

HarmonyOS NEXT 中级开发笔记:基于ArkTS的房屋装修App实践

huafushutong

HarmonyOS NEXT

HarmonyOS NEXT 中级开发笔记:健康管理类应用的ArkTS实践

huafushutong

HarmonyOS NEXT

智能运维新标杆:OpsPilot V3.3通过MCP实现多源运维知识融合

嘉为蓝鲸

智能运维 #WeOps MCP协议

DataWorks数据集成同步至Hologres能力介绍

阿里云大数据AI技术

大数据 Serverless 数据集成 hologres Dataworks

嘉为蓝鲸IT服务管理中心V4.0:灵活扩展+敏捷交付,IT服务管理全链路高效协同

嘉为蓝鲸

AIOPS ITSM 智能运维 IT服务管理中心

去中心化云算力的3个发展阶段,走向自治和高效

PowerVerse

发展 去中心化 算力 web3

HarmonyOS NEXT 中级开发笔记:基于ArkTS的拼团电商应用实践

huafushutong

HarmonyOS NEXT

智能运维,由你定义:SAE自定义日志与监控解决方案

阿里巴巴云原生

阿里云 Serverless 云原生

「通义灵码+X」公开课开讲啦!和赛博同桌一起完成开发任务 有奖励

阿里云云效

阿里云 通义灵码

怎么用最小的投入通过等保测评?一站式服务

黑龙江陆陆信息测评部

双引擎驱动!WeOps存储监控的全插件支持与自定义开发指南

嘉为蓝鲸

智能运维 #WeOps 监控管理

【FAQ】HarmonyOS SDK 闭源开放能力 —Push Kit(12)

HarmonyOS SDK

harmoyos

AI背单词APP的线上运营

北京木奇移动技术有限公司

软件外包公司 AI英语学习 AI背单词

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