欢迎大家前往腾讯云+社区,获取更多腾讯海量技术实践干货哦~
施德来,毕业于浙江大学计算机学院。曾任职于淘宝、网易,现任有赞前端技术负责人、电商小程序技术负责人。
因为有赞刚好在移动电商这个赛道上,整个行业都推动着我们向前走。海量的商家有各自的需求,不断地在业务上督促我们做一些事。这次我代表团队为大家汇报一下我们被商家推动着做了哪些事,主要是关于技术方面的。
我眼中的小程序
首先和大家分享一下我眼中的小程序到底是什么?关于小程序,有两大矛盾困扰着所有的移动开发者。一个是H5跨平台的开发速度很快,但是打开速度很慢,Native能力差。这是它的开放性所决定的,这是一个矛盾。另外一个矛盾是Native的APP体验流畅、功能齐全,但是开发速度极慢、更新麻烦,而且ios和安卓要重复开发。
Write Once,Run Anywhere. 我知道大家都很喜欢这句话,我在后面加了一个Like Native。为了这个目标各大公司都给出了自己的方案,比如Google给出的方案是PWA,因为国内互联网的现状,这个PWA最多可以做到离线缓存、通知推送,所以其实PWA不是一个出路。其他也有一些方案,比如说Hybrid App,PhoneGap、lonic,充分使用Native的能力,但性能终究还是有问题的。我给大家提供另外一个方案:React Native、Weex,充分利用Native的能力,同时也能达到一处编写到处执行,而且也能够写得很快,至少不用写两次。但是它也有一些问题,事实上前端工程师是不可能抛开安卓和ios独立进行开发的,一定需要大量的适配,但这已经算是很大的进步了。
![](https://i-blog.csdnimg.cn/blog_migrate/ca8a2d3327480c347657f2cd383c9a6d.png)
在我眼中现在只有一个选择:JS Native APP,微信本质上就是做JS Native APP,也就是小程序。它拥有JS Native APP的各种优点,再也不需要安卓的工程师和ios的工程师帮助解决系统问题了。结合Win7本身的公众号、浏览器功能,以及它底层的帐号能力,事实上微信已经有点像操作系统了。所以最终的结构是WeChat Operating System,什么事情都可以在微信里面完成,事实上就是这样。
![](https://i-blog.csdnimg.cn/blog_migrate/9a5bb9775f1d66ea3febedcc29ba7fad.png)
有人提出这样的观点,随着微信小程序生态的完善,中国的操作系统可能就是要靠腾讯了。这就是我理解的小程序是JS Native APP中未来相当有竞争力的方案,因为一半以上的人都使用微信。很多H5中需要高阶能力才能解决的问题,被小程序用降维解决了。小程序为什么要打包上传?其实是因为微信可以通过一定的策略让这个包提前下载,大家如果推送过小程序新版本的话就会知道,包是分批更新的,我相信微信底层有更新这个小程序代码或小程序包的机制。它省去了H5中我们要做的大量工作,比如原先要完成的异步加载等等。这些都是为了让打开速度更快,但如果代码被预先加载好了这些问题就都没有了。
以码农的视角介绍有赞微商城小程序
下面我将以码农的视角介绍一下有赞微商城小程序,或许哪天你在做一个小程序的时候,又需要有电商的功能。这时你可以通过小程序之间的跳转,在有赞注册一个小程序,把课程、服务等跳转到有赞这边,进行完购买流程再跳回去。在H5的年代我们有几千个商家就是这么做的,在他们的APP中嵌入了我们的H5,其实在小程序里面也是可以这么做的。
简单来讲,有赞介入得很早,也有过彷徨。小程序是在2016年9月21日开始内测,2017年1月9日正式发布。其实我们2016年就介入了小程序,当时对于小程序的理解又结合了小程序基于地理定位的特点,也就是发现附近的小程序。我们觉得餐饮是很好的切入口,当然电商是我们的老本行,我们很快就做出了电商的小程序。在1月9日小程序发布的时候,我们同时也发布了有赞的电商小程序,那时只能将代码生成给到商家,让商家自己提交。因为当时微信没有提供相关的平台型能力,所以直到现在有些商家还是用我们一年前的代码。其实外界也对小程序有很多的质疑,大概持续了半年不到,我们在这方面的投入其实也不多。随着微信官方推出了很多新的功能,大家对于小程序越来越清晰,商家的需求也越来越大,2017年下半年我们开始发力,商家也开始更重视起来,到了2018年有赞小程序开始爆发。
![](https://i-blog.csdnimg.cn/blog_migrate/a5f2aa340a20f483463f900e725f0ac6.png)
首先声明一下这个数字是被我伪装过的,因为现在不能给大家透露真实的数据,这是购买有赞小程序的每个月的数量,趋势是没有问题的。大家可以简单看到,一开始的趋势是下降的。2017年1月的购买量比较大,刚发布的时候大家都过来用,后来发现好像也没什么。因为那时很多能力没有开放,群的能力、附近的小程序都没有开放,后来慢慢了提供更多的能力,大家慢慢开始有感觉了。
下面来介绍一下我们在小程序里面做了哪些功能。如果大家了解有赞就会知道,我们是把H5里面大量的核心能力全部搬到小程序,同时也做了小程序特有的能力。后台包括店铺、商品、订单、客户、数据、营销工具、营销渠道,市面上有的各种营销工具基本上我们都做了,有些是我们首创的,有些是参考的。
这是我们页面的编辑器,左边是编辑,右边是编辑出的页面,所有页面都是商家自己编的。现在我们已经实现了每秒5万笔订单的处理能力,多门店选择可以根据地理位置选择门店。对于卖水果、卖蛋糕的商家比较有用。其他功能还有拼团、新人有礼、瓜分券等。瓜分券就是分享给自己的小伙伴,比如5个人来领才能领到。这是我们小程序独有的功能,因为小程序在群的能力上,分享页面更方便一些。
![](https://i-blog.csdnimg.cn/blog_migrate/266a16a6cac428f3d8dda0022dd75586.png)
简单来讲,我们的小程序包袱重、工作量大、场景复杂。首先,商家想要所有H5微商的功能,只是想要的比例不一样,我们要选择性地去搬。第二,我们要服务海量的商家,提供他们需要的技术服务,我们要生成海量的小程序。第三,H5微商城大量模块正在重构。这也是我们的工作环境。
![](https://i-blog.csdnimg.cn/blog_migrate/1969010c526baa4d7e0cb45317de82f9.png)
技术上的探索和积累
接下来讲一下有关技术上的探索和积累,第一个问题是如何同时产出海量独立的微商城小程序,每个商家一个版本还不同。微信是提供这种能力的,同一份代码在不同的ID提交后到微信的开发平台可以生成一个模板ID,拿到模板ID后所有商家在我们的后台批量提交小程序。在提交的时候把商家特有的配置,包括商家的APP ID和底部导航信息一起提交给微信,微信再开始审核。
有赞拥有公共版的小程序和专享版的小程序,一套代码两个马甲,共用业务代码。如果小程序的名字是自己的,类似于垂直商城这种有自己的店且完全独立的小程序就属于专享版。公共版是免费的,所有有赞的商家都可以使用。事实上两者的功能基本是一样的,只是底层的导航不一样,本质上我们需要在一套代码里面输出两种小程序。左图为公共版,右图为专享版。在一个仓库里输出两种小程序,解法其实很简单。一般而言我们小程序有一个APP的json,罗列小程序中基本有哪些页面。我们另外罗列出了基于原先的小程序额外多出的页面,底部的导航条信息是独立的,这是不会被合并的。
![](https://i-blog.csdnimg.cn/blog_migrate/81a00ee4d6dd90130e68ba894ffc696e.png)
富文本现在已经不是什么大问题了,在以前对我们来说却是比较难解决的问题。最早的时候富文本是图文编辑的组件,我们最早用的是wxParse,这是开源项目,它能够比较好的解决问题。但是它存在两个问题,一是没有办法很好地处理表格、列表标签,二是它最多只能嵌套11层。一般来说是没有问题的,但是有些商家会从第三方的编辑器编辑源码,再复制到有赞的页面编辑器里。第三方编辑器有的嵌了几十层,在小程序中就会出现很多内容丢失的情况。在2017年7月10日官方推出了一个rich-text,也存在一些问题。总结下来是svg无法在组件里面正常展示,能够展示但不能缩放。
下图是我们整个包大小的变迁,刚刚提到上半年发力,到11月份已经有1.4M,按照这个趋势再过两个月就要超过2M的限制了。我们用了一个叫做wxapp-webpack-plugin的开源工具,因为业务场景不一样可能需要二次开发。它可以帮助我们只打包有用的代码,在H5的生态里是最简单的东西,在小程序里会稍微有点麻烦,我们的结果就是把0.3的包变成0.93兆。12月份微信推出了分包,所有的包加起来4M,每个包不能超过2M。
![](https://i-blog.csdnimg.cn/blog_migrate/e7076839f3e6c1424329284900c23605.png)
接下来还有两部分,一是如何提高开发效率,二是如何提高稳定性。我们在2017年的1月开源了有赞小程序的组件库,我们拥有组件库的传统,最近也改用了官方推荐的自定义组件的写法。在开发的过程当中,同样也会涉及到接口的东西,有切换的问题,有接口转发的问题。在这里推荐大家尝试使用ZanProxy,现在我们的小伙伴没有这个工具就没有办法写代码,它可以很方便地转发。我们也支持自定义插件,做一些不同业务场景需要的关于接口文件、转发以及改造的相关需求,包括在H5的头里面加一些字段之类。
前店后厂模式还是跟效率有关,为了能够比较快速地把小程序做起来,我们回顾总结出了前店后厂模式,也就是减少环节快速往前跑。我们组建了对接商家的群,商家提出需求,开发的同学觉得这个需求有道理就马上去做,有些需求是凭感觉就知道有道理的。因为已经有了H5的能力在参照,我们要做的是选择哪些要复刻到小程序中去。提出的痛点解决之后马上给商家讲清楚,减少所谓的产品测试等各种环节,整个过程是很顺畅的。但需要核心人物同时发挥PM、产品经理以及开发的角色,或者团队里有人每天有一部分时间切换为产品经理。
关于如何提高稳定性,在我看来这是本次分享里比较有含金量的部分。简单来讲就是想要快速迭代但同时活多人少,而且没有测试资源的情况下要怎么快速向前跑。我们的解法就是体验版、稳定版机制,前端工程师历来都是改完马上生效,完全不管之前的版本,最多就是灰度发布。我们组建了一个内测商家群,每个星期及时同步稳定版发布时间以及体验版的新功能。内测商家全部默认使用体验版,但这些商家也是要进行筛选的。我们会在后台单独操作进行更新,也可以进行批量更新。基本上保持的节奏是两个星期一版,所以一个体验版的代码将被100来个内测商家至少使用一个星期。所以体验版小程序在改成稳定版提供给所有商家使用的时候,基本上已经没有什么问题了。其中唯一一次故障就是因为没有遵循这个原则,在体验版上停留三四天就着急上稳定版了。第二就是利用好回滚、撤销接口。对于这个版本出现的所有问题,我们可以批量地把所有商家的小程序都回撤到上一个版本,这是官方提供的借口。我们需要去开发,回撤之前会确认一下。
最后回顾一下,本次分享首先是为大家介绍了我眼中的小程序,简单来讲小程序就是微信操作系统中的APP,解决了之前H5和Native APP的各种问题,降低了开发门槛。第二是从码农的视角介绍了有赞微商城小程序,第三是介绍了我们团队技术上的探索和积累。
Q/A
Q:数据和数据之间做的隔离是在腾讯云上做一个集群吗?
A:这个事和腾讯没有什么关系,我们有自己的运维团队,基本上管得比较底层。当然对于个人开发者而言,我还是蛮推荐腾讯云的套路。刚才你说的商家数据隔离,我们现在没有做这样的事情。确实有给商家提供审核的时候,商家自己的配置,其中一个配置就是在小程序申请的APP ID,我们所有的请求都会带上这个ID,后端会拿到对应的数据。
Q:使用体验版的商家为什么愿意做小白鼠?是因为有一些优惠还是确实看中?
A:这个问题问得非常好,有两个理由。做生意的人,因为跟钱挂钩,他们会认定有些东西是很需要的,是他们下一步商业计划里急需的一环,他愿意承担这个不稳定的风险去使用这个功能。实际上我们的体验版质量也没有那么差,至少我们自己去回归过,该测还是会测。商家很愿意影响你,他对这个产品有自己的想法,人人都是产品经理,他们都希望这个产品按照他的想法去做,所以很愿意参与这个共建。现在很多产品都这么用,我们也用类似的套路去做这个事情,对于我们而言好处当然更多了。
Q:刚才说的体验是在现场,不是在小程序客户端,正儿八经的发到线上?
A:对,无非就是有一个名单,给这个名单发的时候给他提交的是制定的模板ID,是体验版的,只是提交审核的时候不一样而已。回撤是微信最近一两个月才公布的能力,我们也刚刚用起来,之前如果发了一个有问题的版本也没有办法,只能再发一次。
Q:刚才提到跟用户之间直接联系,我想问一个细节,这个推动过程是把多个商家拉到一个群里面这样操作,还是有分开?
A:把多个商家拉到一起。
Q:会不会有不和谐或者冲突的?
A:我不是特别明白你说的不和谐?
Q:比如说有些功能是加强版,我想拥有但是它没有,如果这个版本的价格跟别人的价格都会在群里提到?
A:在有赞我觉得是没有问题的,因为有赞各个版本的价格是比较透明的。说得再直白一些,哪怕你跟我们的CEO是很铁的哥们也没有优惠码,除非是商业定制款、高阶的、有更高的价格,需要有BD的同学进行对接。
Q:单独对接?
A:如果是特别高阶的几十万几百万的肯定需要单独对接,我们普通的基本款是4800,还有9800,都是一样的。
更多分享资料,请戳下面的链接:
问答
相关阅读
此文已由作者授权腾讯云+社区发布,原文链接:https://cloud.tencent.com/developer/article/1117052?fromSource=waitui