มิธยาความเชื่อเรื่องการเพิ่มประสิทธิภาพ Android ที่ถูกยุติแล้ว

มีคู่มือการสอนมากมายที่ทุ่มเทให้กับการเพิ่มประสิทธิภาพ Android และเคล็ดลับการเพิ่มประสิทธิภาพโดยรวม บางอย่างถูกต้อง แต่บางอย่างอิงเพียงทฤษฎี หรือวิธีการดำเนินงานที่ล้าสมัยในระบบ Android หรือเพียงแค่บ่นไร้สาระ รวมถึงคำแนะนำเกี่ยวกับ swap ค่าที่เพิ่มใน build.prop และการเปลี่ยนแปลงตัวแปรใน Linux kernel

แม้แต่มี "สคริปต์เพิ่มประสิทธิภาพ" มากมาย ไฟล์ .zip แฟลชได้แบบ all-in-one ที่สัญญาว่าจะเพิ่มประสิทธิภาพ เวลาแบตเตอรี่ และสิ่งอื่นๆ อย่างมีนัยสำคัญ บางส่วน ของการปรับแต่งอาจทำงานจริง แต่ส่วนใหญ่เป็นแค่เอฟเฟกต์ปลาสีโบ (placebo effect) หรือแย่กว่านั้น คือมีผลกระทบเชิงลบต่ออุปกรณ์

ไม่ได้หมายความว่าผู้คนปล่อยสคริปต์ที่เป็นอันตรายโดยเจตนา - มีแอปที่หลอกลวงแบบ เสียเงิน บน Play Store แน่นอน แต่สคริปต์เพิ่มประสิทธิภาพที่เผยแพร่บนฟอรัม Android โดยทั่วไปมีเจตนาดี เพียงแค่ผู้พัฒนาอาจได้รับข้อมูลผิด หรือเพียงแค่ทดลองกับการปรับแต่งต่างๆ น่าเสียดายที่มักมีเอฟเฟกต์สโนว์บอล (snowball effect) เกิดขึ้น โดยเฉพาะใน "สคริปต์เพิ่มประสิทธิภาพ all-in-one" ชุดเล็กน้อยของการปรับแต่งอาจทำ บางอย่าง ได้ ในขณะที่ชุดอื่นในสคริปต์อาจไม่ทำอะไรเลย - แต่สคริปต์เหล่านี้ถูกส่งต่อกันเป็น "กระสุนเวท" โดยไม่มีการตรวจสอบจริงว่าอะไรทำงาน อะไรไม่ทำงาน

ดังนั้น สคริปต์เพิ่มประสิทธิภาพ all-in-one ส่วนใหญ่ใช้วิธีการเดียวกัน บางอย่างล้าสมัยหรือเป็นอันตรายในระยะยาว สรุปคือ สคริปต์ "all-in-one" ส่วนใหญ่ไม่เป็นไร้ค่าที่รวมการปรับแต่งที่แนะนำไว้ โดยไม่มีแนวคิดชัดเจนว่าการเพิ่มประสิทธิภาพเหล่านี้ "ทำงานอย่างไร" - ผู้ใช้แฟลชสคริปต์ แล้วอ้างว่าประสิทธิภาพเร็วขึ้น (เมื่อจริงๆ แล้ว อาจเป็นเพราะการรีบูทอุปกรณ์อย่างง่ายที่ทำให้ประสิทธิภาพเพิ่มขึ้น เพราะทุกอย่างใน RAM ของอุปกรณ์ถูกล้างออกไป)

ในบทความพิเศษของ Appuals นี้ เราจะเน้นย้ำคำแนะนำที่พบบ่อยที่สุดสำหรับการ "เพิ่มประสิทธิภาพ" Android และว่ามันเป็นเพียงตำนานหรือการปรับแต่งที่ถูกต้องสำหรับประสิทธิภาพอุปกรณ์

Swap

อยู่ที่อันดับหนึ่งของรายการตำนานคือ Android swap - ซึ่งดูบ้าคลั่งในแง่ของการถูกคิดว่าเป็นการเพิ่มประสิทธิภาพ Android วัตถุประสงค์หลักของ swap คือการสร้างและเชื่อมต่อไฟล์เพจ (paging file) ซึ่งจะปลดปล่อยพื้นที่จัดเก็บในหน่วยความจำ 聽起來合理 บนกระดาษ แต่จริงๆ แล้วใช้ได้กับ เซิร์ฟเวอร์ ซึ่งมีการโต้ตอบเกือบเป็นศูนย์

เมื่อคุณใช้ swap ของโทรศัพท์ Android อย่างสม่ำเสมอ จะนำไปสู่การล่าช้ารุนแรงที่มาจากการที่สิ่งต่างๆ หลุดพ้น cache ทิ้งไป ตัวอย่างเช่น หากแอปพลิเคชันพยายามแสดงกราฟิก ซึ่งจัดเก็บอยู่ใน swap ซึ่งต้องโหลดดิสก์ใหม่หลังจากปลดปล่อยพื้นที่โดยการวางข้อมูล swap กับแอปพลิเคชันอื่น มันจริงๆ แล้วเป็นเรื่องยุ่งเหยิง

บางผู้ชื่นชอบการเพิ่มประสิทธิภาพอาจพูดว่า swap ไม่มีปัญหา แต่ไม่ใช่ swap ที่ทำให้ประสิทธิภาพดีขึ้น - แต่เป็นกลไก Android ที่สร้างไว้ lowmemorykiller ซึ่งจะฆ่า process ที่ฟูและมีความสำคัญสูงที่ไม่ได้ใช้งานอยู่ LMK ถูกออกแบบมาเฉพาะสำหรับการจัดการสภาวะหน่วยความจำต่ำ ถูกเรียกใช้จาก process kswapd และโดยทั่วไปจะฆ่า user space processes นี่ต่างจาก OOMkiller (out-of-memory killer) แต่เป็นหัวข้ออื่น

重点是 อุปกรณ์ที่มี RAM 1GB ไม่มีทางเข้าถึงข้อมูลประสิทธิภาพที่จำเป็นใน swap ดังนั้น swap จึงไม่จำเป็นใน Android การนำไปใช้งานเพียงแค่เต็มไปด้วย lag และนำไปสู่ การเสื่อมสภาพ ของประสิทธิภาพ แทนที่จะเพิ่มประสิทธิภาพ

zRAM – ล้าสมัยและไม่มีประสิทธิภาพอีกต่อไป

zRAM เป็นวิธีการเพิ่มประสิทธิภาพอุปกรณ์ที่พิสูจน์แล้วและมีประสิทธิภาพ สำหรับ อุปกรณ์เก่า - คิดถึงอุปกรณ์ที่ใช้ KitKat ที่ทำงานบน RAM ประมาณ 512 MB เท่านั้น ข้อเท็จจริงที่บางคนยังรวม zRAM tweaks ในสคริปต์เพิ่มประสิทธิภาพ หรือแนะนำ zRAM เป็นการปรับแต่งสมัยใหม่ เป็นตัวอย่างของผู้คนที่โดยทั่วไปไม่ได้ปฏิบัติตามโปรโตคอลการดำเนินงานล่าสุด

zRAM ถูกออกแบบมาสำหรับ SoC หลายแกนระดับเริ่มต้น-งบประมาณต่ำ เช่น อุปกรณ์ที่ใช้ชิป MTK และ RAM 512 MB โทรศัพท์จีนราคาถ่ายมาก zRAM ทำคือ แยก kernel ผ่านการเข้ารหัสสตรีม (encryption stream)

เมื่อใช้ zRAM บนอุปกรณ์เก่าที่มี single core แม้ zRAM จะถูกแนะนำบนอุปกรณ์เหล่านี้ ก็จะมี lag จำนวนมากเกิดขึ้น นี่เกิดขึ้นกับเทคโนโลยี KSM (Kernel Same Page Merging) ซึ่งรวมหน่วยความจำที่เหมือนกันเพื่อปลดปล่อยพื้นที่ Google แนะนำจริงๆ แต่ก่อให้เกิด lag มากขึ้นบนอุปกรณ์เก่า เนื่องจาก core threads ที่ทำงานตลอดเวลากำลังทำงานต่อเนื่องจากหน่วยความจำเพื่อค้นหาหน้าที่ซ้ำกัน โดยพื้นฐานแล้ว การพยายามรันการปรับแต่งเพิ่มประสิทธิภาพทำให้อุปกรณ์ช้าลงอีก ดูเหมือนจะขัดแย้ง

Seeder – ล้าสมัยตั้งแต่ Android 3.0

หนึ่งในเคล็ดลับการเพิ่มประสิทธิภาพที่ถاجโต้กันมากที่สุดในหมู่นักพัฒนา Android คือ seeder และเราแน่ใจว่ามีใครพยายามพิสูจน์ว่าเราผิดได้ - แต่ก่อนอื่นเราต้องตรวจสอบประวัติของ seeder

ใช่ มีรายงานจำนวนมากที่ประกาศว่าประสิทธิภาพ Android ดีขึ้นหลังติดตั้งบน อุปกรณ์ Android เก่ามาก แต่ผู้คนด้วยเหตุผลบางอย่างเชื่อว่าหมายความว่ามันยังเป็นการเพิ่มประสิทธิภาพที่ใช้ได้สำหรับ อุปกรณ์ Android สมัยใหม่ ซึ่งเป็นเรื่องบ้าคลั่งอย่างสมบูรณ์ ข้อเท็จจริงที่ Seeder ยังคงดูแลและเสนอเป็นเครื่องมือ "สมัยใหม่" ลด lag เป็นตัวอย่างของข้อมูลผิด - แม้จะไม่ใช่ความผิดของนักพัฒนา Seeder เนื่องจากหน้า Play Store ของพวกเขาบอกว่า Seeder มีประสิทธิภาพน้อยลงหลัง Android 4.0+ แต่ด้วยเหตุผลบางอย่าง Seeder ยังคงโผล่ในการอภิปรายเพิ่มประสิทธิภาพสำหรับระบบ Android สมัยใหม่

Seeder ทำอะไรสำหรับ Android 3.0 คือแก้ไขบั๊กที่ Android runtime จะใช้ไฟล์ /dev/random/ อย่างต่อเนื่องเพื่อรับ entropy ไบฟ์เฟอร์ /dev/random/ จะไม่เสถียร และระบบจะถูกบล็อกจนกว่าจะเติมข้อมูลที่ต้องตามจำนวนที่กำหนด - คิดถึงสิ่งเล็กๆ เช่น เซ็นเซอร์และปุ่มต่างๆ บนอุปกรณ์ Android

ผู้เขียน Seeder นำ Linux-daemon rngd มา compile สำหรับ Android inastroil เพื่อให้ดึงข้อมูลสุ่มจาก /dev/urandom ที่เร็วกว่าและคาดเดาได้ง่ายกว่า และรวมเข้ากับ dev/random/ ทุกวินาที โดยไม่ให้ /dev/random/ หมดลง ผลลัพธ์คือระบบ Android ที่ไม่ประสบปัญหาขาด entropy และทำงานลื่นไหลกว่า

Google แก้ไขบั๊กนี้หลัง Android 3.0 แล้ว แต่ด้วยเหตุผลบางอย่าง Seeder ยังคงโผล่ในรายการ "การปรับแต่งที่แนะนำ" สำหรับการเพิ่มประสิทธิภาพประสิทธิภาพ Android อีกด้วย ยิ่งไปกว่านั้น แอป Seeder มี аналогๆ เล็กน้อย เช่น sEFix ที่รวมฟังก์ชันของ Seeder ไม่ว่าจะใช้ rngd เดียวกัน หรือ haveged ทางเลือก หรือแม้แต่ symlink ระหว่าง /dev/urandom และ /dev/random นี่เป็นสิ่งที่ไม่มีประโยชน์เลยสำหรับระบบ Android สมัยใหม่

เหตุผลที่มันไม่มีประโยชน์คือ เพราะ Android เวอร์ชันใหม่ใช้ /dev/random/ ในสามส่วนประกอบหลัก - libcrypto สำหรับการเข้ารหัสการเชื่อมต่อ SSL การสร้าง SSH keys ฯลฯ WPA_supplication/hostapd ซึ่งสร้าง WEP/WPA keys และสุดท้ายคือไลบรารีเล็กน้อยสำหรับการสร้าง ID ในการสร้างระบบไฟล์ EXT2/EXT3/EXT4

ดังนั้น เมื่อ Seeder หรือการปรับแต่งจาก Seeder ถูกรวมในสคริปต์เพิ่มประสิทธิภาพ Android สมัยใหม่ สิ่งที่เกิดขึ้นคือ การเสื่อมสภาพ ของประสิทธิภาพอุปกรณ์ เนื่องจาก rngd จะตื่นอุปกรณ์อย่างต่อเนื่องและทำให้ความถี่ CPU เพิ่มขึ้น ซึ่งแน่นอนส่งผลลบต่อการใช้พลังงานแบตเตอรี่

Odex

Firmware สต็อกบนอุปกรณ์ Android เกือบทุกเครื่องเป็น odex หมายความว่าพร้อมกับแพ็กเกจมาตรฐานสำหรับแอป Android ในรูปแบบ APK ที่พบใน /system/app/ และ /system/priv-app/ มีชื่อไฟล์เดียวกันแต่อยู่ในนามสกุล .odex ไฟล์ odex มี bytecode แอปพลิเคชันที่เพิ่มประสิทธิภาพแล้ว ซึ่งผ่าน validator และ optimizer virtual machine แล้ว บันทึกในไฟล์แยกโดยใช้ tool อย่าง dexopt

ดังนั้น ไฟล์ odex มีไว้เพื่อออฟโหลด virtual machine และเสนอการเปิดแอปที่ odexed เร็วขึ้น - ด้านลบคือ ไฟล์ ODEX ป้องกันการแก้ไข firmware และสร้างปัญหากับการอัปเดต ดังนั้น ROM แบบกำหนดเองอย่าง LineageOS จึงแจกจ่าย โดยไม่มี ODEX

การสร้างไฟล์ ODEX ทำได้หลายวิธี เช่น ใช้ Odexer Tool - ปัญหาคือมันเป็นเพียง placebo effect เฉยๆ เมื่อระบบ Android สมัยใหม่ไม่พบไฟล์ odex ในไดเรกทอรี /system ระบบจะสร้างขึ้นมาเองและวางไว้ในไดเรกทอรี /system/dalvik-cache/ นี่คือสิ่งที่เกิดขึ้นจริงเมื่อ คุณแฟลช Android เวอร์ชันใหม่ และมันแสดงข้อความ "Busy, Optimizing Applications" เป็นระยะหนึ่ง

Lowmemorykiller tweaks

การทำงานหลายอย่างพร้อมกันใน Android ต่างจากระบบปฏิบัติการมือถืออื่นๆ ในแง่ที่มันอิงตามแบบจำลองคลาสสิกที่แอปพลิเคชันทำงานเงียบๆ ในพื้นหลัง และไม่มีข้อจำกัดจำนวนแอพพื้นหลัง (เว้นแต่จะตั้งค่าใน Developer Options แต่โดยทั่วไปไม่แนะนำ) - ยิ่งไปกว่านั้น ฟังก์ชันการเปลี่ยนไปสู่การทำงานในพื้นหลังไม่หยุด แม้ระบบจะสงวนสิทธิ์ในการฆ่าแอพพื้นหลังในสถานการณ์หน่วยความจำต่ำ (ดูที่เราพูดถึง lowmemorykiller และ out-of-memory killer ก่อนหน้านี้ในคู่มือนี้)

กลับไปที่กลไก lowmemorykiller Android สามารถทำงานต่อได้ด้วยหน่วยความจำจำกัดและขาด swap-partition ผู้ใช้สามารถเปิดแอปพลิเคชันและสลับระหว่างได้ และระบบจะฆ่าแอพพื้นหลังที่ไม่ได้ใช้งานเงียบๆ เพื่อพยายามปลดปล่อยหน่วยความจำสำหรับงานที่ใช้งานอยู่

สิ่งนี้มีประโยชน์มากสำหรับ Android ในช่วงแรก แม้ด้วยเหตุผลบางอย่างมันกลายเป็นที่นิยมในรูปของแอป task-killer ซึ่งโดยทั่วไปเป็นอันตรายกว่าประโยชน์ Task-killer apps ทำให้ตื่นในช่วงเวลาที่กำหนด หรือรันโดยผู้ใช้ และปรากฏว่าปลดปล่อย RAM จำนวนมาก ซึ่งมองว่าเป็นข้อดี - RAM ว่างมากหมายถึงอุปกรณ์เร็วขึ้น ใช่ไหม? แต่ไม่ได้เป็นเช่นนั้นกับ Android

จริงๆ แล้ว การมี RAM ว่างมากจริงๆ อาจเป็นอันตรายต่อประสิทธิภาพและอายุการใช้งานแบตเตอรี่ของอุปกรณ์ เมื่อแอปจัดเก็บอยู่ใน RAM ของ Android มันง่ายกว่าที่จะเรียกใช้ เปิดใช้ ฯลฯ ระบบ Android ไม่ต้องใช้ทรัพยากรมากในการสลับไปยังแอป เพราะมันอยู่ในหน่วยความจำแล้ว

เพราะฉะนั้น task-killers ไม่ได้นิยมเท่าเดิม แม้มือใหม่ Android ยังพึ่งพามันอยู่ดี เพราะขาดข้อมูล น่าเสียดาย แนวโน้มใหม่ได้แทนที่ task-killers คือแนวโน้มของการปรับแต่งกลไก lowmemorykiller เช่น แอป MinFreeManager แนวคิดหลักคือเพิ่ม RAM overhead ก่อนที่ระบบจะเริ่มฆ่าแอพพื้นหลัง

เช่น RAM มาตรฐานทำงานที่ขอบเขต - 4, 8, 12, 24, 32, และ 40 MB และเมื่อพื้นที่จัดเก็บว่าง 40 MB ถูกเติม หนึ่งในแอพ cached ที่โหลดในหน่วยความจำ แต่ไม่ได้รัน จะถูกยกเลิก

ดังนั้น Android จะมีหน่วยความจำว่างอย่างน้อย 40 MB ซึ่งพอสำหรับแอปอีกหนึ่งตัวก่อนที่ lowmemorykiller จะเริ่มกระบวนการทำความสะอาด - หมายความว่า Android จะพยายามใช้ RAM สูงสุดที่มีอยู่โดยไม่รบกวนประสบการณ์ผู้ใช้

น่าเสียดาย ที่บางผู้ชื่นชอบบ้านแนะนำให้เพิ่มค่าเป็น ตัวอย่าง 100 MB ก่อนที่ LMK จะทำงาน ตอนนี้ผู้ใช้จะ สูญเสีย RAM (100 - 40 = 60) ดังนั้นแทนที่จะใช้พื้นที่นี้จัดเก็บแอพแบ็กเอนด์ ระบบจะเก็บปริมาณหน่วยความจำนี้ ว่าง ไว้โดยไม่มีวัตถุประสงค์ใดๆ

LKM tuning อาจมีประโยชน์ สำหรับอุปกรณ์เก่ามากที่มี RAM 512 แต่ใครยังครอบครองอยู่? 2GB เป็น "งบประมาณ" สมัยใหม่ แม้ 4GB RAM ก็ถูกมองว่าเป็น "กลาง" แล้ว LMK tweaks จึงล้าสมัยและไร้ประโยชน์จริงๆ

I/O tweaks

ในสคริปต์เพิ่มประสิทธิภาพ Android หลายตัว คุณจะพบการปรับแต่งที่เกี่ยวกับระบบย่อย I/O เช่น ให้ดูที่สคริปต์ ThunderBolt! ซึ่งมีบรรทัดเหล่านี้:

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

บรรทัดแรกจะให้คำสั่ง I/O scheduler ในการจัดการกับ SSD และบรรทัดที่สองเพิ่มขนาดสูงสุดของคิว I/O จาก 128 เป็น 1024 - เพราะตัวแปร $i มี path ไปยังต้นไม้ของ block devices ใน /sys และสคริปต์รันในลูป

ตามด้วยบรรทัดที่เกี่ยวข้องกับ CFQ scheduler:

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

ตามด้วยบรรทัดเพิ่มเติมที่เป็นของ planner อื่นๆ แต่ในที่สุด คำสั่งสองคำแรกเป็นโจรเพราะ:

Linux kernel สมัยใหม่สามารถเข้าใจได้ด้วยตัวมันเองว่า النوعของสื่อจัดเก็บที่มันทำงานอยู่คืออะไร โดยค่าเริ่มต้น

คิว input-output ยาว (เช่น 1024) ไม่มีประโยชน์บนอุปกรณ์ Android สมัยใหม่ จริงๆ แล้วมันไร้ความหมายแม้บนเดสก์ท็อป - แนะนำจริงๆ เฉพาะบน เซิร์ฟเวอร์หนัก โทรศัพท์ของคุณไม่ใช่เซิร์ฟเวอร์ Linux หนัก

สำหรับอุปกรณ์ Android ไม่มีแอปพลิเคชันที่ได้รับการจัดลำดับความสำคัญใน input-output และไม่มี mechanical driver ดังนั้น planner ที่ดีที่สุดคือ noop / FIFO-queue ดังนั้นการ "ปรับแต่ง" scheduler แบบนี้ไม่ได้ทำอะไรพิเศษหรือมีความหมายต่อระบบย่อย I/O จริงๆ ทั้งหมดคำสั่ง multi-screen list ดีกว่าแทนที่ด้วยลูปง่ายๆ:

for i in /sys/block/mmc*; do echo noop > $i/queue/scheduler echo 0 > $i/queue/iostats done

นี่จะเปิดใช้งาน noop scheduler สำหรับทุกไดรฟ์จากการสะสมสถิติ I/O ซึ่งควรมีผลกระทบเชิงบวกต่อประสิทธิภาพ แม้จะเล็กมากและเกือบสามารถมองข้ามได้

I/O tweak ไร้ประโยชน์อีกอย่างที่พบบ่อยในสคริปต์ประสิทธิภาพคือค่า read-ahead ที่เพิ่มขึ้นสำหรับ SD card ถึง 2MB กลไก read-ahead เป็นการอ่านข้อมูลล่วงหน้าจากสื่อ ก่อนที่แอปจะขอเข้าถึงข้อมูลนั้น ดังนั้น kernel จะพยายามคาดเดาว่าข้อมูลอะไรจะต้องการในอนาคต และโหลดล่วงหน้าเข้า RAM ซึ่งควรลดเวลาตอบสนอง 聽起來ดีบนกระดาษ แต่อัลกอริทึม read-ahead มัก ผิด นำไปสู่การดำเนินการ input-output ที่ไม่จำเป็นทั้งสิ้น รวมถึงการใช้ RAM สูง

ค่า read-ahead สูงระหว่าง 1-8 MB แนะนำสำหรับ RAID-arrays แต่สำหรับอุปกรณ์ Android ควรคงค่าเริ่มต้น 128 KB ไว้

การปรับแต่งระบบจัดการหน่วยความจำเสมือน (Virtual Memory Management)

เทคนิค "เพิ่มประสิทธิภาพ" อีกอย่างที่พบบ่อยคือการปรับแต่งระบบย่อยจัดการหน่วยความจำเสมือน มักจะเป้าหมายเพียงสองตัวแปร kernel คือ vm.dirty_background_ratio และ vm.dirty_ratio ซึ่งใช้สำหรับปรับขนาดบัฟเฟอร์สำหรับจัดเก็บข้อมูล "dirty" Dirty data คือข้อมูลที่เขียนลงดิสก์แล้ว แต่ยังมีอีกบ้างในหน่วยความจำรอเขียนลงดิสก์

ค่า tweak ทั่วไปในทั้ง Linux distros และ Android สำหรับระบบย่อย VM management จะเป็นแบบ:

vm.dirty_background_ratio = 10 vm.dirty_ratio = 20

สิ่งนี้พยายามทำให้เมื่อ dirty data buffer เป็น 10% ของ RAM ทั้งหมด จะปลุก pdflush flow และเริ่มเขียนข้อมูลลงดิสก์ - หากการบันทึกข้อมูลบนดิสก์จะ เข้มข้นเกินไป บัฟเฟอร์จะเติบโตต่อไป และเมื่อถึง 20% ของ RAM ที่มี ระบบจะสลับไปโหมดเขียนแบบ synchronous - โดยไม่มี pre-buffer หมายความว่างานเขียนดิสก์ของแอปพลิเคชันจะ ถูกบล็อก จนกว่าข้อมูลจะเขียนลงดิสก์เสร็จ (AKA 'lag')

คุณควรเข้าใจว่า แม้ขนาดบัฟเฟอร์ ไม่ถึง 10% ระบบจะปลุก pdflush อัตโนมัติหลัง 30 วินาที การรวม 10/20 ค่อนข้างสมเหตุสมผล เช่นบนอุปกรณ์ 1GB RAM จะเท่ากับ 100/200MB RAM ซึ่งมากพอสำหรับการบันทึกแบบ burst ที่ความเร็วมักต่ำกว่าความเร็วบันทึกในหน่วยความจำ NAND ของระบบ หรือ SD-card เช่นตอนติดตั้งแอปหรือคัดลอกไฟล์จากคอมพิวเตอร์

ด้วยเหตุผลบางอย่าง นักเขียนสคริปต์พยายามผลักค่านี้สูงขึ้นไปถึงอัตราที่บ้าคลั่ง เช่นในสคริปต์ Xplix เพิ่มประสิทธิภาพ พบอัตราสูงถึง 50/90

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

บนอุปกรณ์ 1 GB หน่วยความจำ นี่ตั้งค่าขีดจำกัด dirty buffer ไว้ที่ 500/900 MB ซึ่งไร้ประโยชน์สำหรับอุปกรณ์ Android เพราะจะทำงานได้เฉพาะภายใต้ การบันทึกดิสก์ต่อเนื่อง - สิ่งที่เกิดขึ้นเฉพาะบนเซิร์ฟเวอร์ Linux หนัก

ThunderBolt! Script ใช้ค่าที่สมเหตุสมผลกว่า แต่โดยรวมยังไร้ความหมาย:

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;

สองคำสั่งแรกรันบนสมาร์ทโฟนที่มี RAM 512 MB คำสั่งที่สอง - กับ 1 GB และอื่นๆ - กับมากกว่า 1 GB แต่จริงๆ มีเพียงเหตุผลเดียวที่จะเปลี่ยนการตั้งค่าเริ่มต้น - อุปกรณ์ที่มีหน่วยความจำภายในหรือการ์ดหน่วยความจำช้ามาก ในกรณีนี้ จึงสมเหตุสมผลที่จะกระจายค่าตัวแปร คือทำแบบนี้:

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

แล้วเมื่อระบบมีการเขียนแบบ surge operations โดยไม่ต้องบันทึกข้อมูลลงดิสก์ จนถึงครั้งสุดท้ายจะไม่สลับไปโหมด synchronous ซึ่งจะช่วยให้แอปพลิเคชันลด lag ขณะบันทึก

การปรับแต่งและการปรับประสิทธิภาพที่ไร้ประโยชน์เพิ่มเติม

มี "การเพิ่มประสิทธิภาพ" อีกมากมายที่จริงๆ ไม่ทำอะไร ส่วนใหญ่ไม่มีผลกระทบเลย ในขณะที่บางอย่างอาจปรับปรุง บางด้าน ของประสิทธิภาพ แต่ทำให้อุปกรณ์เสื่อมสภาพในดานอื่น (โดยปกติแล้วจะ归结为ประสิทธิภาพ vs การระบายแบตเตอรี่)

นี่คือการเพิ่มประสิทธิภาพยอดนิยมเพิ่มเติมที่อาจหรืออาจไม่มีประโยชน์ ขึ้นอยู่กับระบบ Android และอุปกรณ์

• Acceleration - การเร่งความเร็วเล็กน้อยเพื่อเพิ่มประสิทธิภาพ และ undervolting - ประหยัดแบตเตอรี่เล็กน้อย
• Database Optimization - ทฤษฎีแล้วควร ให้ การปรับปรุงประสิทธิภาพอุปกรณ์ แต่ข้อกล่าวอ้างนี้น่าสงสัย
• Zipalign - น่าสงสัยที่แม้จะมีฟีเจอร์ built-in ของ Android SDK สำหรับการจัดเรียงเนื้อหาภายใน APK-file ในสโตร์ คุณสามารถพบซอฟต์แวร์มากมายที่ไม่ได้ส่งผ่าน zipalign
• ปิดบริการระบบที่ไม่จำเป็น ลบแอปพลิเคชันระบบและแอปพลิเคชันของบุคคลที่สามที่ใช้ไม่บ่อย โดยพื้นฐานคือการถอนการติดตั้ง bloatware
• Custom kernel ที่เพิ่มประสิทธิภาพสำหรับอุปกรณ์เฉพาะ (อีกครั้ง ไม่ใช่ kernel ทุกตัวที่ดีเท่ากัน)
• I/O scheduler noop ที่อธิบายไว้แล้ว
• อัลกอริทึม TCP Westwood - ใช้งานได้มีประสิทธิภาพกว่า Cubic เริ่มต้นของ Android สำหรับเครือข่ายไร้สาย มีใน custom kernels

การตั้งค่า build.prop ที่ไร้ประโยชน์

LaraCraft304 จากฟอรัม XDA Developers ได้ทำการศึกษาและพบว่าจำนวนมากของการตั้งค่า /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