成為全?！lutter App 篇·服務端目錄與文章輔助閱讀錨點、上下篇、瀏覽量和閱讀歷史上一篇解決了目錄項怎么綁到標題上。這篇接著說文章頁里其余那些看起來都很小、但每個都有自己的坑的功能目錄面板、上下篇、瀏覽量、閱讀歷史。四個功能四種不同的數據性質功能數據性質請求時機寫操作目錄正文的一部分跟正文一起無上下篇按發(fā)布時間推導跟正文一起無瀏覽量寫多讀少、不能重復計進入時上報一次有閱讀歷史私有、隨閱讀行為變化本地 同步有前兩個是讀一次就好后兩個是要寫、要同步、要防重。這篇的重點在后者以及一個我在實現 id/slug 別名時才想明白的設計。正文和目錄必須是一個版本先說一個容易被忽略的前提目錄不是獨立請求的。/// 已發(fā)布正文與目錄作為一個版本保存避免目錄指向舊內容。classArticleReader{這個類把正文和目錄當作一個整體存進同一個緩存鍵。為什么必須綁在一起設想分開放的情況目錄緩存 1 天正文緩存 1 小時。用戶讀了一半編輯更新了這篇文章——下一次用戶刷新正文變成新版了但目錄還是舊的。結果就是目錄里那些錨點指向的位置全部偏移點一個跳到錯的地方。而且這個 bug 極難發(fā)現文章短的時候目錄只有兩項錯位也看不出來長文章用戶也不會去逐個點。所以現在的策略是寧可一起過期。正文十分鐘更新一次目錄跟著一起。代價是文章更新后目錄要多等十分鐘才刷新——這個代價明顯小于目錄跳轉錯亂。這個判斷的通用形式是當兩個數據存在語義依賴時它們的緩存生命周期應該取交集而不是各自最優(yōu)化。id 與 slug 的別名問題現在說那個讓我想了一會兒的設計。契約里文章詳情是GET /articles/{idOrSlug}id 和 slug 都接受。這本來是件好事——URL 好看用戶能收藏。但它帶來了一個緩存問題同一篇文章有兩個可能的鍵。用戶在 App 里通過route進來看用的是 slug而從列表點進來用的是Article.route有 slug 用 slug沒有用 id——看起來一致但只要有一個地方用了 id緩存就會分裂成兩份。而且更麻煩的是用戶可能先讀 id 版本的緩存然后從 slug 版本進來界面上毫無區(qū)別但走了兩次網絡請求。現在的解法是一張別名表finalaliasesString,String{};// id 與 slug 恢復到同一正文鍵磁盤別名必須匹配當前 API 環(huán)境。FutureMapString,dynamicread(Stringid,{bool forcefalse})async{varcanonicalaliases[id]??id;if(!aliases.containsKey(id)!force){finalpersistedawaitcache.disk.findKey((key,meta)matchesAlias(key,meta,id),);if(persisted!null){canonicalCacheKey.tryParse(persisted)!.path.substring(CacheKeys.articlePrefix.length);}}finalkkey(CacheKeys.article(canonical),const{});拆開看這個邏輯內存里有別名直接用aliases是運行時攢的沒有去磁盤上掃看有沒有一個緩存鍵指向同一篇文章找到了就把它記進aliases之后都走它關鍵在第二步那個cache.disk.findKey。因為App 重啟后內存別名就沒了但磁盤緩存還在。這時候如果不做這個掃描用戶重啟后進文章又會重新請求一次。而matchesAlias(key, meta, id)那個判斷里有一條關鍵約束——注釋里寫著磁盤別名必須匹配當前 API 環(huán)境。因為開發(fā)環(huán)境和線上環(huán)境的 baseUrl 不同如果把開發(fā)環(huán)境的 slug 別名帶到線上環(huán)境會把兩個環(huán)境的緩存搞混。別名表是內存 磁盤雙層的而且磁盤那層要校驗環(huán)境。這聽起來像過度設計但它擋的是一類很難復現的 bug開發(fā)時緩存里全是別名切到線上環(huán)境后突然大量請求而且原因不明。別名表在什么時機失效看 M4-07 里那段this.cache.events.listen((e){if(e.kindremovede.key.contains(CacheKeys.articlePrefix)){articleReader.aliases.clear();this.cache.invalidate({articleLists});}});文章緩存被刪除時別名表也清空。因為別名指向的正文已經不存在了再拿著舊別名去查會得到 404。目錄面板讓失效項變灰目錄面板的實現比我想的有意思。核心是這一行enabled:keys[t.anchor]?.currentContext!null,onTap:(){Navigator.pop(c);finaltargetkeys[t.anchor]?.currentContext;if(target!null){Scrollable.ensureVisible(target,duration:MediaQuery.disableAnimationsOf(context)?Duration.zero:constDuration(milliseconds:250),alignment:.05,);}},enabled:這個屬性做了一件很樸素但很有效的事錨點沒匹配上的目錄項灰掉、不可點?；氐?M4-13 說的那個游標對齊算法——它是寧可漏也不錯的原則所以理論上確實可能有標題拿不到 anchor。那么這些目錄項該怎么表現可點但點了沒反應 → 用戶反復點以為 App 卡了灰掉不可點 → 用戶知道這個跳不了但不會怪 App第二種明顯更好而且它只需要一個判斷。這也是 M4-13 那段寧可讓某個標題點不動的下游兌現——那里的保守選擇在這里變成了 UI 上可見的合理反饋。if (target ! null)那道檢查是雙保險enabled只影響點擊回調的觸發(fā)真正的執(zhí)行時還要再確認一次。因為onTap觸發(fā)到實際執(zhí)行之間頁面狀態(tài)可能變了。而MediaQuery.disableAnimationsOf(context)這個判斷值得單獨說系統(tǒng)關閉動畫時滾動動畫也應該是 0 延時的。這是無障礙要求的實際應用。有些人因為前庭功能障礙在系統(tǒng)里關掉了動畫App 里如果還播 250ms 的滾動他們會非常不適。而這個信息是可以從系統(tǒng)讀到——不用猜也不用自己加開關。alignment: .05是滾動終點時目標標題離頂部的距離留一點空隙別把標題貼在狀態(tài)欄下面。上下篇它不是上一頁下一頁上一篇和下一篇聽起來簡單。實現的時候發(fā)現一個定義問題上一篇是按發(fā)布時間倒數的上一條嗎如果是那同一分類下的兩篇文章之間可能根本沒有上一篇——用戶直接從一個分類跳進來沒有上下文。所以現在的口徑是用全文流里的相鄰文章而不是分類內的相鄰文章。用戶讀了一篇《接口設計》上一篇是《數據建模》即使這兩篇分類完全不同——它們在時間流上是相鄰的而接著讀這個需求是連續(xù)的。這個決定的代價是上下篇可能和用戶在分類頁看到的順序不一致。一個從前端分類進來的人看到的上一篇可能是篇 Node 后端文章。兩種口徑都有道理我選了全文流理由是它總能給出結果。分類口徑下前后篇可能都為空那時候界面就是一個空區(qū)域用戶得自己回去找導航。上下篇的數據來自adjacent這個資源家族ResourceFamily.adjacent:_ReadRule(CachePolicy(Duration(minutes:5),Duration(hours:1)),_Shape.object,),五分鐘新鮮、一個小時過期不落盤。理由是它和正文是同一篇的上下文變化頻率接近但獨立請求一次沒必要緩存太久。瀏覽量不能重復計但不能漏瀏覽量是寫操作麻煩的地方在于去重和防刷這兩個要求是對立的。不重復計用戶反復進入同一篇文章不能每次都 1。防刷惡意腳本不能刷。后端 M1 已經做了防刷——去重 24 小時冷卻。而客戶端要配合的是同一個用戶的同一次閱讀只上報一次。關鍵判斷是這個一次是按什么算的我最初的實現是進入文章頁就上報。結果發(fā)現兩個問題第一用戶從列表點開文章、切到別的 Tab 又切回來——initState可能重跑上報兩次。第二從上一篇跳到下一篇兩篇文章各上報一次這個是對的但如果連點兩次同一個鏈接就會報兩次?，F在改成綁定文章 id 的上報記錄// 具體實現藏在文章頁狀態(tài)里規(guī)則是// 同一個 articleId 在本次 App 運行期間只上報一次這個本次 App 運行期間的限定詞很重要。它意味著用戶殺 App 重進再讀一遍會再計一次 → 合理因為這是新的一次閱讀用戶反復進出同一篇 → 只計一次 → 合理用戶換設備讀 → 會再計一次 → 接受這個不精確為什么不做得更精確精確意味著要記錄用戶在什么位置讀到了百分之多少數據量大了很多而對內容產品來說收益很小。瀏覽量的誤差容忍度很高但它必須有一個下界——不能是 0。瀏覽量的上報失敗不提示用戶。這是個后臺行為失敗了用戶也無從補救彈個錯誤只會讓用戶困惑。這個判斷看起來有點武斷但它體現了一個原則錯誤的可見性應該和用戶的處置能力匹配。閱讀歷史本地優(yōu)先同步兜底最后一個也是唯一一個真正需要處理離線的產品功能。閱讀歷史的需求有三個跨設備能看到、離線也能看、不重復記錄同一篇文章?，F在的策略是本機存儲 登錄后同步場景數據來源登錄用戶在線服務端權威登錄用戶離線本機最近同步的未登錄只有本機服務端那份是權威的因為它跨設備。本機那份是緩存讓離線可用。麻煩點在寫入。用戶讀到第 5 頁就退出了——這篇文章算讀過嗎現在的口徑是停留超過 20 秒且滾動超過一屏才記入歷史。這兩個條件缺一不可。只有停留時間的話一個手滑點進來立刻退出的也算只有滾動的話用戶可能停在第一屏沒往下看那顯然不算讀完。20 秒和一屏這兩個具體數字是可調的但必須有閾值。一個打開就記的閱讀歷史毫無價值——它會把用戶所有點過的文章都記上包括那些他根本不想看的。而本機那份要按賬號隔離// 會話隔離清理不影響公開資源也不觸及按賬號保存的投稿草稿。voidresetPrivate(){...favoriteIndex.resetFavoriteIndex();reactions.clear();...cache.invalidate({private});M4-09 講過這個resetPrivate。這里體現出來的是用戶 A 退出登錄后A 的閱讀歷史不能被用戶 B 看到。如果閱讀歷史沒做賬號隔離那就是一個實實在在的隱私問題——同一臺手機上切換賬號另一個人能看到你讀過什么。而這在共享設備比如家人的平板上很容易發(fā)生。這一頁的四組緩存策略把它們放一起看這篇文章其實沒什么業(yè)務邏輯全是策略功能資源家族freshmaxAge落盤私有正文 目錄article10 分鐘24 小時是否上下篇adjacent5 分鐘1 小時否否瀏覽量上報article————閱讀歷史history30 秒5 分鐘否是四個決策點每個都有明確的理由正文落盤、上下篇不落盤。正文是用戶反復要看的而且斷了網絡也要能讀上下篇是順帶功能離線時看不到無所謂省下的磁盤空間更值得。上下篇比正文新鮮期長。因為它的數據來自同一篇文章的關聯查詢服務端不需要額外計算而它又不常變。閱讀歷史不落盤。私有數據落盤意味著要處理用戶卸載前的數據會不會殘留成本高于收益。瀏覽量不走緩存。它是寫請求每次都要真發(fā)。一條我一開始想省掉的事閱讀歷史的停留 20 秒 滾動一屏我第一版只做了滾動檢測。理由是滾動說明用戶真的在看比停留時間靠譜。結果用戶反饋說有些文章他就想快速掃一遍要點看到了就退這種也被記進了歷史。這個反饋讓我意識到停留時間不該被當成次要指標?？焖賿咦x是真實的閱讀行為它和點錯了立刻返回在滾動數據上可能很像都沒滾很遠但在時間上差很多。于是兩個條件變成并列關系。而加了時間條件之后的副作用是用戶網絡不好、文章加載慢的那 20 秒里可能什么都沒看到但仍會被計入。這個副作用我知道存在?，F在的判斷是這類誤差和收益不成比例——誤記一次閱讀的成本遠低于漏記一次的成本。同樣的權衡在瀏覽量上也做了寧可能多計一次不能少計。這兩處的共同點是瀏覽類數據允許有誤差但誤差的方向必須是偏高。因為偏低的數據會讓人覺得我的文章沒人看那是真實的問題偏高只是統(tǒng)計不精確沒人因此受損。小結文章頁看起來是全項目最簡單的一頁——它沒有表單、沒有列表、沒有并發(fā)寫。但實際做完發(fā)現四個小功能里有三個的難度不在實現在定義目錄和正文必須同版本—— 兩個有語義依賴的數據緩存生命周期取交集。id/slug 別名要跨重啟—— 內存別名 磁盤掃描且校驗 API 環(huán)境。失效的目錄項要變灰—— 下游的保守選擇需要在上游變成可見的合理反饋。閱讀要有閾值—— 停留 滾動且接受偏高的誤差方向。第二個和第三個尤其值得記。id/slug 別名那個問題在測試環(huán)境幾乎發(fā)現不了因為測試每次都用同一個 key 進而目錄項變灰的價值只有真的發(fā)生過錨點失配的人才知道。還有一條是貫穿全系列的無障礙不是附加項。目錄滾動動畫讀系統(tǒng)設置M4-14M4-26 講測試時會看到可訪問性的自動化檢查。它們都是同一個思路——能用系統(tǒng)提供的信息推斷的就不要自己猜。下一篇講 WebView。它和前面所有頁面都不同因為它要在 App 里放一個瀏覽器。延伸閱讀Flutter Markdown 閱讀器支持范圍與渲染邊界Dio Repository統(tǒng)一響應信封與模型適配文章閱讀輔助上下篇、面包屑、相關文章與閱讀記錄如果這篇文章對你有幫助歡迎訂閱我的 CSDN 專欄「成為全?！?專欄地址https://blog.csdn.net/fungleo/category_13204651.html 本系列配套代碼倉庫https://github.com/fengcms/become-a-full-stack-developer