iOS Dynamic Library

Classes cannot be used in the real framework or cannot contain class files

Calling the Nsclassfromstring function directly in the real framework returns NULL if the specified class is forced to be loaded or referenced directly through the class name

The difference between a static library and a dynamic library in Linux

A. Different

A library is essentially a binary format of executable code that can be loaded into memory for execution. There are two kinds of library, static library and dynamic library.

1. Static function library

The name of such a library is generally libxxx.a; the file compiled from the static function library is larger, because all the data of the entire library is integrated into the target code, and his advantages are obvious, that is, the compiled execution program does not require external library support, because all the functions used are already compiled. This, of course, will also be a disadvantage, because if the static library changes, then your program must be recompiled.

2. Dynamic Function Library

The name of such a library is generally libxxx.so; relative to the static function library, the dynamic function library is not compiled into the target code when it is compiled, and your program executes to the relevant function to invoke the corresponding function in the library, so the dynamic function library produces the smaller executable file. Since the library is not integrated into your program, it is applied and invoked dynamically while the program is running, so you must provide the appropriate library in the running environment of the program. The change of dynamic function library does not affect your program, so the upgrade of dynamic function library is more convenient.

Two, the same

are generated by the *.O target file

The difference between a dynamic library and a static library in iOS development

Benefits of using a static library

1, modular, Division of labor

2, avoid small changes often lead to a large number of duplicate compilation connections

3, can also be reused, note is not shared use

Dynamic Library use has the following benefits:

1 using a dynamic library, you can reduce the final executable file size

2 using dynamic libraries, multiple applications share the same library files in memory, saving resources

3 using a dynamic library, you can update the dynamic library file to update the application without recompiling the connection executable.

From 1 can be drawn, the entire application module, teamwork, Division of labor, the impact is relatively small.

and other benefits,

As can be seen from 2, in fact, the dynamic library should be called Shared library, in this sense, Apple banned the use of dynamic libraries in iOS development can be understood:

Because in the current Iphone,ipodtouch,ipad above the program is a single process, that is, a moment only one process is running, then you write a shared library,

Who do----share to? (When you use only one application exists, others should be suspended, even if multiple processes can be run at the same time, can others use your shared library of things?) This is a custom for your own program. ）

----Currently Apple's AppStore does not support module updates and cannot update a single file (unless you write an update mechanism: You have your own server to place the latest dynamic library files)

As for why Apple prohibits iOS development from using dynamic libraries, I guess the two reasons.

Deep understanding of the iphone static library

In the actual programming process, some common functions are usually made into function libraries for other programs to use, and the other is to reuse the code, and the other is to make the secret of the core technology. So in the actual project development, often use to function library, function library is divided into static library and dynamic library two kinds. As with most familiar dynamic languages and static languages, the so-called static and dynamic is relative to the compile time and runtime: the static library will be linked to the target code when the program is compiled, the program will not need to change the static library when the program is compiled, and the dynamic library will not be linked to the target code at compile time, It is only loaded when the program is running, because the existence of a dynamic library is also required during program run time.

The official iphone only supports static library linking.

Deep understanding of the framework (frameworks, in fact, equivalent to static frameworks, not dynamic libraries)

The packaging framework is also a more important feature that can be used to do things:

(1) Packaging function modules, such as a more mature functional modules packaged into a package, and then later on their own or other colleagues to use more convenient.

(2) Packaging projects, sometimes encountered this situation, is a company to find two development companies to do two projects, and then asked one of their projects nested into another project, at this time can also be Bai nested projects packaged into the framework to put in, so it is more convenient.

Why do we need frameworks (framework)?

It is cumbersome to share libraries in a developer-friendly way. You need to include not only the library itself, but also all the header files, resources and so on.

The way Apple solves this problem is the framework (framework). Basically, this is a folder that has a fixed structure and contains all the things that are necessary to reference the library. Unfortunately, iOS prohibits all dynamic libraries. At the same time, Apple also removed the ability to create a static iOS framework from Xcode.

Xcode can still support the ability to create frames, restart this feature, and we need to make some minor changes to Xcode.

Encapsulating the code in a static framework is allowed by the App Store. Although the form is different, it is still a static library in nature.

Categories of framework (framework)

Most frameworks are in the form of a dynamic-link library. Because only Apple can install dynamic libraries on iOS devices, we can't create this type of framework.

Static-link libraries are just like dynamic libraries, except that they link binary code at compile time, so using static libraries does not have a problem with dynamic libraries (that is, nobody but Apple can use dynamic libraries on iOS).

The "pseudo" framework is implemented by deciphering Xcode's target bundle (using some scripts). It does not differ from the static frame on the surface and when it is used. The functionality of the "pseudo" framework project is almost indistinguishable (not all) from the real Framework project.

The embed framework is a wrapper for a static frame so that Xcode can get the resources within the frame (pictures, plist, NIB, and so on).

This release includes templates for creating static and pseudo frameworks, and the "embedding" framework for both.

Which template to use?

This release has two templates, each with "strong" "weak" two categories. You can choose the one that works best (or both).

The biggest difference is that Xcode cannot create a "true" framework unless you install the static framework file Xcspec in Xcode. This is really a pity (this file is for project use, not framework).

Simple section

Simply put, you can decide which template to use:

• If you don't want to modify Xcode, use the "pseudo" framework version
• If you just want to share the binary (not the project), both of them can be
• If you want to share the framework with developers who don't want to modify Xcode, use the "pseudo" framework version
• If you want to share the framework with developers who have modified Xcode, use the "true" framework version
• If you want to rely on the framework project as another project (via workspace or subproject), use the "true" frame (or "pseudo" frame, after using-framework--)
• If you want to include additional static libraries/frameworks in your framework project and link them to the final result so that you don't need to add them individually to the user project, use the pseudo framework

"Pseudo" framework

The "pseudo" framework is a cracked "Reloacatable object File" (the relocatable format of the target files, which holds the code and data, and is suitable for connecting with other target files to create an executable target file or a shareable target file). It allows Xcode to compile something like a frame--it's actually a bundle.

The pseudo-frame template divides the entire process into several steps, using certain scripts to produce a true static framework (based on a static library instead of a Reloacatable object file). Also, the framework project defines it as a wrapper.cfbundle type, a "second-class citizen" in Xcode.

So it works just like a "true" static frame, but when there is a dependency there is a problem.

Dependency issues

If you don't use dependencies, just creating a normal project is no problem. But if you use project dependencies (such as in Workspace), Xcode is a tragedy. When you click the ' + ' button under "Link Binary with Libraries", the pseudo frame cannot be displayed in the list. You can manually drag it in from the products of your "pseudo" framework project, but when you edit your main project, a warning appears:

warning:skipping file '/somewhere/myframework.framework ' (unexpectedfile type ' Wrapper.cfbundle ' in Frameworks & Libraries Build phase)

and accompanies the link error in the "pseudo" frame.

Fortunately, there is a way to solve it. You can manually tell Linker to use your frame to link using the "-framwork" switch in "other Linker Flags":

-framework Myframework

The warning still exists, but at least it can be properly linked.

Add a different library/frame

If you join other static (not dynamic) libraries/frameworks into your "pseudo" framework project, they will "link" into your final binary framework file. In a "true" framework project, they are pure references, not links.

You can avoid this situation in your project by simply including the header file instead of the static library/framework itself (so that the compilation passes).

The "true" framework

All aspects of the "true" framework conform to the "true" standard. It is a true static framework, just as it was created using the same feature that Apple removed from Xcode.

In order to create a real static framework project, you must install a Xcspec file in Xcode.

If you publish a "real" framework project (rather than compiling it), the person wishing to compile the framework must also install the Xcspec file (using the installation script for this release) so that Xcode can understand the target type.

Note: If you are publishing a fully compiled framework instead of a framework project, the end user does not need to install anything.

I have submitted a report to Apple and want them to update the file in Xcode, but that will take a little time. Openradarlink here

Add other static libraries/frameworks

If you join other static (not dynamic) libraries/frameworks to your "real" framework projects, they will only be referenced and not be linked to the final binaries as "pseudo" frameworks.

Upgrading from an earlier version

If you are upgrading from MK6 or earlier, using the "true" static framework, and using the previous version of Xcode4.2.1, run uninstall_legacy.sh to uninstall any earlier fixes for Xcode. Then run install.sh and restart Xcode. If you use Xcode4.3, you only need to run install.sh and restart Xcode.

Installation

Either run the real framework directory or the install.sh script under the fake framework directory to install (or two you are running).

Restart Xcode and you will see the Staticios framework (or fake Static IOS framework) under the framework&library of the New Project Wizard.

Uninstall, run the unistall.sh script and restart Xcode.

Create an iOS framework project

1. Create a new project.
2. Project type Select the static iOS framework under Framework&library (or fake static iOS framework).
3. Select Include unit tests (optional).
4. Add classes, resources, and so on in target.
5. The header file to be used for any other project must be declared public. Enter Target's build phases page, expand the Copy headers entry, and drag the header file that requires public from project or private to the public section.

Compiling your IOS framework

1. Select scheme for the specified target
2. Modify the scheme's run configuration (optional). The Run configuration uses debug by default, but you may want to use release when you are ready to deploy.
3. The compilation framework (whether the target is iOS device and simulator will compile the same binary, so it doesn't matter who's chosen).
4. Select your framework from the products below, "show in Finder".

There are two folders under the build directory:(yourframework). Framework and (your framework). Embeddedframework.

If your framework has only code, no resources (compared to slices, scripts, xib, CoreData, MOMD files, etc.), you can distribute (yourframework) The framework to your users. If you also include resources, you must distribute (your framework). Embeddedframework to your users.

Why do I need the embedded framework? Because Xcode does not look for resources in a static framework, if you distribute (your framework). Framework, all resources in the frame are not displayed and are not available.

A embedded framework is just an additional package outside of the framework, including symbolic links to all of the resources of this framework. The purpose of this is to enable Xcode to find these resources.

Using the iOS framework

The iOS framework is similar to a regular Mac OS dynamic framework, except that it is statically linked.

Use a framework in your project and simply drag it into your project only. When you include a header file, remember to enclose the frame name with angle brackets instead of double quotes. For example, for frame myframework:

#import <MyFramework/MyClass.h>

Usage issues

Headers not Found

If Xcode cannot find the header file for the frame, you may have forgotten to declare them public. Refer to "Creating an iOS Framework Project" in step 5th.

No Such Product Type

If you do not have iOS Universal framework installed in Xcode and attempt to compile a Universal framework project (for the "true" framework, not the "fake" framework), this results in the following error:

Target Specifies product type ' com.apple.product-type.framework.static ', but there's no such product type for the ' Iphonesi Mulator ' Platform

In order to compile the "true" iOS static framework, Xcode needs to make some changes, so in order to compile a "true" static framework project, install it in all development environments (not required for users who use the framework, only required to compile the framework).

The selected run destination is not a valid for this action

Sometimes, Xcode fails and loads the wrong active settings. First, try restarting Xcode. If the error persists, Xcode produces a bad item (because of a bug in Xcode4, this problem occurs for any type of project). If so, you need to create a new project again.

Link warning

When the framework target is first compiled, Xcdoe will report that the folder cannot be found during the link phase:

Ld:warning:directory not found for option '-l/users/myself/library/developer/xcode/deriveddata/ Myframework-ccahfoccjqiognaqraesrxdyqcne/build/products/debug-iphoneos '

At this point, the target can be clean and recompiled, and the warning will be eliminated.

Core Data MOMD not found

For framework projects and application projects, Xcode compiles MOMD (managed object model files) in different ways. Xcode simply creates a. mom file in the root directory without creating a. MOMD directory (the directory contains versioninfo.plist and. Mom files).

This means that when instantiating Nsmanagedobjectmodel from a model in a embedded framework, you must use the. mom extension as the model URL instead of the. momd extension.

Nsurl *modelurl = [[NSBundle mainbundle]urlforresource:@ "MyModel" withextension:@ "Mom"];

Unknown class MyClass in Interface Builder file.

Because static frames use static links, Linker rejects all code that it deems useless. Unfortunately, linker does not check the Xib file, so if the class is referenced in Xib and not referenced in the O-C code, Linker removes the class from the final executable file. This is a linker problem, not a framework problem (this problem also occurs when you compile a static library). The Apple built-in framework does not occur because they are dynamically loaded at runtime, and dynamic libraries that exist in iOS device firmware are not likely to be deleted.

There are two ways to solve this problem:

Let the end user of the framework turn off the Linker optimization option by adding-OBJC and-all_load in their project's other Linker flags.

Add a code reference to the class in another class of the framework. For example, suppose you have a MyTextField class that is linker out. Suppose you also have a myviewcontroller that uses Mytextfield,myviewcontroller in Xib and is not removed. You should do this:

In the MyTextField:

+ (void) Forcelinkerload_ {}

In the Myviewcontroller:

+ (void) Initialize {[MyTextField forcelinkerload_];}

They still need to add-OBJC to linker settings but do not need to force all_load anymore.

The 2nd method requires you to do a little more work, but it lets the end user avoid turning off linker optimizations when using your framework ( turning off linker optimizations will cause the object file to swell ).

Unexpected file type ' Wrapper.cfbundle ' in frameworks &libraries build phase

This problem occurs when a "dummy" framework project is relied upon as a workspace or as a subproject (the "real" framework project does not have this problem). Although this framework project produces the correct static framework, Xcode can only see from the project file that this is a bundle, so it emits a warning when checking dependencies and skips it during the linker phase.

You can manually add a command to allow linker to link correctly during the link phase. In the Otherlinker flags of the project that relies on your static framework, add:

-framework Myframework

The warning still exists, but does not cause the link to fail.

Libraries being linked or not being linked into the finalframework

Unfortunately, the "true" framework and the "fake" framework templates work differently in handling the introduction of static libraries/frameworks.

The true framework template uses normal static library generation steps and does not link other static libraries/frameworks to the final production.

The "fake" framework template uses "cheat" xcode to make it think that it is compiling the target file in a relocatable format, and in the link phase it is like compiling an executable file to link all the static code files to the final build (although it does not check whether the target code is true). To achieve the same effect as a "true" framework, you can include only the library/frame header file into your project, without the need to include the library/framework itself.

Unrecognized selector in (some class with a category method)

If your static library or static framework contains a module (only declared in the category code, without a class implementation), linker will not be clear, and the code is removed from the binary file. Because there is no such method in the resulting file, a "Unrecognizedselector" exception is reported when a method defined in this category is called.

To work around this, add a "dummy" class to the module code that contains this category. Linker discovers that there is a complete o-c class that links the category code to the module.

I wrote a header file LoadableCategory.h to alleviate this workload:

#import "Someconcreteclass+myadditions.h"

#import "LoadableCategory.h" make_categories_loadable (someconcreteclass_myadditions); @implementation Someconcreteclass (myadditions)

...

@end

When using this framework, you still need to add-OBJC to the other Linker flags in build setting.

Unit test crashes before executing any code

If you create a static frame (or library) target in Xcode4.3, tick "withunit tests" when you try to run the unit test, it crashes:

Thread 1:exc_bad_access (code=2, address=0x0) 0 0x00000000---dyldbootstrap:start (...)

This is a bug in Lldb. You can use GDB to run unit tests. Edit scheme, select Test, and change the debugger debugger from Lldb to gdb in the Info tab.

The above content is transferred from http://blog.csdn.net/stackhero/article/details/9032999

The following is transferred from http://www.2cto.com/kf/201404/292034.html

Dynamic Library This technique appears to be very early, the application uses the dynamic library to have the convenient place also has the painful place. It was a little strange to find out that iOS didn't support the development of the dynamic library shortly after contacting iOS, but think it might be Apple's security.

However, in the development, there is always a situation is able to use the dynamic library more convenient when the search for a few days of information, and finally made a dynamic library, share a bit.

The option to generate a dynamic library is not available at all in Xcode, so we need to generate the dynamic library from the OS X template, but the resulting content needs to be modified to be used.

1. Modify some of the configuration inside the build setting

Base sdk--needs to be modified into iOS SDK

OS X Deployment target--modified to compile Default

2. Compile, this will be an error

Check dependencies:target Specifies product type "com.apple.product-type.library.dynamic", but there ' s no such product Ty PE for the ' Iphoneos ' platform

This is the report Iphoneos platform does not support such product types, this is more troublesome, but we can still modify a series of xcspec files to circumvent this problem.

This needs to be implemented by modifying some of the Xcode tools ' configurations. Specifically:

Open Xcode.app/contents/developer/platforms/macosx.platform/developer/library/xcode/specifications/macosx Product Types.xcspec This file, search for the "com.apple.product-type.library.dynamic" section, then copy the relevant section and paste it into xcode.app/contents/developer/ Platforms/iphonesimulator.platform/developer/library/xcode/specifications/iphone Simulator Producttypes.xcspec Inside

Open the XCODE.APP/CONTENTS/DEVELOPER/PLATFORMS/MACOSX.PLATFORM/DEVELOPER/LIBRARY/XCODE/SPECIFICATIONS/MACOSX Package Types.xcspec This file, search for the "com.apple.package-type.mach-o-dylib" section, then copy the relevant section and paste it into xcode.app/contents/developer/ Platforms/iphonesimulator.platform/developer/library/xcode/specifications/iphone Simulator Packagetypes.xcspec Inside

This is modified for simulator, in order to be used for the real machine, for xcode.app/contents/developer/platforms/iphoneos.platform/developer/library/ The corresponding files in the Xcode/specifications directory are also handled as such.

3. Ensure several compilation parameters

installation directory changed to @executable_path

Mach-o type changed to Dynamic library

Executable extension changed into Dylib

Executable prefix empty

Precompile Prefix header changed to No

Prefix Header Empty

At this time to compile, it should be able to pass.

We can add methods to the library, and then write the application to invoke the method in the library, in practice, it is feasible.

iOS Dynamic Library