App刷量刷友盟方案
App刷量刷友盟方案
其他缘由就不再说了， 能点进这篇文章，就说明也是无奈。 现在创业公司的艰难也是很无奈， 为了给投资人一个美好的数据报表与愿景，而现实又是如此的残酷。 这件事是如此的违背职业道德，但是拿人食君禄为君分忧。说归说，不再闲扯。原系统已于17年底废弃，这里只是梳理一下具体的知识点整理于此，以便备忘形成方案。 本文主要分析一下该助手App系统实现原理与各个部分， 仅做技术研究讨论学习使用， 如因此造成的任何后果与本文作者无关。
1.简介
为了获取更多模拟用户，更高的日活与优质模拟用户而开发的一套综合的模拟助手系统方案。
本文适合具有一定开发能力的开发者共同探讨研读。
2.核心实现原理
-
设备信息修改原理：本系统应用端基于Android 开源框架Xposed ,通过Xposed 对App方法的hook ，从而实现了修改设备信息的操作。
-
用户操作模拟实现原理：Android Framework中定义的AccessibilityServices ，根据自己App 定制辅助程序， 定义具体的操作事件，从而实现了模拟用户的操作。
3.优质用户数据模拟
众所周知umeng统计作为移动应用行业数据统计的权威标尺。 本助手系统也主要为umeng统计定制，也主要针对该系统进行分析，以及高度仿真模拟方式。
3.1用户分析
3.1.1 新增用户
- 新增趋势
- 新增用户质量
3.1.2 活跃用户
- 活跃趋势
- 活跃构成
- 活跃粘度
- 周活跃率
启动次数
分别从渠道，版本 ，时间三个维度方面进行启动统计分析。
版本分布
从应用版本，新增用户、活跃用户、启动次数 四个维度 进行统计分析
行业数据
- 日新增用户
- 日活跃用户
- 日启动次数
- 平均单次使用时长
- 上周活跃用户
- 上周活跃率
- 上月活跃用户
- 上月活跃率
这一部分可以考虑根据需求，系统调度分发相应短期或者中长期任务。可以形成更自然的用户规模的增长模拟，活跃用户，单次使用时长。
3.2 留存分析
留存用户
- 新用户留存
- 活跃用户留存
用户新鲜度
展示每天活跃用户的成分构成，并提供用户成分分析控件做进一步的分析。用户新鲜度帮您从宏观上了解每日启动用户的新老用户比以及来源结构。
某日的活跃用户来源于当天新增用户、1天前新增用户…30天前新增用户、30+天前新增用户。其中当天新增用户与您在当日的推广行为相关，n天前新增用户与n日前的新增用户和n日留存率有关。
用户活跃度
报表展现每个天级时间点的当日活跃用户的活跃程度。
将当日活跃用户按照过去15天（含当天）启动的天数分为1至15组，计数并展示。
活跃1天的用户，表示这个用户在过去15天中仅有1天启动；
活跃2天的用户，表示这个用户在过去15天中仅有2天启动；
活跃15天的用户，表示这个用户在过去15天中15天都启动了。
活跃天数越多的用户，其活跃程度越高，对APP的价值越大。
这一部分可以考虑根据需求，系统调度分发相应短期或者中长期任务。
3.3 渠道分析
这里边统计的两个维度 时段详情、渠道列表 ， 则对应的是不同应用市场的渠道包， 可以根据具体的分配任务进行匹配相应的渠道包和时段。
3.4 用户参与度
这里边所统计的三个维度 ，使用时长、使用频率、使用间隔. 可以根据后端自动化系统的调度，前端来控制实施。
访问页面部分可以根据后期的开发需要进行定制添加统计。
3.5 功能使用
功能使用主要分为 页面访问路径、自定义事件、事件转化率。
目前应用中 嵌入的两个事件，分别是 用户注册、用户登录。
3.6 终端属性
终端属性牵涉到应用的使用范围，地域，以及设备的停留面。
设备终端
主要分为： 机型、 分辨率、操作系统 三个部分。
该部分信息可以通过xposed 的模拟实现。 实现多种设备型号 ， 分辨率， 操作系统 模拟。
网络及运营商
主要分为： 联网方式、运营商。
该部分信息可以通过xposed 的模拟实现。 实现多种联网方式、运营商。
地域
主要分为： 省市、国家/地区
该部分以省市为主。 地域分布主要从GPS定位以及网络辅助定位实现。
该位置信息也主要通过xposed的模拟实现。具体实现方式需要进一步调研。
4. 自动化方案
问题所在： 在用户量达到一定的规模之后，设备的管理，单一重复的工作量消耗，以及不成比例单一重复不规则的模拟数量 会严重影响数据的仿真性。
例如在同一时间，同一种型号手机，不同型号，在一时间大量重复的启动，会在umeng平台产生一种刷量的感觉， 或者说没有统一的管理，调度，单一设备根据算法生成的设备模拟数据就会造成
“每天的启动次数很多，设备量种类繁多，几乎没有相同的用户，存留率极低，活跃度极低，更不会形成良性用户群应该有的正态化分布。”这样很显然不是我们所想要的。
解决方案：自动化主要通过服务端为每台设备调度的模拟任务，进行下发， 到达每个终端后进行批量终端数据以及用户行为的模拟操作。
4.1 应用端自动化
设备端App 可以在一天的指定时间段 进行任务拉取。 分析任务量以及模拟设备信息，用户行为（例如： 注册，登录 等），进行批量自动化模拟操作。
4.2 服务端自动化
4.2.1 自动化模拟设备数据生成
可以进行市面上传统设备型号信息采集 ， 型号，系统，分辨率，必须进行一对一匹配。 不然容易出现：（小米设备，对应的华为型号，三星的分辨率，出现在同一统计终端统计平台中） 这样会严重影响仿真度。
4.2.2 自动化模拟用户行为数据的生成
目前App 在统计平台中自定的功能使用中 只添加了注册与登录部分。
可以根据这两部分 生成相应的自动化模拟操作部分， 例如使用不同的手机号进行模拟新用户注册，登录， 第二天登录。 第三天登录 ，, 定制每天的操作时长。
日后可以根据统计功能使用中不同需求进行 不同的定制话模拟操作需求。
5. 前期实施
5.1. 前期硬件实施
经过调研发现 设备普遍系统版本较高 均大于4.4.4 Android 16， 而市面上支持root的第三方Root 工具支持的root 设备方案 均处于几年前的状态，设备Root方案比较困难。
按照优质模拟用户 数据 每日助手模拟运行时间 5：00 - 24：00 一共19小时 ，每台单次模拟操作时间 10-30分钟 取均值15分钟 19*60/15 = 76个用户。
76- 76 * 0.01（事故率，不确定因素，例如，停电，断网，死机 等） = 75.24 个用户
如果获取日活1万 则需要 10000/75.24 = 133 台设备
总需要设备量 133+133*0.01（事故率： 硬件问题，系统问题，刷机失败） = 136
当然也可以根据实际单用户的实际使用时长 日活需求量来进行适当的调度，增减设备量。
5.2. 前期软件实施
5.2.1 设备端
前期调研的设备使用传统的Root 工具很难起效， 但是调研发现MIUI系统，Android 6.0 的开发版本，保留了用户操作Root权限授权部分。 首次部署 需要人工操作更换开发版操作系统，授予Xposed，Root权限部分， 自己要开发的App Root权限部分，重启等操作。
时间成本：单台设备需要（刷机30分钟，xposed 安装，助手安装，重启 30分钟 ）1.0 小时 1* 136台设备 = 136/8 = 17 日/人
折中办法， 可以直接采购MIUI系统 开发版本设备， 免去了更换开发版操作系统时间。
5.2.2 系统端
系统端在助手系统的调度中起着重要的作用。
完整规范的设备型号数据，以及地理城市模拟数据的采集很有必要，为任务下发与部署提供正确引导。
6. 当前系统支持
6.1 系统端支持
就目前来看采取助手系统进行模拟用户的注册，登录两部分。
注册部分需要接近真实地模拟用户手机号的输入，注册，验证码 。 这时候如果走真实的发送接收验证码流程是行不通的，因为不可能知道一个随机的手机号码的验证码是多少。
系统端需要修改成 发送验证码，接收后 直接通过接口返回验证码 并不需要调用运营商的短信接口 。
或者特殊的字符串作为密码，约定好密码直接登录
此处 成本节省： 0.06 * 10 0000用户 = 6000元 短信费用
6.2 App端支持
针对注册部分改动， 需要输入随机手机号 之后，获取验证码，直接填入服务端返回的验证码，点击验证成功。
需要修改某个版本之后打包。
7. 开发步骤预估
7.1 应用端
7.1.1 型号模拟期
前期可以考虑先把设备品牌号，型号，序列号，IMEI，设备号，系统版本，手机号，网络类型，Mac地址等设备终端信息实现自动化刷取，时长定时，自动退出，清除应用数据。
7.1.2 用户操作模拟期
前期可以实现模拟 注册，登录 。
后期可根据定制需求实现不同的功能使用模拟。
7.1.3 维护期
应用的稳定 升级更新，数据清除等操作。
7.2 系统端
7.2.1 数据采集器
前期可以考虑先把设备品牌号，型号，分辨率、等信息按照市面真实数据进行采集，整理。 序列号，IMEI，系统版本、手机号，Mac地址等信息能够自动生成的 自动生成。
采集接近真实的城市地理数据 信息 与用户信息绑定 ，这个可以根据 城市，用户群分布的离散度进行定制生成。
整理出十万套接近真实的设备、地理位置等基本信息放在db中备用。
7.2.2 系统开发期
系统可以根据需求来定制 新增用户量，活跃用户，单次使用时长、平均时长、启动次数 等信息，进行匹配，调度，下发任务到各个终端设备。
7.2.3 维护期
对于设备终端数的增减进行动态把控。
可以根据具体需求进行开发，维护。
8. 关键点与实施难点预估
- App端设备信息自动化模拟
- 自动化用户行为模拟部分 需要根据AccessibilityServices 定制化开发 。
- 系统端各种设备的完整信息采集
- 系统端根据需求来定制，日新增用户量，活跃用户，单次使用时长、平均时长、启动次数 存留量 等算法的定制与调度。
9. 作弊与反作弊分析
就目前而知的xposed 刷umeng方案可以使用，但是umeng方面也在不停地通过AI等技术添加防止作弊的手段，可以通过设备的指纹码，WiFi列表，配置信息，局域网内通信等来判断某一批访问是否属于刷取的量。 当然反作弊部分也可以通过更多维度的信息定制，来躲避umeng系统的跟踪。这个就要看哪方愿意付出更多的代价。
10 总结
从上至下一共分为10部分将该系统阐述明白。如何优雅的刷取用户真实可靠的数据量，完全在于真实数据的模拟与真实数据的采集和可靠的信息模拟，这是一个慢动作，需要耐心的制定，完整的考量与策划。 当然也可以根据后台信息的呈现，实时地进行调整。
最后一句大道至简， 最简单的模拟造假，就是不造。 世间之事假即假，真即真，假非真、真非假。俗话说纸包不住火就是这个理，这是任何系统也无法模拟的。
11. 参考文档
- Xposed官网
- Xposed Installer
- Xposed for MIUI
- Android AccessibilityServices ）
- Android最佳实践之UI - 实现辅助（外挂）
- AccessibilityService 实战详解