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