Glide 단순 프로 세 스 분석

전 재 는 주 소 를 명시 해 주 십시오 QuincySx:http://www.jianshu.com/p/cf8f8f90f621
이 글 은 이 시리즈 의 첫 번 째 글 입 니 다. 저 는 처음으로 이런 연속 적 인 글 을 썼 습 니 다. 저 는 먼저 글 라 이 드 를 한 층 씩 벗 기 고 더 좋 은 생각 이 있 으 면 제 기 를 환영 합 니 다.
이 편 은 Glide 코드 를 많이 붙 여 대조 분석 하지 않 았 고 가장 간단 한 절차 일 뿐 입 니 다.
이 글 을 읽 으 면 당신 은 무엇 을 얻 을 수 있 습 니까? 이 글 은 Glide 의 기본 적 인 운영 절 차 를 볼 수 있 을 것 입 니 다.
Glide 의 기본 용법 은 전체 문장 이 이 코드 환경 에 따라 설명 된다.

Glide.with(Activity).load(Url).into(ImageView);

각 프로 세 스 대상 의 전환
일단 글 라 이 드 의 각 프로 세 스에 서 의 대상 전환 에 대해 서 말씀 드 리 겠 습 니 다.

우선 with () 방법 을 호출 하면 RequestManager 라 는 대상 을 되 돌려 줍 니 다

그리고 load () 를 호출 하면 Drawable TypeRequest 대상 으로 돌아 갑 니 다. 그러나 이 대상 은 GenericRequestBuilder 대상 에서 계승 되 는 것 을 주의해 야 합 니 다. 단어의 의미 에서 볼 때 이 대상 은 '유 니 버 설 요청 생 성기' 를 생 성 하 는 것 입 니 다. 사실은 그의 의미 와 똑 같은 역할 을 합 니 다 (Glide 작가 에 게 칭찬 을 해 야 합 니 다)

그리고 init () 방법 을 호출 하면 ViewTarget 을 구축 한 다음 에 자원, 캐 시, 캐 시 읽 기, 변환 등 처 리 를 시작 하여 ImageView 위 에 놓 습 니 다

각 단계 에서 하 는 일 을 구체 적 으로 분석 하 다.
구체 적 으로 각 아래 의 각 절 차 를 분석 하 다.
방법
이 방법 은 현재 Activity 에 Fragment 를 추가 하고 라 이 프 사이클 모니터 를 등록 하여 RequestManager 를 구축 하 는 것 입 니 다. Glide 가 초기 화 되 지 않 으 면 Glide 를 초기 화 합 니 다.

with () 이 방법 은 여러 가지 무 거 운 짐 이 있 습 니 다. 하지만... 신경 쓰 지 마 세 요. 그 가 무엇이든 하 는 일 을 골 라 서 말씀 드 리 겠 습 니 다 with(FragmentActivity activity). 방법 에서 호출 RequestManagerRetriever.get() 하면 Request Manager Retriever (이런 작업 은 RequestManager 제공) 의 단일 예 를 얻 고 호출 RequestManagerRetriever.get() 방법 을 얻 을 수 있 습 니 다.Fragment Activity 의 Fragment Manager 대상 을 가 져 옵 니 다. (방법 에 따라 가 져 올 수 있 는 방법 이 다 를 수 있 습 니 다. 여기 서 우 리 는 이것 을 직접 말 하고 다른 것 은 스스로 소스 코드 를 볼 수 있 습 니 다) 그리고 Support Request Manager Fragment 를 현재 Activity 에 추가 합 니 다.(이 Fragment 를 추가 하 는 목적 은 현재 Activity 의 생명 주 기 를 감청 하기 위해 서 입 니 다. 여기 서 생명 주 기 를 감청 하 는 역할 은 이미지 자원 의 획득, 전환 하 는 임 무 를 신속하게 취소 하고 성능 의 낭 비 를 방지 하 는 것 입 니 다) 그리고 Fragment 의 감청 기 를 꺼 내 RequestManager 를 구성 한 다음 에 RequestManager 를 Fragment 에 넣 습 니 다.(뒤의 몇 가지 방법 은 내 가 이름 을 말 하지 않 고 무엇 을 실 현 했 는 지 만 말 하면 소스 코드 를 보면 알 수 있다)

RequestManager 를 구성 할 때 하나의 Glide 를 가 져 옵 니 다. Glide 가 초기 화 되 지 않 으 면 Glide Builder 를 통 해 Glide 를 구축 하고 캐 시, 스 레 드 풀, 전환, 자원 획득 과 전환 제어 류 등 을 완성 한 다음 new 를 사용 하여 Glide

를 호출 합 니 다.

Glide 의 구조 방법 에 감청 과 같은 공급 자, 서로 다른 유형의 ModelLoader, 등록 변환 류 등 을 등 록 했 습 니 다. (이 방법 은 무엇 을 하 는 지 모 르 겠 습 니 다. 블 로 그 를 업데이트 할 것 입 니 다)

그러면 Manifest 의 안쪽 value 가 'GlideModule' 인 모든 meta - data 라벨 을 읽 고 key 를 가 져 와 반사 적 으로 GlideModule 을 가 져 온 다음 GlideModule.registerComponents() 방법 으로 ModelLoader 를 Glide 에 등록 하고 같은 유형의 ModelLoader 를 교체 합 니 다.(왜 같은 유형의 ModelLoader 를 교체 하 는 것 이 라 고 말 할 수 있 습 니까? load () 는 과부하 가 많 기 때 문 입 니 다. 유형 에 따라 서로 다른 유형의 ModelLoader 를 하나의 Map 에 넣 고 해석 하고 사용 합 니 다. 구체 적 으로 into 까지 자세히 설명 합 니 다) 이런 방식 을 통 해 우 리 는 외부 에서 자신의 해석 기 를 제공 할 수 있 습 니 다

Connectivity Monitor 는 네트워크 상태 에서 가 져 올 수 있 는 권한 이 있 는 지 판단 한 다음 Fragment 의 모니터 에 네트워크 모니터 를 넣 을 지, 아니면 빈 모니터 를 넣 을 지 선택 합 니 다. 현재 APP 가 네트워크 상 태 를 가 져 올 수 있 는 권한 이 있 으 면 네트워크 가 바 뀔 때 임 무 대기 열 을 호출 하여 작업 을 다시 시작 합 니 다

load 방법 은 String 인자 와 URL 주 소 를 분석 합 니 다.
이 방법 은 들 어 오 는 매개 변수 유형 에 따라 해당 하 는 ModelLoader 로 돌아 가 요청 대기 열, Activity 수명 주기 모니터 등 을 유지 하고 DrawableTypeRequest 대상 을 구축 하 는 것 이 주요 기능 입 니 다.
1. fromString() 에서 RequestManager.loadGeneric(Class modelClass) 방법 으로 GenericRequestBuilder 류 를 얻 으 면 이 방법 은 무엇 을 했 을 까?

먼저 Glide.buildStreamModelLoader() 방법 을 호출 한 다음 에 방법 에서 호출 buildModelLoader(modelClass, InputStream.class, context) 한 다음 에 방법 에서 호출 Glide.get(context).getLoaderFactory().buildModelLoader(modelClass, resourceClass) 하면 그 는 현재 Glide 에서 ModelLoader 의 공장 을 얻 을 것 이다.(GenericLoader Factory 라 는 클래스 에는 완전한 ModelLoader 목록 과 캐 시 된 ModelLoader 가 저장 되 어 있 습 니 다. 이 클래스 는 Glide 의 구조 방법 에서 new 로 나 온 것 입 니 다. Glide 를 따라 하나의 예 로 들 수 있 습 니 다) 를 가 져 온 후 공장 을 호출 합 니 다 buildModelLoader()이 방법 에서 그 가 먼저 캐 시 를 가 져 온 ModelLoader 가 없 으 면 전체 ModelLoader 목록 을 읽 어서 ModelLoader 를 가 져 오고 이 ModelLoader 를 캐 시 한 다음 에 사용 할 때 빠르게 읽 을 수 있 습 니 다

.

호출 Glide.buildFileDescriptorModelLoader(modelClass, context) 방법 을 사용 한 다음 에 이 방법 에서 buildModelLoader(modelClass, ParcelFileDescriptor.class, context) 이전 단계 와 같은 방법 을 사용 하고 한 유형 에 들 어 갔다. 구체 적 으로 말 하지 않 고 절차 가 같다

.

세 번 째 단 계 는 new Drawable TypeRequest 대상

을 구축 합 니 다.
2. loadGeneric () 호출 완료, load 방법 으로 돌아 가면 Drawable RequestBuilder 를 호출 합 니 다 load(ModelType model)방법, 일반적인 파 라 메 터 를 저장 합 니 다. 우리 의 분석 환경 에서 String 유형 입 니 다. 지금까지 Drawable TypeRequest 는 구축 되 었 습 니 다. 그 는 Drawable Request Builder 에서 계승 되 었 고 GenericRequest Builder 에서 계승 되 었 습 니 다. 다음 단 계 는 이러한 유형 과 밀접 한 관 계 를 가 집 니 다.
into 방법
이 방법 은 비교적 중요 하 다.

into (ImageView view) 방법 을 호출 합 니 다. 그 는 먼저 그림 표시 방식 을 판단 한 다음 에 서로 다른 변환 을 설정 한 다음 에 buildImageViewTarge() 방법 을 호출 합 니 다. 방법 에서 ImageView TargetFactory. buildTarget (Class clazz) 방법 을 호출 하여 ViewTarget (ImageViewTargetFactory 류 도 Glide 초기 화 할 때 생 성 되 었 습 니 다. buildTarget ()방법 중의 clazz 인 자 는 DrawableTypeRequest 의 부모 클래스 DrawableRequestBuilder 의 구조 에 들 어 가 는 것 은 GlideDrawable. class 이기 때문에 이 switch 문 구 는 최종 적 으로 GlideDrawableImageViewTarget 류 를 얻 었 습 니 다. 이런 구조 도 저 장 된 것 일 뿐 View 는 이때 깊이 연구 할 필요 가 없습니다

ViewTarget 구축 완료 후 호출 into(Y target) 방법 (Y extends Target) 을 사용 하여 현재 메 인 스 레 드 인지 아 닌 지 판단 하고, 그렇지 않 으 면 카 라 카 를 뛰 어 넘 어야 합 니 다. 그리고 TargetView 에서 Request 가 있 으 면 멈 추고 제거 합 니 다. buildRequest()방법 은 Request 를 가 져 와 ViewTarget 에 추가 하고 RequestTracker 대기 열 에 추가 하 며 감청 중 입 니 다. 이 단계 의 원본 코드 는 제 가 붙 여 놓 겠 습 니 다. 맨 아래 를 보 겠 습 니 다

세 번 째 단 계 는 다음 소스 세 션 buildRequest(target) 을 사용 합 니 다. 이 방법 은 사용자 가 Request 의 스 레 드 우선 순 위 를 설정 하지 않 으 면 기본 값 (이곳 Glide 의 기본 스 레 드 우선 순 위 는 UI 스 레 드 보다 낮 습 니 다. 그 는 음향 UI 스 레 드 를 두려워 하고 특별한 요구 가 없 으 면 변경 하지 말 라 는 것) 을 사용 한 다음 호출 buildRequestRecursive()이 방법 은 먼저 사용자 가 불 러 온 자원 을 설정 한 적 이 있 는 지 여 부 를 판단 하 는 것 이 그림 의 미리 보기 그림 (저 배 판 그림) 입 니 다. 다음 두 가지 판단 은 모두 미리 보기 그림 과 관계 가 있 습 니 다. 만약 에 우리 문맥 환경, 즉 가장 간단 한 절차 에 따라 그 가 가 는 것 은 else 호출 obtainRequest() 방법 입 니 다. 방법 에서 다시 호출 GenericRequest.obtain() 합 니 다.GenericRequest 를 구축 하 는 과정 은 물론 이 고 여러분 이 직접 보 세 요

네 번 째 단계 RequestTracker.runRequest(request) 는 단어의 의미 에서 볼 때 요청 을 시작 하 는 것 입 니 다. 실제 적 으로 이 방법 이 Request 를 실행 하 는 것 이라는 것 만 알 면 됩 니 다.방법 은 Request 의 상 태 를 바 꾸 고 호출 Request.begin() 방법 으로 Request 의 상 태 를 다시 수정 하여 각종 로 더 를 가 져 옵 니 다. 호출 onSizeReady() (이 클래스 와 방법의 역할 은 캐 시 를 제어 하여 자원 을 가 져 오 는 등 작업 입 니 다. 다음 편 에 서 는 자세히 설명 하 겠 습 니 다) load 측 법 에 리 셋 인터페이스 가 있 습 니 다. 그 가 전달 하 는 것 은 this 입 니 다. 그 는 계속 호출 Engine.load() 할 것 입 니 다.이 방법 은 들 어가 서 기능 을 볼 수 있 습 니 다. 바로 자리 잡 은 그림 을 View 에 불 러 옵 니 다. 우 리 는 다시 target.onLoadStarted(getPlaceholderDrawable()); 안 을 보 러 갑 니 다. 그 가 불 러 오 는 데 성공 할 때 리 셋 Engine.load() 방법 입 니 다. 우리 가 리 셋 한 것 은 this 이기 때문에 리 셋 했 습 니 다 onResourceReady(Resource> resource) 그 는 자원 을 ImageView 에 불 러 옵 니 다.

Request request = buildRequest(target);
target.setRequest(request);
lifecycle.addListener(target);
requestTracker.runRequest(request);

작은 매듭
나 자신 은 이런 종류의 라 이브 러 리 를 읽 어 본 적 이 없다. 나 는 모두 github 에 사용 되 는 라 이브 러 리 를 보 았 다. 할 일이 없 으 면 간단하게 보 았 다. 소감 을 말 해 보 자. 나 는 처음에 Glide 를 보고 싶 을 때 좀 두 려 웠 다. 어떻게 손 을 써 도 읽 을 수 없 을 까 봐 소스 코드 를 다운로드 해서 간단하게 보 았 다. 내 가 읽 은 생각 은 바로 이 라 이브 러 리 의 입문 용법 GenericRequest.onResourceReady() 이다.가장 쉬 운 문 구 는 천천히 보 세 요. 그 가 어떻게 전환 하 는 모든 절 차 를 어떻게 가 는 지 보 세 요. 만약 에 정리 가 잘 되 지 않 으 면 Debug 디 버 깅 에 의존 해서 그 를 따라 갈 수 있 습 니 다. 저도 몇 번 을 보고 나 서 야 실 마 리 를 찾 았 습 니 다. 견지 해 야 이 길 수 있 습 니 다. 인터넷 에서 그들 이 이틀 을 읽 었 으 니 차이 가 많 지 않 습 니 다. 우 리 는 비교 할 수 없습니다. 4, 5 일 을 보고 나 서 야 실마리 가 잡 혔 습 니 다. 천천히 보 세 요.좋아, 버 티 면 승리 야!!!
저의 이 해 는 아직 좀 천박 하고 문장 쓰기 에 도 익숙 하지 않 습 니 다. 여러분 의 질문 을 환영 합 니 다.