一、引言本文将介绍vivo商城在前端维度的多端统一探索与实践，作为所有的。我们从多端价值的角度，为什么需要多端统一，如何满足多端业务需求，实践与创新，简明扼要地阐述了我们在多端统一上所做的一切。2、多终端探索给vivo商城带来什么价值？多终端价值体现在技术架构升级和人力资源释放两个方面。1.技术架构全面升级从现在开始，我们实现了技术架构方案的统一。通过统一，大大降低了开发成本和维护成本。同时，它具有高复用和高效率。2、释放大量人力资源，统一技术架构方案，为业务的横向扩展提供强有力的技术支持和可实现的保障。下图是使用新的技术架构后的开发人力投入比例。从上图可以看出，通过技术架构的升级，释放了可观的开发资源。让释放出来的开发资源做更多有价值的事情。3、为什么要做多端统一？大家可能会有疑问，那就是什么是多端统一？这里我先开个玩笑，先不说unity，先说多端这个词。什么是多终端？想必大家都能说差不多吧。关于多终端，我画了一张图，如下图：从上图可以看出，离线、PC、wap、APP、微信公众号、微信小程序等，每一个都可以称为一个终端。知道了多终端的含义，现在，我们再回顾一下多终端统一。完整的多端统一包括以下几个方面：统一大前端[前端+客户端]、多端统一服务器、多端统一业务、多端统一这里只讨论多端统一前端。从PC浏览器，到手机浏览器，再到APP嵌入，再到各种小程序，再到服务器端和客户端。一个繁荣的生态，就像百家争鸣，百花盛开。然而，繁荣的背后，对前端工程师的挑战也与日俱增。我们承接的终端越来越多，新的终端也在不断出现，比如小程序、快应用。前端工程师陷入了如下套娃陷阱：已有代码和新代码必须适配新端开发场景已经适配新端开发场景的代码变成已有代码开发场景循环...我们希望解决这个问题，希望能实现一套能够覆盖当前端和未来端的技术架构方案【代码】。通俗的说，我们希望实现下图所示的能力：在这个前端开发的背景下，出现了多端统一。是前端未来的一个趋势，也是解决上面套娃陷阱的一剂良药。4、如何满足日益增长的多端业务需求随着时间的推移，各种小程序的业务逐渐受到重视，尤其是vivo商城微信小程序。业务方有两点需求，如下：第一点：让现有vivo商城微信小程序的核心功能与商城H5功能保持一致。第二点：后续版本迭代，小程序端和H5端同步进行。但现实是：现有商城微信小程序的版本迭代已经远远落后于H5版商城。我们用新旧版本的小程序购买流程视频进行对比，让大家有更直观的体验。老商城小程序：视频>>新商城小程序：视频>>从上面两个视频可以看出两者的区别，我们面临着很大的挑战。根据业务方的要求，我们要做的就是解决以上两点，再加上一点，一共三点，如下：第一点：在最短的时间内，完成基本功能和商城H5流程第二点在微信小程序上实现：当后续小程序与H5版本的功能同步迭代时，实现了高复用和高效率。第三点：提前考虑其他端业务场景的实现，做好扩展性和多端复用性。以业务为驱动，我们进行了技术调研、demo验证、mvp验证。最终综合考虑，采用了uni-app多端架构来解决以上两个难点。这里提一下，一个好的业务驱动模型大致如下图所示：用业务推动技术优化和变革，在反复应用的过程中，实时反馈改进，最后回归业务。在这个过程中，技术和业务形成一个良性的闭环。现在。剩下的就是付诸实践了。5、我们做了哪些实践和创新？有一句名言是这样说的：实践是检验真理的唯一标准。诚然，成功人士的背后，有着你看不见的努力和坚持。1.实践在实践过程中，需要考虑的因素很多，列举如下：如何将现有小程序的原生代码转换为多终端项目编写方式，保证转换后的代码可读可控。现有小程序的部分功能逻辑需要完整保留，甚至是小程序的原生API和逻辑，这些如何与多端项目共存。如何将H5代码逻辑最大化复用到多端项目中。如何优雅地将H5的各种组件、设计模式、工程、工具方法适配到多端项目中。等等……那么我们如何处理这些因素呢？我们可以用一张图来概括它的整体，如下图所示：下面介绍我们是如何处理这些因素的。2、代码转换如何将现有小程序的原始代码转换为多端项目编写方式，保证转换后的代码可读可控？我们使用开源的converterminiprogram-to-uniapp来做转换，然后手动解决转换过程中的不匹配问题。解决方案是如此简单和朴实无华。可能大家觉得方案很简单，但是在选择这个方案的背后，我们做了详细的评测，包括和开源转换器作者的微信交流。在与笔者交流的过程中，我们了解了这个转换器的过去、现在和未来，在当时的情况下是一个合适且正确的解决方案。3.代码共存现有小程序的部分功能逻辑需要完整保留，甚至是小程序原生的API和逻辑。这些如何与多终端项目共存？我们通过将项目划分到合理的目录中实现自然隔离，如下图所示：我们将一些尚不能适配多终端的代码放到platforms目录下。此外，我们将使用条件编译来隔离无法转换为多端口的平台。如下图所示：4.重用和适配h5重用是个偷懒的词。如果可以直接复用，就果断复用。不做二次调整，保证与H5高度一致。适应强调的是不改变就适应一切变化。我们不需要改动H5的代码，只需要为他们做一个适配层，比如适配H5路由，适配一些不兼容的组件，甚至是适配窗口。位置很好。从上面介绍的解决方案中，我们可以体会到应对这些因素的核心秘诀是以下两句话：第一句话：因地制宜，找到平衡。第二句：提高重用，减少变更。5、创新有句话是这样说的：平凡中孕育着伟大。说到这里，我们换个说法，就是创新是在实践中孕育出来的。在实践过程中，我们解决了很多问题。在解决问题的过程中，我们做出了一些激动人心的创新。Vuex的创新这个创新来源于一个问题。这个问题的背景是这样的：商城H5商品详情页使用vuex来管理数据。在将vuex移动到小程序的商品详情页时，发现一个现象，如下动画所示：从上面的动画中，我们发现在使用vuex的时候，我们从商品A的商品详情页点击商品B到进入B商品的详情页，此时我们点击左上角返回到A的商品详情页，我们会发现此时商品详情页变成了B商品，也就是说，产品A的数据就没有了。这是一个非常大的问题。经查，原因如下：vuex的命名空间默认是一个，不能自动添加命名空间。在小程序页面使用vuex进行数据管理时，由于小程序页面的数据机制，点击返回时，页面数据使用相同的vuex数据，导致出现上述现象。这里，可能有人会说，在onShow生命周期中，刷新数据，不就解决了吗？其实在这种场景下，刷新数据是非常不合理的。那么如何解决呢？我们知道，使用vuex后，小程序页面数据多次进入同一个页面后会出现显示问题。随后，在群里进行了讨论。综合权衡后，还是决定继续使用vuex，通过给vuex加一个适配层来解决这个问题。随后在群里进行了讨论，综合权衡后决定继续使用vuex。通过给vuex增加一个适配层来解决这个问题。首先我们看一下给vuex添加适配层后执行上面的操作会发生什么。如下动画所示：从上面的动画我们可以发现，在vuex中添加了一个适配层之后。成功解决小程序页面数据使用vuex多次进入同一页面点击返回时出现的显示问题。我们是如何解决这个问题的？核心方案：通过让vuex支持namespace的自动扩容和自动注销，实现更智能的数据流管理方案。核心架构图如下所示，通过在store中自动生成命名空间，保证多次进入同一个页面后，每个页面的数据都保留下来。当页面返回时，通过动态收集父组件的命名空间来完成父子组件的命名空间关联。通过以上技术方案，我们解决了在小程序中使用vuex时存在的问题。这里已经给出了核心架构方案，具体实现不再赘述。6.脱钩创新这种创新源于一个问题。这个问题的背景是这样的：我们现在有普通、秒杀、团购的商品详情页，以后还会有其他的商品详情页，那么如何复用这些详情页中的内容呢？业务组件呢？面对以上问题，你会有以下想法：不同的页面，业务组件中的数据处理是不同的页面，业务组件中的埋点是不同的页面，业务组件中可能有特定的接口请求，你应该会被以上考虑。业务组件的复用非常困难，完全解耦更难。那么，我们如何实现尽可能多的解耦呢？我们做了以下几点：保证埋点在上游是统一的，通过组件层面的埋点设计实现埋点统一。在组件层面，对具体的接口进行条件判断。业务组件的数据被分解为源数据和派生数据。源数据在vuex层面保证一致，派生数据在业务组件中根据实际情况做相应适配。改造vuex，使业务组件与页面的通信完全解耦，业务组件不再需要知道页面的vuex命名空间。开发过mall项目的同学应该都知道，selected层的逻辑是非常复杂的。这里我们以选中层业务组件为例，来说明我们是如何复用业务组件的。以下是目前为止复用的精选炸弹层组件的组成：├──components│├──sku-number│├──sku-product│├──sku-service│├──sku-spec│└──...├──index.js├──index.scss├──index.vue├──mutation-types.js└──track.js我们将选中的炸弹层组件的数据分为sourcedata和Deriveddata，sourcedata是通过vuex层统一起来的，如下图：我们为每个详情页写一个vuex，同时把相同的部分提取到common-detail中。之后我们在vuex中进行处理，保证不同页面给的源数据是一样的。这些源数据将被传递给业务组件。如下代码所示：//这是选中层的业务组件//通过@vivo/smartximport{mapState,mapGetters,mapMutations,mapActions}from'@vivo/smartx'/解耦组件和页面之间的通信/获取源数据计算：{...mapState(['spuInfo','skuInfo']),...mapGetters(['price','pageType']),}methods:{fn(){//strategymode}}通过以上处理，可以很好地将相似的业务组件与不同的页面解耦，从而提高代码的复用性、可维护性和可扩展性。这种解耦业务组件的思路是：不需要将数据和视图完全分离，通过源数据和派生数据，平衡可变和不变的数据，然后使用自研的@vivo/smartxtochangetothesameBecomeanisland，从不变变为成为岛屿。每一次创新都是一次考验。它总是在不经意间给你带来困难，然后逼迫你突破自我，从而创造出更好的东西，如此循环往复。终于上线了多终端架构的vivo官方商城微信小程序。大家可以点击vivo官方商城进行体验。6、小结在这篇文章中，我们回顾了vivo商城微信小程序的多端统一。从业务需求、存在价值，到技术实践与创新，我们希望用技术让多端之路更加顺畅。vivo官网商城前端团队
