2

私はこれを読んでいました: http://developer.android.com/training/articles/perf-tips.html

特に、内部ゲッターとセッターに関するこれ:

仮想メソッドの呼び出しは、インスタンス フィールドのルックアップよりもはるかにコストがかかります。一般的なオブジェクト指向プログラミングの慣例に従い、getter と setter をパブリック インターフェイスに配置することは合理的ですが、クラス内では常にフィールドに直接アクセスする必要があります。

JIT を使用しない場合、フィールドへの直接アクセスは、単純な getter を呼び出すよりも約 3 倍高速です。JIT (直接フィールド アクセスはローカルにアクセスするのと同じくらい安価です) を使用すると、直接フィールド アクセスは単純な getter を呼び出すよりも約 7 倍速くなります。

おそらくパブリックメソッドも参照する「仮想メソッド呼び出し」について言及しています。私のクラスには、メソッドをオーバーライドしてはならないメソッドがたくさんあります。例えば：

public class Something {
    private float m_Float = 0.0f;
    public float getFloat () {
        return m_Float;
    }
}

派生クラスであっても、常に「getFloat()」が「m_Float」を返すようにします。メソッドを「final」とマークすると、Android デバイスのパフォーマンスが向上しますか? そうでない場合でも、最終的な正確性は const-正確性と同じくらい重要ですか? 同様に、仲間の同僚が最終的な正確さを忘れると、Java プログラマーは怒りますか?

メソッドをマークfinalするとパフォーマンスが向上する場合、パフォーマンスの向上は次の場合に無効になりますか?

public class Base {
    public int getRandomNumber () {
        return 4; //chosen by fair dice roll.
                  //guaranteed to be random.
    }
}
public class Derived extends Base {
    public final int getRandomNumber () {
        return 6; //chosen by second fair dice roll.
                  //guaranteed to be more random.
    }
}

この時点でコードを最適化することにはあまり興味がありませんが、最終的な正確さのビットには興味があります.Java が関係する標準的な規則に精通していません。

[編集]

さて、上記のリンクは可能な答えとして与えられています: Android Performance - 'Avoid Internal Getters/Setters'

回答としてマークされた返信は、次のリンクにリンクしています: Dalvik と Android ツールチェーンからどのような最適化を期待できますか?

単純なゲッターとセッターがインライン化されているようです。

Gingerbread では、ゲッター/セッターの単純なインライン化を追加しました。基礎となる JIT フロントエンドは依然として単純なトレース ベースであるため、呼び出し先にブランチがある場合、インライン化されません。ただし、仮想ゲッター/セッターを問題なくインライン化できるように、インライン キャッシュ メカニズムが実装されています。

そしてコメントで、これは尋ねられます：

(3) 可能な限りメソッドを final と宣言する必要がありますか? それとも、それでも仮想呼び出しサイトとしてカウントされますか?

そして、これは答えです：

(3) はい、どうぞ

だから、ここのコメントなどで、すべてが解決したと思います. （メソッドで使用する必要がある場合を除きfinalます。しかし、それはおそらくすぐに答えられるでしょう。私には信念がありますが、それが検証されるか、理由で反論されるのを待っているので..）

[編集]

また、これは Android のドキュメントという意味ではありませんか。パフォーマンスのヒントについて..時代遅れですか？

4

1 に答える 1

1

個人的には、定数以外には使用しないfinalことをお勧めします。かなりの数年間の開発で、定数final以外の適切な使用法を実際に見たことがありません。static final ...このfinalキーワードは、テストに関しては特に厄介です。本当に高いテスト カバレッジが必要な場合は、 PowerMockなどを使用java.net.URLする必要があります。final class

疑わしい場合は、現実的なパフォーマンス テストを作成し、2 つのシナリオをプロファイリングします。識別可能な違いがない場合はfinal、コードなどに制限を追加しないでください。次のようなステートメント:

直接フィールド アクセスは、単純な getter を呼び出すよりも約 3 倍高速です

は、実数がなければまったく意味がありません。単純な getter の呼び出しに 20 マイクロ秒しかかからない場合、コストを 60 マイクロ秒に増やしても意味がありません。モバイル アプリケーションの場合、ゲッターとセッターがパフォーマンスの問題を引き起こすことはありません。

常に正確さを第一に、可読性を第二に、保守性を第二に考えてコーディングしてください。

于 2013-06-18T23:02:31.087 に答える