推荐内容IMESSGAE相关

作者推荐内容	iMessage苹果推软件 *** 点击即可查看作者要求内容信息
作者推荐内容	1.家庭推内容 *** 点击即可查看作者要求内容信息
作者推荐内容	2.相册推 *** 点击即可查看作者要求内容信息
作者推荐内容	3.日历推 *** 点击即可查看作者要求内容信息
作者推荐内容	4.虚拟机安装简单 *** 点击即可查看作者要求内容信息
作者推荐内容	5.iMessage *** 点击即可查看作者要求内容信息

编纂导语：在本年的苹果开辟者大会上，苹果公布了iOS 14等软件的更新，并且特别强调iOS14将支撑AppTrackingTransparency（简称ATT）和SKAdNetwork。本文作者从这一动静动身，对 iOS 14 ATT和SKAdNetwork开展了周全解读，与大师分享。 在2020年的WWDC20上，Apple发布了iOS14，并且特别强调iOS14将支持AppTrackingTransparency（简称ATT）和SKAdNetwork，看似细小的更新，对互联网告白行业的影响则是7.0地动级的。 ATT的更新使开发者获得用户的IDFA必要弹窗并经过用户的赞成，进步了用户隐私透明度。而按照汗青履历，最少40%的用户不会同意，更不用说权限申请弹窗上还要提醒为了向用户供给更精准的广告保举。固然，某些APP会让用户必须同意受权IDFA，不然不提供办事，这类轻易被Apple以用户鄙视的来由下架，更不成取。今朝，iOS上的广告生态中从定向到归因都是基于IDFA之上，影响面不可思议。 SKAdNetwork2.0是由1.0进级而来，以办理上文中提出的IDFA带来的安置和转化归因题目。简略来讲，广告平台需要注册成为Apple的一个广告网络并提供一个回调地点，当用户经由进程此广告网络的广告下载并翻开了广告主的APP以后，Apple会把安装等信息传到回调地址。全部流程中有不少细节问题，详细看下文。 ATT和SKAdNetwork2.0的更新，不但代表着Apple更看重用户隐私透明度，也代表着Apple起头插足广告归因，想作为利用商铺在广告归因平分一杯羹，并为将来更大的广告营业做筹备。

先说影响面： 这次更新，紧张影响的是通过装备号跟内部举行交互的事物上，包括如下： 1.安装和转化归因，在获取不到IDFA时要有新的筹划，比方SKAdNetwork2.0； 2.广告主要更细致归因耽误深度链接，广告主基于IDFA广告点击的延迟深度链接方案不可行，要有其余方案 3.APP拉新时，已安装用户的果断在获取不到IDFA时要有新的方案，用Apple提供的法子去盘问是不是安装某个APP 4.APP拉活、老客叫醒时，基于IDFA的用户定位方案也再也不是支流

在获取不到IDFA时要有新的方案 再说ATT和SKAdNetwork2.0论断： 1.通过读取签名中的广告展现ID，广告平台仍旧可将安装和转化归到某一次广告展示中 2.安装和转化回传的实时性大大降低，会延迟1天到64天之间，且至多传64种转化，转化代价没法回传 3.Apple未说明具体归因逻辑、时长和周期，且给广告主的信息几近为零，未说明若何根绝广告平台做弊 4.未提供除了IDFA之外其他定向方案 5.依赖于点击监测和IDFA的延迟深度链接不可实现​​​​​​​6.用户制止APP拜候IDFA的几率较高末了提出几种解决方案： 通用id方案Id Mapping 方案IDFA+IDFV加密方案 提交产物计划，研发和自测 若是你的公司是属于那荣幸的那一小部门通过了 MFi 会员资历考核，拿到了苹果的 MFi 研发民间文档，也采办了 MFi 样品芯片，那末就可以或许提交产品计划，进行产品研发和自测了。

提交产品计划黑白常关头的一步，需要根据要研发的公司产品的状态、所用技能方案和需要支持的 iOS 设备、iOS 的相干信息都进行细致的描写，此中比力重要信息有。 (1) 附件概览 (Accessory Overview) 技术方案 (Technology) 如果你是做支持 CapPlay 的车机，那么就挑选 CarPlay，否则都应当选择 iAP；如果你的硬件需要跟 iPhone 毗连，并且处置相关业务，而不单单是充电线大要数据线，那么在 Components 里应该选择 Authentication coprocessor。 (2) 固件和硬件 (Firmware & Hardware) 如今全部的 MFi 认证的硬件都需要支持 iAP2 协定，以是必须要选 iAP2 或者同时支持 iAP2 和 iAP1。而后外设硬件跟苹果设备是如何通信的，是操纵 USB 的 Host 情势，还 USB 的 Devices 模式，仍是串口或者蓝牙，这个需要根据产品的需要、特征进行选择。 (3) 选择硬件所支持的 iAP2 的特性 (4) 选择所支持的苹果设备型号 根据产品的计划选择所需要支持的苹果设备型号，包括 iPad，iPhone 和 iPod 的各类型号。 (5) App 相关的信息 这部分也是 iOS 开发者需要重点存眷的部分，包括 App 的版本号，BundleID 和协议字符串以及 iOS App 的主要功效特性描述，这部分信息需要跟最后送 MFi 审核时附带的 App 测试包的信息保持同等。提交了产品计划之后，就可以拿到 PPID (Product Plan ID)。

这个 PPID 也是跟 iOS App 开发者需要关注的。当 App 开发完成，提交 AppStore 上线时，需要在版本审核备注信息里带上这个 PPID，否则审核是过不了的。 接下来就可以进行产品研发了。主要是硬件天生商需要根据苹果提供的开发文档进行硬件和驱动认证步伐的开发。而 iOS App 开发者则主要是需要成 iOS 体系提供的一个系统框架 ExternalAccessory.framework，并且在 info.plist 中设置装备摆设好协议字符串 (Supported external accessory protocols)。当 iOS 设备通过 USB 线或者蓝牙连接到对应硬件时，iOS 系统会把合适 MFi 认证哀求的外设笼统成了一个流工具，App 通过指定的协议字符串来创建一个 EASession 类的实例来访问到该流对象，就能通过 NSInputStream 和 NSOutputStream 跟硬件件进行通信了。这部分功能实现可以参考苹果官方的 进行入门和进修。 产品研发完成后需要进行 ATS (Accessory Test System) 自测，并提供自测陈述。

ATS 自测苹果会提供 ATS Box 的测试工具和软件，主要是针对硬件进行电气特性相关的测试，包括各个节点的电压电流值是否满意苹果要求，然后传输带宽是否不乱，是否到达苹果要求等等。 自测完成之后就可以把硬件和所配套的软件 (iOS App 的 ipa 安装包) 送到苹果指定的测试实验室进行认证测试。iOS 开发者在这个步调需要关注的是如何打包 ipa 包。由于如果间接用开发证书打包，那么苹果测试人员的 iPhone 不在你开发证书的设备列表中，是无法安装的。如果用企业证书打包的话，大概 AppStore 发布证书对应的 BundleID 跟企业证书的 BundleID 纷歧致，所以也不可行。所以推荐的做法是，比及产品研发完成和自测之后，就带上产品计划中拿到的 PPID，提交 AppStore 进行审核。等审核通过之后，就可以直接从 AppStore 下载对应的 ipa 安装包，配合硬件一块儿送 MFi 认证测试了。 三、测试审核和批量生产 这个阶段也是硬件生产商主导进行的，跟 iOS App 开发者干系不大。当硬件的 MFi 认证送审通过之后，还需要对产品的包装也提交认证和审核。

审核通过之后，就可以获得苹果授权进行 MFi 芯片的批量购买，然后根据贩卖计划进行硬件的批量生产和销售了。 整个 MFi 认证的周期大概需要3个月到半年的时辰，并且每次提交认证测试都需要付出一笔600美金的测试用度，所寄去测试的硬件测试样品苹果也是不会寄回来的。 iOS 外设连接黑科技，不需要 MFi 认证，实现 USB 连接 USBMuxd，利用这种连接方法不需要做 MFi 认证，支持 iPhone 上的 App 跟外设通过进行通信，很是便利。 基本原理 iPhone 的 iOS 系统中自带了 USBMuxd 服务，该服务能够实现 USB-TCP 协议的转换，能够把 USB 的端口映射到本机 (localhost) 的 TCP 端 (基于 Unix Domain Socket )。只需要在外设端也实现一个 USBMuxd 服务，并指定端口映射关系， 那 iPhone 的 App 和外设上的应用就可以使用 Socket 进行 TCP 进行通信了。 一个开源实例 开源名目 是一个完备的使用 USBMuxd 方式实现 iPhone App 跟 Mac App 进行 TCP 通信的例子。因为 Mac OS 系统中天生就自带了 USBMuxd 服务，所以 peertalk 的 Mac 端程序是比较简单的。外设一样平常都不会是 Mac 系统，而是 Android 或者 Linux 系统，那怎样办呢？那就自己在系统中集成 USBMuxd 服务，这里可以利用到 实现在外设上集成 USBMuxd 服务。

MFi iOS App 端开发步骤 与附件设备通讯的 App 需设备支持的协议，这些协议由设备制造商保护，但是自界说或标准协议，标准协议可与其他设备通信，iOS不负责这些协议的维护。 为防备定名空间辩论，推荐使用反 DNS 形式命名协议，如 com.apple.myProtocol、com.dji.video、com.dji.protocol、com.dji.common。 1、编程步骤 1.1、引入框架与头文件 外部附件框架 (ExternalAccessory.framework) 为 App 与附件设备通信提供了桥梁。是以，在 Xcode 项目中，需要为每一个与附件设备通信相关的项目增长 ExternalAccessory.framework。 下一步是引入头文件 #import 。 1.2、声明App支持的协议 不声明协议直接挪用EA框架的类会解体。 使用 UISupportedExternalAccessoryProtocols 键在 Info.plist 中声明支持的协议，值为数组，数组的元素为支持的协议，元素的次序肆意且不限数目。这些值只用于判断 App 与附件设备的通信本领。当App与设备通信时，具体通信协议由咱们编程决议。 当附件设备插入 iOS 设备时，系统才晓得 App 可被新插入的设备启动。若以后已安装的 App 都没注册协议，则系统可能到 App Store 去搜刮支持新设备声明的协议的 App。 UISupportedExternalAccessoryProtocols 对应的值虽然说可参考，现实此链接并没给出有帮忙的信息，《MFi Accessory Interface Specification for Apple Devices》也没给出所谓标准协议的字符串值。 1.3、开始通信 创建 EASession。此对象办理与附件设备交互的环境，它与底层系统事变，在设备上来回传输数据。一旦会话建立，数据通过 NSInputStream 和 NSOutputStream 的实例在 App 中传输。收发的数据包的格局由与附件设备通信的协议决定。 接管数据。使用自定义拜托对象，监督 NSInputStream 实例可从附件设备接收数据。 发送数据。向 NSOutputStream 写入数据包便可发送至附件设备。1.4、一个读取外接设备的示例 Info.plist 中加入 Supported external accessory protocols，值为 com.apple.p1。这个只是令系统以为我们的应用有能力与外接设备相同，这里使用 Lightning USB Camera Adapter 测试。

01 ATT ATT全名是AppTrackingTransparency，是Apple为提高用户隐私透明度提供的解决方案，获取IDFA也要符合ATT的要求。目前IDFA需要申请的场景，包括但不限于精准广告推荐、与数据第三方同享设备位置、与广告网络共享ID来定位或者lookalike、应用中放置一个第三方SDK用于第三方广告网络定向。很较着，Apple不但愿IDFA未经用户容许就用于任何的广告定向。 别的，Apple还说有两种情况下，可以跟踪用户且不需要获取用户允许： 当您的应用程序中的员工或设备数据仅连接到用户设备上的第三方数据，并且不会以可辨认用户或设备的方式从设备发送进来与您共享数据的数据代办署理仅将数据用于讹诈检测，防备欺诈或平安目标，并且仅代表您使用。例如，仅使用数据代理来防止信用卡欺诈。这两种情况Apple零丁说进去蛮奇异的，Apple如何能够包管开发者是依照所述要求进行的，而非serve to serve来实现Apple不允许的。

如果单从这两种特别情况来说，对Apple的ATT实行力度是存疑的。 02 SKAdNetwork2.0 SKAdNetwork2.0的团体流程比ATT繁杂一些，触及到的脚色也较多，它实在是Apple针对非IDFA的安装和转化归因的整体方案，是要广告平台、广告主、媒体共同介入才气够实现的。此外，SKAdNetwork2.0是由1.0迭代而来的，1.0用的人很少，2.0增加了一些参数和接口。 SKAdNetwork2.0的主要流程 上图究竟结果只是个流程，看不出来一些细节问题，例如可否把安装归因到某一次暴光？具体各个角色都要做甚么工作？广告网络能否知道转化的发生时间？接下来我们对流程中的每个节点用到的方法、参数等进行详细梳理，才能解决上述问题。 SKAdNetwork2.0的交互流程 1. 广告平台去Apple中注册成为一个广告网络，具有一个广告网络id。除了id以外，有公钥和私钥一对，用以解密Apple在用户安装后回传的信息，公钥要发送给Apple，私钥自行保留。还要提供一个URL，用以接收SKAdNetwork安装验签回发请求。

具体请见：https://developer.apple.com/documentation/storekit/skadnetwork/registering_an_ad_network 2. 广告平台向媒体提供带签名的广告。签名是整个SKAdNetwork2.0关键点。 如何生成签名？ 起首，广告平台要根据所使用的SKAdNetwork版本来选择参数，如果2.0，则拥有以下参数可供选择，版本是指支持的版本： SKStoreProductParameterAdNetworkVersion版本2.0。使用API版本值“ 2.0”。SKStoreProductParameterAdNetworkIdentifier版本1.0和2.0。在Apple上注册的广告网络id。SKStoreProductParameterAdNetworkCampaignIdentifier版本1.0和2.0。广告系列编号。SKStoreProductParameterITunesItemIdentifier版本1.0和2.0。广告主APP的App Store ID，即itunes-item-id。SKStoreProductParameterAdNetworkNonce版本1.0和2.0。是种UUID，是代表每次广告展示的独一值。签名中使用的该随机数的字符串暗示形式必须为小写。

SKStoreProductParameterAdNetworkSourceAppStoreIdentifier版本2.0。媒体APP的应用商店ID。如图source-app-id中的清单3。SKStoreProductParameterAdNetworkTimestamp版本1.0和2.0。代表广告展示时间其次，广告平台对参数和值按照Apple要求进行归并，合并成一条字符串。 然后，广告平台用密钥和Apple提供的算法对合并的字符串加密签名。 最后，将拥有应用调用和启动验签所需的所有必需的“ 广告网络安装验签签名”值。把签名放入广告中，并把广告推给媒体，因此广告网络提供给媒体的API或者SDK都要窜改。 具体请见：https://developer.apple.com/documentation/storekit/skadnetwork/generating_the_signature_to_validate_an_installation 3. 媒体在应用中配置广告网络id。媒体要在一个文件中把需要支持的广告网络id填入，此文件支持多个广告网络id，若某广告网络id不在此文件中，则不会对此广告网络id启动安装验签。 具体请见：https://developer.apple.com/documentation/storekit/skadnetwork/configuring_the_participating_apps 4. 媒体APP表现广告平台提供的带签名的广告。当用户在媒体APP上点击广告时，媒体APP调用App Store视图并代入广告网络提供的签名和验签信息，如许Apple才能知道调起App Store的签名，并把签名带到下一个流程中去。

具体请见：https://developer.apple.com/documentation/storekit/skadnetwork/ad_network_install_validation_keys 5. 用户下载安装广告主APP。 6. 用户打开广告主APP时，广告主APP要调用应用安装验签信息方法。方法是registerAppForAdNetworkAttribution，调用或者初次启动时使用，无需填入其他任何参数，相当于广告主报告Apple说此人打开了我的APP了。Apple会期待广告主APP24小时，若24小时内广告主APP未进入到下个流程，Apple会在之后的24小时当中的随机时间点向广告平台倡议回调，随机时间点也是为了用户隐私吧。PS：其实不需要广告主调用，Apple应该也知道这一次的打开，可能有技术上的困难。 7. 用户在广告主APP上产生转化，广告主APP要调用更新转化值方法。

方法是updateConversionValue(😃，在产生转化时使用，需要传一个int值，6-bit，相当于0-63中的某个值，调用此方法后Apple回调的时间会推延24小时。此方法可屡次调用，可是间隔上一次调用安装（registerAppForAdNetworkAttribution）或转化（updateConversionValue(😃）不克不及跨越24小时，因为超过24小时的话Apple就会发起回调了。多次调用时，后一次的Value要比前一次的大，否则相当于不见效。因此最多会致使64次调用后才会回传给广告平台信息。 我认为ConversionValue更像是转化id而非转化价值，广告主可以基于本身漏斗设计最多64个转化，目前在SKAdNetwork2.0中并不存在转化价值这个参数。 8. Apple把安装和转化信息发送给广告平台注册时填写的URL上。此时就涉及到如何归因，惋惜这方面Apple在文档中没有说得很明白，例如用户看了两个广告网络广告后，在点击后一个广告去安装广告主APP，此时安装信息的发送逻辑，雷同问题另有很多。 9. 广告平台验签收到的安装和转化信息。此时广告平台要支持两种版本的安装和转化信息验签，且只能通过收到的信息中的参数与解密后的签名相验签。生成签名时，用私钥去加密；收到签名后，用公钥去验签息争密。具体参数以下： version版本2.0。与立室的广告网络验签API的版本。

SKStoreProductParameterAdNetworkVersionad-network-id版本1.0和2.0。广告网络idSKStoreProductParameterAdNetworkIdentifiertransaction-id版本1.0和2.0。此验签的唯一值；用于对安装验签消息进行反复数据删除。campaign-id版本1.0和2.0。展示广告时提供的与匹配的广告系列ID 。SKStoreProductParameterAdNetworkCampaignIdentifierapp-id版本1.0和2.0。广告主的APPidattribution-signature版本1.0和2.0。要验签的Apple的署名签名。redownload版本2.0。一个布尔值，批示值为1时用户从新下载并重新安装了该应用程序。source-app-id版本2.0。媒体的APPid。注意：仅当提供的参数满足Apple的隐私阈值时，才会显示。SKStoreProductParameterAdNetworkSourceAppStoreIdentifiersource-appidconversion-value版本2.0。转化id，已安装的应用程序通过调用提供的无标记6位值。注意：仅当已安装的应用程序提供该参数并且提供的参数满足Apple的隐私规矩时，才会显示。updateConversionValue(_:)conversio上述参数中，焦点是attribution-signature签名，若签名被窜改或者非此广告平台的，就会验签失利。通过公钥对签名进行验签和解密后，就可以得到广告平台带入的签名加密前的字符串，而字符串中包含了广告展示ID，即可将安装转化与广告展示ID联系关系起来。（此处很关键，发起实际考证或者找Apple确认）此外，还可用非签名的参数跟签名内的字符串的参数查对，如有冲突即可舍弃此次回传。

文档请见：https://developer.apple.com/documentation/storekit/skadnetwork/verifying_an_install_validation_postback 03 疑难点 1. 归因相关 Apple是否涉及到归因？归因运算逻辑？归因时间周期？点击广告后没有下载，在半途没有点击其他任何广告，用户自行去APP STORE 下载，归因怎么算？先看A广告点击跳转到AppStore，再看B广告并点击跳转到AppStore，传的是A还是B？ 2. 参数相关 redownload 1和0的具体判断逻辑是什么？广告主APP版本跟redownload有啥关系？conversion-value 转化价值的建议用法是什么？说要满足的隐私规则是什么？ 3. 签名相关 在一般情况下，广告网络在生成签名时候的签名，跟安装回传中的签名是否一致？若是，则广告网络是否要根据解密后的签名和其他参数尴尬刁难比？若是，则可以通过广告展示的uuid把安装和曝光关联起来？若是，则有了广告展示的UUID，campaignid还有什么用？ 4. 反作弊相关 通过什么渠道向广告主提供了哪些信息？整套机制是否能有用防止媒体或者广告平台作弊？若是，则整套机制为何能防止？ 04 解决方案 1. 通用id方案 这种方案本色上是探求IDFA的替代品，要根据媒体、广告平台、广告主都能拿到的设备或用户数据，根据这些数据和订定规则去生成一个IDFA的替代品”某某ID”。难点有两个，唯一性和多方承认。要有广泛的唯一性，是作为一个ID的必备能力。而且此方案要遭到多方认可，才能够真正对外使用，否则只是另一个IDFV。 2. Id Mapping方案2、ExternalAccessory框架 1、EAAccessory 提供一个已连接的设备的信息，如制造商，固件版本等。 2、EAAccessoryManager 和谐MFi设备与iOS设备之间的工作。 3、EASession 用来创建 App 与附件设备之间的通信通道。 4、EAWiFiUnconfiguredAccessory 提供未配置的 MFi Wireless Accessory Configuration 设备的信息给 App。 5、EAWiFiUnconfiguredAccessoryBrowser 让 App 访问 MFi Wireless Accessory Configuration 过程。 3、开发本领 Lightning 接了设备则不能连接计算机，所以直观的做法是，将日记用 UITextView 显示出来。写成日志就得每次都拔掉设备，插上电脑，如斯频频。 另一个法子是，通过蓝牙测试传输协议，手机连接电脑，可单步调试。验证完再用 Lightning 连接设备联调。 因自己目前在做对于 iOS App 连接外设方面的工作，因此收集查找相关信息，文章中信息出自于以下简友：、，在此对两位的分享表示感谢。

Protocol和Delegate简介 Protocol协议类似于Java中的接口，是一个自定义方法的调集，让服从这个协议的类去是实现为了达到某种功能的这些方法，与Java接口分歧的是协议中可以定义可选择实现的方法。Delegate代理是一种设计模式，是一个观点，只不过在Objective-C中通过Protocol来进行实现，指的是让其他类来通过本类中定义的协议代理方法‘长途’帮助实现一些操纵，完成一些使命，本类会在符合的机遇通过代理关照实现协议的远程类去做指定的任务。 通过协议实现代理模式的示例 协议代理来历的本类： #import /** * 定义协议 / @protocol AccountDelegate @required // 必须实现的方法，默许是@required // 选中cell的代理变乱 - (void) selectedCell:(NSInteger)index; @optional // 非必须实现的方法 // 更新下拉菜单的高度 - (void) updateListH; @end @interface PopListTableViewController : UITableViewController /* * 定义代理，委托其他类来帮助本类完成一些其他任务，本类通过下面定义的delegate来通知其他实现上面协议的其他类 / @property (nonatomic, weak) iddelegate; @end 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 然后本类在实现中通过定义的delegate通知其他遵守协议的类去执行某个方法： // 通知代理,同时将cell的行号传出去 [_delegate selectedCell:indexPath.row]; 1 2 然后遵守协议的类就可以收到上面的通知主动执行（注意是通知触发的方法执行，是一种回调而不是手动调用）selectedCell这个方法了： 首先要在实现中声明遵守上面的协议： // 遵守AccountDelegate协议，如果遵守多个协议用逗号离隔： @interface PopMenuViewController() 1 2 实现协议方法： /* * 实现协议方法，监听代理,代理通知来了后下面的方法会自动执行，接收传过来的参数 */ - (void)selectedCell:(NSInteger)index { // 这里可以做一些事情，也便是想委托当前这个类要做的那些任务了 // … } 1 2 3 4 5 6 7 问题1： Difference between protocol in Objective-C and interfaces in Java?Objective-C中的协议和java中的接口概念有何不同？ Objective-C中的协议和java中的接口非常类似，但Java中的接口划定实现接口的类必须要实现接口中定义的所有方法，当然默认Objective-C协议中定义的方法也是要必须实现的，只不过Objective-C的协议里的方法有两种范例：必选类型（@required）和可选类型（@optional）。

必须类型是必须要实现的，而可选类型是根据需要选择性实现的。默认是必选类型。 问题2： OC中协议的概念以及协议中方法的默认类型？ OC中的协议类似于Java中的接口，是一个功能方法的集合，但协议本身不是一个类不会自己去实现协议里的方法，而是委托其他任何类去使用实现，凡是用来实现委托代理设计模式，实现不同类对象之间的事件消息通信。 协议中的方法默认都是@required类型的，也就是使用该协议的类必须实现协议里的这些方法。而明白使用@optional润饰的方法可以被使用的类选择性的去实现。 问题3： 什么是代理？感化是什么？ 代理是一种设计模式，又叫‘委托’，指的是一个类对象在某些特按时刻通知到其他类的对象去做一些任务，但不需要获取到那些类对象的指针，二者共同来完成一件事，实现不同对象之间的通信。 作用主要是大大减小了对象之间的耦合度，是代码逻辑加倍清楚有序，削减了框架复杂度，也便于代码的维护扩大。别的消息的通报过程可以有参数回调，类似于Java的回调监听机制，大大提高了编程的灵活性。 这种方案本质上类似PC WEB的cookie mapping，通过广告平台的ID和广告主的ID Mapping，来解决IDFA的问题。

难点也有两个，如何mapping和如何提高mapping浓度。我有个方案是在A APP调起/唤醒B APP时进行mapping，但是mapping是要涵盖拉新、拉活等多种场景的，我这种方案只能解决拉活，而且mapping浓度也无法保证。 3. IDFA+IDFV加密方案 这种方案是adjust提出来的，本质上就是看Apple能不能睁一眼闭一眼。首先，在广告主真个对广告主的IDFA和IDFV构成一个hash。然后，把这个hash和广告主的IDFV传到媒体APP客户端上。其次，在媒体当地上用媒体的IDFA和广告主的IDFV组成一个hash。最后，在媒体本地比较这两个hash是否一致。此方案就是用到了上文ATT标蓝的内容，认为这种方案不会以可识别的方式把IDFA收回去。Apple是否认为这种方案就是符合隐私要求的，这是要打个问号的。 总之，Apple的小改动对付整个iOS不算什么，但是在互联网广告中掀起了暴风骇浪，到目前也没有业内告竣共鸣的解决方案。ATT和SKAdNetwork2.0的推出，确切对用户隐私是利好，但是也会滋长以头部综合广告平台为代表的围墙花圃态势。经此一役，大家又回到同一个起跑线上，有危害就有机遇，希望同行同业能够一起面临。