Android网络底层框架设计

简介:

很多人在进行网络请求的时候，都是直接请求网络数据，然后每次都自己手动解析数据，判断接口类别，然后再进行下一个步骤，但是其实请求网络数据有很多共性的东西，例如存储请求参数的统一性、后台返回的数据类型统一性、sessionId 过期处理统一性等。

（总结《App研发录》第二章（Android 网络底层框架设计））

目录:

1.网络底层封装

2.App 数据缓存设计

3.用户登录

4.HTTP 头中的奥妙

网络底层封装

网路请求格式

Request 格式

网络请求一般具有 POST 、GET 方式：

• POST 方式是把 key-value 这样的键值对存放在 Form 表单中。
• GET 方式是把 key-value 这样的键值对存放在 URL 上。

其实无论是哪种方式，都需要 key-value 的方式，因此，在传参数给网络请求框架的时候，都可以以 Map 的形式，然后网络请求框架再依据请求方式，把 Map 里面的数据取出来，放入相应的位置即可。

Response 格式

后台返回数据格式一般为 JSON，可以与后台协商返回固定格式的 JSON，例如所有的 JSON 都返回 isError、errorType、errorMessage、result 四个字段，它们的意思分别为：

• isError：请求网络数据成功与否。
• errorType：错误类型。
• errorMessage：错误消息。
• result：请求成功的时候返回的数据结果

AsyncTask 的使用和缺点

• 将 AsyncTask 封装在 AndroidLib 类库中。
• 对于网络错误进行处理。例如：
  • SessionId 过期时，提示用户重新登录
  • 无网络时，提示用户检查数据连接情况
  • 服务器无响应的时候，提示服务器正在维护
• 开发者在请求网络框架时，不该处理这么多错误或成功判断，而是应该直接重写 onSuccess 和 onFail 两个回调函数即可。
• AsyncTask 无取消请求的方法，一旦请求后，就不会被取消，导致资源过度浪费并使得迫切请求的接口无法排上队列，无法进行处理。

网络底层的一些优化工作

• 使用 onFail 的统一处理机制，对于常见的问题进行处理。
• 将存放 url 文件的数据一次性全部读取处理，并且放到内存中方便之后进行访问，若内存被回收，则重新读取。
• 不是每个请求都需要回调。
• ProgressBar 的处理。在请求数据的时候，显示进度条，直到有结果返回的时候才将进度条隐藏。进度的样式需要整个 App 风格统一。

App 数据缓存设计

数据缓存策略

• 减少网络获取数据次数：
  • 原本需要从 3 个接口中获取数据，可以制作一个新的接口，一次性获取这些数据。
  • 调用完一次 GET 方式的接口，在一段时间内不能再调用。
• 将 GET 方式的接口数据缓存到本地中，无网络的时候进行获取返回。

强制更新

由于我们使用了数据缓存策略，导致一段时间内的数据不会再进行更新，这时，应该提供一个按钮让用户决定是否强制更新该页面中的数据。

用户登录

自动登录

• 不可将账户密码保存到本地数据中，应使用 Cookie 进行判断是否需要登录。
• 当 Cookie 过期的时候，无论用户身处哪个页面，都必须弹出框，提示用户“Cookie 过期，请重新登录”。
• 为了防止黑客刷库。当发现同一 IP 短时间内频繁访问某个接口的时候，就需要进行拦截，让其进行手动验证才能进行继续访问。

HTTP 头中的奥妙

时间校准

HTTP Response 头中具有一个重要属性——Date，该属性记录了当时的服务器时间。由于部分 App 的本地时间不准确，因此，需要把服务器时间与本地时间进行相减，得到一个差值保存起来，之后读取本地时间的时候，加上该差值，则是服务器时间。

开启 gzip 压缩

当数据返回的量太大的时候，需要开启 gzip 压缩：

• 减少存储空间
• 减少传输的时间

若已开启 gzip 压缩，在获取接口的数据的时候，需要把数据解压后再进行处理。

来源：CSDN

作者：不近视的猫

链接：https://blog.csdn.net/m0_46278918/article/details/104198355