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

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

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

นั่นไม่ได้หมายความว่าผู้คนจะปล่อยสคริปต์ที่ชั่วร้ายโดยเจตนา – มีการปลอม จ่ายเงิน อย่างแน่นอน แอปใน Play Store แต่สคริปต์การเพิ่มประสิทธิภาพที่เผยแพร่บนฟอรัม Android มักมีเจตนาดี เกิดขึ้นได้เพียงว่านักพัฒนาซอฟต์แวร์อาจได้รับข้อมูลผิดพลาด หรือเพียงแค่ทดลองปรับแต่งการปรับแต่งต่างๆ น่าเสียดายที่เอฟเฟกต์ก้อนหิมะมีแนวโน้มที่จะเกิดขึ้น โดยเฉพาะอย่างยิ่งในสคริปต์การปรับให้เหมาะสมแบบ "รวมทุกอย่าง" การปรับแต่งเล็กน้อยอาจทำ บางสิ่ง . ได้จริง ในขณะที่การปรับแต่งชุดอื่นในสคริปต์อาจไม่ทำอะไรเลย แต่สคริปต์เหล่านี้ถูกส่งต่อไปในฐานะกระสุนวิเศษ โดยไม่ต้องมีการสอบสวนจริง ๆ ว่าสิ่งใดใช้ได้ผลและไม่ได้ผล

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

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

สลับ

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

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

ผู้ที่ชื่นชอบการเพิ่มประสิทธิภาพบางคนสามารถพูดได้ว่าการแลกเปลี่ยนนั้นไม่มีปัญหา แต่ก็ไม่ใช่การสลับเพื่อเพิ่มประสิทธิภาพ – เป็นกลไกในตัวของ 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 (Kernel Same Page Merging) ซึ่งรวมหน้าหน่วยความจำที่เหมือนกันในการเสนอราคาเพื่อเพิ่มพื้นที่ว่าง Google แนะนำสิ่งนี้ตามจริงแล้ว แต่ทำให้เกิดความล่าช้ามากขึ้นในอุปกรณ์รุ่นเก่า เนื่องจากแกนโฆษณาที่ทำงานอย่างต่อเนื่องนั้นทำงานอย่างต่อเนื่องจากหน่วยความจำเพื่อค้นหาหน้าที่ซ้ำกัน โดยทั่วไป การพยายามเรียกใช้การปรับแต่งการเพิ่มประสิทธิภาพจะทำให้อุปกรณ์ช้าลงไปอีก อย่างแดกดัน

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

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

ใช่ มีรายงานจำนวนมากที่ประกาศประสิทธิภาพของ 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 เดียวกันหรือไม่ หรือทางเลือก haveged หรือแม้แต่การเชื่อมโยงระหว่าง /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 เพิ่มขึ้น ซึ่งแน่นอนว่าส่งผลเสียต่อการใช้แบตเตอรี่

โอเด็กซ์

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

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

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

Lowmemorykiller ปรับแต่ง

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

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

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

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

ด้วยเหตุนี้ นักฆ่างานจึงไม่ได้รับความนิยมอย่างที่เคยเป็น แม้ว่ามือใหม่ Android จะยังคงพึ่งพาพวกเขาด้วยเหตุผลบางประการ (ขาดข้อมูล เศร้า) . น่าเสียดายที่เทรนด์ใหม่เข้ามาแทนที่ task-killer เทรนด์ของ 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 ตัวอย่างเช่น มาดูที่ ThunderBolt! สคริปต์ซึ่งมีบรรทัดเหล่านี้:

echo 0 > $i/queue/rotational;

echo 1024 > $i/queue/nr_requests;

บรรทัดแรกจะให้คำสั่งตัวกำหนดตารางเวลา I/O ในการจัดการกับ SSD และบรรทัดที่สองจะเพิ่มขนาดสูงสุดของคิว 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;

ตามด้วยบรรทัดอื่นๆ ที่เป็นของผู้วางแผนรายอื่น แต่ท้ายที่สุด สองคำสั่งแรกก็ไม่มีประโยชน์เพราะ:

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

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

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

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

echo noop > $i/queue/scheduler

echo 0 > $i/queue/iostats

done

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

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

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

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

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

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

vm.dirty_background_ratio = 10

vm.dirty_ratio = 20

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

สิ่งที่คุณควรเข้าใจคือแม้ว่าขนาดบัฟเฟอร์ ไม่ถึง 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 ที่ใช้งานหนักเท่านั้น

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

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

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

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

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

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

• การเร่งความเร็ว – การเร่งความเร็วเพียงเล็กน้อยเพื่อปรับปรุงประสิทธิภาพและการทำงานที่ต่ำเกินไป – ประหยัดแบตเตอรี่เพียงเล็กน้อย
• การเพิ่มประสิทธิภาพฐานข้อมูล – ในทางทฤษฎี ควร ให้การปรับปรุงประสิทธิภาพของอุปกรณ์ แต่น่าสงสัย
• Zipalign – น่าแปลกที่แม้ว่าจะมีการจัดแนวเนื้อหาที่มีฟีเจอร์ Android SDK ในตัวภายในไฟล์ APK ในสโตร์ คุณก็ยังพบว่าซอฟต์แวร์จำนวนมากไม่ได้ส่งผ่าน zipalign
• ปิดใช้งานบริการระบบที่ไม่จำเป็น ลบระบบที่ไม่ได้ใช้ และแอปพลิเคชันบุคคลที่สามที่ไม่ค่อยได้ใช้ โดยพื้นฐานแล้ว การถอนการติดตั้งโบลัตแวร์
• เคอร์เนลแบบกำหนดเองพร้อมการปรับให้เหมาะสมสำหรับอุปกรณ์เฉพาะ (อีกครั้ง ไม่ใช่ทุกนิวเคลียสจะดีเท่ากัน)
• อธิบาย Noop ของตัวจัดกำหนดการ I/O แล้ว
• อัลกอริธึมความอิ่มตัว 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

ersist.sys.shutdown.mode

ro.HOME_APP_ADJ