ตำนานการเพิ่มประสิทธิภาพ Android ที่พบมากที่สุด Debunked

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

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

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

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

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

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

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

แอพ Seeder สำหรับ Android

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

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

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

Google ทุบข้อผิดพลาดนี้หลังจาก Android 3.0 แต่ด้วยเหตุผลบางอย่าง Seeder ยังปรากฏขึ้นในรายการ “ tweaks แนะนำ” สำหรับการเพิ่มประสิทธิภาพประสิทธิภาพของ 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 นั้นค่อนข้างแปลกใจเสมอ ซึ่งหมายความว่าข้างแพคเกจมาตรฐานสำหรับแอพ Android ในรูปแบบ APK ที่พบใน / system / app / และ / system / priv-app / เป็นชื่อไฟล์เดียวกันกับนามสกุล. odex ไฟล์ odex มีแอพพลิเคชั่น bytecode ที่ได้รับการปรับแต่งแล้วซึ่งผ่านการรับรองความถูกต้องและเครื่องเสมือนจริงของเครื่องมือเพิ่มประสิทธิภาพแล้วบันทึกลงในไฟล์แยกต่างหากโดยใช้สิ่งที่ต้องการเครื่องมือ dexopt

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

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

Lowmemorykiller ปรับแต่ง

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

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

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

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

ด้วยเหตุนี้นักฆ่าภารกิจจึงไม่ได้รับความนิยมเท่าที่เคยเป็นมาแม้ว่ามือใหม่ Android จะยังคงพึ่งพาพวกเขาด้วยเหตุผลบางประการ ( ขาดข้อมูลเศร้า) น่าเสียดายที่เทรนด์ใหม่ได้เข้ามาแทนที่ task-killers ซึ่งเป็นเทรนด์ของการปรับจูนกลไกแบบ นี่เป็นตัวอย่างของแอป 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 เป็น "ช่วงงบประมาณ" ที่ทันสมัยแม้กระทั่งอุปกรณ์ 4GB RAM จะมองว่าเป็น "ช่วงกลาง" ในทุกวันนี้ดังนั้นการปรับแต่ง LMK จึงล้าสมัยและไร้ประโยชน์จริงๆ

I / O ปรับแต่ง

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

 echo 0> $ i / คิว / การหมุน; 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 อันที่จริงคำสั่งรายการหลายหน้าจอทั้งหมดนั้นถูกแทนที่ด้วยวงจรที่ง่ายกว่า:

 สำหรับ i ใน / sys / block / mmc *; ทำ echo noop> $ i / queue / scheduler echo 0> $ i / queue / iostats เสร็จแล้ว 

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

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

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

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

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

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

 vm.dirty_background_ratio = 10 vm.dirty_background = 20 

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

สิ่งที่คุณควรเข้าใจคือแม้ว่าขนาดบัฟเฟอร์ ไม่ถึง 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; 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
  • ปิดใช้งานบริการระบบที่ไม่จำเป็นลบระบบที่ไม่ได้ใช้และแอพพลิเคชั่นบุคคลที่สามที่ไม่ค่อยได้ใช้ โดยทั่วไปการถอนการติดตั้ง bloatware
  • เคอร์เนลที่กำหนดเองพร้อมการปรับให้เหมาะสมสำหรับอุปกรณ์เฉพาะ (อีกครั้งไม่ใช่นิวเคลียสทั้งหมดที่เท่ากัน)
  • Noop ตัวกำหนดตารางเวลา I / O ที่อธิบายไว้แล้ว
  • อัลกอริธึมความอิ่มตัว TCP Westwood - ใช้งานได้อย่างมีประสิทธิภาพยิ่งขึ้นใน Android ลูกบาศก์เริ่มต้นสำหรับเครือข่ายไร้สายที่มีในเมล็ดที่กำหนดเอง

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

LaraCraft304 จากฟอรัม XDA Developers ได้ทำการศึกษาและพบว่าการตั้งค่า /system/build.prop จำนวนที่น่าประทับใจที่แนะนำสำหรับการใช้“ ผู้เชี่ยวชาญ” ไม่มีอยู่ในแหล่งข้อมูล AOSP และ CyanogenMod นี่คือรายการ:

 ro.ril.disable.power.collapse ro.ot.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_errpt ersist.sys.shutdown.mAP_HOME 

บทความที่น่าสนใจ