ios .mm文件调用c语言函数报错,深入浅出 iOS 编译
前言
兩年前曾經寫過一篇關于編譯的文章《iOS編譯過程的原理和應用》，這篇文章介紹了iOS編譯相關基礎知識和簡單應用，但也很有多問題都沒有解釋清楚：
Clang和LLVM究竟是什么
源文件到機器碼的細節
Linker做了哪些工作
編譯順序如何確定
頭文件是什么？XCode是如何找到頭文件的？
Clang Module
簽名是什么？為什么要簽名
為了搞清楚這些問題，我們來挖掘下XCode編譯iOS應用的細節。
編譯器
把一種編程語言(原始語言)轉換為另一種編程語言(目標語言)的程序叫做編譯器。
大多數編譯器由兩部分組成：前端和后端。
前端負責詞法分析，語法分析，生成中間代碼；
后端以中間代碼作為輸入，進行行架構無關的代碼優化，接著針對不同架構生成不同的機器碼。
前后端依賴統一格式的中間代碼(IR)，使得前后端可以獨立的變化。新增一門語言只需要修改前端，而新增一個CPU架構只需要修改后端即可。
Objective C/C/C++使用的編譯器前端是clang，swift是swift，后端都是LLVM。
LLVM
LLVM(Low Level Virtual Machine)是一個強大的編譯器開發工具套件，聽起來像是虛擬機，但實際上LLVM和傳統意義的虛擬機關系不大，只不過項目最初的名字是LLVM罷了。
LLVM的核心庫提供了現代化的source-target-independent優化器和支持諸多流行CPU架構的代碼生成器，這些核心代碼是圍繞著LLVM IR(中間代碼)建立的。
基于LLVM，又衍生出了一些強大的子項目，其中iOS開發者耳熟能詳的是：Clang和LLDB。
clang
clang是C語言家族的編譯器前端，誕生之初是為了替代GCC，提供更快的編譯速度。一張圖了解clang編譯的大致流程：
接下來，從代碼層面看一下具體的轉化過程，新建一個main.c:
#include
// 一點注釋
#define DEBUG 1
int main() {
#ifdef DEBUG
printf("hello debug\n");
#else
printf("hello world\n");
#endif
return 0;
}
預處理(preprocessor)
預處理會替進行頭文件引入，宏替換，注釋處理，條件編譯(#ifdef)等操作。
#include "stdio.h"就是告訴預處理器將這一行替換成頭文件stdio.h中的內容，這個過程是遞歸的：因為stdio.h也有可能包含其頭文件。
用clang查看預處理的結果：
xcrun clang -E main.c
預處理后的文件有400多行，在文件的末尾，可以找到main函數
int main() {
printf("hello debug\n");
return 0;
}
可以看到，在預處理的時候，注釋被刪除，條件編譯被處理。
詞法分析(lexical anaysis)
詞法分析器讀入源文件的字符流，將他們組織稱有意義的詞素(lexeme)序列，對于每個詞素，此法分析器產生詞法單元(token)作為輸出。
$ xcrun clang -fmodules -fsyntax-only -Xclang -dump-tokens main.c
輸出：
annot_module_include '#include
int 'int' [StartOfLine]Loc=<4:1>4:1>
identifier 'main' [LeadingSpace]Loc=<4:5>4:5>
....
Loc=<1:1>標示這個token位于源文件main.c的第1行，從第1個字符開始。保存token在源文件中的位置是方便后續clang分析的時候能夠找到出錯的原始位置。1:1>
語法分析(semantic analysis)
詞法分析的Token流會被解析成一顆抽象語法樹(abstract syntax tree - AST)。
$ xcrun clang -fsyntax-only -Xclang -ast-dump main.c | open -f
main函數AST的結構如下：
�[0;34m`-�[0m�[0;1;32mFunctionDecl�[0m�[0;33m 0x7fcc188dc700�[0m �[0;33mline:4:5�[0m�[0;1;36m main�[0m �[0;32m'int ()'�[0m
�[0;34m `-�[0m�[0;1;35mCompoundStmt�[0m�[0;33m 0x7fcc188dc918�[0m
�[0;34m |-�[0m�[0;1;35mCallExpr�[0m�[0;33m 0x7fcc188dc880�[0m �[0;32m'int'�[0m�[0;36m�[0m�[0;36m�[0m
�[0;34m | |-�[0m�[0;1;35mImplicitCastExpr�[0m�[0;33m 0x7fcc188dc868�[0m �[0;32m'int (*)(const char *, ...)'�[0m�[0;36m�[0m�[0;36m�[0m
�[0;34m | | `-�[0m�[0;1;35mDeclRefExpr�[0m�[0;33m 0x7fcc188dc7a0�[0m �[0;32m'int (const char *, ...)'�[0m�[0;36m�[0m�[0;36m�[0m �[0;1;32mFunction�[0m�[0;33m 0x7fcc188c5160�[0m�[0;1;36m 'printf'�[0m �[0;32m'int (const char *, ...)'�[0m
�[0;34m | `-�[0m�[0;1;35mImplicitCastExpr�[0m�[0;33m 0x7fcc188dc8c8�[0m �[0;32m'const char *'�[0m�[0;36m�[0m�[0;36m�[0m
�[0;34m | `-�[0m�[0;1;35mImplicitCastExpr�[0m�[0;33m 0x7fcc188dc8b0�[0m �[0;32m'char *'�[0m�[0;36m�[0m�[0;36m�[0m
�[0;34m | `-�[0m�[0;1;35mStringLiteral�[0m�[0;33m 0x7fcc188dc808�[0m �[0;32m'char [13]'�[0m�[0;36m lvalue�[0m�[0;36m�[0m�[0;1;36m "hello debug\n"�[0m
�[0;34m `-�[0m�[0;1;35mReturnStmt�[0m�[0;33m 0x7fcc188dc900�[0m
�[0;34m `-�[0m�[0;1;35mIntegerLiteral�[0m�[0;33m 0x7fcc188dc8e0�[0m �[0;32m'int'�[0m�[0;36m�[0m�[0;36m�[0m�[0;1;36m 0�[0m
有了抽象語法樹，clang就可以對這個樹進行分析，找出代碼中的錯誤。比如類型不匹配，亦或Objective C中向target發送了一個未實現的消息。
AST是開發者編寫clang插件主要交互的數據結構，clang也提供很多API去讀取AST。更多細節：Introduction to the Clang AST。
CodeGen
CodeGen遍歷語法樹，生成LLVM IR代碼。LLVM IR是前端的輸出，后端的輸入。
xcrun clang -S -emit-llvm main.c -o main.ll
main.ll文件內容：
...
@.str = private unnamed_addr constant [13 x i8] c"hello debug
...
@.str = private unnamed_addr constant [13 x i8] c"hello debug\0A\00", align 1
; Function Attrs: noinline nounwind optnone ssp uwtable
define i32 @main() #0 {
%1 = alloca i32, align 4
store i32 0, i32* %1, align 4
%2 = call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([13 x i8], [13 x i8]* @.str, i32 0, i32 0))
ret i32 0
}
...
A
...
@.str = private unnamed_addr constant [13 x i8] c"hello debug\0A\00", align 1
; Function Attrs: noinline nounwind optnone ssp uwtable
define i32 @main() #0 {
%1 = alloca i32, align 4
store i32 0, i32* %1, align 4
%2 = call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([13 x i8], [13 x i8]* @.str, i32 0, i32 0))
ret i32 0
}
...
0", align 1
; Function Attrs: noinline nounwind optnone ssp uwtable
define i32 @main() #0 {
%1 = alloca i32, align 4
store i32 0, i32* %1, align 4
%2 = call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([13 x i8], [13 x i8]* @.str, i32 0, i32 0))
ret i32 0
}
...
Objective C代碼在這一步會進行runtime的橋接：property合成，ARC處理等。
LLVM會對生成的IR進行優化，優化會調用相應的Pass進行處理。Pass由多個節點組成，都是Pass類的子類，每個節點負責做特定的優化，更多細節：Writing an LLVM Pass。
生成匯編代碼
LLVM對IR進行優化后，會針對不同架構生成不同的目標代碼，最后以匯編代碼的格式輸出：
生成arm 64匯編：
$ xcrun clang -S main.c -o main.s
查看生成的main.s文件，篇幅有限，對匯編感興趣的同學可以看看我的這篇文章：iOS匯編快速入門。
_main: ## @main
.cfi_startproc
## %bb.0:
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset %rbp, -16
movq %rsp, %rbp
...
匯編器
匯編器以匯編代碼作為輸入，將匯編代碼轉換為機器代碼，最后輸出目標文件(object file)。
$ xcrun clang -fmodules -c main.c -o main.o
還記得我們代碼中調用了一個函數printf么？通過nm命令，查看下main.o中的符號
$ xcrun nm -nm main.o
(undefined) external _printf
0000000000000000 (__TEXT,__text) external _main
_printf是一個是undefined external的。undefined表示在當前文件暫時找不到符號_printf，而external表示這個符號是外部可以訪問的，對應表示文件私有的符號是non-external。
Tips：什么是符號(Symbols)? 符號就是指向一段代碼或者數據的名稱。還有一種叫做WeakSymols，也就是并不一定會存在的符號，需要在運行時決定。比如iOS 12特有的API，在iOS11上就沒有。
鏈接
連接器把編譯產生的.o文件和(dylib,a,tbd)文件，生成一個mach-o文件。
$ xcrun clang main.o -o main
我們就得到了一個mach o格式的可執行文件
$ file main
main: Mach-O 64-bit executable x86_64
$ ./main
hello debug
在用nm命令，查看可執行文件的符號表：
$ nm -nm main
(undefined) external _printf (from libSystem)
(undefined) external dyld_stub_binder (from libSystem)
0000000100000000 (__TEXT,__text) [referenced dynamically] external __mh_execute_header
0000000100000f60 (__TEXT,__text) external _main
_printf仍然是undefined，但是后面多了一些信息：from libSystem，表示這個符號來自于libSystem，會在運行時動態綁定。
XCode編譯
通過上文我們大概了解了Clang編譯一個C語言文件的過程，但是XCode開發的項目不僅僅包含了代碼文件，還包括了圖片，plist等。以的iOS App為例，我們來看看在XCode中編譯一次都要經過哪些過程？
新建一個單頁面的Demo工程：CocoaPods依賴AFNetworking和SDWebImage，同時依賴于一個內部Framework。按下Command+B，在XCode的Report Navigator模塊中，可以找到編譯的詳細日志：
詳細的步驟如下：
創建Product.app的文件夾
把Entitlements.plist寫入到DerivedData里，處理打包的時候需要的信息(比如application-identifier)。
創建一些輔助文件，比如各種.hmap，這是headermap文件，具體作用下文會講解。
執行CocoaPods的編譯前腳本：檢查Manifest.lock文件。
編譯.m文件，生成.o文件。
鏈接動態庫，o文件，生成一個mach o格式的可執行文件。
編譯assets，編譯storyboard，鏈接storyboard
拷貝動態庫Logger.framework，并且對其簽名
執行CocoaPods編譯后腳本：拷貝CocoaPods Target生成的Framework
對Demo.App簽名，并驗證(validate)
生成Product.app
編譯順序
編譯的時候有很多的Task(任務)要去執行，XCode如何決定Task的執行順序呢？
答案是：依賴關系。
還是以剛剛的Demo項目為例，整個依賴關系如下：
可以從XCode的Report Navigator看到Target的編譯順序：
XCode編譯的時候會盡可能的利用多核性能，多Target并發編譯。
那么，XCode又從哪里得到了這些依賴關系呢？
Target Dependencies - 顯式聲明的依賴關系
Linked Frameworks and Libraries - 隱式聲明的依賴關系
Build Phase - 定義了編譯一個Target的每一步
增量編譯
日常開發中，一次完整的編譯可能要幾分鐘，甚至幾十分鐘，而增量編譯只需要不到1分鐘，為什么增量編譯會這么快呢？
因為XCode會對每一個Task生成一個哈希值，只有哈希值改變的時候才會重新編譯。
比如，修改了ViewControler.m，只有圖中灰色的三個Task會重新執行(這里不考慮build phase腳本)。
頭文件
C語言家族中，頭文件(.h)文件用來引入函數/類/宏定義等聲明，讓開發者更靈活的組織代碼，而不必把所有的代碼寫到一個文件里。
頭文件對于編譯器來說就是一個promise。頭文件里的聲明，編譯會認為有對應實現，在鏈接的時候再解決具體實現的位置。
當只有聲明，沒有實現的時候，鏈接器就會報錯。
Undefined symbols for architecture arm64:
"_umimplementMethod", referenced from:
-[ClassA method] in ClassA.o
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Objective C的方法要到運行時才會報錯，因為Objective C是一門動態語言，編譯器無法確定對應的方法名(SEL)在運行時到底有沒有實現(IMP)。
日常開發中，兩種常見的頭文件引入方式：
#include "CustomClass.h" //自定義
#include //系統或者內部framework
引入的時候并沒有指明文件的具體路徑，編譯器是如何找到這些頭文件的呢？
回到XCode的Report Navigator，找到上一個編譯記錄，可以看到編譯ViewController.m的具體日志：
把這個日志整體拷貝到命令行中，然后最后加上-v，表示我們希望得到更多的日志信息，執行這段代碼，在日志最后可以看到clang是如何找到頭文件的：
#include "..." search starts here:
/Users/.../Build/Intermediates.noindex/Demo.build/Debug-iphoneos/Demo.build/Demo-generated-files.hmap (headermap)
/Users/.../Build/Intermediates.noindex/Demo.build/Debug-iphoneos/Demo.build/Demo-project-headers.hmap (headermap)
/Users/.../Build/Products/Debug-iphoneos/AFNetworking/AFNetworking.framework/Headers
/Users/.../Build/Products/Debug-iphoneos/SDWebImage/SDWebImage.framework/Headers
#include <...> search starts here:
/Users/.../Build/Intermediates.noindex/Demo.build/Debug-iphoneos/Demo.build/Demo-own-target-headers.hmap (headermap)
/Users/.../Build/Intermediates.noindex/Demo.build/Debug-iphoneos/Demo.build/Demo-all-non-framework-target-headers.hmap (headermap)
/Users/.../Build/Intermediates.noindex/Demo.build/Debug-iphoneos/Demo.build/DerivedSources
/Users/.../Build/Products/Debug-iphoneos (framework directory)
/Users/.../Build/Products/Debug-iphoneos/AFNetworking (framework directory)
/Users/.../Build/Products/Debug-iphoneos/SDWebImage (framework directory)
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/10.0.0/include
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include
$SDKROOT/usr/include
$SDKROOT/System/Library/Frameworks (framework directory)
End of search list.
這里有個文件類型叫做heademap，headermap是幫助編譯器找到頭文件的輔助文件：存儲這頭文件到其物理路徑的映射關系。
可以通過一個輔助的小工具hmap查看hmap中的內容：
192:Desktop Leo$ ./hmap print Demo-project-headers.hmap
AppDelegate.h -> /Users/huangwenchen/Desktop/Demo/Demo/AppDelegate.h
Demo-Bridging-Header.h -> /Users/huangwenchen/Desktop/Demo/Demo/Demo-Bridging-Header.h
Dummy.h -> /Users/huangwenchen/Desktop/Demo/Framework/Dummy.h
Framework.h -> Framework/Framework.h
TestView.h -> /Users/huangwenchen/Desktop/Demo/Demo/View/TestView.h
ViewController.h -> /Users/huangwenchen/Desktop/Demo/Demo/ViewController.h
Tips: 這就是為什么備份/恢復Mac后，需要clean build folder，因為兩臺mac對應文件的物理位置可能不一樣。
clang發現#import "TestView.h"的時候，先在headermap(Demo-generated-files.hmap,Demo-project-headers.hmap)里查找，如果headermap文件找不到，接著在own target的framework里找：
/Users/.../Build/Products/Debug-iphoneos/AFNetworking/AFNetworking.framework/Headers/TestView.h
/Users/.../Build/Products/Debug-iphoneos/SDWebImage/SDWebImage.framework/Headers/TestView.h
系統的頭文件查找的時候也是優先headermap，headermap查找不到會查找own target framework，最后查找SDK目錄。
以#import 為例，在SDK目錄查找時：
首先查找framework是否存在
$SDKROOT/System/Library/Frameworks/Foundation.framework
如果framework存在，再在headers目錄里查找頭文件是否存在
$SDKROOT/System/Library/Frameworks/Foundation.framework/headers/Foundation.h
Clang Module
傳統的#include/#import都是文本語義：預處理器在處理的時候會把這一行替換成對應頭文件的文本，這種簡單粗暴替換是有很多問題的：
大量的預處理消耗。假如有N個頭文件，每個頭文件又#include了M個頭文件，那么整個預處理的消耗是N*M。
文件導入后，宏定義容易出現問題。因為是文本導入，并且按照include依次替換，當第一個頭文件定義了#define std hello_world，而第二個頭文件剛好又是C++標準庫，那么所有的std都會被替換。
邊界不明顯。拿到一組.a和.h文件，很難確定.h是屬于哪個.a的，需要以什么樣的順序導入才能正確編譯。
clang module不再使用文本模型，而是采用更高效的語義模型。clang module提供了一種新的導入方式:@import，module會被作為一個獨立的模塊編譯，并且產生獨立的緩存，從而大幅度提高預處理效率，這樣時間消耗從M*N變成了M+N。
XCode創建的Target是Framework的時候，默認define module會設置為YES，從而支持module，當然像Foundation等系統的framwork同樣支持module。
#import 的時候，編譯器會檢查NSString.h是否在一個module里，如果是的話，這一行會被替換成@import Foundation。
那么，如何定義一個module呢？答案是：modulemap文件，這個文件描述了一組頭文件如何轉換為一個module，舉個例子：
framework module Foundation [extern_c] [system] {
umbrella header "Foundation.h" // 所有要暴露的頭文件
export *
module * {
export *
}
explicit module NSDebug { //submodule
header "NSDebug.h"
export *
}
}
swift是可以直接import一個clang module的，比如你有一些C庫，需要在Swift中使用，就可以用modulemap的方式。
Swift編譯
現代化的語言幾乎都拋棄了頭文件，swift也不例外。問題來了，swift沒有頭文件又是怎么找到聲明的呢？
編譯器干了這些臟活累活。編譯一個Swift頭文件，需要解析Target中所有的Swift文件，找到對應的聲明。
當開發中難免要有Objective C和Swfit相互調用的場景，兩種語言在編譯的時候查找符號的方式不同，如何一起工作的呢？
Swift引用Objective C：
Swift的編譯器內部使用了clang，所以swift可以直接使用clang module，從而支持直接import Objective C編寫的framework。
swift編譯器會從objective c頭文件里查找符號，頭文件的來源分為兩大類：
Bridging-Header.h中暴露給swfit的頭文件
framework中公開的頭文件，根據編寫的語言不通，可能從modulemap或者umbrella header查找
XCode提供了宏定義NS_SWIFT_NAME來讓開發者定義Objective C => Swift的符號映射，可以通過Related Items -> Generate Interface來查看轉換后的結果：
Objective引用swift
xcode會以module為單位，為swift自動生成頭文件，供Objective C引用，通常這個文件命名為ProductName-Swift.h。
swift提供了關鍵詞@objc來把類型暴露給Objective C和Objective C Runtime。
@objc public class MyClass
深入理解Linker
鏈接器會把編譯器編譯生成的多個文件，鏈接成一個可執行文件。鏈接并不會產生新的代碼，只是在現有代碼的基礎上做移動和補丁。
鏈接器的輸入可能是以下幾種文件：
object file(.o)，單個源文件的編輯結果，包含了由符號表示的代碼和數據。
動態庫(.dylib)，mach o類型的可執行文件，鏈接的時候只會綁定符號，動態庫會被拷貝到app里，運行時加載
靜態庫(.a)，由ar命令打包的一組.o文件，鏈接的時候會把具體的代碼拷貝到最后的mach-o
tbd，只包含符號的庫文件
這里我們提到了一個概念：符號(Symbols)，那么符號是什么呢？
符號是一段代碼或者數據的名稱，一個符號內部也有可能引用另一個符號。
以一段代碼為例，看看鏈接時究竟發生了什么？
源代碼：
- (void)log{
printf("hello world\n");
}
.o文件：
#代碼
adrp x0, l_.str@PAGE
add x0, x0, l_.str@PAGEOFF
bl _printf
#字符串符號
l_.str: ; @.str
.asciz "hello world\n"
在.o文件中，字符串"hello world\n"作為一個符號來引用，匯編代碼讀取的時候按照l_.str所在的頁加上偏移量的方式讀取，然后調用printf符號。到這一步，CPU還不知道怎么執行，因為還有兩個問題沒解決：
l_.str在可執行文件的哪個位置？
printf函數來自哪里？
再來看看鏈接之后的mach o文件：
鏈接器如何解決這兩個問題呢？
鏈接后，不再是以頁+偏移量的方式讀取字符串，而是直接讀虛擬內存中的抵制，解決了l_.str的位置問題。
鏈接后，不再是調用符號_printf，而是在DATA段上創建了一個函數指針_printf$ptr，值為0x0，代碼直接調用這個函數指針。啟動的時候，dyld會把DATA段上的指針，進行動態綁定，綁定到具體虛擬內存中的_printf地址。更多細節，可以參考我之前的這篇文章：深入理解iOS App的啟動過程。
Tips: Mach-O有一個區域叫做LINKEDIT，這個區域用來存儲啟動的時候，dyld需要動態修復的一些數據：比如剛剛提到的printf在內存中的地址。
理解簽名
基礎回顧
非對稱加密。在密碼學中，非對稱加密需要兩個密鑰：公鑰和私鑰。私鑰加密的只能用公鑰解密，公鑰加密的只能用私鑰解密。
數字簽名。數字簽名表示我對數據做了個標記，表示這是我的數據，沒有經過篡改。
數據發送方Leo產生一對公私鑰，私鑰自己保存，公鑰發給接收方Lina。Leo用摘要算法，對發送的數據生成一段摘要，摘要算法保證了只要數據修改，那么摘要一定改變。然后，用私鑰對這個摘要進行加密，和數據一起發送給Lina。
Lina收到數據后，用公鑰解密簽名，得到Leo發過來的摘要；然后自己按照同樣的摘要算法計算摘要，如果計算的結果和Leo的一樣，說明數據沒有被篡改過。
但是，現在還有個問題：Lina有一個公鑰，假如攻擊者把Lina的公鑰替換成自己的公鑰，那么攻擊者就可以偽裝成Leo進行通信，所以Lina需要確保這個公鑰來自于Leo，可以通過數字證書來解決這個問題。
數字證書由CA(Certificate Authority)頒發，以Leo的證書為例，里面包含了以下數據：簽發者；Leo的公鑰；Leo使用的Hash算法；證書的數字簽名；到期時間等，這些數據用CA的公鑰進行加密。
有了數字證書后，Leo再發送數據的時候，把自己從CA申請的證書一起發送給Lina。Lina收到數據后，先驗證證書的數字簽名是否正確，如果正確說明證書沒有被篡改過，然后用CA的公鑰解密證書數據，根據證書的信息就可以確認這是Leo的證書，對應的公鑰也是Leo的。
iOS App簽名
為什么要對App進行簽名呢？簽名能夠讓iOS識別出是誰對簽名了App，并且簽名后，App沒有被修改過，
另外Apple要嚴格控制App的分發：
App來自Apple信任的開發者
安裝的設備是Apple允許的設備
App在簽名后安裝包沒有被篡改過
證書
通過上文的講解，我們知道數字證書里包含著申請證書設備的公鑰，所以在Apple開發者后臺創建證書的時候，需要上傳CSR文件(Certificate Signing Request)，用keychain生成這個文件的時候，就生成了一對公/私鑰：公鑰在CSR里，私鑰在本地的Mac上。Apple本身也有一對公鑰和私鑰：私鑰保存在Apple后臺，公鑰在每一臺iOS設備上。
Provisioning Profile
iOS App安裝到設備的途徑(非越獄)有以下幾種：
開發包(插線，或者archive導出develop包)
Ad Hoc
App Store
企業證書
開發包和Ad Hoc都會嚴格限制安裝設備，為了把設備uuid等信息一起打包進App，開發者需要配置Provisioning Profile。
可以通過以下命令來查看Provisioning Profile中的內容：
security cms -D -i embedded.mobileprovision > result.plist
open result.plist
本質上就是一個編碼過后的plist
iOS簽名
生成安裝包的最后一步，XCode會調用codesign對Product.app進行簽名。
創建一個額外的目錄_CodeSignature以plist的方式存放安裝包內每一個文件簽名
Base.lproj/LaunchScreen.storyboardc/01J-lp-oVM-view-Ze5-6b-2t3.nib
T2g5jlq7EVFHNzL/ip3fSoXKoOI=
Info.plist
5aVg/3m4y30m+GSB8LkZNNU3mug=
PkgInfo
n57qDP4tZfLD1rCS43W0B4LQjzE=
embedded.mobileprovision
tm/I1g+0u2Cx9qrPJeC0zgyuVUE=
...
代碼簽名會直接寫入到mach-o的可執行文件里，值得注意的是簽名是以頁(Page)為單位的，而不是整個文件簽名：
驗證
在安裝App的時候，
從embedded.mobileprovision取出證書，驗證證書是否來自Apple信任的開發者
證書驗證通過后，從證書中取出Leo的公鑰
讀取_CodeSignature中的簽名結果，用Leo的公鑰驗證每個文件的簽名是否正確
文件embedded.mobileprovision驗證通過后，讀取里面的設備id列表，判斷當前設備是否可安裝(App Store和企業證書不做這步驗證)
驗證通過后，安裝App
啟動App的時候：
驗證bundle id，entitlements和embedded.mobileprovision中的AppId，entitlements是否一致
判斷device id包含在embedded.mobileprovision里
App Store和企業證書不做驗證
如果是企業證書，驗證用戶是否信任企業證書
App啟動后，當缺頁中斷(page fault)發生的時候，系統會把對應的mach-o頁讀取物理內存，然后驗證這個page的簽名是否正確。
以上都驗證通過，App才能正常啟動
小結
如有內容錯誤，歡迎issue指正。
總結
以上是生活随笔為你收集整理的ios .mm文件调用c语言函数报错,深入浅出 iOS 编译的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： centos ：不在 sudoers 文
- 下一篇： 嵩天老师-Python语言程序设计-Py