《iOS系列之不看别后悔》NS_DEPRECATED_IOS、N

苹果公司已成立10周年，10年来，Xcode内部大量api被废弃，但是有时候，为了兼容低版本，我们不得不使用被废弃的api，这样可能会使我们的代码看起来冗余而又复杂，甚至是条理不清。
通常，当我们从APP跳转至第三方应用，实现分享、支付等功能后，返回APP时，需要处理分享、支付等结果。
可能大多数人都会实现如下三个方法：

处理分享、支付等结果
细心的朋友已经发现，在每一个方法上面，我都写有一句注释：
NS_DEPRECATED_IOS(2_0, 9_0)、
NS_DEPRECATED_IOS(4_2, 9_0)、
NS_AVAILABLE_IOS(9_0)。
当然，这种写法并非我个人所创，而是Xcode内部标明api信息的简单宏定义。单词DEPRECATED的意思是废弃的，单词AVAILABLE的意思是可用的，于是这种宏定义的意义就显而易见了。
NS_AVAILABLE_IOS(9_0)表明该api自iOS 9.0时启用，
NS_DEPRECATED_IOS(2_0, 9_0)表明该api自iOS 2.0时启用，到iOS 9.0时被废弃，但是被废弃的api并非不能使用，而是建议开发者使用相应的api进行替换。

下面开始划重点，还拿这三个方法举例，我们为了兼容低版本，于是乎把三个方法全部实现了，那么当我们从第三方应用返回APP时，这三个方法会全部调用吗？
答案是不会全部调用，但是会调用其中的一个。

那么，这种api的调用机制是什么，经过反复的测试和严密的推断，我做出大胆猜想：应用程序会优先调用当前iOS系统内未被废弃的api。

在此处，我们暂且把如上三个方法简称为方法一、方法二和方法三。
若是运行在iOS10系统上，由于方法一、方法二均被废弃，因此调用方法三，
若是运行在iOS8系统上，由于方法一被废弃，方法三未启用，因此调动方法二。

为了验证这个结论，我找到了类似情况的api（推送）进行测试，与预期结果完全一致。

接收推送

至此，困扰我许久的问题终于解决，如果大家还有什么好的建议或想法，欢迎留言。
我们是伟大的程序员，我们天生爱分享！