［读书笔记］《APP研发录》第二章

APP研发录第二章笔记

抛弃AsyncTask，自定义一套网络底层的封装框架。

设计一套App缓存策略。

设计一套MockService的机制，在没有MobileAPI的时候，也能假装获取到了网络返回的数据。

封装了用户Cookie的逻辑。

2.1 网络底层封装

很多公司和团队都是用AsyncTask来封装网络底层，因为这个类非常好用，内部封装了很多好用的方法，但缺点是可扩展性不高。

对于网络请求，我们一般定义为GET和POST即可，GET为请求数据，POST为修改数据（增删改）。

1.Request格式

所有的MobileAPI都可以写作http://www.xxx.com/aaaa.api的形式。

对于GET，我们可以写作：http://www.xxx.com/aaaa.api?k1=va&k2=v2的形式，也就是说，把key-value这样的键值对存放在URL上。之所以这样设计，是为了更方便地定义数据缓存。我们尽量使GET的参数都是string、int这样的简单类型。

对于POST，我们将key-value这样的键值对存放在Form表单中，进行提交。POST经常会提交大量数据，所以有些键值对要定义成集合或者复杂的自定义实体，这时我们就需要将这样的值转换为JSON字符串进行提交，由App传递到MobileAPI后，再将JSON字符串转换为对应的实体。

2.Response格式

我们一般使用JSON作为MobileAPI返回的结果。最规范的JSON数据返回格式如下。

JSON数据格式1：

{
"isError" : true,
"errorType" : 1,
"errorMessage" : "网络异常",
"result" : ""
}

JSON数据格式2：

{
"isError" : false,
"errorType" : 0,
"errorMessage" : "",
"result" : {
"cinemaId" : 1,
"cinemaName" : "星美"
}
}

这里，isError是调用MobileAPI成功与否，errorType是错误类型（如果成功则为0），errorMessage是错误消息（如果成功则为空），result是成功请求返回的数据结果（如果失败则返回空）。

既然所有的JSON都返回isError、errorType、errorMessage、result这4个字段，我们不妨定义一个Response实体类，作为所有JSON实体的最外层，代码如下所示：

public class Response
{
private boolean error;
private int errorType;       // 1为Cookie失效
private String errorMessage;
private String result;
public boolean hasError() {
return error;
}
public void setError(boolean hasError) {
this.error = hasError;
}
public String getErrorMessage() {
return errorMessage;
}
public void setErrorMessage(String errorMessage) {
this.errorMessage = errorMessage;
}
public String getResult() {
return result;
}
public void setResult(String result) {
this.result = result;
}
public int getErrorType() {
return errorType;
}
public void setErrorType(int errorType) {
this.errorType = errorType;
}
}

如果成功返回了数据，数据会存放在result字段中，映射为Response实体的result属性。

上面的JSON数据返回的是一笔影院数据，如果返回的result是很多影院的数据集合，那么就要把result解析为相应的实体集合，如下所示：

{
"isError" : false,
"errorType" : 0,
"errorMessage" : "",
"result" : [
{"cinemaId" : 1, "cinemaName" : "星美"},
{"cinemaId" : 2, "cinemaName" : "万达"}
]
}

2.1.2 AsyncTask的使用和缺点

对AsyncTask的封装属于网络底层的技术，所以AsyncTask应该封装在AndroidLib类库中，而不是具体的项目里。

对网络异常的分类，也就是Response类中的errorType字段，分析如下：

一种是请求发送到MobileAPI，MobileAPI执行过程中发现的异常，这时候要自定义错误类型，也就是errorType，比如说1是Cookie过期，2是第三方支付平台不能连接，等等，这些已知的错误都是大于0的整数，因接口不同而各自定义不同。

另一种是在App访问MobileAPI接口时发生的异常，有可能App自身网络不稳定，有可能因为网络传输不好导致返回了空值，这些异常情况我们都标记为负数。

基于上述分析，AsyncTask的doInBackground方法复写为：

@Override
protected Response doInBackground(String… url) {
return getResponseFromURL(url[0]);
}
private Response getResponseFromURL(String url) {
Response response = new Response();
HttpGet get = new HttpGet(url);
String strResponse = null;
try {
HttpParams httpParameters = new BasicHttpParams();
HttpConnectionParams.setConnectionTimeout(httpParameters, 8000);
HttpClient httpClient = new DefaultHttpClient(httpParameters);
HttpResponse httpResponse = httpClient.execute(get);
if (httpResponse.getStatusLine().getStatusCode()
== HttpStatus.SC_OK) {
strResponse = EntityUtils.toString(httpResponse.getEntity());
}
} catch (Exception e) {
response.setErrorType(-1);
response.setError(true);
response.setErrorMessage(e.getMessage());
}
if (strResponse == null) {
response.setErrorType(-1);
response.setError(true);
response.setErrorMessage("网络异常, 返回空值");
} else {
strResponse = "{'isError':false,'errorType':0,'errorMessage':'',
'result':{'city':'北京','cityid':'101010100','temp':'17',
'WD':'西南风','WS':'2级','SD':'54%','WSE':'2','time':'23:15',
'isRadar':'1','Radar':'JC_RADAR_AZ9010_JB',
'njd':'暂无实况','qy':'1016'}}";
response = JSON.parseObject(strResponse, Response.class);
}
return response;
}

相应的，在AsyncTask的onPostExecute方法中，我们要对错误类型进行分类，从而进一步回调：

public abstract class RequestAsyncTask
extends AsyncTask<String, Void, Response> {
public abstract void onSuccess(String content);
public abstract void onFail(String errorMessage);
@Override
protected void onPreExecute() {
}
@Override
protected void onPostExecute(Response response) {
if(response.hasError()) {
onFail(response.getErrorMessage());
} else {
onSuccess(response.getResult());
}
}

目前我们只定义了onSuccess和onFail两个回调函数，将网络返回值简单地分为成功与失败两种情况。

在相应的Activity页面，调用AysncTask如下所示：

protected void loadData() {
String url = "http://www.weather.com.cn/data/sk/101010100.html";
RequestAsyncTask task = new RequestAsyncTask() {
@Override
public void onSuccess(String content) {
// 第2种写法, 基于fastJSON
WeatherEntity weatherEntity = JSON.parseObject(content,
WeatherEntity.class);
WeatherInfo weatherInfo = weatherEntity.getWeatherInfo();
if (weatherInfo != null) {
tvCity.setText(weatherInfo.getCity());
tvCityId.setText(weatherInfo.getCityid());
}
}
@Override
public void onFail(String errorMessage) {
new AlertDialog.Builder(WeatherByFastJsonActivity.this)
.setTitle("出错啦").setMessage(errorMessage)
.setPositiveButton("确定", null).show();
}
};
task.execute(url);
}

网上关于如何使用AsyncTask的文章不胜枚举，大家都在欣赏它的优点，却忽略了它的致命缺点，那就是不能灵活控制其内部的线程池。

线程池里面的每个线程存放的都是MobileAPI的调用请求，而AsyncTask中又没有暴露出取消这些请求的方法，也就是我们熟知的CancelRequest方法，所以，一旦从A页面跳转到B页面，那么在A页面发起的MobileAPI请求，如果还没有返回，并不会被取消。

对于一款频繁调用MobileAPI的应用类App而言，最严重的情况发生在首页到二级页面的跳转，因为在首页会调用十几个MobileAPI接口，视网络情况而定，如果是WiFi，应该很快就能请求到数据，不会产生积压，但如果是3G或者2G，那么请求就会花费很长时间，而我们在这期间就跳转到二级页面，而这个二级页面也会调用MobileAPI接口，那么将得不到任何结果，因为首页的请求还在排队处理中，之前的那十几个MobileAPI接口的数据还都遥遥无期在线程池里排队呢，就更不要说当前页面这个请求了。

如果你不信，我们可以做个试验。记录每次MobileAPI请求发起和接收数据的时间点，你会看到，在迅速进入二级页面后，首页的十几个MobileAPI请求只有发起时间并没有返回时间，说明它们还在处理过程中，都被堵塞了。

2.1.3 使用原生的ThreadPoolExcutor+Runnable+Handler

既然AsyncTask有诸多问题，那么退而求其次，使用ThreadPoolExecutor+Runnable+Handler的原生方式，对网络底层进行封装。

建议大家下载源码感受一些，源码下载地址：

《App研发录》 源码

2.1.4　网络底层的一些优化工作

接下来将完善这个框架，修复其中的一些瑕疵，如onFail的统一处理机制、UrlConfigManager的优化、ProgressBar的处理等。

1.onFail的统一处理机制

如果访问MobileAPI请求失败，我们一般希望只是在App上简单地弹出一个提示框，告诉用户网络有异常。

也就是说，对于每个在Activity中声明的RequestCallback实例而言，尽管每个onSuccess方法的处理逻辑各不相同，但每个onFail方法都是一样的逻辑和代码，如下所示：

weatherCallback = new RequestCallback() {
@Override
public void onSuccess(String content) {
WeatherInfo weatherInfo = JSON.parseObject(content,
WeatherInfo.class);
if (weatherInfo != null) {
tvCity.setText(weatherInfo.getCity());
tvCityId.setText(weatherInfo.getCityid());
}
}
@Override
public void onFail(String errorMessage) {
new AlertDialog.Builder(WeatherByFastJsonActivity.this)
.setTitle("出错啦").setMessage(errorMessage)
.setPositiveButton("确定", null).show();
}
};

我不希望每次都编写同样的onFail方法，这会使程序很臃肿。于是在AppBaseActivity中写一个自定义类AbstractRequestCallback，如下所示：

public abstract class AppBaseActivity extends BaseActivity {
public abstract class AbstractRequestCallback
implements RequestCallback {
public abstract void onSuccess(String content);
public void onFail(String errorMessage) {
new AlertDialog.Builder(AppBaseActivity.this)
.setTitle("出错啦").setMessage(errorMessage)
.setPositiveButton("确定", null).show();
}
}
}

那么我们的weatherRequestCallback的实例化就可以改写如下，可以看到，不再需要重写onFail方法：

weatherCallback = new AbstractRequestCallback() {
@Override
public void onSuccess(String content) {
WeatherInfo weatherInfo = JSON.parseObject(content,
WeatherInfo.class);
if (weatherInfo != null) {
tvCity.setText(weatherInfo.getCity());
tvCityId.setText(weatherInfo.getCityid());
}
}
};

当然，如果有些MobileAPI接口在返回错误时需要App特殊处理，比如重启App或者啥都不做，我们只需要在实例化AbstractRequestCallback时，重写onFail方法即可，如下所示。重写的onFail方法是一个空方法，表示出错时啥都不做：

weatherCallback = new AbstractRequestCallback() {
@Override
public void onSuccess(String content) {
WeatherInfo weatherInfo = JSON.parseObject(content,
WeatherInfo.class);
if (weatherInfo != null) {
tvCity.setText(weatherInfo.getCity());
tvCityId.setText(weatherInfo.getCityid());
}
}
@Override
public void onFail(String errorMessage) {
// 重启App或者啥都不做
}
};

2.UrlConfigManager的优化

在UrlConfigManager的实现上，我们采取的策略是每发起一次MobileAPI请求，都会读取url.xml文件，把符合这次MobileAPI接口调用的参数取出来。

在一个大量调用MobileAPI的App中，这样的设计会造成频繁读xml文件，性能很差。于是我们对其进行改造，在App启动时，一次性将url.xml文件都读取到内存，把所有的UrlData实体保存在一个集合中，然后每次调用MobileAPI接口，直接从内存的这个集合中查找。考虑到内存中的数据会被回收，所以上述这个集合一旦为空，我们要从url.xml中再次读取。

基于上述方案，我们对UrlConfigManager的findUrl方法进行改造：

public static URLData findURL(final Activity activity,
final String findKey) {
// 如果urlList还没有数据(第一次)
// 或者被回收了, 那么(重新)加载xml
if (urlList == null || urlList.isEmpty())
fetchUrlDataFromXml(activity);
for (URLData data : urlList) {
if (findKey.equals(data.getKey())) {
return data;
}
}
return null;
}

其中，fetchUrlDataFromXml方法就不多说了，它的工作就是把xml的数据都搬到内存集合urlList中。

3.不是每个请求都需要回调的

有些时候，我们调用一个MobileAPI接口，并不需要知道调用成功与否以及返回结果是什么，比如向MobileAPI发送打点统计数据。那就是说，我们不需要回调函数了，那么代码可以写为：

void loadAPIData3() {
ArrayList<RequestParameter> params
= new ArrayList<RequestParameter>();
RequestParameter rp1 =
new RequestParameter("cityId", "111");
RequestParameter rp2 =
new RequestParameter("cityName", "Beijing");
params.add(rp1);
params.add(rp2);
RemoteService.getInstance()
.invoke(this, "getWeatherInfo", params, null);
}

我们将空的RequestCallback传给HttpRequest，那么在HttpRequest处理请求返回的结果时，就需要添加HttpRequest是否为空的判断，不为空，才会处理返回结果；否则，发起MobileAPI请求后什么都不做。

有以下两个地方需要修改：

1）处理请求时：

response = httpClient.execute(request);
if ((requestCallback != null)) {
// 获取状态
final int statusCode =
response.getStatusLine().getStatusCode();
if (statusCode == HttpStatus.SC_OK) {
final ByteArrayOutputStream content =
new ByteArrayOutputStream();

2）遇到异常，是否要回调onFail方法：

public void handleNetworkError(final String errorMsg) {
if ((requestCallback != null)) {
handler.post(new Runnable() {
@Override
public void run() {
HttpRequest.this.requestCallback
.onFail(errorMsg);
}
});
}
}

4.ProgressBar的处理

在调用MobileAPI的时候，会显示进度条ProgressBar，直到返回结果到onSuccess或onFail回调方法，ProgressBar才会消失。

由于App要保持风格统一，所以所有页面的ProgressBar应该长得一样。那么我们就可以将其定义在AppBaseActivity中，如下所示：

public abstract class AppBaseActivity extends BaseActivity {
protected ProgressDialog dlg;
public abstract class AbstractRequestCallback
implements RequestCallback {
public abstract void onSuccess(String content);
public void onFail(String errorMessage) {
dlg.dismiss();
public void onFail(String errorMessage) {
dlg.dismiss();
new AlertDialog.Builder(AppBaseActivity.this)
.setTitle("出错啦").setMessage(errorMessage)
.setPositiveButton("确定", null).show();
}
}
}

在使用的时候，在开始调用MobileAPI的地方，执行show方法；在onSuccess和onFail方法的开始，执行dismiss方法：

@Override
protected void loadData() {
dlg = Utils.createProgressDialog(this,
this.getString(R.string.str_loading));
dlg.show();
loadAPIData1();
}
void loadAPIData1() {
weatherCallback = new AbstractRequestCallback() {
@Override
public void onSuccess(String content) {
dlg.dismiss();
WeatherInfo weatherInfo = JSON.parseObject(content,
WeatherInfo.class);
if (weatherInfo != null) {

不要把Dialog的show方法和dismiss方法封装到网络底层。网络底层的调用经常是在子线程执行的，子线程是不能操作Dialog、Toast和控件的。

2.2　App数据缓存设计

如果以为上一节内容就是网络底层框架的全部，那就错了。那只是网络底层框架的最核心的功能，我们还有很多高级功能没有介绍。在接下来的几节中，我将陆续介绍到这些高级功能。本节先介绍App本地的缓存策略。

2.2.1　数据缓存策略

对于任何一款应用类App，如果访问MobileAPI的速度和牛车一样慢，那么就是失败之作。不要在WiFi下测试速度，那是自欺欺人，要把App放在2G或3G网络环境下进行测试，才能得到大部分用户的真实数据。

访问MobileAPI，主要慢在一来一回的传输速度上，对于服务器的处理速度，不需要担心太多，大多数服务器逻辑原本就是支持网站端的，现在只是在外面包了一层，返回给App而已。

既然时间主要花在了数据传输上，那么我们就要想一些应对的措施。比如说，减少MobileAPI的调用次数。对于一个App页面，它一次性可能需要3部分数据，分别从3个MobileAPI接口获取，那么我们就可以做一个新的MobileAPI接口，将这3部分数据都获取到，然后一次性返回。

减少调用次数只是若干解决方案中的一种，更极端的做法是，App调用一次MobileAPI接口后，在一个时间段内不再调用，仍然使用上次调用接口获取到的数据，这些数据保存在App上，我们称为App缓存，这个时间段我们称为App缓存时间。

App缓存只能针对于MobileAPI中GET类型的接口，对于POST不适用。因为GET是获取数据，而POST是修改数据。

此外，即使是GET类型的接口，对于那些即时性很低的、不怎么改变的数据，比如获取商品的描述，缓存时间可以设置得比较长，比如5~10分钟，对于那些即时性比较高、频繁变动的数据，比如商品价格，缓存时间就会比较短，甚至不能进行缓存。

即使对于同一个需要做App缓存的MobileAPI，参数不同，缓存也是不同的。比如GetWeather.api这个MobileAPI接口，它有一个参数也就是时间date，对于date=2014-9-8和date=2014-9-9，它们就分别对应两个缓存，不能存在一起。

接下来要说的是，App缓存存在哪里，以及以什么方式进行存放。由于缓存数据比较大，所以我们将其存在SD卡上，而不是内存中。这样的话，App缓存策略就仅限于那些有SD卡的手机用户了。

我们可以将xxx.apik1=va&k2=v2这样的URL格式作为key，存放App缓存数据。需要注意的是，我们要对k1、k2这些key进行排序，这样才能唯一，否则对于如下URL：

xxxx.apik1=v1&k2=v2
xxxx.apik2=v2&k1=v1

就会被认为是两个不同的key存放在缓存中，但其实它们是一样的。

对上面的介绍总结如下：

1）对于App而言，它是感受不到取的是缓存数据还是调用MobileAPI。具体工作由网络底层完成。

2）在url.xml中为每一个MobileAPI接口配置缓存时间Expired。对于post，一律设置为0，因为post不需要缓存。

3）在HttpRequest类中的run方法中，改动3个地方：

a）写一个排序算法sortKeys，对URL中的key进行排序。

b）将newUrl作为key，检查缓存中是否有数据，有则直接返回；否则，继续调用MobileAPI接口。

// 如果这个get的API有缓存时间(大于0)
if (urlData.getExpires() > 0) {
final String content = CacheManager.getInstance()
.getFileCache(newUrl);
if (content != null) {
handler.post(new Runnable() {
@Override
public void run() {
requestCallback.onSuccess(content);
}
});
return;
}
}

c）MobileAPI接口返回数据后，将数据存入缓存。

final Response responseInJson = JSON.parseObject(
strResponse, Response.class);
if (responseInJson.hasError()) {
handleNetworkError(responseInJson.getErrorMessage());
} else {
// 把成功获取到的数据记录到缓存
if (urlData.getNetType().equals(REQUEST_GET)
&& urlData.getExpires() > 0) {
CacheManager.getInstance().putFileCache(newUrl,
responseInJson.getResult(),
urlData.getExpires());
}
handler.post(new Runnable() {
@Override
public void run() {
requestCallback.onSuccess(responseInJson
.getResult());
}
});
}

4）CacheManager用于操作读写缓存数据，并判断缓存数据是否过期。缓存中存放的实体就是CacheItem。

5）在App项目中，创建YoungHeartApplication这个Application级别的类，在程序启动时，初始化缓存的目录，如果不存在则创建之。

public class YoungHeartApplication extends Application {
@Override
public void onCreate() {
super.onCreate();
CacheManager.getInstance().initCacheDir();
}
}

2.2.2　强制更新

不光是App端需要记录缓存数据，在MobileAPI的很多接口，其实也需要一样的设计。

如果对于某个接口的数据，MobileAPI缓存了5分钟，App缓存了3分钟，那么最极端的情况是，用户在8分钟内是看不到数据更新的。因此，我们需要在页面上提供一个强制更新的按钮。

我们可以让RemoteService多暴露一个boolean类型的参数，用于判断是否要遵守App端缓存策略，如果是，则在从url.xml中取出UrlData实体后，将其expired强制设置为0，这样就不会执行缓存策略了。

RemoteService的改动如下：

public void invoke(final BaseActivity activity,
final String apiKey,
final List<RequestParameter> params,
final RequestCallback callBack) {
invoke(activity, apiKey, params, callBack, false);
}
public void invoke(final BaseActivity activity,
final String apiKey,
final List<RequestParameter> params,
final RequestCallback callBack,
final boolean forceUpdate) {
final URLData urlData =
UrlConfigManager.findURL(activity, apiKey);
if(forceUpdate) {
// 如果强制更新, 那么就把过期时间强制设置为0
urlData.setExpires(0);
}
HttpRequest request =
activity.getRequestManager().createRequest(
urlData, params, callBack);
DefaultThreadPool.getInstance().execute(request);
}

那么在调用的时候，只需要加一个参数就好：

RemoteService.getInstance().invoke(
this, "getWeatherInfo", params,
weatherCallback);

2.3　MockService

设计App端MockService包括如下几个关键点：

1）对需要Mock数据的MobileAPI接口，通过在url.xml中配置Node节点MockClass属性，来指定要使用那个Mock子类生成的数据：

<Node
Key="getWeatherInfo"
Expires="300"
NetType="get"
MockClass="com.youngheart.mockdata.MockWeatherInfo"
Url="http://www.weather.com.cn/data/sk/101010100.html" />

这里将使用com.mockdata.mockdata包下的MockWeatherInfo子类来解析。

2）我使用了反射工厂来设计MockService。MockService类是基类，它有一个抽象方法getJsonData，用于返回手动生成的Mock数据。

public abstract class MockService {
public abstract String getJsonData();
}

每个要Mock数据的MobileAPI接口，都对应一个继承自MockService的子类，都要实现各自的getJsonData方法，返回不同的JSON数据。

比如在上述url.xml中声明的MockWeatherInfo，它对应的类实现如下：

public class MockWeatherInfo extends MockService {
@Override
public String getJsonData() {
WeatherInfo weather = new WeatherInfo();
weather.setCity("Beijing");
weather.setCityid("10000");
Response response = getSuccessResponse();
response.setResult(JSON.toJSONString(weather));
return JSON.toJSONString(response);
}
}

3）接下来介绍如何实现反射机制。

主要的改造工作在RemoteService类的invoke方法中，根据是否在url.xml中指定了MockClass值来决定，是调用线上MobileAPI还是从本地MockService直接取假数据。

如果MockClass有值，就把这个值反射为一个具体的类，比如MockWeatherInfo，然后调用它的getJsonData方法。

public void invoke(final BaseActivity activity,
final String apiKey,
final List<RequestParameter> params,
final RequestCallback callBack) {
final URLData urlData = UrlConfigManager.findURL(activity, apiKey);
if (urlData.getMockClass() != null) {
try {
MockService mockService = (MockService) Class.forName(
urlData.getMockClass()).newInstance();
String strResponse = mockService.getJsonData();
final Response responseInJson =
JSON.parseObject(strResponse, Response.class);
if (callBack != null) {
if (responseInJson.hasError()) {
callBack.onFail(responseInJson.getErrorMessage());
} else {
callBack.onSuccess(responseInJson.getResult());
}
}
} catch (ClassNotFoundException e) {
e.printStackTrace();
} catch (InstantiationException e) {
e.printStackTrace();
} catch (IllegalAccessException e) {
e.printStackTrace();
}
} else {
HttpRequest request =
activity.getRequestManager().createRequest(
urlData, params, callBack);
DefaultThreadPool.getInstance().execute(request);
}
}

2.4　用户登录

2.4.1　登录成功后的各种场景

首先，贯穿App的，应该有一个User全局变量，在每次登录成功后，会将其isLogin属性设置为true，在退出登录后，则将该属性设置为false。这个User全局变量要支持序列化到本地的功能，这样数据才不会因内存回收而丢失。

其次，登录分为3种情形：

情形1：点击登录按钮，进入登录页面LoginActivity，登录成功后，直接进入个人中心PersonCenterActivity。这种情况最直截了当，一路执行startActivity(intent)就能达到目的。

情形2：在页面A，想要跳转到页面B，并携带一些参数，却发现没有登录，于是先跳转到登录页，登录成功后，再跳转到B页面，同时仍然带着那些参数。

这就主要是setResult(intent,resultCode)发挥作用的时候了，Activity的回调机制这时候派上了用场，如下所示：

btnLogin2.setOnClickListener(new OnClickListener(){
@Override
public void onClick(View v) {
if(User.getInstance().isLogin()) {
gotoNewsActivity();
} else {
Intent intent = new Intent(LoginMainActivity.this,
LoginActivity.class);
intent.putExtra(AppConstants.NeedCallback, true);
startActivityForResult(intent,
LOGIN_REDIRECT_OUTSIDE);
}
}
});

情形3：在页面A，执行某个操作，却发现没有登录，于是跳转到登录页，登录成功后，再回到页面A，继续执行该操作。

处理方式同于情形2，也是使用setResult来完成回调。

btnLogin3.setOnClickListener(new OnClickListener(){
@Override
public void onClick(View v) {
if(User.getInstance().isLogin()) {
changeText();
} else {
Intent intent = new Intent(LoginMainActivity.this,
LoginActivity.class);
intent.putExtra(AppConstants.NeedCallback, true);
startActivityForResult(intent,
LOGIN_REDIRECT_INSIDE);
}
}
});

无论是上述哪种情形，登录页面LoginActivity只有一个，所以要把上面的三个逻辑整合在一起，如下所示：

RequestCallback loginCallback = new AbstractRequestCallback() {
@Override
public void onSuccess(String content) {
UserInfo userInfo = JSON.parseObject(content,
UserInfo.class);
if (userInfo != null) {
User.getInstance().reset();
User.getInstance().setLoginName(userInfo.getLoginName());
User.getInstance().setScore(userInfo.getScore());
User.getInstance().setUserName(userInfo.getUserName());
User.getInstance().setLoginStatus(true);
User.getInstance().save();
}
if(needCallback) {
setResult(Activity.RESULT_OK);
finish();
} else {
Intent intent = new Intent(LoginActivity.this,
PersonCenterActivity.class);
startActivity(intent);
}
}
};

整合的关键在于从上个页面传过来needCallback变量，它决定了是否要回到上个页面。

另一方面，我们看到，在登录成功后，我们会把用户信息存储到User这个全局变量并序列化到本地，这是因为各个模块都有可能使用到用户的信息。其中LoginStatus是关键，接下来的篇幅将着重谈论这个属性。

最后在LoginMainActivity中的onActivityResult回调函数，它负责处理登录后的事情，如下所示：

@Override
protected void onActivityResult(int requestCode,
int resultCode, Intent data) {
if (resultCode != Activity.RESULT_OK) {
return;
}
switch (requestCode) {
case LOGIN_REDIRECT_OUTSIDE:
gotoNewsActivity();
break;
case LOGIN_REDIRECT_INSIDE:
changeText();
break;
default:
break;
}
}

我们看到，对于情形2，当用户在LoginMainActivity点击按钮想跳转到NewsActivity，如果已经登录，就直接跳转过去；否则，先到LoginActivity登录，然后回调LoginMain-Activity的onActivityResult，仍然跳转到NewsActivity。

2.4.2　自动登录

所谓自动登录，就是登录成功后，重启App后用户仍然是登录状态。

最直接的方法是，登录成功后，本地保存用户名和密码。重启App后，检查本地是否有保存用户名和密码，如果有，则将用户名和密码传入到登录接口，模拟用户登录的行为。

但这样就有安全风险了，分析如下：

本地保存用户密码，这种的敏感信息容易被人窃取。要么是在本地文件中看到这些信息，要么是侦听App的网络请求，获取到请求的数据。

所以本地保存密码时，一定要进行加密。对称加密是不可靠的，因为很难确保App的源代码不外泄，所以别有用心的人还是可以根据源码中的对称加密算法，反向把密码推算出来。只有不对称加密才是安全的。

那么登录之后呢？市面上大多数App的逻辑都有问题，它们会在本地保存一个isLogin的全局变量，登录成功后设置为true。接下来涉及用户相关的MobileAPI，只有在这个值为true时才能调用，它们会把UserId传递给服务器。

服务器的解决方案通常也很简陋，它没有任何安全机制，包括用户信息相关的MobileAPI接口，只要接口调用参数中有UserId，它就会去把相关的数据取出并返回。

一种补救措施是，每次调用用户相关的MobileAPI接口时，都需要把UserId和加密后的密码一起传递。而服务器需要对那些用户相关的MobileAPI接口加上安全验证机制，每次请求都检查用户名和密码是否正确。我们要求密码是经过哈希散列算法不对称加密过的，是无法还原的。服务器的验证工作是根据传过来的UserId从数据库中取出相应的密码，然后进行比对。注意，数据库中存放的密码是在注册的时候经过哈希散列算法加密过的。

本地保存用户名和密码的另一个问题是，每次用户启动App，登录页都会一闪而过，因为它要模拟用户登录的行为：假装输入用户名和密码，然后假装点击登录按钮。这样做用户体验很不好倒是其次，关键是这种做法有个无法自圆其说的硬伤——出于安全考虑，我们要修改登录接口，使其除了接收用户名和密码这两个参数外，还必须接收验证码，也就是动态口令.

我们知道，验证码必须是手动输入的，否则就失去了它存在的意义。但是当前这种自动登录的做法，我们只知道用户名和密码，而不知道每次生成的验证码是什么，所以就不能自动登录了。是时候该抛弃这种每次启动就进行一次登录的机制了，其实Web在这一点已经做得很成熟了，那就是Cookie机制。

也有的人管Cookie叫Token，这是用户身份的唯一性标志。

首先，App在登录成功后，会从服务器获取到一个Cookie，这个Cookie存放在Http-Response的header中，如下所示：

Set-Cookie: customer=huangxp; path=/foo; domain=.ibm.com;
expires= Wednesday, 19-OCT-05 23:12:40 GMT; [secure]

我们将其取出来，不用关心它是什么，只要把它存放在本地文件中即可。

我们需要修改App的网络底层，也就是HttpRequest类，分以下几步：

1）每次发起MobileAPI请求时，都要把本地保存的Cookie取出来，放到HttpRequest的header中。还是那句话，不用管Cookie是什么，也不管Cookie是否有值，都应如下操作：

// 添加Cookie到请求头中
addCookie();
// 发送请求
response = httpClient.execute(request);

2）每次接收MobileAPI的相应结果时，都把HttpResponse的header里面的Cookie取出来，覆盖本地保存的Cookie。不用管Cookie有值与否，如下所示：

if (urlData.getNetType().equals(REQUEST_GET)
&& urlData.getExpires() > 0) {
CacheManager.getInstance().putFileCache(newUrl,
responseInJson.getResult(),
urlData.getExpires());
}
handler.post(new Runnable() {
@Override
public void run() {
requestCallback.onSuccess(responseInJson
.getResult());
}
});
// 保存Cookie
saveCookie();

以下是addCookie和saveCookie方法的实现：

public void addCookie() {
List<SerializableCookie> cookieList = null;
Object cookieObj = BaseUtils.restoreObject(cookiePath);
if (cookieObj != null) {
cookieList = (ArrayList<SerializableCookie>) cookieObj;
}
if ((cookieList != null) && (cookieList.size() > 0)) {
final BasicCookieStore cs = new BasicCookieStore();
cs.addCookies(cookieList.toArray(new Cookie[] {}));
httpClient.setCookieStore(cs);
} else {
httpClient.setCookieStore(null);
}
}
public synchronized void saveCookie() {
// 获取本次访问的cookie
final List<Cookie> cookies =
httpClient.getCookieStore().getCookies();
// 将普通cookie转换为可序列化的cookie
List<SerializableCookie> serializableCookies = null;
if ((cookies != null) && (cookies.size() > 0)) {
serializableCookies = new ArrayList<SerializableCookie>();
for (final Cookie c : cookies) {
serializableCookies.add(new SerializableCookie(c));
}
}
}
BaseUtils.saveObject(cookiePath, serializableCookies);
}

而服务器的相应操作，对于来自App的请求：

3）如果是用户信息相关的，则判断HttpRequest中Cookie是否有效，如果有效，就去执行后续的逻辑并返回结果；否则，返回Cookie过期失效的错误信息。

4）如果是用户无关的，则不需要检查HttpRequest中Cookie，直接执行下面的逻辑即可。

此外，还需要注意几个地方，都是些琐碎的工作：

用户注销功能，要把本地保存的Cookie清空。App判断用户是否登录的标志，就是Cookie是否为空。

用户注册功能，一般在注册成功后，都会拿着用户名和密码再调用一次登录接口，这就又和验证码功能冲突了，解决方案是注册成功后直接跳转到登录页面，让用户手动再输入一次。这是从产品层面来解决问题。另一种解决方案是，注册成功后进入个人中心页面，不需要再登录一次，而是把注册和登录接口绑在一起。

对于Cookie过期，App应该跳转到登录页面，让用户手动进行登录。这里有一个比较有挑战性的工作，就是登录成功后，应该返回手动登录之前的那个页面。我们在下一节再细说这个技术。

2.4.3　Cookie过期的统一处理

Cookie不是一直有效的，到了一定时间就会失效。

Cookie过期的表现是，当访问MobileAPI某个接口的时候，就不会返回数据了，代之以Cookie过期的错误消息，这时要统一处理。

我们要求MobileAPI在遇到这种情况时，直接返回以下内容的JSON，其中，errorType固定为1：

{
"isError" : true,
"errorType" : 1,
"errorMessage" : "Cookie失效, 请重新登录",
"result" : ""
}

为此我们修改AndroidLib，使之支持Cookie失效的场景。

1）在RequestCallback中增加一种onCookieExpired回调方法，如下所示：

public interface RequestCallback
{
public void onSuccess(String content);
public void onFail(String errorMessage);
public void onCookieExpired();
}

2）在网络底层对JSON返回结果进行解析，如果发现是属于Cookie过期的错误类型，就直接回调onCookieExpired方法，如下所示：

final Response responseInJson = JSON.parseObject(
strResponse, Response.class);
if (responseInJson.hasError()) {
if(responseInJson.getErrorType() == 1) {
handler.post(new Runnable() {
@Override
public void run() {
requestCallback.onCookieExpired();
}
});
} else {
handleNetworkError(responseInJson.getErrorMessage());
}

我们模拟一种场景，在CookieExpiredActivity页面，访问天气预报这个MobileAPI接口，如果Cookie失效，则弹出对话框，通知用户“Cookie过期，请重新登录”，点击确定按钮，将跳转到登录页。登录成功后，将回到上一个页面，即CookieExpiredActivity。

由于所有页面处理Cookie过期的逻辑都是相同的，所以我们将其封装到基类AppBaseActivity中，放在和onFail方法平级的位置：

public void onCookieExpired() {
dlg.dismiss();
new AlertDialog.Builder(AppBaseActivity.this)
.setTitle("出错啦")
.setMessage("Cookie过期, 请重新登录")
.setPositiveButton("确定",
new DialogInterface.OnClickListener() {
@Override
public void onClick(DialogInterface dialog,
int which) {
Intent intent = new Intent(
AppBaseActivity.this,
LoginActivity.class);
intent.putExtra(AppConstants.NeedCallback,
true);
startActivity(intent);
}
}).show();
}

2.4.4　防止黑客刷库

MobileAPI在发现有同一IP短时间内频繁访问某一个MobileAPI接口时，就直接返回一段HTML5，要求用户输入验证码。

App在接收到这段代码时，就在页面上显示一个浮层，里面一个WebView，显示这个要求用户输入验证码的HTML5。

2.5　HTTP头中的奥妙

2.5.1　HTTP请求

HTTP请求分为HTTPRequest和HTTPResponse两种。但无论哪种请求，都由header和body两部分组成。

1.HTTP Body

Body部分就是存放数据的地方，回顾一下我们在HTTPRequest类中封装的网络请求：

1）对于get形式的HTTPRequest，要发送的数据都以键值对的形式存放在URL上，比如aaa.apik1=va&k2=va。它的Body是空的，如下所示：

if (urlData.getNetType().equals(REQUEST_GET)) {
// 添加参数
final StringBuffer paramBuffer = new StringBuffer();
if ((parameter != null) && (parameter.size() > 0)) {
// 这里要对key进行排序
sortKeys();
for (final RequestParameter p : parameter) {
if (paramBuffer.length() == 0) {
paramBuffer.append(p.getName() + "="
+ BaseUtils.UrlEncodeUnicode(p.getValue()));
} else {
paramBuffer.append("&" + p.getName() + "="
+ BaseUtils.UrlEncodeUnicode(p.getValue()));
}
}
newUrl = url + "?" + paramBuffer.toString();
} else {
newUrl = url;
}
request = new HttpGet(newUrl);
}

2）对于post形式的HTTPRequest，要发送的数据都存在Body里面，也是以键值对的形式，所以代码编写与get情形完全不同，如下所示：

else if (urlData.getNetType().equals(REQUEST_POST)) {
request = new HttpPost(url);
// 添加参数
if ((parameter != null) && (parameter.size() > 0)) {
final List<BasicNameValuePair> list =
new ArrayList<BasicNameValuePair>();
for (final RequestParameter p : parameter) {
list.add(new BasicNameValuePair(
p.getName(), p.getValue()));
}
((HttpPost) request).setEntity(
new UrlEncodedFormEntity(list, HTTP.UTF_8));
}
}

2.HTTP Header

与Body相比，HTTP header就丰富的多了。它由很多键值对（key-value）组成，其中有些key是标准的，兼容于各大浏览器，比如：

accept

accept-language

referrer

user-agent

accept-encoding

此外，我们还可以在MobileAPI端自定义一些键值对，然后要求App在调用MobileAPI时把这些信息传递过来。比如MobileAPI可以定义一个check-value这样的key，然后要求App将AppId（同一公司的不同App编号）、ClientType（Android还是iPhone、iPad）这些值拼接在一起经过MD5加密后，作为这个key的值传递给MobileAPI，然后由MobileAPI再去分析这些数据。

对于App开发人员而言，只要按照MobileAPI的要求，把这些key所需要的值拼接成HTTPRequest头正确传递过去即可。如下所示：

void setHttpHeaders(final HttpUriRequest httpMessage)
{
headers.clear();
headers.put(FrameConstants.ACCEPT_CHARSET, "UTF-8,*");
headers.put(FrameConstants.USER_AGENT,
"Young Heart Android App ");
if ((httpMessage != null) && (headers != null))
{
for (final Entry<String, String> entry : headers.entrySet())
{
if (entry.getKey()!=null)
{
httpMessage.addHeader(entry.getKey(), entry.getValue());
}
}
}
}

我们在组装Cookie之前调用setHttpHeaders方法：

// 添加必要的头信息
setHttpHeaders(request);
// 添加Cookie到请求头中
addCookie();
// 发送请求
response = httpClient.execute(request);

而在返回数据时，也可以从HTTP Response头中把所需要的数据解析出来。Android SDK将其封装成了若干方法以供调用。我们在下面的章节将会看到。

前面我们介绍过Cookie，其实也是HTTP头的一部分。它的作用我们已经见识过了。下面将讨论HTTP头中的另几个重要字段。

2.5.2　时间校准

接下来要介绍的是HTTP Response头中另一重要属性：Date，这个属性中记录了MobileAPI当时的服务器时间。

为什么说这个属性很重要呢？App开发人员经常遇到的一个bug就是，App显示的时间不准，经常会因为时区问题前后差几个小时，而接到用户的投诉。

为了解决这个问题，要从MobileAPI和App同时做一些工作。MobileAPI永远使用UTC时间。包括入参和返回值，都不要使用Date格式，而是减去UTC时间1970年1月1日的差值，这是一个long类型的长整数。

在App端比较麻烦。这里我们只讨论中国，比如国内航班时间、电影上映时间等等，那么我们把MobileAPI返回的long型时间转换为GMT8时区的时间就万事大吉了——只需要额外加8个小时。无论使用的人身在哪个时区，他们看到的都应该是一个时间，也就是GMT8的时间。

由于App本地时间会不准，比如前后差十几分钟，又比如设置了GMT9的时区，这样在取本地时间的时候，就会差一个小时。遇到这种情况，就要依赖于HTTP Response头的Date属性了。

每调用一次MobileAPI，就取出HTTP Response头的Date值，转换为GMT时间后，再减去本地取出的时间，得到一个差值delta。这个值可能是因为手机时间不准而差出来的那十几分钟，也可能是因为时区不同导致的1个小时差值。我们将这个delta值保存下来。那么每当取本地当前时间的时候，再额外加上这个delta差值，就得到了服务器GMT8的时间，就做到了任何人看到的时间是一样的。

因为App会频繁调用MobileAPI，所以这个delta值也会频繁更新，不用担心长期不调用MobileAPI而导致的这个delta值不太准的问题。

接下来我们修改AndroidLib框架，以支持上述的这些功能。

1）首先，在HTTPRequest类提供一个用于更新本地时间和服务器时间差值的方法updateDeltaBetweenServerAndClientTime，如下所示，由于我们在这里补上了UTC和GMT8相差的那8个小时，所以App其他地方不再需要考虑时差的问题，如下所示：

void updateDeltaBetweenServerAndClientTime() {
if (response != null) {
final Header header = response.getLastHeader("Date");
if (header != null) {
final String strServerDate = header.getValue();
try {
if ((strServerDate != null) && !strServerDate.equals("")) {
final SimpleDateFormat sdf = new SimpleDateFormat(
"EEE, d MMM yyyy HH:mm:ss z", Locale.ENGLISH);
TimeZone.setDefault(TimeZone.getTimeZone("GMT+8"));
Date serverDateUAT = sdf.parse(strServerDate);
deltaBetweenServerAndClientTime = serverDateUAT
.getTime()
+ 8 * 60 * 60 * 1000
- System.currentTimeMillis();
}
} catch (java.text.ParseException e) {
e.printStackTrace();
}
}
}
}

我们会在发起MobileAPI网络请求得到响应结果后，执行该方法，更新这个差值：

// 发送请求
response = httpClient.execute(request);
// 获取状态
final int statusCode = response.getStatusLine().getStatusCode();
// 设置回调函数, 但如果requestCallback, 说明不需要回调, 不需要知道返回结果
if ((requestCallback != null)) {
if (statusCode == HttpStatus.SC_OK) {
// 更新服务器时间和本地时间的差值
updateDeltaBetweenServerAndClientTime();

因为我们的App会频繁的调用MobileAPI，所以为了避免频繁读写文件，我们没有将deltaBetweenServerAndClientTime存到本地文件，而是放在了内存中，当作一个全局变量来使用。

2）我们把这个deltaBetweenServerAndClientTime方法暴露出来，供外界调用：

public static Date getServerTime() {
return new Date(System.currentTimeMillis()
+ deltaBetweenServerAndClientTime);
}

现在我们就可以模拟一个场景了。我把手机的时间改成任意一个值，然后再进入到WeatherByFastJsonActivity页面，因为页面加载的时候会调用MobileAPI获取天气的接口，所以本地会保存一个deltaBetweenServerAndClientTime差值。点击WeatherByFastJsonActivity页面上的“获取服务器时间”按钮，会因为我调用了AndroidLib中封装好的getServerTime方法，而弹出GMT8的当前时间：

btnShowTime.setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {
String strCurrentTime = Utils.getServerTime().toString();
new AlertDialog.Builder(WeatherByFastJsonActivity.this)
.setTitle("当前时间是：").setMessage(strCurrentTime)
.setPositiveButton("确定", null).show();
}
});

2.5.3　开启gzip压缩

HTTP协议上的gzip编码是一种用来改进Web应用程序性能的技术。大流量的Web站点常常使用gzip压缩技术来减少传输量的大小，减少传输量大小有两个明显的好处，一是可以减少存储空间，二是通过网络传输时，可以减少传输的时间。

使用gzip的流程如下：

1）在App发起请求时，在HTTPRequest头中，添加要求支持gzip的key-value，这里的key是Accept-Encoding，value是gzip。如下所示，我们需要修改setHttpHeaders方法：

void setHttpHeaders(final HttpUriRequest httpMessage) {
headers.clear();
headers.put(FrameConstants.ACCEPT_CHARSET, "UTF-8,*");
headers.put(FrameConstants.USER_AGENT, "Young Heart Android App ");
headers.put(FrameConstants.ACCEPT_ENCODING, "gzip");
if ((httpMessage != null) && (headers != null)) {
for (final Entry<String, String> entry : headers.entrySet()) {
if (entry.getKey() != null) {
httpMessage.addHeader(entry.getKey(), entry.getValue());
}
}
}
}

2）MobileAPI的逻辑是，检查HTTP请求头中的Accept-Encoding是否有gzip值，如果有，就会执行gzip压缩。

如果执行了gzip压缩，那么在返回值也就是HTTPResponse的头中，有一个content-encoding字段，会带有gzip的值；否则，就没有这个值。

3）App检查HTTPResponse头中的content-encoding字段是否包含gzip值，这个值的有无，导致了App解析HTTPResponse的姿势不同，如下所示值，这个值的有无，导致了App解析HTTPResponse的姿势不同，如下所示（以下代码参见HTTPRequest这个类）：

String strResponse = "";
if ((response.getEntity().getContentEncoding() != null)
&& (response.getEntity().getContentEncoding()
.getValue() != null)) {
if (response.getEntity().getContentEncoding()
.getValue().contains("gzip")) {
final InputStream in = response.getEntity()
.getContent();
final InputStream is = new GZIPInputStream(in);
strResponse = HttpRequest.inputStreamToString(is);
is.close();
} else {
response.getEntity().writeTo(content);
strResponse = new String(content.toByteArray()).trim();
}
} else {
response.getEntity().writeTo(content);
strResponse = new String(content.toByteArray()).trim();
}