作者简介
崔广宇，携程酒店研发部小程序开发经理，曾负责过反爬虫开发以及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，那么基本上不会碰到什么兼容问题。这个工具还在开发中，这条路应该是一个比较平坦的路，能少很多坑。
以上就是携程酒店开发小程序的一些经验。 有一些是非技术的感想，甚至是吐槽，有一些是被逼无奈做出来的所谓的“黑科技”， 希望能够对大家有所启发。
