“踩坑”经验分享:Swift语言落地实践

发布时间:2023年12月28日

作者 | 路涛、艳红

导读

Swift 是一种适用于iOS/macOS应用开发、服务器端的编程语言。自2014年苹果发布 Swift 语言以来,Swift5 实现了 ABI 稳定性、Module 稳定性和Library Evolution,与Objective-C(下文简称“OC”)相比,Swift 在开发效率、安全、编译优化、运行性能和内存管理方面具有显著优势。(官方博客:https://www.swift.org/about/ )

百度App 已在工程和环境上支持 Swift 开发,百度搜索大前端团队负责搜索服务的稳定落地,我们积极探索 Swift的应用,希望能大幅提升开发效率和灵活性、提升端用户的搜索体验。然而,在实施过程中可能会遇到各种问题,例如代码陈旧且不支持Swift,人员对Swift掌握不够熟练、意识不足,协作方对Swift的支持不足等。

对于其他语言来说,Swift相对年轻,我们在实践过程中整理一些常见问题及其解决方法,希望能帮助读者更顺利地使用Swift进行编程,提高研发效率。

全文6947字,预计阅读时间18分钟。

01 Swift 适用场景

在决定是否引入Swift前,我们需要判断场景是否适合。通常情况下,可以用OC的场景均适合使用Swift,但也有一些不太适合直接替换的场景,需要慎重,比如:

1、涉及OC动态性,频繁在runtime时操作属性和方法;

2、核心基础功能,出现问题影响面较大的逻辑;

3、调用C++(目前Swift不能直接调用C++);

4、继承不支持Swift组件的类。

此外,对使用OC比较久远的工程,使用Swift前也应注意:

1、能在工程环境和单独模块上支持Swift;

2、模块较多的工程,可以内外OC和Swift混编;

3、为了避免Swift Waring带来的潜在问题,可以把SWIFT_TREAT_WARNINGS_AS_ERRORS设置为YES,这样警告会作为错误,辅助程序员更好的规范代码;

4、模块Module化后,要注意维护 umbrella header 中的公开头文件。

注:本文中的“组件”均指代工程中的“Target”。

02 Swift的基本用法

2.1 Swift 的字符串为什么这么难用?

如:字符串不能通过索引取字符

  • 原因:Swift认为字符串是由一个个字形群集(grapheme clusters) 组成的,字形群集的大小不固定所以不能用整数去索引 (字形群集其实就是Swift中的Character(字符)类)。

  • 解决方案:如要通过下标取字符可以为String添加扩展在下标subscript实现通过传入Int索引,在subscript转为String.index获取对应字符的方式。

2.2 try try? try! 的区别

当你进行文件操作时,可能会遇到需要使用try、try?和try!的情况。它们在异常处理方面有所不同。

1、使用try时,如果出现异常,程序会进入异常处理流程,你可以在catch语句块中处理这个异常。

2、使用try?时,如果发生异常,它不会进入异常处理流程,而是返回一个可选值类型。也就是说,如果出现异常,它将返回nil。

3、使用try!时,它不允许异常继续传播。一旦出现异常,程序会立即停止执行。

因此,在文件操作中,你可以根据需要选择合适的异常处理方式。在百度App中一般推荐使用try?。

2.3 public 和 open 的区别

在Swift语言中,public和open都是用于在模块中声明需要对外界暴露的函数的关键字,但它们在继承和公开程度上有所不同。

1、public关键字修饰的类在模块外部无法被继承。 这意味着,如果其他模块试图继承这个类,编译器会报错。这样的限制可以保护类的完整性,但也可能限制了其在其他模块中的可重用性。

2、open关键字则允许任意继承。 如果一个类被open关键字修饰,那么其他模块中的类可以自由地继承这个类,不受任何限制。这样的公开程度使得open关键字修饰的类在模块间的重用性和扩展性更加灵活。

从公开程度上来说,public的限制比open更严格,所以可以说public < open,即public的公开程度比open要低。

2.4 解析JSON情况

在Swift中解析JSON的情况,如果自行将JSON转换为字典,需要涉及到类型判断、转换等操作,代码比较复杂。这时可以使用第三方库SwiftyJSON、ObjectMapper或者系统库JSONEncoder来简化操作,提高开发效率。

2.5 UIView子类必须添加init?(coder decoder: NSCoder)的原因

1、这是NSCoding protocol定义的,遵守了NSCoding protocol的所有类必须继承。只是有的情况会隐式继承,而有的情况下需要显示实现。

2、当我们在子类定义了指定初始化器(包括自定义和重写父类指定初始化器),那么必须显示实现required init?(coder aDecoder: NSCoder),而其他情况下则会隐式继承,我们可以不用理会。

3、当我们使用storyboard实现界面的时候,程序会调用这个初始化器。

4、注意要去掉fatalError,fatalError的意思是无条件停止执行并打印。

2.6 Swift类和子类的初始化

Swift的类和子类初始化涉及到两个关键阶段。首先,确保所有的存储属性被赋予初始值,然后,在实例准备使用之前,可以自定义存储属性的值。为了确保这两个阶段成功,实施了四步安全检查,详细如下:

1、在完成本类所有存储属性赋值之后,指定构造器才能向上代理到父类的构造器。

2、在为继承的属性设置新值之前,指定构造器必须向上代理调用父类构造器。

3、便利构造器必须先调用其他构造器,再为任意属性(包括所有同类中定义的)赋新值。

4、在第一阶段构造完成之前,构造器不能调用任何实例方法,不能读取任何实例属性的值,不能引用self作为一个值。

总之,类初始化必须完成的一个任务就是让所有的存储属性都有初始值(optional 除外)。如果父类有指定初始化,子类必须也有指定初始化,并且必须调用父类的其中一个指定初始化(如果是必须初始化,就是重载),并遵循两段式初始化的规则。一个便利初始化必须调用同一类中的初始化方法(可以是另一个便利初始化,也可以是指定初始化),但最终一定会调用到一个指定初始化。便利初始化不遵循两段式初始化的规则,不能被子类调用或者重载。

03 OC与Swift的互相调用及跳转

3.1 组件内Swift文件调用公开OC头文件

  • 将公开OC头文件(如:xyz.h)添加到组件(如:ABC)umbrella header中(如:#import);

  • Swift文件中直接调用公开OC头文件内容。

3.2 组件内Swift文件调用非公开(私有)的OC文件

组件应该尽可能少的公开暴露头文件,但Swift和OC混编不可避免使用OC非公开头文件,因此我们可以采取以下措施:将Framework 中将私有头文件声明为一个私有 module(modulemap内声明),由组件内的 Swift 源码 import 该私有 module 即可。

1、创建Private.modulemap文件,以NewModule做为组件名为例,可以命名为NewModule.private.modulemap,内容为下,module后面加_Private

  • 罗列头文件的形式
framework module NewModule_Private {
  header "xxxxx.h"
}
  • 使用根头文件的形式,添加头文件NewModule_Private.h
framework module NewModule_Private {
  umbrella header "NewModule_Private.h"

  export *
  module * { export * }
}

2、在组件build settings中配置MODULEMAP_PRIVATE_FILE路径,MODULEMAP_PRIVATE_FILE=‘NewModule.private.modulemap’;百度App中在NewModule.boxspec中如下代码设置路径;

s.xcconfig = {
    'MODULEMAP_PRIVATE_FILE' => '${BOX_ROOT}/NewModule.private.modulemap'
}

3、将NewModule.private.modulemap添加到工程目录;百度App中在NewModule.boxspec中如下代码设置路径;

s.refer_files = [
      "NewModule.private.modulemap",
]

4、将xxxxx.h设置为Private header,百度App中在NewModule.boxspec中如下代码设置xxxxx.h到Private header

s.private_headers = [
    "Sources/xxxxx.h"
  ]

5、调用方式

import NewModule_Private
let objectX = xxxxx()
print(objectX)

注意:

  • 添加的Private头文件可能存在传递头文件的情况,即import其他头文件,也需要将传递的头文件添加到NewModule_Private中,同时import需要使用尖括号;

  • Private Header也会暴露在framework中,所以可以约定外部组件使用Public Header,而避免使用Private Header,因为随着业务发展和Swift&OC混编,Private Header是不稳定的。

3.3 组件内OC文件如何调用Swift文件?

  • Swift 类需要继承 NSObject,方法前面加上@objc 标识,并且是 public 或者 open 的;

  • 引入方式 #import"

3.4 OC中的向前声明,被Swift文件引用该组件会报错

如error: cannot find protocol definition for ‘xxxProtocol’

  • 原因:此报错在OC中是代码警告,百度App中默认情况Swift中SWIFT_TREAT_WARNINGS_AS_ERRORS 设置为 YES,导致OC中的Warning视为Error;

  • 解决方案:三选一

1、暂时设置 SWIFT_TREAT_WARNINGS_AS_ERRORS 为 NO

2、import xxxProtocol 不要向前声明

3、使用 pragma 忽略警告

3.5 Swift怎么用OC定义的宏?

  • 在Swift中,能直接使用定义为常量的宏,不能使用带有方法调用的宏,也不能使用静态常量。
下面这种定义为常量的宏可以使用
#define APP_LANGUAGE_EN @"en" 
#define kNavigationBarHeight 44.0

下面带有方法调用的宏不可以使用
#define kScreenHeight [[UIScreen mainScreen] bounds].size.height
#define kScreenWidth [[UIScreen mainScreen] bounds].size.width

下面带有静态常量swift不能使用,可以改成宏
static NSString *const StopTabRefreshNotifyNameHtml = @"TabRefreshNotifyNameHtml";

3.6 Swift与OC泛型的混编

  • 在我分们基础框架中,有一个使用了OC泛型的类,如:
@interface BBAXYZ<T> : NSObject <BBAXYZEventProtocol>  
@property (nonatomic, weak) T page;  
@end

这个泛型的使用导致无法使用Swift来继承和开发BBAXYZ的子类。然而,这个基础框架是业务的核心部分,因此,我们需要在未来支持Swift的开发。

  • 经过仔细观察和分析,我们发现泛型主要被用于指定page属性的类型。因此,我们可以考虑去掉泛型,改为提供一个返回适当类型的方法。这样,我们就可以在Swift中顺利地继承和使用这个基础框架。修改后的代码如下:
@interface BBAXYZ : NSObject <BBAXYZEventProtocol>  
- (id<BBAXYZEventProtocol>)page;  
@end

然后,我们可以创建一个OC类来实现这个基础框架,并让所有的子类继承这个OC类并实现 page 方法,以返回适当类型的对象。这样,我们就可以在Swift中顺利地继承和使用这个基础框架。

例如:

@interface BBAABC : BBAXYZ  
- (UIViewController<BBAXYZEventProtocol> *)page; 
@end

需要注意的是,虽然这样的修改增加了轻量级的中间OC类,但它仍然实现了Swift与OC的混编,并允许我们在Swift中开发新的子类。这种方式既保证了代码的兼容性,又使得我们可以继续利用OC的优点。

  • 使用方式
class BBAEFG: BBAABC {
    
}

3.7 Swift调用OC接口,OC的nullability标注使用时的注意事项

问题场景:

1、OC 接口定义为 nonnull,swfit 调用时正常是当做不可选类型使用,这时如果 OC 接口不规范返回 nil,则出现运行时崩溃。

2、OC 接口未定义 nonnull 或 nullable,在这种情况下,编译器会将 OC 的指针类型当成是隐式解析可选类型(例如 String!)导入到 Swift 中。swift 调用时,OC接口如果返回 nil,将会因为隐式解析一个为 nil 的可选值导致运行时崩溃。

解决方式:

1、Swift 调用 OC 接口时,如果 OC 的接口声明为 nonnull 或未指定 nullability 时,只有明确 OC 接口不为空的情况下才可调用

2、在 OC 环境下,将 nil 赋值给 nonnull 指针也没有关系,编译器只会产生警告。这就需要程序员按规范编写 OC 代码,正确使用 nullability 标注,并增加运行时判空的断言,以支持向后兼容。

04 其他常见问题

4.1 Xcode编译只提示编译错误,提示信息非常少

  • 原因:使用Swift语言开发的组件,依赖了不支持Module化的组件,导致组件都能编译成功,但整个工程却编译失败了;

  • 解决方案:二选一

1、检查并保障所有依赖的组件都已经Module化了,如配置build settings;

2、在组件中新增Swift文件(空文件也行)。

4.2 由于组件开启了Library Evolution 导致的编译报错

错误显示:@objc’ instance method in extension of subclass of ‘xxxxx’ requires iOS 13.0.0

这是由于组件开启了Library Evolution导致,开关BUILD_LIBRARY_FOR_DISTRIBUTION 控制的。

一个库开启了Library Evolution,在依赖链下游的库中将:

1、对它的类实现 @objc 子类。

2、对它的类使用 extension 实现 @objc 的方法(这在 UIKit 的 protocol 中经常会遇到)。

3、对它的类实现子类,并添加 @objc 方法,且方法中使用父类的类型作为参数。

这些功能是实现的局限。估计是需要在 Swift 运行时有一些对应的更改,所以只在 swift 5.1 (iOS 13)运行时里才可以运行。

除此之外,还会有一些编译时没有报错,但运行时 crash 或结果不正确的情况。

百度App中默认开启Library Evolution,一个组件关闭Library Evolution会导致二进制存在不兼容的情况,暂时无解决方案。

4.3 暴露的Private头文件如果使用双引号import,会报警告,需要修改为尖括号

如果使用import <xxxx.h>,Project下其他Target就引用不到了,如百度App中Debug模块引用此Private头文件时,会报错 not found with include, use “quotes” instead。

  • 原因:这是由于其他Target对主模块引用时默认是从当前项目下引用头文件,而尖括号方式从系统库或用户库中引用;

  • 解决方案:其他Target将Private Header 配置到其 HEADER_SEARCH_PATHS,使用双引号和尖括号均可。

05 总结

以上是我们在Swift开发过程中所遇到的一些常见问题及其相应的解决方案。然而,随着我们不断深入Swift开发这片浩渺的海洋,更多独特的问题将会逐渐浮现。我们会持续将这些新问题以及其对应的解决方案整理并发布出来,为广大的开发者们提供有价值的参考。欢迎大家留言探讨。

百度搜索大前端团队,持续招聘 iOS/Android/Web前端 研发工程师。

简历欢迎投递至joinefe@baidu.com

——END——

推荐阅读

移动端防截屏录屏技术在百度账户系统实践

AI Native工程化:百度App AI互动技术实践

揭开事件循环的神秘面纱

百度搜索展现服务重构:进步与优化

百度APP iOS端包体积50M优化实践(七)编译器优化

文章来源:https://blog.csdn.net/lihui49/article/details/135264180
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。