关于App请求及使用中的一些思考

本文主要总结归纳:

  • 网络请求整个过程中的所需要进行的业务流程

及对app开发中的一些思考:

  • 羊毛党用户如何处理
  • 服务器访问避免拥堵
  • app崩溃事故如何避免

N次叠加总结,经验不断积累,精益求精,永久使用,何乐不为?


网络请求流程相关

网络请求前

判断是否需要执行缓存

*【优先用缓存(数据库、sp、腾讯MMKV、图片可以预加载在内存中),如果存在缓存不执行下面操作】

网络请求前

检查网络正常连接时

  • 请求参数【加密】签名校验等操作
  • 加入正在加载动画、或阴影块代替当前显示UI、或先用缓存【可显示上次缓存时间、设置过期不缓存等逻辑】展示

检查网络断开连接时

  • 提示、或弹框提示【可参考权限请求类似流程】
  • 是否执行缓存逻辑【需根据业务动态控制】
  • 需注意:网络及时恢复是否再次自动请求【动态获取当前接口是否需要、可用viewmodel和livedata来做】

网络请求期间

拦截相关

  • 请求前【补充header信息、或者公用参数等】可根据参数加上是否需要添加
  • 请求前后【接口加密、解密】
  • 请求后【301重试、登录失效退出等、响应数据统一处理、缓存、304服务端返回的数据是上次的缓存数据客户端可直接以缓存为准】

网络请求后

网络响应超时

  • 重试机制进行前
    • 判断接口是否需要进行重试
  • 重试机制进行时
    • 执行请求前【检查网络连接】如中途网络断开,中断重试机制
      • 连接正常,重试N次,每次【动态获取当前接口是否再需要重试】
  • 重试机制结束后【检查网络连接】【网络断开时提示、或弹框提示】执行
    • 网络数据获取失败、重试失败、无缓存等
    • 执行网络错误展示、并加入重试按钮等

网络响应正常

  • 针对相同返回数据格式统一处理共用逻辑【可在请求之前设置是否执行,根据每个请求绑定一个tag来判断需要统一处理与否】
  • 关闭正在加载动画等类似业务
  • 执行数据缓存等、删除多余过期缓存

网络响应错误

  • 可自定义类似网站一样的错误页面跳转

其他遐想

客户端超流量并发请求服务器

  • 可否与服务器自定义好协议、第一个接口初始化获取当前app流向那个服务器。下一次该app就走新服务器获取后台数据。
  • 第一个获取app流向那个服务器,可根本当前服务器承受的压力进行选择,保证用户访问稳定有效【每台服务器保证连接用户在当前最大限制内】。【可能需要后台多数据库相互之间及时备份、对于访问不需要及时性的api可走缓存】

第三方骚扰用户识别加黑

  • 使用定位判断用户是否远程刷单等、如是可IP加黑处理
  • 模拟器不准使用、或只能使用公司利益不受损业务
  • 可开多级防线来处理【不同防线用户能访问的业务不一样、防线不触犯可降级、触犯就增加级别】

app崩溃防线设定

  • app直接打不开的情形,清理所有缓存数据,类似重新安装处理。【并上报服务器一级事故】
  • app崩溃次数在能接受范围或指定业务只清理相关业务缓存等,【可上报服务器注意排查】

关于app优化

  • 关于内存优化:可尝试单独使用进程操作【图库、webview浏览】
  • 关于启动优化:sdk初始化相关单独开线程、或延时初始化亦可延长至需要使用的地方再初始化