1.オーバードローの最適化
何オーバードローのですか？
上書き（上書き）は、画面上の画素が同じ時間枠内で複数回描画され記載されています。で可視UIをやっていない場合、描画動作は、いくつかの画素領域になり、多層重複UI構造が複数回描画されます。これは、CPUとGPUのリソースを浪費することになります。
開発者からオーバードローのエリアを見るためにオプションを設定することができ、赤は最も深刻なオーバードローエリアです。
最適化手法：
1. 移除布局中多余的背景
2. 减少层级嵌套，使用约束布局
3. 减少透明度使用
######カスタムビューonDrawでは、キャンバスを調整することがcanvas.clipRectメソッドを使用することができ、オーバー誇張によって引き起こされます。またはcanvas.quickRejectを使用しています。
2.その他のUIの最適化
代わりに、マージンのマルチユースのパディング
使用マージは、階層を減らすことができます。
使用ViewStub、遅延ロード、全く時間がロードされていないしてはいけません
、のような形状のより多くの使用をビットマップの使用を最小限に抑えます
16msの問題
主流のリフレッシュレートは60回/秒、それは16msのリフレッシュで出て変換されます。この時間は、人間の目よりも大きい場合カトンを感じるだろう。しかし、16msのは少しカスタムビューに長いonDrawの実現のために、可能な限り、実際にはあまりこれ以上することが残された時間を描く、描画するための時間ではありません。
注：彼らはファーストクラスの操作の再作成DISPLAYLIST、DISPLAYLISTレンダリング、アップデート画面に直列にする必要がありますことをすべての変更の表示内容を描きます。プロセスの性能特性は、あなたのビュー、ステータスの変更とレンダリングパイプラインビューの実行性能の複雑さに依存します。たとえば、ボタンを増やす前に、現在のサイズを倍に増加するボタンのニーズの大きさ、再計算する必要があると、親ビューによって他のサブビューの配置を想定。全体HierarcyViewの大きさの再計算をトリガーする操作のサイズを変更し表示します。それが修正されている場合は表示場所HierarchViewは、ビューの他の場所がトリガされます再計算しました。レイアウトは非常に複雑である場合、深刻なパフォーマンス上の問題を引き起こすことは非常に容易になります。
代わりに、JPG、PNGの使用ベクトルグラフィック
