shoes-doc

shoes-doc

• 智能鞋文档
• 替代：https://www.showdoc.com.cn/oujshoes/5563386304444371

目前单位粒度：

• 时间 duration 秒
• 消耗 consume 大卡/千卡
• 距离 distance 米

操作系统参数 os：

• 1 Android
• 2 IOS

---

• 如果测试服的表描述与正式服有出入，以测试服为最新标准

---

app 1.4 版本发布到正式服时需要的操作

1. 运行重新统计
2. 清理用户积分记录表，只记录消费的积分
3. 清理运动目标表，将 consume 转为 duration

---

交接相关

shoes 项目目前后端主要由林雨(13640875627，以下写作本人）和方坤标进行开发和维护

项目主要分 社交 和 运动 两大块，进一步细分

• 社交包含 论坛发帖、举报反馈、好友关系、通知公告、用户聊天、分享转发 等功能
• 运动包含 游戏记录、目标成就、跑步记录、运动数据、积分交换、排行榜单 等功能
• 此外还有一些其他功能，用户信息、第三方登录注册、设备推送 等

目前本人负责的功能主要有：用户聊天、运动分享，以及上述提到的所有运动和其他功能

框架使用了简单的自建 mvc 框架，根据 url 中的路径找到对应的控制器和方法即可

• 在基础控制器可以设置具体路由是否需要登录访问
• 一些请求的公共操作也放在基础控制器的构造函数

配置文件是根据所访问的域名决定的，分为 全局、开发、测试、正式 环境，终端环境需要加上 env 参数传递具体环境

插件和自动加载，本框架并未使用 composer 来提供自动加载，主要加载流程在 framework/loader.php 中

• 类可以在设置的路径中逐个查找
• 一些全局函数可以在文件数组中指定进行加载
• extensions 路径可以放插件或者 composer 的包，如果二级目录有 init.php 则这个文件会被引入

Laravel 相关，为了增强功能，框架引入了 Laravel 的 数据库、表单验证 插件，具体使用方法可以查阅 Laravel 5.5 版本文档

• 表单验证 https://learnku.com/docs/laravel/5.5/validation/1302
• 数据库 https://learnku.com/docs/laravel/5.5/eloquent/1332

数据库操作，该项目有两个数据库操作方式

• 一个是 SQL 拼接工具，其基类在 framework/Model.php，模型存放目录在 models
• 另一个是 ORM 映射工具， Laravel 的 Eloquent，其模型基类在 framework/LModel.php，模型存放目录在 lmodels
• 本人负责的功能大多是用 ORM 的方式操作数据库的

控制器逻辑抽离，该项目的控制器公用业务逻辑，有两种抽离方式

• 第一种是放在 models 目录下的模型中包含相关业务方法
• 第二种是在 services 目录中抽出来的单个服务类
• 本人负责的功能大多是用第二种方式复用逻辑代码

缓存使用 redis，有 dwRedis 和 LRedis 两种方式，本人使用 LRedis 类操作 redis

• 在 LRedis 中集中定义 键 和 类型，避免在其他地方直接写错键名，也避免用错类型
• LRedis 将键分为三种，一种是不用拼接，一种是在后面拼接，另一种是通过模板传参
• LRedis 将 redis 操作封装了一层，需要自定义的操作可以继续拓展

日志分为两类，一类是 TmpLog 类主动记录所需的数据，一类是请求日志

• TmpLog 记录的数据在 tmp_log 表中
• 请求日志在 request_log 表中，每张表存一个星期的数据，数据首先缓存在 redis 中，由 tasks/saveRequestLog.php 每分钟写入数据库，LogService 可以控制写入行为

限流工具在 LimitService，主要用于防止用户刷一些关键或收费接口

• 每个功能的限流需要先定义 redis 的键
• 可以根据用户 ID、手机、IP 和 自定义键来进行统计
• 以 limit 开头的相关方法也集成到了基础控制器中

脚本、任务 和 测试

• 脚本一般用于执行数据库批量修改，目录在 scripts，目前有 重新统计用户消耗、重新计算记录 MET、重新统计用户运动数据 和 重置用户数据 四个脚本
• 任务一般用于 cron 中定期执行，目录在 tasks，例如每分钟更新游戏缓存等
• 测试，目录在 tests，一般放一些单元测试或者请求测试

运动记录分为三类，游戏、跑步 和 日常步数

• 运动记录的基础表为 exer_record，记录通用的参数，例如步数、时长、卡路里等，根据类型不同关联了其他记录
• 游戏记录基础表为 game_record，记录了游戏的额外参数，例如积分、游戏模式等
• 跑步记录的基础表为 jog_record，记录了跑步的额外参数，例如每公里配速、轨迹信息（长字段在 jog_record_info）等
• 日常步数不需要额外表

运动记录统计，相关表为 exer_record_x，x 为 day month sum 时分别统计 天 月 总

• 统计表的来源为 exer_record 表，通过 ExerService 的 doSumRecord 来添加一条记录的统计
• 统计的指标包括 消耗（总、游戏、跑步、日常），时长（总、游戏、跑步），步数（总、游戏、跑步、日常），距离（总、游戏、），次数（总、游戏、跑步），下蹲、跳跃、有效时长（步数、游戏步数、跳跃、下蹲），met
• 重新统计：如果卡路里等计算方式的需求发生了变化，则原来的记录需要重新统计，在 scripts/reCalcX 脚本。所有统计的的重新统计类似

跑步记录统计，jog_record_km_duration_month 保存每个月内分距离最短用时的记录，jog_record_month 分 距离、时长和配速三个指标保存一个月内最好的记录

• 统计表的来源为 exer_record 和 jog_record，通过 JogService 的 sumRecord 方法来添加一条记录的统计
• 统计和查询时需要分时间段计算最佳指标：最远距离、最长时间、最快配速、分公里的最快时间，具体计算相关方法在 JogService 的 Best 关键词的方法

游戏记录统计，分游戏统计游戏和运动数据，相关表为 game_record_sum

日常步数，维度为每小时，不包含时长

• 批量处理用的脚本在 tasks/syncStep.php，前端一次性提交超过 100 条数据会插入临时表等待批量处理
• 日常步数处理在 ExerService 的 addDailyStep，该方法对批量处理做了优化

聊天消息轮询，相关表为 message

• 查询是否有新消息采用轮询的方式，检测缓存中的最新消息 id 达到同步的目的
• 消息记录存储在用户设备，服务器只临时保存三个月的，和固定条数的未读消息
• 消息类型根据 type 字段分为 文本、图片、链接、转发帖子、转发运动和游戏邀请

游戏邀请和推送，通过 PushService 进行推送，目前使用的推送服务是个推

游戏和运动榜单，相关表为 rank、rank_game_record、rank_sport_record

• 榜单分为两种，一是对应一个游戏的游戏榜单，二是对应一个运动指标的运动榜单
• 榜单统计以月为周期，统计前一百名，并根据排名发放奖励，对应脚本 tasks/settleRank.php
• 榜单排位的变动需要发送通知，一次排名变动，所有影响到的用户都需要发

成就记录，相关表为 achievement、achievement_series、user_achievement、user_achievement_times_record

• 成就分系列，每个系列有多个成就，系列内成就的统计指标相同
• 成就的描述需要为 动词 + 数量 + 量词 的组合，例如 累计登陆 10 天
• 成就完成需要发送通知，弹窗展示

运动目标，相关表为 sport_target、sport_target_record、sport_target_reward

• 可以设置每天的目标为自定义分钟，游戏或者跑步都可以增加进度

卡路里计算（MET）

• 消耗的卡路里需要通过 卡路里消耗（kal） = MET值 × 0.0167 × 时间h（min） × 体重（kg）
• 相应的 MET 值，步数、跳和蹲的对应时间，产品都有文档记录
• 游戏卡路里 GameService->calcConsume，跑步卡路里 JogService->calcConsume，日常步数卡路里 ExerService->calcDailyStepConsume
• MET 可以通过公式反推，用总的数据得到响应的平均 MET 进行展示

---

页游相关

坦克伪装月卡

新增购买记录表 hd_card_buy，其他相关表 hd_card_type（卡码类型），hd_card_store（卡码库存），order（订单，在 extra 字段存储卡码信息）。

• 购买方法在 order/createTankMask
• 支付回调在 order/payCallback
• 激活卡码在 item/checkCard

外部游戏（跳转群黑游戏）

新增 hd_item_outer_game_timer 表（用于计算外部游戏的游玩时间，以便识别任务状态，以下简称 timer 表），其他相关表 game（游戏），hd_item_user（用户当天道具领取）

• 外部游戏为 game 表中的 game_mode = 3
• 获取外部游戏跳转链接在 login/outerGame
• 领取任务在 item/accept 外部游戏需要做特殊处理，在 timer 表添加记录（任务是玩某个游戏一定时间，可以领取奖励，外部游戏的新需求只关心任务的领取，及任务完成的状态变更即可，其余跟正常游戏一样）
• 任务列表相关在模型 ItemUser 中处理了外部游戏的特殊情况：
• userItemInit 方法的返回中加入了 game_mode 和 outer_game_code 字段
• checkUserItem 方法中外部游戏的任务，在与 timer 表对比后获得任务的状态