パフォーマンスに関して神経質になる必要はないと思うけど、それなりに気を付けないとスクロール時にガタガタしたりしてしまったりするので、一通り知識としては頭に入れておきたいところだと感じた。Developersミクロなレベルでの最適化の話。(今回はそういう話ではない。:必要ない処理をしない。避けられるならメモリ割り当てを行わない。バージョンの違いによって、あるデバイスでは効率の良いコードであっても別のデバイスではそうでないこともある。有無によっても効率の良いコードが何かは違ってくる。エミュレータでの計測では、パフォーマンスについて、本当に少しのことしかわからない。Objectsオブジェクトの生成はできるだけ避ける、ということ。オブジェクトを受け取って、メソッドの中で追加するようにすればよい。オブジェクトの生成が避けられる。次元配列で代替できるならばその方が良い。配列をそれぞれ別に作って管理した方が良い。一般化すると、短期的に使用される一時的なオブジェクトの生成は避けるべし、ということ。オブジェクトの生成が少ないと、それだけガベージコレクションの頻度が小さくなるので、ユーザー体験に影響する。向けにプログラミングするときよりもリソースの消費には気を使わなければならない、というところか。メソッドにすべき、という話。メソッド呼び出しのコストが気になる場所ってそんなあるのかどうかわかんないけど。重要ってわけでもないのかな。なくても速いのだろうか。しておきましょう、って話。し、変数のルックアップのコストもなくなる。それはしない方が良い。メソッドの呼び出しはインスタンスフィールドのルックアップよりもコストが大きい。用意するのは良いが、例えばクラス内で使用する場合は直接フィールドアクセスするべきとのこと。使っても直接的なフィールドアクセスでも良い、みたい。ループを使いましょう。フィールドにアクセスしたりするのは、パッケージプライベートなメソッドを呼び出したり、パッケージプライベートなフィールドにアクセスしたりするよりもコストがかかる。メンバをパッケージプライベートに変更すると良い。(ので、整数値でいいところは整数値を使おう。用に最適化されてたりするので、ライブラリメソッドがあるならそれを使おう。書かれたアプリの高速化のためのものではない、とのこと。無しのデバイスでは、実際の型の変数を通してのメソッド呼び出しの方が、インターフェイス経由のそれよりもわずかに効率が良い。有りの場合は区別できない。有りの場合は局所変数へのアクセスもフィールドへのアクセスもコストは変わらない。変更によりコードが読みやすくなると考えられないならば、やる価値はないだろう。Measure最適化するときには、解決すべき問題があることを認識しておかなければならない。(やみくもにパフォーマンスを上げようとするのではなく、遅い部分があるからこそ最適化しようとするものだ、ってことだと思う。変更前のパフォーマンスを計測することができて、変更して比較できるように。この資料で述べられていることは、全てベンチマークによる裏付けがある。用のマイクロベンチマークのためのフレームワークを使って行われた。役立つものであるとのこと。使うのがオススメらしい。いうのもプロファイリングに便利である。無効化することを認識しておく必要がある。見る細かい話が多いが、普段開発をするうえではそこまで神経質にならなくてもいいのではないかなーという感じがした。メンバにアクセスする話とか。)しかし、例えば描画処理をするごとにメモリ割り当てをしてしまうと、ガベージコレクションが頻発してスクロール時にガタガタしてしまう、というようなことがあるので、パフォーマンスのチップスにはちゃんと身に付けて、避けるべき部分はしっかり避けていかなければならないと思う。>*1:定数変数じゃないものが他にあればどっちにしろ必要だと思うけど。メンバにアクセスするわけなので、そのギャップを埋めるためにコンパイラが仲介用のメソッドを生成するようになっている。仲介用のメソッドを経由する必要があるので、コストがかかる。ドキュメントをぼちぼち読んでます。アプリ開発Windows開発者はてなブログをはじめよう!nobuokaさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。