YYKit

YYWebImage: 1. SDWebImage가gif 그림을 재생할 때 메모리 사용량이 크게 줄어든다.SDWebImage에서gif에 대한 그림 처리는gif 그림의 모든 프레임을 그룹에 저장하고 UIImageView 대상에게 값을 부여하여 애니메이션을 재생하는 것입니다.배열에 저장된 UIImage 객체는 디코딩이 메모리 공간을 차지하지 않으며 화면에 구체적으로 재생될 때까지 디코딩되지 않습니다.예를 들어 한 gif 그림은 100 프레임이 있는데 UIImageView로 재생할 때 재생이 진행될수록 메모리가 계속 증가하고 순환 재생이 끝날 때까지 관찰할 수 있다.UIImageView는 배열 대상을 강하게 인용하기 때문에, 배열의 대상은 재생이 진행됨에 따라 끊임없이 디코딩되어 커다란 메모리 공간을 차지하기 때문에 방출할 수 없기 때문에 메모리가 폭발하기 쉽다.YYWebImage에서gif 그림을 재생합니다. 타이머 정책을 사용합니다.YYAnimatedImageView는 UIImageView의 하위 클래스입니다.사전으로gif 그림의 모든 프레임을 캐시합니다. 캐시 형식은

@{
  @1: UIImage,
  @2: UIImage.....
}

CADisplayLink 타이머를 이용하여 색인 값 1, 2, 3을 계속 바꾸고 캐시 사전에서 대응하는 UIImage 대상을 꺼내서 YYAnimatedImageView의layer에 값을 부여합니다.contents 속성으로 애니메이션을 생성합니다.캐시 사전 개체 내부의 UIImage가 디코딩되지 않았기 때문에 메모리 폭발 문제가 없습니다.이상의 설명은 틀렸다. 아래를 기준으로 SDWebImage는gif자원 중의 모든 이미지를 메모리에 기록하고 animatedImageWithImages 방식으로 애니메이션을 재생한다. 이렇게 하면 gif윤방할 때 메모리에서 자원을 직접 읽으면 되고 CPU의 사용을 낮추며 빈칸으로 유창도를 바꿀 수 있다. 그러나 동시에 불러오는 gif의 수량이 증가할 때 메모리 문제가 특히 뚜렷하게 드러날 수 있다.재생 시간은 총 시간을 채택하기 때문에 모든 사진이 평균 시간을 재생하기 때문에 재생 효과가 떨어진다.YYWebImage는 NSOperation 백엔드 스레드로 그림을 풀고 캐시합니다. 타이머로 캐시에서 그림을 읽고gif 그림을 재생합니다.이것은 반드시 CPU를 소모해야 하기 때문에 YYWebImage는 SDWebImage보다 CPU를 더 소모한다.메모리 사용 상황에 따라 캐시 그림 사전 데이터량을 제어하고 메모리를 제어합니다.타이머를 사용하기 때문에 모든 그림의 재생 시간은 기본적으로gif가 차지하는 시간이기 때문에 재생 효과가 좋다.
2. 인터랙티브 스캔을 실현하여 그림이 다운로드되지 않았을 때 더 좋은 효과를 나타낸다. 그림을 다운로드할 때 먼저 CGImageSourceCreateIncremental(NULL)으로 빈 그림 원본을 만들고 새 데이터를 얻을 때 CGImageSourceUpdateData(data,false)를 호출하여 그림 원본을 업데이트하고 마지막으로 CGImageSourceCreateImageAtIndex()로 그림을 만들어서 표시한다.SDWebImage는 이 방법으로 그림을 풀지 않았습니다. 사진 다운로드가 완료된 후 매우 갑작스럽게 나타나 효과가 떨어집니다.
3. 그림은 왜 표시하기 전에 디코딩을 해야 합니까?각 이미지 프레임워크는 이미지를 다운로드한 후 백엔드 라인에서 디코딩 작업을 하지만 디코딩을 하지 않아도 정상적으로 표시할 수 있다. 왜냐하면 시스템은 이미지가 표시될 때 자동으로 디코딩을 하기 때문이다.프레임워크가 사전에 서브스레드에서 디코딩을 하면 시스템이 자동으로 주스레드에서 디코딩을 하는 것을 피할 수 있기 때문에 이로 인해 주스레드가 막히고 플래시 등 현상을 초래할 수 있다.사전에 그림을 디코딩하면 그림의 메모리 사용량이 크게 증가할 수 있다.프레임워크에는 메모리와 디스크 캐시가 있고 큰 그림에 대해서는 메모리가 너무 크고 심지어 메모리를 방출하지 못해 발생하는 플래시 현상이 존재할 수 있다. 다음과 같은 방법으로 해결할 수 있다.

큰 그림에 대해 사전 압축 해제 작업을 금지하고 프레임은 모두 이 점을 고려했다. 하나의 속성은 NO로 설정하면 된다.

그림 메모리의 크기는 그림의 사이즈와 관계가 있기 때문에 스트레스를 풀기 전에 그림 등의 비율을 압축하면 차지하는 공간이 크게 줄어든다.

메모리 캐시를 수동으로 비우고 메모리 캐시 최대 용량 설정 등

YYModel: 1. 왜 효율이 높습니까?

모델의 구조는 일반적으로 고정되어 있기 때문에 실행할 때 모델 클래스와 부류의 모든 속성(property,method,setter/getter,type 등)을 캐시합니다.

속성 수식자(strong 등)와 type(NSArray 등)을 매거적으로 획득하는 것이 NSScanner보다 효율이 높다.

모델의 setter를 호출하여 모든 속성에 값을 부여하고 KVC보다 성능이 높습니다.

CF 프레임워크 함수를 많이 사용하여 성능이 향상되었습니다.

dispatch 사용semaphore_t 라인 안전 보장

YYCache: 1. 메모리 캐시 양방향 체인표와 CFMutable Dictionary Ref가 메모리에 협조하여 전자 처리 순서, 후자 처리 조회.LRU 알고리즘을 실현하여 가장 먼저 사용된 노드, 즉 체인 테이블 끝의 데이터를 도태시킨다.예를 들어 A, B, C, D 네 개의 데이터가 순서대로 있는데 CFMutable Dictionary Ref는 가장 빠른 조회 속도를 확보하고 체인 시계는 가장 빠른 이동 속도를 보장하여 C를 헤드로 이동한다. 이 두 가지는 천의무봉이다.메모리 경보나 사용자가 백엔드로 물러나면 서브라인 방출 대상 기술로 캐시 데이터를 정리한다. 이 기술 원리는 다음과 같다.

- (void)viewDidLoad {
    [super viewDidLoad];
    Person *p = [Person new];
    dispatch_async(dispatch_get_global_queue(0, 0), ^{
       [p class]
    });
}

예를 들어 정상적인 상황에서 p 대상은 메인 라인에서 방출되지만 하위 라인 Block으로 p 대상을 포획하면viewDidLoad가 실행된 후 Block은 마지막으로 p가 있는 장소이고 p는 하위 라인 runloop 운행이 끝날 때 방출되며 대상이 하위 라인에서 방출되는 목적을 달성하여 메인 라인 자원의 점용을 피한다.
2. 디스크 캐시 작은 파일(기본값은 20kb 이하)은 sqlite를 사용하고 큰 파일은 압축한 후에 파일을 쓰는 방식으로 저장하여 효율이 가장 높다.특히 sqlite 문장에 캐시를 했습니다.

- (sqlite3_stmt *)_dbPrepareStmt:(NSString *)sql {
    if (![self _dbCheck] || sql.length == 0 || !_dbStmtCache) return NULL;
    //  _dbStmtCache sqlite3_stmt
    sqlite3_stmt *stmt = (sqlite3_stmt *)CFDictionaryGetValue(_dbStmtCache, (__bridge const void *)(sql));
    if (!stmt) {
        //  
       sqlite3_prepare_v2(_db, sql.UTF8String, -1, &stmt, NULL);
        //  
        CFDictionarySetValue(_dbStmtCache, (__bridge const void *)(sql), stmt);
    } else {
        sqlite3_reset(stmt);
    }
    return stmt;
}

sqlite3_stmt: 이 대상의 표시는 이진 형식으로 컴파일되어 실행될 단일 SQL 문장입니다.이것을 캐시하면 sql문장이 이 실행 가능한 문장을 반복적으로 생성하는 비용을 피할 수 있고 성능이 최적화됩니다.큰 파일에 대해서는 파일 전체 부분을 파일 쓰기 방식으로 저장하고 sqlite로 이 파일의 기초 정보를 저장한다. 예를 들어 파일 경로, 파일 크기, 저장 시간 등이다.