作者:叶遥、颂晨
闲鱼号在闲鱼业务中一直承担着非常重要的角色,它既是卖家组织商品的货架,又是达人自我表达的载体,既是大V私域运营的阵地,又是小铺开店经营的门面。它是闲鱼各产品线的交汇点,号店浑然一体,一定要类比的话,它更像是抖音/小红书个人主页+淘宝店的综合体。
闲鱼号是个用户高频访问的场景,产品Feature快速迭代,体验上备受关注,当下面临的问题:
• 古董级高度耦合的业务代码、多业务线并行的日常需求时常让前端成为交付瓶颈。
• 基于Weex 1.0渲染附带着大量的双端不一致问题和体验顽疾,也限制了交互创新。
最近我们对闲鱼号做了架构升级,相信很快就会和大家见面,这里做个小结,概括下来这次升级直接带来的收益:
1. 体验
中高端机上维持秒开,同时:
• 新增微信朋友圈式的下拉封面交互,手势体感更加连贯,个人表达更加充分。
• 新增贴近原生体验的下拉刷新交互,提升APP体验一致性。
• 优化嵌套滚动的交互体验,纵划横划更加自然顺滑,逛起来更高效。
2. 可维护性
可维护性的提升是「产品->设计->实现」综合优化的结果,具体:
• 产品侧重新梳理所有Features,抽象并制订同类功能的表达原则,确定各业务的表达方式、优先级。
• 设计侧综合考虑模块权重、所属角色、用户比例、扩展方式等因素确定设计框架。
• 技术侧通过组件化拆分+全局状态的方式解耦业务逻辑,提高需求并行效率。
一、 为什么要升级
闲鱼号项目已有超过5年历史,目前业务较难向前迭代,原因主要归结为端容器能力受限和架构腐化两方面。
1. 端容器能力受限
闲鱼号目前是前端页面,容器使用Weex1.0(后文统称Weex)。Weex两年前就少有维护,其既有问题使得承载当下业务有以下问题:
• 难维护。闲鱼号存在较多的舆情顽疾,究其原因,Weex不是标准前端容器,在布局、组件、动画、事件等方面与预期不一致。一部分绕道解决,一部分只能保持现状依托升级容器解决。
• 难做好体验。业务定位使闲鱼号在体验上有较高要求,但“这个交互是Native实现的,Weex做不了”不时会出现在业务迭代的技术评估中。
2. 项目架构腐化
闲鱼号有较高的业务复杂度和较厚重的历史上下文。承载了人设、电商、内容、信任等领域的业务,同时存在多维度视图(主/客态、B/C态、内容/电商态),多年下来已发展到5.x版本,技术架构仍未进行过本质升级,相关问题已严重影响项目日常维护和迭代,主要体现在:
1) ViewModel过于复杂。ViewModel是大管家,统一格式化、将数据派发到模块。在平铺了15+模块数据的场景,ViewModel改动不时“牵一发而动全身”。
2) 缺乏统一的状态共享方案,数据流混乱。组件间通信存在Vue事件体系、自建事件体系、全局controller、自建状态共享体系多种方式。
二、 升级目标
对应上述问题,闲鱼号迎来了技术架构升级。升级核心目标是,未来1-2年技术架构不成为项目迭代、维护的吞吐瓶颈,支撑业务快速、平稳、创新的发展,能持续保持高标准体验。其中:
• 容器能力:升级渲染容器,提升容器能力边界。明显减少存量体验顽疾,多场景协助业务、设计完成理想的交互、视觉体验。
• 项目架构:模块解耦,打造清晰的数据流。明显提升迭代效率,减少影响面回归成本和压力,降低不同模块协作冲突次数。
其中针对项目架构部分非本文重点,主要通过模块化前端后数据协议、统一状态管理方案进行了解决。后文继续介绍容器能力部分的思考和实践。
接下篇:https://developer.aliyun.com/article/1225888?groupCode=idlefish