一般来说，Google马甲包的A/B包都是独立的，我们一般把A包称为壳包，它是给Google审核看的。
根据技术方案的不同，大概有这么几类：
| A包 | B包 | 事件上报 |
|---|---|---|
| Flutter/Cordova | URL地址，直接用Webview打开 | 客户端jsbridge或者服务端S2S |
| java/Kotlin + NDK（可选） | URL地址 | 客户端jsbridge或者服务端S2S |
| java/Kotlin + NDK（可选） | B面apk | apk 客户端上报 |
| Unity/Cocos | URL地址 | 客户端jsbridge或者服务端S2S |
| Unity/Cocos | B面apk | apk 客户端上报 |
| Unity/Cocos | 和A包融合（同源） | Unity/Cocos自己上报 |
今天我们就分析最下面这种包，就是A/B包融合一体的包。
包名：com.luckycardzumatp.luckycardzumagame
上架时间：2026年3月10日
https://play.google.com/store/apps/details?id=com.luckycardzumatp.luckycardzumagame
下载次数：100k+
技术方案
A/B包是cocos creator打的标准cocos包，其中A面用到的scene预制在包里面，B面用到的scene需要等A/B判断ok后，从服务器下载。
A/B判断：轮询Adjust.getAttribution去拿渠道安装来源
1.先判断MCC卡是否ok。
2. 然后发送一个HTTP请求给服务器，内容如下：
这里关键的是传入了type=Organic这个参数，用于判断渠道来源。
这个参数来自于哪里呢：Adjust.getAttribution返回值的network字段。
我们知道，从Adjust初始化到Adjust.getAttribution能返回归因后的值，这段时间差了3-5s，如果获取时间太早，就获取不到。
这个app的做法非常简单，就是不断去轮询，每1s去查询1次，直到查到Adjust.getAttribution的返回值正常为止，如果一直不正常，就查询15次结束。
在轮询期间，一直显示loading页面，所以体验不是很好。
3. 服务器返回的结果如果ok，这个时候就在cocos层启动下载B面资源的过程，然后进入B面。
这种方案的好处是获取安装来源是通过Adjust的接口，另外A/B同源，核心判断逻辑在cocos里面这样会比较安全。但是也存在几个问题：
1. Adjust.getAttribution天然比google自带的installreferer返回要慢。
2. Adjust.getAttribution会有很多玩家归因不成功，导致被当成自然流量，只能进入A面，造成转换率低。
3. 做包比较耗时，可复用性差。