2017-06-23 17 views
0

たとえば、次のインターフェイスがあります。特定のUIKitコンポーネントの代わりにUIKitをインポートすると、パフォーマンス/コンパイル時間のメリットはありますか?

#import<UIKit/UIKit.h> 

@interface someClass : NSObject 
@property (nonatomic, copy) NSString *string; 
@property (nonatomic, copy) UIFont *font; 
@end 

UIKit全体を不必要にインポートしているような気がします。私は次のことが上のものと違うかどうかは分かりません。

#import<Foundation/Foundation.h> 
#import<UIKit/UIFont.h> 

@interface someClass: NSObject 
@property (nonatomic, copy) NSString *string; 
@property (nonatomic, copy) UIFont *font; 
@end 

私はUIKitだけをインポートすると、他のすべての必要なフレームワークをリストする必要はありません。しかし、そうすることの本当の利点/欠点はありますか?また、#importを使用する代わりに、この特定の例で何らかの違いがある@importモジュールを使用しました。

答えて

2

理論上、はい。これがCとObjective-Cヘッダーの設計方法です。それはコンパイラのための作業が少なく、コンパイル時間が速いので、必要なコンポーネントだけをインポートすることになっています。 Appleフレームワークを見ると、通常はどのように動作するのですか(それぞれのヘッダーは、使用するコンポーネントのみをインポートします)。

これは、実際には必要なヘッダーの一覧を維持するための膨大な作業であり、パフォーマンスの向上はほとんど見られません。これは、UIKitコンポーネントが非常に結びついているため、UIFont.hヘッダーがほかのUIKitヘッダーをインポートし、他のヘッダーなどをインポートすることになります。そして、たぶん大部分のUIKitを毎回インポートすることになります。

実際に違いを生み出すのは、Modulesというコンパイラの機能ですが、これは有効にする必要があります(ただし、デフォルトで有効になっていると思いますが、Xcodeのビルド設定でEnable modulesをチェックしてください)。たとえば、UIKitモジュールなどのモジュールを使用すると、コンパイラは最初にインポートされた後にモジュール全体をコンパイルしてからキャッシュします。ソースファイル内の同じモジュールの他のすべてのインポートは、このキャッシュされたバージョンを使用します。その結果、コンパイル時間が大幅に短縮されます。

デフォルトでは、@import UIKit;を実行してUIKitモジュールをインポートしますが、コンパイラはUIKitモジュール(モジュールが有効な場合)のインポートとしても理解します。同様に動作します。

ドット表記法(例:@import UIKit.UIFont;)を使用してモジュールの一部をインポートすることもできますが、モジュール全体のコンパイルとキャッシングが引き続き実行されるため、パフォーマンスの向上とは見なされません。ここでも、コンパイラは#import<UIKit/UIFont.h>@import UIKit.UIFont;として理解します。

あなたの質問への答えは、#import<UIKit/UIKit.h>とと同じ結果が得られます。最初のものを使うべきです。なぜなら、コンパイラの作者に感謝してくれてありがとう、もう一度考えることはないからです!

関連する問題