s40 기계는 게임, 대중 과학에 대한 더 나은 메모리를 가지고 있습니다.

메모리 사용량에는 프로그램과 리소스라는 두 가지 주요 유형이 있습니다. ·프로그램 클래스는 MIDlet이 시작될 때 클래스 바이트코드 파일로 컴파일되어 메모리에 로드되며 한꺼번에 추가됩니다. 즉, MIDlet에 클래스가 많을수록, 단일 클래스 프로그램이 길어지고, 클래스 내에 문자열 상수와 데이터가 많아질수록, 컴파일된 클래스 파일의 크기가 커지고 로드 후 더 많은 메모리를 차지하게 됩니다. 나는 MIDlet이 시작된 후 전체 프로그램이 차지하는 메모리 양을 확인하기 위해 MIDlet 클래스의 생성자에 있는 Runtime 메소드를 자주 사용합니다. //최적화 방법: 1. MIDlet 프로그램은 메모리 사용량을 줄이기 위해 두 개의 클래스로 작성되지만 Java의 OOP 기능은 희생됩니다. 이러한 단점은 프로그램이 상대적으로 클 때 특히 분명해집니다. 게다가 코코모는 단일 클래스가 너무 크고 로딩 시간이 너무 길어 보물상자 로고의 6초 제한을 위반하는 상황을 겪은 적이 있다. //2. 우아한 코드를 작성하고, 함수 수를 줄이고, 프로그램이 출시될 때 try catch를 제거하고, 프로그램 줄 수를 최소화하십시오. 이것은 일반적으로 이전 40에서는 불가능하지만 이제 CoCoMo는 메모리를 절약하기 위해 더 이상 이에 의존하지 않습니다. //3. 데이터와 문자열을 파일에 쓰고, 사용할 때는 메모리에 로드하고, 사용하지 않을 때는 null로 설정합니다. 4. I/O 작업 getClass(). getResourceAsStream(file);, 데이터베이스 작업 RecordStore. openRecordStore(name, true);, 사운드 생성 관리자. createPlayer();, 이미지 생성 이미지. createImage(파일); 짧은 시간 안에 많은 양의 메모리를 점유하고 나중에 해제합니다. MIDlet 프로그램의 남은 메모리가 부족하면 이러한 함수를 자주 호출할 때 메모리 오버플로가 발생하여 소위 메모리 피크가 발생하는데, 이는 특히 이전 40에서 흔히 발생합니다. OutOfMemoryError가 다시 발생하면 런타임을 사용하여 메모리 피크가 발생하는 위치를 찾아 이 명령문을 별도로 호출하고 시스템을 유연하게 활용해 보십시오. gc()를 사용하여 시간 내에 수집합니다. //·리소스 사진: 메모리를 많이 차지하며, 특히 사진 리소스가 많은 모바일 게임에서는 더욱 그렇습니다. 이미지 리소스의 메모리 사용량을 계산하는 것은 J2ME 게임 개발자의 일반적인 작업이 되었습니다. CoCoMo에서는 이미지의 메모리 사용량을 계산하는 방법을 설명합니다. //메모리 사용량 = 너비 * 높이 * 픽셀 바이트 수, 픽셀 바이트 수는 모델에 따라 다릅니다. //예를 들어 7210에서 64*64 그림의 메모리 사용량 = 64*64*1.5 = 614 4(바이트) = 6K, S60의 메모리 사용량 = 64*64*2 = 8192(바이트) = 8K입니다. 픽셀 바이트 수는 모델에 따라 다릅니다. 예를 들어 7210은 4096 컬러 모델이므로 12비트가 픽셀을 표현하는데 사용되므로 1.5를 곱한다는 뜻이고, S60은 65536컬러 모델이고 16비트가 픽셀을 표현하는데 사용되므로 2를 곱한다는 의미입니다. //최적화 방법//이미지를 압축하면 메모리를 절약할 수 있다고 생각하는 것은 잘못된 것입니다. 위의 설명에 따르면 이미지가 메모리에 로드된 후에는 너비와 높이에만 관련되며 이미지 데이터의 크기와는 아무런 관련이 없습니다. 이미지를 압축하면 jar 크기만 줄어들 수 있지만 메모리 사용량은 줄어들지 않습니다. //1. 정적 방법: 그림의 크기를 줄입니다. 너비와 높이가 더 작으면 결과도 더 작아집니다. 이 아이디어를 바탕으로 Gameloft의 Prince of Persia와 같은 애니메이션 편집기와 같은 도구가 등장했습니다. 캐릭터를 분할한 후 인체의 일부를 재사용할 수 있습니다. 각 부품의 컴팩트한 배치는 사진의 크기를 줄이고 사진의 모든 공간을 최대한 활용하는 것입니다. //2. 동적 방법: 동시에 메모리에 로드되는 사진 수를 줄입니다. CoCoMo는 나루토 사무라이 프로젝트에서 이러한 상황을 겪은 적이 있습니다. 당시에는 6가지 종류의 몬스터가 있었습니다. 동시에 메모리에 로드된다면 분명 올드 40에서는 폭발할 터이다. 하지만 각 레벨마다 2~3종의 몬스터만 등장하기 때문에 각 레벨에서는 해당 레벨에 등장한 몬스터의 사진만 로드하면 된다. 지금 생각해보면 이 프로젝트는 예전 40에서 오버플로가 자주 발생했습니다. //Sound//Sound도 상대적으로 메모리를 많이 잡아먹는 리소스입니다. 사운드의 오디오 트랙이 차지하는 바이트는 바이트 스트림으로 변환되어 메모리에 로드됩니다. 따라서 오디오 트랙이 차지하는 바이트를 줄이면 메모리 소비를 줄일 수 있습니다. Gameloft의 현재 접근 방식은 사운드 변환 도구를 사용하여 mid를 ott로 변환한 다음 이를 ByteArrayInputStream 바이트 스트림으로 변경하여 플레이어를 생성하는 것입니다.