一般情况下，APP中会有大量的接口，再加上版本的变化，接口的升级，可能会衍生出很多个稍有差异的接口，这个时候接口如果维护的不好，后边会乱为一锅粥，客户端不同版本使用不同的接口名（xxxv1,xxxv2,xxxv3.....）。
有的公司每次发布完APP，就强制用户更新。不推荐这样，用户体验太差。
就算是强制更新，在苹果审核期间，新的APP接口和老的接口也必须能同时使用。
处理方法
一、 客户端做兼容，接口不用做兼容
APP强制更新（不建议）
接口URL：api.xxx.com/v1.0/xxxx.java
接口的URL中加入版本号，如上：v1.0。
采用灰度服务器 部署正在审核中的 接口版本（如：v1.1）。等审核通过后，将老版本的APP设置强制更新，然后把线上服务器重新部署上最新的代码，再去掉灰度服务器。这样APP接口全部访问正式的线上服务器。热更新
紧急的小需求可以用热更新，大的需求建议还是用原生的代码，因为你用热更新修改完（用JS或Lua），最后还要在原生代码里修改。
网游用热更新的比较多，因为网游的APP太大，不可能加个小关卡 就要求用户重新下载，并且游戏更新比企业级APP更频繁，用热更新可以不断新加关卡、场景、活动推广。React Native 和Weex
没接触过 可以自己了解
二、 服务端做版本兼容
-
App 请求服务器接口的时候携带接口版本字段
服务器根据接口版本调用相应的方法，每个接口逻辑里 加if 判断（不推荐）
接口URL：api.xxx.com/api?version=v1&..
if (version == ‘1.5.0’) {
//do_something
} else if (version ==‘1.4.0') {
//do_something
}
不同版本的逻辑都在一个方法里，在于容易造成代码混乱，不利于维护。
一个版本一个文件
相当于每个接口版本都是一个独立的项目。放到服务器的独立文件夹里。使用什么版本接口写到客户端配置里面或者通过一个接口获取就行。
例：
1.0版本：http://x.x.x.x:xx/xxapi/v1.0/xxx
1.2版本：http://x.x.x.x:xx/xxapi/v1.2/xxx
文件夹位置：Controller/V1.0/
-----------------/xxxx.php
文件夹位置：Controller/V1.2/
-----------------/xxxx.php
优点：版本逻辑分开维护。看url就能知道哪个版本。删除多余版本 不用修改代码。
缺点：同个接口不同版本 文件是重复的。并且 如果有个接口前几版就有问题，一直遗留到现在，就需要改好几套一样的代码。-
token代替版本号
几个要点：
a. 客户端发送请求时token是固定不变的，使用token间接的标记请求的接口版本。
b. server保存了token和对应接口的版本号，请求来了之后会先根据这个寻找对应的接口版本。
c. 每个目录对应一个版本，根据请求的接口读取对应目录下的接口配置文件，找到最终要执行的具体接口。
例如：http://xxxx.xxxx.com/module/controller/list?token=6918b5e0567c7d47314c10ed413e3f95 这个请求最终会打到listv2这个接口。
d. 这样就可以在服务端灵活的配置接口了，客户端只要每次请求的时候带上默认的token参数，就可以得到自己想要的了，完全不需要关心版本的问题。 继承的方式
ControllerV1
ControllerV2 extends ControllerV1
采用继承的方式，既可以利用之前的接口代码，又可以采用override的方式修改部分接口的实现。
缺点：如果上个版本（也就是父类）修改了代码，就会影响后面的所有版本。不同版本使用不同的域名/不同服务器
不同版本不同分支，部署在不同的服务器上。如果某个版本用不到了，直接干掉服务就好了。
例如我现在的API要从1.x升到不兼容的2.0版本了，那就给当前的发布分支打个Tag。等哪天1.x版的API需要fix bug，就能很简单地从这个Tag切一个1.x的分支出来fix bug后进行测试发布，而且这个分支不会合并到任何分支，所以不会影响其他版本。
优点：部署的过程不会影响其他版本api的使用，并且可以减轻单台服务器的负担。
缺点：如果2.0也有同样bug的话，也要在2.0分支上改一遍。如果版本很多的话，工作量大。所以呢，一般不会同时发布两个以上的版本。另外，如果要兼容过多的版本，服务器也需要够多才行。同时，因为老版本的人用的少，也就是有的服务器访问量很少，有的服务器访问量很多。不能真正的负载均衡，浪费了服务器资源。
最后做下版本使用监控。当观察到所有用户都使用新版本的客户端的时候，并保持一段时间的时候。放弃对老版本的维护，继而下掉老版本的资源。
版本更新
开启APP->请求初始化接口->检测是否需要更新? 否->首页Or 是->更新
在初始化接口的时候，需要客户端发送几个数据：
app_id 客户端id，比如： 1，安卓手机 2，iphone手机
version_id 大版本号id
version_mini 小版本号id
did 用户客户端信息（客户端工程师会获取这个数据）
encrypt_did did加密后的字符串（did 加上 APP设备数据表中的key，然后md5）
数据库方面：需要两张表。一张是记录升级版本信息的表，记录着设备的id，版本号信息，下载地址等。另外一张表是记录的设备的信息，比如安卓手机的信息，版本信息表中有一个外键app_id，关联的就是设备信息表的主键。
//设备信息表，记录了各种客户端的信息
CREATE TABLE IF NOT EXISTS `app_table` (
`app_id` smallint(6) NOT NULL AUTO_INCREMENT COMMENT '主键',
`name` varchar(10) NOT NULL COMMENT '设备名称',
`is_encryption` tinyint(1) NOT NULL COMMENT '是否加密',
`key` varchar(10) NOT NULL COMMENT '加密key',
`image_size` text NOT NULL COMMENT '按照json来存储',
`create_time` int(11) NOT NULL COMMENT '添加时间',
`update_time` int(11) NOT NULL COMMENT '修改时间',
`status` tinyint(1) NOT NULL COMMENT '状态 1正常0删除',
PRIMARY KEY (`app_id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COMMENT='app设备表' AUTO_INCREMENT=2 ;
//版本升级信息表，存放了各种版本的信息
CREATE TABLE IF NOT EXISTS `version_upgrade` (
`id` smallint(4) NOT NULL AUTO_INCREMENT COMMENT '主键',
`app_id` smallint(4) NOT NULL COMMENT '客户端设备id',
`version_id` smallint(4) NOT NULL COMMENT '大版本号id',
`version_mini` mediumint(8) NOT NULL COMMENT '小版本号',
`version_code` varchar(10) NOT NULL COMMENT '版本标识1.2',
`type` tinyint(4) NOT NULL COMMENT '是否升级1是0否',
`apk_url` varchar(255) NOT NULL COMMENT '下载链接地址',
`upgrade_point` varchar(255) NOT NULL COMMENT '升级提示',
`status` tinyint(4) NOT NULL,
`create_time` int(11) NOT NULL COMMENT '添加时间',
`update_time` int(11) NOT NULL COMMENT '修改时间',
PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COMMENT='软件升级信息表' AUTO_INCREMENT=2 ;
通过app的版本信息与服务器信息对比，看是否要进行版本升级
