App稳定性之应用分身（App稳定性之应用分身）

今天上午工作过程中，我们的审核同事发了一段视频，是一个用户通过“多开分身”这样子的软件将我们的App的多开高达5个分身，当时我第一个感觉这啥样的用户啊，后面就把如何防止用户多开提上了日程。

在Android设备中，当前很流行应用分身，市面上也冒出了很多分身软件，例如360的分身大师，LBE平行空间，以DroidPlugin插件运行的产品；虽然它给我们带来很多便利，但是对于业务来说却带来很多麻烦，例如营销号产生的不合规的内容。

1) 数据安全隐患风险：

所有的分身双开应用数据，都通过【应用分身】的过滤，数据不可避免地都要经过【应用分身】，万一【应用分身】被掌握，或使用第三方【应用分身】类应用，数据会存在安全隐患。简单粗暴的反编译修改APK的方式也会存在类似的问题。

2) Android政策风险：

【应用分身】功能实现的原理 实际上是通过监听截取进程消息，替换反射，类似黑客的手段，可能Android会禁止该类应用。后续Android版本更新后有可能会被限制无法使用。

3) 卡顿、资源占用问题：

【应用分身】无论采用系统层还是应用层的做法，都会占用系统资源，如果分身过多，可能会造成系统卡顿。可以通过限制分身数量的方式来加以避免。

4) 三方应用兼容问题

类似Android政策风险，【应用分身】采用类似黑客手段，可能会遭到第三方应用如微信/QQ等的屏蔽

一些三方应用调用接口不标准，可能没办法被【应用分身】监听和替换，会造成分身应用和本身应用表现不同的兼容性异常。

先把危害告知下大家，下面就聊一聊如何让我们的应用遇到在多开时候自动跳过。

今天我把应用市场大部分的分身软件都下载了个遍，大概了解了下绝大部分分身软件是靠克隆备份方式来执行的，然后有一部分软件虚拟机技术来进行的。

克隆方式的这类应用很好解决，我们只需要把Context.getFilesDir路径打印出来比对，看是否符合正常应用即可，代码如下：

但是以上方式对于采用虚拟机技术是无效的，但是我们可以通过主动抛出异常方式来检测崩溃日志是否含有我们设置的过滤词进行判断

然后我们可以设置过滤词即可，目前我设置的过滤词有xposed、 morgoo(360的分身) 、droidplugin，后期过程中我们不断去发掘不断的去填充这些过滤词。

除了应用分身以外，诸多用户还喜欢使用模拟器，怎么判断是否是模拟器，我们可以从cpu架构、蓝牙、拨号、温度传感、遥感等模拟器没有的功能去辨别。

在业务发展过程中，要注意用户的一些操作行为也许超出了我们允许的范围，此时我们要及时纠正用户行为。