ตำนานการเพิ่มประสิทธิภาพ Android ที่พบบ่อยที่สุดถูกหักล้าง

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

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

สลับ

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

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

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

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

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

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

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

เมื่อใช้ zRAM บนอุปกรณ์รุ่นเก่าที่มีไฟล์ แกนเดียว แม้ว่าจะแนะนำให้ใช้ zRAM ในอุปกรณ์ดังกล่าว แต่ความล่าช้าในปริมาณมากก็มักจะเกิดขึ้น สิ่งนี้เกิดขึ้นกับเทคโนโลยี KSM ( เคอร์เนลการรวมเพจเดียวกัน) ซึ่งรวมเพจหน่วยความจำที่เหมือนกันในการเสนอราคาเพื่อเพิ่มพื้นที่ว่าง อันที่จริงแนะนำโดย Google แต่นำไปสู่ความล่าช้ามากขึ้นในอุปกรณ์รุ่นเก่าเนื่องจากแกนหลักที่ใช้งานอยู่ตลอดเวลาจะทำงานอย่างต่อเนื่องจากหน่วยความจำเพื่อค้นหาหน้าที่ซ้ำกัน โดยทั่วไปแล้วการพยายามเรียกใช้การปรับแต่งการเพิ่มประสิทธิภาพจะทำให้อุปกรณ์ทำงานช้าลงมากยิ่งขึ้น

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

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

แอป Seeder สำหรับ Android

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

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

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

Google ได้ทำลายข้อบกพร่องนี้หลังจาก Android 3.0 แต่ด้วยเหตุผลบางประการ Seeder ยังคงปรากฏขึ้น “ การปรับแต่งที่แนะนำ” รายการสำหรับการเพิ่มประสิทธิภาพการทำงานของ Android นอกจากนี้แอป Seeder ยังมีแอนะล็อกบางตัวเช่น sEFix ซึ่งรวมถึงฟังก์ชันการทำงานของ Seeder ไม่ว่าจะใช้แบบเดียวกัน rngd หรือทางเลือกอื่น แฮ็ก หรือแม้แต่ symlink ระหว่าง / dev / urandom และ / dev / random สิ่งนี้ไม่มีจุดหมายอย่างแน่นอนสำหรับระบบ Android สมัยใหม่

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

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

Odex

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

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

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

Lowmemorykiller ปรับแต่ง

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

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

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

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

ด้วยเหตุนี้นักฆ่างานจึงไม่ได้รับความนิยมเท่าที่เคยเป็นมาแม้ว่ามือใหม่ Android มักจะพึ่งพาพวกเขาด้วยเหตุผลบางประการ ( ขาดข้อมูลเศร้า) . น่าเสียดายที่เทรนด์ใหม่ได้เข้ามาแทนที่นักฆ่างานซึ่งเป็นแนวโน้มของ lowmemorykiller การปรับแต่งกลไก นี่จะเป็นตัวอย่าง MinFreeManager แอปและแนวคิดหลักคือการเพิ่มค่าใช้จ่ายของ RAM ก่อนที่ระบบจะเริ่มฆ่าแอปพื้นหลัง

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

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

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

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

การปรับแต่ง I / O

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

เสียงสะท้อน 0> $ i / คิว / การหมุน; เสียงสะท้อน 1024> $ i / que / nr_requests;

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

หลังจากนั้นคุณจะพบบรรทัดที่เกี่ยวข้องกับตัวกำหนดตารางเวลา CFQ:

เสียงสะท้อน 1> $ i / que / iosched / back_seek_penalty; เสียงสะท้อน 1> $ i / que / iosched / low_latency; เสียงสะท้อน 1> $ i / que / iosched / slice_idle;

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

เคอร์เนล Linux ที่ทันสมัยสามารถเข้าใจประเภทของสื่อเก็บข้อมูลที่ใช้งานได้โดยค่าเริ่มต้น

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

สำหรับอุปกรณ์ Android แทบจะไม่มีแอปพลิเคชันใดที่จัดลำดับความสำคัญในอินพุตเอาต์พุตและไม่มีไดรเวอร์เชิงกลดังนั้นผู้วางแผนที่ดีที่สุดคือ noop / FIFO-que ดังนั้นตัวกำหนดตารางเวลาประเภทนี้ ' บิด' ไม่ได้ทำอะไรพิเศษหรือมีความหมายต่อระบบย่อย I / O ในความเป็นจริงคำสั่งรายการหลายหน้าจอเหล่านี้จะถูกแทนที่ด้วยวงจรง่ายๆ:

สำหรับ i in / sys / block / mmc *; ทำ echo noop> $ i / que / ตัวกำหนดตารางเวลา echo 0> $ i / que / iostats เสร็จแล้ว

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

การปรับแต่ง I / O ที่ไร้ประโยชน์อีกอย่างที่มักพบในสคริปต์ประสิทธิภาพคือค่าการอ่านล่วงหน้าที่เพิ่มขึ้นสำหรับการ์ด SD สูงสุด 2MB กลไกการอ่านล่วงหน้ามีไว้สำหรับข้อมูลเบื้องต้นที่อ่านจากสื่อก่อนที่แอปจะร้องขอการเข้าถึงข้อมูลนั้น โดยพื้นฐานแล้วเคอร์เนลจะพยายามคิดว่าข้อมูลใดที่จะต้องใช้ในอนาคตและโหลดลงใน RAM ล่วงหน้าซึ่งจะช่วยลดเวลาในการส่งคืน สิ่งนี้ฟังดูดีบนกระดาษ แต่อัลกอริทึมการอ่านล่วงหน้ามักจะมากกว่า ไม่ถูกต้อง ซึ่งนำไปสู่การทำงานที่ไม่จำเป็นโดยสิ้นเชิงของอินพุต - เอาท์พุตไม่ต้องพูดถึงการใช้ RAM ที่สูง

แนะนำให้ใช้ค่าการอ่านล่วงหน้าสูงระหว่าง 1 - 8 MB ในอาร์เรย์ RAID แต่สำหรับอุปกรณ์ Android ควรปล่อยให้ค่าเริ่มต้นอยู่ที่ 128 KB

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

เทคนิค 'การเพิ่มประสิทธิภาพ' ทั่วไปอีกอย่างคือการปรับระบบย่อยการจัดการหน่วยความจำเสมือน โดยทั่วไปจะกำหนดเป้าหมายเฉพาะตัวแปรเคอร์เนลสองตัวแปรคือ vm.dirty_background_ratio และ vm.dirty_ratio ซึ่งมีไว้สำหรับการปรับขนาดของบัฟเฟอร์สำหรับจัดเก็บข้อมูล 'สกปรก' สกปรก โดยทั่วไปข้อมูลคือข้อมูลที่เขียนลงดิสก์ แต่ยังมีหน่วยความจำมากกว่านี้และรอการเขียนลงดิสก์

ค่า tweak ทั่วไปใน Linux distros และ Androis ไปยังระบบย่อยการจัดการ VM จะเป็นดังนี้:

vm.dirty_background_ratio = 10 vm.dirty_ratio = 20

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

สิ่งที่คุณควรเข้าใจก็คือแม้ว่าขนาดบัฟเฟอร์ ไม่ถึง 10% ระบบจะเริ่มเล่น pdflush โดยอัตโนมัติหลังจากผ่านไป 30 วินาที การรวมกันของ 10/20 นั้นค่อนข้างสมเหตุสมผลตัวอย่างเช่นบนอุปกรณ์ที่มี RAM 1GB ซึ่งจะเท่ากับ 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 ขนาดใหญ่

สายฟ้า! สคริปต์ใช้ค่าที่สมเหตุสมผลกว่า แต่โดยรวมแล้วมันก็ยังไม่มีความหมาย:

ถ้า ['$ 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; fi;

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

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 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 ersistode.shutdown.memcap