【ArchSummit架构师峰会】探讨数据与人工智能相互驱动的关系>>> 了解详情
写点什么

携程酒店小程序开发背后的“黑科技”

  • 2020-02-15
  • 本文字数:3873 字

    阅读完需:约 13 分钟

携程酒店小程序开发背后的“黑科技”

本文将分享携程酒店小程序的一些开发经验, 和一些非技术的经验。这里的小程序包括微信小程序,支付宝,百度,头条。快应用因为与这些小程序的体系截然不同,就不放进来讨论了。文中所有观点均为个人观点, 不代表公司言论。


首先看一下项目背景。小程序的概念是微信发明的,2016 年左右内测,17 年不温不火,18 年忽然火爆起来。


当年小龙给出的定义是: 用完即走。这个理想很好,但一直没办法实现,因各大互联网都希望用户留下来,而不希望用户流失。所以 18 年小程序进行了大量的改进,都与“用完即走”的理念背道而驰。微信也不再提用完即走,还加了一句: “走了还会回来”。


通常我们会用小程序和 app 做比较,其实小程序更像 H5。尤其是出了 webview 之后,很多公司甚至直接用 webview 来做全流程,这种情况下, 小程序就沦为了一个空壳。


小程序和 H5 进行对比,就会发现小程序支持的功能更少。很多 H5 的风骚玩法,在小程序上都不能实现。反过来说,小程序又扩充了一些对硬件的访问,但是不是特别多,最典型的就是截屏的 callback,这个在 H5 是不存在的。


发布的时候因为是新平台,大家都不愿意投入,甚至多次传出了 “小程序要死了”的论调。这点和 silverlight 很像,区别是小程序现在活的很好,而且有越来越好的趋势。当然了这是现状。当时还是做的很艰辛的,各方面都不愿意投入资源来做。加上很多人担心小程序会吸血 app,更加恐慌这项新技术。


因此,携程这边自然而然形成了一个独特的开发模式


第一个就是,产品与开发一起提需求


对于普通的业务来说,通常产品会比较强势.小程序这里完全不同。小程序有两个问题: 第一, 竞品未必做的比我们好。第二, 竞品可能有一些私有 api,我们完全不能模仿。出于一些众所周知的原因,有些小程序天生是有一点特权的。


此外,微信小程序发展速度非常快,新的 api 出来了,开发比产品更加敏感,因此双方要进行合作,一起提需求。这也体现了“人人都是产品经理”,开发也可以参与到产品设计中。


保持简单。这是微信倡导的。微信有个大杀招,限制 size。不知道有多少人是老的小程序开发人员,最早的小程序 size 限制是 1M,携程当时在 1M 的限制内,上了好几个 BU 的业务。


主要人员来自 H5 开发转行。这个非常好理解。小程序虽然叫“程序”,写法和一些应用程序完全不同,却和 H5 没啥区别。很多 mvvm 框架写法和小程序是一样的,基本上没什么学习成本。


超越敏捷的速度开发。这个是被逼的。一个起步项目,没有太多节奏可言,抢一点是一点。 举个例子: 如果在上高地,你会按照先打奶和 DPS 后打肉的顺序严格执行吗?不会的,你会根据情况不断调整,能占便宜的时候就打最近的,仅此而已。节奏完全是乱的。


有个游戏叫“混乱之治”,以前很不理解这个游戏的名字,觉得 “混乱”是“混乱”, “治”是“治”。做了小程序之后则深有体会。


Webview 登录态问题。Webview 是小程序里一个很奇葩的存在,可以理解成微信向现实主义的妥协。原本是“忽悠”H5 开发上小程序这条船,结果却在小程序里又开了 webview, 让大家用 H5 做开发。因此这里就涉及到登录态同步的问题。


通常,webview 是做促销用的,很少用于主流程。原因是 webview 的灵活性。这个算优点也算缺点。优点是可以热更新,缺点是过于灵活容易触碰微信的底线。


微信给 webview 做了限制,必须全屏,不准遮挡。有一些黑科技可以绕过这些限制,但这会导致微信的封杀,完全是得不偿失的。我们通常用 webview 的灵活性, 来做促销页面。众所周知,促销是最容易发生需求变更的。


Webview 做促销也需要登录态。可以做到向内向外双向打通,但是在促销上,我们会进行单项打通,也就是只允许小程序把登录态无脑传递给 webview,不允许反向传。因为反向可能会污染登录态。


圆形二维码和普通二维码的选择。 这里的圆形二维码就是大家常见的,圆圆的那种小程序码。这种是微信极力推荐的。我们会根据情况,进行使用, 而不是全盘使用。因为普通二维码有更强的能力。


普通二维码是方型二维码,但是方型二维码不全是普通二维码,腾讯也提供了一个方型二维码的能力。因为有数量限制我们一般不用。腾讯还支持用一个普通的 url 映射到小程序路径。可以在小程序里写个 router,在官网设置一个绑定, 把 url 映射成微信小程序的 url。


这种做法会延伸出一个新的玩法,叫:通用二维码。简单的说就是,这个绑定关系,微信可以设,支付宝也可以设,百度也可以设。同一个二维码,微信扫出来会进入微信小程序,支付宝扫描可以进入支付宝小程序, 百度进百度小程序。如果在其他平台,不支持跳转, 例如 iphone 的相机,还可以正常打开 H5 页面,因为 url 可以做 302 跳转。这一点会很方便线下铺设二维码。


看似无用的 api 的使用方式。微信提供了很多有意思的 api,如何用是看大家的创意。


比如好多小程序都会拦截截屏事件。用户截屏说明用户想分享东西,那么就在截屏的时候弹出分享按钮,问用户是否想分享。这是一个顺其自然的操作方式,根本不需要教育用户。


我们提前上线了埋点,证明了截屏次数与订单数成正比。说明截屏的人是有下单意愿的,他们截屏,是为了分享给朋友,询问意见。那我们干脆直接把分享功能放进去了。现在看来这个操作已经是常规操作了,但当时微信加这个 api 的时候,这个玩法还是很让人叫好的。


下一个技术问题是推送和分享。这个可能会触及到微信的底线,这里提示一点:微信反对的是“恶意分享”,和“恶意推送”,而不是反对“分享”和“推送”,否则微信就不会提供这个能力了。这个大家可以想一想,两者有多大的差别。


人员分配问题


微信小程序现在实际上是拆分成两个小团队在做的,一个小团队做关键集群的业务,一个小团队做非关键集群的业务。关键集群,主要是主流程, 下单。这个保持着非常传统的 scrum 节奏,因为订单是一个很严肃的事情,来不得半点玩笑。


还有一个小团队在做促销相关的开发。目前外界对小程序的认知还是:适合拉新。这一点虽然微信官方不认可,但是私下大家的做法,还是很看中了微信流量的。因为促销的变化性很大,而且非常容易惹事情,因此促销是有自己的专用集群的。而且能用 webview 的地方,是绝对不用原生做开发的,因为原生代码涉及到审核问题。虽然我们的审核速度还是很快的, 但是毕竟是个很不可控的行为,促销不喜欢这种不可控。


有些地方还是会用原生的,因为 webview 的能力有些不足。这个后面我们马上会提到。


黑科技


第一点:没有什么是一次跳转不能搞定的


这是我们在内部群提到过的一句话。最初的出处是,有些团队需要用 H5 做页面,但是又需要一些原生能力,例如分享。这一点是很多促销所必需的能力。


这个需求的本质,其实是“偷权限”。在 webview 要操作的东西,如果操作不了,那么就进行一次跳转,进入原生页面。在原生页面可以拥有你所想要的所有权限。


例如,用户想分享一个活动链接,点了一个 div,我们不可能在 div 上面挂分享事件,微信没有提供这个能力。那怎么办呢?可以跳转一个页面,上面有两个按钮,一个叫“分享给朋友”,一个叫“分享到朋友圈”。


为什么不直接出两个按钮, 非要点完了再进行一次选择呢?这不增加用户费力度吗? 原因就是:只有进行一次跳转,才能偷到原生能力。而为了让这次跳转显得顺其自然,给用户一个解释,就不得不给出一个页面,假装在问:你是要分享给朋友呢,还是要分享到朋友圈呢?事实上,真正做的是通过这一次跳转,进入原生页面,使用原生能力。


而且,如果用户操作回退,比如滑动回退,还能回到之前的页面,一切看起来是顺其自然的。这样,在用户基本上没有感受到伤害的情况下,偷取了原生能力。


如果一次不行,那就两次。这个主要涉及到登录。例如,一个促销页面,点击一个按钮,需要检查权限。那么最简单的办法就是跳转到一个原生页面,然后再跳回来。


这里有个问题,回退之后,登录态发生了变化。要处理刷新问题。刷新往往是开发者最痛恨的操作,因为动不动就少刷一部分。促销团队上线压力很紧迫,开发时间远远比用户体验要宝贵。我们有时候就会直接牺牲用户体验,刷全页,性能差就加服务器,简单粗暴搞定。这个时候,有时候就不进行回退了,直接再走一次前进。


不要担心层数问题,逼急了就 relaunch。这个主要也是针对促销来说的。 主流程对层数是有严格要求的。但是促销不一样,层数用光了,需要跳转导流的时候直接一个 relaunch,抹掉历史,就没有层数问题了。促销很多事情都是简单粗暴, 但是特别有效。


讲了一大堆微信小程序的东西, 其实我们还做了其他厂商的小程序。为了降低开发成本,有各种转换工具,从微信小程序转换到支付宝,百度,头条甚至是 H5。


各家小程序的 api 基本相同,有点像当年 javascript 刚出来的时候的感觉, 大家都相似,但是总是有点兼容性的差异。转换工具只要解决这些差异即可。


最后一项,H5,可能有些和业界普遍的做法格格不入。业界普遍会使用 H5 转微信小程序,但是总会有各种兼容性问题。我们看来,H5 的功能是多于小程序的,也就是说 H5 是个全集,小程序相当于一个子集,从全集转子集,肯定会有各种不支持的东西出来。但是如果反过来想呢?从子集转全集,先有小程序再转 H5,那么基本上不会碰到什么兼容问题。这个工具还在开发中,这条路应该是一个比较平坦的路,能少很多坑。


以上就是携程酒店开发小程序的一些经验。 有一些是非技术的感想,甚至是吐槽,有一些是被逼无奈做出来的所谓的“黑科技”, 希望能够对大家有所启发。


作者介绍


崔广宇,携程酒店研发部小程序开发经理,曾负责过反爬虫开发以及 H5 开发。


本文转载自公众号携程技术(ID:ctriptech)。


原文链接


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


2020-02-15 17:45703

评论

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

重新思考流处理与流数据库

吴英骏

开源 云原生 流处理 ​Rust 实时数据库

大型 3D 互动开发和优化实践 | 京东云技术团队

京东科技开发者

游戏 3D 企业号 6 月 PK 榜 互动游戏

强化学习基础篇[2]:SARSA、Q-learning算法简介、应用举例、优缺点

汀丶人工智能

人工智能 深度学习 强化学习

堡垒机重要吗?为什么?求解!

行云管家

堡垒机 安全运维 录像审计

一文读懂责任分配矩阵,解决你80%的项目难题

敏捷开发

项目管理 Scrum 敏捷开发 责任分配矩阵 RACI矩阵

数据隐私为先:EMQX Cloud BYOC 架构解析

EMQ映云科技

物联网 云服务 mqtt

实现mac电脑与安卓互通|MacDroid 破解版

魔仙苹果mac堡

MacDroid for mac 安卓设备文件传输助手 MacDroid中文 MacDroid破解 mac与安卓同步

【5.26-6.02】写作社区优秀技术博文一览

InfoQ写作社区官方

热门活动 优质创作周报

中移链资源管理介绍

BSN研习社

让AI无处不在!Intel拿出全新VPU:超高能效碾压GPU

E科讯

TiDB数据迁移实践DM工具

TiDB 社区干货传送门

迁移 实践案例

2个场景实例讲解GaussDB(DWS)基表统计信息估算不准的处理方案

华为云开发者联盟

数据库 后端 华为云 华为云开发者联盟 企业号 6 月 PK 榜

一次网络请求中的流量分发过程 | 京东云技术团队

京东科技开发者

数据传输 企业号 6 月 PK 榜 流量分发 网络请求

魔法门之英雄无敌3下载,死亡阴影 for Mac中文版

魔仙苹果mac堡

mac游戏 英雄无敌3 英雄无敌3高清中文版 魔法门之英雄无敌3下载 死亡阴影中文版

rocketmq4 docker安装 阿里云linux2(centos7)

folo

Docker centos RocketMQ部署

TiDB集群数据库灾难恢复手册

TiDB 社区干货传送门

管理与运维 备份 & 恢复

人工智能工程总体介绍

紫晖

人工智能 软件工程 数据开发

行云堡垒V7亮点有哪些?具体看这里!

行云管家

IT运维 行云堡垒

亿级大表毫秒关联,荔枝微课基于腾讯云数据仓库Doris的统一实时数仓建设实践

科技热闻

圣邦股份:品类持续深挖,高端加速推进,模拟龙头稳健发展

华秋电子

复杂Flink任务Task均衡调度和优化措施

Openlab_cosmoplat

大数据

这本数智平台白皮书讲透了大型企业数智化升级业务痛点

用友BIP

白皮书 数智底座 数智平台 平台白皮书 数智化转型白皮书

简洁实用的文本编辑器:FSNotes中文版

真大的脸盆

Mac Mac 软件 文本编辑器 文本管理 文本处理工具

我又和redis超时杠上了

蓝胖子的编程梦

redis 性能分析 云服务器 线上事故 接口超时

含有CPU芯片的PCB设计需要考虑的五个主要方面

华秋电子

手把手实践丨基于STM32+华为云设计的智慧烟感系统

华为云开发者联盟

云计算 华为云 华为云开发者联盟 企业号 6 月 PK 榜

TiDB 落地SAS机器实践

TiDB 社区干货传送门

实践案例 应用适配 HTAP 场景实践

BFF层聚合查询服务异步改造及治理实践 | 京东云技术团队

京东科技开发者

优化技巧 企业号 6 月 PK 榜 BFF层 异步优化

强化学习基础篇【1】:基础知识点、马尔科夫决策过程、蒙特卡洛策略梯度定理、REINFORCE 算法

汀丶人工智能

人工智能 深度学习 强化学习

单点登录的三种实现方式

Authing

SSO 单点登录

玩转服务器之应用篇:从零开始构建小型高可用环境

京东科技开发者

高可用 云主机 云服务器 企业号 6 月 PK 榜

携程酒店小程序开发背后的“黑科技”_技术管理_崔广宇_InfoQ精选文章