作者简介
崔广宇,携程酒店研发部小程序开发经理,曾负责过反爬虫开发以及H5开发。
本文将分享携程酒店小程序的一些开发经验, 和一些非技术的经验。这里的小程序包括微信小程序,支付宝,百度,头条。快应用因为与这些小程序的体系截然不同,就不放进来讨论了。文中所有观点均为个人观点, 不代表公司言论。
首先看一下项目背景。小程序的概念是微信发明的,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,那么基本上不会碰到什么兼容问题。这个工具还在开发中,这条路应该是一个比较平坦的路,能少很多坑。
以上就是携程酒店开发小程序的一些经验。 有一些是非技术的感想,甚至是吐槽,有一些是被逼无奈做出来的所谓的“黑科技”, 希望能够对大家有所启发。
【推荐阅读】
从智行 Android 项目看组件化架构实践
携程框架团队对于应用监控系统的探索与思考
节省55%测试时间,携程酒店比对平台介绍
终于来了!携程开源RN开发框架 - CRN
关于数据的异常检测,看这一篇就够了
为了让携程上万员工上好网,他们做了这些