เครื่องs40มีความจำเล่นเกมดีขึ้นตามหลักวิทยาศาสตร์ยอดนิยม

การใช้หน่วยความจำมีสองประเภทหลัก ได้แก่ โปรแกรมและทรัพยากร ·คลาสโปรแกรมจะถูกคอมไพล์เป็นไฟล์คลาสไบต์โค้ดและโหลดลงในหน่วยความจำเมื่อ MIDlet เริ่มทำงาน และจะถูกเพิ่มทั้งหมดในครั้งเดียว กล่าวคือ ยิ่งมีคลาสใน MIDlet มาก โปรแกรมคลาสเดียวก็จะยาวขึ้น และยิ่งค่าคงที่สตริงและข้อมูลภายในคลาสมากขึ้น ไฟล์คลาสที่คอมไพล์ก็จะใหญ่ขึ้น และหน่วยความจำก็จะกินมากขึ้นหลังจากโหลด ฉันมักจะใช้วิธี Runtime ในตัวสร้างของคลาส MIDlet เพื่อตรวจสอบจำนวนหน่วยความจำที่โปรแกรมทั้งหมดครอบครองหลังจาก MIDlet เริ่มทำงาน //วิธีการเพิ่มประสิทธิภาพ: 1. โปรแกรม MIDlet ถูกเขียนเป็นสองคลาสเพื่อลดการใช้หน่วยความจำ แต่ต้องเสียคุณสมบัติ OOP ของ Java ข้อเสียนี้จะเห็นได้ชัดโดยเฉพาะเมื่อโปรแกรมมีขนาดค่อนข้างใหญ่ นอกจากนี้ CoCoMo ยังเคยพบกับสถานการณ์ที่คลาสเดียวมีขนาดใหญ่เกินไปและเวลาโหลดนานเกินไป ซึ่งละเมิดขีดจำกัด 6 วินาทีบนโลโก้ของหีบสมบัติ //2. พยายามเขียนโค้ดที่สวยงาม ลดจำนวนฟังก์ชัน ลบ try catch เมื่อโปรแกรมออก และลดจำนวนบรรทัดโปรแกรมให้เหลือน้อยที่สุด โดยทั่วไปสิ่งนี้เป็นไปไม่ได้ในรุ่น 40 รุ่นเก่า แต่ตอนนี้ CoCoMo ไม่ต้องอาศัยสิ่งนี้อีกต่อไปเพื่อประหยัดหน่วยความจำ //3. เขียนข้อมูลและสตริงลงในไฟล์ โหลดลงในหน่วยความจำเมื่อมีการใช้งาน และตั้งค่าเป็นว่างเมื่อไม่ได้ใช้งาน 4. การดำเนินการ I/O getClass() getResourceAsStream (ไฟล์); การดำเนินการฐานข้อมูล RecordStore openRecordStore (ชื่อ, จริง);, ตัวจัดการการสร้างเสียง createPlayer();, การสร้างอิมเมจ createImage(ไฟล์); จะครอบครองหน่วยความจำจำนวนมากในช่วงเวลาสั้น ๆ และปล่อยออกมาในภายหลัง หากหน่วยความจำที่เหลืออยู่ของโปรแกรม MIDlet ไม่เพียงพอ หน่วยความจำล้นจะเกิดขึ้นเมื่อมีการเรียกใช้ฟังก์ชันเหล่านี้บ่อยครั้ง ส่งผลให้เกิดจุดสูงสุดของหน่วยความจำ ซึ่งเป็นเรื่องปกติโดยเฉพาะในรุ่น 40 เก่า เมื่อพบ OutOfMemoryError อีกครั้ง ให้ใช้ Runtime เพื่อค้นหาตำแหน่งที่หน่วยความจำสูงสุดเกิดขึ้น และพยายามเรียกคำสั่งเหล่านี้แยกกัน และใช้งาน System อย่างยืดหยุ่น gc() เพื่อรวบรวมทันเวลา //·รูปภาพทรัพยากร: ใช้พื้นที่หน่วยความจำจำนวนมาก โดยเฉพาะเกมมือถือที่มีทรัพยากรรูปภาพมากมาย การคำนวณการใช้หน่วยความจำของทรัพยากรรูปภาพกลายเป็นงานปกติสำหรับนักพัฒนาเกม J2ME CoCoMo จะอธิบายวิธีคำนวณการใช้หน่วยความจำของรูปภาพ: //การใช้หน่วยความจำ = ความกว้าง * ความสูง * จำนวนพิกเซลไบต์ โดยที่จำนวนพิกเซลไบต์จะแตกต่างกันไปขึ้นอยู่กับรุ่น // ตัวอย่างเช่น การใช้หน่วยความจำของรูปภาพ 64*64 บน 7210 = 64*64*1.5 = 614 4 (ไบต์) = 6K การใช้หน่วยความจำบน S60 = 64*64*2 = 8192 (ไบต์) = 8K จำนวนไบต์ของพิกเซลจะแตกต่างกันไปตามรุ่น ตัวอย่างเช่น 7210 เป็นรุ่น 4096 สี ซึ่งหมายความว่า 12 บิตถูกใช้เพื่อแสดงพิกเซล ดังนั้นคูณด้วย 1.5 ในขณะที่ S60 เป็นรุ่น 65536 สี และใช้ 16 บิตเพื่อแสดงพิกเซล ดังนั้นให้คูณด้วย 2 //วิธีการเพิ่มประสิทธิภาพ//การคิดว่าการบีบอัดรูปภาพจะช่วยประหยัดหน่วยความจำถือเป็นเรื่องผิด ตามคำอธิบายข้างต้น หลังจากโหลดรูปภาพลงในหน่วยความจำแล้ว รูปภาพจะสัมพันธ์กับความกว้างและความสูงเท่านั้น และไม่เกี่ยวข้องกับขนาดของข้อมูลรูปภาพ การบีบอัดรูปภาพสามารถลดขนาด jar ได้เท่านั้น แต่จะลดการใช้หน่วยความจำไม่ได้ //1. วิธีการคงที่: ลดขนาดของรูปภาพ หากความกว้างและความสูงน้อยกว่า ผลลัพธ์ก็จะเล็กลง จากแนวคิดนี้ เครื่องมือต่างๆ เช่น โปรแกรมแก้ไขแอนิเมชั่นได้ปรากฏขึ้น เช่น Prince of Persia ของ Gameloft หลังจากที่ตัวละครถูกแบ่งออกแล้ว ส่วนต่าง ๆ ของร่างกายมนุษย์ก็สามารถนำมาใช้ซ้ำได้ การจัดวางแต่ละส่วนให้กะทัดรัดคือการลดขนาดของภาพและใช้พื้นที่ทุกตารางนิ้วในภาพให้เกิดประโยชน์สูงสุด //2. วิธีไดนามิก: ลดจำนวนภาพที่โหลดลงในหน่วยความจำในเวลาเดียวกัน CoCoMo เคยเจอสถานการณ์นี้ในโครงการ Naruto Samurai ตอนนั้นมีมอนสเตอร์อยู่ 6 ประเภท หากพวกมันถูกโหลดเข้าสู่หน่วยความจำในเวลาเดียวกัน มันจะระเบิดในยุค 40 แบบเก่าอย่างแน่นอน อย่างไรก็ตาม มีมอนสเตอร์เพียงสองถึงสามประเภทเท่านั้นที่ปรากฏในแต่ละเลเวล ดังนั้นแต่ละเลเวลจึงจำเป็นต้องโหลดรูปภาพของมอนสเตอร์ที่ปรากฎในระดับนั้นเท่านั้น ตอนนี้ฉันคิดถึงโปรเจ็กต์นี้ โอเวอร์โฟลว์เกิดขึ้นบ่อยครั้งในยุค 40 เก่า //เสียง//เสียงก็เป็นทรัพยากรที่ค่อนข้างใช้หน่วยความจำเช่นกัน ไบต์ที่ครอบครองโดยแทร็กเสียงในเสียงจะถูกแปลงเป็นสตรีมไบต์และโหลดลงในหน่วยความจำ ดังนั้นการลดจำนวนไบต์ที่ครอบครองโดยแทร็กเสียงจึงสามารถลดการใช้หน่วยความจำได้ วิธีการปัจจุบันของ Gameloft คือการใช้เครื่องมือแปลงเสียงเพื่อแปลงเสียงกลางเป็น ott จากนั้นเปลี่ยนเป็นสตรีมไบต์ ByteArrayInputStream เพื่อสร้างผู้เล่น