fix: 更新文档
This commit is contained in:
parent
6da7649720
commit
2eaa19190b
46
邀请文档.md
46
邀请文档.md
@ -19,15 +19,43 @@
|
||||
- 触发点: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)
|
||||
- **识别规范**:文件名或路径中包含 `ic-<code>`,例如 `HiFastVPN-ic-888.dmg`。
|
||||
- **解析逻辑(分层检测策略)**:
|
||||
1. **直接路径匹配 (Win/Mac 通用)**:从当前运行的 `.exe` 或 `.app` 全路径中正则提取。这是最直接、最高效的手段。
|
||||
2. **安装渠道配置文件 (Windows 独有)**:读取程序安装目录下的 `channel.txt`。支持 Inno Setup 在安装时通过 `{srcexe}` 获取安装包名并自动生成该文件。这为 Windows 提供了最稳定的安装后识别方案。
|
||||
3. **挂载源追溯 (macOS 独有)**:通过 `hdiutil info` 关联运行中的 App 及其原始 `.dmg` 文件名。专门解决“程序未改名但在已命名的镜像中运行”的场景。
|
||||
4. **下载元数据提取 (macOS 独有)**:通过 `mdls` 读取文件扩展属性。即便安装包已清理,只要系统保留了下载来源记录,仍可识别。
|
||||
5. **下载目录智能扫描 (Win/Mac 通用)**:作为最后兜底,扫描用户下载目录(Downloads)下最近修改的、符合命名规范的镜像或安装包(`.dmg`/`.exe`)。这一策略能有效解决用户下载后虽然安装程序没改名,但原始安装包依然留在下载文件夹中的场景。
|
||||
- **调试支持**:当 `inviteDebugMode` 开启且识别到邀请码时,桌面端会弹出确认对话框。
|
||||
### 桌面端各平台识别方案
|
||||
由于 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)
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user