作者：京東零售 鄧立兵

隨着Swift的日漸成熟和給開發過程帶來的便利性及安全性，京喜App中的原生業務模塊和基礎模塊使用Swift開發佔比逐漸增高。本次討論的是struct對比Class的一些優劣勢，重點分析對包體積帶來的影響及規避措施。

一、基礎知識

1、類型對比

引用類型：將一個對象賦值給另一個對象時，系統不會對此對象進行拷貝，而會將指向這個對象的指針賦值給另一個對象，當修改其中一個對象的值時，另一個對象的值會隨之改變。【Class】

值類型：將一個對象賦值給另一個對象時，會對此對象進行拷貝，複製出一份副本給另一個對象，在修改其中一個對象的值時，不影響另外一個對象。【structs、Tuples、enums】。Swift中的【Array, String, and Dictionary】

兩者的區別可以查閲Apple官方文檔

2、Swift中struct和Class區別

1、class是引用類型、struct是值類型
2、類允許被繼承，結構體不允許被繼承
3、類中的每一個成員變量都必須被初始化，否則編譯器會報錯，而結構體不需要，編譯器會自動幫我們生成init函數，給變量賦一個默認值
4、當你需要繼承Objective-C某些類的的時候使用class
5、class聲明的方法修改屬性不需要`mutating`關鍵字；struct需要
6、如果需要保證數據的唯一性，或者保證在多線程數據安全，可以使用struct；而希望創建共享的、可變的狀態使用class

以上三點可以參考深入理解Swift中的Class和Struct進行更多細節的閲讀學習

二、struct優選

孔子曰：擇其善者而從之，其不善者而改之。

1、安全性

使用struct是值類型，在傳遞值的時候它會進行值的copy，所以在多線程是安全的。無論你從哪個線程去訪問你的 Struct ，都非常簡單。

2、效率性

struct存儲在stack中(這比malloc/free調用的性能要高得多)，class存儲在heap中，struct更快。

3、內存泄露

沒有引用計數器，所以不會因為循環引用導致內存泄漏

基於這些因素，在日常開發中，我們能用struct的我們儘量使用struct。

三、struct的不完美

孟子曰：魚，我所欲也，熊掌亦我所欲也；二者不可得兼。

“熊掌” 再好，吃多了也難以消化。特別在中大型項目中，如果沒有節制的使用struct，可能會帶來意想不到的問題。

1、內存問題

值類型有哪些問題？比如在兩個struct賦值操作時，可能會發現如下問題：

1、內存中可能存在兩個巨大的數組；
2、兩個數組數據是一樣的；
3、重複的複製。

解決方案：COW(copy-on-write) 機制

1、Copy-on-Write 是一種用來優化佔用內存大的值類型的拷貝操作的機制。
2、對於Int，Double，String 等基本類型的值類型，它們在賦值的時候就會發生拷貝。（內存增加）
3、對於 Array、Dictionary、Set 類型，當它們賦值的時候不會發生拷貝，只有在修改的之後才會發生拷貝。（內存按需延時增加）
4、對於自定義的數據類型不會自動實現COW，可按需實現。

那麼自定義的數據如何實現COW呢，可以參考官方代碼：

/*
我們使用class，這是一個引用類型，因為當我們將引用類型分配給另一個時，兩個變量將共享同一個實例，而不是像值類型一樣複製它。
*/
final class Ref {
  var val : T
  init(_ v : T) {val = v}
}

/*
創建一個struct包裝Ref：
由於struct是一個值類型，當我們將它分配給另一個變量時，它的值被複制，而屬性ref的實例仍由兩個副本共享，因為它是一個引用類型。
然後，我們第一次更改兩個Box變量的值時，我們創建了一個新的ref實例，這要歸功於：isUniquelyReferencedNonObjC
這樣，兩個Box變量不再共享相同的ref實例。
*/
struct Box {
    var ref : Ref
    init(_ x : T) { ref = Ref(x) }

    var value: T {
        get { return ref.val }
        set {
          //  isKnownUniquelyReferenced 函數來檢查某個引 用只有一個持有者
          // 如果你將一個 Swift 類的實例傳遞給這個函數，並且沒有其他變量強引用 這個對象的話，函數將返回 true。如果還有其他的強引用，則返回 false。不過，對於 Objective-C 的類，它會直接返回 false。
          if (!isUniquelyReferencedNonObjC(&ref)) {
            ref = Ref(newValue)
            return
          }
          ref.val = newValue
        }
    }
}
// This code was an example taken from the swift repo doc file OptimizationTips 
// Link: https://github.com/apple/swift/blob/master/docs/OptimizationTips.rst#advice-use-copy-on-write-semantics-for-large-values

實例説明：我們想在一個使用struct類型的User中使用copy-on-write的：

struct User {
    var identifier = 1
}

let user = User()
let box = Box(value: user)
var box2 = box                  // box2 shares instance of box.ref.value

box2.value.identifier = 2 			// 在改變的時候拷貝 box2.value=2	box.value=1


//打印內存地址
func address(of object: UnsafeRawPointer) {
    let addr = Int(bitPattern: object)
    print(NSString(format: "%p", addr))
}

注意這個機制減少的是內存的增加，以上可以參考寫更好的 Swift 代碼：COW(Copy-On-Write)進行更多細節的閲讀學習。

2、二進制體積問題

這是一個意向不到的點。發現這個問題的契機是何驍同學在對京喜項目進行瘦身的時候發現，在梳理項目中各個模塊的大小發現商詳模塊的包體積會比其他模塊要大很多。排除該模塊業務代碼多之外，通過對linkmap文件計算髮現，有兩個struct模型體積大的異常明顯：

通過簡單的將兩個對象，改成class類型後的二進制大小為：

這兩個對象會存在在不同類中進行傳遞，根據值類型的特性，增加也只是內存的大小，而不是二進制的大小。那麼問題就來了：

2.1、大小對比

回答該問題之前，先通過查閲資料發現，在C語言中static stuct佔用的二進制體積的確會大些，主要是因為static stuct是zero-initialized or uninitialized, 也就是説它在初始化不是空的。它們會進入數據段，也就是説，即使在初始化struct的一個字段，二進制文件也包含了整個結構的完整image。Swift可能也類似。具體可以查詢：Why does usage of structs increase application's binary size?

通過代碼實踐：

class HDClassDemo {
    var locShopName: String?
}
struct HDStructDemo {
    var locShopName: String?
}

編譯後計算linkmap的體積分別為：

1.54K HDClassDemo.o
1.48K HDStructDemo.o

並沒有得出struct會比class大的表現，通過Hopper Disassembler查看.o文件對比：

發現有四處值得注意的點：

1、class特有的KVO特性，想對比 struct 會有體積的增加；
2、同樣的 getter/setter/modify 方法，class增加的體積也多一些，猜測有可能是class類型會有更多的邏輯判斷；
3、init 方法中，struct增加體積較多，應該是 struct 初始化的時候，給變量賦一個默認值的原因；
4、struct 中的 "getEnumTagSinglePayload value" 和 "storeEnumTagSinglePayload value" 佔用較大的，但是通過linkmap計算，這兩部分應該沒有被最終在包體積中。

通過閲讀 https://juejin.cn/post/7094944164852269069 這兩個字段是為 Any 類型服務，上面的例子不涉及
struct ValueWitnessTable {
    var initializeBufferWithCopyOfBuffer: UnsafeRawPointer
    var destroy: UnsafeRawPointer
    var initializeWithCopy: UnsafeRawPointer
    var assignWithCopy: UnsafeRawPointer
    var initializeWithTake: UnsafeRawPointer
    var assignWithTake: UnsafeRawPointer
    var getEnumTagSinglePayload: UnsafeRawPointer
    var storeEnumTagSinglePayload: UnsafeRawPointer
    var size: Int
    var stride: Int
    var flags: UInt32
    var extraInhabitantCount: UInt32
}

所以結論是上面的寫法，struct並沒有表現比class體積大。可能是 Apple 在後面已經優化解決掉了。

但是，測試驗證過程中發現另外一個奇特的地方，當使用let修飾變量時

class HDClassDemo {
    let locShopName: String? = nil
}
struct HDStructDemo {
    let locShopName: String?
}

編譯後計算linkmap的體積分別為：

1.25K	HDStructDemo.o
0.94K	HDClassDemo.o

通過Hopper Disassembler查看.o文件對比：

在這種情況下，有兩個結論

1、let比var的二進制大小會小，減少部分主要是在setter/modify和kvo字段中。所以開發過程中養成好習慣，非必要不使用var修飾

2、在一個或者多個let修飾的情況下，struct二進制大小的確是大於class

最後，如果struct對象通過賦值操作傳遞給其他類（OtherObject），比如這樣（項目中經常存在）

let sd = HDStructDemo()
OtherObject().sdAction(sd: sd)

class OtherObject: NSObject {
    private var sd: HDStructDemo?
    func sdAction(sd: HDStructDemo) {
        self.sd = sd
        print(sd)
    }
}

在其他類(OtherObject)中的二進制中有多個內存地址的存儲和讀取端，一個變量會有兩次ldur、str操作，猜測分別對 變量名稱和類型的兩次操作（下圖是7個變量時的讀寫操作）：

00000000000003c0         ldur       x4, [x29, var_F0]
00000000000003c4         str        x4, [sp, #0x230 + var_228]
00000000000003c8         ldur       x3, [x29, var_E8]
00000000000003cc         str        x3, [sp, #0x230 + var_220]
00000000000003d0         ldur       x2, [x29, var_E0]
00000000000003d4         str        x2, [sp, #0x230 + var_218]
00000000000003d8         ldur       x1, [x29, var_D8]
00000000000003dc         str        x1, [sp, #0x230 + var_210]
00000000000003e0         ldur       x17, [x29, var_D0]
00000000000003e4         str        x17, [sp, #0x230 + var_208]
00000000000003e8         ldur       x16, [x29, var_C8]
00000000000003ec         str        x16, [sp, #0x230 + var_200]
00000000000003f0         ldur       x15, [x29, var_C0]
00000000000003f4         str        x15, [sp, #0x230 + var_1F8]
00000000000003f8         ldur       x14, [x29, var_B8]
00000000000003fc         str        x14, [sp, #0x230 + var_1F0]
0000000000000400         ldur       x13, [x29, var_B0]
0000000000000404         str        x13, [sp, #0x230 + var_1E8]
0000000000000408         ldur       x12, [x29, var_A8]
000000000000040c         str        x12, [sp, #0x230 + var_1E0]
0000000000000410         ldur       x11, [x29, var_A0]
0000000000000414         str        x11, [sp, #0x230 + var_1D8]
0000000000000418         ldur       x10, [x29, var_98]
000000000000041c         str        x10, [sp, #0x230 + var_1D0]
0000000000000420         ldur       x9, [x29, var_90]
0000000000000424         str        x9, [sp, #0x230 + var_1C8]
0000000000000428         ldur       x8, [x29, var_88]
000000000000042c         str        x8, [sp, #0x230 + var_1C0]

這將勢必對整個App的包體積帶來巨大的增量。一定一定一定要結合項目進行合理的選擇。

2.2、如何取捨

在安全、效率、內存、二進制大小多個方面，如何取得平衡是關鍵。

單從二進制大小作為考量，這裏有一些經驗總結可以提供參考：

1、如果變量都是let修飾，class 遠勝於 struct，變量越多，優勢越大；7個變量的情況下大小分別為：

3.12K	HDStructDemo.o
1.92K	HDClassDemo.o

2、如果變量都是var修飾，struct 遠勝於 class，變量越多，優勢越大：

1個變量：
1.54K	HDClassDemo.o
1.48K	HDStructDemo.o

60個變量：
44.21K	HDClassDemo.o
24.22K	HDStructDemo.o

100個變量：
71.74K	HDClassDemo.o
38.98K	HDStructDemo.o

3、如果變量都是var修飾，但是都遵循 Decodable 協議，這裏又有乾坤：

這種情況有可能在項目中存在，並且規律不是簡單的誰大誰小，而是根據變量的不同，呈現不同的規則：

使用腳本快速創建分別包含1-200個變量的200個文件

fileCount=200
for (( i = 0; i < $fileCount; i++ )); do
	className="HDClassObj_${i}"
	classFile="${className}.swift"
	structName="HDStructObj_${i}"
	structFile="${structName}.swift"
	classDecodableName="HDClassDecodableObj_${i}"
	classDecodableFile="${classDecodableName}.swift"
	structDecodableName="HDStructDecodableObj_${i}"
	structDecodableFile="${structDecodableName}.swift"
	echo "class ${className} {" > $classFile
	echo "struct ${structName} {" > $structFile
	echo "class ${classDecodableName}: Decodable {" > $classDecodableFile
	echo "struct ${structDecodableName}: Decodable {" > $structDecodableFile
	for (( j = 0; j < $i; j++ )); do
		line="\tvar name_${j}: String?"
		echo $line >> $classFile
		echo $line >> $structFile
		echo $line >> $classDecodableFile
		echo $line >> $structDecodableFile
	done
	echo "}" >> $classFile
	echo "}" >> $structFile
	echo "}" >> $classDecodableFile
	echo "}" >> $structDecodableFile
done

得到200個文件後，選擇arm64架構編譯後，分析linkmap文件，得到的文件大小為：

index	Class	Struct	ClassDecodable	StructDecodable
1	0.7	0.15	3.03	2.32
2	1.53	1.48	6.54	6.37
3	2.23	1.88	8.12	7.66
4	2.94	2.31	9.37	8.65
5	3.64	2.69	10.73	9.69
6	4.34	3.08	12.05	10.66
7	5.04	3.46	13.36	11.63
8	5.74	3.84	14.62	12.62
9	6.45	4.22	14.97	13.61
10	7.15	4.62	16.11	14.9
11	7.85	5.02	17.25	15.96
12	8.55	5.42	18.39	17.06
13	9.26	5.82	19.53	18.2
14	9.96	6.22	20.67	19.36
...
...
...
76	53.61	31.09	92.19	91.91
77	54.31	31.49	93.34	93.35
...
...
...
198	139.69	79.99	234.45	329.59
199	140.4	80.39	235.58	332
200	141.11	80.79	236.72	334.43

對於的增加曲線圖為：

HDStructDecodableObj在77個變量下體積將返超HDClassDecodableObj

根據曲線規則，可以得出Class、Struct、ClassDecodable增長是線性函數，對應的分別函數近似為：

Y = 0.825 + X * 0.705
Y = 1.0794 + X * 0.4006
Y = 5.3775 + X * 1.1625

HDClassDecodableObj的函數規則分佈猜測可能是一元二次函數（拋物線）、對數函數。在真實對比測試數據均不符合，也可能是分段函數吧。有知曉的同學請告知。

四、預防策略

聖人云：不治已病治未病，不治已亂而治未亂。

京喜從2020年開始陸續使用Swift作為業務開發的主要開發語言，特別是在商詳、直播、購物車、結算、設置等業務已經全量化。單單將商詳中的PGDomainModel、PGDomainData從struct改成class類型，該模塊的二進制大小從12.1M左右減少到5.5M，這主要是因為這兩個對象本身的變量較多，並且被大量其他樓層類賦值使用導致，收益可謂是具大。其他模塊收益相對會少一些。

可以通過SwiftLint的自定義規則，當在HDClassDecodableObj情況下，超過一定數量變量時，編譯錯誤來規避類似的問題。

自定義規則如下：

custom_rules:
  disable_more_struct_variable:
    included: ".*.swift"
    name: "struct不應包含超過10個的變量"
    regex: "^(struct).*(Decodable).*(((\n)*\\s(var).*){10,})"
    message: "struct不應包含超過10個的變量"
    severity: error

編譯報錯的效果如下：

規則也暫時發現的兩個問題：

1、regex次數問題

理論上的數量應該是77個才告警，但是配置數量超過15在編譯過程就會非常慢，在正則在正則可視化頁面運行穩定，但是使用SwiftLint卻幾乎卡死，問題暫未找到解決方案。可能需要閲讀SwiftLint源碼求助。

2、識別率問題

因為是根據var的次數進行匹配，一旦出現註釋（//） 統計也會誤差。正則過於複雜，暫時也沒有找到解決方案。

本文涉及到的代碼、腳本、工具、數據都開源存放在HDSwiftStructSizeDemo，文件結構説明如下：

.
├── Asserts # 圖片資源
├── README.md
└── Struct對比
    ├── HDSwiftCOWDemo # 測試struct和class大小的工程（代碼）
    │   ├── HDSwiftCOWDemo	
    │   └── HDSwiftCOWDemo.xcodeproj
    ├── LinkMap # 改造後的LinkMap源碼，支持二進制升/降排序序（工具）
    │   ├── LinkMap
    │   ├── LinkMap.xcodeproj
    │   ├── README.md
    │   ├── ScreenShot1.png
    │   └── ScreenShot2.png
    ├── StructSize.playground # playground工程，主要驗證二進制增長的函數（代碼）
    │   ├── Contents.swift
    │   ├── contents.xcplayground
    │   └── playground.xcworkspace
    ├── Swift-Struct/Class大小.xlsx # struct和class大小數據及圖表生成（數據：最終產物）
    └── linkmap對比 # 記錄struct和class的linkmap數據（數據）
        ├── HDClassDecodableObj.txt
        ├── HDClassObj.txt
        ├── HDStructDecodableObj.txt
        ├── HDStructObj.txt
        └── LinkMap.app

歡迎大家 🌟Star 🌟

五、參考資料

深入理解Swift中的Class和Struct

寫更好的 Swift 代碼：COW(Copy-On-Write)

Swift官方COW文檔

Understanding Swift Copy-on-Write mechanisms

swift 結構體copy-on-write技術

什麼是COW？

數據來測試是否實現COW

COW自定義實現

arm彙編儲存指令str stur和讀取指令 ldr ldur的使用,對應xcode c++中的代碼反彙編教程

正則可視化頁面

正則表達式全集

SwiftLint

SwiftLint_Rule

SwiftLint-Advanced