转载请标明出处：一片枫叶的专栏
上一篇文章中我们讲解了android app中的升级更新操作，app的升级更新操作算是App的标配了，升级操作就是获取App的升级信息，更新操作是下载，安装，更新app，其中我们既可以使用app store获取应用的升级信息，也可以在应用内通过请求本地服务器获取应用的升级信息，并通过与本地app的版本号对比判断应用是否需要升级。
升级信息是app更新的基础，只有我们的app的升级信息指明需要更新，我们才可以开始后续的更新操作–也就是下载安装更新app。这里强调一点的是应用的升级操作分为普通的升级和强制升级两种，普通的升级操作就是完成一次对app的更新操作，而强制更新是在线上的app出现bug 的时候一种强制用户升级的手段，用户体验不太好，所以一般不太建议使用这种方式升级用户的app。
更多关于app升级更新的信息，可参考我的：android产品研发（十四）–>App升级与更新
本文将讲解android中数据传输中需要了解的数据序列化方面的知识，我们知道android开发过程中不同Activity之间传输数据可以通过Intent对象的put**方法传递，对于java的八大基本数据类型(char int float double long short boolean byte)传递是没有问题的，但是如果传递比较复杂的对象类型（比如对象，比如集合等），那么就可能存在问题，而这时候也就引入了数据序列化的概念。
序列化的定义：
这里我们先看一下呢序列化在百科上的定义
序列化 (Serialization)将对象的状态信息转换为可以存储或传输的形式的过程。在序列化期间，对象将其当前状态写入到临时或持久性存储区。以后，可以通过从存储区中读取或反序列化对象的状态，重新创建该对象。
简单来说就是我们的数据在传输的时候需要将信息转化为可以传输的数据，然后在传输的目标方能够反序列化将数据还原回来，这里的将对象状态信息转换为可传输数据的过程就是序列化，将可传输的数据逆还原为对象的过程就是反序列化。
为什么需要序列化：
知道前面的序列化定义，内存对象什么需要实现序列化呢？
永久性保存对象，保存对象的字节序列到本地文件。
通过序列化对象在网络中传递对象。
通过序列化对象在进程间传递对象。
实现序列化的两种方式：
那么我们如何实现序列化的操作呢？在android开发中我们实现序列化有两种方式：
实现Serializable接口
实现parcelable接口
两种序列化方式的区别：
都知道在android studio中序列化有两种方式：serializable与parcelable。那么这两种实现序列化的方式有什么区别呢？下面是这两种实现序列化方式的区别：
Serializeble是java的序列化方式，Parcelable是android特有的序列化方式；
在使用内存的时候，Parcelable比Serializable性能高，所以推荐使用Parcelable。
Serializable在序列化的时候会产生大量的临时变量，从而引起频繁的GC。
Parcelable不能使用在要将数据存储在磁盘上的情况，因为Parcelable不能很好的保证数据的持续性在外界有变化的情况下。尽管Serializable效率低点， 也不提倡用，但在这种情况下，还是建议你用Serializable。
最后还有一点就是Serializeble序列化的方式比较简单，直接集成一个接口就好了，而parcelable方式比较复杂，不仅需要集成Parcelable接口还需要重写里面的方法。
对象实现序列化的实例：
通过实现Serializable接口实现序列化：
上面介绍了那么多概念上的知识，下面我们就具体看一下如何通过这两种方式实现序列化，我们首先看一下如何通过实现Serializable接口实现序列化，通过实现Serializable接口实现序列化，只需要简单的实现Serialiizable接口即可。通过实现Serializable接口就相当于标记类型为序列化了，不需要做其他的操作了。
/**
* Created by aaron on 16/6/29.
*/
public class Person implements Serializable{
private int age;
private String name;
private String address;
public int getAge() {
return age;
}
public void setAge(int age) {
this.age = age;
}
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
public String getAddress() {
return address;
}
public void setAddress(String address) {
this.address = address;
}
}可以发现我们定义了一个普通的实体Person类，并设置了三个成员属性以及各自的set，get方法，然后我们就只是简单的实现了Serializable接口就相当于将该类序列化了，当我们在程序中传输该类型的对象的时候就没有问题了。
通过实现Parcelable接口实现序列化：
然后我们在看一下通过实现Parcelable接口来实现序列化的方式，通过实现Parcelable接口实现序列化相当于实现Serialiable接口稍微复杂一些，因为其需要实现一些特定的方法，下面我们还是以我们定义的Person类为例子，看一下如果是实现Parcelable接口具体是如何实现的：
/**
* Created by aaron on 16/6/29.
*/
public class Person implements Parcelable{
private int age;
private String name;
private String address;
public int getAge() {
return age;
}
public void setAge(int age) {
this.age = age;
}
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
public String getAddress() {
return address;
}
public void setAddress(String address) {
this.address = address;
}
@Override
public int describeContents() {
return 0;
}
@Override
public void writeToParcel(Parcel dest, int flags) {
dest.writeInt(this.age);
dest.writeString(this.name);
dest.writeString(this.address);
}
public Person() {
}
protected Person(Parcel in) {
this.age = in.readInt();
this.name = in.readString();
this.address = in.readString();
}
public static final Creator CREATOR = new Creator() {
@Override
public Person createFromParcel(Parcel source) {
return new Person(source);
}
@Override
public Person[] newArray(int size) {
return new Person[size];
}
};
}可以发现当我们通过实现Parcelable接口实现序列化还需要重写里面的成员方法，并且这些成员方法的写法都比较固定。
实现Parcelable序列化的android studio插件：
顺便说一下最近发现一个比较不错的Parcelable序列化插件。下面就来看一下如何安装使用该插件。
- 打开android studio –> settings –> Plugins –> 搜索Parcelable –> Install –> Restart，这样安装好了Parcelable插件；
- 然后在源文件中右键 –> Generate… –> Parcelable
- 点击Parcelable之后可以看到，源文件中已经实现了Parcelable接口，并重写了相应的方法：
这样我们就安装好Parcelable插件了，然后当我们执行Parcelable操作的时候就重写了Parcelable接口的相应序列化方法了。
总结：
可以通过实现Serializable和Parcelable接口的方式实现序列化
实现Serializable接口是java中实现序列化的方式，而实现Parcelable是android中特有的实现序列化的方式，更适合android环境
实现Serializable接口只需要实现该接口即可无需其他操作，而实现Parcelable接口需要重写相应的方法
android studio中有实现Parcelable接口的相应插件，可安装该插件很方便的实现Parcelable接口，实现序列化
另外对产品研发技术，技巧，实践方面感兴趣的同学可以参考我的：
android产品研发（一）–>实用开发规范
android产品研发（二）–>启动页优化
android产品研发（三）–>基类Activity
android产品研发（四）–>减小Apk大小
android产品研发（五）–>多渠道打包
android产品研发（六）–>Apk混淆
android产品研发（七）–>Apk热修复
android产品研发（八）–>App数据统计
android产品研发（九）–>App网络传输协议
android产品研发（十）–>不使用静态变量保存数据
android产品研发（十一）–>应用内跳转scheme协议
android产品研发（十二）–>App长连接实现
android产品研发（十三）–>App轮训操作
android产品研发（十四）–>App升级与更新
本文以同步至github中：github.com/yipianfengy…，欢迎star和follow
转载请标明出处：一片枫叶的专栏
上一篇文章中我们讲解了android app中的轮询操作，讲解的内容主要包括：我们在App中使用轮询操作的情景，作用以及实现方式等。一般而言我们使用轮询操作都是通过定时任务的形式请求服务器并更新用户界面，轮询操作都有一定的使用生命周期，即在一定的页面中启动轮询操作，然后在特定的情况下关闭轮询操作，这点需要我们尤为注意，我们还介绍了使用Timer和Handler实现轮询操作的实例，更多关于App中轮询操作的信息，可参考我的：android产品研发（十三）–>App轮询操作
本文将讲解app的升级与更新。一般而言用户使用App的时候升级提醒有两种方式获得：
一种是通过App Store获取
一种是打开应用之后提醒用户更新升级
而更新操作一般是在用户点击了升级按钮之后开始执行的，这里的升级操作也分为两种形式：
app升级操作：
在App Store中升级需要为App Store上传新版App，我们在新版本完成之后都会上传到App Store中，不同的应用市场审核的时间不同，一般除了第一次上传时间较长之外，其余的审核都是挺快的，一般不会超过半天（不排除例外情况奥），在审核完成之后就相当于完成了这个应用市场的发布了，也就是发布上线了。这时候如果用户安装了这个应用市场，那么就能看到我们的App有新版本的升级提醒了。
除了可以在应用市场升级，我们还可以在应用内升级，在应用内升级主要是通过调用服务器端接口获取应用的升级信息，然后通过获取的服务器升级应用信息与本地的App版本比对，若服务器下发的最新的App版本高于本地的版本号，则说明有新版本发布，那么我们就可以执行更新操作了，否则忽略掉即可。
应用内升级其实已经有好多第三方的SDK了，常见的友盟，百度App开发工具包都已经集成了升级的功能，部分SDK厂商还提供增量更新的功能。增量更新的内容不是我们这里的讨论重点，想了解更多增量更新的内容可参考：浅谈Android增量升级
这里我们先简单介绍一下友盟的App升级功能，友盟其实已经有了App升级的API，我们只需要简单的调用即可。
/**
* 请求友盟更新API，判断是否弹出更新弹窗
*/
public static void updateVersion(final Activity mContext, final MainActivity.UpdateCallback updateCallback, final boolean isShow) {
UmengUpdateAgent.setUpdateListener(new UmengUpdateListener() {
@Override
public void onUpdateReturned(int updateStatus, UpdateResponse updateInfo) {
switch (updateStatus) {
case UpdateStatus.Yes:
try {
String value = MobclickAgent.getConfigParams(mContext, "FORCE_UPDATE_MIXVERSION");
if (value != null && !value.trim().equals("")) {
int versionCode = Config.changeVersionNameToCode(value);
if (versionCode != 0) {
String localVersionName = getVersionName(mContext);
int localVersionCode = Config.changeVersionNameToCode(localVersionName);
if (localVersionCode <= versioncode)="" {="" updatecallback.onupdatesuccess(updateinfo);="" }="" else="" umengupdateagent.setupdateautopopup(true);="" umengupdateagent.showupdatedialog(mcontext,="" updateinfo);="" catch="" (exception="" e)="" e.printstacktrace();="" break;="" case="" updatestatus.no:="" if="" (isshow)="" config.showtoast(mcontext,="" "您当前使用的友友用车已是最新版本");="" });="" umengupdateagent.setupdateautopopup(false);="" umengupdateagent.forceupdate(mcontext);="" umengupdateagent.setchannel(channelutil.getchannel(mcontext));="" }<="" code="">以上是友盟的升级API，在调用之前需要先继承友盟的SDK，这样经过调用之后我们就可以通过友盟实现更新接口的提示功能了，默认的友盟提供了静默安装，更新提示弹窗，强制更新等几种，可以根据自身App的需求来确定更新的方式。
如果不喜欢使用第三方的更新方式，我们也可以通过调用服务器接口的方式实现自己的更新弹窗提示，主要的逻辑也是通过判断服务器下发的最新App版本号与本地版本号对比，若服务器端的App版本号大于本地的App版本号，则说明当前App不是最新的版本，需要升级，这里我们简单看一下友友用车中自定义的更新接口实现：
/**
* 检测App是否需要更新
*
* @param mContext
* @param isShow 若不需要更新是否需要弹出文案
*/
public static void queryAppBaseVersionInfo(final Activity mContext, final boolean isOneUpdate, final boolean isShow) {
try {
if (!Config.isNetworkConnected(mContext)) {
dismissProgress(isShow);
return;
}
if (isQueryAppUpdated && isOneUpdate) {
return;
}
L.i("开始调用请求是否需要版本更新的接口....");
ExtInterface.QueryAppBaseVersionInfoNL.Request.Builder request = ExtInterface.QueryAppBaseVersionInfoNL.Request.newBuilder();
request.setClientChannel(CHANNEL_ANDROID);
NetworkTask task = new NetworkTask(Cmd.CmdCode.QueryAppBaseVersionInfo_VALUE);
task.setBusiData(request.build().toByteArray());
NetworkUtils.executeNetwork(task, new HttpResponse.NetWorkResponse() {
@Override
public void onSuccessResponse(UUResponseData responseData) {
if (responseData.getRet() == 0) {
try {
isQueryAppUpdated = true;
ExtInterface.QueryAppBaseVersionInfoNL.Response response = ExtInterface.QueryAppBaseVersionInfoNL.Response.parseFrom(responseData.getBusiData());
if (response.getRet() == 0) {
L.i("请求检测App是否更新接口成功，开始解析返回结果");
parserUpdateResule(mContext, response, isShow);
} else {
if (isShow) {
showDefaultNetworkSnackBar(mContext);
}
}
} catch (InvalidProtocolBufferException e) {
e.printStackTrace();
if (isShow) {
showDefaultNetworkSnackBar(mContext);
}
}
}
}
@Override
public void onError(VolleyError errorResponse) {
L.e("请求检测更新接口失败....");
if (isShow) {
showDefaultNetworkSnackBar(mContext);
}
}
@Override
public void networkFinish() {
L.i("请求检测更新接口完成....");
dismissProgress(isShow);
}
});
} catch (Exception e) {
e.printStackTrace();
}
}该接口只会在App打开时调用一次，判断App是否需要更新，然后在请求服务器成功之后，会解析请求结果，我们继续看一下我们的解析逻辑：
/**
* 解析更新检查结果
*
* @param response
*/
private static void parserUpdateResule(Activity mContext, ExtInterface.QueryAppBaseVersionInfoNL.Response response, boolean isShow) {
if (mContext == null) {
return;
}
ExtInterface.AppBaseVersionInfo appBaseVersionInfo = response.getAppBaseVersionInfo();
if (appBaseVersionInfo.getIsDel() == ENEFFECT) {
return;
}
String updateVersionCode = appBaseVersionInfo.getVersionCode();
int updateCode = changeVersionNameToCode(updateVersionCode);
int localCode = changeVersionNameToCode(VersionUtils.getVersionName(mContext));
L.i("本地版本号：" + localCode + " " + VersionUtils.getVersionName(mContext) + " 远程版本号：" + updateCode
+ " " + updateVersionCode);
if (localCode < updateCode) {
L.i("开始显示更新弹窗...");
showUpdateDialog(mContext, appBaseVersionInfo);
}
else {
if (isShow) {
Config.showToast(mContext, mContext.getResources().getString(R.string.about_new));
}
}
}解析更新接口信息的时候，会判断App的更新操作是普通更新还是强制更新，若是强制更新的话，则没有取消按钮，并且更新弹窗不可关闭。若是普通的更新的话则有暂不更新按钮，点击暂不更新更新弹窗会取消，但是当下次打开App的时候，弹窗提醒还是会弹窗。
普通更新包含暂不更新和立即更新两个按钮操作：
强制更新只有立即更新按钮，弹窗不可取消：
app更新操作：
app的更新操作就是下载App并安装了，下面我们还是分两部分看，应用市场的更新与应用内更新
在应用市场中更新App很简单就是执行简单的下载操作，然后顺着App的提醒，一步步安装即可，这里没有什么需要注意的地方。
应用内更新操作主要是当用户点击了更新按钮之后执行的，下载，安装等逻辑，下面我们看一下友友用车应用内更新的实践。
应用内更新主要包含了：普通更新和强制更新两种，其中普通更新弹窗可以选择更新也可以选择忽略，而强制更新只能选择更新，并且更新弹窗不可取消。
下面的代码是执行下载操作的核心逻辑：
/**
* 开始执行下载动作
*/
private static void doDownLoad(final Activity mContext, String downloadUrl, final String actionButtonMsg, final boolean isFocusUpdate) {
if (isFocusUpdate) {
DownLoadDialog.updateRela.setVisibility(View.VISIBLE);
DownLoadDialog.progressBar.setProgress(0);
DownLoadDialog.progressBar.start();
DownLoadDialog.updatePercent.setText("0%");
DownLoadDialog.materialDialog.getPositiveButton().setEnabled(false);
DownLoadDialog.materialDialog.getPositiveButton().setText("下载中");
}
Config.showToast(mContext, "开始下载安装包.......");
doDeleteDownApk(mContext);
L.i("安装包下载地址：" + downloadUrl);
DownloadManager.getInstance().cancelAll();
DownloadManager.downloadId = DownloadManager.getInstance().add(DownloadManager.getDownLoadRequest(mContext, downloadUrl, new DownloadStatusListenerV1() {
@Override
public void onDownloadComplete(DownloadRequest downloadRequest) {
L.i("onDownloadComplete_____...");
showPositiveText(false, actionButtonMsg);
if (isFocusUpdate) {
DownLoadDialog.updatePercent.setText("100%");
DownLoadDialog.progressBar.stop();
} else {
String title = "正在下载友友用车...";
String content = "下载成功";
DownloadNotification.showNotification(mContext, title, content, DownloadNotification.notofyId);
UUApp.notificationManager.cancel(DownloadNotification.notofyId);
}
doInstallApk(mContext);
UUApp.getInstance().exit();
}
@Override
public void onDownloadFailed(DownloadRequest downloadRequest, int errorCode, String errorMessage) {
L.i("onDownloadFiled______...");
L.i("errorMessage:" + errorMessage);
showPositiveText(false, actionButtonMsg);
if (isFocusUpdate) {
DownLoadDialog.updatePercent.setText("更新失败");
} else {
String title = "正在下载友友用车...";
String content = "下载失败";
DownloadNotification.showNotification(mContext, title, content, DownloadNotification.notofyId);
}
}
@Override
public void onProgress(DownloadRequest downloadRequest, long totalBytes, long downloadedBytes, int progress) {
if (lastProgress != progress) {
lastProgress = progress;
L.i("onProgress_____progress:" + progress + " totalBytes:" + totalBytes + " downloadedBytes:" + downloadedBytes);
showPositiveText(true, actionButtonMsg);
if (isFocusUpdate) {
String content = downloadedBytes * 100 / totalBytes + "%";
float result = progress / (float)100.00;
DownLoadDialog.progressBar.setProgress(result);
DownLoadDialog.updatePercent.setText(content);
} else {
String title = "正在下载友友用车...";
String content = downloadedBytes * 100 / totalBytes + "%";
DownloadNotification.showNotification(mContext, title, content, DownloadNotification.notofyId);
}
}
}
}));
}这里的下载操作包含了三个回调方法：
onDownloadComplete()
onDownloadFailed()
onProgress()
其中onDownlaodComplete方法在下载完成时回调，onDownloadFailed方法在下载失败是回调，而onProgress方法则用于刷新下载进程，我们在onProcess方法中更新通知栏下载进度，具体我们可以看一下更新通知栏消息的方法：
/**
* 更新通知栏显示
* @param title
* @param content
* @param notifyId
*/
public static void showNotification(Activity mContext, String title, String content, int notifyId) {
NotificationCompat.Builder mNotifyBuilder = new NotificationCompat.Builder(mContext)
.setSmallIcon(R.mipmap.icon)
.setContentTitle(title)
.setContentText(content)
.setSmallIcon(android.R.drawable.stat_sys_download);
Notification notification = mNotifyBuilder.build();
UUApp.notificationManager.notify(notifyId, notification);
}而在onDownloadFailed方法中，执行的代码逻辑是提示用户下载失败，
而在onDownloadComplete方法中，执行安装下载apk文件的操作，我们可以继续看一下我们是如何执行安装逻辑的。
/**
* 执行安装apk文件
*/
private static void doInstallApk(Activity mContext) {
Intent intent = new Intent(Intent.ACTION_VIEW);
intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
intent.setDataAndType(Uri.fromFile(new File(DownloadManager.getApkPath(mContext))),
"application/vnd.android.package-archive");
mContext.startActivity(intent);
}这段代码会调用android的安装apk程序，这样我们就执行了下载文件的安装操作，不同的手机安装程序及展示界面略有不同。
总结：
App升级操作分为两种，在应用市场提示升级和在应用内提示升级，而在应用内提示升级可以继承第三方升级API（如：友盟），也可以自己实现；
应用升级的提示主要逻辑是根据服务器端的APK版本号与本地的应用版本号对比，若服务器端的应用版本号高于本地版本号，则说明应用需要升级；
应用升级可以分为普通升级和强制升级两种，一般不太建议使用强制升级（用户体验很差），除非是一些严重的线上bug；
App的更新操作包含下载与安装两部分，下载操作时可以选择继承第三方服务，也可以自己实现。
另外对产品研发技术，技巧，实践方面感兴趣的同学可以参考我的：
android产品研发（一）–>实用开发规范
android产品研发（二）–>启动页优化
android产品研发（三）–>基类Activity
android产品研发（四）–>减小Apk大小
android产品研发（五）–>多渠道打包
android产品研发（六）–>Apk混淆
android产品研发（七）–>Apk热修复
android产品研发（八）–>App数据统计
android产品研发（九）–>App网络传输协议
android产品研发（十）–>不使用静态变量保存数据
android产品研发（十一）–>应用内跳转scheme协议
android产品研发（十二）–>App长连接实现
android产品研发（十三）–>App轮询操作
本文以同步至github中：github.com/yipianfengy…，欢迎star和follow
转载请标明出处：一片枫叶的专栏
上一篇文章中我们讲解了android app实现长连接的几种方式，各自的优缺点以及具体的实现，一般而言使用第三方的推送服务已经可以满足了基本的业务需求，当然了若是对技术有追求的可以通过NIO或者是MINA实现自身的长连接服务，但是自己实现的长连接服务一来比较复杂耗时比较多，而且可能过程中有许多坑要填，一般而言推荐使用第三方的推送服务，稳定简单，具体管理长连接部分的模块可参考：android产品研发（十二）–>App长连接实现。
而本文将讲解app端的轮询请求服务，一般而言我们经常将轮询操作用于请求服务器。比如某一个页面我们有定时任务需要时时的从服务器获取更新信息并显示，比如当长连接断掉之后我们可能需要启动轮询请求作为长连接的补充等，所以这时候就用到了轮询服务。
什么是轮询请求
在说明我们轮询请求之前，这里先说明一下什么叫轮询请求，我的理解就是App端每隔一定的时间重复请求的操作就叫做轮询请求，比如：App端每隔一段时间上报一次定位信息，App端每隔一段时间拉去一次用户状态等，这些应该都是轮询请求，那么前一篇我们讲了App端的长连接，为什么我们有了长连接之后还需要轮询操作呢？
这是因为我们的长连接并不是稳定的可靠的，而我们执行轮询操作的时候一般都是要稳定的网络请求，而且轮询操作一般都是有生命周期的，即在一定的生命周期内执行轮询操作，而我们的长连接一般都是整个进程生命周期的，所以从这方面讲也不太适合。
轮询请求实践
与长连接相关的轮询请求
- 上一篇我们在讲解长连接的时候说过长连接有可能会断，而这时候在长连接断的时候我们就需要启动一个轮询服务，它作为长连接的补充。
/**
* 启动轮询服务
*/
public void startLoopService() {
if (!LoopService.isServiceRuning) {
if (UserConfig.isPassLogined()) {
if (MinaLongConnectManager.session != null && MinaLongConnectManager.session.isConnected()) {
LoopService.quitLoopService(context);
return;
}
LoopService.startLoopService(context);
} else {
LoopService.quitLoopService(context);
}
}
}这里就是我们执行轮询服务的操作代码，其作用就是启动了一个轮询service（即轮询服务），然后在轮询服务中执行具体的轮询请求，既然这样我们就具体看一下这个service的代码逻辑。
/**
* 长连接异常时启动服务，长连接恢复时关闭服务
*/
public class LoopService extends Service {
public static final String ACTION = "com.youyou.uuelectric.renter.Service.LoopService";
/**
* 客户端执行轮询的时间间隔，该值由StartQueryInterface接口返回，默认设置为30s
*/
public static int LOOP_INTERVAL_SECS = 30;
/**
* 轮询时间间隔(MLOOP_INTERVAL_SECS 这个时间间隔变量有服务器下发，此时轮询服务的场景与逻辑与定义时发生变化，涉及到IOS端，因此采用自己定义的常量在客户端写死时间间隔)
*/
public static int MLOOP_INTERVAL_SECS = 30;
/**
* 当前服务是否正在执行
*/
public static boolean isServiceRuning = false;
/**
* 定时任务工具类
*/
public static Timer timer = new Timer();
private static Context context;
public LoopService() {
isServiceRuning = false;
}
/**
* 启动轮询服务
*/
public static void startLoopService(Context context) {
if (context == null)
return;
quitLoopService(context);
L.i("开启轮询服务，轮询间隔：" + MLOOP_INTERVAL_SECS + "s");
AlarmManager manager = (AlarmManager) context.getApplicationContext().getSystemService(Context.ALARM_SERVICE);
Intent intent = new Intent(context.getApplicationContext(), LoopService.class);
intent.setAction(LoopService.ACTION);
PendingIntent pendingIntent = PendingIntent.getService(context.getApplicationContext(), 1, intent, PendingIntent.FLAG_UPDATE_CURRENT);
/**
* 闹钟的第一次执行时间，以毫秒为单位，可以自定义时间，不过一般使用当前时间。需要注意的是，本属性与第一个属性（type）密切相关，
* 如果第一个参数对应的闹钟使用的是相对时间（ELAPSED_REALTIME和ELAPSED_REALTIME_WAKEUP），那么本属性就得使用相对时间（相对于系统启动时间来说），
* 比如当前时间就表示为：SystemClock.elapsedRealtime()；
* 如果第一个参数对应的闹钟使用的是绝对时间（RTC、RTC_WAKEUP、POWER_OFF_WAKEUP），那么本属性就得使用绝对时间，
* 比如当前时间就表示为：System.currentTimeMillis()。
*/
manager.setRepeating(AlarmManager.RTC_WAKEUP, System.currentTimeMillis(), MLOOP_INTERVAL_SECS * 1000, pendingIntent);
}
/**
* 停止轮询服务
*/
public static void quitLoopService(Context context) {
if (context == null)
return;
L.i("关闭轮询闹钟服务...");
AlarmManager manager = (AlarmManager) context.getApplicationContext().getSystemService(Context.ALARM_SERVICE);
Intent intent = new Intent(context.getApplicationContext(), LoopService.class);
intent.setAction(LoopService.ACTION);
PendingIntent pendingIntent = PendingIntent.getService(context.getApplicationContext(), 1, intent, PendingIntent.FLAG_UPDATE_CURRENT);
manager.cancel(pendingIntent);
L.i("关闭轮询服务...");
context.stopService(intent);
}
@Override
public void onCreate() {
super.onCreate();
context = getApplicationContext();
}
@Override
public int onStartCommand(Intent intent, int flags, int startId) {
L.i("开始执行轮询服务... \n 判断当前用户是否已登录...");
if (UserConfig.isPassLogined()) {
L.i("当前用户已登录... \n 判断长连接是否已经连接...");
if (MinaLongConnectManager.session != null && MinaLongConnectManager.session.isConnected()) {
L.i("长连接已恢复连接，退出轮询服务...");
quitLoopService(context);
} else {
if (isServiceRuning) {
return START_STICKY;
}
startLoop();
}
} else {
L.i("用户已退出登录，关闭轮询服务...");
quitLoopService(context);
}
return START_STICKY;
}
@Override
public void onDestroy() {
super.onDestroy();
L.i("轮询服务退出，执行onDestory()方法，inServiceRuning赋值false");
isServiceRuning = false;
timer.cancel();
timer = new Timer();
}
@Override
public IBinder onBind(Intent intent) {
throw new UnsupportedOperationException("Not yet implemented");
}
/**
* 启动轮询拉去消息
*/
private void startLoop() {
if (timer == null) {
timer = new Timer();
}
timer.schedule(new TimerTask() {
@Override
public void run() {
isServiceRuning = true;
L.i("长连接未恢复连接，执行轮询操作... \n 轮询服务中请求getInstance接口...");
LoopRequest.getInstance(context).sendLoopRequest();
}
}, 0, MLOOP_INTERVAL_SECS * 1000);
}
}可以发现这里的service轮询服务的代码量还是比较多的，但是轮询服务请求代码注释已经很详细了，所以就不做过多的说明，需要说明的是其核心就是通过Timer对象每个一段时间执行一次网络请求。具体的网络请求代码：
L.i("长连接未恢复连接，执行轮询操作... \n 轮询服务中请求getInstance接口...")
LoopRequest.getInstance(context).sendLoopRequest()这里的轮询服务请求核心逻辑：当长连接出现异常时，启动轮询服务，并通过Timer对象每隔一定时间拉取服务器状态，当长连接恢复时，关闭轮询服务。这就是我们与长连接有关的轮询服务的代码执行逻辑，看完这部分之后我们再看一下与页面相关的轮询请求的执行逻辑。
与页面相关的轮询请求
- 与页面相关的轮询请求
我们的App中当用户停留在某一个页面的时候我们可能需要定时的拉取用户状态，这时候也需要使用轮询请求拉取服务器状态，当用户离开该页面的时候关闭轮询服务请求。
这里我们看一下我们产品当前行程页面的轮询操作，用于轮询请求当前用户的车辆里程，费用，用时等信息，具体可参考下图：
其实在当前Fragment页面有一个定时的拉去订单信息的轮询请求，下面我们具体看一下这个定时请求的执行逻辑：
/**
* TimerTask对象，主要用于定时拉去服务器信息
*/
public class Task extends TimerTask {
@Override
public void run() {
L.i("开始执行执行timer定时任务...");
handler.post(new Runnable() {
@Override
public void run() {
isFirstGetData = false;
getData(true);
}
});
}
}而这里的getData方法就是拉去服务器状态的方法，这里不做过多的解释，当用户退出这个页面的时候需要清除这里的轮询操作。所以在Fragment的onDesctoryView方法中执行了清除timerTask的操作。
@Override
public void onDestroyView() {
super.onDestroyView();
...
if (timer != null) {
timer.cancel();
timer = null;
}
if (timerTask != null) {
timerTask.cancel();
timerTask = null;
}
...
}这样当用户打开这个页面的时候初始化TimerTask对象，每个一分钟请求一次服务器拉取订单信息并更新UI，当用户离开页面的时候清除TimerTask对象，即取消轮询请求操作。可以发现上面我们看到的与长连接和页面相关的轮询请求服务都是通过timer对象的定时任务实现的轮询请求服务，下面我们看一下如何通过Handler对象实现轮询请求服务。
通过Handler对象实现轮询请求
- 下面我们来看一个通过Handler异步消息实现的轮询请求服务。
/**
* 默认的时间间隔：1分钟
*/
private static int DEFAULT_INTERVAL = 60 * 1000;
/**
* 异常情况下的轮询时间间隔:5秒
*/
private static int ERROR_INTERVAL = 5 * 1000;
/**
* 当前轮询执行的时间间隔
*/
private static int interval = DEFAULT_INTERVAL;
/**
* 轮询Handler的消息类型
*/
private static int LOOP_WHAT = 10;
/**
* 是否是第一次拉取数据
*/
private boolean isFirstRequest = false;
/**
* 第一次请求数据是否成功
*/
private boolean isFirstRequestSuccess = false;
/**
* 开始执行轮询，正常情况下，每隔1分钟轮询拉取一次最新数据
* 在onStart时开启轮询
*/
private void startLoop() {
L.i("页面onStart，需要开启轮询");
loopRequestHandler.sendEmptyMessageDelayed(LOOP_WHAT, interval);
}
/**
* 关闭轮询，在界面onStop时，停止轮询操作
*/
private void stopLoop() {
L.i("页面已onStop，需要停止轮询");
loopRequestHandler.removeMessages(LOOP_WHAT);
}
/**
* 处理轮询的Handler
*/
private Handler loopRequestHandler = new Handler() {
@Override
public void handleMessage(Message msg) {
if (!isFirstRequestSuccess) {
L.i("首次请求失败，需要将轮询时间设置为:" + ERROR_INTERVAL);
interval = ERROR_INTERVAL;
} else {
interval = DEFAULT_INTERVAL;
}
L.i("轮询中-----当前轮询间隔：" + interval);
loopRequestHandler.removeMessages(LOOP_WHAT);
if (!isFirstRequestSuccess || !Config.locationIsSuccess()) {
isClickLocationButton = false;
doLocationOption();
} else {
loadData();
}
System.gc();
loopRequestHandler.sendEmptyMessageDelayed(LOOP_WHAT, interval);
}
};这里是通过Handler实现的轮询操作，其核心原理就是在handler的handlerMessage方法中，接收到消息之后再次发送延迟消息，这里的延迟时间就是我们定义的轮询间隔时间，这样当我们下次接收到消息的时候又一次发送延迟消息，从而造成我们时时发送轮询消息的情景。
以上就是我们实现轮询操作的两种方式：
Timer对象实现轮询操作
Handler对象实现轮询操作
上面我们分析了轮询请求的不同使用场景，作用以及实现方式，当我们在具体的开发过程中需要定时的向服务器拉取消息的时候就可以考虑使用轮询请求了。
总结：
轮询操作一般都是通过定时请求服务器拉取信息并更新UI；
轮询操作一般都有一定的生命周期，比如在某个页面打开时启动轮询操作，在某个页面关闭时取消轮询操作；
轮询操作的请求间隔需要根据具体的需求确定，间隔时间不宜过短，否则可能造成并发性问题；
产品开发过程中，某些需要试试更新服务器拉取信息并更新UI时，可以考虑使用轮询操作实现；
可以通过Timer对象和Handler对象两种方式实现轮询请求操作；
另外对产品研发技术，技巧，实践方面感兴趣的同学可以参考我的：
android产品研发（一）–>实用开发规范
android产品研发（二）–>启动页优化
android产品研发（三）–>基类Activity
android产品研发（四）–>减小Apk大小
android产品研发（五）–>多渠道打包
android产品研发（六）–>Apk混淆
android产品研发（七）–>Apk热修复
android产品研发（八）–>App数据统计
android产品研发（九）–>App网络传输协议
android产品研发（十）–>不使用静态变量保存数据
android产品研发（十一）–>应用内跳转scheme协议
android产品研发（十二）–>App长连接实现
本文以同步至github中：github.com/yipianfengy…，欢迎star和follow
