Swift在58安居客房产实践-开源中国

背景

2014年Apple在WWDC发布了新的语言Swift。随后一直在不断的更新迭代和优化，国内外各大公司一直在踊跃欲试，但一直都没有商用或大规模使用。直到2019年Apple发布了5.0版本，并宣布ABI稳定，2020年更是陆续SwiftUI、CareKit等Swift专属SDK，并且Apple一直在大力推广鼓励大家使用Swift。在这样的背景下，越来越多的开发者、开源项目都加快了Swift生态搭建的脚步。
另外Swift作为一门新语言，相比于Objective-C有巨大的后发优势：安全、高效、高性能等。这些特性有利于开发者提升开发效率和APP质量。在《Swift 2021 生态调研报告》中App Store免费前100中国外APP使用Swift占比91%。国内占比近50%

现状

在这样的趋势之下，58集团与2020年底启动了Swift共建项目，内部称为混天项目。目标是搭建Swift的基础组件、辅助工具及基础设施。制定集团Swift开发规范和代码检测工具以及Swift在各个业务线中的落地。

房产业务作为集团核心产业，深度参与了混天项目的研发及Swift的落地。下面的内容主要是Swift在房产业务线从0到1落地的过程中遇到的一些问题和探索。
目前公司项目都是OC语言开发的,在这样的一个快速迭代历史悠久的项目中，短期内是不可能将所有项目用Swift重写，所以我们前期采用的都是Swift和OC的混合开发。

工程架构

在接入Swift之前，我们先来了解下集团APP的工程架构以及房产的业务结构。58集团iOS团队维护了58同城、安居客、赶集网、58同镇、招财猫、车商通等十几款APP,为了降低维护的成本和开发效率，团队将基础功能进行组件化，提供多个自研基础组件以及SDK，打造APP工厂。但不同APP和业务线对底层的依赖情况各不相同。于是在此基础之上增加中间层，来解决业务垂直业务跨APP时的底层差异和APP内业务之间的共享。

房产业务结构

集团在58同城、安居客、赶集网、58同镇都有房产业务，在早期各个团队之间相对独立运行维护。随着业务的垂直化和产业化。房产发起木星计划，目标是打造成一套代码，多APP运行。来降低维护的成本和开发效率。让不同团队更加关注自己的业务，发挥自己的优势。虽然开发维护效率提高了，但同时也增加了工程的复杂度，下面就是房产目前核心业务的业务结构：

混编方案

目前Swift和Objective-C业内混编的方式主要有两种:

定向桥接

如果是在一个 App Target 内部混编的话，通过在宿主工程中添加桥接文件的方式进行混编,每个工程第一次创建Swift文件的时候，系统都会创建一个桥接(ProductModuleName-Bridging-Header.h)文件

Swift类需要访问OC的类时，只需要在这个桥接文件中导入需要暴露的类，即可在Swift中访问相应 OC的类和方法
OC访问Swift时在OC类中导入ProductName-Swift.h(隐藏文件)，即可访问Swift中暴露给 Objective-C的类和方法
这种方式使用起来非常的简单便捷，但有两个缺陷:

随着Swift使用场景越来越多，导入的头文件也会变得臃肿。
如果工程是通过Cocoapods管理，Pod和Pod之间是不能相互调用的

Module

我们的项目工程一个壳工程和多个业务子工程组成在一起，每一个业务线子工程都有一个或多个模块连接在一起，通过Cocoapods进行管理，模块之间是有依赖关系的。我们不但需要Swift和OC之间的调用，还需要跨Pod调用，所以桥接的方式肯定是不能满足。这时候还有一种方式就是Module。将 Build Settings 中的 Defines Module 选项设置为 YES，然后新建一个 umbrella header，再将需要暴露给Swift 调用的 OC 的头文件在这个 umbrella header 中导入
如果要想在 ObjC 调用 Swift，同样也要将 Build Settings 中的 Defines Module 选项设置为 YES，然后在要引用 Swift 代码的 ObjC 文件中导入编译器生成的头文件 #import

Module化实践

通过上面了解到目前我们的工程架构已经是通过Cocoapods进行组件/模块化管理.每个模块就是一个Module，而定向桥接的方式是不能跨Module通信，所以我们适合Module的方式进行混编，那如果进行混编呢？

环境搭建

开启Module选项
为了Pod库之间能够引用暴露的Swift接口，第一步需要让被访问的库开启module，需要在Swift所在的Pod文件夹下的podspec中的xcconfig下，添加’DEFINES_MODULE’ => ‘YES’
添加依赖
调用方需要在自己的podspec里添加moudule依赖，s.dependency ‘被调用方的pod库’
使用方式
配置好上述的依赖配置后，就可以调用开启Module的pod库了。不管是Swift文件中还是OC文件中都可以通过@import方式引用即可，同时Components组件也可以跨Pod调用WBLOCO中的OC的方法以及对外暴露的Swift接口，当然，暴露Swift接口想要暴露在OC环境下，需要用@objc声明，同时接口要声明成public

#import "WBListVC.h"
@import WBLOCO;@interface WBListVC ()@property (nonatomic, strong) LCListView  *listV;@end

工程变化

业务库开启moudule后工程目录的变化及注意事项：
WBLOCO开启module后，额外生成WBLOCO.modulemap和WBLOCO-umbrella.h两个文件

默认情况下WBLOCO中的umbrella.h里会导出所有OC的头文件，为解决此问题，可通过在podspec的private_header_files中添加屏蔽头文件的导出

Components Pod添加WBLOCO依赖后工程文件的变化

Swift类型对外暴露注意事项

Swift接口想要暴露在OC环境中，无论是在当前Pod还是跨Pod暴露，首先Swift的class想要定义成public, 同时对外暴露的接口需要用@objc声明，接口也要定义成public

import Foundation@objc public enum LCListItemSelectionStyle: Int {   case single   case multiple}public class LCListItemModel:NSObject {   @objc public var list_selected:Bool = false   @objc public var list_selection_style:LCListItemSelectionStyle = .single   @objc public var text:String = ""   @objc public var data:[LCListItemModel] = []   @objc public convenience init(modelWithDict: [String:Any]) {        self.init()        LCListItemModel.init(dict: modelWithDict)    }

踩坑案例

环境配置好，在接入Swift混编开发是时候遇到各种各样的问题坑，以下是房产在接入Swift时遇到的一些相对通用问题。

重复定义问题

创建Swift文件之后，工程直接编译失败，错误如下：

根据提示排查发现是因为工程代码中协议名称或者Block名称有重复，在纯OC中只要两个文件没有相互引用，编译器检测相对没有那么严格，所以编译不会报错，但接入Swift之后，编译器检测更加严格，编译就失败了，那解决的方式独立抽离一份，删除重复定义的或者修改相应的协议名和Block名称之后，再次编译成功。

LLDB调试问题

我们在混编开发过程中，但我们在在控制台po调试的时候，发现变量名看不到，提示类似错误信息如下：

(lldb) po selfwarning: Swift error in fallback scratch context: :1:9: note: in file included from :1:#import "WBLOCO-umbrella.h"       ^
/Users/xxxx/.../WBLOCO-umbrella.h:70:9: note: in file included from /Users/xxxx/.../Components-umbrella.h:70:#import "LGBaseNode.h"       ^
/Users/xxxx/.../LGBaseNode.h:9:9: note: in file included from //Users/xxxx/.../LGBaseNode.h:9:#import "LGDefines.h"       ^error: could not build Objective-C module 'WBLOCO':1:9: note: in file included from :1:#import "WBLOCO-umbrella.h"

这种错误的原因都是跨Pod引用OC头文件引入不规范导致，我们需要把所有.h文件中跨Pod导入的文件都需要改成全路径的方式引入例如：
Components的Pod中引入WBLOCO的Pod类
修改前：

#import "WBLOCO.h"

修改后：

#import

这样就能调试，但代码中有很多这种不规范的写法，我们可以通过脚本替换，把项目中所以不规范的全部统一修改。

Swift与OC混编时反射问题及原理探究

Swift与OC混编时反射问题背景

在日常开发中，我们经常会用到反射这个机制。iOS开发中系统也给我们提供了相应的API,我们可以通过这些API执行将字符串转为Class、SEL等操作。由于OC语言的动态性，这些操作都是发生在运行时的。

// SEL和字符串转换FOUNDATION_EXPORT NSString *NSStringFromSelector(SEL aSelector);FOUNDATION_EXPORT SEL NSSelectorFromString(NSString *aSelectorName);// Class和字符串转换FOUNDATION_EXPORT NSString *NSStringFromClass(Class aClass);FOUNDATION_EXPORT Class __nullable NSClassFromString(NSString *aClassName);// Protocol和字符串转换FOUNDATION_EXPORT NSString *NSStringFromProtocol(Protocol *proto) NS_AVAILABLE(10_5, 2_0);FOUNDATION_EXPORT Protocol * __nullable NSProtocolFromString(NSString *namestr) NS_AVAILABLE(10_5, 2_0);

通过这些方法，我们可以在运行时通过字符串创建相应的实例，并动态选择调用相应的方法。

Class cls = NSClassFromString(@"ViewController");ViewController *vc = [[cls alloc] init];SEL selector = NSSelectorFromString(@"initWithData");[vc performSelector:selector];

房产主要的核心页面都是流式布局，业务的特点是子业务相似度高，更新频率快，要有一定的动态性和灵活性。

基于以上的原因我们设计的方案客户端内置Cell，每个Cell绑定一个Key,通过Server下发数据Key，反射出对应的Cell,从而展示不同的内容和控制显示的内容的顺序。
但最近我们接入Swift与OC进行混编之后，就遇到了NSClassFromString反射的问题。

Swift与OC混编时反射初探

我们先来创建Swift类TestClass，当前的Module名称为HouseTest，下面看NSClassFromString这两种获取方式打印输出的结果。

import Cocoa@objc public class TestClass: NSObject {}

OC代码中通过反射获取这个TestClass这个类对象第一种方式输出的cls是为空的，第二种方式是在类名前期需求拼接上Module名称我们看到拿到cls实例

但这种方案我们实际在项目中使用时有2个明显的缺陷
1.Swift类我们必须知道Module名，而OC是没有Module名，我们需要判断是Swift还是OC的类来做特殊处理。每次新增一个Swift类,就得判断,代码很不优雅。
2.在多pod下，如果类被移动到另外一个pod，那么这个Class就找不到了，编译也不会报错。
我们工程中核心页面都是流式布局，根据Server下发的数据通过反射拿到对应的Cell Class实现动态化布局,混编情况下上面的方案差异处理较大，不能满足我们的需求。
我们最终使用了另外一种方案：在Swift的类中@ojbc后面加上自定义的类名，代码如下：

@objc(TestClass)public class TestClass: NSObject {}

加上@objc(TestClass)之后，OC中反射时获取Swift的Class我们就不需要关心Module名，底层处理方式和OC一样，这样就抹平了底层的差异性。

Class cls =  NSClassFromString(@"TestClass");

我们验证一下：

这们看到这里我们TestClass，通过这种方式就解决了上面那种方式的两个缺陷。
那么通过上面的问题思考：为什么Swift类在反射的时候需要加上Module名，@objc(TestClass)底层干了什么？

Swift与OC混编时反射打破砂锅问到底

因OC 源码不是开源的，没办法直接看源码，先下个符号断点，看下汇编代码（x86）

Foundation`NSClassFromString:->  0x181a3c43c :   pacibsp     0x181a3c440 :   stp    x28, x27, [sp, #-0x40]!    0x181a3c444 :   stp    x22, x21, [sp, #0x10]    0x181a3c448 :  stp    x20, x19, [sp, #0x20]    ......    ......    0x181a3c4f8 : bl     0x181d41f00               ; symbol stub for: objc_msgSend    0x181a3c4fc : mov    x21, x0    0x181a3c500 : mov    x0, x21    0x181a3c504 : bl     0x181d41ef0               ; symbol stub for: objc_lookUpClass

通过上面的汇编代码,查看关键信息，最后我们看到调用了objc_lookUpClass 通过上面的汇编模拟一下伪代码。

Class _Nullable MY_NSClassFromString(NSString *clsName) {    if (!clsName) { return Nil; }    NSUInteger classNameLength = [clsName length];    char buffer[1000];    if ([clsName getCString:buffer maxLength:1000 encoding:NSUTF8StringEncoding]        && classNameLength == strlen(buffer)) {        return objc_lookUpClass(buffer);    } else if (classNameLength == 0) {        return objc_lookUpClass([clsName UTF8String]);    }
    for (int i = 0; i         if ([clsName characterAtIndex:i] == 0) {            return Nil;        }    }    return objc_lookUpClass([clsName UTF8String]);}

验证结果：

2021-06-23 21:13:58.750828+0800 HouseTest[25683:4936266] my_cls = TestClass

通过伪代码我们发现这里并没有看出异常，加不加@objc(TestClass)都一样，那肯定是后面流程有问题。那只能调试源码(当前为objc-781)
我们跟踪源码的调用流程：objc_lookUpClass -> look_up_class -> getClassExceptSomeSwift

最后我们看到是从 NXMapGet(gdb_objc_realized_classes, name, cls)获取的。gdb_objc_realized_classes保存的是从Mach-O中加载的全部的类，难道是Swift 写的类没有被加载进来？那我们去看看加入的时候是怎么加进去的，我们找到程序启动类插入到gdb_objc_realized_classes 方法

我们看到这里加个Log打印一下

到TestClass这个类并不是我们看到的样子，变成了 _TtC6KCObjc9TestClass所以我们在调用NSStringFromClass(“TestClass”)时，传入的key是TestClass，maptable中存入的key是_TtC6KCObjc9TestClass
所以返回空了。那为什NSClassFromString(“ModuleName.ClassName”)就可以了呢？我们跟踪一下流程

走到这里result 还是为空,往下执行 copySwiftV1MangledName

到这里处理完之后结果
那为什么加上@objc(ClassName)就可以了，验证一下

这里就变成了真实的类名所以直接就能拿到对应Class的地址

我们在看一下加上 @objc(TestClass)和@objc编译之后的Swift桥接件和没加区别 @objc(TestClass)

没加@objc(TestClass)

这里我们看到一个 className是TestClass,一个是_TtC6KCObjc9TestClass

@objc后续

从这里我们也能够看到Swift中不同Pod中可以有相同的Class。通过ModuleName进行区分第一个Pod

import Foundation
class TestClass: NSObject {    var name = "我是One Pod"
}

第二个Pod

import Foundation
class TestClass: NSObject {    var name = "我是Tow Pod"
}

两个Module名不同，类名相同，最后的拼接完之后是不相同的，所以能够正常编译。如果我们给这两个类都加上 @objc(TestClass)呢? 我可以看到编译直接失败。

这里也说明Swift中不能的Module可以同名原因

Swift与OC注入绑定问题与优化

前面的文章也说到房产主要的核心页面都是流式布局，我们设计的方案客户端内置Cell，每个Cell绑定一个Key,通过Server下发数据Key，反射出对应的Cell。那么Cell和Key是如何进行绑定的？

在纯OC时代，绑定Key-Class方式有很多种，最开始采用的也是比较简单和直接的方式，在进入房产业务时,通过NSDictionary进行绑定Key-CellName和Key-Model，绑定方式如下：

NSMutableDictionary *classNames = [NSMutableDictionary dictionary];[classNames setObject:@"HSListHeaderCell" forKey:@"list_header_data"];[classNames setObject:@"HSListFootCell" forKey:@"list_foot_data"];......
NSMutableDictionary *modelNames = [NSMutableDictionary dictionary];[classNames setObject:@"HSListHeaderModel" forKey:@"list_header_data"];[classNames setObject:@"HSListFootModel" forKey:@"list_foot_data"];

但经过一段时间的迭代，我们发现这种方式有一些弊端，每次新增Cell都需要来这里修改代码，而且多业务线同时开发的时候不容易管理和维护，且容易代码冲突，违反了设计原则中的开闭原则。所以我们后期在重构的时候想到解决这个问题。

OC注入绑定方案一

首先我们想到的方案是注入的方式,在每个类的+Load方法中绑定Key-CellName，代码如下：

+(void)load{    [HSBusinessWidgetBindManager.sharedInstance setWidgetKey:@"list_header_data" widgetClassName:@"HSListHeaderWinget"];}+ (NSString *)cellName {    return NSStringFromClass(HSListHeaderCell.class);}
+ (NSString *)cellModelName {    return NSStringFromClass(HSListHeaderModel.class);}

但这种方式的缺陷就是+Load方法会对应用程序的启动时长有一定的影响，我们加起来有上百个Cell,所以+Load方法也不是一个很好的方式。(在这里我们直接绑定的是Widget，简化外部处理的流程，Cell、Model的绑定和数据相关的处理由Widget来完成)

OC注入绑定方案二

最后我们现在实现的方式是在程序预编译阶段，直接把绑定的数据写到Macho中，程序在进入业务线时，写入到内存中，然后通过Server下发的Key找到对应的WidgetName，具体代码如下：

typedef struct {    const char * cls;    const char * protocol;} _houselist_presenter_pair;

#define _HOUSELIST_SEGMENT "__DATA"#define _HOUSELIST_SECTION "__houselist"
#define HOUSELIST_PRESENTER_REGIST(PROTOCOL_NAME,CLASS_NAME)__attribute__((used, section(_HOUSELIST_SEGMENT "," _HOUSELIST_SECTION))) static _houselist_presenter_pair _HOUSELIST_UNIQUE_PAIR = {#CLASS_NAME,#PROTOCOL_NAME,};

但Widget需要绑定时,引入上面定义好的宏，传入对应的Key和WidgetName:

HOUSELIST_PRESENTER_REGIST(list_header_data, HSHeaderWidget)

进入房产业务时，读取Macho中DATA段之前存储的数据，并保存到内存中，代码如下：.h文件

@interface HouseListPresenterKVManager : NSObject