作者：叶遥、颂晨
闲鱼号在闲鱼业务中一直承担着非常重要的角色，它既是卖家组织商品的货架，又是达人自我表达的载体，既是大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
