LoaderManager 사용 설명 (1) --- Loader 이전의 세계 가 없습니다.

원본:
http://www.androiddesignpatterns.com/2012/07/loaders-and-loadermanager-background.html
작가 님 감사합니다.
Alex Lockwood 의 노력 은 우리 에 게 이렇게 멋 진 글 을 보 여 주 었 다.
제1 부분 Loader 이전의 세상 이 없어 요.
이 부분 은 Loaders 와 Loader Manager 에 대해 간략하게 소개 할 것 입 니 다.1 절 은 안 드 로 이 드 3.0 이전에 데 이 터 를 어떻게 불 러 와 결함 을 지적 할 것 이다.2. 각 유형의 목적 과 데 이 터 를 비동기 로 불 러 오 는 능력 을 말한다.
이 글 은 Loaders 와 LoaderManager 에 관 한 일련의 글 의 시작 입 니 다. 이 시 리 즈 는 다음 과 같 습 니 다.
전 세계
2: LoaderManager 알 아 보기
3: 실현 Loaders
4: 실례: AppListLoader
Loaders 와 Loader Manager 에 대해 전혀 모른다 면 계속 읽 기 전에 Loaders 가 이 드 를 읽 어 보 는 것 을 강력 히 권장 합 니 다.
이전 상황
Android 3.0 이전에 많은 응용 프로그램의 응답 성능 에 결함 이 있 었 다.UI 전환 사이 의 작은 고장, activity 전환 지연, ANR 문제.응답 성능 의 고장 은 대부분 이 사실 에서 비롯 됩 니 다. - 대부분의 개발 자 들 이 UI 스 레 드 에서 조회 작업 을 실 행 했 습 니 다. 이런 방식 으로 데 이 터 를 불 러 오 는 것 이 최 악의 선택 입 니 다.
이 글 은 신속 한 피드백 을 강조 하면 서 안 드 로 이 드 3.0 이전 API 는 이 기능 을 지원 하지 않 은 것 으로 보인다.Loaders 이전에 cursor 는 주로 두 가지 Activity 방법 (현재 시간 이 지 났 습 니 다 deprecated) 을 통 해 관리 하고 조회 합 니 다.
 
public void startManagingCursor(Cursor)
activity 에 게 자신의 생명 주기 에 따라 cursor 의 생명 주 기 를 관리 하 라 고 알려 줍 니 다.cursor 는 활성 stopped 가 활성 화 될 때 자동 으로 deactivate () 가 됩 니 다.이벤트 가 무 너 질 때 자동 으로 close () 됩 니 다.이벤트 stopped 를 한 후에 다시 restarted 를 하면 cursor 는 re - queried (requery ()) 에서 최신 데 이 터 를 다시 조회 합 니 다.
public Cursor managedQuery(Uri, String, String, String, String)
이 함 수 는 ContentResolver 의 query () 방법 에 대한 포장 입 니 다.query 를 실행 하 는 것 외 에 도 되 돌아 오기 전에 startManagingCursor (cursor) 를 호출 합 니 다.즉, 이 query 의 cursor 를 activity 수명 주기 관리 에 넣 었 다 는 것 이다.
사용 하기에 편리 하면 서도 위의 방법 은 UI 스 레 드 에서 조회 작업 을 수행 할 때 심각 한 지연 문 제 를 일 으 킬 수 있 습 니 다.또한 이 'managed cursors' 방식 은 activity 설정 변화 (configuration changed, 가로 세로 화면 전환, 키보드 팝 업 등) 시 데 이 터 를 유지 하지 않 습 니 다.이러한 상황 에서 requry () 데 이 터 를 다시 시작 하지만 실제로는 필요 없고 효과 가 적 으 며 방향 전환 이 정체 되 고 멈 출 수 있다.
질문
간단 한 코드 에서 managed cursors 문 제 를 모 의 합 니 다.아래 에 제 공 된 코드 는 ListActivity 에서 데 이 터 를 불 러 오 는 것 으로 Android 3.0 이전의 API 를 사용 합 니 다.이 활동 은 ContentProvider 에서 데 이 터 를 조회 하고 되 돌아 오 는 cursor 를 관리 합 니 다.검색 결 과 는 Simple Cursor Adapter 로 포장 되 어 listview 에 표 시 됩 니 다.코드 정련 은 다음 과 같 습 니 다:

public class SampleListActivity extends ListActivity {

  private static final String[] PROJECTION = new String[] {"_id", "text_column"};

  @Override
  protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);

    // Performs a "managed query" to the ContentProvider. The Activity 
    // will handle closing and requerying the cursor.
    //
    // WARNING!! This query (and any subsequent re-queries) will be
    // performed on the UI Thread!!
    Cursor cursor = managedQuery(
        CONTENT_URI,  // The Uri constant in your ContentProvider class
        PROJECTION,   // The columns to return for each data row
        null,         // No where clause
        null,         // No where clause
        null);        // No sort order

    String[] dataColumns = { "text_column" };
    int[] viewIDs = { R.id.text_view };
 
    // Create the backing adapter for the ListView.
    //
    // WARNING!! While not readily obvious, using this constructor will 
    // tell the CursorAdapter to register a ContentObserver that will
    // monitor the underlying data source. As part of the monitoring
    // process, the ContentObserver will call requery() on the cursor 
    // each time the data is updated. Since Cursor#requery() is performed 
    // on the UI thread, this constructor should be avoided at all costs!
    SimpleCursorAdapter adapter = new SimpleCursorAdapter(
        this,                // The Activity context
        R.layout.list_item,  // Points to the XML for a list item
        cursor,              // Cursor that contains the data to display
        dataColumns,         // Bind the data in column "text_column"...
        viewIDs);            // ...to the TextView with id "R.id.text_view"

    // Sets the ListView's adapter to be the cursor adapter that was 
    // just created.
    setListAdapter(adapter);
  }
}

위의 코드 는 세 가지 문제 가 있다.만약 네가 위 에서 말 한 내용 을 읽 었 다 면, 두 문 제 를 시작 하 는 것 은 어렵 지 않 을 것 이다.
1. managedQuery 는 Ui 스 레 드 에서 조회 작업 을 실 행 했 습 니 다. 이 로 인해 응답 이 없 을 것 입 니 다. 이 방법 은 더 이상 사용 하지 말 아야 합 니 다.
2. Activity. java 소스 코드 를 보면 managed Query 도 startManagingCursor 를 호출 하여 조회 한 데 이 터 를 관리 하 는 것 을 알 수 있 습 니 다.cursor 의 후속 종료, requery 등 을 고려 하지 않 아 도 되 기 때문에 간편 해 보 입 니 다.그러나 이러한 방식 을 사용 하면 activity 의 상태 가 stopped 에서 돌아 올 때마다 데 이 터 를 다시 조회 해 야 하기 때문에 UI 스 레 드 가 끊 길 수 있 습 니 다.activity 가 cursor 를 관리 하 는 데 발생 하 는 위험 이 편리 성 보다 큽 니 다.
3. 32 줄 의 Simple Cursor Adapter 구조 방법 이 시대 에 뒤떨어 졌 으 니 더 이상 사용 하지 말 아야 합 니 다.이 구조 방법의 문 제 는 변 경 될 때 Simple Cursor Adapter 가 자동 으로 조회 하 게 된다 는 것 이다.구체 적 으로 Cursor Adapter 는 데이터 에 ContentObserver 모니터 를 등록 하고 감청 데이터 가 변 할 때 requery 데 이 터 를 등록 합 니 다.표준 구조 함 수 를 사용 해 야 합 니 다.만약 네가 세 번 째 조항 을 이해 하지 못 한다 면, 괜찮아, 이것 은 단지 작은 잘못 일 뿐이다.
Android 태 블 릿 기기 의 발 표 는 UI 우호 성 을 강화 해 야 합 니 다 (반응 이 빠 릅 니 다).더 큰 설비, 7 ~ 10 인치 평판 의 응용 이 더욱 복잡 하고 상호작용 이 많 으 며 더 많은 인터페이스 구 조 를 가진다.다음은 Fragment, fragment 를 소개 하여 응용 을 더욱 동적 이 고 더 많은 이벤트 구동 을 할 것 입 니 다.데 이 터 를 불 러 오 는 간단 한 단일 스 레 드 방법 은 분명히 더 이상 적합 하지 않다.그래서 이것 이 바로 Loader 와 Loader Manager 가 Android 3.0 에서 탄생 한 배경 이다.
Android3.0，Loaders， LoaderManager
Honeycomb 이전에 cursors 의 작업 을 관리 하기 가 쉽 지 않 습 니 다. 예 를 들 어 UI 스 레 드 에서 정상적으로 동기 화 되 어 모든 조회 가 배경 스 레 드 에서 적시에 실 행 될 수 있 도록 합 니 다.Android 3.0 은 이 과정 을 간소화 하기 위해 Loader 와 LoaderManager 류 를 도입 했다.ASL (Android Support Library) 을 사용 해 Android 1.6 이상 시스템 에서 이 두 종 류 를 구현 할 수 있다.
새로운 Loader API 는 커 다란 발전 이 고 사용자 체험 의 커 다란 발전 이다.Loaders 는 모든 cursor 작업 이 비동기 적 인 것 을 확보 하여 UI 스 레 드 에서 막 힐 가능성 을 제거 합 니 다.그리고 LoaderManager 를 통 해 관리 할 때 Loaders 는 activity 인 스 턴 스 에서 현재 cursor 데 이 터 를 유지 할 수 있 습 니 다. 즉, 다시 조회 할 필요 가 없습니다 (예 를 들 어 가로 세로 화면 전환 으로 activity 를 다시 시작 해 야 할 때).데이터 가 바 뀌 었 을 때 Loaders 는 바 텀 데이터 의 업데이트 와 재 검색 을 똑똑 하 게 감지 할 수 있다.
총결산
허 니 콤 의 로 더 스 와 라 이브 러 리 가 생 긴 이후 안 드 로 이 드 애플 리 케 이 션 은 더욱 좋아 졌 다.현재 startManagingCursor 와 managed Query 를 사용 하 는 것 은 매우 적합 하지 않 습 니 다. 프로그램 을 느리게 만 들 뿐만 아니 라 프로그램 이 카드 로 죽 을 가능성 도 있 습 니 다.다른 한편, Loaders 는 데 이 터 를 불 러 오 는 작업 을 단독 배경 프로 세 스에 맡 기 면 사용자 체험 을 뚜렷하게 향상 시 킬 수 있다.