laoyang/FamilyBook_harmonyos
1
0
Fork 0
Code Issues 2 Pull Requests Actions Packages Projects Releases Wiki Activity
93 Commits 1 Branch 0 Tags
d4b9d08b7e36cf5fc6e732a4bde662b302319111
Commit Graph
6 Commits
Author SHA1 Message Date
laoyang 86de59616c 端上：#47~#55 打包 —— 行程双轨、动态类型、表单全局规范 (#53) 
#48 计划/实际双轨：nodeAction(start/done/cancel)，完成即转实际行程，
    实际行程不再显示状态；新增 actualStartedAt/actualEndedAt
#49 类型/出行方式/车辆 chip 改内部读状态（@Builder 值传参不刷新）
#50 类型点击立即变色、出行方式平铺、参与人显示已选头像
#51 节点类型动态加载（原硬编码5种）、地址 onPick 拿详细地址与坐标
#52 标签改主题色 Bold、必填红无星号、编辑行程标题同步
#53 表单两排版式（标签独占一行解决左右对不齐）；电影弹层 layoutWeight 修滚动
#54 地址联想框加时间窗抑制（600ms 内不搜）、候选限高 180

含附件回填诊断日志（DIAG-ATTACH/FILL），待真机确认后移除
 2026-11-05 12:41:04 +08:00
laoyang 0397270e8b 日程改为本地库按需查询，修掉每次进页面解析 9.3MB 的架构错误 
## 用户指出的问题

「这个数据量很大，不是应该每次同步完了之后解包放在一个数据库里吗？
 然后点开日程，不就是把今天的日程从数据库里查出来吗？
 这个应该速度非常快才对呀！怎么能每次打开都要去读所有的数据呢？」

用户说得完全对。这是**架构错误**，上一轮我只做了算法层的局部优化
（把 O(n²) 改成 O(n)），没动"数据怎么存、怎么取"这个根本问题。

## 改前 vs 改后

改前：
    load() → module_cache 表读 **9.3MB 字符串**
           → JSON.parse **28628 个对象**
           → 全塞进 this.allEvents 内存数组
    渲染   → 在这 28628 条上遍历

`module_cache` 的设计注释本来写着「解析一遍毫秒级，可接受」——
那是按小数据量假设写的，日程涨到 2.8 万条后这个假设就破了。

改后：
    load() → ① `WHERE date BETWEEN ? AND ?`（走 idx_cal_date）→ 立刻渲染
             ② 后台拉全量 → 批量入库 → 重查当前范围
    渲染   → 只在**当前范围**那几十到几百条上遍历

## 改动

### FbSchema / FbDb：新增 cal_events 实体表

字段对齐 FbCalEvent（12 个）+ uid + fetched_at，三个索引：
- `idx_cal_date` —— 按日期查（最高频）
- `idx_cal_date_kind` —— 农历/节日按 kind 过滤
- `idx_cal_uid` —— 同步去重

⚠️ 主键不用服务端 `ref_id`：衍生条目（农历/节气/纪念日）的 ref_id **恒为 0**，
几万条全撞主键。用自增 rowid + (cal_id, uid) 唯一索引。
uid 由 kind|calId|evId|date|time|title哈希 组成。

⚠️ **建表语句与 migrate 两处都改了**，列名逐一比对一致
（这个坑本项目已踩 5 次，加了静态守卫钉住）。

### FbCalStore（新建）：本地库读写

- `replaceAll(rows, stamp)` —— 事务内先 DELETE 再分批写（20 行/批，照
  FbMovieRepo 的实测结论，200 行会卡死）。整批替换而非逐条 upsert，
  否则服务端已删的条目会永远留在本地。
- `between(from,to)` / `ofDay(iso)` —— 页面真正用的查询
- `lunarBetween` —— 月视图 42 个格子只要农历文字，单独查比取全量再过滤快
- `count()` / `fetchedAt()` —— 判空与"数据新不新"

⚠️ 命名用 `FbCalStore` 而不是 `FbCalRepo`：后者已存在，是**接口读写**层
（create/update/remove/fetchBooks）。我第一版误覆盖了它，编译报 8 处错误后
从 git 恢复，改名为 Store 区分「本地库」和「接口」。

### FbCalendarPage

- `allEvents` → **`rangeEvents`**（改名强制提醒：这里不再是全量）
- `rangeOfView()` —— 算当前视图需要的日期区间
- `loadFromLocal()` —— 先查本地，有数据立刻渲染
- `persistAndRefresh()` —— 入库完成后重查，界面跟上最新数据
- `reloadRange()` + `@Monitor('showYear','showMonth','mode')` —— 翻月/切视图按需重查
- `rangeSeq` —— 防抖，避免旧结果覆盖新结果

## 验证

### 编译
`build_hap debug` → BUILD SUCCESSFUL

### 静态校验（34 项全过）
`_tooling/check_cal_db.js`，含最关键的两项：
- 建表与迁移**列名逐一相同**（15 列全对上）
- `load()` 里本地查询确实在远程同步**之前**

### 未验证
**真机实测未做**（设备未连接）。需要确认：
- 老库升级（v7→v8）是否顺利建表
- 首次进入（库空）要等全量拉取，之后进入应该秒开
- 翻月是否立刻有数据

## 过程中的一个失误

第一版把新仓储命名为 `FbCalRepo`，**覆盖了已存在的同名文件**。
编译立刻报 8 处 "has no exported member / does not exist on type"。
从 git 恢复原文件后改名 `FbCalStore`，避免了两层职责混在一个类里。

教训：新建文件前先查同名是否存在（`git status` 没报是因为该文件本就在版控里，
我 `cp` 上去把它改成"已修改"状态，看着像正常改动）。
 2026-11-03 09:59:40 +08:00
laoyang 7858de27e3 v0.8.4 简要卡观感 / 分享 / 名册搜索 / 全局返回手势（v59e） 
八条需求的落地与真因：

1. 浮层与白底"糊在一起"、看不清 —— 根因不是配色，是**遮罩从来没画出来过**：
   ArkUI 的八位色值是 #AARRGGBB（alpha 在前），而全应用写的是 '#00000066'
   （本意"黑 40%"）⇒ alpha = 0x00 ⇒ 全透明。同型还有 brand + '1A'（拼到了蓝通道）
   与 shadow('#00000033')。⇒ 17 个文件统一改走 fbAlpha() / FB_MASK / FB_SHADOW /
   FB_HAIRLINE；真机像素采样复验：遮罩 (148,146,140)、卡片白、浅底 (237,242,243)。
2. 简要卡外圈加**主题色描边环**（外层铺色 + padding，不是 border —— border 会被
   内层圆角切出白缝）。
3. 简要卡**去掉删除按钮**，删除挪到完整详情卡最下面（Divider + 红字块）。
   顺手修一处静默失败：confirmDelete() 原来只取 quickSource()，
   从家谱直接开详情时 quickPerson 为 null ⇒ 点删除毫无反应。
4. 信息行间距 10 → 16（每行再各加 3vp 上下内边距，实测行距 134/118px）。
5. 主电话整行可点**直接拨号**（call.makeCall，落到系统拨号盘）。
6. 按钮改为 详情 / 编辑 / 分享 / 关闭；分享走系统分享面板，
   内容为纯文本「姓名 / 电话 / 邮箱」三项（用户点名的就是这三项，
   不多带单位），面板拉不起来时兜底复制到剪贴板并提示。
7. 名册搜索"完全不能用"有两个独立真因：
   ① 搜索框是 List 的第一个 item，无结果时整个 List 被空态替换 ⇒ 输入框被卸载、
      焦点丢失 ⇒ 输不进第二个字。改：List 无条件渲染，空态自身做成 ListItem。
   ② rowToPerson 把 initials 写死成空串，服务端下发的拼音首字母从未落库 ⇒
      拼音搜索恒 0 结果。改：FB_DB_VERSION 6→7 + PRAGMA 探测补列 + 同步时落库；
      匹配同时遍历全部电话（原来只比主号）。
   另加搜索框「清空」（24×24 命中区）。
8. 全局返回手势：应用是单页 + 模块分发、没有路由栈 ⇒ 自建 FB_BACK 登记表
   （倒序询问）+ moduleHistory + applyModule()（不记历史，否则 A/B 两页来回弹）。
   9 个页面登记/注销；Index.onBackPress 先关浮层 → 回上一模块 → 才 return false
   交给系统退桌面（onBackPress 必须声明 boolean，返回 void 会被当成没接管）。

验证：
- 静态守卫 417 / 0（新增 ⑤阴影·描边·色环 ⑥透明度色 ⑦返回手势 ⑧搜索 ⑨分享）
- 反向验证 10 / 0（9 条注入全部能让守卫变红；其中"遮罩换纯黑"那条暴露了
  一条存在型假绿，已改成数个数 + 禁止 Color.Black）
- 建表/迁移列一致性守卫 12 / 0
- 真机全模块遍历 14 / 14；真机逐项复核 12 / 0 与 7 / 0

工具侧顺带修好两个过期的探针：
- 遍历探针仍用"应用内横滑"打开抽屉，而该手势早已按用户要求去掉、入口改为顶栏图标
  ⇒ 一次全量遍历里 12 个模块全报"抽屉里没找到"（像应用坏了，其实是探针过期）。
- 资源/笔记两页写死了早已不存在的条目（户口本/房产证/阳台改造清单）⇒ 改成
  结构性文案（副标题 + 常驻筛选胶囊），不随用户数据变化而恒红。
 2026-10-18 23:12:57 +08:00
laoyang 77b494a274 修「名册永远是空的」：person_roster.phones 只在迁移里加过、没进建表语句 
用户 2026-10-18：「名册现在没有任何数据啊，看看咋回事。」

真机日志（唯一直接证据）：
  E .../Config: table person_roster has no column named phones
  (SQLite errno 2，名册整批 batchInsert 全部失败)

根因（两条安装路径的行为分叉）：
  `person_roster.phones` 当初**只加在 `FbDb.migrate()` 的 v3→v4 ALTER 里**，
  **没进 `FbSchema.FB_SCHEMA_SQL` 的建表语句**。于是：
    · 老库升级 → 走 migrate() → 执行 ALTER → 有 phones ✅
    · 全新安装 → store.version 一上来就等于 FB_DB_VERSION(5)
                 ⇒ migrate() 首行 `from >= FB_DB_VERSION` 直接 return
                 ⇒ 那句 ALTER **永远不执行** → 没有 phones ❌
  用户这次是**卸载重装**（前端流程要求），正好走的是坏的那条路。

为什么藏了这么久（两个"静默"叠加）：
  ① `pageHeaderItem` 的空状态文案是「登录后会从服务器拉取你名册里的人」——
     一个**已经登录**的人被提示去登录，完全猜不到真实原因；
  ② `syncInBackground()` 里 `repo.sync()` 的**异常没人接**：
     异常从 async 函数冒出去，`bootstrap()` 之后没有任何 catch
     ⇒ 整个后台同步静默死掉，`syncNote` 还是 ''（看着像"同步成功"）。

三处修复：
  ① `FB_SCHEMA_SQL` 的 person_roster 补上 `phones`（新装用户直接对）；
  ② `FB_DB_VERSION` 5→6 + 新增"结构自愈"迁移：**主动探测列是否存在**
     （`PRAGMA table_info`，不靠异常控制流 —— 否则会把库损坏之类的真原因
      一起吞成"大概已经加过了"），缺则补 `ALTER`。这一条是给**已经装坏的库**
     （version=5 但缺列）用的：它们的版本号已经到位，不会再进任何 `from < N`
     分支，只能靠新版本号再捞一次。
  ③ `syncInBackground()` 包 try/catch，把异常落成**用户看得见的文案**
     （「名册写入本地库失败：<原因>」）。纪律：后台任务的异常必须就地
     变成一句话，不能指望"调用方会 catch"——调用方往往是 fire-and-forget。

真机验证（两条路径都跑了）：
  · 旧库自愈：`本地库迁移：v5 → v6` → `v6 迁移完成：补上 person_roster.phones`
    → `[5] 本地库就绪，版本=6`；随后名册页**数据全出来了**
    （标签云 全部/大学同学 55/同事 40/实验室 23/合作伙伴/爸爸/家人；
      人员 爸爸/妈妈/岳父/岳母/杨永全 等），缺列报错 0 条。
  · 全新安装（清数据重来）：`version=0` → 首装建表 22 条 → 直接 v6，
    迁移无事可做（正确：建表已含全部列）。

新增守卫（防这类"新装 vs 升级分叉"复发）：
  `_fb_guard_schema_columns.js`（11 条）静态解析 `FB_SCHEMA_SQL` 的建表列
  与 `migrate()` 的全部 `ALTER ... ADD COLUMN`，断言**每个 ALTER 加过的列
  都必须在建表语句里**；另钉住 v6 存在性探测、版本号、后台同步 try/catch。
  `_fb_schema_falsify.py` 6 项注入 ⇒ 6/0（每项都成功打红对应断言）。
  已挂进流水线（run_guarded_suite 全量 b59b）。

顺带修 `_fb_v57_falsify.py` 的一处**过时注入锚点**：它注入的是
`allowSkip: this.app.lockReason === ''`，而该参数已按用户要求整个删除
⇒ 改成反方向注入「把 onSkip 后门加回来必须被抓」（12/0 通过）。

验证：hvigor BUILD SUCCESSFUL；_fb_arkts_guard.js 328/0；b57 12/0；新守卫 11/0。
 2026-10-18 20:40:30 +08:00
laoyang 2132ee42d2 v0.8.0 本地加密 / 被踢清数据 / 增量同步 / 附件队列 / 顶栏同步进度 
用户 2026-10-18 两条：
「直接做 L3 锁界面 + 本地加密（HUKS，踢设备即吊销密钥）：数据在但读不出，
  重登后恢复密钥即可用。」
「右上角头像和提醒前面加同步进度…首次全量、之后增量；进来先展示本地数据，
  一边同步一边更新；附件后台队列同步（名册头像 / 电影海报 / 观影照片 / 资源附件）。」

① 整库加密（FbSchema v4→v5，新增 module_sync / attach_cache 两张表）
   RDB encrypt=true。加密属性一经创建不可修改 ⇒ openWithEncryption 三段式：
   直接开 → 失败删库重建 → 再失败降级明文（degraded 字段，设置页如实显示，
   不静默降级）。

② 两层密钥（FbKeyStore）
   HUKS 里 KEK（fb_kek_v1，不可导出）包裹 32 字节 DEK；revoke() 删 KEK
   ⇒ 已落盘附件密文在数学上解不开，这就是"踢设备即吊销密钥"。
   重新登录重新生成 DEK 并重下附件（不做服务端托管，为了省一次重下
   把能解你本地数据的密钥放到服务端不值）。
   会话属性里 PURPOSE 只出现一次：原来把含 ENCRYPT|DECRYPT 的生成属性直接
   拿去开会话再 push 一个 PURPOSE，同一 tag 出现两次在 HUKS 里行为未定义
   ⇒ 拆成 kekBaseProps / kekGenProps / kekSessionProps。

③ AES-256-GCM（FbCrypto）
   落盘 iv(12)|ct|tag(16)；变换串必须带 padding 段（AES256|GCM|PKCS7，
   缺了抛 801）；解密从尾部切 tag。

④ 附件后台队列（FbAttachQueue）
   attach_cache 台账（pending/done/fail，MAX_TRIES=3）；密文放 filesDir、
   明文临时放 cacheDir；扩展名白名单筛 key。
   图片地址收成统一入口 fbImageSrc(key,token)：本地有就用 file://，
   没有才回网络 —— 收成一个函数才漏不掉（5 个页面全部改过来）。

⑤ 被踢 / 退出清数据
   lockOut → 清令牌 → FB_ATTACH.wipe（第一步就是吊销 KEK）→ FbDb.wipe
   （先关句柄再 deleteRdbStore，并发去重，open 会等它）→ 同步状态复位。
   重新登录后重建密钥 + 库 + 附件索引，否则之后只读网络不写缓存且不报错。

⑥ 增量同步（FbSyncAll 重写）
   先问 /api/v1/changes；指纹相同就跳过。本地没水位必须拉（否则老用户升级后
   一个模块都不同步）；24h 陈旧上限兜"改无 updated_at 表的已有行"；
   /changes 拿不到时判 ping status>0 —— 断网直接收工，不退回全量
   （否则 12 个模块各等 15 秒）。
   家谱也进了预同步列表（原来只在打开时拉，离线是一片空白）；
   总步数由 CACHE_MODULES.length 算出，不写死。

⑦ 删除传播
   服务端是物理删除、没有墓碑 ⇒ 观影同步改成"先清后插"
   （persons 跨模块共用，不清）。

⑧ 顶栏同步进度
   头像与铃铛之间加三态按钮（转圈 / 红感叹号 / 灰对勾）+ bindSheet 面板：
   进度条、「N 个模块没有变化」、附件行、失败清单、立即同步（防连点）。
   状态中心 FbSyncState（@ObservedV2 + @Trace，AppStorageV2 单例）；
   界面直接读 @Trace 字段，不提供派生 getter。

验证：hvigor BUILD SUCCESSFUL；_fb_arkts_guard.js 290/0（本批新增 59 条）；
_fb_v58_falsify.py 31 项注入 38/0；b57 反向验证 12/0（锚点跟上本批 logout 改动）；
本地 e2e 1519/0；全量流水线 PUSH_RC=0。
 2026-10-18 16:01:41 +08:00
laoyang 776c95ba0b v0.7.0 接上真实服务器：登录 / 设备会话 / 全量同步与各模块真实数据 
从「演示数据壳子」走到「真的能连家里的服务器用」。

登录（用户 2026-10-17「完整的登录功能」）
  · 首次启动先填服务器地址 → /api/v1/ping 自报门户（认得出"这地址上真是家书"）
  · 手机号或用户名 + 密码 → 拿令牌；失败提示统一，不泄露账号是否存在
  · FbDeviceStore：首次启动生成并持久化设备 UUID（三方应用拿不到 UDID），
    设备名取机型（marketName），并上报 platform / app_version

设备会话（v57，用户 2026-10-17）
  · 一把令牌 = 一台设备的一条会话；每次启动打一次 /me（有网就验）
  · 两种锁分开：need_login（401/被踢 → 清令牌）与 offline_expired
    （离线超 24h → 只锁界面、不清数据、联网自动恢复）——
    混成一种就会违背用户要的"一直联网就不用每天输密码"
  · 运行期任何请求 401 → 网络层全局回调立刻锁定跳登录页（FbHttp 的 authProbe
    让登录/校验类请求跳过，避免"两个地方同时跳登录页"）
  · 退出登录：先清本地令牌（主防线），再尽力通知服务端
  · 设置页显示版本号与「这台设备」

数据层
  · FbDb / FbSchema / FbParse / 各 Repo（日程 / 名册 / 观影 / 模块）+ FbSyncAll
  · 首页改为服务端 /home（农历/节气/纪念日/生日/天气/统计/往年的今天）
  · 日程页用 FbDayEventPanel，与网页端显示方式/红线/并排三处一致

验证：ArkTS 静态守卫 231/0；hvigor 编译 BUILD SUCCESSFUL（entry-default-signed.hap）。
 2026-10-18 03:36:04 +08:00