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

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

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

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

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

このAppualsの独占記事では、「最適化」に関する最も一般的な推奨事項のいくつかに焦点を当てます。 Androidのパフォーマンス、およびそれらが単なる神話であるか、デバイスのパフォーマンスの正当な調整であるかどうか。

スワップ

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

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

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

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

zRAM –時代遅れで、もはや効率的ではありません

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

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

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

シーダー–Android3.0以降は古くなっています

Android開発者の間で最も議論されている最適化のヒントの1つは、 seederです。 、そして誰かがこのトピックについて私たちが間違っていることを証明しようとする可能性があると確信していますが、最初にシーダーの歴史を調べる必要があります。

はい、はるかに古いAndroidデバイスにインストールした後のAndroidのパフォーマンスの向上を宣言するレポートが多数あります。 。ただし、何らかの理由で、これは最新のAndroidデバイスにも適用可能な最適化であると人々は信じています。 、これは絶対にばかげています。 Seederが現在も維持され、「モダン」として提供されているという事実 ラグリダクションツールは誤った情報の例です。ただし、これはSeederの開発者の責任ではありません。これは、Playストアページでさえ、Android4.0以降ではSeederの効果が低いと述べているためです。それでも、何らかの理由で、Seederは最新のAndroidシステムの最適化の議論に登場します。

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

Seederの作者はLinuxデーモンrngd 、Androidのinastroil用にコンパイルされているため、/ dev / random /が使い果たされることなく、はるかに高速で予測可能な/ dev / urandom経路からランダムデータを取得し、それらを毎秒dev /random/にマージします。その結果、エントロピーの欠如を経験せず、はるかにスムーズに動作するAndroidシステムが実現しました。

GoogleはAndroid3.0の後でこのバグを壊しましたが、何らかの理由で、Seederは「推奨される調整」でポップアップします。 Androidのパフォーマンスを最適化するためのリスト。さらに、Seederアプリには、同じ rngd を使用しているかどうかに関係なく、Seederの機能を含むsEFixのようないくつかの類似物があります。 または代替のhaveged 、または/ dev/urandomと/dev/randomの間のシンボリックリンクですらあります。これは、最新のAndroidシステムにはまったく意味がありません。

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

つまり、 Seeder またはSeederベースの拡張機能が最新のAndroid最適化スクリプトに含まれています。最終的に発生するのは劣化です。 rngd であるため、デバイスのパフォーマンスが低下します。 常にデバイスを起動し、CPU周波数の増加を引き起こします。これはもちろん、バッテリー消費に悪影響を及ぼします。

Odex

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

したがって、odexファイルは、仮想マシンをオフロードし、odexedアプリケーションの起動を高速化することを目的としています。欠点として、ODEXファイルはファームウェアの変更を防ぎ、更新で問題を引き起こすため、LineageOSなどの多くのカスタムROMが配布されますODEXなし 。

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

低メモリキラーの調整

Androidのマルチタスクは、アプリケーションがバックグラウンドで静かに動作する従来のモデルに基づいており、バックグラウンドアプリの数に制限がないという点で、他のモバイルオペレーティングシステムとは異なります（デベロッパーオプションで設定されている場合を除く）。ただし、これは一般的に推奨されます） –さらに、バックグラウンド実行への移行機能は停止されませんが、システムはメモリ不足の状況でバックグラウンドアプリを強制終了する権利を留保します（このガイドの前半で低メモリキラーとメモリ不足キラーについて説明した場所を参照してください）。 ） 。

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

これは、初期のAndroidにとって非常に便利でしたが、何らかの理由で、一般的に有益というよりも有害なタスクキラーアプリの形で人気が出てきました。タスクキラーアプリは、設定された間隔で起動するか、ユーザーによって実行され、大量のRAMを解放するように見えます。これは、ポジティブと見なされます。空きRAMが多いほど、デバイスが高速になります。ただし、これはAndroidの場合とは異なります。

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

このため、タスクキラーはかつてほど人気が​​ありませんが、Androidの初心者は、何らかの理由でタスクキラーに依存する傾向があります（残念ながら情報不足） 。残念ながら、新しいトレンドがタスクキラーに取って代わりました。 lowmemorykillerのトレンドです。 メカニズムの調整。これは、たとえば MinFreeManager アプリであり、主なアイデアは、システムがバックグラウンドアプリの強制終了を開始する前にRAMオーバーヘッドを増やすことです。

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

したがって、基本的に、Androidには常に少なくとも40 MBの使用可能なメモリがあります。これは、 lowmemorykillerの前にもう1つのアプリケーションを収容するのに十分です。 クリーンアッププロセスを開始します。つまり、Androidは、ユーザーエクスペリエンスを妨げることなく、利用可能なRAMを最大限に活用するために常に最善を尽くします。

悲しいことに、一部の自作愛好家が推奨し始めたのは、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;

最初の行は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サブシステムに対して特別なことや意味のあることは何もしていません。実際、これらのマルチスクリーンリストコマンドはすべて、単純なサイクルに置き換える方が適切です。

for i in /sys/block/mmc*; do

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デバイスの場合は、デフォルト値の128KBのままにしておくことをお勧めします。

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

もう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 ];then

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つのコマンドは512MBのRAMを搭載したスマートフォンで実行され、2番目のコマンドは1 GBを搭載し、その他のコマンドは1GBを超えています。ただし、実際には、デフォルト設定を変更する理由は1つだけです。それは、内部メモリまたはメモリカードが非常に遅いデバイスです。この場合、変数の値を分散すること、つまり、次のようなものを作成することは合理的です：

sysctl -w vm.dirty_background_ratio=10

sysctl -w vm.dirty_ratio=60

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

追加の役に立たない微調整とパフォーマンスの調整

実際には何もしない「最適化」は他にもたくさんあります。それらのほとんどはまったく効果がありませんが、他の人は一部を改善する可能性があります パフォーマンスの側面。他の方法でデバイスを劣化させます（通常、パフォーマンスとバッテリーの消耗に要約されます） 。

Androidのシステムとデバイスに応じて、役立つ場合と役に立たない場合がある、その他の一般的な最適化をいくつか示します。

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