适用情况
- 个人开发者需要为少量正式版本保留加固额度
- 小型团队有固定迭代节奏和多个候选包验证需求
- 企业团队需要把多个应用或流水线纳入统一额度规划
- 购买前希望看到无需登录即可抓取和核对的公开价格
公开套餐 · SNAPSHOT V1
APK 加固套餐与价格
套餐按加固额度计费，不要求订阅。公开快照展示当前基础版、专业版和企业版的价格、额度与适用人群，让团队在注册和上传前就能估算发布频率与验证成本。购买前仍应先用候选 APK 完成签名、安装和关键功能验证。
上传 APK 开始验证更新于 2026年8月18日
不适用情况
- 希望购买后自动完成签名、应用商店审核或设备兼容保证
- 尚未确认 APK 能安装、升级和运行关键业务流程
- 需要隐藏真实恶意行为或绕过安全审核
01 / 计费模型
额度对应加固任务，余额与套餐分开管理
每次提交加固任务会消耗相应额度。公开套餐快照提供用于决策的价格和数量，登录后的充值中心负责实际购买、账户余额和交易记录。套餐名称、价格或额度发生实质变化时，应显式更新快照和页面更新时间。
按量方式适合围绕发布候选安排成本，但一个版本可能需要不止一次任务：最小策略验证、配置调整和最终候选都应作为独立产物记录。不要用覆盖旧产物的方式节省记录。
02 / 用量估算
把额度与真实发布流程绑定
先统计每月正式版本数量，再乘以每个版本计划验证的候选数。若有多个 ABI、渠道包或独立应用，应分别计算。预留用于依赖升级、签名迁移和紧急修复的验证额度，但不要为了消耗额度启用无必要的保护。
个人项目可以从较小额度开始，确认产物签名与设备回归流程。团队应指定谁创建任务、保存配置、签署结果和批准发布。企业场景还要按应用和发布线记录额度归属，避免只有交易记录而没有技术证据。
- 01统计每月应用与正式发布次数
- 02估算每次发布的候选包和回滚验证数量
- 03加入依赖升级与紧急修复预留
- 04确认配置、签名、测试和批准责任
- 05按实际消耗复盘下一个周期套餐
03 / 选择依据
价格之外还要看验证成熟度
下面的建议是容量规划，不是功能或效果承诺。所有套餐使用同一发布验证原则。
| 团队状态 | 优先考虑 | 购买前门禁 |
|---|---|---|
| 个人开发者、少量发布 | 基础版的较小额度 | 完成一次端到端候选验证 |
| 小团队、固定迭代 | 专业版的周期容量 | 明确产物归档和签名责任 |
| 多应用或企业流水线 | 企业版的集中额度 | 建立应用级消耗与发布审计 |
| 流程仍不稳定 | 先验证，不急于扩大额度 | 解决安装、升级和关键功能问题 |
04 / 快照治理
公开价格必须在接口异常时仍可读取
本页和首页使用版本化公开套餐快照预渲染，不依赖浏览器连接套餐数据库。因此登录、Supabase 或充值接口暂时不可用时，搜索引擎和访问者仍能读取价格、额度和适用人群。
快照不是支付确认。实际下单前，充值中心会加载可购买配置；若登录后的配置与公开快照不一致，应暂停购买并联系支持。任何更新都应同时修改快照版本、更新时间和 sitemap 的 lastmod，而不是每天机械刷新。
05 / 购买边界
套餐购买不等于发布结果保证
加固会改变 APK，产物为未签名交付。应用所有者必须使用自己的签名材料，并在目标设备和渠道验证安装、升级、启动、登录、网络、支付、推送、后台任务和 Native 功能。
检测规则、系统版本、第三方 SDK 和应用代码会变化。套餐只提供使用额度，不承诺所有未来版本、设备、商店或安全产品保持相同结果。先完成小范围验证，再把稳定流程扩展到更多发布。
常见问题
先确认边界，再采取动作
套餐是否需要订阅？
不需要。当前公开模式为按额度购买，实际可购买配置和账户余额在登录后的充值中心确认。
一个额度能做什么？
额度用于创建一次加固任务。签名、真实设备测试、应用商店提交和误报申诉仍由发布团队完成。
为什么公开页直接显示价格？
静态快照让访问者和搜索引擎在套餐接口异常时仍能获得决策信息，也减少注册前的不确定性。
公开价格和充值中心不一致怎么办？
不要继续支付。以实际下单界面为交易确认，并通过 Telegram 联系支持核对快照更新时间。
应该一次购买多少额度？
按应用数量、发布频率、每版候选次数和应急预留估算。流程未验证前，先完成一次端到端测试。
下一步
先用候选 APK 验证流程
上传 APK、选择最小策略并完成自己的签名与设备回归，再按真实发布频率选择额度。