This profile

  • Topic: New cover
  • Tips: Precompiled in Swift
  • Interview module: Differences between DYLD 2 and DYLD 3; The compilation process
  • Good blog: Package dependency management tools
  • Learning materials: Develop a mini Go language compiler from scratch
  • Development tool: Git repository browsing tool Tig

This topic

Zhangferry: The first issue of fish Weekly in 2022. Starting from this issue, we will use a new cover designed by our designer friend Polaris. The theme of this scene is fishing. Fishing at work does not mean that we do not do our duty, but our yearning for free life. Both hard Work and Life balance, 2022, come on!

The development of Tips

zhangferry

Precompilation in Swift

Clang has the concept of precompiled Macros, which in Xcode corresponds to Build Setting -> Apple Clang-preprocessing Preprocessor Macros. You can set different precompiled macro commands according to different Configuration. Debug =1 in the Debug environment is the built-in macro command. We usually use the following Configuration:

#if DEBUG
// debug action
#end
Copy the code

If we need to add Configuration, such as Stage, we want a new precompiled macro such as Stage to represent it. If we do this:

It works in Objective-C code, it doesn’t work in Swift code. This is because the compiler used by Swift is SwifTC, which does not recognize the precompiled macros defined in Clang.

The solution is to use the SWIFT_ACTIVE_COMPILATION_CONDITIONS configuration variable, which corresponds to Active Compilation Conditions in the Build Setting. To make the STAGE macro available to Swift code, do the following:

Parsing the interview

zhangferry

What are the differences between DYLD 2 and DYLD 3

Dyld is a dynamic loader, it is mainly used for dynamic library linking and program start loading work, it has two major versions: DYLD 2 and DYLD 3.

dyld 2

Dyld2 was introduced in iOS 3.1 until iOS 12 was completely replaced by DYLD 3. It has gone through many iterations, and features that are common today, such as ASLR, Code Sign, Shared Cache, etc., were introduced in DyLD 2. Dyld 2 execution flows like this:

  • parsingmach-oHeader files, find the dependency libraries, which may have other dependencies, and do a recursive analysis until you get a complete map of all dylibs. There’s a lot of data, a lot of processing;
  • Map allmach-oFiles, put them into the address space;
  • Perform symbol lookup if your program uses itprintfFunction, will findprintfWhether it’s in the library system, and then we find its address, copy it to the function pointer in your program;
  • Bind and rebase to fix internal and external Pointers;
  • Run some initialization tasks such as loading categories, load methods, etc.
  • Execute the main;

dyld 3

Dyld 3 was introduced in iOS 11 in 2017 to optimize the library. It will now also be used to launch third-party apps in iOS 13, replacing DyLD 2 entirely.

The main feature of DYLD 3 is the introduction of a startup closure, which contains the cache information needed for startup, and this closure is done outside the process. Quite a bit of work has actually been done by the time the APP is opened, which will make DyLD execution faster.

The most important feature is the startup closure, which contains the cache information needed for startup to speed up startup. The following is a comparison of dyLD 2 and DYLD 3 execution steps:

Dyld 3 execution steps are divided into two steps, separated by the dotted line in the figure. The steps are executed outside the process above the dotted line and are executed when the following processes are created:

  • The first three steps to find dependencies and symbols are time-consuming and involve some security issues, so the information is written to the disk as a cache closure, corresponding to the address: TMP /com.apple.dyld. Closures are created when the phone is restarted/when the App is updated/when the App is first downloaded.

  • When the process starts, the closure is read and validated.

  • The next step is the same as dyLD 2

Dyld 3 improvements and optimizations in iOS 13

IOS Dyld has lived and died

The compilation process

A common compiler architecture, such as LLVM, uses a three-step process, meaning that there are three steps from source code to machine code:

Front-end Frontend -> Optimizer -> Backend

The advantage of this design is that the compilation responsibilities are separated so that when a new language or CPU architecture is added, only the front and back ends need to be modified.

The front-end is affected by language. The corresponding front-end of Objective-C and Swift is Clang and SWIFTC respectively. The following figure summarizes the compilation process for both languages:

The front end

The compiler front end does the following:

  1. Lexical analysis: split source code to generate a series of tokens.
  2. Syntax analysis: the syntax tree is generated by scanning the tokens generated in the previous step. This analysis process adopts context-free syntax analysis method.
  3. Semantic analysis: Semantic analysis is divided into static semantic analysis and dynamic semantic analysis. Static semantic analysis is confirmed during compilation, and dynamic semantic analysis can only be determined during runtime. This step includes type matching and type conversions that confirm the type of each expression in the syntax tree.

The IR middleware is then exported for use by the optimizer. This step Swift will have several more steps than ObjC, one of which is ClangImporter, which is used to be compatible with OC. It imports the Clang Module, maps ObjC or C’s API to the Swift API, and the exported result can be used by the semantic parser.

Another difference is that Swift has several SIL related steps (highlighted in blue), SIL stands for Swift Intermediate Language, which is different from IR, but is swift-specific Intermediate Language, Suitable for Swift source analysis and optimization. It is divided into three steps:

  1. Generate the raw SIL
  2. Do some data flow diagnostics and convert to standard SIL
  3. Do some Swift specific optimizations, including ARC, generics, etc

The optimizer

The compiled front end generates a uniform IR (Intermediate Representation) file passed to the optimizer, which is a strongly typed, compact set of instructions that abstracts the target instructions. The Optimization Level levels in Xcode — -o0, -o1, -O2, -O3, -OS — are handled in this step.

If you turn on Bitcode, it will also convert to Bitcode, which is the binary form of IR.

The back-end

This step is relatively simple and generates assembly and object files for different CPU architectures.

link

Project compilation is done on a file basis, and cross-file invocation methods cannot be located to the calling address. Links are used to bind these symbols. Links are divided into static links and dynamic links:

  • Static linking occurs at compile time, linking individual.o files to static libraries before the executable is generated. The common static linker is GNU LD, LLVM4 also has its own linker LLD.

  • Dynamic linking occurs at run time and is used to link dynamic libraries. It finds dependent dynamic libraries at startup and then performs symbolic resolution and address redirection. Dynamically link it to dyLD.

Swift.org – Swift Compiler

Good blog

Finishing editor: Dongpo elbow son

1. IOS package dependency management tools — from Nuggets: Little Green Leaf

This series of six articles introduces CocoaPods and Swift Package Manager in terms of principle, usage, and creating custom libraries. They also compare CocoaPods and Swift Package Manager.

2, CocoaPods Podspec parsing principle – from the world of chu: Chu

In CocoaPods, podSpec files are used to describe basic information about a POD library, including name, version, source, dependencies, and so on. This article showed you how to use a DSL approach to store configured properties in a hash table of an object and establish dependencies on each other by building a tree that holds all configuration information.

3. Some experience sharing about Swift Package Manager — from bytedance Technical team

Swift Package Manager is the product of Apple to make up for the lack of official component library management tools in current iOS development. Compared to other component-management controls, its definition files are easier to understand and Magic to use. Simply place the source code in the appropriate folder and Xcode automatically generates the project files and the configuration required to compile the target product. At the same time, SPM is compatible with Cocoapods to provide complementary features. In addition to introducing the current situation and common usage of Swift Package Manager, this paper also expounds the author’s thoughts on the future of SPM.

4, Fix swift Package Manager fetch slow problem — from Short book: Chocoford

It is not easy to fetch the SPM library on Github directly in Xcode due to certain network limitations. Several solutions to improve fetch success rates are presented in this article. Edit special note: Xcode package has built-in terminal, command line tools and other applications, any proxy Settings in the system terminal will not affect it. SS + Proxifier allows network data in Xcode to pass through the specified proxy.

5. Swift Package Manager adds resource files from Nuggets: Moxacist

Starting with swift-tool-version 5.3, Swift Package Manager provides the ability to add resource files to packages. This article is a summary of WWDC 2020 – Swift Software Package Resources and Localization.

Learning materials

Mimosa

µGo Language Implementation — Developing a Mini Go language compiler from Scratch

Address: github.com/chai2010/ug…

µGo is a true subset of the Go language (excluding the standard library part), which can be directly compiled and executed as Go code. The author tries to implement a toy language by learning and improving it while learning as a clue to the µGo compiler. At present, it is not finished, and you can pay attention to the compiler or Go interested partners. Here is a brief introduction to Go compiler customization by The author, as well as open source books such as Introduction to the Go Syntax Tree (published as the Go Language Customization Guide) and Advanced Programming for the Go Language.

Tools recommended

CoderStar

Tig

Address: jonas. Making. IO/tig /

Software status: Open source, free

Software Introduction:

Tig is a Git resource library browser, using Ncurses development, very suitable for the use of command line git operations partners.

About us

IOS Fish weekly, mainly share the experience and lessons encountered in the development process, high-quality blog, high-quality learning materials, practical development tools, etc. The weekly warehouse is here: github.com/zhangferry/… If you have a good content recommendation, you can submit it through the way of issue. You can also apply to be our resident editor to maintain the weekly. Also can pay attention to the public number: iOS growth road, backstage click into the group communication, contact us, get more content.

Phase to recommend

IOS Fishing Weekly Thirty-ninth issue

IOS Fishing Weekly 38th issue

IOS Fishing Weekly 37th issue

IOS Fishing Weekly 36th issue