アクセス制御によるパフォーマンスの改善

数年前、Appleチームは興味深い記事「ダイナミック送信の削減による生産性の向上」を公開しました。 この記事は非常に興味深いもので、Swiftとそのコンパイラーの微妙な側面を強調しています。



今日の記事では、Swiftのパフォーマンスとアクセス制御がSwiftに与える影響について説明します。 アクセス制御は、初心者の開発者が見落としがちなメカニズムです。 この記事の目的は、作成するコードを熟考することの重要性と、コードの各行が全体像にどのように適合するかを示すことです。

アクセス制御について少し

Swiftのアクセス制御は簡単に習得できます。 アクセスレベルとその定義は近年少し変更されており、現在、Swiftには信頼できるアクセス制御ソリューションがあります。



Objective-Cを使用する場合、アクセス制御の利点を理解するまでに時間がかかる場合があります。 アクセスレベルの効果的な使用は、初心者の開発者と経験豊富な開発者を区別する概念の1つです。 これがなぜそうなのかをお見せしましょう。

アクセスレベルの定義以上のもの

自分で作業する場合や小さなチームで作業する場合、アクセス制御はあまり役に立たないかもしれません。 他のソフトウェアプロジェクトに統合されたフレームワーク、ライブラリ、またはSDKを開発している場合、アクセス制御が本当に役立つことは事実です。 ただし、サードパーティによる配布および使用のためにソースコードベースで作業している場合にのみ、アクセス制御が有用または必要であると考える場合は、間違いです。



アクセス制御には多くの利点があり、そのうちのいくつかは見落としがちです。 適切なアクセス制御の明らかな利点は通信です。 privateキーワードをクラスのインスタンスメソッドに付加することにより、インスタンスメソッドがサブクラスによってオーバーライドされるべきではないことを暗黙的に報告します。 慎重に選択された1つのキーワードを使用して、コードはそれ自体を表しています。 各開発者は、プライベートと宣言されている場合にインスタンスメソッドをオーバーライドできない理由を理解しています。

Swiftのパフォーマンスの改善

ただし、アクセス制御には、多くの新しいSwift開発者が気付いていない副作用があります。 コンパイラは、コードのパフォーマンスを最適化するために使用したアクセスレベルをチェックすることをご存知ですか？ これが今日お話ししたいことです。



アクセス制御がより効率的なソフトウェアにどのようにつながるかを理解するために、Swiftへのメソッドの送信について説明する必要があります。 心配しないで。 基本のみを考慮します。 これはルートからの技術的な逸脱にすぎませんが、興味深いものになることをお約束します。

メソッドディスパッチとは

オブジェクトのメソッドを呼び出すか、そのプロパティの1つにアクセスすると、このオブジェクトにメッセージが送信されます。 ランタイムは、メッセージに一致するメソッドを判別する必要があります。 この例を見てください。

window.makeKeyAndVisible()
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

UIWindowのインスタンスであるウィンドウオブジェクトでmakeKeyAndVisible（）メソッドを呼び出します。 実行時に、メッセージはウィンドウオブジェクトに送信されます。 メッセージに対してどのメソッドを呼び出す必要があるかは明らかなように思えるかもしれませんが、常にそうであるとは限りません。



makeKeyAndVisible（）メソッドを置き換えるUIWindowのサブクラスを扱っている場合はどうなりますか？ ランタイムは、サブクラスまたはスーパークラスでmakeKeyAndVisible（）メソッドを呼び出すかどうかを決定する必要があります。



メソッドディスパッチは、特定のメッセージに対して呼び出されるメソッドを決定するためにランタイムが使用する一連のルールです。 Swiftは、直接ディスパッチ、テーブルディスパッチ、メッセージディスパッチの3つのタイプに依存しています。 直接送信は静的送信とも呼ばれます。 メッセージとテーブルの送信は、動的送信の一種です。

ダイナミックディスパッチ

メッセージ配信は、Objective-CおよびObjective-Cランタイムの権限です。 送信された各メッセージは動的に送信されます。 これはどういう意味ですか？ Objective-Cランタイムは、実行時にメッセージに対して呼び出すメソッドを示し、クラス階層をチェックします。 そのため、Objective-Cは非常に動的な言語です。 Objective-Cのダイナミズムは、 Key-Value Observingや動作モデルを含むいくつかのCocoa機能の能力でもあります。



動的ディスパッチには1つの重要な欠点があります。 ランタイムはメッセージに対してどのメソッドを呼び出すかを決定する必要があるため、動的ディスパッチ自体は直接ディスパッチに比べて遅くなります。 つまり、動的ディスパッチにはオーバーヘッドがほとんどありません。

静的ディスパッチ

直接ディスパッチとも呼ばれる静的ディスパッチは、独自の違いがあります。 コンパイラーは、コンパイル時にメッセージを呼び出すメソッドを決定できます。 名前が示すように、これは動的な提出ではありません。 柔軟性とダイナミズムで失われたものは、生産性で達成されます。



ランタイムは、実行時に呼び出すメソッドを決定する必要はありません。 直接送信を使用する場合、動的送信に関連するわずかなパフォーマンスはまったく利用できません。

パフォーマンスの最適化

メソッドのディスパッチの詳細は掘り下げませんが、覚えておく必要があります。静的ディスパッチは動的ディスパッチよりも効率的です。 パフォーマンスを向上させるために、コンパイラのタスクは、メソッドの呼び出しを可能な限り動的ディスパッチから静的ディスパッチに昇格させることです。

アクセス制御による最適化

Objective-Cはメッセージの送信のみに依存していますが、Swiftは直接、表形式、およびメッセージ送信の組み合わせを使用します。 Swiftは静的送信を好みます。 議論に集中するために、この記事の残りの部分で静的および動的なディスパッチに注目します。



継承は強力なパラダイムですが、同時に、コンパイラーがメソッドの呼び出し方法を正確に判断することがより困難になります。 この例を見てください。

 import UIKit class ViewController: UIViewController { // MARK: - View Life Cycle override func viewDidLoad() { super.viewDidLoad() // Fetch Notes fetchNotes() } // MARK: - Helper Methods func fetchNotes() { ... } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ViewControllerクラスはfetchNotes（）メソッドを定義します。 メソッドとプロパティはデフォルトで内部で宣言されていることをご存知でしょう。つまり、同じモジュールで定義されている他のオブジェクトがメソッドまたはプロパティを使用できることを意味します。 fetchNotes（）をinternalとして宣言するだけで十分ですか？ これには特定の依存関係があります。



内部キーワードをfetchNotes（）メソッドにバインドしたため、 ViewControllerのサブクラスはfetchNotes（）メソッドをオーバーライドできます。 その結果、 fetchNotes（）メソッドが呼び出されたときに、コンパイラは実行する実装を決定できません。 ランタイムでは、 fetchNotes（）メソッドへの呼び出しを動的に送信する必要があります

書いたコードの分析

経験豊富な開発者が作成したコードを見ると、作業中のプロジェクトにどのように適合するかを分析します。 メソッドの実装は、ソリューションの一部にすぎません。 ViewControllerのサブクラスはfetchNotes （）メソッドをオーバーライドする必要がありますか？ 答えがいいえの場合、キーワードprivateまたはfileprivateを添付する必要があります。 これは、アクセス制御のコンテキストで意味があるだけでなく、生産性も向上させます。 これはなぜですか？



コンパイラーは、 fetchNotes（）メソッドをチェックすると、 privateとして宣言されていることを認識します。これは、このメソッドをサブクラスでオーバーライドできないことを意味します。 コンパイラはこのヒントを取得し、メソッド宣言にfinalを安全に出力します。 finalキーワードがメソッド宣言に付加されるたびに、動的メソッドの代わりにこのメソッドの呼び出しを静的に送信できるため、パフォーマンスがわずかに向上します。

完全なモジュール最適化

この記事は、モジュール全体の最適化について言及せずには完了しません。 Swiftコンパイラーはソフトウェアエンジニアリングの驚くべき創造物であり、知らない多くの素晴らしい機能を備えています。 これらの優れた機能の1つは、モジュール全体の最適化です。



デバッグビルドでは、モジュールの最適化はデフォルトで無効になっています。 これはコンパイル時間の短縮につながりますが、保存時間の代価を支払います。 モジュール全体を最適化しないと、プロジェクトの各ファイルは、ソースコードデータベースの残りを考慮せずに個別にコンパイルされます。 これは開発中に適しています。



ただし、さらに配布するためにプロジェクトを作成する場合、モジュール全体の最適化により、アプリケーションのパフォーマンスを最適化できます。 コンパイラは、各ファイルを個別に処理しなくなりました。 彼はあなたのプロジェクトであるパズルを作成します。 それは何を意味し、なぜ重要なのですか？



前に示したコードスニペットをもう一度見てみましょう。 fetchNotes（）の呼び出しは 、実行時に動的にディスパッチされることに注意してください。 モジュール全体の最適化が有効になっている場合、これはそうではありません。 コンパイラがモジュール全体、プロジェクトをチェックし、各ファイルが大きな画像にどのように収まるかを判断すると、 fetchNotes（）メソッドをオーバーライドするViewControllerのサブクラスが存在しないことを検出します。 これは、コンパイラがfetchNotes（）メソッドの宣言についてfinalを推測できることを意味します。



finalキーワードは、メソッドまたはプロパティをサブクラスでオーバーライドできないことを意味します。 先ほど見た結果、 fetchNotes（）が privateとして宣言されていなくても、 fetchNotes（）の呼び出しは静的な方法で送信できます。 スマートコンパイラ。 そうじゃない？

トレーニングを継続します。

教育に投資することがいかに重要であるかを強調しながら、開発者の開発についてよく書きます。 Swift言語の詳細を学ぶことは、開発者として私を変えました。 今日私が書いたコードは、1年前に書いたコードとは異なります。



メソッドの送信は最先端のトピックのように思えるかもしれませんが、自動参照カウントまたはプロトコル指向プログラミングについて学ぶことと同じくらい重要だと思います。 Swiftは簡単に把握できます。 優れたデベロッパーになることを真剣に考えている場合は、学習を続けて視野を広げることが重要です。