تم فضح معظم الأساطير الشائعة حول تحسين Android

وبالتالي ، فإن الكثير من نصوص التحسين الكل في واحد تستخدم نفس الطرق ، وبعضها قديم تمامًا أو ضار على المدى الطويل. باختصار ، فإن غالبية نصوص التحسين 'الكل في واحد' ليست سوى عمليات ضبط موصى بها مجمعة معًا ، مع عدم وجود فكرة واضحة عن كيفية أو سبب 'عمل هذه التحسينات - ثم يقوم المستخدمون بوميض النصوص البرمجية ، ويدعون أن أدائها أسرع فجأة ( بينما في الواقع ، كان من المرجح أن يكون الإجراء البسيط للغاية المتمثل في إعادة تشغيل أجهزتهم هو الذي تسبب في زيادة الأداء ، حيث يتم تنظيف كل شيء في ذاكرة الوصول العشوائي للجهاز) .

في هذه المقالة الحصرية لبرنامج Appuals ، سنسلط الضوء على بعض التوصيات الأكثر شيوعًا لـ ' التحسين ' أداء Android ، وما إذا كان مجرد خرافة أو تعديل شرعي لأداء الجهاز.

مبادلة، مقايضة

في الجزء العلوي من قائمة الأسطورة ، يوجد نظام تبديل Android - وهو أمر سخيف للغاية من حيث اعتباره تحسينًا لنظام Android. الغرض الرئيسي من Swaps هو إنشاء ملف ترحيل الصفحات وتوصيله ، مما يؤدي إلى توفير مساحة تخزين في الذاكرة. هذا يبدو معقولاً على ورقة ، لكنه ينطبق حقًا على أ الخادم ، التي ليس لها أي تفاعل تقريبًا.

عند استخدام مبادلة هاتف Android بانتظام ، فسيؤدي ذلك إلى تأخيرات شديدة تنجم عن تجاوز الأشياء لذاكرة التخزين المؤقت. تخيل ، على سبيل المثال ، إذا حاول أحد التطبيقات عرض رسم يتم تخزينه في المبادلة ، والذي يتعين عليه الآن إعادة تحميل القرص بعد تحرير مساحة عن طريق وضع تبادل البيانات مع تطبيق آخر. انها حقا فوضوية.

يمكن لبعض المتحمسين للتحسين أن يقولوا إن المقايضة لم تقدم أي مشاكل ، لكنها لا تؤدي إلى تعزيز الأداء - إنها آلية Android المدمجة منخفض الذاكرة ، والتي ستقتل بانتظام العمليات المتضخمة ذات الأولوية العالية التي لا يتم استخدامها. تم تصميم LMK خصيصًا للتعامل مع حالات انخفاض الذاكرة ، ويتم استدعاؤه من ملف kswapd عملية ، ويقتل عمليات مساحة المستخدم بشكل عام. هذا يختلف عن OOMkiller (قاتل نفاد الذاكرة) ، لكن هذا موضوع مختلف تمامًا.

النقطة المهمة هي أن الجهاز الذي يحتوي ، على سبيل المثال ، 1 غيغابايت من ذاكرة الوصول العشوائي لا يمكنه الوصول إلى بيانات الأداء الضرورية في المبادلة ، وبالتالي فإن التبديل ليس ضروريًا على الإطلاق في Android. تنفيذه محفوف بالتأخير ويؤدي إلى انحلال في الأداء بدلاً من تحسينه.

zRAM - قديم ولم يعد فعالاً

zRAM هي طريقة مجربة وفعالة لتحسين الجهاز ، من أجل الأجهزة القديمة - فكر في الأجهزة التي تعتمد على KitKat والتي تعمل على حوالي 512 ميغابايت فقط من ذاكرة الوصول العشوائي. حقيقة أن بعض الأشخاص لا يزالون يقومون بتضمين تعديلات zRAM في نصوص التحسين ، أو يوصون بـ zRAM كنوع من تعديلات التحسين الحديثة ، هي مثال على الأشخاص الذين لا يتبعون بشكل عام أحدث البروتوكولات التشغيلية.

كان zRAM مخصصًا لشرائح SoCs متعددة النوى على مستوى مبتدئ ، مثل الأجهزة التي تستخدم شرائح MTK و 512 ميجابايت من ذاكرة الوصول العشوائي. الهواتف الصينية الرخيصة جدا ، أساسا. ما يفعله zRAM أساسًا هو فصل النواة عبر تيار التشفير.

عند استخدام zRAM على الأجهزة الأقدم بملحق جوهر واحد ، حتى إذا كان zRAM موصى به في مثل هذه الأجهزة ، تميل الكميات الكبيرة من التأخر إلى الارتفاع. يحدث هذا أيضًا مع تقنية KSM ( دمج نفس الصفحة في Kernel) الذي يجمع بين صفحات ذاكرة متطابقة في محاولة لتحرير مساحة. هذا في الواقع موصى به من قِبل Google ، ولكنه يؤدي إلى تأخيرات أكبر على الأجهزة القديمة ، لأن العناصر الأساسية النشطة باستمرار تعمل باستمرار من الذاكرة للبحث عن الصفحات المكررة. بشكل أساسي ، تؤدي محاولة تشغيل قرص التحسين إلى إبطاء الجهاز أكثر ، ومن المفارقات.

Seeder - قديم منذ Android 3.0

واحدة من أكثر نصائح التحسين إثارة للجدل بين مطوري Android هي الارز ، ونحن على يقين من أن شخصًا ما قد يحاول إثبات خطأنا في هذا الموضوع - لكن علينا أولاً فحص تاريخ المصدر.

التطبيق بزار لالروبوت

نعم ، هناك عدد كبير من التقارير التي تعلن عن أداء أفضل لنظام Android بعد التثبيت أجهزة Android الأقدم . ومع ذلك ، يعتقد الأشخاص لأي سبب من الأسباب أن هذا يعني أيضًا أنه تحسين قابل للتطبيق لـ أجهزة Android الحديثة ، وهو أمر سخيف تمامًا. حقيقة أن Seeder لا يزال يتم صيانته وتقديمه باعتباره ' عصري' أداة تقليل التأخير هي مثال على المعلومات الخاطئة - على الرغم من أن هذا ليس خطأ مطور Seeder ، حتى صفحة Play Store الخاصة بهم تشير إلى أن Seeder أقل فعالية بعد Android 4.0+. ومع ذلك ، لأي سبب من الأسباب ، لا يزال Seeder ينبثق في مناقشات التحسين لأنظمة Android الحديثة.

ما يفعله Seeder بشكل أساسي لنظام Android 3.0 هو معالجة الخطأ حيث يستخدم وقت تشغيل Android الملف / dev / random / بشكل نشط للحصول على الانتروبيا. سيصبح / dev / random / buffer غير مستقر ، وسيتم حظر النظام حتى يملأ الكمية المطلوبة من البيانات - فكر في أشياء صغيرة مثل المستشعرات والأزرار المختلفة على جهاز Android.

أخذ مؤلف سيدر شيطان لينكس rngd ، وتم تجميعها لـ inastroil لنظام Android بحيث أخذ بيانات عشوائية من مسار أسرع وأكثر قابلية للتنبؤ به / dev / urandom ، ودمجها في dev / random / كل ثانية ، دون السماح باستنفاد / dev / random /. نتج عن ذلك نظام Android لا يعاني من نقص في الإنتروبيا ، وكان أداؤه أكثر سلاسة.

حطمت Google هذا الخطأ بعد Android 3.0 ، ولكن لسبب ما ، لا يزال Seeder ينبثق 'التعديلات الموصى بها' قوائم لتحسين أداء Android. علاوة على ذلك ، يحتوي تطبيق Seeder على عدد قليل من نظائرها مثل sEFix والتي تتضمن وظائف Seeder ، سواء باستخدام rngd أو البديل قد ، أو حتى مجرد ارتباط رمزي بين / dev / urandom و / dev / random. هذا لا معنى له على الإطلاق لأنظمة Android الحديثة.

السبب في عدم جدوى ذلك هو أن إصدارات Android الأحدث تستخدم / dev / random / في ثلاثة مكونات رئيسية - libcrypto ، لتشفير اتصالات SSL ، وإنشاء مفاتيح SSH ، وما إلى ذلك. WPA_supplication / hostapd الذي يولد مفاتيح WEP / WPA ، وأخيراً ، حفنة من المكتبات لتوليد المعرف في إنشاء أنظمة ملفات EXT2 / EXT3 / EXT4.

اذن متى بزار أو التحسينات المستندة إلى Seeder مضمنة في البرامج النصية الحديثة لتحسين Android ، ما يحدث في النهاية هو ملف انحلال في أداء الجهاز ، لأن rngd سوف يوقظ الجهاز باستمرار ويسبب زيادة في تردد وحدة المعالجة المركزية ، مما يؤثر بالطبع سلبًا على استهلاك البطارية.

Odex

البرامج الثابتة للأوراق المالية على أجهزة Android دائمًا ما تكون odex. هذا يعني أنه إلى جانب الحزمة القياسية لتطبيقات Android بتنسيق APK ، الموجود في / system / app / و / system / priv-app / ، لها نفس أسماء الملفات بامتداد .odex. تحتوي ملفات odex على تطبيقات ثنائية التشفير التي مرت بالفعل من خلال المدقق والجهاز الظاهري للمحسن ، ثم تم تسجيلها في ملف منفصل باستخدام شيء مثل dexopt أداة.

لذلك ، تهدف ملفات odex إلى إلغاء تحميل الجهاز الظاهري وتقديم تسريع إطلاق التطبيق odexed - على الجانب السلبي ، تمنع ملفات ODEX التعديلات على البرامج الثابتة ، وتخلق مشاكل مع التحديثات ، ولهذا السبب يتم توزيع العديد من ROMs المخصصة مثل LineageOS بدون ODEX .

يتم إنشاء ملفات ODEX بعدة طرق ، مثل استخدام أداة Odexer - المشكلة تكمن في تأثيرها الوهمي البحت. عندما لا يجد نظام Android الحديث ملفات odex في دليل / system ، فسيقوم النظام بإنشائها بالفعل ووضعها في الدليل / system / dalvik-cache /. هذا بالضبط ما يحدث عندما ، على سبيل المثال ، تومض إصدارًا جديدًا من Android ويعطي الرسالة 'مشغول ، تحسين التطبيقات' لفترة من الوقت.

القرص Lowmemorykiller

يختلف تعدد المهام في Android عن أنظمة تشغيل الأجهزة المحمولة الأخرى بمعنى أنه يعتمد على نموذج كلاسيكي حيث تعمل التطبيقات بهدوء في الخلفية ، ولا توجد قيود على عدد تطبيقات الخلفية ( ما لم يتم تعيين أحدها في خيارات المطور ، ولكن يوصى بهذا بشكل عام) - علاوة على ذلك ، لا يتم إيقاف وظيفة الانتقال إلى تنفيذ الخلفية ، على الرغم من أن النظام يحتفظ بالحق في قتل تطبيقات الخلفية في حالات انخفاض الذاكرة ( انظر أين تحدثنا عن قاتل الذاكرة المنخفضة وقاتل الذاكرة في وقت سابق في هذا الدليل) .

للعودة إلى منخفض الذاكرة آلية ، يمكن أن يستمر Android في العمل بكمية محدودة من الذاكرة ونقص في قسم المبادلة. يمكن للمستخدم الاستمرار في تشغيل التطبيقات والتبديل بينها ، وسيقتل النظام بصمت تطبيقات الخلفية غير المستخدمة لمحاولة تحرير الذاكرة للمهام النشطة.

كان هذا مفيدًا للغاية لنظام Android في الأيام الأولى ، على الرغم من أنه لسبب ما أصبح شائعًا في شكل تطبيقات قاتلة المهام ، والتي تكون عمومًا أكثر ضررًا من الفائدة. إما أن تستيقظ تطبيقات قاتلة المهام على فترات زمنية محددة ، أو يتم تشغيلها من قبل المستخدم ، ويبدو أنها تحرر كميات كبيرة من ذاكرة الوصول العشوائي ، والتي يُنظر إليها على أنها إيجابية - فالمزيد من ذاكرة الوصول العشوائي المجانية تعني جهازًا أسرع ، أليس كذلك؟ ولكن هذا ليس هو الحال تمامًا مع Android.

في الواقع ، يمكن أن يكون وجود كمية كبيرة من ذاكرة الوصول العشوائي المجانية ضارًا في الواقع بأداء جهازك وعمر البطارية. عندما يتم تخزين التطبيقات في ذاكرة الوصول العشوائي لنظام Android ، يكون من السهل جدًا استدعائها وتشغيلها وما إلى ذلك. لا يحتاج نظام Android إلى تخصيص الكثير من الموارد للتبديل إلى التطبيق ، لأنه موجود بالفعل في الذاكرة.

لهذا السبب ، لم تعد أدوات قتل المهام شائعة كما كانت من قبل ، على الرغم من أن المبتدئين في Android لا يزالون يميلون إلى الاعتماد عليهم لسبب ما ( نقص المعلومات ، للأسف) . لسوء الحظ ، حل اتجاه جديد محل قاتلة المهام ، اتجاه منخفض الذاكرة ضبط الآلية. سيكون هذا على سبيل المثال MinFreeManager التطبيق ، والفكرة الرئيسية هي زيادة سعة ذاكرة الوصول العشوائي (RAM) قبل أن يبدأ النظام في قتل تطبيقات الخلفية.

على سبيل المثال ، تعمل ذاكرة الوصول العشوائي القياسية عند الحدود - 4 و 8 و 12 و 24 و 32 و 40 ميجابايت ، وعندما يتم ملء مساحة التخزين المجانية البالغة 40 ميجابايت ، يتم تحميل أحد التطبيقات المخزنة مؤقتًا في الذاكرة لكن لا تعمل سيتم إنهاء.

لذلك ، سيكون لدى Android دائمًا ما لا يقل عن 40 ميغابايت من الذاكرة المتوفرة ، وهو ما يكفي لاستيعاب تطبيق آخر من قبل منخفض الذاكرة تبدأ عملية التنظيف - مما يعني أن Android سيبذل قصارى جهده دائمًا لاستخدام أكبر قدر ممكن من ذاكرة الوصول العشوائي المتاحة دون التدخل في تجربة المستخدم.

للأسف ، ما بدأه بعض عشاق البيرة المنزلية أوصوا به هو رفع القيمة إلى 100 ميغابايت ، على سبيل المثال ، قبل بدء تشغيل LMK. والآن ، سيقوم المستخدم فعليًا تخسر ذاكرة الوصول العشوائي (100-40 = 60) ، لذلك بدلاً من استخدام هذه المساحة لتخزين التطبيقات الخلفية ، سيحتفظ النظام بهذا القدر من الذاكرة مجانا ، بدون أي غرض على الإطلاق.

LKM tuning يمكن أن تكون مفيدة للأجهزة الأقدم مع 512 RAM ، ولكن من يمتلكها بعد الآن؟ 2 غيغابايت هو 'نطاق الميزانية' الحديث ، حتى أجهزة ذاكرة الوصول العشوائي بسعة 4 غيغابايت تعتبر 'متوسطة المدى' هذه الأيام ، لذا فإن تعديلات LMK قديمة وغير مجدية حقًا.

تعديلات I / O

في الكثير من نصوص التحسين لنظام Android ، ستجد غالبًا تعديلات تتناول نظام الإدخال / الإخراج الفرعي. على سبيل المثال ، دعنا نلقي نظرة على ملف صاعقة! النص الذي يحتوي على هذه الأسطر:

صدى 0> $ i / queue / rotational ؛ صدى 1024> $ i / queue / nr_requests ؛

سيعطي السطر الأول تعليمات جدولة الإدخال / الإخراج في التعامل مع SSD ، والثاني يزيد الحجم الأقصى لقائمة الانتظار I / O من 128 إلى 1024 - لأن المتغير $ i يحتوي على مسار لشجرة أجهزة الكتلة في / sys ، ويعمل البرنامج النصي في حلقة.

بعد ذلك ، تجد سطرًا متعلقًا بجدول CFQ:

صدى 1> $ i / queue / iosched / back_seek_penalty ؛ صدى 1> $ i / queue / iosched / low_latency ؛ صدى 1> $ i / queue / iosched / slice_idle ؛

يتبع ذلك المزيد من الأسطر التي تنتمي إلى المخططين الآخرين ، ولكن في النهاية ، فإن الأمرين الأولين لا طائل من ورائه لأن:

نواة Linux الحديثة قادرة على فهم نوع وسيطة التخزين التي تعمل معها بشكل افتراضي.

قائمة انتظار طويلة للمدخلات والمخرجات ( مثل 1024) عديم الفائدة على جهاز Android الحديث ، في الواقع لا معنى له حتى على سطح المكتب - إنه موصى به حقًا فقط الخوادم الثقيلة . هاتفك ليس خادم Linux شديد التحمل.

بالنسبة لجهاز Android ، لا توجد فعليًا تطبيقات ذات أولوية في الإدخال والإخراج ولا يوجد برنامج تشغيل ميكانيكي ، لذا فإن أفضل مخطط هو قائمة الانتظار noop / FIFO ، لذا فإن هذا النوع من المجدول ' قرص' لا يقوم بأي شيء خاص أو ذو مغزى للنظام الفرعي I / O. في الواقع ، من الأفضل استبدال كل أوامر القائمة متعددة الشاشات هذه بدورة بسيطة:

لـ i in / sys / block / mmc * ؛ do echo noop> $ i / queue / Scheduler echo 0> $ i / queue / iostats تم

سيؤدي ذلك إلى تمكين جدولة noop لجميع محركات الأقراص من تراكم إحصائيات الإدخال / الإخراج ، والتي يجب أن يكون لها تأثير إيجابي على الأداء ، على الرغم من كونها صغيرة جدًا ويكاد يكون مهملاً تمامًا.

يعد تعديل الإدخال / الإخراج غير المجدي الذي يوجد غالبًا في البرامج النصية للأداء هو زيادة قيم القراءة المسبقة لبطاقات SD حتى 2 ميجابايت. آلية القراءة المسبقة هي لقراءة البيانات المبكرة من الوسائط ، قبل أن يطلب التطبيق الوصول إلى تلك البيانات. لذلك بشكل أساسي ، ستحاول النواة معرفة البيانات التي ستكون مطلوبة في المستقبل ، وتحميلها مسبقًا في ذاكرة الوصول العشوائي ، مما يقلل من وقت العودة. يبدو هذا رائعًا على الورق ، لكن خوارزمية القراءة المسبقة غالبًا ما تكون خطأ ، مما يؤدي إلى عمليات غير ضرورية تمامًا من المدخلات والمخرجات ، ناهيك عن استهلاك ذاكرة الوصول العشوائي المرتفع.

يوصى باستخدام قيم قراءة مسبقة عالية تتراوح بين 1 و 8 ميجابايت في مصفوفات RAID ، ولكن بالنسبة لأجهزة Android ، من الأفضل ترك القيمة الافتراضية 128 كيلوبايت.

يعدل نظام إدارة الذاكرة الظاهرية

أسلوب 'التحسين' الشائع الآخر هو ضبط النظام الفرعي لإدارة الذاكرة الظاهرية. يستهدف هذا عادةً متغيرين فقط من kernel ، vm.dirty_background_ratio و vm.dirty_ratio ، وهما لضبط حجم المخزن المؤقت لتخزين البيانات 'القذرة'. قذر عادةً ما تكون البيانات عبارة عن بيانات تمت كتابتها على القرص ، ولكن لا يزال هناك المزيد في الذاكرة وتنتظر كتابتها على القرص.

ستكون قيم القرص النموذجية في كل من توزيعات Linux و Androis للنظام الفرعي لإدارة VM كما يلي:

vm.dirty_background_ratio = 10 vm.dirty_ratio = 20

لذا فإن ما يحاول القيام به هو أنه عندما يكون المخزن المؤقت للبيانات المتسخ 10٪ من إجمالي حجم ذاكرة الوصول العشوائي ، فإنه يستيقظ pdflush تدفق ويبدأ في كتابة البيانات على القرص - إذا كانت عملية تسجيل البيانات على القرص ستكون كثير الكثافه ، سيستمر نمو المخزن المؤقت ، وعندما يصل إلى 20٪ من ذاكرة الوصول العشوائي المتاحة ، سيتحول النظام إلى عملية الكتابة اللاحقة في الوضع المتزامن - بدون تخزين مؤقت مسبق. هذا يعني أن عمل الكتابة إلى تطبيق القرص سيكون محظور ، حتى تتم كتابة البيانات على القرص (AKA 'lag').

ما يجب أن تفهمه هو أنه حتى لو كان حجم المخزن المؤقت لا تصل إلى 10٪ ، سيقوم النظام تلقائيًا بتشغيل pdflush بعد 30 ثانية. مزيج 10/20 معقول جدًا ، على سبيل المثال على جهاز به ذاكرة وصول عشوائي (RAM) سعة 1 جيجابايت ، فإن هذا سيعادل 100/200 ميجابايت من ذاكرة الوصول العشوائي ، وهو أكثر من كافٍ من حيث سجلات الاندفاع حيث تكون السرعة غالبًا أقل من سجل السرعة في نظام NAND -الذاكرة ، أو بطاقة SD ، مثل عند تثبيت التطبيقات أو نسخ الملفات من جهاز كمبيوتر.

لسبب ما ، يحاول كتّاب النصوص دفع هذه القيمة إلى أعلى ، إلى معدلات سخيفة. على سبيل المثال يمكننا أن نجد في Xplix معدل مرتفع يصل إلى 50/90.

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

على جهاز به ذاكرة تبلغ 1 غيغابايت ، فإن هذا يحدد حدًا لمخزن مؤقت متسخ إلى 500/900 ميجابايت ، وهو أمر غير مفيد تمامًا لجهاز Android ، لأنه سيعمل فقط في ظل تسجيل مستمر على القرص - شيء يحدث فقط على خادم لينكس ثقيل.

صاعقة! يستخدم البرنامج النصي قيمة أكثر منطقية ، ولكن بشكل عام ، لا يزال بلا معنى إلى حد ما:

إذا ['$ mem' -lt 524288] ؛ ثم 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 ؛ فاي ؛

يتم تشغيل الأمرين الأولين على الهواتف الذكية ذات ذاكرة الوصول العشوائي 512 ميجا بايت ، والثاني - بسعة 1 جيجا بايت ، والآخرين - بأكثر من 1 جيجا بايت. ولكن في الواقع ، هناك سبب واحد فقط لتغيير الإعدادات الافتراضية - جهاز به ذاكرة داخلية أو بطاقة ذاكرة بطيئة للغاية. في هذه الحالة ، من المعقول نشر قيم المتغيرات ، أي لعمل شيء مثل هذا:

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

بعد ذلك ، عندما يكتب نظام الطفرة العمليات ، دون الحاجة إلى تسجيل البيانات على القرص ، لن يتحول حتى الأخير إلى الوضع المتزامن ، مما سيسمح للتطبيقات بتقليل التأخير عند التسجيل.

تعديلات إضافية عديمة الفائدة وضبطات الأداء

هناك الكثير من 'التحسينات' التي لا تفعل شيئًا حقًا. معظمهم ببساطة ليس له أي تأثير على الإطلاق ، بينما قد يتحسن الآخرون بعض جانب من الأداء ، مع تدهور الجهاز بطرق أخرى ( عادة ما يتلخص في الأداء مقابل استنزاف البطارية) .

فيما يلي بعض التحسينات الإضافية الشائعة التي قد تكون مفيدة أو لا تكون ، اعتمادًا على نظام وجهاز Android.

• التسارع - التسارع الصغير لتحسين الأداء والتقليل من الجهد - يوفر القليل من البطارية.
• تحسين قواعد البيانات - هذا من الناحية النظرية ينبغي يعطي تحسنا في أداء الجهاز ، ولكن هذا مشكوك فيه.
• Zipalign - من المفارقات أنه على الرغم من ميزة Android SDK المضمنة في محاذاة المحتوى داخل ملف APK في المتجر ، يمكنك العثور على الكثير من البرامج لا تنتقل عبر zipalign.
• قم بتعطيل خدمات النظام غير الضرورية ، وإزالة النظام غير المستخدم وتطبيقات الجهات الخارجية التي نادرًا ما تستخدم. في الأساس ، إلغاء تثبيت bloatware.
• نواة مخصصة مع تحسينات لجهاز معين (مرة أخرى ، ليست كل النوى جيدة على قدم المساواة).
• وصفت بالفعل I / O جدولة noop.
• خوارزمية التشبع TCP Westwood - تُستخدم بكفاءة أكبر في Android Cubic الافتراضي للشبكات اللاسلكية ، والمتوفر في نواة مخصصة.

إعدادات عديمة الفائدة build.prop

أجرى LaraCraft304 من منتدى مطوري XDA دراسة ووجدت أن عددًا مثيرًا للإعجاب من إعدادات /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 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.Hutdown.