独自のiOSフレームワークを構築する方法

モバイル開発者のタスクの中で、定期的にSDKを作成するなど、最も一般的な（実際にはアプリケーションを作成する）ことに加えて表示されます。



このようなタスクの例としては、サービス（広告、分析、天気）のREST APIを使用したSDKの作成、アルゴリズムの実装ライブラリ、画像処理などがあります。リストはほぼ無制限です。



このような製品の間違いは、アプリケーションを開発するときよりも修正がはるかに困難です。 アプリケーションの場合、AppStoreで更新し、モデレーションとユーザー更新がパスするのを待ちます。 SDKの場合、チェーンは追加のステップとして成長します-開発者が更新するのを待ちます。



一部の種類のタスクでは、SDKを使用するすべてのアプリケーション開発者が十分に資格を取得できるわけではないため、状況が悪化する可能性があります。 この点で、統合により最小限の複雑さが生じるはずです。 これは、広告SDKと分析に特に当てはまります。これらは、多くの場合、アプリケーションの作成のメインステージよりもはるかに遅く組み込まれ、常に元の開発者によって埋め込まれるわけではありません。



同様のSDKは通常、ライブラリ、テストアプリケーション、ドキュメント、他のツールのプラグインなど、多くのコンポーネントで構成されています。 この記事では、フレームワーク、いくつかの手法、開発機能の形でライブラリを構築することについて説明します。











そもそも、解決すべき問題についての小さなコメント。 私たちの目標は、統合中に最小限の労力と知識を必要とし、その後も副作用のない形式でライブラリを取得することです。

このようなソリューションには、たとえばCocoaPodsがあります。これにより、特に、クローズドソースコードでパッケージを配布できます。 ライブラリをCocoaPodsで公開する方法を説明する記事（たとえば、 hereまたはhere ）が多数あります。おそらく、ここでは繰り返しません。

幅広い開発者向けに設計されたSDKでは、この配布方法は明らかに十分ではありません。一部の開発者は基本的に使用しません（「githubを再びブロックしたらどうする？」）。

フレームワーク形式のSDKアセンブリに焦点を当てます。 ユーザーが統合に必要なのは、ユーザーをプロジェクトにドラッグすることだけです。

iOS8動的フレームワークについて

iOS 8および対応するバージョンのiOS SDKのリリースにより、プロジェクトの作成時に新しいタイプのターゲット（動的フレームワーク）が登場しました。 それが私たちに合っているかどうかを調べてみましょう。

このタイプのターゲットの外観は、まず第一に、メインアプリケーションが共通のコードとリソースを共有する必要がある拡張機能の導入によるものでした。 結果として得られる動的ライブラリは、実際のライブラリと類似しており、たとえばOS Xに部分的にしか存在しません。 実際のところ、ライブラリはまだアプリケーションサンドボックスに残っており、拡張機能とメインアプリケーションにのみ使用できます。

このようなフレームワークを使用してSDKを配布することは可能ですか？ 現時点では、状況はあいまいです。 Appleのドキュメントによると、埋め込みフレームワークはiOS8でのみ使用できます。 アプリケーションには以下の配置ターゲットがまだある場合がありますが、そのようなフレームワークを使用することはできません。 練習は少し異なる状況を示しています。 それでも、EmbeddedフレームワークはiOSバージョン8より前のデバイスで起動できますが、このようなフレームワークを使用するアプリケーションをAppStoreで公開しようとすると、この喜びはすぐに消えてしまいます。 自動検証の段階で、エラーが発行されます。

フレームワーク「...」のMinimumOSVersionが無効です。 最小値はiOS 8.0です。

フレームワークターゲットの最小バージョンを8.0に設定すると、プロジェクトのリンク段階でエラーが発生します。

ld：組み込みdylib /フレームワークはiOS 8.0以降でのみサポートされます

現時点での動的フレームワークの概要は次のとおりです。iOSSDKの最小バージョンが8から始まる場合にのみ、それらを使用および配布できます。

SDKアセンブリについて

Xcode 6が提供するものと同じ動的フレームワークテンプレートを使用してみますが、ここでは静的バージョンをビルドします。 いくつかの変更の後、これは非常に可能です。 始めましょう。



ターゲットのタイプとしてCocoa Touch Frameworkを選択する新しいプロジェクトを作成します。 任意の名前を選択してください。 明確にするために、私たちのものはMySDKと呼ばれます。











SDKのクラスをプロジェクトに追加します。 パブリックに利用できるはずのヘッダーファイルは、パブリックとしてマークされ、デフォルトでプロジェクトで作成されたアンブレラヘッダーにインポートされます。 この例では、MySDK.hと呼ばれます











次に、ターゲットのBuildSettingsに移動し、LinkingセクションでMach-O TypeをStatic Libraryに変更します。











ターゲットのスキームの設定で、起動構成をリリースに変更します。 このアクションは、アクティブなアーキテクチャだけでなく、使用可能なすべてのアーキテクチャでアセンブリを実行するために必要です。









ライブラリを使用する開発者は、おそらくiOSのすべての可能なプロセッサアーキテクチャでコードを実行したいと思うでしょう。 そして、私たちはこれに注意しなければなりません。 現在、アーキテクチャの現在のリストには、デバイス用の3（armv7、armv7s、arm64）とシミュレータ用の2（i386、x86_64）が含まれています。 これを行うには、サポートされている各アーキテクチャのレイヤーを含む、いわゆるファットバイナリライブラリを収集する必要があります。 これを行うには、Aggregateタイプのプロジェクトにターゲットを作成します。 MySDKUniversalと呼びましょう。











BuildPhasesターゲットで、次のスクリプトを使用してスクリプトの実行フェーズを追加します。

FRAMEWORK_NAME="${PROJECT_NAME}" SIMULATOR_LIBRARY_PATH="${BUILD_DIR}/${CONFIGURATION}-iphonesimulator/${FRAMEWORK_NAME}.framework" DEVICE_LIBRARY_PATH="${BUILD_DIR}/${CONFIGURATION}-iphoneos/${FRAMEWORK_NAME}.framework" UNIVERSAL_LIBRARY_DIR="${BUILD_DIR}/${CONFIGURATION}-iphoneuniversal" FRAMEWORK_PATH="${UNIVERSAL_LIBRARY_DIR}/${FRAMEWORK_NAME}.framework" xcodebuild -project ${PROJECT_NAME}.xcodeproj -sdk iphonesimulator -target ${FRAMEWORK_NAME} -configuration ${CONFIGURATION} clean build CONFIGURATION_BUILD_DIR=${BUILD_DIR}/${CONFIGURATION}-iphonesimulator ARCHS='i386 x86_64' xcodebuild -project ${PROJECT_NAME}.xcodeproj -sdk iphoneos -target ${FRAMEWORK_NAME} -configuration ${CONFIGURATION} clean build CONFIGURATION_BUILD_DIR=${BUILD_DIR}/${CONFIGURATION}-iphoneos ARCHS='arm64 armv7 armv7s' rm -rf "${UNIVERSAL_LIBRARY_DIR}" mkdir "${UNIVERSAL_LIBRARY_DIR}" mkdir "${FRAMEWORK_PATH}" cp -r "${DEVICE_LIBRARY_PATH}/." "${FRAMEWORK_PATH}" lipo "${SIMULATOR_LIBRARY_PATH}/${FRAMEWORK_NAME}" "${DEVICE_LIBRARY_PATH}/${FRAMEWORK_NAME}" -create -output "${FRAMEWORK_PATH}/${FRAMEWORK_NAME}"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここでは、フレームワークのアセンブリを2回呼び出し、リポユーティリティを使用して、結果のライブラリを1つのファットバイナリに収集します。 xcodebuildを呼び出すときは、最後のARCHSパラメーターに注意してください。 指定しない場合、デバイスのアセンブリは、デフォルトで変数ARCHS_STANDARDに記述されているアーキテクチャのリストを使用します。 事実、AppleはARCHS_STANDARD変数からXcode6のarmv7を意図的に除外し、armv7、arm64のみを残しているようです。 一般に、これは開発者にとって大きな問題ではなく、アプリケーションでは、ほとんど常にarmv7sを除外できます。 問題のないアプリケーションは、おそらく最適化はあまり行われませんが、A6、A6Xプロセッサで動作します。 ただし、SDKを開発するときは、開発者としてそのような決定を行うべきではありません。 アーキテクチャを明示的にリストする方がはるかに簡単です。

中毒について

まれに、サードパーティの依存関係なしでコードができること。 たとえば、ネットワークライブラリ、さまざまなパーサー、システムフレームワークのクラスのカテゴリなど。 その結果、これらのクラスはすべてSDKに分類され、それを使用する開発者はプロジェクトをビルドするときに問題に遭遇する可能性があります。 これらの問題は、彼がSDKライブラリで「配線」されているものの1つを使用したいとすぐに始まります。 コンパイラは、アプリケーションをビルドするときに「重複したシンボル」の束を生成します。 これは悪いように思われます。開発者は、依存関係からこのライブラリを削除するだけで済みます。クラスはすでにSDKに含まれているからです。 問題は、このライブラリを更新する機能を失い、SDKの可用性に依存するようになることです。



解決策は、いくつかの予約はあるものの、利用可能な最良のものと呼ぶことができますが、使用されるライブラリのインポートされたすべてのシンボルにプレフィックスを追加することです。 フレームワークのビルドプロセスに別のステップが追加されます。 これを行うには、個別のプロジェクトターゲットを作成します。ここで、すべての依存関係を含む静的ライブラリを構築します。 extと呼びましょう。











すべての依存関係をビルドフェーズリストのCompileSourcesセクションに追加します。 最後のフェーズでは、カスタムスクリプトを追加します。 スクリプト自体はここで取得されます 。 ライブラリから文字に追加するプレフィックスと、生成するヘッダーファイルへのパスを修正することを忘れないでください。 私たちの場合、それは次のとおりです。

 header="${SRCROOT}/${PROJECT_NAME}/ext/NamespacedDependencies.h" prefix="MYSDK"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

「ext」ターゲットのアセンブリを開始します。 結果のライブラリは必要ありません。 興味深いのは、結果のヘッダーファイルNamespacedDependencies.hです。 空ではなく、依存ライブラリのシンボル名を置き換えるマクロが含まれていることを確認してください。 その後、結果のヘッダーファイルをメインターゲットMySDKに追加します。



NamespacedDependencies.hは、依存関係ヘッダーをインポートする前にインポートする必要があります。 プロジェクトでこれに最も適した場所は、PCHファイルです。 プロジェクトにまだ存在しない場合は、作成する必要があります。 ターゲット設定でパスを指定することを忘れないでください。











これで、フレームワークを構築するときに、依存ライブラリのすべてのシンボルに指定されたプレフィックスが提供されます。 この事実は、nmユーティリティを実行することで確認できます。

 nm -a /Users/mik/Library/Developer/Xcode/DerivedData/Build/Products/Release-iphoneuniversal/MySDK.framework/MySDK | grep MYSDK 00000000000022be t +[MYSDK_AFURLConnectionOperation batchOfRequestOperations:progressBlock:completionBlock:] 0000000000000000 t +[MYSDK_AFURLConnectionOperation networkRequestThreadEntryPoint:] ...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このトリックの結果、最終プロジェクトで同じ依存関係を使用する場合、SDKは競合を引き起こしませんが、もちろん、アセンブルされたアプリケーションのサイズが大きくなります。

リソースについて

コンパイルされたライブラリ自体に加えて、画像、音声、xibファイルなどのリソースとともに配布する必要がある場合がよくあります。 また、フレームワーク構造には、リソースを含むフォルダーを含めることができます。 ただし、Xcodeは単に無視します。

プロジェクトにリソースを追加できるようにするには、フレームワークと一緒に、リソースを含む別個のバンドルまたはフレームワーク自体の内部にあるリソースへのシンボリックリンクのいずれかを配布する必要があります。

方法1

リソースについては、フレームワーク内に配置する別個のバンドルを作成します。











すべてのリソースをその中に配置します。そして、それはすでにフレームワーク内にあります。

OS Xのバンドルテンプレートを使用したという事実により、バンドルターゲットでさらにいくつかの設定を行うことを忘れないことが重要です。

1. 最新のiOS（デフォルトの最新OS X）にBase SDKをインストールします
2. ビルドフェーズから[ソースのコンパイル]セクションを削除する
3. [高解像度アートワークの結合]設定を[いいえ]に設定します。 そうしないと、異なる画面密度のリソースが1つのTIFFファイルに収集されます

このセットアップ後、MySDKResources.bundleをメインのMySDKターゲットのコピーバンドルリソースセクションと、Target DependenciesのMySDKResourcesターゲットに追加できます。

フレームワーク内にあるバンドルにシンボリックリンクを追加することは残ります。 これを行うには、ユニバーサルラインフレームワークを収集するスクリプトに追加します。

 pushd ${UNIVERSAL_LIBRARY_DIR} ln -sfh "${FRAMEWORK_NAME}.framework/${FRAMEWORK_NAME}Resources.bundle" "${FRAMEWORK_NAME}Resources.bundle" popd
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

フレームワークに加えてSDKを使用するには、このシンボリックリンクをプロジェクトに追加する必要もあります。

方法2

最初の方法の重大な欠点は、フレームワークが不可欠でなくなることです。 そして、これはSDKの配布において非常に重要です。 これが適用される場合、sdkコードにリソースを埋め込むなどの手法を使用できます。 この方法は、小さなリソースを保存するのに便利です。 たとえば、音、ボタンの画像、ロゴ、テキストリソースなどです。 当然、リストはこのセットに限定されず、リソースは絶対に任意です。

ここでは、xxdユーティリティが役立ちます。このユーティリティには、静的C配列の形式で素晴らしい出力オプションがあります。 ビルドフェーズプロジェクトでこのような追加のリソース生成スクリプトを使用します。これは、ソースのコンパイル前にスクリプトの実行として追加する必要があります。

 RESOURCES_FILE="${SRCROOT}/${PROJECT_NAME}/MySDKResources.h" rm -f ${RESOURCES_FILE} pushd "${SRCROOT}/${PROJECT_NAME}Resources/images" for filename in *.png; do xxd -i $filename >> "${RESOURCES_FILE}" done popd
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

結果のMySDKResources.hがプロジェクトに追加されます。 次に、NSDataオブジェクトを作成してリソースを使用し、そのオブジェクトから、画像用のUIImageなどの他のオブジェクトを作成します。

 NSData *pngData = [NSData dataWithBytesNoCopy:close_png length:close_png_len freeWhenDone:NO];
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

プロバージョン管理

SDKを配布する場合、各ビルドが一意のバージョン番号を持っていると非常に便利です。 サポートに連絡するとき、またはバグトラッカーのエラーを説明するとき、主に便利です。 バージョン番号を生成するには多くの方法があります。 これで解決しました。 MAJOR.MINOR.BUILDの形式を使用します。MAJOR.MINORは、リリースポリシー、下位バージョンの互換性などに応じて手動で設定されます。 リポジトリの現在のブランチのコミット数はビルドとして取得されます（リリースビルドは常に同じブランチから発生します）。 このプロセスを自動化するには、フレームワークのビルドフェーズの前にBuildPhasesターゲットに追加される小さなスクリプトが使用されます。 このファイルの第1世代後、publicとマークされたプロジェクトにアンブレラヘッダーで追加することを忘れないでください。

 VERSION=`git rev-list HEAD --count` echo "#define MYSDK_VERSION @\"1.0.${VERSION}\"" > ${SRCROOT}/MYSDKVersion.h
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

その後、バージョン番号はSDK自体で使用できます。 たとえば、APIへのリクエストのパラメーターとして、またはログへの出力用。

結論の代わりに

そのため、この記事では、主にアセンブリに関連するSDK開発のいくつかの重要な側面を取り上げました。 しかし、この点に関しては、sdkに関連する問題の範囲は尽きることはありません。 SDKアセンブリの自動化、ドキュメント、テストSDKの自動化、古いバージョンのiOSのサポート、UnityやAdobe Airなどのツールのプラグインの開発など、興味深いことは影響を受けませんでした。 しかし、これはすでに別の記事であり、おそらく1つの記事ではありません。