简述店铺浏览闭环后，由于各端数据和渲染分离，导致代码无法复用，导致研发成本增加；同时，技术栈多年没有升级，前后矛盾，严重落后于竞争对手。对ISV开放性的支持程度也停滞不前。针对这一系列问题，商城研发团队启动了多端融合降本增效项目，决心对多端渲染全部进行升级重写，从底层能力上解决了上述所有问题，使商店浏览从原来的重复发展1.0时代进入了代码多端复用的新时代2.0。背景店铺团队为京东数十万商户提供快速搭建页面并展示在不同APP、M站、京购小程序上的能力。同时，还引入ISV服务商，为商家提供定制化的地板开发，帮助商家提高产品销售转化；其次，ISV模板的销售也能为京东每年带来数百万的额外收入。多年来，店铺装修端和商家的各个浏览端，一直由不同的团队维护。2021年上半年，由于业务调整，所有闭环将对智浦团队进行闭环。在闭环前期，我们梳理了各个端的业务状态，发现了几个比较大的问题。一是各浏览器端显示效果不一致，APP端、M站、京购商城页面功能不一致。二是各个系统的技术栈不统一。服务器端也有用C语言开发的应用程序。在前端，技术栈也多种多样，导致这些系统的维护成本很高。如果一个需求是要在所有终端上展示，那么就需要在每个终端上开发，压力很大，而且测试上线的成本也很高。三是业务关闭后，人力资源并没有增加，相当于原来的资源只开发了装修端的业务，现在需要承担另外三个浏览端的业务需求。同时，在渲染技术方面，竞品门店全面切换至自研小程序渲染。无论是需求开发效率还是ISV模板开发效率，都远高于京东商城RN开发技术。同时，随着竞品APP小程序基础能力的全面铺开，其他业务也可以轻松在竞品门店展示。但由于京东商城APP采用RN技术渲染，楼层间无法插入外部楼层。因此，考虑到目前的经营状况，店铺的多终端融合势在必行，需要在每个终端上展示一套代码。其次，在店铺渲染技术方面，也需要摒弃RN，向竞品店铺技术看齐。只有这样，才能提高团队和ISV服务商的开发效率，同时扩展门店接入其他业务的基础设施能力。现有的各端渲染流程是为了解决商家更换模板后，能够在APP端实时生效的问题。智能店铺装修系统目前采用“XML模板转JSON动态传递方案”，通过XML定义每套模板的结构和样式。商户装修店铺后，服务器将装修数据和XML定义的样式解析成JSON格式发送给各个展示终端。这样做最大的好处就是APP端无需集成跟版，可以在线随时更换不同的模板样式。但是这也产生了一个很大的问题，因为M站和小程序都可以支持Js模板渲染，但是现在我们只能通过解析这组JSON数据来获取模板进行渲染。同时，由于浏览器维护团队的不一致，各团队的服务器在收到JSON数据后重新打包。这样做的直接结果就是接口数据格式根本就不统一。其次，各个团队的前端也开发了解析库来解析这组JSON数据，所以这些解析库根本无法复用。其次，由于应用是独立的，支持的终端多，部署的线上项目也多。解决方案需要解决的问题基于以上背景以及目前各终端的渲染状态，门店多终端融合需要考虑四个问题：一是服务端数据要统一，必须输出一组标准数据格式定义。其次，前端需要统一多端渲染，让一套代码在不同端开发使用。第三，前端渲染集成后，各个店铺首页的性能不能降低，不能影响用户体验。最后，门店的多终端融合还需要解决ISV开发楼层模板的效率问题。由于内容较多，我们重点介绍一下两端的“前端渲染集成方案”和“首屏性能保障方案”。前端渲染集成方案01方案设计由于门店目前采用的是“XML模板转JSON动态投放方案”，因此有多套解析库来解析这组数据，造成重复工作量的问题。因此，第一套集成方案是“APP解析库与小程序解析库共存方案”。左图中，对于服务端统一下发的数据，前端开发了一个统一的解析库，里面包含两套逻辑，一是通过RN解析库实现京东APP之间的复用，然后通过JDReact转化为H5统一M站店铺和装修端预览。另一套逻辑是通过小程序解析和库实现京购小程序商店和京东小程序业务的统一。该方案对现有APP端业务改动较小，属于半集成方案，由于仍需维护两套分析逻辑，因此只能减少30%-40%的工作量。同时，上面分析的几个问题也没有得到解决。首先，H5和小程序还需要一个解析库来解析得到模板样式，效率低下。其次，ISV仍然只能开发RN模板，效率并没有得到提升。;三是在技术统一性和可扩展性方面，仍然落后于竞品门店。第二种方案是“多终端统一RN方案”。该方案对全店各端的浏览和渲染技术进行了全面升级。右上图中，通过京东开源的太郎技术方案，首先开发了一个静态资源的多端融合项目。APP端，通过京东平台事业部的JDHybrid解决方案，创建H5离线包，将离线包预下载到用户APP中。当用户打开店铺时，会将离线包资源注入到店铺原有的webview页面中，杜绝静态资源请求，访问性能得到大幅提升。M端和PC端，通过Taro转换H5页面，支持店铺的M站和PC端的预览页。小程序端，直接打出小程序包，支持京购小程序门店、京东小程序等业务场景。这套方案彻底解决了以上所有问题，团队在面对多端业务需求时，工作量可降低60-70%。同时由于h5和小程序可以直接获取模板样式，渲染性能也得到了提升；ISV不再开发低效的RN模板，通过多终端融合方案，也可以在每个终端展示一套模板；总体而言，在技术和可扩展性方面，它也与竞争商店保持一致。目前APP商店页面已经实现了原楼层和webview楼层的共同展示。我们也在开发将京东小程序嵌入到店铺首页展示，增加webview复用，保证性能。上线后，商店首页将具备同时渲染原生+H5+小程序的基础设施能力。其他商家只需要按照这套技术体系，也可以快速渲染店铺内的H5楼层和小程序楼层。02总体方案概述整个“多端统一RN去除方案”包括：H5与APP整合、H5与小程序整合、Nodejs服务、ISV跨端开放四大主要解决方案；以及异常、容灾、性能、监控四大扩容方案；因为方案很多，这里就不一一详述了。如果有同学对这套方案感兴趣，可以联系我们智浦团队进行交流。首屏性能保障方案各终端首屏性能方面，目前IOS端和Android端，店铺原楼层混合RN楼层首屏渲染时间约为0.7-1秒；M站商店需要4s左右；购买一个小程序商店大约需要2.5秒。因此，三个终端的现有渲染时间是本次多终端融合的参考基准。01核心保障措施在IOS端。Hybrid离线包用于减少页面和静态资源的请求时间，webview容器在第一次进入store时就开始初始化。其次，将耗时的图片放在最后进行懒加载。问。通过这些措施，在首屏渲染5层楼的前提下，用户可以感知首屏耗时约800毫秒，整体时间与线上原生+RN渲染的表现一致。这里有两点可以继续优化。比如可以在点击店铺入口时放置数据接口请求。其次，目前服务器端的数据接口需要时间来返回首页的所有数据。如果改为只返回首屏的数据，或者加入缓存措施，这样也可以有效减少数据请求的耗时，最终也会体现在首屏的耗时减少上。.在Android端，服务器端数据接口请求在用户点击商店入口时开始。当用户进入商店时，数据请求时间消耗减少了近一半。同时，通过Hybrid离线包方案，安卓端首屏时间也与在线时间保持一致。还有几个点可以进一步优化，比如界面耗时优化，进店时提前进行webview初始化和静态资源注入。这样也可以有效提高店铺的访问性能。02综合保护措施除了上面使用的优化措施外，还针对不同的目的使用了一些优化措施。APP端也采用了静态资源文件合并的措施，降低离线包加载失败时加载在线H5页面的性能。.以及骨架屏、地板、图片懒加载等措施。在小程序端和M站，也采用了H5端的骨架屏、懒加载、浏览器离线缓存等方案来提升页面性能。Fusionbenefit01首屏性能提升多端融合后，新首页在IOS和Android上的首屏性能与在线原生+RN的渲染性能基本一致。M站和精狗小程序尚未全面上线，预计会有较大提升。02ISV开放能力提升目前门店仅开放APP端RN自定义模板给ISV。RN受限于技术本身，无法很好地支持三终端。同时，由于开发环境复杂，调试困难，极大地影响了ISV的开发效率。与竞品ISV开发相比，同一套效果相似的模板平均开发时间要长1-2倍。基于Taro规范开发的用于多端融合的技术栈，商店现已实现统一的多端渲染库，ISV仅开发一套代码，稍作调整即可支持三端，并且效率也会大大提高。推动。03人效及其他提升人效方面，涉及多端渲染需求，人力投入较之前减少56%，工时减少66%。数据接口也在服务器端统一，人工成本降低30%-50%。同时，在技术专利和文章积累方面，也通过了3项技术专利，其中2项还在筹备阶段。其次，4篇技术文章也在陆续写中。技术展望前端技术经过十余年的发展，技术栈和技术框架迭代比较快，需要业务支撑的显示终端也越来越多。如果每个终端都需要重复开发，那么这个人力消耗肯定是不行的。可忍受的。因此，需要权衡各种因素，找到一个前端技术的最佳组合实践，而这个原则必须是一套代码，多端适配和复用。但是，受限于互联网技术的发展和各厂商自身利益的选择，在前端渲染方面，还不可能统一成一套标准的技术栈，能够自然地运行在各厂商提供的软件上.于是，各种奇门遁甲兼容技术应运而生。无论是开发规范兼容、底层引擎兼容，还是配置交付兼容等，都是各方追求统一的尝试。道路越简单，用户接受起来就越快，学习和使用成本最低的技术才能一直走下去。或许有一天，基于W3C体系的技术规范会逐渐被各厂商所接受，并与底层引擎适配兼容。
