[email protected]버 전 구체 적 인 핫 업데이트 메커니즘

열 갱신 원리

react - native 프로그램 은 실제 적 으로 원생 의 모듈 + JS 와 이미지 자원 모듈 이 고 열 업 데 이 트 는 바로 그 중의 js 와 이미지 자원 을 업데이트 하 는 것 이다.

안 드 로 이 드 프로그램 은 zip 압축 을 풀 면 bundle 파일 과 자원 파일 을 똑똑히 볼 수 있 습 니 다

.
핫 업데이트 방법
열 업 데 이 트 는 또 전체 업데이트 와 증분 업데이트 로 나 뉜 다.

전체 업 데 이 트 는 서버 에 가서 업로드 한 ppk 파일 을 직접 캡 처 하고 다운로드 하여 로 컬 ppk 파일 을 직접 덮어 쓰 는 것 입 니 다.

증분 업 데 이 트 는 bsdiff 알고리즘 을 사용 하여 두 bundle 간 의 차 이 를 비교 한 다음 에 다른 부분 만 수정 합 니 다.

프로그램 을 시작 할 때 서버 에 업데이트 가 필요 하 냐 는 요청 을 보 냅 니 다.URL： http://update.reactnative.cn/api/checkUpdate/${key} 가방 을 잡 든 소스 코드 를 보 든 결론 은 이 요청 을 사용 하여 json 의 key 값 을 업데이트 하여 app 에 맞 게 하 는 것 입 니 다.

{
    "upToDate": true,
    "ok": 1
}

이것 은 서버 가 나 에 게 되 돌려 준 값 입 니 다. 이미 최신 버 전이 라면 upToDate 를 되 돌려 줍 니 다.

{
    "expired": true,
    "downloadUrl":'xxx',
    "ok": 1
}

하 드 버 전 업데이트 가 필요 하 다 면 expired 의 인 자 를 되 돌려 주 고 downloadUrl (마음대로 쓴 것 일 수도 있 습 니 다. 구체 적 으로 는 이 이름 이 아 닐 수도 있 습 니 다. 게 으 르 면 버 전 을 지 워 보 겠 습 니 다) 의 인 자 를 주 십시오. 물론 이 인 자 는 제 가 그의 홈 페이지 에서 설정 한 것 입 니 다. 바로 제 새 버 전의 다운로드 주소 입 니 다.
이 럴 때 열 업데이트 가 필요 하 다 면 현재 버 전 [email protected] 의 대량의 데이터 시험 상황 을 보면 반환 형식 은 두 가지 가 있 습 니 다. 비록 소스 코드 에 세 번 째 가 있 지만.

{
    "update": true,
    "hash": "FppJ-yU8-_bvYJe5Sg5_opUp_eFH",
    "name": "0.2.1",
    "description": "test",
    "metaInfo": "0.2.1",
    "updateUrl": "http://update-packages.reactnative.cn/FppJ-yU8-_bvYJe5Sg5_opUp_eFH?e=1483510148&token=made75kGFhOozkiRfa7LK_E1xG1pLOnhW8fhbnev:t2YXoxZZXQImvvyHH1hdrnNNRmQ=",
    "pdiffUrl": "http://update-packages.reactnative.cn/lpKbEZnU6_T-mvwZGfzIQby489Bm-FppJ-yU8-_bvYJe5Sg5_opUp_eFH.pdiff?e=1483510148&token=made75kGFhOozkiRfa7LK_E1xG1pLOnhW8fhbnev:YBI4sdIEr30wa1DHV4xnMUlI1bU=",
    "ok": 1
}

update 는 true 로 열 업데이트 가 필요 하 다 는 뜻 입 니 다. 그 중 에 updateUrl 이라는 인자 가 있 습 니 다. 이 매개 변수 가 제공 하 는 주 소 는 전체 업데이트 주소 입 니 다. 제 전체 bundle 을 다운로드 할 것 입 니 다.또 하나의 매개 변 수 는 pdiffUrl 입 니 다. 이것 이 바로 증분 업데이트 입 니 다. 저 는 pdiff 파일 을 다운로드 한 다음 에 검 측 한 결과 안 드 로 이 드 상황 에서 cpu 가 이미 뛰 기 시 작 했 고 백 스테이지 프로그램 데이터 가 올 랐 지만 데이터 가 움 직 이지 않 았 습 니 다. 내부 계산 을 했 기 때문에 테스트 해 보 니 서로 다른 핸드폰 에서 도 표현 이 다르다 는 것 을 알 게 되 었 습 니 다.쿠 파이 A8930: 120 SViVioX 7: 90S 샤 오미 5: 75S.아이 폰 전 계열 휴대 전화 1S - 5S 사이.(눈대중 은 한 사람 이 쓴 코드 가 아니 거나 안 드 로 이 드 가 읽 고 쓴 스 레 드 에 문제 가 생 겼 습 니 다. 단지 추측 일 뿐 입 니 다) 이상 의 시간 은 시간 만 계산 하 는 것 입 니 다. 다운로드 증 가 량 이 몇 십 K 를 업데이트 하 는 것 도 1S 에 불과 하기 때 문 입 니 다.
서버 가 pdiffUrl 로 돌아 갈 지 여부 에 대해 서 는 공식 원 리 를 계산 할 수 없습니다. 같은 가방 이 있 기 때문에 가끔 은 pdiffUrl 로 돌아 갈 때 도 있 고, 어떤 때 는 updateUrl 만 있 을 때 도 있 습 니 다. 그러나 어떤 상황 에서 도 updateUrl 이 있 기 때문에 우 리 는 이 점 을 이용 하여 불필요 한 기다 림 을 고 칠 수 있 습 니 다.예 를 들 어 저 는 데이터 가 많 습 니 다. 저 는 안 드 로 이 드 기 계 를 100 S 를 기다 리 게 하고 싶 지 않 습 니 다. 백 스테이지 에서 조용히 업데이트 하고 싶 지 않 습 니 다. 그러면 바로 소스 코드 를 바 꾸 겠 습 니 다. 다행히 소스 코드 를 빨리 찾 아서 수정 하 는 것 이 더욱 쉽 습 니 다.

export async function downloadUpdate(options) {
  if (!options.update) {
    return;
  }

  if (options.diffUrl) {
    await HotUpdate.downloadPatchFromPpk({
      updateUrl: options.diffUrl,
      hashName: options.hash,
      originHashName: currentVersion,
    });
  } else if (options.pdiffUrl) {
    await HotUpdate.downloadPatchFromPackage({
      updateUrl: options.pdiffUrl,
      hashName: options.hash,
    });
  } else {
    await HotUpdate.downloadUpdate({
      updateUrl: options.updateUrl,
      hashName: options.hash,
    });
    
  }
  return options.hash;
}

이것 이 바로 증분 업데이트 여 부 를 판단 하 는 코드 입 니 다. 그 중에서 diffUrl 은 본 적 이 없어 서 논 리 를 움 직 이지 않 기 때문에 간단 합 니 다. 증분 과 전량 을 순 서 를 바 꾸 면 됩 니 다.

export async function downloadUpdate(options) {
  if (!options.update) {
    return;
  }

  if (options.diffUrl) {
    await HotUpdate.downloadPatchFromPpk({
      updateUrl: options.diffUrl,
      hashName: options.hash,
      originHashName: currentVersion,
    });
  } else if (options.updateUrl) {
    await HotUpdate.downloadUpdate({
      updateUrl: options.updateUrl,
      hashName: options.hash,
    });
  } else {
    await HotUpdate.downloadPatchFromPackage({
      updateUrl: options.pdiffUrl,
      hashName: options.hash,
    });
  }
  return options.hash;
}

해결 해 보 니 안 드 로 이 드 는 서버 가 저 에 게 pdiffUrl 을 주 었 음 에 도 불구 하고 저 는 전체 업 데 이 트 를 선택 할 것 입 니 다. 네, 3M 트 래 픽 만 들 었 습 니 다. 하지만 모두 무선 네트워크 이기 때문에 20S 이내 에 이 핫 업 데 이 트 는 분명 좋 을 것 입 니 다. 그렇게 오래 기다 릴 필요 가 없습니다.
문제.

이 index. js 파일 에 Ios 와 안 드 로 이 드 가 구분 되 지 않 은 것 을 발 견 했 습 니 다. 그래서 제 가 ios 를 원래 의 논리 로 보 내 려 면 판단 이 필요 하기 때문에 나중에 테스트 를 해 보 겠 습 니 다.

bsdiff 알고리즘 을 사용 한 후, 다운로드 주소 의 ipa 가방 도 좋 고, apk 가방 도 좋 으 며, 반드시 update. reactnative. cn 의 가방 과 완전히 일치 해 야 한 다 는 것 을 명심 하 세 요.그렇지 않 으 면 처음으로 증분 업데이트 가 시작 되면 축하합니다. 무한 재 부팅.왜 이런 문제 가 발생 했 는 지, 나의 추측 은:

(update. cn 의 가방 은 7 번 입 니 다. 사용자 에 게 다운로드 주소 에 있 는 가방 은 8 번 입 니 다. 8 번 의 프로그램 내용 은 7 번 보다 몇 가지 문안 수정 만 더 있 었 습 니 다. 이때 제 가 열 업 데 이 트 를 보 냈 습 니 다. 이름 은 10 번 입 니 다. 그러면 그 계산 방식 은 원래 10 번 에서 7 번 을 뺀 = 3 입 니 다. 그리고 이 3 을 들 고 7 = 10 을 더 하면 업데이트 에 성 공 했 습 니 다. 하지만 당신 이 가지 고 있 는 가방 은 8 입 니 다. 그 는 1 을 들 었 습 니 다.0 - 7 = 3, 3 + 8 은 = 11! = 10. boom 폭발. 11! = 10, 무한 열 업데이트. 하지만 영원히 맞지 않 습 니 다. 그래서 무한 재 부팅) 괄호 내용 은 추측 일 뿐 공식 과 소통 하지 않 았 습 니 다.