したがって、多くのオールインワン最適化スクリプトは同じ方法を使用しており、そのうちのいくつかは完全に時代遅れであるか、長期的には有害です。要約すると、「オールインワン」最適化スクリプトの大部分は、これらの最適化がどのように、またはなぜ機能するのか明確な考えがなく、まとめて推奨されるチューニングにすぎません。ユーザーはスクリプトをフラッシュし、パフォーマンスが突然速くなると主張します。 （（ 実際、パフォーマンスの向上を引き起こしたのは、デバイスを再起動するという非常に単純な行為である可能性が最も高い場合です。 、 デバイスのRAM内のすべてがクリーンアップされるため） 。
このAppualsの独占記事では、「」に関する最も一般的な推奨事項のいくつかに焦点を当てます。 最適化」 Androidのパフォーマンス、そしてそれが単なる神話なのか、それともデバイスのパフォーマンスの正当な調整なのか。
スワップ
神話リストの一番上にあるのはAndroidスワップです。これは、Androidの最適化と見なされるという点でかなりばかげています。スワップの主な目的は、ページングファイルを作成して接続することです。これにより、メモリ内のストレージスペースが解放されます。これは賢明に聞こえます 紙の上に 、しかしそれは本当に サーバ 、ほとんど対話性がありません。
Androidスマートフォンのスワップを定期的に使用すると、キャッシュをすり抜けることに起因する深刻な遅延が発生します。たとえば、アプリケーションがスワップに保存されているグラフィックを表示しようとした場合、別のアプリケーションとのデータスワップを配置してスペースを解放した後、ディスクを再ロードする必要があるとします。本当に散らかっています。
一部の最適化愛好家は、スワップは問題を提供しなかったと言うことができますが、それはパフォーマンスを向上させるスワップではありません-それは組み込みのAndroidメカニズムです 低メモリキラー 、使用されていない肥大化した優先度の高いプロセスを定期的に強制終了します。 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つは 杉 、そして誰かがこのトピックについて私たちが間違っていることを証明しようとする可能性があると確信していますが、最初にシーダーの歴史を調べる必要があります。
Android用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システムが実現しました。
グーグルはAndroid3.0の後にこのバグを壊しました、それでも何らかの理由で、Seederはまだポップアップします 「推奨される調整」 Androidのパフォーマンス最適化のリスト。さらに、Seederアプリには、同じものを使用しているかどうかに関係なく、Seederの機能を含むsEFixのようないくつかの類似物があります rngd または代替 持っている 、または/ dev / urandomと/ dev / randomの間のシンボリックリンクですらあります。これは、最新のAndroidシステムではまったく意味がありません。
その意味がない理由は、新しいAndroidバージョンが3つの主要コンポーネントで/ dev / random /を使用しているためです– libcrypto 、SSL接続の暗号化、SSHキーの生成など。WEP/ WPAキーを生成するWPA_supplication / hostapd、そして最後に、EXT2 / EXT3 / EXT4ファイルシステムの作成でIDを生成するための少数のライブラリ。
そうするとき シーダー または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のマルチタスクは、アプリケーションがバックグラウンドで静かに動作する従来のモデルに基づいており、バックグラウンドアプリの数に制限がないという点で、他のモバイルオペレーティングシステムとは異なります（ 開発者向けオプションで設定されていない限り、これは一般的に推奨されません） –さらに、バックグラウンド実行への移行機能は停止されませんが、システムはメモリ不足の状況でバックグラウンドアプリを強制終了する権利を留保します（ このガイドの前半で、低メモリキラーとメモリ不足キラーについて説明した場所を参照してください） 。
に戻るには 低メモリキラー メカニズムにより、Androidは限られた量のメモリとスワップパーティションの欠如で動作し続けることができます。ユーザーは引き続きアプリケーションを起動して切り替えることができ、システムは未使用のバックグラウンドアプリをサイレントに強制終了して、アクティブなタスクのためにメモリを解放しようとします。
これは初期のAndroidにとって非常に便利でしたが、何らかの理由でタスクキラーアプリの形で人気が出てきました。これは一般的に有益というよりも有害です。タスクキラーアプリは、設定された間隔で起動するか、ユーザーによって実行され、大量のRAMを解放するように見えます。これは、ポジティブと見なされます。空きRAMが多いほど、デバイスが高速になります。ただし、これはAndroidの場合とは異なります。
実際、大量の空きRAMがあると、デバイスのパフォーマンスとバッテリー寿命に悪影響を与える可能性があります。アプリがAndroidのRAMに保存されていると、アプリの呼び出しや起動などがはるかに簡単になります。Androidシステムはすでにメモリにあるため、アプリへの切り替えに多くのリソースを費やす必要はありません。
このため、タスクキラーはかつてほど人気がありませんが、Androidの初心者は、何らかの理由でタスクキラーに依存する傾向があります（ 悲しいことに、情報の欠如） 。残念ながら、新しいトレンドがタスクキラーに取って代わりました。 低メモリキラー メカニズムの調整。これは例えば MinFreeManager 主なアイデアは、システムがバックグラウンドアプリの強制終了を開始する前に、RAMのオーバーヘッドを増やすことです。
したがって、たとえば、標準RAMは4、8、12、24、32、および40 Mbの境界で動作し、40 MBの空きストレージ容量がいっぱいになると、キャッシュされたアプリの1つがメモリに読み込まれます。 実行されていません 終了します。
したがって、基本的に、Androidには常に少なくとも40 MBの使用可能なメモリがあります。これは、以前にもう1つのアプリケーションを収容するのに十分です。 低メモリキラー クリーンアッププロセスを開始します。つまり、Androidは、ユーザーエクスペリエンスを妨げることなく、利用可能なRAMの最大量を使用するために常に最善を尽くします。
悲しいことに、一部の自作愛好家が推奨し始めたのは、LMKが起動する前に値をたとえば100 MBに上げることです。これで、ユーザーは実際に 失う RAM（100 – 40 = 60）なので、このスペースを使用してバックエンドアプリを保存する代わりに、システムはこの量のメモリを保持します 自由 、まったく目的がありません。
LKMチューニング 便利なことができます 512 RAMを搭載したはるかに古いデバイスの場合ですが、誰がそれらを所有しているのでしょうか。 2GBは現代の「予算範囲」であり、4GB RAMデバイスでさえ最近「中程度」と見なされているため、LMKの調整は本当に時代遅れで役に立たない。
I / Oの調整
Androidの多くの最適化スクリプトでは、I / Oサブシステムに対応する微調整がよく見られます。たとえば、を見てみましょう 落雷！ 次の行を含むスクリプト：
エコー0> $ i / queue /ローテーション;エコー1024> $ i / queue / nr_requests;
最初の行はSSDを処理する際のI / Oスケジューラーの指示を示し、2番目の行はキューI / Oの最大サイズを128から1024に増やします。$ i変数にはブロックデバイスのツリーへのパスが含まれているためです。 / sysであり、スクリプトはループで実行されます。
その後、CFQスケジューラに関連する行が見つかります。
エコー1> $ i / queue / iosched / back_seek_penalty;エコー1> $ i / queue / iosched / low_latency;エコー1> $ i / queue / iosched /ママアイドル;
この後に他のプランナーに属する行が続きますが、最終的には、最初の2つのコマンドは次の理由で無意味です。
最新のLinuxカーネルは、デフォルトで使用しているストレージメディアの種類を理解できます。
長い入出力キュー（ 1024など） 最新のAndroidデバイスでは役に立たず、実際にはデスクトップでも意味がありません。実際には、 頑丈なサーバー 。お使いの携帯電話は頑丈なLinuxサーバーではありません。
Androidデバイスの場合、入出力で優先されるアプリケーションや機械的なドライバーは事実上ないため、最適なプランナーはnoop / FIFOキューであるため、このタイプのスケジューラーは「 微調整」 I / Oサブシステムに対して特別なことや意味のあることは何もしていません。実際、これらのマルチスクリーンリストコマンドはすべて、単純なサイクルに置き換える方が適切です。
/ sys / block / mmc *のiの場合; echo noop> $ i / queue / scheduleer echo 0> $ i / queue / iostatsを実行します
これにより、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];次に、sysctl -w vm.dirty_background_ratio = 10; sysctl -w vm.dirty_ratio = 20;それ以外の場合、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_velocityro。 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タグ アンドロイド 開発 読んだ12分
