掌握Apple动态库（dylib）：多语言创建与调用指南

需积分: 18 132 浏览量更新于2024-08-01 收藏 753KB PDF 举报

动态链接库（Dynamic Library）是软件开发中常见的一种技术，特别是在Apple的开发环境中，如Objective-C和C++应用的构建。苹果的官方文档《DynamicLibraryProgrammingTopics》详尽介绍了如何在iOS和macOS平台上创建、管理和使用动态库（dylib），这是Apple系统中用于共享代码和函数模块的关键组件。首先，动态库允许开发者将常用的功能或模块封装为独立的可重用部分，这样可以避免重复编写代码，提高代码复用性和维护性。它支持多种编程语言，如C、Objective-C以及C++，这意味着开发者可以根据自己的需求选择最合适的语言来编写库。在创建动态库时，文档涵盖了以下几个关键主题： 1. **通用指南**：这部分概述了动态链接库的基本概念，包括其优势、何时使用以及如何在项目中导入动态库。 2. **版本管理**：介绍了如何处理不同版本的动态库，确保兼容性和稳定性，包括适配库之间的依赖关系。 3. **编译与链接**：详细解释了如何在Xcode或其他开发工具中设置编译器选项，正确链接动态库到项目中，并处理符号解析和重定位。 4. **语言支持**：分别针对C、Objective-C和C++编程语言，提供了特定语法和实践指导，包括如何声明和实现库中的函数，以及如何正确导出供外部程序调用。 5. **安全性与性能**：涉及动态库的安全特性，比如沙盒模式下的权限管理和内存管理，以及如何优化库的性能，如减少内存泄漏和提高代码效率。 6. **调试与测试**：介绍了如何有效地调试动态库，以及如何编写单元测试来确保库的质量。 7. **发行与分发**：包括如何打包和发布动态库，以及如何在App Store上为用户提供更新和兼容性保证。 8. **法律与许可**：强调了版权保护和商标使用的规范，确保在商业用途中遵循Apple的规则，避免侵权。这份文档是Apple为iOS和macOS开发者提供的宝贵资源，对于理解和实践动态链接库技术至关重要，能够帮助开发者高效地构建健壮、可扩展的应用程序。通过阅读和遵循文档中的指导，开发者可以更好地利用动态链接库提升应用程序的性能和用户体验。

A runtime loaded library is a dynamic library the client opens with the dlopen function. Clients do not

include runtime loaded libraries in their link line. The dynamic loader, therefore, doesn’t open these libraries

when the client is loaded. Clients open a runtime loaded library when they’re about to use a symbol it exports.

Clients don’t have any undefined external references to symbols in runtime loaded libraries. Clients get the

address of all the symbols they need from runtime loaded libraries by calling the dlsym function with the

symbol name.

A client must always be compatible with its dependent libraries. Otherwise, an application doesn’t launch

or a runtime loaded library fails to load.

When you design a dynamic library, you may have to consider its ongoing maintenance. Sometime you may

have to make changes to the library to implement new features or to correct problems. But you also have

to think about the library’s existing clients. There are two types of revisions you can make to a library: revisions

that are compatible with current clients and require no client-developer intervention and revisions that

require that clients be linked against the new revision. The former are minor revisions and the latter are

major revisions.

The following sections explore compatibility issues to consider before implementing a library that may need

to updated at a later time.

Defining Client Compatibility

As a library upon which existing clients depend is revised, changes to it may affect the clients’ ability to use

new versions of the library. The degree to which a client can use earlier or later versions of a dependent

library than the one it is linked against is called client compatibility.

Some changes are minor; these include adding symbols that are unknown to clients. Other changes are

major; such changes include removing a symbol, changing a symbol’s size or visibility, and changing the

semantics of a function. All the symbols a library exposes to clients make up the library’s ABI (application

binary interface). The library’s API (application programming interface) comprises only the functions that a

library makes available to its clients. The degree to which a library’s ABI remains the same from the point of

view of the clients that were developed using an earlier version of the library determines the library’s stability.

Ensuring that a library’s ABI remains stable guarantees that clients can use newer versions of the library

unchanged. That is, users of an application that depends on a library that’s updated regularly can see their

application’s performance improve as they update the library (think of the Mac OS X Software Update

mechanism) without obtaining a new version of the application.

For example, assume an application is linked against the first version of a dynamic library and released to

end users. Later, the library’s developer makes minor changes to the library and releases it. When end users

install the new version of the library on their computers, the application can to use the new version without

requiring the end users to get an updated application file from the developer. The application may benefit

from efficiency improvements made to the library’s API. And, depending on how the library was written, the

application might be able to take advantage of features introduced by the new version. However, these

features are accessed by the application only through the API available in the first version of the library. Any

interfaces introduced in the new version of the library go unused by the application.

Figure 1 (page 15) illustrates the life cycle of the Draw dynamic library and one of its clients.

Managing Client Compatibility With Dependent Libraries

Dynamic Library Design Guidelines

Figure 1 The life cycle of a dynamic library and a client

Minor,

compatible revision

Minor,

incompatible revision

Major revision

Draw 1.1

draw_line()

draw_square()

Client 1.0

draw_line()

draw_square()

Draw 1.2

draw_line()

draw_square()

draw_polygon()

Client 1.0

draw_line()

draw_square()

Draw 1.0

draw_line()

draw_square()

Client 1.0

draw_line()

draw_square()

Draw 1.2

draw_line()

draw_square()

draw_polygon()

Client 1.1

draw_line()

draw_square()

draw_polygon()

Draw 2.0

draw_line()

draw_polygon()

Client 1.2

draw_line()

draw_polygon()

This list describes the versions of the library and the client:

■ Draw 1.0 is the initial version of the library. It exports two functions, draw_line and draw_square .

■ Client 1.0 is linked against Draw 1.0. Therefore, it can use the two symbols the library exports.

■ Draw 1.1 has faster versions of draw_line and draw_square , but their semantics are unchanged,

maintaining client compatibility. This is a compatible, minor revision because Client 1.0 can use Draw

1.1.

■ Draw 1.2 introduces the draw_polygon function. The API of the new revision of the library is a superset

of the previous version’s API. The Draw 1.1 API subset of the 1.2 version is unchanged. Therefore, Client

1.0 can use Draw 1.2. However, Client 1.0 doesn't know of the existence of draw_polygon and, therefore,

it doesn’t use it. This is a minor revision because the API Client 1.0 knows about is unchanged in Draw

1.2. But this is also an incompatible revision because the API changed. Clients linked against this version

of the library cannot use earlier versions.

■ Client 1.1 is linked against Draw 1.2 and uses draw_polygon. Client 1.1 cannot use earlier versions of

the library because it uses draw_polygon, a function that isn’t exported by those versions. However, if

the library’s developer adds the weak_import attribute to the symbol’s definition, Client 1.1 would be

able to use earlier versions of the library by ensuring that draw_polygon exists in its namespace before

using it. If the symbol isn’t defined, the client may use other means of performing the desired task, or it

may not perform the task. See “Symbol Exporting Strategies” (page 18) for details.

■ Draw 2.0 doesn’t export draw_square. This is a major revision because a symbol exported in the previous

version of the library is not exported in this version. Clients linked against this version of the library

cannot use earlier versions.

Managing Client Compatibility With Dependent Libraries 15

Dynamic Library Design Guidelines

Clients should be able to use all the minor revisions to the library they’re linked against without relinking. In

general, to use a major revision of a library, the client must be linked against the new version. The client may

also need to be changed to take advantage of new symbols, to adapt its use of symbols that have been

modified, or to not use symbols that are not exported by the new revision.

Note: The header files for your libraries should include only the symbols the libraries’ clients should actually

use. If clients use symbols other than the ones you specify, they limit the compatibility of their products with

new or earlier versions of your libraries.

Specifying Version Information

The filename of a dynamic libraries normally contains the library’s name with the lib prefix and the .dylib

extension. For example, a library called Dynamo would have the filename libDynamo.dylib. However, if

a library may go through one or more revisions after it’s released, its filename must include the major version

number of the revision. Clients linked against libraries whose filename includes the major version number

of the revision never use a new major revision of the library because major revisions are published under

different filenames. This versioning model prevents clients from using library revisions whose API is

incompatible with the API known to the clients.

When you publish a dynamic library intended to have future revisions, you must disclose the library’s major

version number in its filename. For example, the filename for the first version of the Draw library, introduced

in “Defining Client Compatibility” (page 14), could be libDraw.A.dylib. The letter A specifies the major

version number for the initial release. You can use any nomenclature for the major version. For example, the

Draw library could also be named libDraw.1.dylib, or libDraw.I.dylib. The important thing is that

the filenames of subsequent major revisions of the library have different (and preferably incremental) major

version numbers. Continuing the Draw library example, a major revision to the library could be named

libDraw.B.dylib , libDraw.2.dylib, or libDraw.II.dylib. Minor revisions to the library are released

under the same filename used by the previous major revision.

In addition to the major version number, a library has a minor version number. The minor version number

is an incremental number using the format X[.Y[.Z]] , where X is a number between 0 and 65535, and Y

and Z are numbers between 0 and 255. For example, the minor version number for the first release of the

Draw library could be 1.0. To set the minor version number of a dynamic library, use the gcc

-current_version option.

The compatibility version number is similar to the minor version number; it’s set through the gcc

-compatibility_version option. The compatibility version number of a library release specifies the

earliest minor version of the clients linked against that release can use. For instance, the example in “Defining

Client Compatibility” (page 14) indicates that Client 1.1 cannot use versions of the Draw library earlier than

1.2 because they don’t export the draw_polygon function.

Before loading a dynamic library, the dynamic loader compares the current version of the .dylib file in the

user’s file system with the compatibility version of the .dylib file the client was linked against in the

developer’s file system. If the current version is earlier (less) than the compatibility version, the dependent

library is not loaded. Therefore, the launch process (for client applications) or the load process (for client

libraries) is aborted.

Managing Client Compatibility With Dependent Libraries

Dynamic Library Design Guidelines

Note: The dynamic loader performs the version compatibility test only with dependent libraries. Dynamic

libraries opened at runtime with dlopen don’t go through this test.

Specifying Your Library’s Interface

The most important aspect to define before implementing a dynamic library is its interface to its clients. The

public interface affects several areas in the use of the library by its clients, the library’s development and

maintenance, and the performance of the applications in which the library is used:

■ Ease of use: A library with a few but easily understandable public symbols is far easier to use than one

that exports all the symbols it defines.

■ Ease of maintenance: A library that has a small set of public symbols and an adequate set of private

symbols, is far easier to maintain because there are few client entry points to test. Also, developers can

change the private symbols to improve the library in newer versions without impacting the functionality

of clients that were linked against an earlier version.

■ Performance: Designing a dynamic library so that it exports the minimum number of symbols optimizes

the amount of time the dynamic loader takes to load the library into a process. The fewer exported

symbols a library has, the faster the dynamic loader loads it.

The following sections show how to determine which of the library’s symbols to export, how to name them,

and how to export them.

Deciding What Symbols to Export

Reducing the set of symbols your library exports makes the library easy to use and easy to maintain. With a

reduced symbol set, the users of your library are exposed only to the symbols that are relevant to them. And

with few public symbols, you are free to make substantial changes to the internal interfaces, such as adding

or removing internal symbols that do not affect clients of your library.

Global variables should never be exported. Providing uncontrolled access to a library’s global variables leaves

the library open to problems caused by clients assigning inappropriate values to those variables. It’s also

difficult to make changes to global variables from one version of your library to another without making

newer revisions incompatible with clients that were not linked against them. One of the main features of

dynamic libraries is the fact that, when implemented correctly, clients can use newer versions of them without

relinking. If clients need to access a value stored in a global variable, your library should export accessor

functions but not the global variable itself. Adhering to this guideline allows library developers to change

the definitions of global variables between versions of the library, without introducing incompatible revisions.

If your library needs the functionality implemented by functions it exports, you should consider implementing

internal versions of the functions, adding wrapper functions to them, and exporting the wrappers. For

example, your library may have a function whose arguments must be validated, but you’re certain that the

library always provides valid values when invoking the function. The internal version of the function could

be optimized by removing validation code from it, making internal use more efficient. The validation code

can then be placed in the wrapper function, maintaining the validation process for clients. In addition, you

can further change the internal implementation of the function to include more parameters, for example,

while maintaining the external version the same.

Specifying Your Library’s Interface 17

Dynamic Library Design Guidelines

剩余83页未读，继续阅读

archimic

粉丝: 5
资源: 30

掌握Apple动态库（dylib）：多语言创建与调用指南

dynamic trade6汉化版

在动态库(dynamic libraries)和静态库(static libraries)使用模板(template)

在动态库和静态库中使用模板（dynamic libraries ，static libraries）

libpango-1.0.so dynamic libraries from Ubuntu 18.04

Looking for dynamic libraries QWidget: Must construct a QApplication before a QWidget

DLLs ( Dynamic Link Libraries) DLLs ( Dynamic Link Libraries)

Grails Dynamic Tag Libraries.pdf

Porting Windows Dynamic Link Libraries to Linux.zip

初步认识动态链接库（Dynamic Link Libraries，dll）

Writing Win32 Dynamic Link Libraries (Dlls) And Calling Them From Labview

最新资源