假如看看对应的接入SDK，无非都是初始化（账号认证）、deeplink、埋点数据上报这些功能。看似很简单，实际上却有很多的坑，需要一步一个脚印的走。
下面对AF平台的接入以及部分常见接入问题做出总结
MMP平台的SDK基本都需要在APP启动时或之前认证，有些在AndroidManifest.xml/Info.plist中配置，有些在代码中，或者两者结合，一般在代码中的会更加方便。
AF的主要是在代码中配置的方式，且Android和iOS的方式会有点不同，AF_DEV_KEY和APP_ID可在代码中配置。DEV_KEY是唯一的KEY，而APP_ID则是iOS商店id。
AppsFlyerOptionsappsFlyerOptions=AppsFlyerOptions(afDevKey:_AF_DEV_KEY,appId:kReleaseMode_AF_APP_ID:_AF_APP_ID_DEBUG,showDebug:false,timeToWaitForATTUserAuthorization:30,);大部分的配置初始化可以在代码中完成。
那怎么区分测试环境和正式环境呢？
AF这一点不是很好，没有直接能够区分出来是否沙盒的开关，也就是说，按我理解的，他们没有设计区分测试环境，沙盒环境的场景，而这是很常见的功能。
要区分测试环境（沙盒环境）和正式环境，且数据分离，只能够另外建个应用、项目，然后用这个新的应用，作为他的测试环境。
为了实现不同的应用，iOS需要虚构一个测试用的APP_ID，因为他是用APP_ID来作为不用应用的区分。就比如上一点的示例代码中的AF_APP_ID_DEBUG。
Android则是根据包名来区分不用应用，所以需要在build.gradle的buildTypes中，设置applicationIdSuffix，使在debug中自动增加后缀
buildTypes{debug{...applicationIdSuffix".debug"}profile{...applicationIdSuffix".debug"}release{...}}这会导致一个问题，Android测试和正式为两个包，因为包名不一样，iOS则是同一个包，但APP_ID不一样。
还有另一个影响，如果使用了如googlefirebase这种，需要类似google-services.json来认证加载配置的，Android因为它会根据包名来认证，所以需要在不同环境下进行不同的配置。如下
比如在debug下的，更改里面的package_name，加上后缀.debug
DEEPLINK分为深度链接和延迟深度链接（deferdeeplink），简单来说就是分为已安装情况（前者）和未安装情况（后者）下携带过来的链接处理。
但对于技术方面SDK的接入，实际上不用考虑他是普通的还是延迟的，都是同样的处理。
主要要配置好urlscheme（应用链接）和UniversalLinks/AppLink（通用链接）
·UrlScheme：，也称应用链接，只针对App已安装情况，打开指定app并响应跳转落地页
Android(AndroidManifest.xml)
在配置完成之后，就可以接入他们的监听回调。AF中，有两种回调onInstallConversionData和onDeepLinking。他们都是深度链接的监听。
·onDeepLinking为新的UDL（Unifieddeeplinking）模式，该模式不依赖归因进行深度链接处理，优点是可以更快更准确的响应。缺点是只处理深度链接（DeepLink）的数据，所携带参数必须带有deep_link_value，才能够触发响应。
后者为新的方式，响应更快，但它并不是对前者的替代。很多功能依旧需要前者才能用，后者主要是用在比如说AF的onelink跳转的场景下，其他的功能场景比如横幅跳转并没有适配，要用的话还得手动加参数。
具体在接入各平台各功能（如目录投放、Feed流这种）时，需要注意下平台是否能支持，是否需要另外接入，接入后怎么避免重复处理。
可用logEvent来手动上报
logEvent(eventName,eventValues);eventName：事件名；eventValue：事件参数。
上报时是实时上报，可以考虑下频率的问题，比如加入列表曝光事件，一次性上报曝光列表而不是循环上报。
假如有统一的附加数据携带，不需要在每个事件中修改eventValues来带上，可以通过setAdditionalData来配置
所有平台在iOS14.5之后都只能用SKAN来进行归因，这就导致了很多的坑。
14以下是用的旧的归因方式，所以展示在总面板中。14以上使用的SKAN，数据汇总在SKAN面板。
SKAN面板需要设置衡量模式，大致是收入、事件转化这些。
事件数还好，他能够正常的统计。收入则是最麻烦的，因为他不会上报具体的收入数值，他让你设置一个衡量范围，所谓的CV值（conversionvalue），且最多64个，即0-63。并且无论衡量什么，总数量上限就是64。
不过cv限制，也是投放同学考虑如何设计来保证投放效果。但随之而来的一个重要问题是，所有平台都使用的同一个Apple的SDK上报，他们的数据会互相影响！
这又多坑，SKANSDK上报cv，是这样上报的，比如5块钱的收入事件触发了一次，那他就会上报五块钱的cv，5的cv则为1，假如又支付了五块钱，就是五块钱触发了两次，那就会将五块钱的cv+1，5的cv变为2。（这个五块钱就上面定的每个衡量范围0-63）
classfuncupdatePostbackConversionValue(_conversionValue:Int,completionHandlercompletion:((Error)->Void)=nil)就是这么神奇的统计方式，假如同时接入了AF和FB的SDK，都上报了一次五块钱的收入事件，那他的cv就会变成2，实际是1，导致数据错乱。甚至于假如说FB定的衡量模式跟你的不一样，导致fb上报的不是5，而是其他的，比如具体收入值。那你的衡量会被完全打乱，SKAN回传的数据跟实际数据完全不一样。
即使已经调整为仅一个SDK来处理SKAN的CV事件，还是有很多问题。比如我遇到的，cv数永远都是记在最大的范围值上，也就是上报的cv超过了设置的最大衡量值，比如63，现在全部收入都是63（确认上报的数据大部分没有超过63）。并且没有有效的解决方案，说是接入多个SDK互相影响，现在全屏蔽了，仅用AF的S2S上报来做收入上报，依旧是这样的问题。不知道是不是AF的上报有问题，还是有其他数据在用别的衡量模式，但按理来说，假如AF成功update了cv，那即使有其他导致63（或超过63）的值改变，也应该有实际衡量值的数据，为什么只有63的呢？
iOS的Appid测试id是虚构，这也是没有沙盒环境设计埋下的坑。SKAN是根据APPID来上报到对应的应用，然后AF根据Appid来拿到对应Apple回传的数据。
假如是虚构的，而SKAN是根据实际APPID来上报的，为了不影响只能屏蔽，所以就拿不到对应测试环境的数据。
SKAN的上报也无法抓包（或者说我没找到方式），抓不到问题。