搜索

利用Swift API可用性解决App Extension无法编译问题

知识小集

共 12769字，需浏览 26分钟

 · 2021-08-23



目录

  • 问题

  • 探索

  • 平台可用性

  • API可用性

  • #available

  • 函数调用链

  • 协议函数

  • Objective-C函数API

    • 普通API

    • 重写系统方法的API

问题

从Xcode12.5开始，苹果要求所有的Extension Target必须设置APPLICATION_EXTENSION_API_ONLY为true，否则将会导致编译错误“Application extensions and any libraries they link to must be built with the APPLICATION_EXTENSION_API_ONLY build setting set to YES”；但是我们通常会在主工程和Extension之间使用Framework或其他方式共享代码，这些代码中使用了非extension-only API，所以导致问题出现，本篇文章将探讨如何解决这个问题。

探索

我们以一个具体的工程结构为例，如下图所示：

我们的主工程Host App中，创建了一个Share Extension的扩展Target做分享相关的操作；另外，为了模块化，我们有一个Library工程包含所有的基础组件和Fundation扩展方法，NetworkService工程包含网络请求相关的功能封装和处理，他们都被编译为Framework供主工程和Share Extension共同使用；

我们首先需要把Share Extension、Library、NetworkService这三个工程的Build Setting中APPLICATION_EXTENSION_API_ONLY设置为true；由于我们在Library和NetworkService中都使用了UIApplication.shared.open，UIApplication.shared.keyWindow这类非extension-only的API，所以编译这两个子工程是无法通过的。

首先想到的解决办法是代码拆分，我们可以把Library按是否使用extension-only API进行拆分，拆分成两个工程Libray和LibraryExtension，LibrayExtension中包含符合extension-only的API，提供给Share Extesnion使用；Library中包含其他不设限API，提供给主工程或其他非Extesnion工程使用；

然后NetworkService也采用相同方法进行改造，这种方式是可以解决问题的，但是除了拆分代码创建新工程的代价，也会带来很多额外的工作量；比如主工程中Host App，原来都是引用import Library，现在就需要逐个修改确认，是使用Libray还是LibraryExtension，或者添加同时引用两个，这对于一个已有的大工程来说，是一个不小的工作量；

另外，笔者在搜索这个问题的解决方式时，发现swift-cast网站作者提供了一个另外的解决方案：使用ACTION_EXTENSION；如果你的App恰好使用的是Action Extension可以采用这个方式去尝试：

#if !ACTION_EXTENSION
    //codes that don't obey extension-only API requests
#else
    //normal codes 
#endif 

显然，上面的两种方式都有各自的局限性，所以我们需要寻找更加广泛使用的解决方案，改动更小的解决方案；Swift语言提供了API可用性的标识，这个功能能够解决我们所遇到的问题，下面我们先来了解一下Swift的API可用性。

Swift的API可用性（API availability）

在Swift中使用@available可以标记API的可用性信息，比如是否API在某个版本被废弃，这个API需要的Swift版本大于5.4才能使用，等等。我们来看几个具体方面：

平台可用性

@available(iOS 13.0, OSX 10.15, *)
@available(tvOS, unavailable)
@available(watchOS, unavailable)
public struct SearchField: View{
    ...
}

在SwiftUI中我们定义一个SearchField组件，就需要对其适用的平台和系统版本进行限制，上面这段代码表明，SearchField适用于大于等于iOS13或OSX 10.15版本，同时针对tvOS和watchOS都是不可用的。

具体注释定义如下：

@available(platform version , platform version ..., *)
  • platform：指定具体适用的平台，比如iOS, macCatalyst, macOS/OSX, tvOS 或者 watchOS，还可以指定适用的扩展Extension Target，比如ApplicationExtension或macOSApplicationExtension，这是解决文章开头提出的问题的重要工具，这部分稍后将详细介绍；
  • version：具体的数字，可以由一位、两位或三位正整数通过点号（.）分割组成，分别代表主版本号，次版本号，补丁版本号；
  • 可以有多个platform+version组成，之间用逗号分隔（,），比如@available(iOS 13.0, OSX 10.15, *)；
  • 星号(*)，表示该API可用于所有其他平台。为了处理潜在的未来平台，平台可用性注释总是需要一个星号；

API可用性

我们在软件开发过程中会不断改进，引入新的API，废弃旧的API，与此对应的@available可以进行这部分工作API的标记。

// With introduced, deprecated, and/or obsoleted
@available(platform | *
          , introduced: version , deprecated: version , obsoleted: version
          , renamed: "..."
          , message: "...")

// With unavailable
@available(platform | *, unavailable , renamed: "..." , message: "...")
  • platform：与前面介绍一致；
  • introduced, deprecated, obsoleted：API在指定版本开始可以使用，标记introduced；API即将在指定版本被废弃，标记deprecated，使用此API时编译产生警告；API在指定版本开始被淘汰，标记obsoleted，使用此API时编译产生错误。
  • unavailable：通过与platform配合使用，表示指定平台版本API不能使用，如果在此情况下使用此API将会产生编译错误。
  • renamed：当使用此API时提供另一个API用来替换当前API，当有此标识时Xcode提供了一个自动修复选项。
  • message：在编译警告或错误发生时，提供一个字符串说明给使用者。

与平台可用性不同，这种形式只允许指定一个平台。因此，如果你想注释多个平台的可用性，你需要使用多个@available属性。例如，下面是简单示例如何表示多个平台:

@available(macOS, introduced: 10.15)
@available(iOS, introduced: 13)
@available(watchOS, introduced: 6)
@available(tvOS, introduced: 13)

#available

在Swift中，你可以使用可用性条件#available来断言if、guard和while语句，以确定运行时API的可用性。与@available属性不同，#available条件不能用于Swift语言版本检查。

#available表达式的语法类似于@available属性:

if | guard | while #available(platform version , platform version ..., *) …

不能使用&&和||等逻辑操作符组合多个#available表达式，但可以使用逗号，它们等价于&&。在实践中，这只对调整Swift语言版本和单个平台的可用性有用(因为对多个平台的检查要么是多余的，要么是不可能的)。

// 要求Swift 5 和 iOS 13
guard #available(swift 5.0), #available(iOS 13.0) else { return }

注意，#available没有对应的unavailable标识，只能判断符合条件的；

解决问题

有了前面介绍的基础知识，我们来讨论本文开头提出的“App Extension无法编译通过”的具体解决方案：使用@available对API做函数级别的平台API标记；

以下面gotoAppSystemSetting函数为例：

    @available(iOSApplicationExtension, unavailable, message: "This method is NS_EXTENSION_UNAVAILABLE.")
    @available(watchOSApplicationExtension, unavailable, message: "This method is NS_EXTENSION_UNAVAILABLE.")
    @available(tvOSApplicationExtension, unavailable, message: "This method is NS_EXTENSION_UNAVAILABLE.")
    @available(iOSMacApplicationExtension, unavailable, message: "This method is NS_EXTENSION_UNAVAILABLE.")
    @available(OSXApplicationExtension, unavailable, message: "This method is NS_EXTENSION_UNAVAILABLE.")
    static func gotoAppSystemSetting() {
        if let url = URL(string: UIApplication.openSettingsURLString) {
            if UIApplication.shared.canOpenURL(url) {
                UIApplication.shared.open(url, options: [:], completionHandler: nil)
            }
            
        }
        
    }

由于函数中使用了UIApplication.shared.open这类Extension不能使用的API，所以需要增加Extension不可用@available标记。

这样修改之后，由于明确的标记了API的可用性范围，开启APPLICATION_EXTENSION_API_ONLY为true之后，编译也可以正常通过。

函数调用链

单个API函数问题解决后，你还需要考虑函数调用的链，比如在函数A中使用了UIApplication.shared.keyWindow，那么A函数就需要标记为不能Extension使用的API；

@available(iOSApplicationExtension, unavailable, message: "This method is NS_EXTENSION_UNAVAILABLE.")
func A() {
    ...
    //调用UIApplication.shared.keyWindow
    ...
}

接下来，如果有函数B调用了函数A，函数C都调用了函数B，那么函数B和C也都需要上述相同的@available标记；

@available(iOSApplicationExtension, unavailable, message: "This method is NS_EXTENSION_UNAVAILABLE.")
func B() {
    ...
    A（） //函数B中调用A函数
    ...
}

@available(iOSApplicationExtension, unavailable, message: "This method is NS_EXTENSION_UNAVAILABLE.")
func C() {
    ...
    B（） //函数C中调用B函数
    ...
}

协议函数

接下来，我们继续看协议函数相关的一个问题。有一个协议DialogueViewProtocol，声明了一个show方法如下面代码所示：

public protocol DialogueViewProtocol{
    func show(cancelHander acancelHander:(() -> Void)? ,comfirmHander acomfirmHander:(() -> Void)?)
}

我们有两种样式DialogueView组件需要实现，分别是DialogueView_1和DialogueView_2，为了抽取共同代码，它们都继承自DialogueView；

//DialogueView_1继承DialogueView
public class DialogueView_1:DialogueView{
   
}
//DialogueView_2继承DialogueView
public class DialogueView_2:DialogueView{

}
//DialogueView_1遵守DialogueViewProtocol实现show函数
extension DialogueView_1:DialogueViewProtocol{
    public func show(cancelHander acancelHander: (() -> Void)?,comfirmHander acomfirmHander:(() -> Void)?){
     ...
     //不同的内部实现
    }
    
//DialogueView_2遵守DialogueViewProtocol实现show函数    
extension DialogueView_2:DialogueViewProtocol{
    public func show(cancelHander acancelHander: (() -> Void)?,comfirmHander acomfirmHander:(() -> Void)?){
     ...
     //不同的内部实现
    }

在具体实现两个不同样式的DialogueView子类时，它们都遵守DialogueViewProtocol，实现了不同的show方法；

在show函数中两个方法都用到了UIApplication.shared.keyWindow，显然都无法被Extension使用，所以需要对show方法进行前面相同的@available(iOSApplicationExtension, unavailable, message: "This method is NS_EXTENSION_UNAVAILABLE.")标注，这样修改之后，API不被Extension使用的问题解决了，但是又引出了新的问题，导致show方法不可见，两个子View没有实现遵守DialogueViewProtocol协议；

那么怎么来解决呢？我们需要继续改造代码，在DialogueView基类中实现协议，来解决这个问题；

//基类DialogueView遵守DialogueViewProtocol
extension DialogueView:DialogueViewProtocol{
    public func show(cancelHander acancelHander:(() -> Void)? ,comfirmHander acomfirmHander:(() -> Void)?){
        //空实现
    }
}

extension DialogueView_1{
//标记，复写show函数
    @available(iOSApplicationExtension, unavailable, message: "This method is NS_EXTENSION_UNAVAILABLE.")
    public override func show(cancelHander acancelHander: (() -> Void)?,comfirmHander acomfirmHander:(() -> Void)?){
        ... 
    }
}

extension DialogueView_2{
//标记，复写show函数
    @available(iOSApplicationExtension, unavailable, message: "This method is NS_EXTENSION_UNAVAILABLE.")
    public override func show(cancelHander acancelHander: (() -> Void)?,comfirmHander acomfirmHander:(() -> Void)?){
        ...
    }
}

DialogueView遵循DialogueView，实现了show函数的空实现，然后在DialogueView_1和DialogueView_2中重写（override）show函数，需要注意DialogueView中show函数因为不使用Extension限制API，所以无需@available标记，而DialogueView_1和DialogueView_2是需要的。

Objective-C函数API

使用Objective-C编写的函数也可能是用了Extension不可用的API，Objective-C语言也提供了NS_EXTENSION_UNAVAILABLE_IOS对其进行标记，系统函数中有很多这样的例子：

./EventKitUI.framework/Headers/EKEventViewController.h:NS_EXTENSION_UNAVAILABLE_IOS("EventKitUI is not supported in extensions")
./Foundation.framework/Headers/NSObjCRuntime.h:#define NS_EXTENSION_UNAVAILABLE_IOS(_msg)  __IOS_EXTENSION_UNAVAILABLE(_msg)
./UIKit.framework/Headers/UIAlertView.h:- (instancetype)initWithTitle:(NSString *)title message:(NSString *)message delegate:(id /*<UIAlertViewDelegate>*/)delegate cancelButtonTitle:(NSString *)cancelButtonTitle otherButtonTitles:(NSString *)otherButtonTitles, ... NS_REQUIRES_NIL_TERMINATION NS_EXTENSION_UNAVAILABLE_IOS("Use UIAlertController instead.");
./UIKit.framework/Headers/UIApplication.h:- (void)beginIgnoringInteractionEvents NS_EXTENSION_UNAVAILABLE_IOS("");               // nested. set should be set during animations & transitions to ignore touch and other events

具体针对iOS来说：

NS_EXTENSION_UNAVAILABLE_IOS（"..."）

标记Extension不能使用这些API,后面有一个参数，可以作为提示，用什么API替换

普通API

在头文件中对函数添加标记

+ (UIImage *)launchImage NS_EXTENSION_UNAVAILABLE_IOS("");

重写系统方法的API

如果是重写了系统方法，比如继承UIViewController，重写了statusBarStyle，那么对其进行标记就需要在实现函数中

- (UIStatusBarStyle)statusBarStyle NS_EXTENSION_UNAVAILABLE_IOS("") {
    return [UIApplication sharedApplication].statusBarStyle;
}

结语

由于Xcode12.5新版本带来的变化，导致我们需要利用Swift语言API可用性的标记，对不合符extension-only的API进行@available(iOSApplicationExtension, unavailable)标记，Objective-C语言也有对应的NS_EXTENSION_UNAVAILABLE_IOS（"..."）标记可以使用；你也需要对当前标记函数调用链上的上游函数增加标记，另外，你也可能需要针对协议函数，实现默认实现，以解决标记@available不可见问题。

引用

  • https://stackoverflow.com/questions/33308196/checking-for-protocol-availability-in-swift
  • https://forums.swift.org/t/availability-checking-for-protocol-conformances/42066/8
  • https://www.cnblogs.com/lxlx1798/articles/13060713.html
  • https://apollozhu.github.io/2017/06/20/swift-and-ns-extension-unavailable/
  • https://swift-cast.com/2021/04/38/
  • https://nshipster.com/available/
  • https://davedelong.com/blog/2019/04/09/conditional-compilation-part-3/

浏览 19
点赞
评论
收藏
分享

手机扫一扫分享

举报
评论
图片
表情
推荐
APP 安全测试项总结
一、安装包测试　　1.1、关于反编译　　目的是为了保护公司的知识产权和安全方面的考虑等，一些程序开发人员会在源码中硬编码一些敏感信息，如密码。而且若程序内部一些设计欠佳的逻辑，也可能隐含漏洞，一旦源码泄漏，安全隐患巨大。　　为了避免这些问题，除了代码审核外，通常开发的做法是对代码进行混淆，混淆后源代
测试开发技术
0
展讯平台手机重启问题分析指南
和你一起终身学习，这里是程序员Android经典好文推荐，通过阅读本文，您将收获以下知识点:一、 User 版本 默认开启 sysdump 方法二、插入SD卡 抓取Sysdump log三、 sysdump log 分析四、展讯平台抓取重启 串口log的方案五、展讯平台判断重启类型六、展讯平台关闭
程序员Android
0
字节员工：35岁以后被裁员的，后来都走了哪条路？现在2-2，要不要利用最后一年拼命上个岸。
架构师大咖 架构师大咖，打造有价值的架构师交流平台。分享架构师干货、教程、课程、资讯。架构师大咖，每日推送。 公众号该公众号已被封禁在当今竞争激烈的职场环境中，年龄并不总是一个决定性
源码共读
0
字节面试：如何解决MQ消息积压问题？
面试题大全：www.javacn.siteMQ（Message Queue）消息积压问题指的是在消息队列中累积了大量未处理的消息，导致消息队列中的消息积压严重，超出系统处理能力，影响系统性能和稳定性的现象。1.消息积压是哪个环节的问题？MQ 执行有三大阶段：消息生产阶段。消息存储阶段。消息消费阶段。
Java中文社群
0
Stability AI开放Stable Diffusion 3 API，在线免费使用
「Stability AI」宣布开放其最新文本到图像生成模型「Stable Diffusion 3」的API接口，供开发者和企业使用。该模型采用创新的多模态扩散转换器架构，在字体、细节还原、提示理解等方面表现优异，评测结果超越了业内其他顶尖系统。与DALL-E 3和Midjourney v6等最先进
IQ前端
0
【第126期】效地利用AI辅助编程并提高编程效率
概述 AI可以在编程的多个环节中提供帮助，从而显著提高编程效率。同时，也要注意AI工具的选择和使用，确保它们能够真正提升你的工作效率，而不是成为额外的负担。通过这些工具通过不同的方式辅助编程，包括代码生成、错误检测与修复、代码审查、自动化测试、性能优化等，旨在提高编程效率和代码质量。开发者可以根据
前端微服务
0
【第124期】Vue 3 组合式 API 的瑞士军刀（VueUse）
概述 今天，我们要深入探索一个强大的工具集——VueUse。它为 Vue 3 的组合式 API（Composition API）提供了超过 200 个实用函数，让你的开发工作更加得心应手。官方网站：https://vueuse.org/VueUse 是什么？VueUse 的官方网站是 https:
前端微服务
0
排名问题新解法：探索可视化计算中的 RANK 函数
上次我们介绍了可视化计算替代 DAX 计算的一些场景。参考：PowerBI 进阶：可视化计算替代 DAX 场景探索今天我们介绍一个新的场景，这是一个困扰许多人的问题，排名问题。在 DAX 中，很多新手小白对于上下文概念还不太理解，但在处理排名问题时又要求你必须理解一些上下文，比如常见的绝对排名和相对
PowerBI战友联盟
8
想都是问题，干就有答案，今天收获2个成绩
觉醒的拉新活动终于结束我以加入涛哥战队的方式去做的这次拉新活动最终排名是第4，没进前三虽然有遗憾，但还是从这个活动中学到了很多东西。为什么我要参与这个活动呢？参加这个拉新活动目的绝不是为了赚这个佣金，虽然我也能分到几千块，如果纯粹地为了赚这个佣金，其实是一个投入产出比极低的事情。最主要的还是奔着学习
python之禅
0
性能爆表：SpringBoot利用ThreadPoolTaskExecutor批量插入百万级数据实测！
关注我们,设为星标,每天7:40不见不散,架构路上与您共享回复架构师获取资源大家好，我是你们的朋友架构君，一个会写代码吟诗的架构师。来源：azdebug.blog.csdn.net/article/details/103697108前言具体实现细节测试结果总结前言开发目的： 提高百万级数据
Java架构师社区
0
点赞
评论
收藏
分享

手机扫一扫分享

举报