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