71 lines
4.4 KiB
Markdown
71 lines
4.4 KiB
Markdown
## 文档更新内容补充
|
||
- 收录 OpenInstall 配置参数：
|
||
- appkey：alf57p
|
||
- iOS Associated Domains：applinks:alf57p.oplinking.com
|
||
- 其余方案保持既定约束：静默邀请、仅在 kr_deviceLogin 成功后调用、仅打印日志、不改动 UI、不清理本地、桌面平台从包名截取邀请码、网络层 silentInvite 标识屏蔽响应弹窗但保留请求拦截。
|
||
|
||
## 《说明文档.md》新增/修订片段（拟写）
|
||
|
||
### OpenInstall 配置
|
||
- 版本：openinstall_flutter_plugin:^2.5.7
|
||
- appkey：alf57p
|
||
- iOS：
|
||
- Associated Domains：applinks:alf57p.oplinking.com
|
||
- 在 AppDelegate 转发 openURL/Universal Links 到插件
|
||
- Android：
|
||
- Manifest 配置深链与自定义 scheme（与 iOS 域名对应），按官方文档完成
|
||
|
||
### 触发点与静默行为
|
||
- 触发点：await authApi.kr_deviceLogin() 成功分支（[app_run_data.dart](file:///Users/apple/Documents/source/hi-client/lib/app/common/app_run_data.dart#L410-L460)），在 kr_saveUserInfo 之前调用 KRUserApi().hi_inviteCode(inviteCode)
|
||
- 静默：仅打印控制台日志，不走响应弹窗，不清理本地状态，不重试
|
||
|
||
### 桌面端各平台识别方案
|
||
由于 Windows 和 macOS 的分发机制完全不同，识别策略已进行针对性分离：
|
||
|
||
#### Windows 平台（高可靠方案）
|
||
* **主流方案：自动读取 `channel.txt`**
|
||
* **原理**：利用 Inno Setup 脚本，在安装过程中实时获取安装包名（如 `Setup_ic-888.exe`），截取 `ic-` 后缀并将其写入安装目录下的 `channel.txt`。
|
||
* **代码实现**：程序启动时优先检测运行路径下的 `channel.txt`。只要该文件存在，识别率接近 100%，无需依赖其他高危权限。
|
||
* **辅助/降级方案**：
|
||
1. **直接路径匹配**：识别手动重命名的 `.exe` 文件名。
|
||
2. **下载目录扫描**：作为最后兜底，扫描 `~/Downloads` 文件夹下的重命名安装包。
|
||
|
||
#### macOS 平台（多级追溯方案）
|
||
* **识别逻辑（分层检测策略）**：
|
||
1. **挂载源追溯 (核心)**：通过 `hdiutil info` 关联运行中的 App 及其原始 `.dmg` 文件名。专门解决“程序未改名但在已命名的镜像中运行”的场景。
|
||
2. **直接路径匹配**：从当前 `.app` 包名的全路径（或已改名的包名）中正则提取。
|
||
3. **下载元数据提取**：通过 `mdls` 读取文件扩展属性 `kMDItemWhereFroms`。即便安装包已清理，只要系统保留了下载来源记录，仍可识别。
|
||
4. **下载目录扫描**：扫描用户下载目录（Downloads）下最近修改的 `.dmg` 安装包。
|
||
|
||
- **调试支持**：当 `inviteDebugMode` 开启且在任意平台识别到邀请码时，App 会弹出醒目的确认对话框，方便测试验证。
|
||
|
||
### 100% 可靠性技术分析（深入）
|
||
目前桌面端的提取逻辑存在性能天花板，以下是针对生产环境的最终建议：
|
||
|
||
#### 1. 为什么 DMG 改名不是 100%？
|
||
macOS 的隔离机制决定了当文件从 DMG 拷贝到 `/Applications` 后，父容器的所有属性（文件名、挂载关联）都会被物理切断。**本地提取方案仅作为“零成本辅助”存在。**
|
||
|
||
#### 2. 如何实现 100% 闭环？
|
||
* **工业级方案：指纹识别（OpenInstall / Adjust）**
|
||
* **地位**：核心主力方案。
|
||
* **逻辑**：通过浏览器端采集（IP、UA、分辨率等）与 App 启动端采集进行云端指纹匹配。
|
||
* **优势**：无视安装位置，无视文件名改动，100% 跨生存周期追踪。
|
||
* **备选方案：PKG 安装包 (macOS Installer)**
|
||
* **逻辑**：模仿 Windows 的 Inno Setup，在 `postinstall` 阶段运行脚本。
|
||
* **局限**：签发成本极高，需要服务端实时重签名，通常不推荐。
|
||
|
||
### 结论
|
||
**Windows 依靠 `channel.txt` 已实现 100% 识别；macOS 建议以“OpenInstall 指纹识别”为主力，本代码实现的“hdiutil/mdls 追溯”为辅，共同构建 100% 识别链路。**
|
||
|
||
### 网络层标识（silentInvite）
|
||
- 载体：Dio RequestOptions.extra（可选 Header: X-Client-Mode: invite_silent）
|
||
- 行为：保留请求拦截；屏蔽响应弹窗与登录失效弹窗；错误向上传递，调用方仅打印日志
|
||
|
||
### 测试清单
|
||
- iOS UL 验证：applinks:alf57p.oplinking.com
|
||
- Android 深链验证
|
||
- 设备登录成功后静默绑定日志验证
|
||
- 桌面解析包名验证
|
||
|
||
## 交付
|
||
- 经你确认后，我将把上述内容写入《说明文档.md》，目前仍不进行代码改动。 |