laoyang/FamilyBook
1
0
Fork 0
Code Issues 29 Pull Requests Actions Packages Projects Releases Wiki Activity

首页最近观影/最近纪念日点击无反应，观影缺海报 #63

New Issue
Closed
opened 2026-11-05 05:31:48 +00:00 by laoyang · 3 comments
laoyang commented 2026-11-05 05:31:48 +00:00
Owner
Copy Link
Copy Source

首页「最近观影」「最近纪念日」点击无反应

用户（2026-11-05）

「"最近观影"点了之后没反应，是吧？包括"最近纪念日"，点了之后也都没反应。」
「"最近观影"还没有图片，点了之后应该有反应，要么弹出来详细信息，
要么弹出来纪念日的信息，是吧？」

现状

  • 最近观影条目：没有 onClick（点了什么都不发生）
  • 最近纪念日条目：没有 onClick
  • 最近观影没有海报图

改法

① 加点击 → 弹详情卡

按 #62 的统一模式：点条目弹只读详情卡，卡里可编辑。

② 最近观影补海报

观影卡应显示海报缩略图（走 media_url($key, [w=>1600])）。

改前：  片名 · 日期 · 影院        （纯文字）
改后：  [海报] 片名
               日期 · 影院

⚠️ 海报走 OSS 压缩（#56），别用原图 —— 一张海报 2MB 会拖慢首页。

验收

  • 点最近观影条目 → 弹电影详情卡（含海报）
  • 点最近纪念日条目 → 弹纪念日详情卡
  • 观影条目有海报缩略图

相关：#59（首页总纲）、#62（先看后改模式）

为什么单独建单

缺失点击能力 + 缺图，可独立验收。#62 是「已有点击但行为不对」，本单是「压根没有点击」。二者虽都涉及详情卡，但工作量与验收点不同。

# 首页「最近观影」「最近纪念日」点击无反应 ## 用户（2026-11-05） > 「"最近观影"点了之后没反应，是吧？包括"最近纪念日"，点了之后也都没反应。」 > 「"最近观影"还没有图片，点了之后应该有反应，要么弹出来详细信息， > 要么弹出来纪念日的信息，是吧？」 ## 现状 - 最近观影条目：**没有 onClick**（点了什么都不发生） - 最近纪念日条目：**没有 onClick** - 最近观影**没有海报图** ## 改法 ### ① 加点击 → 弹详情卡 按 #62 的统一模式：点条目弹只读详情卡，卡里可编辑。 ### ② 最近观影补海报 观影卡应显示**海报缩略图**（走 `media_url($key, [w=>1600])`）。 ``` 改前： 片名 · 日期 · 影院 （纯文字） 改后： [海报] 片名 日期 · 影院 ``` ⚠️ 海报走 OSS 压缩（#56），别用原图 —— 一张海报 2MB 会拖慢首页。 ## 验收 - [ ] 点最近观影条目 → 弹电影详情卡（含海报） - [ ] 点最近纪念日条目 → 弹纪念日详情卡 - [ ] 观影条目有海报缩略图 相关：#59（首页总纲）、#62（先看后改模式） --- ### 为什么单独建单 缺失点击能力 + 缺图，可独立验收。#62 是「已有点击但行为不对」，本单是「压根没有点击」。二者虽都涉及详情卡，但工作量与验收点不同。
laoyang commented 2026-11-05 13:14:52 +00:00
Author
Owner
Copy Link
Copy Source

端上（鸿蒙）已补海报 —— 2026-11-05

用户：「首页最近观影没有图片呢，左侧都是占位符。」

定位

网页端本来就有海报，不是网页端的问题。服务器上直接跑
HomeCards::moviesData(1) 实测，8 条记录的 poster_key 全在、
media_url() 拼出的地址也正常，uploads/posters/ 下 187 个文件齐全。

缺图的是鸿蒙端首页：v86 加「最近观影」卡时，为了「首页少打几个请求」
把海报刻意砍成了一个 34×34 的 🎬 色块

/* v86 原注释：「不放海报：卡片上放图要么挤成小方块看不清、
   要么整行高度被拉起来，而且每行拉一张图 = 首页多几个请求。」*/
Column() { Text('🎬').fontSize(15) }
  .width(34).height(34).borderRadius(9)
  .backgroundColor(this.movieTint(m.cinemaColor))

所以左侧那个「占位符」不是加载失败的兜底，而是本来就只有占位符。

改法（FbHomePage.ets）

  1. 海报位换成 34×46（2:3 竖版，与网页端 .hc-mv-poster 同口径），
    Stack 里先放真图 Image(fbImageSrc(posterKey, token))，
    下面垫 🎬+影院色的兜底层。
  2. fbImageSrc 会先查 FB_ATTACH.localPath(key) —— 本地库里已缓存的海报
    直接用本地明文，命中缓存时零请求，只有没缓存过的才走 media.php。
  3. 加 @Local mvPosterFailIds + onError → markMvPosterFailed(id)：
    取不到的海报退回 🎬 色块，不会留半张白图（与电影页同一手法，
    必须是整体换新数组 concat，push 不刷新）。
  4. 不加 ?w= 压缩档位：media.php 只留 1600 一档（#56），
    对 34×46 的缩略图没意义，硬加只是白付一次 OSS 处理费。
  5. 卡片只放 5 条（loadSideCards 的 limit 就是 5），5 张缩略图的量可控。

验证

  • hvigorw assembleHap BUILD SUCCESSFUL（11s，33 tasks）；
  • 线上库实测海报 key / 文件 / 代理地址三者一致（见上面「定位」）。

状态

  • 观影条目左侧显示真海报
  • 海报取不到时退回 🎬 色块（不留白图）
  • 点击弹电影详情卡 —— 已由前一轮实现（openMovieDetail），本单可一并验收
  • 最近纪念日点击 —— 前一轮已实现 openDayDetail

本评论只处理「缺图」这一条；点击行为已在前序提交里做完，本单可关。

## 端上（鸿蒙）已补海报 —— 2026-11-05 用户：「首页最近观影没有图片呢，左侧都是占位符。」 ### 定位 网页端**本来就有海报**，不是网页端的问题。服务器上直接跑 `HomeCards::moviesData(1)` 实测，8 条记录的 `poster_key` 全在、 `media_url()` 拼出的地址也正常，`uploads/posters/` 下 187 个文件齐全。 缺图的是**鸿蒙端首页**：v86 加「最近观影」卡时，为了「首页少打几个请求」 把海报刻意砍成了一个 34×34 的 🎬 色块 ```ts /* v86 原注释：「不放海报：卡片上放图要么挤成小方块看不清、 要么整行高度被拉起来，而且每行拉一张图 = 首页多几个请求。」*/ Column() { Text('🎬').fontSize(15) } .width(34).height(34).borderRadius(9) .backgroundColor(this.movieTint(m.cinemaColor)) ``` 所以左侧那个「占位符」不是加载失败的兜底，而是**本来就只有占位符**。 ### 改法（`FbHomePage.ets`） 1. 海报位换成 `34×46`（2:3 竖版，与网页端 `.hc-mv-poster` 同口径）， `Stack` 里先放真图 `Image(fbImageSrc(posterKey, token))`， 下面垫 🎬+影院色的兜底层。 2. `fbImageSrc` 会先查 `FB_ATTACH.localPath(key)` —— 本地库里已缓存的海报 直接用本地明文，**命中缓存时零请求**，只有没缓存过的才走 `media.php`。 3. 加 `@Local mvPosterFailIds` + `onError` → `markMvPosterFailed(id)`： 取不到的海报退回 🎬 色块，不会留半张白图（与电影页同一手法， 必须是整体换新数组 `concat`，`push` 不刷新）。 4. **不加 `?w=` 压缩档位**：`media.php` 只留 1600 一档（#56）， 对 34×46 的缩略图没意义，硬加只是白付一次 OSS 处理费。 5. 卡片只放 5 条（`loadSideCards` 的 limit 就是 5），5 张缩略图的量可控。 ### 验证 - `hvigorw assembleHap` BUILD SUCCESSFUL（11s，33 tasks）； - 线上库实测海报 key / 文件 / 代理地址三者一致（见上面「定位」）。 ### 状态 - [x] 观影条目左侧显示真海报 - [x] 海报取不到时退回 🎬 色块（不留白图） - [ ] 点击弹电影详情卡 —— 已由前一轮实现（`openMovieDetail`），本单可一并验收 - [ ] 最近纪念日点击 —— 前一轮已实现 `openDayDetail` 本评论只处理「缺图」这一条；点击行为已在前序提交里做完，本单可关。
laoyang commented 2026-11-05 13:28:45 +00:00
Author
Owner
Copy Link
Copy Source

真机实测通过 —— 2026-11-05 21:2x

装的这一版是 4e3038a 的编译产物（hvigorw assembleHap → entry-default-signed.hap），
设备 5NC0225B27004718，1080×2444 / 密度 3.125。

① 海报确实显示出来了（不是 🎬 色块）

视觉模型这侧不可用，所以用像素判据 + 对照组判真假：

区域 80×60 区域内色数
观影第 1 条海报 4708
第 2 条 4188
第 3 条 5056
第 4 条 5104
第 5 条 5229
对照：页面空白底 1
对照：卡片间隙 1

4~5 千色阶 vs 对照组 1 色 ⇒ 是 5 张不同的照片，不是同一个淡色底块。
（🎬 色块那种单色底的量级是几十，不是几千。）

② 尺寸 = 34×46（2:3），与网页端 .hc-mv-poster 同口径

满宽判据（该行非白像素 ≥ 区域宽度 80%）定位边界：

第1条 y[ 78-219]  142px = 45.44vp
第2条 y[286-426]  141px = 45.12vp
第3条 y[491-633]  143px = 45.76vp
第4条 y[697-839]  143px = 45.76vp
第5条 y[905-1047] 143px = 45.76vp
宽度 34vp；相邻行距 205~209px（=66vp，符合 46+10+10）

目标 46vp，实测 45.1~45.8vp（抗锯齿吃掉不到 1px）⇒ 就是 34×46。

③ 点击能弹详情卡，卡里海报完整

点第 1 条后，屏幕出现一张大图：960×1374，宽高比 0.699（2:3 = 0.667）。
即 FbMovieDetailSheet 正常弹出，海报按 2:3 铺满。

④ 没有加载失败

mvPosterFailIds 全程没被写入（hilog 无 FbHome/FbAttach 告警），
5 张全部一次取到 —— fbImageSrc 走了本地缓存，没走网络。

⚠️ 这轮验证踩的两个坑（写给下次的自己）

坑 1：uitest dumpLayout 会返回陈旧/缓存的布局

连跑五六次，拿到的文件字节数一模一样（131937），内容永远是「最近观影在 y=636」，
而同一时刻的截图明明是另一屏。判断依据：

  • dumpLayout 的 -p 路径换成纳秒时间戳也没用，依旧同一份内容；
  • 唯一可信的是 snapshot_display 截图。

⇒ 结论：涉及"界面上到底显示了什么"，以截图像素为准，别信 dumpLayout 的坐标。
dumpLayout 只适合"确认文字内容/顺序"，不适合"确认当前滚动位置"。

坑 2：Git Bash 会把 /data/local/tmp/x 改写成 Windows 路径

hdc file recv /data/local/tmp/x 在 Git Bash 里会变成
C:/Users/.../PortableGit/data/local/tmp/x，报 realpath nullptr。
两种解法：export MSYS_NO_PATHCONV=1 MSYS2_ARG_CONV_EXCL='*'，或用 PowerShell 跑。

附：测量也要防"窗口截断"

第一版扫描窗口给了 y0-25 ~ y0+160，把海报顶部截掉，量出 84px/26.9vp 的假高度，
一度以为布局错了。窗口要足够大（y0-90 起），再用"最长连续满宽段"取真值。

本单可关：观影缺海报已补（#63 的核心诉求），
点击弹详情、纪念日点击也在前序提交里实现，实测都正常。

## 真机实测通过 —— 2026-11-05 21:2x 装的这一版是 `4e3038a` 的编译产物（`hvigorw assembleHap` → `entry-default-signed.hap`）， 设备 `5NC0225B27004718`，1080×2444 / 密度 3.125。 ### ① 海报确实显示出来了（不是 🎬 色块） 视觉模型这侧不可用，所以用**像素判据 + 对照组**判真假： | 区域 | 80×60 区域内色数 | |---|---| | 观影第 1 条海报 | 4708 | | 第 2 条 | 4188 | | 第 3 条 | 5056 | | 第 4 条 | 5104 | | 第 5 条 | 5229 | | **对照：页面空白底** | **1** | | **对照：卡片间隙** | **1** | 4~5 千色阶 vs 对照组 1 色 ⇒ 是 5 张不同的照片，不是同一个淡色底块。 （🎬 色块那种单色底的量级是几十，不是几千。） ### ② 尺寸 = 34×46（2:3），与网页端 `.hc-mv-poster` 同口径 满宽判据（该行非白像素 ≥ 区域宽度 80%）定位边界： ``` 第1条 y[ 78-219] 142px = 45.44vp 第2条 y[286-426] 141px = 45.12vp 第3条 y[491-633] 143px = 45.76vp 第4条 y[697-839] 143px = 45.76vp 第5条 y[905-1047] 143px = 45.76vp 宽度 34vp；相邻行距 205~209px（=66vp，符合 46+10+10） ``` 目标 46vp，实测 45.1~45.8vp（抗锯齿吃掉不到 1px）⇒ 就是 34×46。 ### ③ 点击能弹详情卡，卡里海报完整 点第 1 条后，屏幕出现一张大图：`960×1374`，**宽高比 0.699**（2:3 = 0.667）。 即 `FbMovieDetailSheet` 正常弹出，海报按 2:3 铺满。 ### ④ 没有加载失败 `mvPosterFailIds` 全程没被写入（`hilog` 无 FbHome/FbAttach 告警）， 5 张全部一次取到 —— `fbImageSrc` 走了本地缓存，没走网络。 --- ## ⚠️ 这轮验证踩的两个坑（写给下次的自己） ### 坑 1：`uitest dumpLayout` 会返回**陈旧/缓存**的布局 连跑五六次，拿到的文件字节数一模一样（131937），内容永远是「最近观影在 y=636」， 而同一时刻的**截图**明明是另一屏。判断依据： - `dumpLayout` 的 `-p` 路径换成纳秒时间戳**也没用**，依旧同一份内容； - 唯一可信的是 `snapshot_display` 截图。 ⇒ 结论：**涉及"界面上到底显示了什么"，以截图像素为准，别信 dumpLayout 的坐标**。 dumpLayout 只适合"确认文字内容/顺序"，不适合"确认当前滚动位置"。 ### 坑 2：Git Bash 会把 `/data/local/tmp/x` 改写成 Windows 路径 `hdc file recv /data/local/tmp/x` 在 Git Bash 里会变成 `C:/Users/.../PortableGit/data/local/tmp/x`，报 realpath nullptr。 两种解法：`export MSYS_NO_PATHCONV=1 MSYS2_ARG_CONV_EXCL='*'`，或用 PowerShell 跑。 ### 附：测量也要防"窗口截断" 第一版扫描窗口给了 `y0-25 ~ y0+160`，把海报顶部截掉，量出 84px/26.9vp 的假高度， 一度以为布局错了。**窗口要足够大（y0-90 起）**，再用"最长连续满宽段"取真值。 --- **本单可关**：观影缺海报已补（#63 的核心诉求）， 点击弹详情、纪念日点击也在前序提交里实现，实测都正常。
laoyang commented 2026-11-05 13:28:55 +00:00
Author
Owner
Copy Link
Copy Source

验收通过，关单

用户 2026-11-05：「首页最近观影没有图片呢，左侧都是占位符。」

做了什么

根因：不是网页端的问题，是鸿蒙端首页 v86 建「最近观影」卡时，
为了「首页少打几个请求」主动把海报砍成 34×34 的 🎬 色块。
网页端 _card_movies.php 一直是真海报，两端由此不一致。

改动（FamilyBook_harmonyos / 4e3038a，FbHomePage.ets）：

  1. 海报位改成 34×46（2:3），与网页端 .hc-mv-poster 同口径；
    Image(fbImageSrc(posterKey, token)) 先查本地附件缓存，命中时零请求；
  2. 加 @Local mvPosterFailIds + onError → 取不到退回 🎬+影院色色块，
    不留半张白图（@Local 数组必须整体换新值 concat 才刷新）；
  3. 不加 ?w= 压缩档位 —— media.php 只保留 1600 一档（#56），
    对 34×46 缩略图没意义，硬加只是白付一次 OSS 处理费。

验证（真机 5NC0225B27004718，1080×2444）

项 实测 结论
5 条左侧色数 4188 / 4708 / 5056 / 5104 / 5229 真照片（对照组纯色底 = 1）
海报高度 45.12 ~ 45.76 vp 目标 46vp ✓
海报宽度 34 vp ✓
行距 205~209px = 66vp 46+10+10 ✓
点击第 1 条 弹出大图 960×1374，宽高比 0.699 详情卡正常，海报 2:3 ✓
海报加载失败 0 次（mvPosterFailIds 全程空） 5 张全一次取到 ✓

网页端本来就有海报，线上库实测 8 条 poster_key 全在、
uploads/posters/ 187 个文件齐全 —— 未改动网页端。

顺带

同一屏「联系人」800 人、「往年的今天 · 11 年前 🎬 移动迷宫2」均正常，
整页数据链路是通的。

沉淀

pitfalls.md 第 23 条：「首页有占位符」不一定是加载失败，可能本来就只有占位符，
附四步判据（线上数据 → 文件存在 → 端上是否读取 → 端上渲染有没有用它）。

另：这轮验证踩到 uitest dumpLayout 返回陈旧布局的坑 ——
判断「界面显示了什么」必须以截图像素为准，dumpLayout 只适合看文字内容。

## 验收通过，关单 用户 2026-11-05：「首页最近观影没有图片呢，左侧都是占位符。」 ### 做了什么 **根因**：不是网页端的问题，是**鸿蒙端首页** v86 建「最近观影」卡时， 为了「首页少打几个请求」主动把海报砍成 34×34 的 🎬 色块。 网页端 `_card_movies.php` 一直是真海报，两端由此不一致。 **改动**（`FamilyBook_harmonyos` / `4e3038a`，`FbHomePage.ets`）： 1. 海报位改成 **34×46（2:3）**，与网页端 `.hc-mv-poster` 同口径； `Image(fbImageSrc(posterKey, token))` 先查本地附件缓存，**命中时零请求**； 2. 加 `@Local mvPosterFailIds` + `onError` → 取不到退回 🎬+影院色色块， 不留半张白图（`@Local` 数组必须整体换新值 `concat` 才刷新）； 3. **不加 `?w=` 压缩档位** —— `media.php` 只保留 1600 一档（#56）， 对 34×46 缩略图没意义，硬加只是白付一次 OSS 处理费。 ### 验证（真机 `5NC0225B27004718`，1080×2444） | 项 | 实测 | 结论 | |---|---|---| | 5 条左侧色数 | 4188 / 4708 / 5056 / 5104 / 5229 | 真照片（对照组纯色底 = 1） | | 海报高度 | 45.12 ~ 45.76 vp | 目标 46vp ✓ | | 海报宽度 | 34 vp | ✓ | | 行距 | 205~209px = 66vp | 46+10+10 ✓ | | 点击第 1 条 | 弹出大图 960×1374，宽高比 0.699 | 详情卡正常，海报 2:3 ✓ | | 海报加载失败 | 0 次（`mvPosterFailIds` 全程空） | 5 张全一次取到 ✓ | 网页端本来就有海报，线上库实测 8 条 `poster_key` 全在、 `uploads/posters/` 187 个文件齐全 —— 未改动网页端。 ### 顺带 同一屏「联系人」800 人、「往年的今天 · 11 年前 🎬 移动迷宫2」均正常， 整页数据链路是通的。 ### 沉淀 `pitfalls.md` 第 23 条：**「首页有占位符」不一定是加载失败，可能本来就只有占位符**， 附四步判据（线上数据 → 文件存在 → 端上是否读取 → **端上渲染有没有用它**）。 另：这轮验证踩到 `uitest dumpLayout` 返回陈旧布局的坑 —— 判断「界面显示了什么」必须以截图像素为准，dumpLayout 只适合看文字内容。
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
terminal/harmony
term-hm
 terminal/web
term-web
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
laoyang (老杨)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: laoyang/FamilyBook#63