WorkMigration/智能鞋/1、固件与硬件.md

推送升级的逻辑

1. 正式升级推送版本的具体逻辑

   从最高版本 [往低] 开始扫描，一旦客户端的硬件版本和APP版本 [符合] 要求的最高/最低版本，则 [立即匹配] 推送此固件，而其他符合最高/最低条件的低版本不会被推送。

   例如：

   • 客户端的硬件版本是1.1.1, APP版本是1.4.0;
   • 某固件A（V2.2.6, 硬版要求2.2.0~2.2.65535, APP要求1.0.0~2.0.0）;
   • 某固件B（V1.1.2, 硬版要求1.1.0~1.1.65535, APP要求1.0.0~2.0.0）;
   • 某固件C（V1.1.1, 硬版要求1.1.0~1.1.65535, APP要求1.0.0~2.0.0）;

   其中，客户端的情况符合B/C的要求，但B固件版本大于C，故优先匹配并推送B.

2. 灰度升级推送版本的具体逻辑

   在正式升级逻辑的基础上，仅开放给前N名用户（N采用有效使用人数来计数，下载失败或没有使用的不算）.

3. 内测升级推送版本的具体逻辑

   在正式升级逻辑的基础上，只有被指定的内测人员可收到推送.

---

固件状态的转换

---

版本号解释

硬件版本格式

(0~255).(0~255).(0~65535)

• 第一位指硬件颠覆级别的改造，或者在重构时所用；
• 第二位在硬件产生较小改动时所用；
• 第三位指硬件在完全没有改动情况下，对固件包的修改时所用。

固件版本格式

(0~255).(0~255).(0~65535)

• 三个位的定义，与硬件一致
• 在实际固件升级过程中，*前两位应与硬件的保持一致*，第三位应 大于等于 硬件的第三位

审核日志类型解析

保存在hardware_version表test_log字段，以JSON结构存储，详见后台代码HardwareVersion::$defaultTestLog

结构如下

• inner: 内测阶段
• gray: 灰度阶段
• publish: 正式发布
• down: 下架重申
• waterLogs: 操作流水多条

其中，inner/gray/publish/down属性用于表示固件的最终审计情况（即四个属性仅保存最后一次的变更值）

还有一个特殊的属性waterLogs，用于保存每次审计产生的流水，每条流水的格式如下：

['type' => 'inner内测|gray灰度|publish正式|down下架', 'data' => 'inner|gray|publish对应的数据'],

---

鞋子硬件地址

类似与网络的MAC地址

特别说明，不同的左右鞋组合，会产生不同的地址。两双鞋任意左右组合，则地址数有4个。

但实际生产环境下，普通用户只有一双鞋，故地址也应只有一个

---

内测过程

1. 后台在上传固件后，点击“开始内测”，选定参与内测的人员（但不需要特别定死机型等信息）。之后可以随时修改内测参与条件。
2. 相关人员通过趣动APP，检查固件更新，直接收到内测版本的固件推送，按APP提示操作即可。
3. 在测试人员确认固件没有问题后，在后台固件界面，点击“继续内测”打开浮动面板，再点击“确认通过内测，前往灰度发布”按钮。此时测试阶段的生命周期完结。

---

灰度发布过程

1. 在后台顶部找到正在内测过程的固件，执行前文中[内测过程]的第3步
2. 在灰度发布面板，填写确认的开发人员姓名，及灰度完成人数指标。点击“保存灰度指标”，这样就进入了灰度过程，此时对外有限开放空中升级生效。
3. 当实际升级人数不低于灰度指标时，才可点击“前往正式发布”。此时灰度的生命周期完结。

---

正式发布过程

1. 在后台顶部找到正在灰度发布过程的固件，执行前文中[灰度发布过程]的第3步
2. 指定确认正式发布的开发人员姓名，点击“确认发布”。

---

下载人数统计

下载流水保存在 hardware_version_dl 表

以用户ID+版本ID为数据句柄，同条件仅保存最后一次下载的流水。

---

下载人数与实际升级人数的区别

• 下载人数 > 以hardware_version_dl为依据，作count统计得到。 > 是指点击了检查更新下载了固件的用户数 实际升级人数：

• 实际升级人数

  指完成了下载且成功升级了固件的用户数,这个才算使用人数

  一般地，实际人数会小于下载人数。

  但如果实际人数大于下载人数，则可能是由于固件开发者使用了线刷或测试环境升级等方式，部署了固件.