私はそれをよりよく説明できるため、言い換えを気にしません。親クラスはFoo
で、内部クラスはFoo$Inner
です::と仮定すると、
問題は、VMがfooとFooの$インナー異なるクラスであるため、違法であることをFooの$インナーからはFooのプライベートメンバーへの直接アクセスを考慮していることです、 Java言語が内部クラスが外部クラスのプライベートメンバーにアクセスすることを許可しています。ギャップを埋めるために、コンパイラは、合成方法のカップルを生成する:それはmValueフィールドにアクセスしたり、外側のクラスのdoStuffメソッドを呼び出す必要があるときはいつでも
/*package*/ static int Foo.access$100(Foo foo) {
return foo.mValue;
}
/*package*/ static void Foo.access$200(Foo foo, int value) {
foo.doStuff(value);
}
内部クラスコードは、これらの静的メソッドを呼び出します。つまり、上記のコードは、アクセサメソッドを使用してメンバーフィールドにアクセスしている場合です。先ほどアクセサーが直接フィールドアクセスよりも遅い方法について説明しました。これは特定の言語イディオムの例であり、「目に見えない」パフォーマンスヒットをもたらします。
パフォーマンスのホットスポットでこのようなコードを使用している場合は、プライベートアクセスではなく、パッケージにアクセスするために内部クラスによってアクセスされるフィールドとメソッドを宣言することでオーバーヘッドを回避できます。残念なことに、これは、同じパッケージ内の他のクラスからフィールドに直接アクセスできるため、これをパブリックAPIで使用しないでください。
出典:https://developer.android.com/training/articles/perf-tips.html#PackageInner
あなたは非静的内部クラスはアンドロイドで推奨されていない読みましたか? – Cristian
これはアンドロイドの問題ではありません。交換可能で高速なコードの場合は、静的なコード以外は避けて、必要な情報をローカルフィールドとして保存してください。内部クラスの問題は、GC'edを取得するために親クラスへの参照を 'null'に設定できないことです。コンパイラは、内部クラスのアクセスがプライベートで親クラスのインスタンスごとに1つの内部クラスがある場合、アクセスメソッドを生成する必要があります。 – Stephan
@Cristianはこのリンクの一番下までスクロールします。http://developer.android.com/resources/articles/avoiding-memory-leaks.html 内部クラスのライフサイクルを制御できない場合は避けてください。ありがとうございます。 – OckhamsRazor