つぎへ、一緒に
次も、また、鼓動の芽吹く場所へ
次も、また、花火の響く夜へ
ときめきは、ゆっくり積もっていく。
心之所往
下一次，再次，走去心跳生长的地方
下一次，再次，听着花火打响的夜晚
期待，会慢慢堆积。
打开 App，不需要登录，不需要配置，不需要学习复杂操作。 Tsugie 会在当下这个时刻，给出最值得去的下一站。
- 以“当前时间 + 当前地点”为输入，直接给出下一站值得去的
へ。 - 首屏全屏地图直达决策链路，无登录门槛、无学习成本。
- 地图点位 -> quickCard -> 详情页，一步步把“想去”变成“立刻出发”。
- AI 推荐同时建模空间距离、时间状态、活动热度，实时重排候选集合。
- AI 热度与惊喜度贯穿卡片和详情表达，让“为什么推荐它”可感知、可解释。
- 对
unknown / ended / 长等待活动执行严格门禁与降权，推荐池持续保持可行动质量。
- 地图页负责“此刻在哪儿去”，日历页「時めぐり」负责“接下来哪天去”。
- 两条视角共享统一时间状态模型：
upcoming / ongoing / ended / unknown。 - 地图、轮播、详情、日历保持同源判断，用户在任何入口都能得到一致结论。
- 收藏语义固定为“想访问”，打卡语义固定为“已访问”，全场景统一 logo 表达。
- 装饰、图章、状态反馈形成可积累体验，每一次互动都会留下可见痕迹。
- 未到开始时间禁止打卡，顶部中间提示气泡即时反馈，规则清晰且有仪式感。
- 支持 Apple 地图与 Google 地图双通道导航，点击即走。
- 导航起点与定位策略同源：日本境内且授权通过使用真实定位，否则使用东京天空树默认点。
- 本地通知支持开始前提醒，帮助用户把“想去”转成“到场”。
- 密集点位下仍保持点位、气泡、装饰、按钮可点击、可预期。
- 多语言体验完整覆盖
ja / zh-Hans / en，文案语气统一。 - 动效节奏与交互反馈持续优化，保持连贯、顺滑、低打断的地图体验。
Tsugie 将“地图推荐”实现为完整算法链路，贯穿数据、检索、排序与展示。
- 全量活动数据先做统一清洗与语义对齐，再进入空间索引阶段。
- 采用 Geohash 前缀做空间哈希分桶（Hash Partition），将全国数据切成可随机访问的小块。
- 每个桶独立编码，最终写入二进制 payload；索引文件仅保存：
bucket -> offset/length- 校验信息
- 编解码协议元数据
- 运行时按
offset/length直接跳读命中桶，避免全量扫描。 - 这本质上是“空间索引 + 文件级随机访问”，目标是把 I/O 从全量线性读取降到命中桶读取。
- 坐标链路采用多阶段可靠性治理：
- 主来源坐标直用
- 低置信度项走联网 geocode（含缓存）
- 极端缺失再走兜底策略并标记来源
- 对“同坐标堆叠脏数据”做二次修复：
- 以经纬度 6 位小数聚类（哈希聚类）
- 对低置信度重叠组逐条重查
- 命中新坐标且与旧值不同才覆盖写回
- 导出前设质量门禁：高风险重叠组超过阈值直接阻断发包。
- 目标是将“错误坐标可视化污染”前置消灭在数据端，客户端保持稳定消费链路。
- 用户位置先编码为中心 Geohash，再基于网格边界计算检索步长。
- 检索采用 Ring Expansion（扩圈）策略：
R -> 2R -> 4R，逐级放大，不命中不做无谓解码。 - 每轮只读取命中桶分片，解码后进入候选池，再做分层筛选：
- 高精度坐标优先
- 低置信度坐标降权
- 过期活动粗排剔除
- 最终做 Top-K 输出，保证首屏和轮播在高负载下仍稳定出结果。
- 空间命中：
O(B_hit)（命中桶数） - 候选排序：
O(M log M)（候选量 M） - 随机读取：
O(1)索引寻址 + 顺序解码命中分片 - 工程目标：把“全国数据问题”转成“附近小集合问题”
- Tsugie 将时间状态按区间问题处理：
ongoingupcoming(<3h / <12h / <24h / >24h)endedunknown
- 这是一种 Segment-Tree 风格的区间命中思维：先命中时间段，再套对应评分与门禁规则。
- 好处是规则可扩展、可解释、可稳定迭代，不会因为“补一个 if”把排序搞乱。
Tsugie 将 AI 推荐与 AI 热度推算整合为统一决策内核，确保“可去性”和“吸引力”同时被计算。
- 推荐内核采用多目标信号融合：空间可达性、时间可行动性、动态热度、动态惊喜、近场增益与临场窗口增益并行建模。
- 排序核使用分层融合器与置信度惩罚链路，将弱置信、低时效候选稳定压制在后排。
- 空间衰减负责“去哪更顺路”，时间门控负责“什么时候更值得”，热度与惊喜负责“为什么此刻更想去”。
- 粗排阶段先剔除
ended，避免过期活动进入推荐池。 - 精排阶段把
unknown明确压到最后层级，确保“时刻已知”候选优先曝光。 upcoming采用<3h / <12h / <24h阶梯窗口，>24h进入连续衰减，避免远期开场误占前排。ongoing + near通过专用增益项强优先，确保“正在进行且离你近”的活动稳定进入前列。
- 类别先验采用可配置策略矩阵，在同分与近同分区间参与最终裁决。
- 同分处理加入稳定化规则，避免轮播首位因微小扰动频繁抖动。
- 类别先验与时间门禁协同执行，保证低时效候选无法绕过时机约束。
- 动态热度具备完整时段行为：开场前预热、进行中抬升、结束后冷却。
- 动态惊喜在进行中与临近开场区间获得额外增益，并与距离信号耦合。
- 热度与惊喜度共同驱动推荐与详情表达，确保排序结论与氛围反馈一致。
- 每个推荐结果都可由“距离、时间状态、动态热度、动态惊喜、近场增益”解释。
- 排序核与卡片展示层共享同源信号，避免“排第一但解释不通”的断裂体验。
- 推荐输出稳定遵循同一规则，不因入口差异而改变决策口径。
Tsugie 将收藏、打卡、图章、装饰统一为单一状态体系，让“操作结果”在全场景可见且一致。
- 收藏语义固定为“想访问”，打卡语义固定为“已访问”。
- 打卡自动联动收藏，避免用户出现“已到场但不在收藏”的语义冲突。
- 地图、卡片、抽屉、详情共享同一语义层，状态表达不漂移。
- 交互初期采用瞬态图章提供即时反馈，降低点击后的空窗感。
- 当用户形成收藏或打卡行为后，图章进入稳定锁定阶段。
- 这套机制兼顾“轻反馈速度”与“长期记忆沉淀”。
- 装饰层优先跟随当前焦点点位，突出当前决策对象。
- 非焦点装饰被主动收敛，减少密集地图上的干扰和误触。
- 在重叠点位场景中，装饰不会破坏主交互层级。
upcoming活动不允许打卡，规则在全入口一致执行。- 拦截后触发顶部中间提示气泡，反馈即时且可感知。
- 提示自动销毁，避免常驻遮挡和二次干扰。
- 状态更新采用幂等策略，重复触发不会造成回退。
- 清理与重建后状态可恢复，减少“重进后变样”的不确定感。
- 结果是：用户的每一次互动都能被稳定记住并持续可见。
Tsugie 把资源治理做成常态化机制，目标不是“短时能跑”，而是“长时稳定运行”。
- 定期回收周期：
180s。 - 内存看门狗巡检：
8s。 - 相机变化触发：跨距
180km或累计14次显著移动。 - 多触发并行存在，保证不同负载场景都能及时收敛。
- 高压阈值：
380MB，进入主动回收路径。 - 紧急阈值：
460MB，先裁剪渲染集合，再执行实例重建。 - 分级处置避免“一刀切”重建带来的体验跳变。
- 回收时同步清理查询签名、缓存快照、异步任务和临时状态。
- 地图实例重建与推荐上下文解耦，避免回收过程污染当前视野推荐。
- 通过统一清理顺序阻断旧状态残留导致的幽灵行为。
- 入场建立必要观察链路与调度任务。
- 离场统一终止任务与观察者，杜绝悬挂引用。
- 详情重资源在离场时显式释放，防止反复进入导致内存台阶上升。
- 在连续拖动、连续选点、频繁进出详情的组合压力下保持响应。
- 资源回收不破坏交互上下文，不出现“回收后推荐口径跳变”。
- 最终效果是：会话越长，体验曲线仍保持稳定。
Tsugie 在详情页采用“粉末渲染”管线，把重渲染拆成可控节奏。
- 首阶段只输出标题与关键状态，先保证“信息可读”。
- 媒体阶段延后展开，避免首帧被图像解码阻塞。
- 完整阶段再补齐长内容，保证结构稳定后再填细节。
- Hero 图、氛围区、延迟模块都提供对应骨架块。
- 骨架采用统一节奏过渡，降低白屏感与闪断感。
- 用户在等待资源期间始终有可理解的页面骨架。
- 插图与活动主图均采用异步加载，避免主线程长阻塞。
- 插图下采样上限
420，主图下采样上限1280，兼顾清晰度与内存占用。 - 可见性优先加载，让首屏视觉先完整再逐步精修。
- 详情离场时主动释放位图引用，避免隐性堆积。
- 重新进入时按需重建，不携带旧图缓存污染新页面。
- 该策略显著降低“多次开关详情后”内存累加。
- 首次进入时延下降，用户先读信息再等细节。
- 分阶段填充减少一次性大渲染引发的掉帧。
- 在复杂详情内容下仍保持可控的交互连续性。
Tsugie 对“拖动 -> 重排 -> 点选”链路建立了完整抗抖控制。
- 连续相机事件只做轻量心跳，不直接触发重计算。
- 只有稳定事件点才进入重算链路，避免逐帧重排。
- 这让地图拖动保持流畅，后台计算保持克制。
- 位移阈值：
0.12km。 - 缩放阈值：
1.05。 - 默认去抖窗口：
220ms。 - 三重条件共同抑制“微抖动 -> 大重排”的放大效应。
- 程序化相机变化进入抑制窗口，不参与手势重排判定。
- 定位重置、卡片聚焦、地图重建等动作不会意外触发推荐翻页。
- 用户手势与系统动作边界清晰，行为可预期。
- 当新视口仍落在已加载包络内，仅执行轻量裁剪。
- 避免完整 reload 带来的闪烁与序列抖动。
- 这一步显著提升拖动中的视觉稳定性。
- 采用聚类锚点与分层命中，优先保障动作按钮可点性。
- 对重叠点位支持强制展开，降低误取消概率。
- 气泡、装饰、按钮在紧邻场景下仍保持可点击、可预期。
Tsugie 采用“双轨数据平面”：离线内置能力保证启动速度，实时检索能力保证视野准确。
- 首屏可直接读取内置数据包，避免网络冷启动等待。
- 进入即有可计算候选，不依赖远端接口先返回。
- 在弱网场景下仍能保持决策链路完整。
- 视口变化后按扩展区域动态估算查询半径与查询上限。
- 仅加载附近分片并增量替换渲染集合，不做全量粗暴加载。
- 该策略把 I/O、CPU 与内存峰值控制在可预测区间。
- 全量缓存可用时走内存路径，优先稳定时延。
- 全量缓存尚未就绪时走分片附近检索，保证响应连续。
- 两条路径共享同一排序口径，避免入口切换导致结果突变。
- 推荐候选集合与地图渲染集合独立维护。
- 地图重建或内存回收后，推荐仍可基于当前视野重建。
- 这避免了“回收后又回到定位点推荐”的语义回跳。
- 在弱网、抖动网、间歇网环境下持续提供附近建议与导航入口。
- 视口移动后的推荐刷新保持可预期，不被网络状态反复打断。
- 速度与稳定性不是二选一，而是同一套数据平面下的并行目标。
Tsugie 将“开抽屉卡顿”与“日历打开慢”作为独立性能课题治理，建立了预热优先的交互路径。
- 启动阶段同步预热收藏抽屉快照与日历缓存，减少首次展开时的临场计算。
- 预热任务与地图初始化并行执行，避免把压力集中到单次点击时刻。
- 目标是让“首开侧栏/首开日历”从计算触发点变成缓存命中点。
- 日历详情数据按
dayKey预分组并预排序，打开侧栏直接读取结果。 - 详情抽屉关闭后保留缓存，不在每次开关中重复重建。
- 在性能优先策略下允许轻微实时性牺牲，换取稳定帧率与响应速度。
- 日历月视图采用月块池预构建，提前准备前后月份结构。
- 翻页时优先复用池内月块，仅在缺块时增量补齐。
- 该策略显著降低“翻月瞬时创建大量格子”造成的掉帧风险。
- 收藏筛选、计数与分类统计进入快照缓存，按状态修订号增量失效。
- 收藏/打卡变更只触发局部快照更新，不做全量重算。
- 结果是侧栏打开动作从“计算驱动”切换为“读取驱动”。
- 主页侧栏与收藏抽屉采用统一动画调度，避免开关速度突变和闪烁。
- 抽屉插入/移除使用显式过渡，减少层级切换时的视觉跳变。
- 保持动效一致性的同时降低主线程瞬时负担，提升整体交互顺滑度。
一个真正以“下一步决策”为核心的地图产品。
Tsugie 从定位、推荐、交互、渲染到资源治理，形成完整系统能力。
- 隐私政策与提审口径（本地文档）：
记录/tsugie-隐私政策与提审口径-v1.md - 提审预检清单：
ios开发/tsugie/tsugie/APP_STORE_PRECHECK.md - 隐私声明页面（线上）：
https://www.shyr0.com/idea/tsugie/privacy