-->
IOS Packaging Static Library detailed introduction
First, the preface
A book I read a while ago said: "At a distance, a lot of interesting knowledge seems to be bluffing." "For example, I would like to summarize the" Static library knowledge, when I was a cub, I really think those suffixes named ". Frameworke", ". a", ". Dylib" files are mysterious, very high cold. At that time I know that as long as the import of a library can refer to the library inside a lot of encapsulated good things, but to this "library" is what "ghost" is always foggy. Well, the nonsense is not much to say, look down to know what it is a "ghost".
Ii. Additions to some concepts
1, what is the library?
The so-called library is a collection of program code, is a way of sharing program code.
2, the classification of the library
According to the source of the program code, the library can be divided into two categories
Open Source Library
The source code is public and you can see the concrete implementation. For example GitHub on the more famous third party framework Afnetworking, Sdwebimage.
Closed Source Library
Unfair open source code, only publicly invoked interface, see no specific implementation, is a compiled binary file. This is common in some company SDK packages, such as the Gold Map SDK, the ring letter Instant Messaging SDK, and so on. And the closed source library is divided into two categories: static library and dynamic library. The focus of this article is the static library.
3. The existence form and usage difference of static library and dynamic library
Existence form:
Static Library
File suffix name with ". A" or ". Framework"
Dynamic Library
File suffix name with ". Dylib" or ". Framework"
Use the difference:
The static library link is copied into the executable file, and multiple copies are used multiple times.
When a static library is used by a program
Dynamic library links are not replicated when the program is run dynamically loaded into memory by the system for program invocation. And the system is only loaded once, multiple programs shared, saving memory.
When a dynamic library is used by a program
4. IOS Device CPU Architecture
Simulator:
4s-5: i386
5s-7 plus:x86_64
Real machine (iOS device):
Armv6:iphone, iphone 2, iphone 3G, ipod touch (first generation), ipod touch (second generation)
Armv7:iphone 3Gs, iphone 4, iphone 4s, ipad, ipad 2
Armv7s:iphone 5, IPhone 5c (Static library can run on armv7s architecture as long as it supports ARMV7)
Arm64:iphone 5s, iphone 6, iphone 6 Plus, iphone 6s, iphone 6s Plus, ipad Air, ipad Air2, ipad mini2, ipad Mini3
Note : The real machine IPhone7, IPhone7 Plus A10 Processor What is the structure of the temporary unknown, did not find the relevant information, seemingly not announced, but the simulator is x86_64.
Third, packaging Static library
Because the static inventory in two forms, we first look. A static library package
. A file Static library packaging
1, open Xcode to create a new project, here take Xcode8 as an example, select the project as follows:
To create a new project
2, after the creation of the project, and then create a tool class Staticlibtool, add a method for testing
Create a tool class to add test methods
The STATICLIBTOOL.M file is implemented as follows
TATICLIBTOOL.M File Implementation
3, the operation of the project to pack
Run Engineering Package
After running, we will see the project in the Products folder under the Libstaticlib.a file from red to black. Right-click the show in Finder to find it in its directory. This is our packed. a static file.
Packed. A static file
But is it over? Of course not, we know that the biggest meaning of static library exists is to hide the specific implementation of the code, but this is also hidden too thoroughly, always have to expose some interface or header file for people to call it.
4, open to oral documents
Targets->build phases->copy files-> "+" you need to expose the header file
Here we make the new test class StaticLibTool.h public
Public access to oral documents
After exposing the header file, we rerun the package with the 1, 2, 3 process above, and we'll get a header file and a. A static library (pictured below), which is exactly what we need.
Re-run the package
5. Create a new operational project, drag the two packaged files into the project test
Test
Select Iphone7 Simulator Run, the program is running normally, click on the emulator screen, print log as follows:
Log output
We can see the output is OK, package. A static library is done.
But don't be too happy. When I switch the simulator to Iphone5 run, the compiler does not pass directly, the error is as follows:
The IPhone 5 emulator Runtime Compilation error
What does the figure "Undefined Symbols for architecture i386" mean? It means our LIBSTATICLIB.A static library does not support the i386 schema. What the hell is i386? It's not clear that you can pull up and look at the "CPU architecture for IOS devices," and here's not much to explain.
The IPhone 5 Simulator is exactly the i386 architecture, and the static library we're packing does not support. But the iphone 7 simulator runs without problems, which means that the static library we packaged supports the CPU architecture x86_64 of the iphone 7 simulator. See the next step in how to view the schemas supported by the static library.
6, terminal view of the static library supported by the architecture
Terminal->CD into library file path->lipo-info library name
Terminals View the schemas supported by the static library
As you can see in the figure above, our static library only supports the X86_64 schema, which means that this static library can only run emulator devices between Iphone5s-iphone7plus. So just when we ran the iphone5 simulator, the compiler would make an error.
Here to further explain, packaging static library, you use what simulator to run, packaging out of the static library to support what simulator architecture, and just when I was packaged with IPhone7 run, so only support the architecture x86_64. So this is too much trouble, can you pack a static library to support a variety of architecture simulator? The answer is yes, please see the next step.
7. Configure All Simulator architecture
Project-> buildseting-> build Active architecture only set to No
Set all emulator schemas to fit
Once the setup is complete, we rerun the packaging of the static library file (you can choose an emulator at any time) and follow the 6th-step terminal to view its supported architectures, and we can see that the result of the terminal output is to support both I386 and x86_64, which means that all emulators are supported at the same time.
Pack it up. A static library has come to an ending, however, according to the above process packaging can only run on the simulator, the real machine is not running, because the iOS true machine device and simulator architecture is not the same (why not like to pull up to see), so not finished (I do not want to AH), please see the next step
8, packaging support the real machine structure of the static library
All processes are the same as above, only when we run packaging to choose the real machine to run, the following figure you can choose to plug in the real machine, you can choose generic iOS Devices. Of course, don't forget. Setting supports all true machine model schemas: Build Active architecture is set to No.
Packaging a static library that supports the true machine schema
We can look at the packaged terminals to see the results as follows:
Terminal output Results
The image above can be seen to support both ARMV7 and arm64, which is to support all iOS devices. All right, here's the package. A static library is an ending.
. frameworke File Static Library packaging
1, still Xcode create a new project Frameworkelib, select the project as follows:
To create a new project
When the creation is complete, we can see that the project itself takes a FrameworkeLib.h file, which is similar to a master header file.
FrameworkeLib.h file
2, to create the class that needs testing, in order to facilitate me to the above packaging, a test class Staticlibtool directly drag to use.
3, set up to support all emulator architecture or the True machine architecture (and packaging. A 7th Step)
4. Public header File
Target-build phases-headers-Drag header files that need to be exposed from project into public
Exposure header File
5, set the package is a static library. Because dynamic libraries can also be in the form of a framework, they need to be set, otherwise the default is to play the dynamic library
target->buildsetting-> search Keyword mach->mach-o Type set to static Library (this default option is dynamic)
Set the static library to be packaged
6, check the real machine or simulator to run the device packaging (and packaging. A), the finished products folder under the Frameworkelib.framework file from red to black, the right button shows in the Finder display as follows:
Packaging results
Frameworkelib.framework drag into the project can be used directly, where no longer testing. In addition, it is important to add that the static library is packaged with a beta (Debug) or release version, based on your own requirements, and how to set the next step.
7. Set up beta and release versions of packaged static libraries (. A and. Frameworke)
Product-> scheme-> Edit scheme-> run-> Select Debug or Release
Set version
Thank you for reading, I hope to help you, thank you for your support for this site!