スローレンダリングの修正方法（Android vitals）

Question

スローレンダリング用の新しいGoogle Playコンソール - Android vitalsセクションの下位25％にリストされているアプリがあります。私はsuch articlesのため、Google Playが下位25％に該当する場合、Playストアのランキングであなたのアプリに不利益を被る可能性があると思われます。

しかし、このメトリックを改善することはできないようです。それは音楽を演奏し、SeekBarとTextViewを持っていて、音楽プレーヤーのように250msごとに更新されます。

public class MainActivity extends AppCompatActivity { 

    int count; 
    SeekBar seekBar; 
    TextView textView; 

    Runnable runnable = 
      new Runnable() { 
       @Override 
       public void run() { 
        textView.setText(Integer.toString(count)); 
        seekBar.setProgress(count); 
        ++count; 
        seekBar.postDelayed(runnable, 250); 
       } 
      }; 

    @Override 
    protected void onCreate(Bundle savedInstanceState) { 
     super.onCreate(savedInstanceState); 
     setContentView(R.layout.activity_main); 

     seekBar = (SeekBar) findViewById(R.id.seek); 
     textView = (TextView) findViewById(R.id.text); 
     seekBar.post(runnable); 
    } 
} 

ここに全プロジェクト：私は実証する最低限の基本的なプログラムを作っ https://github.com/svenoaks/SlowRendering.git

私はネクサスデバイスと同様のハードウェア上でこのプログラムを実行すると、私は
adb shell dumpsys gfxinfo com.example.xyz.slowrenderingコマンドのためにこれらの結果を得る：

Stats since: 19222191084749ns 
Total frames rendered: 308 
Janky frames: 290 (94.16%) 
90th percentile: 32ms 
95th percentile: 36ms 
99th percentile: 44ms 
Number Missed Vsync: 2 
Number High input latency: 0 
Number Slow UI thread: 139 
Number Slow bitmap uploads: 0 
Number Slow issue draw commands: 283 

これは、ほとんどすべてのフレームがレンダリングに16ミリ秒以上かかることを意味します。私は更新の定期的な性質のためだと思います。私がテストした他のすべての音楽プレーヤーアプリでも、私が見る限り、この遅いレンダリングの問題があります。 Googleのアルゴリズムがアプリランクを損ねるのではないかと心配していますが、スコアを改善する方法はありますか？

Answer 1

レイアウト内のTextViewが問題の原因です。 layout widthがwrap_contentであるため、幅はコンテンツの幅（この例ではテキスト）と同じでなければなりません。したがって、TextView.setTextに電話するたびに、高価な測定/レイアウトのパスが発生します。簡単にlayout_width〜match_parentに設定すると問題が解決します。ここで

が systraceから取られているもの2枚の画像は、それが1つのフレーム内でUIスレッド上の作業の実行を実証しています。一番上のものは layout_width=wrap_contentで、下のものは layout_width=match_parentです。私がテストした方法は、フレームレートを向上させる以下の

2：

• あなたは16msの（seekBar.postDelayed(runnable, 16)）のような短いスパンで実行可能を投稿する場合、あなたはこのなめらかな60fpsの取得：

  をP/s：なぜ私はまだよく分からない。

• Runnableの代わりにcountの値を更新するには、他の方法を使用してください。 Runnableのスケジュールを変更するには、View.postOnAnimation(Runnable)を使用します。サンプルプロジェクトの結果は60FPSです。

EDIT：私はあなたのコードをチェックしpostOnAnimation(Runnable)

Runnable runnable = 
    new Runnable() { 
    @Override 
    public void run() { 
     textView.setText(Integer.toString(count)); 
     seekBar.setProgress(count); 
     seekBar.postOnAnimation(this); 
    } 
    }; 



Runnable updateCount = new Runnable() { 
    @Override public void run() { 
     ++count; 
     seekBar.postDelayed(this, 250); 
    } 
    }; 

Answer 2

を使用しています。これが実際のコードであるか、それ以上のものがあるかどうかは不明です。いずれにせよ、私はアンドロイドのレンダリングの問題のいくつかに注意を引くでしょう。

1.オーバードロー

オーバードローは、あなただけの何か他のものによって再び色を取得する画素で着色してGPUの処理時間を無駄に場所です。これらは、親コンテナレイアウトに背景を追加してから、子も背景を追加した場合や、共通の背景をアプリケーションのテーマのスタイルファイルに追加した後、背景をxmlの他の部分に追加した場合あなたが作成したレイアウトファイル。

オーバードローの原因は何でもかまいません。コードをチェックしてみてください。すべてのモバイルデバイスにデベロッパーツールがインストールされ、デベロッパーオプションでオーバードローをチェックします。 Hereは、オーバードローの公式文書です。各ビューをレンダリングするために

2.ビュー階層

、Androidは三つの段階を経る：

3.draw

2.layout

1.measure

をAndroidがこれらのステージを完了するのにかかる時間は、階層内のビューの数に比例します。あなたのレイアウトファイルには、線形レイアウトを含む制約レイアウトがあることがわかります。私はこれの使用を見ません。制約レイアウトは、開発者がビュー階層を縮小するのに役立つように導入されました。特定のレイアウトが持つことができる子の数を減らす。これを手助けするツールもあります。 Hereはそれに関する正式なアンドロイドガイドです。 これらの手順を試して、GPUレンダリングの問題を把握してください。