OnecardDemo 用户信息每批 1000 条设计

日期：2026-08-24
状态：已实施，待现场验证

1. 目标

将 Android 端“获取全部用户信息”的分页大小从每批 200 条调整为每批 1000 条，减少用户总量较大时的 WebService 请求次数。

厂家文档没有规定 GetCustomerByNum 的单次硬性上限；1000 条是当前 Android 实现采用的分页策略，不表述为厂家接口限制。

2. 功能边界

• 只修改“获取全部用户信息”的自动分页大小。
• 分页默认值定义为现有常量类中的 Constants.ONE_CARD_CUSTOMER_BATCH_SIZE = 1000，WebService 客户端读取该常量，不在客户端内部硬编码数字。
• 每批最多请求 1000 条；最后一批不足 1000 条时，按剩余数量请求。
• 例如用户总数为 2500 时，依次请求 1000、1000、500 条。
• “获取部分用户信息”继续使用页面输入的数量，不额外强制限制为 1000。
• 起始账号继续使用上一批返回的最大 CUSTOMERID + 1，不改变现有分页游标规则。
• 本次不增加页面配置项或持久化配置；后续可配置化时替换常量取值来源，不改变分页流程。
• 不修改服务器地址、AppID、SOAP 操作名、超时参数、XML 解析或页面布局。

3. 错误处理

沿用现有行为：响应不含 CUSTOMERID、用户编号无法解析、HTTP/SOAP/XML 请求失败或返回异常时停止全部用户下载并显示错误，不用空数据继续翻页。

本次不增加自动降级到 500/200 条的逻辑；如果 1000 条在现场服务器出现超时，再根据实际日志单独设计动态降级策略。

4. 验证方案

• 增加分页行为测试，验证 2500 条会按 1000、1000、500 分批。
• 验证不足 1000 条时只请求一次实际数量。
• 运行服务器相关单元测试和完整 JVM 测试。
• 运行 Debug APK 构建和 Lint，确认没有编译或静态检查回归。
• 现场连接服务器后执行“获取全部用户信息”，检查返回总数、分页结果和是否超时。

5. 验收标准

• 代码中的自动分页大小为 1000。
• 分页值集中定义在 Constants，WebService 客户端不再保存私有分页常量。
• 全量获取不会请求超过剩余用户数的数量。
• 部分用户查询行为保持不变。
• 协议说明明确 1000 是 Android 当前分页策略，而非厂家硬上限。
• 自动测试、构建和 Lint 通过后交付现场验证。