Máy s40 có bộ nhớ tốt hơn cho game, khoa học phổ thông.

Có hai loại sử dụng bộ nhớ chính là chương trình và tài nguyên. ·Lớp chương trình sẽ được biên dịch thành một tệp mã byte của lớp và được tải vào bộ nhớ khi MIDlet được khởi động và nó sẽ được thêm vào cùng một lúc. Điều đó có nghĩa là, càng có nhiều lớp trong MIDlet, chương trình một lớp càng dài và càng có nhiều hằng chuỗi và dữ liệu trong lớp thì tệp lớp được biên dịch sẽ càng lớn và càng chiếm nhiều bộ nhớ hơn sau khi tải. Tôi thường sử dụng phương thức Runtime trong hàm tạo của lớp MIDlet để kiểm tra lượng bộ nhớ bị chiếm bởi toàn bộ chương trình sau khi MIDlet được khởi động. //Phương pháp tối ưu hóa: 1. Chương trình MIDlet được viết thành hai lớp để giảm mức sử dụng bộ nhớ, nhưng lại làm mất đi các tính năng OOP của Java. Nhược điểm này sẽ đặc biệt rõ ràng khi chương trình có quy mô tương đối lớn. Hơn nữa, CoCoMo từng gặp phải tình trạng một lớp quá lớn và thời gian tải quá lâu, vi phạm giới hạn 6 giây trên logo của rương kho báu. //2. Cố gắng viết mã tinh tế, giảm số lượng chức năng, loại bỏ thử bắt khi chương trình được phát hành và giảm thiểu số lượng dòng chương trình. Điều này nhìn chung là không thể thực hiện được trên 40 cũ nhưng hiện tại CoCoMo không còn dựa vào điều này để tiết kiệm bộ nhớ nữa. //3. Ghi dữ liệu và chuỗi vào tệp, tải chúng vào bộ nhớ khi sử dụng và đặt chúng thành null khi không sử dụng. 4. Thao tác I/O getClass(). getResourceAsStream(file);, thao tác cơ sở dữ liệu RecordStore. openRecordStore(name, true);, Trình quản lý tạo âm thanh. createPlayer();, tạo ảnh Image. createImage(tập tin); sẽ chiếm một lượng lớn bộ nhớ trong một khoảng thời gian ngắn và giải phóng nó sau đó. Nếu bộ nhớ còn lại của chương trình MIDlet không đủ, tình trạng tràn bộ nhớ sẽ xảy ra khi các hàm này được gọi thường xuyên, dẫn đến cái gọi là đỉnh bộ nhớ, đặc biệt phổ biến trên phiên bản 40 cũ. Khi gặp lại OutOfMemoryError, hãy sử dụng Runtime để tìm vị trí xảy ra đỉnh bộ nhớ và thử gọi các câu lệnh này một cách riêng biệt, đồng thời sử dụng System một cách linh hoạt. gc() để thu thập kịp thời. //·Tài nguyên hình ảnh: Chúng chiếm dung lượng lớn bộ nhớ, đặc biệt là các game di động có nhiều tài nguyên hình ảnh. Tính toán mức sử dụng bộ nhớ của tài nguyên hình ảnh đã trở thành nhiệm vụ thường xuyên của các nhà phát triển trò chơi J2ME. CoCoMo sẽ giải thích cách tính mức sử dụng bộ nhớ của hình ảnh: //Mức sử dụng bộ nhớ = chiều rộng * chiều cao * số byte pixel, trong đó số byte pixel thay đổi tùy theo kiểu máy. // Ví dụ: mức sử dụng bộ nhớ của ảnh 64*64 trên 7210 = 64*64*1.5 = 614 4 (byte) = 6K, mức sử dụng bộ nhớ trên S60 = 64*64*2 = 8192 (byte) = 8K. Số byte pixel thay đổi tùy theo kiểu máy. Ví dụ: 7210 là mô hình 4096 màu, có nghĩa là 12 bit được sử dụng để biểu thị một pixel, nhân với 1,5, trong khi S60 là mô hình 65536 màu và 16 bit được sử dụng để biểu thị một pixel, do đó nhân với 2. //Phương pháp tối ưu hóa//Thật sai lầm khi nghĩ rằng nén hình ảnh có thể tiết kiệm bộ nhớ. Theo giải thích ở trên, sau khi hình ảnh được tải vào bộ nhớ, nó chỉ liên quan đến chiều rộng và chiều cao chứ không liên quan gì đến kích thước của dữ liệu hình ảnh. Nén hình ảnh chỉ có thể giảm kích thước jar chứ không thể giảm mức sử dụng bộ nhớ. //1. Phương pháp tĩnh: Giảm kích thước của hình ảnh. Nếu chiều rộng và chiều cao nhỏ hơn thì kết quả sẽ nhỏ hơn. Dựa trên ý tưởng này, các công cụ như trình chỉnh sửa hoạt hình đã xuất hiện, chẳng hạn như Prince of Persia của Gameloft. Sau khi các nhân vật được phân chia, các bộ phận trên cơ thể con người có thể được tái sử dụng. Việc bố trí nhỏ gọn từng bộ phận nhằm giảm kích thước của hình ảnh và tận dụng tối đa từng centimet không gian trong hình. //2. Phương pháp động: Giảm số lượng ảnh được tải vào bộ nhớ cùng một lúc. CoCoMo từng gặp phải tình huống này trong dự án Naruto Samurai. Có 6 loại quái vật vào thời điểm đó. Nếu nạp vào bộ nhớ cùng lúc thì chắc chắn sẽ nổ trên 40 cũ. Tuy nhiên, mỗi cấp độ chỉ xuất hiện hai đến ba loại quái vật nên mỗi cấp độ chỉ cần tải hình ảnh của những quái vật xuất hiện ở cấp độ đó. Bây giờ tôi nghĩ về dự án này, lỗi tràn xảy ra thường xuyên trên 40 cũ. //Sound//Sound cũng là một tài nguyên tương đối tiêu tốn bộ nhớ. Các byte được chiếm bởi rãnh âm thanh trong âm thanh sẽ được chuyển đổi thành luồng byte và được tải vào bộ nhớ. Do đó, việc giảm số byte mà rãnh âm thanh chiếm giữ có thể giảm mức tiêu thụ bộ nhớ. Cách tiếp cận hiện tại của Gameloft là sử dụng công cụ chuyển đổi âm thanh để chuyển đổi mid thành ott, sau đó thay đổi nó thành luồng byte ByteArrayInputStream để tạo Trình phát.