最も一般的なAndroid最適化の神話が暴かれる

Androidのパフォーマンスを向上させるための専用のガイドや、全体的な最適化のヒントがあります。 それらのいくつかは合法であり、他は理論のみに基づいているか、Androidシステムの時代遅れの操作方法であるか、単なるナンセンスです。 これには、スワップの推奨事項、build.propに追加された値、およびLinuxカーネルの変数の変更が含まれます。

パフォーマンス、バッテリー寿命などを大幅に向上させることを約束するオールインワンのフラッシュ可能な.zipが多数あります。 微調整のいくつかは実際に機能しますが、大部分は単なるプラセボ効果であり、さらに悪いことに、実際にはデバイスに悪影響を及ぼします。

それは、人々が故意に悪意のあるスクリプトをリリースしているということではありません。Playストアには間違いなく偽の有料アプリがありますが、Androidフォーラムでリリースされた最適化スクリプトは一般的に意図的です。または、さまざまな最適化の微調整を試してみてください。 残念ながら、特に「オールインワン」最適化スクリプトでは、一種の雪玉効果が発生する傾向があります。 ほんの一握りの微調整が実際に何かをする可能性がありますが、スクリプト内の別の微調整のセットはまったく何もしないかもしれません。しかし、これらのスクリプトは魔法の弾丸として受け継がれます。 。

したがって、多くのオールインワン最適化スクリプトは同じ方法を使用していますが、その一部は長期的には完全に時代遅れまたは有害です。 要約すると、「オールインワン」最適化スクリプトの大部分は、これらの最適化が「どのように、またはなぜ動作するのか」という明確な考えのない、推奨されるチューニングです。ユーザーはスクリプトをフラッシュし、パフォーマンスが突然速くなると主張します( 実際に は、デバイスのRAM内のすべてが消去される ため、パフォーマンスの向上を引き起こしたのは、デバイスを再起動する非常に単純な行為である可能性が最も高い

このAppuals専用の記事では、Androidのパフォーマンスを「 最適化する」ための最も一般的な推奨事項と、それが単なる神話なのか、デバイスパフォーマンスの正当な調整なのかを強調します。

スワップ

神話のリストの一番上にあるのはAndroidのスワップです。これはAndroidの最適化と見なされるという点ではかなり馬鹿げています。 スワップの主な目的は、ページングファイルを作成して接続し、メモリ内のストレージスペースを解放することです。 これは紙上では理にかなっているように聞こえますが 、インタラクティブ性をほとんど持たないサーバーに実際に適用できます

Androidスマートフォンのスワップを定期的に使用すると、キャッシュをすり抜けることで生じる深刻な遅延が発生します。 例えば、アプリケーションがスワップに保存されているグラフィックを表示しようとした場合、別のアプリケーションとデータを交換してスペースを解放した後、ディスクを再ロードする必要があるとします。 本当に面倒です。

一部の最適化愛好家は、スワップが問題を提供しなかったと言うことができますが、それはパフォーマンスを向上させるスワップではありません-それは使用されていない肥大化した優先度の高いプロセスを定期的に殺す組み込みの Androidメカニズムlowmemorykillerです LMKは、メモリ不足の状態を処理するために特別に設計され、 kswapdプロセスから呼び出され、一般にユーザー空間プロセスを強制終了します。 これはOOMkiller(out-of-memory killer)とは異なりますが、まったく別のトピックです。

ポイントは、たとえば1GBのRAMを搭載したデバイスは、スワップで必要なパフォーマンスデータに到達できないため、Androidではスワップは絶対に必要ないということです。 その実装は単に遅れを抱えており、最適化するのではなく、パフォーマンスの低下につながります。

zRAM –時代遅れで効率が悪くなった

zRAMは、 古いデバイスのデバイス最適化のための実証済みで効果的な方法です。約512 MBのRAMでのみ動作するKitKatベースのデバイスだと考えてください。 一部の人々が依然として最適化スクリプトにzRAM調整を含めるか、またはzRAMを何らかの最新の最適化調整として推奨するという事実は、一般に最新の運用プロトコルに従わない人々の例です。

zRAMは、MTKチップセットと512 MBのRAMを使用するデバイスなど、エントリーレベルの予算範囲のマルチコアSoCを対象としています。 基本的に非常に安い中国の携帯電話。 基本的にzRAMは、暗号化ストリームを介してカーネルを分離します。

単一コアの古いデバイスでzRAMを使用すると、そのようなデバイスでzRAMが推奨されていても、大量のラグが発生する傾向があります。 これは、空き領域を確保するために同一のメモリページを組み合わせたKSMテクノロジ( カーネル同一ページマージ)でも発生します。 これは実際にGoogleによって推奨されていますが、常にアクティブなコアシーアドがメモリから重複ページを検索するために継続的に実行されているため、古いデバイスでの遅延が大きくなります。 基本的に、最適化の微調整を実行しようとすると、皮肉なことにデバイスの速度がさらに低下します。

Seeder – Android 3.0から廃止

Android開発者の間で最も議論されている最適化のヒントの1つはseederであり、誰かがこのトピックについて間違っていることを証明できると確信していますが、最初にseederの履歴を調べる必要があります。

Android用Seederアプリ

はい、 はるかに古いAndroidデバイスにインストールした後、より良いAndroidパフォーマンスを宣言するレポートが多数あります 。 しかし、なんらかの理由で人々は、これが最新のAndroidデバイスに適用可能な最適化であることを意味すると信じていますが 、これはまったくばかげています。 Seederが依然として維持され、「 最新の」ラグ削減ツールとして提供されているという事実は、誤報の一例です。ただし、これはSeederの開発者の責任ではありません。 それでも、なんらかの理由で、Seederは最新のAndroidシステムの最適化の議論に引き続き登場します。

SeederがAndroid 3.0で基本的に行うことは、Androidランタイムが/ dev / random /ファイルを積極的に使用してエントロピーを取得するバグに対処することです。 / dev / random /バッファーは不安定になり、システムは必要な量のデータがいっぱいになるまでブロックされます。Androidデバイスのさまざまなセンサーやボタンのような小さなものを考えてください。

Seederの作成者はLinux-demon rngdを取得し 、Androidのイナストロイル用にコンパイルしたため、はるかに高速で予測可能な/ dev / urandom経路からランダムデータを取得し、/ dev / randomを許可せずにdev / random /に毎秒マージします/疲れ果てる。 これにより、エントロピーの不足が発生せず、はるかにスムーズに実行されるAndroidシステムが実現しました。

GoogleはAndroid 3.0以降でこのバグを解消しましたが、何らかの理由で、SeederはAndroidのパフォーマンスを最適化するための「推奨調整」リストに引き続き表示されます。 さらに、Seederアプリには、同じrngdまたは代替havegedを使用するか、/ dev / urandomと/ dev / random間の単なるシンボリックリンクを使用するかにかかわらず、Seederの機能を含むsEFixなどの類似物がいくつかあります。 これは、最新のAndroidシステムではまったく意味がありません。

それが無意味な理由は、新しいAndroidバージョンがSSL接続の暗号化、SSHキーの生成などの3つの主要なコンポーネントである/ dev / random /を使用するためです。WPA/ suppa / hostapdはWEP / WPAキーを生成します。 EXT2 / EXT3 / EXT4ファイルシステムの作成時にIDを生成するためのライブラリ。

したがって、 SeederまたはSeederベースの拡張機能が最新のAndroid最適化スクリプトに含まれている場合、 rngdは常にデバイスを起動し、CPU周波数の増加を引き起こすため、デバイスのパフォーマンスが低下します。 。

オデックス

Androidデバイスの標準ファームウェアは、ほぼ常にodexです。 これは、/ system / app /および/ system / priv-app /にあるAPK形式のAndroidアプリの標準パッケージと同じファイル名で、拡張子が.odexであることを意味します。 odexファイルには、バリデーターとオプティマイザー仮想マシンを既に通過した最適化されたバイトコードアプリケーションが含まれており、 dexoptツールなどを使用して別のファイルに記録されます。

そのため、odexファイルは仮想マシンの負荷を軽減し、odexされたアプリケーションの起動を高速化することを目的としています。欠点として、ODEXファイルはファームウェアの変更を防ぎ、更新の問題を作成します。そのため、LineageOSなどの多くのカスタムROMはODEX

ODEXファイルの生成は、Odexer Toolを使用するなど、さまざまな方法で行われます。問題は、純粋にプラセボ効果であるということです。 最新のAndroidシステムが/ systemディレクトリでodexファイルを見つけられない場合、システムは実際にそれらを作成し、/ system / dalvik-cache /ディレクトリに配置します。 これは、たとえば、新しいAndroidバージョンをフラッシュすると、「ビジー、アプリケーションの最適化」というメッセージがしばらくの間表示される場合にまさに発生します。

低メモリキラーの調整

Androidのマルチタスクは、アプリケーションがバックグラウンドで静かに動作する古典的なモデルに基づいており、バックグラウンドアプリの数に制限がないという点で他のモバイルオペレーティングシステムと異なります( 開発者オプションで設定されている場合を除き、一般的に推奨されます) -さらに、システムは低メモリ状況でバックグラウンドアプリを強制終了する権利を留保しますが、バックグラウンド実行への移行機能は停止しません( この前にlowmemorykillerとout-of-memory killerについて説明した場所を参照してください)ガイド)

lowmemorykillerメカニズムに戻るために、Androidは限られた量のメモリとスワップパーティションの不足で動作を継続できます。 ユーザーは引き続きアプリケーションを起動してアプリケーションを切り替えることができ、システムは使用されていないバックグラウンドアプリを静かに強制終了して、アクティブなタスクのためにメモリを解放します。

これは初期のAndroidにとって非常に便利でしたが、何らかの理由でタスクキラーアプリの形で一般的になりました。 タスクキラーアプリは、設定された間隔で起動するか、ユーザーによって実行され、大量のRAMを解放するように見えます。これは肯定的と見なされます。 ただし、Androidの場合はそうではありません。

実際、大量の空きRAMがあると、実際にはデバイスのパフォーマンスとバッテリー寿命に悪影響を与える可能性があります。 アプリをAndroidのRAMに保存すると、呼び出しや起動などがはるかに簡単になります。Androidシステムは、既にメモリにあるため、アプリへの切り替えに多くのリソースを費やす必要はありません。

このため、タスクキラーは以前ほど人気が​​ありませんが、Android初心者は何らかの理由( 悲しいことに情報不足)で依然それらに依存する傾向があります。 残念ながら、 低メモリキラーメカニズムチューニングの傾向であるタスクキラーは新しい傾向に置き換わりました。 これは、たとえばMinFreeManagerアプリであり、主なアイデアは、システムがバックグラウンドアプリを強制終了する前にRAMのオーバーヘッドを増やすことです。

したがって、たとえば、標準RAMは境界で動作します– 4、8、12、24、32、および40Mb。40MBの空きストレージ領域がいっぱいになると、メモリにロードされているが実行されていないキャッシュアプ​​リの1つ終了します。

基本的に、Androidには常に少なくとも40 MBの使用可能なメモリがあり、これはlowmemorykillerがクリーンアッププロセスを開始する前にもう 1つのアプリケーションを収容するのに十分です。つまり、Androidは、ユーザー体験。

残念ながら、一部の自作愛好家が推奨し始めたのは、LMKが起動する前に値をたとえば100 MBに上げることです。ユーザーは実際にRAMを失います(100 – 40 = 60)。アプリを終了すると、システムはこの量のメモリを解放しますが 、まったくその目的はありません。

LKMチューニング 、512 RAMを搭載したはるかに古いデバイスに役立ちますが、それを所有しているのは誰ですか? 2GBは現代の「予算範囲」であり、最近では4GBのRAMデバイスでさえ「中間範囲」と見なされているため、LMKの調整は本当に時代遅れで役に立たないものです。

I / Oの調整

Android向けの多くの最適化スクリプトには、I / Oサブシステムに対処する微調整が含まれています。 たとえば、 ThunderBoltを見てみましょう! 次の行を含むスクリプト:

 echo 0> $ i / queue / rotational; echo 1024> $ i / queue / nr_requests; 

1行目はSSDを扱う際のI / Oスケジューラーの指示を示し、2行目はキューI / Oの最大サイズを128から1024に増やします-$ i変数にはブロックデバイスのツリーへのパスが含まれるため/ sys、およびスクリプトがループで実行されます。

次に、CFQスケジューラに関連する行を見つけます。

 echo 1> $ i / queue / iosched / back_seek_penalty; echo 1> $ i / queue / iosched / low_latency; echo 1> $ i / queue / iosched / slice_idle; 

この後に、他のプランナーに属する行が続きますが、最終的に、最初の2つのコマンドは無意味です:

最新のLinuxカーネルは、デフォルトで動作しているストレージメディアのタイプを理解できます。

長い入出力キュー( 1024など)は、最新のAndroidデバイスでは役に立たず、実際にはデスクトップ上でも意味がありません。実際には、 ヘビーデューティサーバーでのみ推奨されます 。 お使いの携帯電話は頑丈なLinuxサーバーではありません。

Androidデバイスの場合、入出力に優先順位付けされるアプリケーションはほとんどなく、メカニカルドライバーもありません。そのため、最適なプランナーはnoop / FIFOキューです。したがって、このタイプのスケジューラー「 微調整」は、 I / Oサブシステム。 実際、これらのマルチスクリーンリストコマンドはすべて、単純なサイクルに置き換える方が適切です。

 / sys / block / mmc *のi echo noop> $ i / queue / scheduler echo 0> $ i / queue / iostats done 

これにより、I / O統計の蓄積からすべてのドライブのnoopスケジューラーが有効になり、パフォーマンスにプラスの影響がありますが、非常に小さく、ほぼ完全に無視できます。

パフォーマンススクリプトでよく見られるもう1つの無駄なI / O調整は、最大2MBのSDカードの先読み値の増加です。 先読みメカニズムは、アプリがそのデータへのアクセスを要求する前に、メディアからデータを早期に読み取るためのものです。 したがって、基本的に、カーネルは将来どのデータが必要になるかを把握しようとし、それをRAMにプリロードします。これにより、戻り時間が短縮されます。 これは紙上では素晴らしいように聞こえますが、先読みアルゴリズムは間違っていることが多く、RAMの消費が多いことは言うまでもなく、入出力のまったく不要な操作につながります。

RAIDアレイでは1〜8 MBの高い先読み値が推奨されますが、Androidデバイスの場合は、デフォルト値の128 KBのままにしておくのが最善です。

仮想メモリ管理システムの調整

もう1つの一般的な「最適化」手法は、仮想メモリ管理サブシステムの調整です。 これは通常、2つのカーネル変数vm.dirty_background_ratioとvm.dirty_ratioのみを対象としています。これらは、「ダーティ」データを保存するためのバッファーのサイズを調整するためのものです。 ダーティデータは、通常、ディスクに書き込まれたデータですが、メモリにはまだ残っており、ディスクへの書き込みを待機しています。

LinuxディストリビューションとAndroisの両方でのVM管理サブシステムに対する一般的な調整値は次のようになります。

 vm.dirty_background_ratio = 10 vm.dirty_ratio = 20 

そのため、ダーティデータバッファーがRAMの合計量の10%になると、 pdflushフローが起動し、ディスクへのデータの書き込みが開始されます。ディスクにデータを記録する操作が強すぎる場合、バッファは増加し続け、使用可能なRAMの20%に達すると、システムはプリバッファなしで、同期モードの後続の書き込み操作に切り替わります。 これは、 データがディスクに書き込まれる (「ラグ」 とも呼ばれる)まで、ディスクアプリケーションへの書き込み作業がブロックされることを意味します。

バッファサイズが10%達していない場合でも、システムは30秒後に自動的にpdflushを開始することを理解する必要があります。 10/20の組み合わせはかなり合理的です。たとえば、1GBのRAMを搭載したデバイスでは、100 / 200MBのRAMに相当します。これは、速度がシステムNANDの速度レコードを下回ることが多いバーストレコードに関しては十分すぎる-メモリ、またはSDカード(アプリのインストール時やコンピューターからのファイルのコピー時など)。

何らかの理由で、スクリプト作成者は、この値をさらに高くして、不合理なレートにしようとします。 たとえば、 Xplix最適化スクリプトでは、 50/90という高いレートを見つけることができます。

 sysctl -w vm.dirty_background_ratio = 50 sysctl -w vm.dirty_ratio = 90 

メモリが1 GBのデバイスでは、これはダーティバッファの制限を500/900 MBに設定します。これはAndroidデバイスではまったく役に立ちません。 ディスクへの一定の記録の下でのみ動作するためです。 Linuxサーバー。

落雷! スクリプトはより合理的な値を使用しますが、全体的には、まだかなり無意味です。

 if ["$ mem" -lt 524288]; then sysctl -w vm.dirty_background_ratio = 15; sysctl -w vm.dirty_ratio = 30; elif ["$ mem" -lt 1049776];次にsysctl -w vm.dirty_background_ratio = 10; sysctl -w vm.dirty_ratio = 20; else sysctl -w vm.dirty_background_ratio = 5; sysctl -w vm.dirty_ratio = 10; fi; 

最初の2つのコマンドは512 MBのRAMを搭載したスマートフォンで実行され、2番目のコマンドは1 GBで、その他のコマンドは1 GB以上で実行されます。 しかし、実際には、デフォルト設定を変更する理由は1つしかありません。内部メモリまたはメモリカードが非常に遅いデバイスです。 この場合、変数の値を広げること、つまり次のようなものを作成するのが合理的です:

 sysctl -w vm.dirty_background_ratio = 10 sysctl -w vm.dirty_ratio = 60 

次に、サージシステムがディスクにデータを記録することなく操作を書き込むと、最後まで同期モードに切り替わりません。これにより、アプリケーションは記録時の遅延を減らすことができます。

その他の無駄な調整とパフォーマンスチューニング

本当に何もしない、もっと多くの「最適化」があります。 それらのほとんどはまったく効果がありませんが、他の方法でデバイスを劣化させながらパフォーマンスを改善するものもあります( 通常、パフォーマンスとバッテリーの消耗につながります)

ここでは、Androidシステムとデバイスに応じて、有用な場合とそうでない場合がある追加の一般的な最適化をいくつか示します。

  • 加速–パフォーマンスと低電圧を改善する小さな加速–バッテリーを少し節約します。
  • データベースの最適化-理論的には、これによりデバイスのパフォーマンスは向上するはずですが、疑わしいです。
  • Zipalign –皮肉なことに、Android SDKに組み込まれているストア内のAPKファイル内のコンテンツのアライメントにもかかわらず、多くのソフトウェアがzipalignを介して送信されないことがわかります。
  • 不要なシステムサービスを無効にし、使用されていないシステムとほとんど使用されないサードパーティアプリケーションを削除します。 基本的に、ブロートウェアのアンインストール。
  • 特定のデバイス用に最適化されたカスタムカーネル(すべてのニュークリアスが同等に優れているわけではありません)。
  • I / Oスケジューラのnoopについてはすでに説明しました。
  • 飽和アルゴリズムTCP Westwood –ワイヤレスネットワーク用のデフォルトのAndroid Cubicでより効率的に使用され、カスタムカーネルで利用可能。

無駄な設定build.prop

XDA DevelopersフォーラムのLaraCraft304は調査を実施し、「エキスパート」の使用に推奨される印象的な数の/system/build.prop設定がソースAOSPおよびCyanogenModに存在しないことを発見しました。 リストは次のとおりです。

 ro.ril.disable.power.collapse ro.mot.eri.losalert.delay ro.config.hw_fast_dormancy ro.config.hw_power_saving windowsmgr.max_events_per_sec persist.cust.tel.eons ro.max.fling_velocity ro.min.fling_velocity ro。 kernel.checkjni dalvik.vm.verify-bytecode debug.performance.tuning video.accelerate.hw ro.media.dec.jpeg.memcap ro.config.nocheckin profiler.force_disable_ulog profiler.force_disable_err_rpt ersist.sys.shutdown.mode ro.HOME_APP_ADJ 

興味深い記事