iOSPrefix.pchのベストプラクティス

StackOverflow https://stackoverflow.com/questions/2845211

  •  27-09-2019
  •  | 
  •  

質問

iOSプロジェクトのPrefix.pchにさまざまな便利なマクロを追加する多くの開発者を見てきました。

iOS Prefix.pchファイルに何を追加することをお勧めしますか（またはお勧めしませんか）？Prefix.pchはどのように見えますか？

役に立ちましたか？

解決

Ewww…マクロを.pchファイルに入れないでください！.pchファイルは、定義上、プロジェクト固有のプリコンパイル済みヘッダーです。プロジェクトのコンテキストを超えて使用するべきではなく、#includesと#imports以外のものを含めるべきではありません。

ヘッダー間で共有したいマクロなどがある場合は、それらを独自のヘッダーファイル（Common.hなど）に貼り付け、。の先頭にある#include を貼り付けます。pch。

他のヒント

最新のiOSおよびOSXの場合、ユーザーはモジュールを使用する必要があります。これは新しいプロジェクトではデフォルトで有効になっており、インポート/インクルードは@importを使用して実行されます。

モジュールを使用すると、コンパイラはモジュールのコンテンツの中間表現（フレームワークのヘッダーなど）を作成できます。 PCHと同様に、この中間表現は複数の翻訳間で共有できます。ただし、モジュールは必ずしもターゲット固有である必要はなく、宣言を（*.pchに）ローカライズする必要がないため、モジュールはこれをさらに一歩進めます。この表現により、冗長なコンパイラ作業を大幅に節約できます。

モジュールを使用する場合、PCHは必要ありません。おそらく、依存関係に対してローカルな@importを使用することを優先して、モジュールを完全に削除する必要があります。その場合、PCHは、依存関係にローカルなタイピングインクルージョン（とにかく実行する必要があるIMO）からあなたを救うだけです。

ここで、元の質問を振り返ると、PCHをあらゆる種類のランダムなもので埋めることは避けてください。マクロ、定数、#defines、およびあらゆる種類の小さなライブラリ。一般に、ソースファイルの大部分に本当に不要なものは省略する必要があります。 PCHにあらゆる種類のものを配置することは、重みと依存関係を追加するだけです。私は人々が彼らがリンクするすべてのものをPCHに置くのを見ます。実際には、補助フレームワークは通常、ほとんどの場合、いくつかの翻訳にのみ表示される必要があります。例えば。 「これがStoreKitのものです。StoreKitを表示する必要がある場所にのみインポートしましょう。具体的には、これら3つの翻訳です。」これにより、ビルド時間が短縮され、依存関係を追跡できるため、コードをより簡単に再利用できます。したがって、ObjCプロジェクトでは、通常、Foundationに立ち寄ります。 UIがたくさんある場合は、PCHにUIKitまたはAppKitを追加することを検討してください。これはすべて、ビルド時間を最適化することを前提としています。 （ほぼ）すべてを含む大規模なPCHの問題の1つは、不要な依存関係の削除に非常に時間がかかることです。プロジェクトの依存関係が大きくなり、ビルド時間が長くなったら、ビルド時間を短縮するために、不要な依存関係を排除して反撃する必要があります。また、頻繁に変更されるものはすべて、通常、PCHから除外する必要があります。変更には完全な再構築が必要です。 PCHを共有するためのいくつかのオプションがあります。 PCHを使用する場合は、共有のサポートを目指してください。

PCHに入れたものに関しては、何年も前にターゲットの大部分でそれらの使用をやめました。通常、資格を得るのに十分な共通点はありません。私はC ++、ObjC、ObjC ++、Cを記述していることを覚えておいてください。コンパイラーは、ターゲットの言語ごとに1つを出力します。そのため、これらを有効にすると、コンパイル時間が遅くなり、I / Oが高くなることがよくありました。最終的に、依存関係を増やすことは、複雑なプロジェクトで依存関係と戦うための良い方法ではありません。複数の言語/方言を使用する場合、特定のターゲットに必要な依存関係にはさまざまなバリエーションがあります。いいえ、すべてのプロジェクトに最適であるとはお勧めしませんが、大規模なプロジェクトでの依存関係管理にある程度の見通しを与えることができます。

参考資料

私はbbumに同意します。PCHファイルについての私の見解は、#includeまたは#importステートメントのみが含まれている必要があるということです。したがって、役立つ高レベルのマクロがたくさんある場合は、bbumが示唆しているように、そのファイルのCommon.hや#importなどで定義してください。

私は通常、さらに一歩進んで、PCHファイルを使用して、すべてのUIKitおよびFoundationクラスカテゴリ（#import、XXCategories.hなど）のXXを含む#import（NSString+XXAdditions.hは使用するクラス命名プレフィックス規則）というファイルをUIColor+XXAdditons.hします。

ヘッダーファイル「macros.h」を作成します

このヘッダーをPrefix.pchにインポートします

このmacros.hには、すべてのフレームワークとその他の重要なものを配置します。

パフォーマンスが心配な場合でも、心配しないでください。アップルの言葉を見てください。

ヘッダーとパフォーマンス

マスターヘッダーファイルを含めると、 膨満するプログラム、心配しないでください。 OSXインターフェイスが実装されているため フレームワークを使用して、それらのインターフェースのコードは動的に存在します 共有ライブラリであり、実行可能ファイルにはありません。また、コードのみ プログラムで使用されるものは実行時にメモリにロードされるため、 同様に、メモリ内のフットプリントは小さいままです。 コンパイル時に多数のヘッダーファイルをインクルードする場合も、心配する必要はありません。 Xcodeはプリコンパイル済みを提供します コンパイル時間を短縮するヘッダー機能。すべてをコンパイルすることによって フレームワークヘッダーを一度に、ヘッダーを再コンパイルする必要はありません 新しいフレームワークを追加しない限り。それまでの間、 パフォーマンスがほとんどまたはまったくない、含まれているフレームワークからのインターフェース ペナルティ。

マクロにも。h次のような定数をたくさん入れています。 ジェネラコディセタグプレ

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top