많은 양의 데이터를 J2ME과 함께 저장하는 모범 사례


9

장치에 저장할 많은 양의 데이터가있는 J2ME 응용 프로그램을 개발 중입니다 (1MB이지만 변수의 영역). 필자는 파일 시스템에 의지 할 수 없기 때문에 레코드 관리 시스템 (RMS)을 사용하고 있습니다. 레코드 관리 시스템 (RMS)은 여러 레코드 저장소를 허용하지만 각각 크기가 제한되어 있습니다. 초기 타겟 플랫폼 인 Blackberry는 각각 64KB로 제한합니다.

다른 사람이 RMS에 많은 양의 데이터를 저장하는 문제와 어떻게 관리했는지 궁금합니다. 나는 그것의 너무 큰 경우 레코드 크기를 계산하고 하나의 데이터 세트를 여러 매장으로 분할해야한다고 생각하고있다. 그러나 그것은 그대로 유지하기 위해 많은 복잡성을 추가한다.

다양한 유형의 데이터가 저장되지만 특히 한 세트 만 64KB 제한을 초과합니다.

  0

일부 장치는 허용되는 레코드 저장소의 수를 제한한다는 사실에 유의할 가치가 있습니다. 이 값은 2로 낮을 수 있습니다. 18 mar. 152015-03-18 16:29:44

9

몇 킬로바이트 이상이라면 JSR 75 나 원격 서버 중 하나를 사용해야합니다. RMS 레코드는 일부 고급 단말 에서조차 크기와 속도면에서 극히 제한적입니다. J2ME에서 1MB의 데이터를 처리해야한다면 신뢰할 수 있고 이식 가능한 유일한 방법은 네트워크에 저장하는 것입니다. HttpConnection 클래스와 GET 및 POST 메서드는 항상 지원됩니다.

JSR 75 FileConnection을 지원하는 핸드셋에서 유효한 대안이 될 수 있지만 코드 서명이없는 경우 사용자 경험의 악몽입니다. 거의 모든 단일 API 호출은 담요 사용 권한이없는 보안 프롬프트를 호출합니다. JSR 75로 앱을 배포하는 회사는 가능한 모든 인증서의 일부만을 커버하기 위해 모든 포트에 대해 보통 6 개의 바이너리가 필요합니다. 이것은 제조업체 인증서에만 적용됩니다. 일부 핸드셋에는 캐리어 고정 인증서 만 있습니다.


3

가장 유연한 접근 방식은 RMS 위에 직접 파일 시스템을 구현하는 것입니다. 하드 드라이브의 블록과 비슷한 방식으로 RMS 레코드를 처리하고 inode structure 또는 이와 유사한 방법을 사용하여 논리 파일을 여러 블록에 분산시킬 수 있습니다. 블록 상단에 바이트 또는 스트림 지향 인터페이스를 구현 한 다음 특수 데이터 구조를 작성하기위한 API 레이어를 만드는 것이 좋습니다 (또는 단순히 데이터 스트림에 직렬화 할 수있는 개체를 만들 수 있습니다).

Tanenbaum's classical book on operating systems은 간단한 파일 시스템을 구현하는 방법을 다루지 만, 종이가 마음에 들지 않으면 온라인에서 다른 자료를 찾을 수있을 것이라고 확신합니다.


4

RMS 성능과 구현은 장치마다 크게 다르므로 플랫폼 이식성이 문제가되는 경우 일부 장치에서는 코드가 제대로 작동하지 않을 수 있습니다. RMS는 대량의 데이터가 아닌 소량의 데이터 (고득점 테이블 등)를 저장하도록 설계되었습니다.

일부 플랫폼은 여러 레코드 저장소에 저장된 파일보다 빠르다는 것을 알 수 있습니다. 일부는 한 상점 내의 여러 레코드로 더 빠릅니다. 많은 것은 저장을 위해 괜찮지 만, 많은 양의 데이터를 저장소에서 삭제할 때 사용이 느려지 게됩니다.

가능한 경우 JSR-75를 사용하고 더 나은 기능이없는 경우 RMS로 되돌아가는 고유 한 파일 저장소 인터페이스를 만드는 것이 가장 좋습니다.

불행히도 JavaME의 경우 코드의 장치 별 변형을 작성하는 경우가 많습니다.


1

저는 JavaME를 코딩하기 시작했으나, 모든 데이터 청크의 크기가 제한되어있는 이전 버전의 PalmOS에 대한 경험이 있으므로 레코드 색인 및 오프셋을 사용하여 데이터 구조를 설계해야합니다.


2

Blackberry OS 4.6에서 RMS 저장소 크기 제한이 512KB로 증가되었지만 많은 장치가 4.6을 지원하지 않을 가능성이 높기 때문에이 점이별로 도움이되지 않습니다.블랙 베리의 또 다른 옵션은 저장 용량이 64kb이지만 저장소의 크기에는 제한이없는 영구 저장소 (장치의 물리적 한계 제외)입니다.

저는 Carlos와 izb가 옳다고 생각합니다.


2

JSR75 (FileConnection)를 사용하고 유효한 (신뢰할 수있는) 인증서로 MIDlet에 서명하는 것을 잊지 마십시오.


1

감사 위원 모두에게 유용한 커미션을 제공합니다. 결국 가장 간단한 해결책은 저장되는 데이터의 양을 제한하고, 저장소의 크기에 따라 데이터를 조정하는 코드를 구현하고, 로컬에 저장되지 않은 경우 필요에 따라 서버에서 데이터를 가져 오는 것입니다. OS 4.6에서 한도가 높아진다는 사실에 흥미 롭습니다. 내 코드는 단순히 자체적으로 조정하고 더 많은 데이터를 저장합니다.

.cod 컴파일러를 사용하지 않고 Blackberry 용 J2ME 응용 프로그램을 개발하면 JSR 75 우리가 아카이브에 서명 할 수 없기 때문에 어떤 것들. Carlos가 지적했듯이 이것은 어떤 플랫폼에서든 문제이며 PIM 부분을 사용하여 비슷한 문제가 발생했습니다. RMS는 Blackberry 플랫폼에서 매우 느린 것처럼 보이기 때문에 데이터가 메모리에 캐시되고 우선 순위가 낮은 백그라운드 스레드에서 RMS에 쓰여지지 않는 한 맨 위에있는 inode/b-tree 파일 시스템이 얼마나 유용한 지 잘 모르겠습니다.

  0

RIM에 등록하고 서명 키를 얻은 경우 영속 저장소 API를 사용할 수 있습니다.이 API는 메가 바이트 단위의 데이터 저장에 적합합니다. 나는 서명 키가별로 비용이 들지 않는다고 생각합니다. 29 sep. 082008-09-29 10:33:26

  0

내가 말했듯이 J2ME API 만 사용하고 있습니다. RIM API에 액세스 할 수 없으면이 문제가 발생하지 않습니다. 02 oct. 082008-10-02 22:07:45


2

읽기 전용으로 리소스 파일의 색인을 생성하여 허용되는 시간 (10 초 이내)에 도착했습니다. 2 ~ 800KB CSV 가격 목록 내보내기가 있습니다. 프로그램 클래스와이 두 파일은 300KB JAR로 압축됩니다.

검색시 나는 List을 표시하고 백그라운드에서 두 개의 Thread을 실행하여 채우므로 첫 번째 결과가 매우 빠르게 나타나고 즉시 볼 수 있습니다. 처음에는 간단한 선형 검색을 구현했지만 너무 느려서 (~ 2 분).

그런 다음 알파벳순으로 정렬 된 파일의 색인을 생성하여 각 문자의 시작을 찾습니다. 이제 라인별로 구문 분석하기 전에 첫 문자를 기준으로 원하는 위치에 먼저 InputStreamReader.skip()을 입력합니다. 나는 그 지연이 대부분 자원의 압축을 푸는 것으로부터 오는 것이라고 생각한다. 그래서 자원을 나누면 더 빨리 속도를 낼 것이다. 쉬운 업그레이드의 이점을 잃지 않고 그렇게하고 싶지 않습니다. CSV는 사전 처리없이 내보내집니다.