玩转app迭代开发
现在互联网开发都处于快速迭代开发的状态。这里我们来讨论一下迭代开发中的生命周期，代码版本，兼容性设计等话题。
生命周期
通常，一个产品都具有两个环境：
- 测试环境：用于开发，测试搭建的环境
- 线上环境：正式面向用户的环境
而每个版本的生命周期通常会经历如下几个阶段(忽略需求和设计等辅助阶段)：
- 开发：处于编码状态，需要不定时的发布到测试环境中进行测试
- 测试：本版本功能开发完成，此时将代码完整的发布到测试环境中，进行内部测试
- 预发布：此时APP的后台系统已经部署到线上环境中，但是还需要一部分用户（内部人员，被
邀请的体验用户等）进行线上测试最新的APP，如果出现问题，能及时的回滚 - 正式发布：此时APP已经处于完全推广状态，通知旧版本的用户进行升级到最新的APP版本可用，
当然旧版本还是能保持一段时间的可用状态，不能马上不可用。
所以针对APP，可能会出现同一个时间，线上存在多个不同版本的APP。所以我们需要注意：
- 测试的时候：需要测试那些比较活跃的老版本APP，而不是仅仅测试最新发布的APP。
- API开发的时候：需要保持活跃版本APP的API兼容性。
代码版本
在开发过程中，会遇到代码版本的管理问题，比如说：一个线上的BUG，如何进行修改和发布。这需要一个合理的代码版本管理。
版本号
通常，我们会采用x.y.z的格式来定义版本号，而考虑到机器和人的区别，出现了两种方式的版本号定义：
- versionName：也就是x.y.z，便于人类识别的版本号
- versionCode：通过x.y.z计算出来的数值，便于计算机识别的版本号
versionName的公式为：
versionName = x.y.z , 且 x.y.z 都为数字
- x -> 主版本号，无上限
- y -> 小功能版本号，上限 99(可以根据实际情况调整)
- z -> 修订版本号（修复BUG），上限 99(可以根据实际情况调整)
versionCode计算公式为：
versionCode = x * 10000 + y * 100 + z 的格式命名
通常采用versionCode作为系统内部的版本对比数值
代码版本结构
无论是SVN还是GIT通常都有 /tags,/branches,/trunk三个主要目录，而具体的使用方法为：
/tags 快照目录，每次从/branches中发布到线上的代码，都需要标记tag到/tags下，以便于发现BUG进行修复
/1.1.0 发布的1.1.0版本
/1.1.1 发布的1.1.1版本，修复了/1.1.0发布的某些BUG
/1.2.0 发布的1.2.0版本
/branches 开发目录，当开发或者修复到一定程度后，需要合并代码到/trunk中，并且/branches中的不同代码版本只能通过/trunk交换代码。开发或者修复完成后，需要合并代码到/trunk中，并且标记tag到/tags。
/1.1.x 1.1.x 功能版本
/1.2.x 1.2.x 功能版本
/trunk 合并目录，最新稳定的代码版本，主要用于branches之间的代码交换，注意代码开发不在/trunk上。
注意：对于APP的发布，从/branches/1.2.x 打tag到/tags/的时候，需要上传apk和mapping文件到/tags/1.2.0/release中，方便之后定位bug。
兼容性设计
基本概念
这里写一些通用的概念：
- APP版本废弃: 活跃用户不在这个被废弃的APP版本，并且服务器限制该版本APP使用。
服务器
在保持兼容的过程中，服务器的兼容性还是比较好处理的，因为服务器的升级完全处于我们自己的控制中，
不会出现服务器处于不同的版本状态。所以，只要处理好数据库，HTTP接口，推送协议，基本能保证
迭代无副作用。
数据库
在业务的开发过程中，不可避免的就是添加新的字段和删除原来旧的字段，对于新的字段添加，基本上可
以保证旧的业务正常的运行，而删除字段，则可能导致旧的业务不能正常的运行，所以需要慎重选择。
当然我们也不是不能删除字段，一般的做法是先保留旧的字段，然后等待APP版本废弃，之后就可
以进行删除该字段了。
HTTP接口
URL 兼容性
对于HTTP接口，在迭代过程中，会出现如下几种情况：
- 添加API
- 删除API
- 修改API
- 添加字段
- 删除字段
这几种情况，为了保证已经上线的APP能正常的运行，所以我们需要对API做兼容性工作。API格式为：
当对一个API进行更新的时候，并且无法做到兼容的时候(删除字段等)，我们新建一个
这种格式的API，并且使用注解标记原先API为废弃状态(禁止新开发版本使用该API，并且版本迭代
到后面几个版本后，可以剔除该API)。这种API设计方式有如下的优点：
- API更新的表示非常的简洁，只用添加版本号到最后即可
- 废弃的API和新的API都在同一个代码文件中，维护比较方便
然而，这种方式有一个缺点：对同一个API修改的次数过多，会导致形成过多的 API 版本（1，2，3，4，5）
不是非常的好看，我们可以通过设置一个版本滑动窗口来解决。
版本滑动窗口：当API版本迭代到10的时候，自动又从0开始，当然了0版本号的api需要早早的被废弃掉。
当然，还有其他解决URL兼容性的方法，比如说：采用 http://host/v1/module/service 的方式，但是这个方式
存在一个比较致命的地方：每次修改API，都需要FORK出新的代码版本，而往往我们还需要维护旧版本代码，导致
维护难度（修改同一个API的时候，需要打开该API的多个代码版本进行维护）。
API扩展性
不仅仅是API的URL需要保持兼容性，针对返回的数据，我们也需要做到一定程度的扩展性。
例子一 ： 朋友圈主题不同类型
在最早的时候，朋友圈还是只能处于发发图片和文字的状态，后来加入了一些额外的元素，
如音乐，视频，图文等内容。然而在加入了新的主题类型后，旧的用户不一定会马上升级，
所以要保持朋友圈的兼容性。有大致两个做法：
- 添加host/module/server2这种类型的API，使得它支持新扩展的音乐，视频，图文。
- 返回数据结构中添加TYPE属性，APP仅仅处理能识别TYPE的数据，过滤掉不能识别TYPE的数据(音频，图文等)。
方案1虽然说也能处理这些情况，但是总体来说没有方案2来的更加优雅。
TOKEN 认证
对于HTTP接口设计中身份验证，通常采用TOKEN的方式。因为TOKEN比较方便存储，以及显示的使用。
返回JSON
HTTP 返回的数据格式，通常采用JSON格式：{code:-1|0|1,msg:String,data:any}。
- code: 状态码，负数为系统统一错误代码，0为成功，正数为业务错误代码。
- msg:执行结果提示，String类型
- data:需要返回的数据，可能为空，也可以为任何数据类型JSONObject,JSONArray,Int,Double,String.
HTTPS
为了通信的安全，我们还需要采用HTTPS连接方式，避免中间人攻击等常见的网络攻击手段。
推送协议
开发移动APP的时候，不可避免的就是使用长连接推送一些及时消息，比如说新闻，广告，强制下线通知等。而推送协议的格式基本上为：
{ module: 模块类型, function:操作类型, [data]:{msg:"hello world"}}。
当APP端接收到推送的时候。采用如下的步骤处理推送：
- 判断业务模块module是否能处理
- 判断function是否能进行处理
- 读取data数据
- 根据 module,function 使用data作为参数，调用具体的处理函数。
处理过程中，注意使用
try{
...logic
}catch(Exception e){
}
避免处理过程中，导致APP奔溃。
当出现推送协议完全不兼容（删除字段，删除含义等）的情况的时候，我们需要针对推送协议做兼容处理，通常我们可以采用function[..N]的方式来兼容。在兼容期阶段，我们可以采用：
- 检测连接APP的版本，选择正确的推送格式function 还是 function2 格式
- 同时发送function 和 function2 协议，新版本APP删除function支持，仅仅处理function2。而旧版本APP仅仅只能处理function协议，忽略了function2的协议处理。
- 预先埋点，在几个版本之前就嵌入function2的逻辑，当function逻辑的版本APP都废弃后，就可以统一采用function2 协议推送。
上述两种方法各有优缺点：方案1比较智能，但是开发量比较大。而方案二比较方便，但是比较损耗流量。而方案3需要时间来过度。
移动端
移动端升级，主要涉及到本地数据（数据库，磁盘文件），APP全局升级补丁，协议兼容性（HTTP，推送），
以及APP版本检测，而JAVA代码和资源文件，当然就不需要进行处理了。
数据库
数据库升级还是比较方便的，这里我们采用APP版本代码（versionCode）作为SQLite的版本号，
SQLite已经为我们提供好了onUpgrade接口，在升级的时候，SQLite会给出旧的版本号，和最新的版本号，
此时我们只要做：
就可以保证对数据库的正确升级了。
App全局升级补丁
除了数据库升级，对于磁盘文件，升级后的引导页面等需要处理的杂项，可以在APP全局升级补丁中进行
处理。比如说，某个版本，可以删除某些磁盘文件，那么，就可以在全局补丁中编写代码。具体的做法为：
- 每次打开APP初始化application的时候onCreate()，读取记录在本地数据库的APP版本号和APK中的versionCode进行对比
- 如果不一致，那么，就有可能是升级后，重新打开APP的情况，那么，我们就可以进行升级补丁操作
- 升级完成后， 把最新的APK中的versionCode写入本地数据库，避免下一次打开APP的时候，重复升级
升级代码大致如下：
可以发现，使用versionCode作为升级代码点，能比较清晰的区分出不同版本做了什么事情。而且对于从比较老的版本直接升级过来，也是OK的。
APP版本检测
APP版本检测和是升级是比较核心的功能模块。主要实现的功能有：
- 定时检测 APP 是否需要升级，并且进行提示。
- 判断用户是否可以继续使用该APP，即当前APP需要强制升级。
所以，APP检测的时候，给定服务器最新的版本信息数据即可，格式基本是这个样子：
含义：
- versionName：最新版本名称 x.y.z
- versionCode： 最新版本代码
- deadVersionCode：如果APP#versionCode <= Server#deadVersionCode，需要进行强制升级，不能再使用其他功能。
当检测到新的APP版本后，还需要在界面上进行ALERT，通知用户进行升级。强制升级的话，需要禁用所有
的功能（避免APP奔溃）。然后进行ALERT用户。
APP版本检测功能，应该算是APP快速迭代的保证。可以让服务端来控制APP是否可以继续使用和升级。
总结
当然了，还有一些其他方面的迭代开发话题，之后再补充上去。