簡介： 魚樂圈上線啦～

閑魚會玩社區(qū)的重要陣地：會玩圈子今年年初已經(jīng)上線啦~

作為一款承載著「基于興趣聚集同好人群」的社區(qū)型產(chǎn)品，相較于常規(guī)導購型產(chǎn)品來說，在業(yè)務復雜度、交互復雜度、性能體驗穩(wěn)定性要求上都要高出許多，像多角色區(qū)分、嵌套滾動、多形態(tài) Feeds 無限加載、顏文字等特殊字符處理、頁面直開、視頻播控等場景都是導購場景很少遇到的。

本文將圍繞著會玩圈子的前端設計、開發(fā)過程中遇到的典型問題進行介紹。

關鍵設計

如上圖為會玩圈子的設計大圖，可以看到整體的業(yè)務邏輯相對較為復雜。并且由于應用中存在多種角色狀態(tài)，不同角色的用戶展示界面和操作邏輯也有差異點存在，前端同學進行開發(fā)上手的成本較高。

為了降低前端同學在開發(fā)過程中對于全局業(yè)務理解的成本，減少溝通中信息傳遞容易遺漏的問題。我們在設計之初首先進行了最小模塊的拆分工作。以模塊維度來分配相應的工作，將模塊間存在數(shù)據(jù)共享和數(shù)據(jù)通信行為進行梳理拆解，以最優(yōu)方式來分配數(shù)據(jù)狀態(tài)維護的最小閉環(huán)，降低組件間耦合度。

1. 模塊拆分

在此處定義的模塊不是前端日常開發(fā)中所講的模塊組件拆分，而是能夠獨立閉環(huán)自成體系的一個業(yè)務單元。這樣在項目過程中除了部分組件間數(shù)據(jù)傳遞需要做預先約定外，前端同學僅僅只需要專注于自己所負責的交互場景即可。
??
以圈子模塊主頁為例，根據(jù)設計稿我們將它拆分為了三個獨立的業(yè)務模塊：圈子信息模塊、信息流模塊和浮層組件模塊，他們無論從功能上還是展示上都完全不同。

• 圈子信息模塊： 偏展示型模塊。交互較少，根據(jù)業(yè)務數(shù)據(jù)展示相應的信息模塊內(nèi)容，需要根據(jù)用戶當前的身份展示不同類型的模塊組件，并且可以根據(jù)當前用戶的身份來進行權限校驗，在未符合時進行友好Tip提示的能力。
• 信息流模塊： 偏交互型模塊。需要支持多個列表在Tab下嵌套滾動的能力，模塊本身需要維護用戶關注狀態(tài)表、黑名單篩選表和視頻播放列表，方便模塊中的子組件進行數(shù)據(jù)共享。并且列表具備單排流和瀑布流兩種布局模式，列表內(nèi)元素存在商品、帖子內(nèi)容兩種類型卡片。支持評論、點贊查看原圖、視頻播放、觸發(fā)浮層等多種交互能力。
• 浮層模塊：通用型模塊。允許開發(fā)者根據(jù)業(yè)務需求注冊相應的模塊組件，并且允許配置相應的展示位置、動畫效果和圖層index

2. 狀態(tài)值拆分

由于在圈子中有非常多需要共享信息的場景存在，例如用戶相關數(shù)據(jù)、圈子基礎信息等，僅僅只是基于業(yè)務模塊閉環(huán)來拆分狀態(tài)在此處就不適合了。

因此在完成模塊拆分之后我們對圈子主頁的狀態(tài)數(shù)據(jù)進行了梳理，根據(jù)組件最小渲染原則來對狀態(tài)進行相應的拆分，如下圖所示：

全局狀態(tài)

如上圖，對于有共享訴求的狀態(tài)變量，我們優(yōu)先將這些狀態(tài)值匯總到一起以方便統(tǒng)一處理。

但由于是C端場景，交互復雜度不高并且考慮到資源包的大小會對用戶體驗有一定影響。此處的全局狀態(tài)的管理方案我們選擇了直接使用Rax原生的useReducer + useContext來進行處理，并將獲取對應實例context 的方法Hooks化以方便開發(fā)同學使用，簡單demo代碼如下所示：

業(yè)務組件狀態(tài)

對于非共享型的數(shù)據(jù)，則要求放到業(yè)務模塊中組件渲染影響最小的容器層來進行維護，以單排流的帖子列表為例：

• 卡片的初始數(shù)據(jù)通過props形式傳入，單一帖子的交互性數(shù)據(jù)都保留在帖子元素組件一層來維護。
• 列表容器中除了基礎狀態(tài)信息外，僅僅只做視頻播放的控制，不額外觸發(fā)容器級的重渲染。

實施調(diào)優(yōu)

在多個業(yè)務模塊進行組合調(diào)試的過程中，我們發(fā)現(xiàn)交互體驗依然有許多不盡人意的問題點：

• 展示模塊過多的情況下，如果在多個Tab下進行數(shù)據(jù)加載切換過后整個頁面的交互會出現(xiàn)明顯的卡頓感：比如點擊彈出浮層會有明顯的等待時延，翻頁切換Tab時對應的下標移動會不同步。
• 浮層容器中注冊的部分組件由于依賴共享變量，在共享變量變化時也會觸發(fā)不必要的重渲染：效果為會跟著閃動一下。
• 網(wǎng)絡狀況不穩(wěn)定的情況，頁面展示不夠友好的；從用戶點擊路由跳轉到首屏頁面展示的等待時間過于明顯，與我們要求的頁面直開效果相差甚遠。

  1. 減少Context.Provider重渲染

  
  使用Context盡管可以提升狀態(tài)值傳遞的便捷性，但是伴隨的問題也相當明顯：每一次狀態(tài)值更新變化都會觸發(fā)整個Context.Provider和下面的子組件重新渲染。

這與我們預期的渲染流程不一致，畢竟我可能只是調(diào)整了一個CircleHeader組件所依賴的值，沒必要底下CircleSlider組件及其中的列表組件都需要跟著做調(diào)整渲染，這個代價是我們無法接受的。

通過在社區(qū)中尋找相應的解決方案，我們發(fā)現(xiàn)還是有一定技巧來解決這個問題的：Context.Provider其實組件也保持著Rax組件的一致規(guī)則：props.children作為傳入屬性，它如果保持不變就不會觸發(fā)值diff，進而也就不會出現(xiàn)重渲染的問題了。

那如何才能做到讓Provider不會由于props.children的變化產(chǎn)生重渲染呢？通過社區(qū)提供的資料，我們發(fā)現(xiàn)每次執(zhí)行的都是JSX轉義后的createElement(xxx)。由于每次執(zhí)行產(chǎn)生的子組件都不一致，所以會導致不必要的重渲染。

為此我們將Context.Provider單獨拆分成為一個專門用于傳狀態(tài)值的高階組件，將子組件以props.children的形式傳入：

通過這種方式，我們將CircleApp變?yōu)榱薙tateless Component。只有在首次初始化組件時進行渲染，之后Provider值變化時頁不會重新導致GlobalContextProvider執(zhí)行createElement(CircleApp``)來重新創(chuàng)建組件實例了，減少不必要的js執(zhí)行。

2. 調(diào)整組件結構

如上圖可以看到在圈子中存在較多彈出浮層組件的場景，在初版設計過程中考慮到浮層組件由于也需要使用到全局共享變量。因此在設計組件結構之初，將浮層容器組件放到了全局共享變量的GlobalContextProvider組件之內(nèi)。

但在實際體驗過后發(fā)現(xiàn)，盡管對于內(nèi)部的浮層組件獲取共享變量較便利了，但反饋出來的問題也相當明顯：在使用中低端機型時，如果頁面加載的數(shù)據(jù)過多后會出現(xiàn)明顯的延遲感。并且浮層組件僅僅在真實展示的時候才需要用到相應的狀態(tài)值，非展示時其實不需要關系這些數(shù)據(jù)的具體內(nèi)容。

?

為此我們調(diào)整了浮層容器組件和主頁常駐組件的層級結構，如上圖所示：將常駐組件容器和層容器由原來的嵌套結構優(yōu)化為了并行結構，兩組件之間的數(shù)據(jù)通信通過方法調(diào)用來觸發(fā)。這樣調(diào)整之后優(yōu)點相對比較明顯：首先浮層組件可以更加通用、復用性更強。所有所需參數(shù)都是通過傳參的方式傳入，不需要再強依賴全局共享狀態(tài)，對于開發(fā)同學來說維護起來的成本更低。其次因為減少對共享狀態(tài)值的依賴，子組件不必要的重渲染也都得到了優(yōu)化。對于中低端機型也能提供相對更好的互動體驗。

3. 首屏體驗優(yōu)化 + 容災機制

在去年下半年的體驗優(yōu)化升級戰(zhàn)役中閑魚的前端頁面體驗都有了很大的提升：頁面首屏等待時間大幅度降低、內(nèi)容展示更加友好，各個頻道頁接入漸進式首屏后用戶能更快的查看到內(nèi)容數(shù)據(jù)。
但在圈子開發(fā)的過程中，我們發(fā)現(xiàn)對于個性化推薦的場景之前提出的漸進式首屏方案無法較好的支持。為此我們選擇了降級方案，調(diào)整了從圈子廣場頁到圈子主頁及相關子頁面的路由跳轉邏輯。

如上圖，通過制定上下游頁面之間的數(shù)據(jù)緩存約定來達成容災和提高交互體驗是目的。在每次頁面路由跳轉時都將相應的業(yè)務數(shù)據(jù)進行緩存，在下一級頁面對消費相應的緩存數(shù)據(jù)。這樣不僅可以在網(wǎng)絡環(huán)境較差的情況下提升用戶的體驗。同時在接口報錯時進行可以起到最低程度的有效兜底，避免用戶體感過差。

優(yōu)化前? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??優(yōu)化后

在此基礎上為了提升頁面首屏的渲染速度，我們接入提升數(shù)據(jù)預取方案和離線包緩存方案。將首屏頁面渲染過程中最為耗時的資源包加載過程和首屏接口請求過程做了并行化處理，從而降低了首屏展示的等待時長。

優(yōu)化前后效果對比：

優(yōu)化前 優(yōu)化后

后續(xù)展望

會玩圈子的首個版本在遭遇各種小問題后終于順利上線了。在這個過程中解決了部分在之前電商導購場景下未經(jīng)歷過的問題：例如角色權限管控，多狀態(tài)值管理等問題。這些經(jīng)驗的沉淀對于之后閑魚社區(qū)內(nèi)復雜C端應用體系的成長可以提供一定的助力。

但目前仍有許多的問題點待我們思考優(yōu)化：

• 目前圈子主頁的首屏平均可交互時長為1000ms左右，用戶從點擊入口到進入主頁內(nèi)瀏覽基本無需等待。但我們相信通過根據(jù)設備類型來做區(qū)分，在進入頁面之初降級部分中低端機非必須能力能夠為這一類用戶提供更快的交互體驗。
• 為了突出社區(qū)內(nèi)不同圈子個性點，相信自定義的裝修能力以及定制插件能力在之后是必不可少的。要如何能夠基于現(xiàn)有的架構體系快速接入這些業(yè)務訴求，也是我們在現(xiàn)有能力上需要預先思考到的
• 根據(jù)業(yè)務訴求的變化，如何將從業(yè)務模塊中產(chǎn)生的組件盡量做到更通用化并且支持多種容器也是需要解決的。

作者：閑魚技術——龐止

原文鏈接

本文為阿里云原創(chuàng)內(nèi)容，未經(jīng)允許不得轉載

?

總結

以上是生活随笔為你收集整理的0到1：闲鱼高复杂度高性能社区圈子开发实录的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。