안드로이드 개발 노트: 커서와 관련된 성능 문제를 깊이 이해하다

데이터베이스에 대량의 데이터가 저장되어 있을 때,Cursor로 조회할 때 성능 문제를 일으킬 수 있으니 주의해야 한다.데이터베이스에서 조회된Cursor는 메모리 공간의 신청과 데이터 충전을 포함하여 하나의 Cursor Window로 데이터 관리를 한다.CursorWindow는 Cursor의 내용 크기에 대해 제한이 있습니다. 1024*1024로 제한하면 1M입니다. 다시 말하면 Cursor의 데이터 크기는 1M을 초과할 수 없습니다. 1M을 초과하면 다음과 같은 오류가 발생합니다.

 
  
08-23 05:48:31.838: DEBUG/Cursor(1805): skip_rows row 149 
  
08-23 05:48:31.844: ERROR/CursorWindow(1805): need to grow: mSize = 1048576, size = 11499, freeSpace() = 7397, numRows = 80 
  
08-23 05:48:31.844: ERROR/CursorWindow(1805): not growing since there are already 80 row(s), max size 1048576 
  
08-23 05:48:31.844: ERROR/Cursor(1805): Failed allocating 11499 bytes for blob at 228,7 
  
08-23 05:48:31.849: DEBUG/Cursor(1805): finish_program_and_get_row_count row 12 
  
08-23 05:48:31.851: DEBUG/browser/BrowserBookmarkFoldersAdapter(1805): getView()-Position:149 
  
08-23 05:48:32.019: DEBUG/Cursor(1805): skip_rows row 148 
  
 
 

커서윈도에 빈 공간이 부족해 새로운 공간을 신청하고 있지만 신청에 실패한 것 같다는 뜻이다.이 오류는 검색된 커서가 null일 수도 있고, 심각한 문제를 일으키지 않을 수도 있습니다.그러나 이는 성능상의 문제를 일으키고 끊임없이 신청 공간이 많은 CPU 시간을 차지해 휴대전화 전체가 카드로 변하게 만든다.특히 ListView나 GridView에 바인딩된 커서는 미끄러지지 않거나 10퍼센트의 카드가 미끄러질 수 있습니다.안드로이드 2.3의 원생 Browser, 그 중의 역사 기록을 열면 200개가 넘는 역사 기록이 있을 때 끊임없이 미끄러진다. 특히 아래에서 위로 미끄러질 때 10분의 카드가 된다. 그 책갈피에 대해 항목이 100개가 넘고 각각의 미리 보기 그림이 있을 때 미끄러지는 것은 특별한 카드가 되고 심지어 열리지 않는다.
이 문제는 근본적인 해법이 없다. 이것은 안드로이드 시스템의 제한이다. 유일하게 실행할 수 있는 방법은 피하는 것이다. 즉, 가능한 한 커서의 크기를 1M보다 작게 하는 것이다. 다음은 실행할 수 있는 방법이다.
1. 필요한 필드만 조회하는 것이 특히 중요하다. UI가 표시하는 필요나 실제 필요한 필드를 조회하는 것이다.꼭 Content Resolver를 줘야 돼요.query (uri, 프로젝트) 두 번째 매개 변수인 PROJECTION. 이 매개 변수가null이면 테이블의 모든 필드를 조회합니다. 줄 수가 늘어나면Cursor의 크기가 빠르게 증가합니다.Browser에 기록된 이유는 query에서 모든 필드를 조회했기 때문입니다. 라이브러리에favicon과thumbnail 바이너리 파일이 저장되어 있기 때문에 이 두 필드를 포함할 때Cursor의 용량은 쉽게 제한됩니다.
2. 바이너리 파일은 데이터베이스에 존재하지 않는다. 데이터베이스에 비교적 짧은 문자, 정수, 볼, 부동점수 등 일부 저장할 수 있고 조회와 조작이 쉬운 경량급 데이터만 저장할 수 있다. 목적도 빠른 검색과 조회에 있다.그림과 같은 긴 문자(예를 들어 글) 등 빅데이터는 하드디스크에 파일 형식으로 저장한 다음 데이터베이스에 접근 경로를 저장하는 것이 좋다.favicon과 같은 작은 그림도 데이터베이스에 존재하는 것을 고려할 수 있지만thumbnail의 그림은 현명하지 않다. 전체 응용 프로그램의 수량에 제한이 있지 않으면 조회할 때 1M의 제한에 도달하기 쉽다.
3. 특히 대량의 데이터가 5000급이나 만급 또는 10만급 또는 백만급을 초과할 경우 단계별로 조회해야 한다. 표에 기록된 데이터의 양이 아무리 작아도 항목 수가 5000급이나 만급 또는 그 이상일 때 1M의 제한에 도달할 때 단계별로 조회해야 한다. 예를 들어 매번 조회 500개, 또는 1000개가 필요하다.또 전시용으로 쓰려면 이렇게 많은 데이터가 한꺼번에 나오면 사용자들도 보기 불편하다.
[실례] 안드로이드 2.3 책갈피, 역사 기록과 최대 3개의 페이지를 방문할 때 데이터량이 300 정도에 이르면 미끄러지는 현상이 나타난다. 특히 아래에서 위로 미끄러질 때 특별한 카드가 쏟아진다.

 
  
08-23 05:48:31.844: ERROR/CursorWindow(1805): need to grow: mSize = 1048576, size = 11499, freeSpace() = 7397, numRows = 80 
  
08-23 05:48:31.844: ERROR/CursorWindow(1805): not growing since there are already 80 row(s), max size 1048576 
  
08-23 05:48:31.844: ERROR/Cursor(1805): Failed allocating 11499 bytes for blob at 228,7 
  
 
 

이런 로그.책갈피는 특별한 카드로 열고 미끄러질 수 없을 것 같다.그 이유는 그들이 검색할 때 모두 같은 필드 집합 Browser를 사용했기 때문이다.HISTORY_PROJECTION.책갈피, 역사 기록, 최대 방문은 세 개의 다른 전시 페이지이지만, 그들의 데이터는 모두 bookmarks표에서 나온 것이다.Bookmarks 테이블에 있음id,title,url,bookmark,favicon,touch_icon,thumbnail 등 필드에서favicon과thumbnail은 이진 이미지 데이터(byte[])입니다.Browser.HISTORY_PROJECTION에는 모든 필드가 포함되어 있고 물론favicon과thumbnail도 포함되어 있기 때문에 항목이 200여개가 되면 커서는 1M의 제한에 도달하기 때문에 성능이 떨어지고 슬라이딩이 끊긴다.
사실 역사 기록과 최대 두 페이지에 대한thumbnail과touchicon은 전혀 쓸모가 없어요. 그건id,title,url,bookmark와favicon;책갈피 페이지의 경우도 GRID에서만 thumbnail을 사용합니다.따라서 검색할 때의 필드 집합 Browser만 있으면 됩니다.HISTORY_PROJECTION에서 THUMBNAIL을 제거하면 슬라이딩 카드를 해결할 수 있습니다.