简介：鱼乐圈上线啦～

闲鱼会玩社区的重要阵地：会玩圈子今年年初曾经上线啦~

作为一款承载着「基于趣味汇集同好人群」的社区型产品，相较于惯例导购型产品来说，在业务复杂度、交互复杂度、性能体验稳定性要求上都要高出许多，像 多角色辨别 、 嵌套滚动 、 多状态 Feeds 有限加载 、 颜文字等特殊字符解决 、 页面直开 、 视频播控 等场景都是导购场景很少遇到的。

本文将围绕着会玩圈子的前端设计、开发过程中遇到的典型问题进行介绍。

要害设计

如上图为会玩圈子的设计大图，能够看到整体的业务逻辑绝对较为简单。并且因为利用中存在 多种角色状态，不同角色的用户展现界面和操作逻辑也有差别点存在，前端同学进行开发上手的老本较高。

为了升高前端同学在开发过程中对于全局业务了解的老本，缩小沟通中信息传递容易脱漏的问题。咱们在设计之初首先进行了最小模块的拆分工作。以模块维度来调配相应的工作，将模块间存在数据共享和数据通信行为进行梳理拆解，以最优形式来调配数据状态保护的最小闭环，升高组件间耦合度。

1. 模块拆分

========

在此处定义的模块不是前端日常开发中所讲的模块组件拆分，而是可能独立闭环自成体系的一个业务单元。这样在我的项目过程中除了局部组件间数据传递须要做事后约定外，前端同学仅仅只须要专一于本人所负责的交互场景即可。

以圈子模块主页为例，依据设计稿咱们将它拆分为了三个独立的业务模块：圈子信息模块、信息流模块和浮层组件模块，他们无论从性能上还是展现上都齐全不同。

• 圈子信息模块： 偏展现型模块。交互较少，依据业务数据展现相应的信息模块内容，须要依据用户以后的身份展现不同类型的模块组件，并且能够依据以后用户的身份来进行权限校验，在未合乎时进行敌对 Tip 提醒的能力。
• 信息流模块： 偏交互型模块。须要反对多个列表在 Tab 下嵌套滚动的能力，模块自身须要保护用户关注状态表、黑名单筛选表和视频播放列表，不便模块中的子组件进行数据共享。并且列表具备单排流和瀑布流两种布局模式，列表内元素存在商品、帖子内容两种类型卡片。反对评论、点赞查看原图、视频播放、触发浮层等多种交互能力。
• 浮层模块：通用型模块。容许开发者依据业务需要注册相应的模块组件，并且容许配置相应的展现地位、动画成果和图层 index

1. 状态值拆分

=========

因为在圈子中有十分多须要共享信息的场景存在，例如用户相干数据、圈子根底信息等，仅仅只是基于业务模块闭环来拆分状态在此处就不适宜了。

因而在实现模块拆分之后咱们对圈子主页的状态数据进行了梳理，依据组件最小渲染准则来对状态进行相应的拆分，如下图所示：

全局状态

如上图，对于有共享诉求的状态变量，咱们优先将这些状态值汇总到一起以不便对立解决。

但因为是 C 端场景，交互复杂度不高并且思考到资源包的大小会对用户体验有肯定影响。此处的全局状态的治理计划咱们抉择了间接应用 Rax 原生的 useReducer + useContext 来进行解决，并将获取对应实例 context 的办法 Hooks 化以不便开发同学应用，简略 demo 代码如下所示：

业务组件状态

对于非共享型的数据，则要求放到业务模块中组件渲染影响最小的容器层来进行保护，以单排流的帖子列表为例：

• 卡片的初始数据通过 props 模式传入，繁多帖子的交互性数据都保留在帖子元素组件一层来保护。
• 列表容器中除了根底状态信息外，仅仅只做视频播放的管制，不额定触发容器级的重渲染。

施行调优

在多个业务模块进行组合调试的过程中，咱们发现交互体验仍然有许多不尽人意的问题点：

• 展现模块过多的状况下，如果在多个 Tab 下进行数据加载切换过后整个页面的交互会呈现显著的卡顿感：比方点击弹出浮层会有显著的期待时延，翻页切换 Tab 时对应的下标挪动会不同步。
• 浮层容器中注册的局部组件因为依赖共享变量，在共享变量变动时也会触发不必要的重渲染：成果为会跟着闪动一下。
• 网络情况不稳固的状况，页面展现不够敌对的；从用户点击路由跳转到首屏页面展现的等待时间过于显著，与咱们要求的 页面直开成果 相差甚远。1. 缩小 Context.Provider 重渲染
  应用 Context 只管能够晋升状态值传递的便捷性，然而随同的问题也相当显著：每一次状态值更新变动都会触发整个 Context.Provider 和上面的子组件从新渲染。

这与咱们预期的渲染流程不统一，毕竟我可能只是调整了一个 CircleHeader 组件所依赖的值，没必要底下 CircleSlider 组件及其中的列表组件都须要跟着做调整渲染，这个代价是咱们无奈承受的。

通过在社区中寻找相应的解决方案，咱们发现还是有肯定技巧来解决这个问题的：Context.Provider 其实组件也放弃着 Rax 组件的统一规定：props.children 作为传入属性，它如果放弃不变就不会触发值 diff，进而也就不会呈现重渲染的问题了。

那如何能力做到让 Provider 不会因为 props.children 的变动产生重渲染呢？通过社区提供的材料，咱们发现每次执行的都是 JSX 本义后的 createElement(xxx)。因为每次执行产生的子组件都不统一，所以会导致不必要的重渲染。

为此咱们将 Context.Provider 独自拆分成为一个专门用于传状态值的高阶组件，将子组件以 props.children 的模式传入：

通过这种形式，咱们将 CircleApp 变为了 Stateless Component。只有在首次初始化组件时进行渲染，之后 Provider 值变动时页不会从新导致 GlobalContextProvider 执行 createElement(CircleApp“)来从新创立组件实例了，缩小不必要的 js 执行。

1. 调整组件构造

==========

如上图能够看到在圈子中存在较多弹出浮层组件的场景，在初版设计过程中思考到浮层组件因为也须要应用到全局共享变量。因而在设计组件构造之初，将浮层容器组件放到了全局共享变量的 GlobalContextProvider 组件之内。

但在理论体验过后发现，只管对于外部的浮层组件获取共享变量较便当了，但反馈进去的问题也相当显著：在应用中低端机型时，如果页面加载的数据过多后会呈现显著的提早感。并且浮层组件仅仅在实在展现的时候才须要用到相应的状态值，非展现时其实不须要关系这些数据的具体内容。

为此咱们调整了浮层容器组件和主页常驻组件的层级构造，如上图所示：将常驻组件容器和层容器由原来的嵌套构造优化为了并行构造，两组件之间的数据通信通过办法调用来触发。这样调整之后长处绝对比拟显著：首先浮层组件能够更加通用、复用性更强。所有所需参数都是通过传参的形式传入，不须要再强依赖全局共享状态，对于开发同学来说保护起来的老本更低。其次因为缩小对共享状态值的依赖，子组件不必要的重渲染也都失去了优化。对于中低端机型也能提供绝对更好的互动体验。

1. 首屏体验优化 + 容灾机制

=================

在去年下半年的体验优化降级战斗中闲鱼的前端页面体验都有了很大的晋升：页面首屏等待时间大幅度降低、内容展现更加敌对，各个频道页接入渐进式首屏后用户能更快的查看到内容数据。
但在圈子开发的过程中，咱们发现对于个性化举荐的场景之前提出的渐进式首屏计划无奈较好的反对。为此咱们抉择了降级计划，调整了从圈子广场页到圈子主页及相干子页面的路由跳转逻辑。

如上图，通过制订上下游页面之间的数据缓存约定来达成容灾和进步交互体验是目标。在每次页面路由跳转时都将相应的业务数据进行缓存，在下一级页面对生产相应的缓存数据。这样不仅能够在网络环境较差的状况下晋升用户的体验。同时在接口报错时进行能够起到最低水平的无效兜底，防止用户体感过差。

在此基础上为了晋升页面首屏的渲染速度，咱们接入晋升 数据预取计划 和离线包缓存 计划。将首屏页面渲染过程中最为耗时的 资源包加载过程 和首屏接口申请过程 做了并行化解决，从而升高了首屏展现的期待时长。

优化前后成果比照：

优化前 优化后

后续瞻望

会玩圈子的首个版本在遭逢各种小问题后终于顺利上线了。在这个过程中解决了局部在之前电商导购场景下未经验过的问题：例如角色权限管控，多状态值治理等问题。这些教训的积淀对于之后闲鱼社区内简单 C 端利用体系的成长能够提供肯定的助力。

但目前仍有许多的问题点待咱们思考优化：

• 目前圈子主页的首屏均匀可交互时长为 1000ms 左右，用户从点击入口到进入主页内浏览根本无需期待。但咱们置信通过依据设施类型来做辨别，在进入页面之初降级局部中低端机非必须能力可能为这一类用户提供更快的交互体验。
• 为了突出社区内不同圈子共性点，置信自定义的装修能力以及定制插件能力在之后是必不可少的。要如何可能基于现有的架构体系疾速接入这些业务诉求，也是咱们在现有能力上须要事后思考到的
• 依据业务诉求的变动，如何将从业务模块中产生的组件尽量做到更通用化并且反对多种容器也是须要解决的。

作者：闲鱼技术——庞止
原文链接
本文为阿里云原创内容，未经容许不得转载