前言

每年的云音樂年度聽歌報告，就像一個靠譜的老朋友，總會在忙碌一年的時光盡頭里叩響記憶的大門。

• 如果你曾錯過了彼時的年報，不妨現(xiàn)在就拿起手機掃描上圖的二維碼，與往期的精彩視聽來一場不期而遇的邂逅；
• 如果你為年報中精巧而溫馨的動畫而深深著迷，請直接移步至本文的姊妹篇：「云音樂2023年報動效大揭秘」一探究竟；
• 如果你恰好想了解年報中前端開發(fā)承擔(dān)了什么樣的角色、積累了哪些最佳實踐 ——那么巧了，本文將從性能體驗、質(zhì)量管理、工程效率和一些筆者底層思考，幫助你逐步揭開年報的神秘面紗

性能體驗

首次訪問年報活動為例，好的用戶體驗主要包括以下幾個方面：

• 頁面能秒級打開，頁面到達率高、流失少；
• 頁面間轉(zhuǎn)場展示流暢，不會出現(xiàn)卡頓；
• 文本和圖片內(nèi)容在任何設(shè)備上都能完整展示，不出現(xiàn)缺失或者加載閃爍情況；
• 音頻或視頻啟播速度快，播放過程中不發(fā)生錯亂或者卡頓情況；
• 頁面內(nèi)的動效展示流暢，不會出現(xiàn)卡頓；

圖片

簡而言之，體驗優(yōu)涉及以下幾個方面：

1、頁面導(dǎo)航：包括首屏秒開，頁面轉(zhuǎn)場等

2、資源管理：包括圖片、視頻、音頻和字體包等

3、頁面適配：包括文本適配、動效適配和機型適配等

首屏秒開

首屏秒開是指用戶從點擊鏈接開始到展示頁面內(nèi)容大約在1s左右完成。整個過程經(jīng)歷如圖所示：

容器初始化 -> CDN -> TCP 建連 -> html/js/css 加載解析 -> DOM / CSSOM 解析 -> 渲染布局 -> 繪制

圖片

對于前端開發(fā)來說，優(yōu)化難度是從右到左，越到左邊就越需要跨團隊合作來完成。可以簡單的分析總結(jié)：

• 在渲染/繪制階段，可以隔離狀態(tài)變化頻繁的組件，減少無效狀態(tài)引起的繪制。盡量選擇由 GPU 渲染的 CSS3 來實現(xiàn)動效。邏輯實現(xiàn)的動效建議使用GSAP。
• 在 DOM / CSSDOM 解析階段，可以減少 DOM 的嵌套深度，減少使用 JavaScript 直接修改元素樣式，減少不必要的 CSS，減少使用 CSS 選擇器等。
• 在 HTML / JS / CSS 加載解析階段，可以通過構(gòu)件工具對文件進行壓縮。利用離線包能力，將這些資源提前下載到本地。
• 在 CDN、TCP 建連階段，更多依賴 App 網(wǎng)絡(luò)庫底層的優(yōu)化，如使用 HTPP/2 減少 TCP 連接數(shù)。
• 在容器初始化階段，為了達到極致的打開速度，可以將 H5 容器進行預(yù)初始化。也可以建立容器復(fù)用池，減少容器創(chuàng)建的耗時。

頁面管理

頁面路由

為了有效管控年報中多個視圖的高效展示和切換，采用了 SPA[1] 的形式對H5進行組織，同時為頁面路由提供了路由表的配置。

路由表簡單理解是各個子頁面路由對象的集合，這個集合可以是全局?jǐn)?shù)組對象，本地文件，或者服務(wù)端下發(fā)的配置。集合內(nèi)的順序決定了用戶看到報告頁順序。這樣也可以根據(jù)產(chǎn)品的述求，靈活調(diào)整集合內(nèi)的順序，這樣就能動態(tài)調(diào)整頁面順序了。

各個子頁面路由對象的屬性具體如下。建議不用傳統(tǒng)的 path，因為子頁面數(shù)量多，且名稱很難記憶，可以使用 routerIndex，這是子頁面在交互稿中的位置代號，方便開發(fā)和調(diào)試。其中 ignoreSwipe 是使用在下節(jié)手勢處理中「子容器接管父容器手勢」的場景。

export interface PageProps {
    model: unknown;
    position?: number; // 頁面埋點使用
}

export interface PageRouteProps {
    c: ComponentType<PageProps>;
    cId: string; // 當(dāng)前頁面唯一id
    routerIndex: number | string; // 路由索引
    ignoreSwipe?: boolean; // 是否忽略滑動，默認(rèn)false
}

手勢處理

年報項目中用戶可以通過點擊、左右滑動、上下滑動來切換頁面。為了防止手勢沖突，全局只有一個父容器，各個報告頁面是子容器；一些手勢頻控、頁面狀態(tài)變化等通用邏輯統(tǒng)一在父容器中實現(xiàn)。只在父容器中使用 hammerjs 做手勢監(jiān)聽，子容器不再負(fù)責(zé)頁面切換的手勢監(jiān)聽，關(guān)鍵代碼如下。

hammer = new Hammer(reportRef.current);
 hammer.get('swipe').set({ direction: Hammer.DIRECTION_ALL });
 hammer.on('swipeleft', onNextPageWrap);
 hammer.on('swiperight', onPrePageWrap);
 hammer.on('swipeup', onNextPage);
 hammer.on('swipedown', onPrePage);

對于子容器，可能會有以下幾種特殊情況：

情況一：如果子容器需要感知用戶手勢事件，可以監(jiān)聽父容器發(fā)出的自定義事件。

// 【翻頁】動效：下一頁
export const ON_PAGE_NEXT = 'ON_PAGE_NEXT';

// 【翻頁】動效：上一頁
export const ON_PAGE_PREV = 'ON_PAGE_PREV';

情況二：如果子容器需要完全接管父容器的手勢監(jiān)聽事件，例如年度歌手相關(guān)的所有頁面。首先需要在路由表中將 ignoreSwipe=ture 設(shè)置忽略手勢，然后在監(jiān)聽父容器發(fā)出的通知，進行自定義的事件處理。最后當(dāng)子容器接管結(jié)束后，需要根據(jù)需要再次觸發(fā)父容器的切換事件。關(guān)鍵代碼如下：

const onNextPage = useCallback(
    (nextAction) => {
        if (currentPage >= len - 1) {
            nextAction(); // 結(jié)束接管，再次觸發(fā)父容器的切換事件
            return;
        }
        
        setCurrentPage(currentPage + 1);
    },
    [currentPage, len]
);

useEffect(() => {
        bus.on(ON_PAGE_NEXT, onNextPage);

        return () => {
            bus.off(ON_PAGE_NEXT, onNextPage);
        };
    }, [onNextPage, onPrePage]);

情況三：如果子容器存在特定區(qū)域需要響應(yīng)特點手勢，例如歌手來信頁面左右切換是查看歌手來信。這時候需要子容器調(diào)用stopPropagation主動阻止手勢向父容器傳遞。

轉(zhuǎn)場實現(xiàn)

在路由表和手勢處理準(zhǔn)備就緒后，最后來看看頁面之間轉(zhuǎn)場的實現(xiàn)。年報頁面的轉(zhuǎn)場效果使用React官方實現(xiàn)的 react-transition-group 組件。由于篇幅限制，這里不詳細(xì)介紹react-transition-group 組件的底層原理。結(jié)合路由表順序和當(dāng)前頁面位置，通過 z-index 和 match 來控制子頁面的層級和顯示隱藏。使用 CSSTransition 實現(xiàn)頁面間的進場和退場CSS動畫。關(guān)鍵代碼如下：

(pages || []).map((item, index) => {
    // zIndex 和 match是關(guān)鍵代碼
    const zIndex = (pages.length - index) * 100;
    const match = index === currentIdx;
    return (
        <div
            key={item.cId}
            style={{
                zIndex,
                pointerEvents: match ? 'auto' : 'none',
                overflow: 'hidden',
            }}>
                <CSSTransition
                    in={match}
                    timeout={100}
                    ...
                    appear
                    unmountOnExit>
                    <item.c
                        model={item.model}
                        positinotallow={index} />
                </CSSTransition>
          </div>        
    );
})

但是以上的頁面轉(zhuǎn)場存在一個問題，即頁面之間只能存在一種轉(zhuǎn)場方式。如何自定義頁面之間的轉(zhuǎn)場效果？基本思路是各自頁面維護自己的轉(zhuǎn)場效果；大部分頁面只需將轉(zhuǎn)場信息配置到路由表中；小部分頁面可以通過頁面上下文獲得上一個或者下一個頁面的信息，動態(tài)決定如何進場或者退場?；谠撍悸罚脑炻酚杀韺ο?，新增一個 TransitionParams 協(xié)議，并且提供漸隱漸顯的默認(rèn)轉(zhuǎn)場實現(xiàn)。關(guān)鍵代碼如下：

export type TransitionParams = {
    timeout: number | { appear?: number | undefined; enter?: number | undefined; exit?: number | undefined };
    classNames: CSSTransitionClassNames;
};

export interface PageRouteProps {
    c: ComponentType<PageProps>;
    cId: string; // 當(dāng)前頁面唯一id
    routerIndex: number; // 路由索引
    transition: TransitionParams; //默認(rèn)是漸隱漸顯的轉(zhuǎn)場效果
    ignoreSwipe?: boolean; // 是否忽略滑動，默認(rèn)false
}

CSSTransition 配合改造后的關(guān)鍵代碼如下：

<CSSTransition
    in={match}
    timeout={item.transition.timeout}
    // 關(guān)鍵代碼
    classNames={item.transition.classNames}
    appear
    unmountOnExit>
        <item.c model={item.model} positinotallow={index} />
</CSSTransition>

資源管理

資源管理主要任務(wù)是將網(wǎng)絡(luò)資源下載到本地，最終將本地資源加載到內(nèi)存，以便程序可以使用這些資源。優(yōu)化資源管理可以有效提高年報用戶體驗。通常開發(fā)者會通過壓縮資源的大小，并通過內(nèi)容分發(fā)網(wǎng)絡(luò)（CDN）加快資源的下載速度。但是除了這些還有其他通用的方法呢？

在介紹具體優(yōu)化手段前，先來看以下關(guān)鍵字，這些是性能優(yōu)化的通用方法。

• 提前 preload：提前準(zhǔn)備必要的資源，提升加載速度
• 同步 sync：串行執(zhí)行當(dāng)前任務(wù)，確保執(zhí)行任務(wù)的優(yōu)先級
• 異步 async：工作線程異步執(zhí)行，處理比較耗時的操作，不阻塞主線程
• 懶加載 lazy：又稱按需加載，不浪費請求
• 緩存 cache：將資源緩存到內(nèi)存或者磁盤本地，減少不必要的網(wǎng)絡(luò)請求
• 延遲 defer：不立即執(zhí)行任務(wù)，延遲執(zhí)行

總結(jié)如下圖：

圖片

接下來，將從圖片、視頻、字體包等各個資源，進一步解析如何結(jié)合上述關(guān)鍵詞進行優(yōu)化。

圖片

關(guān)鍵字：提前 preload、懶加載 lazy、緩存 cache

圖片資源占整個年報項目資源中的比例是最高的，大概 70% 左右。所以圖片展示速度是否足夠快和內(nèi)容是否完整都會直接影響用戶體驗。

優(yōu)先將圖片資源使用 tinypng 進行手動壓縮，在不失真的情況下，保證圖片大小足夠小。其次正確選擇圖片格式能有效減少圖片大小。其中圖片格式很多，主流的有：

• SVG 是基于XML的矢量圖片格式，不失真無限放大。支持動畫。
• JPEG 是有損壓縮，不支持透明度或者動畫。
• PNG 是無損壓縮，支持透明度。APNG 是 PNG 的擴展，支持動胡奧。
• WebP 是無損和有損壓縮，支持動畫或者透明度。
• GIF 是位圖圖片格式，支持動畫。

不同圖片格式在不同場景上使用。格式?jīng)]選準(zhǔn)確，會導(dǎo)致資源浪的費。如在「年度總覽」一頁中，海浪??背景是一張PNG格式，大小為 1.7MB。但是該場景不需要透明，選擇JPEG后大小為 96kb?？偨Y(jié)如下是選擇圖片格式的流程圖。

圖片

小圖標(biāo)或 logo 可以使用 SVG。其它能用 WebP 盡量使用 WebP。對于 WebP 的兼容性問題，可以通過業(yè)務(wù)封裝的圖片組件進行處理，不能使用 WebP 則兜底變成 PNG ，因為 PNG 兼容性最好。GIF 盡量不適用。對于超過特定大小的動圖，建議使用CSS動效或者視頻替代。

在已經(jīng)壓縮圖片和選擇正確的圖片格式的前提下，會在當(dāng)前報告頁面提前 preload 預(yù)加載下一頁面的圖片資源，并將圖片緩存cache在本地。

預(yù)下載的方式有多種，可以自動全量下載，也可以手動按需下載。

自動全量下載，可以基于上文 CSSTransition 的 in 參數(shù)。不只是匹配當(dāng)前頁面進行渲染，也提前渲染下一頁。自動下載的方案存在缺點比較明顯，如：不能按需下載；頁面的生命周期和用戶感知不一致，導(dǎo)致一些邏輯提前執(zhí)行如頁面曝光埋點。

let matchIndex = -1;

(pages || []).map((item, index) => {
    const zIndex = (pages.length - index) * 100;
    const match = index === currentIdx;
    if (match) {
        matchIndex = index;
    }

    return (
        <div
            key={item.cId}
            style={{
                zIndex,
                pointerEvents: match ? 'auto' : 'none',
                overflow: 'hidden',
            }}>
                <CSSTransition
                    // in 這里是關(guān)鍵代碼
                    in={match || (index ===  matchIndex + 1)}
                    timeout={item.transition.timeout}
                    classNames={item.transition.classNames}
                    appear
                    unmountOnExit>
                    <item.c model={item.model} positinotallow={index} />
                </CSSTransition>
          </div>        
    );
})

相較自動下載，手動按需下載更加可控。手動按需下載那些圖片可以選擇更接近用戶體感的 LCP（Largest Contentful Paint）原則。因為在業(yè)務(wù)頁面加載階段，命中 LCP 的元素可能會發(fā)生變化，所以這里主觀選擇可能命中 LCP 的圖片元素進行預(yù)下載。如下圖，最終選擇A、B、C、D這個四張圖片進行預(yù)加載。

圖片

手動下載的方法有多種?？梢曰谌綆?nbsp;pxloader 進行再一次封裝。如果將 React 升級到19后，系統(tǒng)默認(rèn)提供了 preload API，更多API詳情見此鏈接[2]。

import { preload } from 'react-dom'

// 下載字體包
preload('https://.../path/to/font.woff', { as: 'font' })

// 下載樣式表
preload('https://.../path/to/stylesheet.css', { as: 'style' })

// 下載不知道的文件類型
prefetchDNS('https://...')

手動下載的時機可以監(jiān)聽頁面切換，根據(jù)當(dāng)前頁面信息在路由表中獲取到下一個需要預(yù)加載的頁面信息。最終手動下載的偽代碼如下：

const preload = new PreLoader();

const usePreLoader = ({ pages, currentIdx }: PreLoadSourceProps): void => {
    useEffect(() => {
        const preLoadIndex = currentIdx + 1; // 提前預(yù)加載
        const item = pages[preLoadIndex];

        if (item.cId === YearOverviewIdentifier) {
            preload.add([A, B]);
            preload.start();
        }

        ...

    }, [currentIdx, pages, reportInfo]);
};

視頻

關(guān)鍵字：提前preload、同步sync

和圖片同樣的思路，先明確視頻的尺寸，不同尺寸大小的視頻資源大小也不一樣。在視頻尺寸正確的前提下，在做視頻體驗優(yōu)化才能事半功倍。在項目初期準(zhǔn)備 6 種視頻，相同視頻內(nèi)容，網(wǎng)絡(luò)環(huán)境下，用不同系統(tǒng)的機型進行壓測。這 6 種視頻，分別是：

• 寬1242、高2688、FPS50
• 寬1242、高2688、FPS25
• 寬1080、高2388、FPS50
• 寬1080、高2388、FPS25
• 寬720、高1625、FPS50
• 寬720、高1625、FPS25

壓測得出的實驗結(jié)論是：

• 安卓 10-13，分辨率高于 2400 的 6 種視頻大小都能體驗，但寬1242 & 高2688 尺寸的視頻基本上會有卡頓；
• 安卓 10-13，分辨率低于 2400，寬1242 & 高2688 該尺寸的視頻無法進行體驗；
• 安卓 10 以下的，只能體驗寬720 & 高1624 該尺寸下的視頻。
• iOS 系統(tǒng) 13-16，體驗都正常，iOS12 系統(tǒng)，寬1242 & 高2688 & FPS50 和寬1080 & 高2338 & FPS50無法進行體驗。

最后根據(jù)實驗結(jié)論，結(jié)合視頻效果和資源大小的考慮，最終采用三種尺寸的視頻，分別是：

• 寬1080、高2388、FPS50，命名為 w1080FPS50
• 寬720、高1625、FPS50，命名為 w720FPS50
• 寬720、高1625、FPS25，命名為 w720FPS25

總結(jié)如下是選擇視頻尺寸大小的流程圖。w1080FPS50 體驗最優(yōu)，w720FPS25 兼容性最好。開發(fā)可以根據(jù)不同的機型、系統(tǒng)選擇合適的視頻。

圖片

為了讓用戶在點擊封面頁面的開始按鈕后能流暢觀看視頻，選擇在封面頁面渲染完成后，同步 sync 添加視頻頁面。通過 zIndex 將其隱藏在封面頁后面，利用用戶游覽封面頁的間隙，提前 preload 創(chuàng)建 video 組件。同時，設(shè)置<video>的 preload='auto'，讓游覽器結(jié)合網(wǎng)絡(luò)等自身條件自動決策是否預(yù)加載視頻。

即使選擇好合適的視頻資源后，也需要兜底處理一些播放的異常情況，防止播放失敗影響體驗?？梢员O(jiān)聽onWaiting回調(diào)，如果在規(guī)定時間內(nèi)如果沒有再次觸發(fā)onPlay回調(diào)，會直接手動執(zhí)行onEnd回調(diào)的事件。也可以在onCanPlay回調(diào)中啟動視頻超時定時器，在規(guī)定范圍內(nèi)系統(tǒng)沒有自動觸發(fā)到onEnd回調(diào)，那也會直接手動執(zhí)行onEnd回調(diào)的事件。

音頻、字體包

關(guān)鍵字：延遲defer，懶加載lazy

音頻在工程中通常有兩種播放能力：WebAudio H5 原生播放能力和通過RPC方式調(diào)用客戶端原生播放能力。

在站內(nèi)場景中，通常推薦使用客戶端 RPC 提供的播放能力，因為它可以復(fù)用端上播放的基礎(chǔ)能力，如播放音質(zhì)、啟播時長等都有優(yōu)化。如果站內(nèi)想要繞過某些播放權(quán)限，會選擇 H5 原生播放能力。而在站外，只能使用H5原生播放能力。為了簡化開發(fā)接入，封裝 audioManager 業(yè)務(wù)組件，提供統(tǒng)一的API接口，抹平站內(nèi)、站外的兼容性問題。

對于字體包，通常會懶加載 lazy 選擇視覺設(shè)計中使用到的字體包。針對固定文案的情況下，使用工具裁剪掉多余的字體，從而達到最小字體包。也會在 header 中延遲 defer 下載字體包的資源，以避免阻塞封面頁的渲染。在封面頁面不使用特殊字體包的前提下，可以在封面頁面設(shè)置不可見的<p>標(biāo)簽，靜默下載字體包，從而讓后續(xù)報告頁面里的特殊字體不出現(xiàn)跳變。

小結(jié)

可以組合使用不同的優(yōu)化手段來提高性能，但切記物極必反。例如在年報項目開發(fā)過程中，為了實現(xiàn)歌手子頁面轉(zhuǎn)場的效果，會將 6 個子頁面提前加載。在開發(fā)早期，各個頁面渲染復(fù)雜度低，不會出現(xiàn)問題。但在后續(xù)為了提高視覺效果，加入了各種噪點、混合、粒子效果后，在低端機設(shè)備上，該模塊在切換時容易出現(xiàn)白屏現(xiàn)象。最后定位是子頁面提前預(yù)加載過多，內(nèi)存占用大，使得端上收到 OOM 警告，回收 H5 容器，從而導(dǎo)致了白屏。最后，采用懶加載 lazy 加載，同一時間最多顯示 3 個頁面，這樣既保證子頁面轉(zhuǎn)場的流暢，也保證了功能的正常使用。

頁面適配

用戶手機機型千變?nèi)f化，頁面適配是必須要面對的問題。開發(fā)之前先明確兩個關(guān)鍵的點：站內(nèi)是否支持全屏；站外是否需要支持。明確后結(jié)合工程現(xiàn)狀，將需要適配的重點機型進行枚舉，并歸納總結(jié)，以 iPhone 機型為例如下：

圖片

如果只適配站內(nèi)全屏/非全屏，建議將適配的機型寬高比控制在 2 個以內(nèi)。舉例年報只支持站內(nèi)全屏，如下圖第二列所示，可以將站內(nèi)適配劃分成 2 檔，通過媒體查詢，所以只需支持寬高比大于等于 375 / 667，適配范圍支持站內(nèi)寬屏或者小屏的機型。針對特殊頁面，還可以配 合max-height 再做微調(diào)。

@media screen and (min-aspect-ratio: 375 / 667) {
    // 大于等于 0.5622
    // 適配范圍：站內(nèi)寬屏、特殊小屏的機型
}

@media screen and (max-height: 750px) {
}

如果需要適配站外，建議將適配的機型寬高比控制在 4 個以內(nèi)。如下圖第三列所示，分析歷史站外流量分布，重點支持微信、微博等 App。可以將站內(nèi)、外適配劃分成四檔。第一檔需支持寬高比大于等于 400 / 815 且小于 375 / 667，適配范圍支持15pro、12promax、15promax、vivo s9 等站外+大屏。第二檔需支持寬高比大于等于 375 / 667 且小于 375 / 603，適配范圍支持 8p、SE 等站內(nèi)+寬屏、小屏。第三檔需支持寬高比大于等于 375 / 603，適配范圍支持8p、SE 等站外、寬屏+小屏。

@media screen and (min-aspect-ratio: 400 / 815) and (max-aspect-ratio: 374 / 667) {
    // 大于等于 0.4907，小于等于 0.5607
    // 適配范圍：15pro、12promax、15promax、vivo s9 等 站外+大屏
}

@media screen and (min-aspect-ratio: 375 / 667) and (max-aspect-ratio: 374 / 603) {
    // 大于等于 0.5622，小于0.6218
    // 適配范圍：8p、SE 等 站內(nèi)+寬屏、小屏  
}

@media screen and (min-aspect-ratio: 375 / 603) {
    // 大于等于 0.6218
    // 適配范圍：8p、SE 等 站外、寬屏+小屏 
}

質(zhì)量監(jiān)控

面向年報這種大型活動，針對質(zhì)量問題的感知不能僅被動通過用戶反饋問題，更重要的是需要一套完善的監(jiān)控系統(tǒng)自動發(fā)現(xiàn)問題。通過這套系統(tǒng)也能夠有效評估出線上運行的狀態(tài)，最后用數(shù)據(jù)來驗證“質(zhì)量優(yōu)”這個技術(shù)指標(biāo)。

對于開發(fā)者而言，質(zhì)量優(yōu)的背后實質(zhì)是高可用。需要對各種異常結(jié)果進行兜底，來保證用戶完整體驗完年報活動。簡而言之，質(zhì)量優(yōu)涉及以下幾個方面：

1、異常監(jiān)控：包括 crash 平臺、實時數(shù)據(jù)監(jiān)控平臺，離線日志回?fù)破脚_等

2、功能降級：包括 AB 配置中心，上線 SOP 白皮書，活動研發(fā)平臺等

3、數(shù)據(jù)準(zhǔn)確：包括異常數(shù)據(jù)兜底，敏感數(shù)據(jù)過濾，埋點數(shù)據(jù)等

異常監(jiān)控

除了必備的異常 crash 監(jiān)控平臺，還需要根據(jù)年報活動的特性來構(gòu)建一個更全面的監(jiān)控體系。主要包括分享率監(jiān)控、視頻卡頓監(jiān)控、音頻啟播失敗監(jiān)控、接口異常監(jiān)控等。由于監(jiān)控的多樣性，需要根據(jù)不同的場景采用不同的監(jiān)控策略。例如，如果想觀察分享點擊率，需要實時上報監(jiān)控數(shù)據(jù)；如果需要排查頁面白屏問題，需要收集用戶本地的離線數(shù)據(jù)。由于年報日活高，樣本數(shù)據(jù)量大，需要考慮是否需要采樣上報。建議實時數(shù)據(jù)采用一定的采樣率，而離線數(shù)據(jù)則采全量上報。

監(jiān)控的思路是：現(xiàn)狀分析，指標(biāo)建設(shè)，監(jiān)控埋點，指標(biāo)分析，方案優(yōu)化，AB 實驗，驗證收益。PACD 的方式持續(xù)改進，直到問題被解決。

以分享率監(jiān)控為例?；顒臃窒砺室_到xx%是年報關(guān)鍵指標(biāo)。分析工程中現(xiàn)狀后，制定如下圖的監(jiān)控指標(biāo)。

圖片

結(jié)合線上埋點數(shù)據(jù)，能夠清晰發(fā)現(xiàn)圖片生成耗時和圖片生成成功率對圖片分享成功率有正向影響。因此，后續(xù)開發(fā)的重點就是如何降低圖片耗時生成和提高圖片生成的成功率。

功能降級

監(jiān)控的本質(zhì)是及時發(fā)現(xiàn)問題并快速止損。在面對突發(fā)情況時，通過線上配置快速關(guān)閉某些非核心功能，以確保核心功能的正常進行。在開發(fā)中過程中，可以將降級開關(guān)集中配置在一個能進行可視化的活動研發(fā)平臺內(nèi)統(tǒng)一管理，如下圖。在上線前，需要將這些開關(guān)納入上線前的標(biāo)準(zhǔn)操作流程（SOP）中。

圖片

下圖是年報的監(jiān)控大盤。對可能嚴(yán)重影響用戶體驗的功能，如白屏、視頻和音頻進行了重點監(jiān)控，同時也對關(guān)鍵業(yè)務(wù)模塊，如報告頁面和歌手來信進行了監(jiān)控。這些監(jiān)控在年報活動也發(fā)揮了重要的作用。例如，通過對報告頁面接口的監(jiān)控，發(fā)現(xiàn)由于 cookie 丟失導(dǎo)致用戶進入不了年報的問題；通過對音頻播放的監(jiān)控，明確了站內(nèi)需要支持音視頻的自動播放。

數(shù)據(jù)準(zhǔn)確

最后數(shù)據(jù)準(zhǔn)確性也是質(zhì)量優(yōu)的重要組成部分。其中需要關(guān)注兩個方面。首先，需要確保用戶界面的數(shù)據(jù)準(zhǔn)確無誤，這包括對服務(wù)端可能出現(xiàn)的異常情況進行兜底處理，例如服務(wù)端下發(fā)數(shù)據(jù)失敗或者下發(fā)敏感數(shù)據(jù)等情況需。其次，要確保上報后臺的埋點數(shù)據(jù)不會漏報、重復(fù)報或者缺失關(guān)鍵信息。這些埋點數(shù)據(jù)的準(zhǔn)確性直接影響策劃和開發(fā)的實時決策。

工程效率

除了體驗好、質(zhì)量優(yōu)，效率高也是開發(fā)一直追求的命題。

對于策劃或者視覺來說，需求的頻繁變更是項目最大的風(fēng)險。這要求開發(fā)團隊能夠預(yù)見并總結(jié)可能出現(xiàn)變更的情況。例如，頁面順序會根據(jù)內(nèi)測用戶的反饋進行調(diào)整，頁面數(shù)量可能會根據(jù)線上頁面的流失率進行刪除。在例如，視覺要求頁面之間有統(tǒng)一的轉(zhuǎn)場效果，但是針對某些特殊頁面，要求工程應(yīng)該能夠支持自定義的轉(zhuǎn)場效果。

對于 QA 或者客服來說，當(dāng)用戶反饋問題時，他們應(yīng)能夠通過快捷方式查看該用戶的年報。同時，由于年報通常包含 30+ 頁面，他們希望能有一種快速定位到特定頁面的方法。通過這種方式，他們可以自助定位并解決部分線上客訴。在排除了用戶自身、數(shù)倉或者服務(wù)端的問題后，再將問題提到前端。

對于開發(fā)者來說，期望有一套開箱即用的基礎(chǔ)組件，如圖片、視頻、音頻等?；蛘吣軌蛟陧椖縿?chuàng)建初期，就能有一個包含基礎(chǔ)交互、數(shù)據(jù)模型和常用基礎(chǔ)組件的年報模板。更進一步是，希望在開發(fā)過程使用使用D2C的插件，通過視覺稿直接生成代碼。更終極的狀態(tài)是，策劃和運營通過搭建平臺能自助地構(gòu)建出年報項目。

圖片

簡而言之，效率高涉及以下幾個方面：

1、頁面導(dǎo)航：包括頁面自動曝光、支持動態(tài)路由等

2、功能調(diào)試：包括年報快捷查看，頁面快速定位等

3、工程基建：包括通用組件/能力，年報模板，D2C 插件，搭建平臺等

為了實現(xiàn)各個活動之間的能力復(fù)用，可以將活動成果都會統(tǒng)一沉淀到活動研發(fā)平臺。

這個平臺覆蓋了活動的完整生命周期，包括開發(fā)前期需要參考的技術(shù)方案，UI組件，通用能力，活動模板，開發(fā)中期需要的功能開關(guān)、分享內(nèi)容等配置，以及開發(fā)后期需要用到保障SOP和監(jiān)控告警等。

圖片

后續(xù)在年報項目的初期階段，計劃通過活動研發(fā)平臺的年報模板工程，快速搭建出年報的項目?；谶@個初始化工程，數(shù)據(jù)開發(fā)團隊能盡早進行的自測稽查。

深度思考

最終年報項目按照預(yù)期順利拿到業(yè)務(wù)結(jié)果。再次回顧立項初期，開發(fā)并不是簡單被動接收目標(biāo)，簡單的將需求實現(xiàn)。可以從業(yè)務(wù)和技術(shù)關(guān)系分析出發(fā)，定性、定量分析項目目標(biāo)是否能夠達成。

關(guān)系分析

業(yè)務(wù)和技術(shù)的關(guān)系可以劃分為三大類別：業(yè)務(wù)驅(qū)動技術(shù)、技術(shù)保障業(yè)務(wù)、技術(shù)引領(lǐng)業(yè)務(wù)。

業(yè)務(wù)驅(qū)動技術(shù)的一個典型例子是2020年報[3]中的DIY音樂人物形象。這是開發(fā)第一次在大型項目中使用 three.js。項目的初期，需要做大量的技術(shù)調(diào)研，并需要快速解決一些從未碰過的難題。項目的過程中，由于技術(shù)局限性，策劃不得不妥協(xié)，對需求進行調(diào)整。在業(yè)務(wù)驅(qū)動技術(shù)的情況下，大部分情況是未知的，這會使得開發(fā)處于高度緊張的狀態(tài)，也可能導(dǎo)致技術(shù)動作的變型。

技術(shù)引領(lǐng)業(yè)務(wù)的一個典型例子是性格POP[4]。在這個項目中，開發(fā)主導(dǎo)了整過程，他們基于矩形樹圖算法實現(xiàn)一個無縫擠壓的動效。策劃團隊根據(jù)這個特定的動效，定制業(yè)務(wù)需求。在技術(shù)引領(lǐng)業(yè)務(wù)的情況下，由于整個過程因為都是已知的，開發(fā)都是胸有成竹的狀態(tài)，這通常會使業(yè)務(wù)的收益超出預(yù)期。

大部分的需求都是屬于技術(shù)保障業(yè)務(wù)的情況。這要求開發(fā)對當(dāng)前的工程能力有清晰的認(rèn)知，并協(xié)助策劃做出最合理的決策。開發(fā)需要科學(xué)分析業(yè)務(wù)目標(biāo)是否能達成，可以有效地管理策劃的心理預(yù)期。

圖片

需要多積累技術(shù)知識，減少業(yè)務(wù)驅(qū)動技術(shù)的被動情況出現(xiàn)。同時也需要提升對業(yè)務(wù)的敏銳度，讓技術(shù)引領(lǐng)業(yè)務(wù)的發(fā)展。最后將知識和經(jīng)驗沉淀，從而更好保障業(yè)務(wù)的需求。

定量分析

2023年報就是典型的技術(shù)保障業(yè)務(wù)的場景。在業(yè)務(wù)立項初期，產(chǎn)品目標(biāo)是日活xx千萬，活動分享率 xx%。

圖片

項目初期項目負(fù)責(zé)人不應(yīng)埋頭搬磚，需要先通過現(xiàn)有數(shù)據(jù)，理性分析業(yè)務(wù)目標(biāo)是否能達成。

圖片

分析顯示，目前 Android 和 iOS 雙端的日活累計是X千萬。這個數(shù)字實際設(shè)定了年報日活躍用戶的上限。如果這個上限都不能滿足業(yè)務(wù)目標(biāo)，那開發(fā)需要尋找更多的推廣渠道。除了現(xiàn)有的移動端設(shè)備，可以考慮其他有多終端設(shè)備，如PC、iPad和TV，還可以考慮支持例如微信等站外渠道。這樣開發(fā)階段，需要重點考慮如何適配這些不同的用戶界面。

在確定投放渠道之后，可以進一步分析每個渠道內(nèi)的投放位置。例如，在移動端通常會選擇在首頁首幀 banner、首頁彈窗、以及其他高日活的頁面進行投放。細(xì)化分析每個位置的用戶點擊率，最終能初步預(yù)估活動的日活。在投放位置有限情況，如果這個預(yù)估值無法達到業(yè)務(wù)目標(biāo)，那么需要額外開發(fā)其它點擊率較高的位置，如啟動開屏位，供策劃選擇。

在不同角色中，對分享率這個指標(biāo)的定義可能會有所不同。因此，在項目啟動的前期，開發(fā)需要和策劃達成一致，明確如何統(tǒng)計活動的分享率。在明確統(tǒng)計口徑后，分析現(xiàn)有的分享行為，包括圖片分享、鏈接分享、口令分享和截屏分享。需要注意，截屏分享是最容易忽略統(tǒng)計的一種分享行為。接下來，分析不同分享行的流程。如下圖所示列出了不同分享行為所需要經(jīng)過的路徑。

圖片

在這些路徑下進行數(shù)據(jù)埋點，以便能夠觀察和分析影響分享率的漏斗。通過結(jié)合對漏斗的專項治理和過往活動的數(shù)據(jù)，最終也能準(zhǔn)確預(yù)估年報的數(shù)據(jù)。

圖片

定性分析

日活和分享率很大程度取決于年報的產(chǎn)品創(chuàng)意是否足夠新穎。產(chǎn)品創(chuàng)意需要將用戶的聽歌數(shù)據(jù)以字體、圖片、動效、音頻、視頻等多種方式準(zhǔn)確地展示給用戶，從而引發(fā)用戶的共鳴。而作為開發(fā)者，需要以流暢、準(zhǔn)確、且高效的方式將這些多元的媒體內(nèi)容傳達給到用戶。

案例一：得益于今年年報對體驗和質(zhì)量的高要求，上線后 5 日總客訴量比往年減少了 41%，收獲了大批用戶好評。

圖片

案例二：首頁banner投放，從用戶點擊到 H5 頁面打開，頁面達到率 Android 端只有93%左右。假設(shè)將頁面到達率從 93% 優(yōu)化到 97% 以上，對年報帶來收益大概是是新增上百萬的日活用戶。

因此，好的用戶體驗和高的產(chǎn)品質(zhì)量能夠有效地促進年報的分享，從而進一步提升日活躍用戶數(shù)量。

總結(jié)

一款深入人心的作品，不僅要有優(yōu)質(zhì)的產(chǎn)品內(nèi)容支撐，有效的技術(shù)優(yōu)化和保障也不可或缺，具體總結(jié)如下圖：

圖片

最后本文從2023年度報告中的性能體驗、質(zhì)量監(jiān)控和工程效率等方面出發(fā)，介紹了筆者在年報項目經(jīng)歷中的一些探索和經(jīng)驗。

參考資料

[1]SPA: https://developer.mozilla.org/en-US/docs/Glossary/SPA

[2]更多API詳情見此鏈接: https://react.dev/reference/react-dom#resource-preloading-apis

[3]2020年報: https://st.music.163.com/c/year2020

[4]性格POP: https://sg.music.163.com/jia/begin/show