中国联通网站备案及ip地址备案管理要求,WordPress博客自动更新文章,开发公司成本管理,电脑上重新下载一个wordpress如何应对产品形态与产品节奏相对确定情况下转变为『在业务需求与产品形态高度不确定性的情况下#xff0c;如何实现业务交付时间与交付质量的确定性』。我们希望通过混合架构#xff08;Native 业务容器 Weex 2.0#xff09;作为未来交易终端架构的重要演进方向#xff0c… 如何应对产品形态与产品节奏相对确定情况下转变为『在业务需求与产品形态高度不确定性的情况下如何实现业务交付时间与交付质量的确定性』。我们希望通过混合架构Native 业务容器 Weex 2.0作为未来交易终端架构的重要演进方向在 Native 容器侧充分发挥原生语言的性能优势、常驻 App 的调控与管控能力、手势识别与交互优势来解决体验问题。本专题《淘宝交易终端架构探索》是我们摸索出的部分实践总结欢迎大家一起交流进步。 第一篇《Weex购物车长列表横滑操作优化“编年史”》 第二篇《淘宝页面首帧优化的经验和心得》 第三篇《淘宝App交易链路终端混合场景体验探索》本篇 第四篇《淘宝订单列表Fragment转场动画卡顿解决方案》待发布 第五篇《探索淘宝购物车SurfaceView闪黑的解决方案》待发布 前言 ▐ 名词释义 DinamicXDX一个提供多端统一能力且高性能、高可用的客户端动态化解决方案不依赖发版即可完成UI及部分逻辑的更新。Weex一个可以使用现代化 Web 技术栈开发高性能跨端应用的框架在标准化、性能、开发体验等方面都有大幅提升。Orange/一休提供配置动态下发、AB实验分流及业务数据分析等能力。JSTracker端到端的前端监控与数据分析平台覆盖用户体验、安全生产等方向打造实时监控、多端覆盖、智能化的数据平台。 诞生背景 ▐ 基础交易链路是什么 作为电商的核心链路之一基础交易链路由一系列流程和节点驱动。其立足于选到支、支到用两个核心场景重要程度不言而喻也具备了巨大的流量价值。 购物车下单支付成功订单列表订单详情物流详情退款详情 对于业务开发而言交易链路的性能体验和迭代效率成为重中之重。性能体验需要从用户视角出发重点关注勾选、支付、列表、详情等多个场景的首屏时长、滑动帧率、页面稳定性等而迭代效率的核心在于快速上线、想发就发以满足复杂多变的业务需求。 ▐ 终端技术侧演进 为了持续提升性能体验与迭代效率终端技术侧也在不断探索与革新从纯原生客户端开发模式逐步过渡到客户端前端的跨端开发模式。基于传统的纯原生开发通常能带来较好的性能体验但同样面临着几大挑战 发版效率。以周迭代模式为例从业务代码提交集成到经历多轮灰度验证再到上架应用市场逐渐成为主版本一般需要两周左右。如果以月迭代模式开发则需要更长的版本发布时间。业务需求交付周期较长新功能更新迭代较慢也就无法带来极致的用户体验。开发效率。从渲染逻辑来看原生UI组件的动态性不足复杂布局的改动对于客户端版本具有较强的依赖性从业务逻辑来看受限于平台差异业务逻辑的复用性较差无法实现逻辑的动态编排。多端一致性。对于同一个产品需求需要Android、iOS和Harmony多端开发投入人力翻倍而且多端代码不一致可能会带来潜在的稳定性风险。长尾碎片化。考虑到客户端版本及用户更新频率Android、iOS和Harmony多端都存在长尾碎片化问题在功能兼容性和版本稳定性上都面临着严峻的挑战。 为了解决上述问题多年来客户端架构不断迭代升级通过引入DinamicX等高性能解决方案在动态性和通用性做到了较高的水准但与前端灵活的研发模式相比仍存在一些不足 迭代效率。以订单搜索空结果优化页面为例如果采用客户端方案开发不仅需要多端人力投入还要重点关注信息流嵌套滚动等相关问题实现方案也具有较大的平台差异性而采用前端方案开发不仅能极大降低人力成本在关键问题的处理方案上也能够实现多端统一。考虑到以上原因我们选择了基于前端开发的技术方案实现了本功能的快速迭代上线。性能优化。前端技术架构不断演进不断追求着高性能的目标。不管是Web框架还是Weex1.0/2.0框架都通过多种容器层和业务层的硬优化手段在首屏性能、滑动帧率和CPU占用率等方向展现了不俗的成绩。 但是仅仅依靠单端的努力还不足以满足复杂多变的交易业务场景。为了实现性能体验不劣于客户端、研发效率不逊于前端的目标我们提出了交易终端混合架构 —— 其基于原生平台容器结合Weex渲染框架提供了高性能高效率的开发迭代模式目前已应用于订单详情、支付成功、退款列表、物流详情等多个交易核心场景。 架构设计与业务实践 ▐ 基础架构 交易终端混合架构旨在提升迭代效率、优化性能体验其为前端页面提供客户端原生容器支持开放多种性能优化能力供业务选择。该架构提供容器管理、实例管理、数据管理、资源管理、逻辑管理五大核心功能目前已在Android、iOS和Harmony三端落地并服务于多个核心业务场景。总体而言该架构主要具备三个核心优势 配置驱动能力。混合架构的各项功能由一系列配置驱动接入方仅需根据自身业务特点选择适合的功能配置即可享受混合架构带来的性能收益。运行管控内聚。各个性能优化管理器由混合架构统一调配性能数据由内部JSTracker监控各接入业务亦可通过Orange/一休实验控制放量或观察收益。扩展定制便捷。混合架构支持业务自定义性能优化能力接入对内基于白名单过滤业务场景对外提供静态/动态注册方式便于业务方自行扩展优化策略。 下图展示了混合架构的整体设计思路接下来将逐一讲解各个功能模块。 路由导航。此模块基于应用内导航能力配置hostpathquery的混合架构统一拦截规则增加混合架构query参数匹配进行页面二次过滤进一步提升了业务接入的稳定性。同时Android端还可在特定场景下拦截至混合架构的Fragment相邻页面共用同一个Activity进一步降低了容器导航耗时。业务配置。此模块由各业务方数据配置组合而成各业务按需配置、互相独立混合架构将基于此配置对业务方提供各类能力。业务配置可类比为一棵多叉树以业务配置为根节点进而衍生出订单列表、下单等多个业务子节点而各个子节点又根据所需能力继续衍生出多个功能节点如订单列表会衍生出容器管理、实例管理、资源管理等多个节点各个功能节点亦可继续衍生子节点。开关与实验。此模块集成了Orange和一休实验的相关能力既可控制功能放量又可观测性能收益。为了优化配置下发的滞后性开关读取时机由配置创建时修改为能力使用时增强了配置更新的及时性。子管理器。此模块作为混合架构的核心模块提供了容器管理、实例管理、数据管理、资源管理、逻辑管理等五大功能。后面章节会做详细阐述在此不加赘述容器组件。此模块可为前端页面提供容器侧支持封装了页面埋点、页面回退等通用能力。此外Android端除了Activity组件外还额外提供了Fragment容器选项支持路由导航与DinamicX事件链两种模式接入进一步提升了容器的基础性能体验。性能监控。作为混合架构的坚实后盾性能监控可为接入方提供页面性能和稳定性的双重保障现已接入JSTracker实时监控平台。接入方既可通过预热命中率/使用率、预请求命中率/使用率等指标监控页面性能评估混合容器带来的收益又可通过网络接口监控、页面白屏等指标监测接入页面的稳定性保证页面的正常运行。对外能力。混合架构对外提供三端统一且易于接入的API支持客户端调用Native方法和前端调用JSBridge方法两种方式。简言之业务方在某个场景下的特定时机点传入相关业务参数即可使用混合架构的性能优化能力。 ▐ 性能优化容器管理 要想使用混合架构的各种性能优化能力必然离不开容器侧的支持。在架构建立初期我们提供了ViewController、Activity等组件来承担页面容器的职责。但对于Android平台而言基于Activity的页面容器虽然具有较强的通用性和较好的稳定性但相对耗时的导航阶段无法将混合架构的性能优势发挥到极致因此我们还提供了Fragment容器能力供业务方选择。为了方便外部接入除了业务方主动调用事务添加Fragment外还支持路由导航与DinamicX事件链两种模式接入。 路由导航当前页面和上一跳页面共用同一个混合架构的Activity时可考虑通过路由的方式接入。通过页面拼接参数的方式路由到混合架构的拦截器混合架构便可在内部完成Fragment容器的页面切换。该方式已在“支付成功-订单详情”的链路中使用显著减低了此路径下跳转到订单详情的导航时长。DinamicX事件链交易业务的Native页面大都接入了奥创体系而DX事件链作为重要组成部分可将用户操作产生的多个事件串联在一起。以订单列表为例作为购后的核心页面用户可基于订单列表跳转至诸多交易场景。而订单列表采用奥创体系搭建我们新增的跳转至Fragment的原子能力便可轻松接入。当业务方想要接入Fragment时只需在DX平台上新增事件链并在Native端编写模板代码即可。 ▐ 性能优化实例管理 现阶段交易域前端页面大都基于Weex架构开发Weex架构的优势显而易见但结合具体的交易域业务场景来看在某些方面仍有可以挖掘的优化空间如导航时间较长、容器初始化较慢等。在整个交易流程链路中考虑到用户路径较为连续在前置页面的空闲时机为后置页面提供实例管理的性能优化也就成为了可能。 实例管理简而言之就是提前渲染Weex实例并对Weex实例进行精细化管理目前混合架构已支持Weex实例的同步预热和异步预热。值得注意的是当业务方接入异步预热功能时往往能带来更大的收益原因有二一是Weex实例预热不再阻塞主线程主线程的性能空间得以进一步释放二是前端页面能够基于异步预热开展提前布局也就进一步提升了首屏性能。 混合架构的实例管理功能当前已接入多个业务场景首屏时长收益较为显著低端机首屏时长优化约20%。接下来以订单列表进入订单详情为例简要介绍实例管理的核心流程。 1. 如上文基础架构所言订单详情要想使用混合架构的实例管理能力第一步就是要将其所需要的功能参数写入基础配置之中。实例管理已支持自定义预热时机点如路由统跳时、容器创建时等、自定义回收策略回收复用等、自定义销毁策略直接销毁、低内存销毁、特定时机销毁等等多种能力。 预热配置: [{业务身份标识,预热URL,预热时机,回收策略,销毁策略,...},{...}
] 2.进入订单列表页面闲时后客户端即可调用onStage方法预热订单详情的Weex实例并将其放入实例缓存池中缓存池的容量上限同样由配置决定。 3.用户点击进入订单详情时获取池中缓存的预热实例并将业务所需的参数通过消息传递给预热实例即可完成页面的最终展示。 ▐ 性能优化数据管理 Weex实例提前预热和Fragment优化解决了容器耗时及导航耗时的问题但仍然无法减少页面网络请求带来的时间开销。为了进一步降低P95首屏时长混合架构为接入方提供了数据管理的通用能力。通过提前发起网络预请求结合本地缓存策略后续页面即可立即使用缓存数据而无需再次发起网络请求也就进一步缩短了页面“白屏”时长。对于客户端页面预请求数据可持久化到内存及磁盘对于前端页面可通过Weex消息通道直接传递预请求数据。 从请求发起方来看网络预请求可分为两类第一类是由客户端主动发起的网络预请求通过配置网络请求的具体参数在合适的前置时机直接请求网络然后进行数据缓存或数据传递此种方式可应用于客户端页面的主接口请求如订单列表主接口及前端页面的主接口请求如支付成功主接口第二类是由前端主动发起的网络预请求客户端只需提前将必要的业务参数发送给前端的Weex实例前端页面收到数据后自行发起网络请求此种方式可应用于前端页面的附加请求如支付成功信息流接口。 接下来我们以下单商品跳转支付成功为例简要阐述数据管理的相关流程。 1.与实例管理配置类似数据管理功能同样提供了相关配置供业务方选择。这里支付成功页面主接口选择客户端预请求的方式支付成功页面信息流接口因依赖主接口数据返回故选择前端预请求的方式。 预请求配置: [{业务身份标识,预请求时机,网络请求配置,缓存配置,...},...
] 2.点击立即支付按钮会调用混合架构提供的JSBridge预热支付成功的Weex实例并发起创单请求。 3.订单创建成功后跳转至收银台页面客户端即可调用onStage方法发起接口预请求并将请求到的数据提前发送给Weex实例。 4.用户付款成功跳转至支付成功页面时支付成功的Weex实例使用提前拿到的数据渲染上屏即可。 此外Android端支付成功场景还接入了异步预热提前布局的能力P95首屏时长也得到了进一步压缩。 ▐ 性能优化资源管理 我们基于容器管理降低了导航耗时使用实例管理降低了容器耗时借助数据管理减少了页面请求耗时那么前端页面需要的资源是否也能够通过提前缓存来进一步减少首屏时长呢混合架构提供的资源管理能力恰好解决了此类问题。资源管理主要分为ZCache资源管理和图片资源管理两大部分 ZCache管理 淘宝App内部提供的ZCache能力可以将前端所需的 html、js、css 等资源打包客户端选择合适的时机提前下载到本地后用户浏览页面时就无需重复下载有效提升了页面加载性能。ZCache提供了访问时安装、闲时安装、启动安装三种方式且默认设置为访问时安装。但通过统计交易域ZCache命中率发现此类安装方式命中率并不高P95收益不及预期。考虑到交易链路的连续性强用户动线清晰贯穿购前、购中和购后整条链路比如 购物车-下单-支付-订单因此在诸多场景下都可为后续页面进行ZCache预取。 因此ZCache管理提供了客户端预取和前端预取JSBridge两种方式其基于场景维度预取页面ZCache资源。客户端内置核心页面ZCache资源名称并可通过Orange配置动态下发预取包名。例如当我们想要在某个场景预取ZCache资源时只需动态配置Orange即可这也极大地提升了ZCache管理的灵活性。经历多个版本迭代在ZCache团队的大力支持下交易域核心场景页面访问已基本实现本地资源的直接利用。 图片管理 借助ZCache管理能力极大地降低了页面资源的拉取耗时但想要进一步压缩资源加载时间就不得不提到图片资源管理。在交易域多图场景下如订单列表、支付成功等由于图片数量较多如果进入页面后再发起图片请求累积起来的图片加载总时长从P95分位来看就非常惊人。 与ZCache预取的思路一致在交易链路特定前置路径上亦可对后续页面发起异步图片预取请求。这样一来在用户进入后续页面时图片即可命中内存/磁盘缓存而不必发起网络请求。同样的图片管理模块也提供了客户端预取和前端预取两种方式供接入方灵活使用。 ▐ 性能优化逻辑管理 实例管理、数据管理和资源管理是混合架构性能优化的三板斧三个模块各司其职从不同的角度提升了页面性能也极大改善了用户体验。但随着交易业务的持续发展对混合架构也提出了新的要求。对于某些场景而言虽然无需使用混合架构的性能优化能力但仍需要依赖其他业务调用混合架构的时机点开展业务定制优化。本着“对扩展开放对修改关闭”的原则我们又提供了逻辑管理模块。逻辑管理模块收敛了各业务调用混合容器的时机采用白名单注解的方式过滤接入业务减少了上层业务对底层架构的入侵。此模块当前已接入购物车、逆向、下单等多个业务各业务相互隔离可基于实际场景实现各自的优化逻辑。 ▐ 快速接入 对于业务方而言混合架构提供了简单高效的接入方式只需三步即可享受混合架构带来的性能优化收益。 STEP1前端页面URL配置到导航能力的拦截规则之中并拼接tradeHybridtrue参数。 STEP2按需选择性能优化能力容器管理、实例管理、数据管理、资源管理或逻辑管理配置性能优化的具体参数并将其写入混合架构的通用配置。 STEP3按需配置Orange开关及一休实验控制放量节奏即可完成业务接入。 成果展示 基于交易终端混合架构结合各个前端页面的性能优化方案交易核心场景线上P95首屏时长均有较大优化其中订单详情、支付成功等场景的优化幅度更是达到70%以上。接下来我们以Android端为例简要介绍几个典型场景的容器接入方案并使用低端机型进行线下对比测试。 1.订单详情使用Fragment替代Activity作为页面承载单元在订单列表页面闲时进行资源预取ZCache及商品主图、实例预热及精细化数据预请求。线下对比测试视频如下 2.支付成功与订单详情类似在支付成功的前置链路也进行了资源预取ZCache及页面图片、实例预热及数据预请求。与此同时支付成功还接入了Weex提供的异步实例预热提前布局能力线上P95首屏时长进一步压缩。线下对比测试视频如下 3. 物流详情物流详情同样使用了Fragment来减少导航耗时再结合资源预取及实例预热取得了阶段性优化成果。后续将逐步接入更多混合架构的性能优化能力进一步降低首屏时长。线下对比测试视频如下 未来展望 以上章节介绍了混合架构当前的设计思路和优化手段未来将继续从链路级优化、容器丰富化、能力多样化、多端一致性和调度智能化等方向继续探索混合架构的可能性。 团队介绍 我们是淘天集团-基础交易终端团队一支专注于手淘APP交易域购物车、下单、订单、物流等业务研发和体验优化的技术团队。在丰富的业务场景下我们通过持续的技术探索、不断的创新突破给数亿用户提供极致可靠的交易保障、极致流畅的操作交互以及极致顺滑的购物体验。 ¤ 拓展阅读 ¤ 3DXR技术 | 终端技术 | 音视频技术 服务端技术 | 技术质量 | 数据算法
