APP 에서 캐싱, 로드 및 새로 고침 메커니즘 설계 및 구현

장면 1: 서버에서 새 데이터를 요청하면서 기다립니다. 우리는 사용자에게 무엇을 보여줍니까? 첫 번째는 로드를 기다리는 아름다운 페이지입니다. 두 번째는 캐시된 내용입니다. 둘째, 사용자는 페이지를 조작하면서 오래된 데이터를 보고, 새 데이터를 기다리며, "운영 가능성" 과 "가용성" 을 높여 서버에서 데이터를 가져오는 크기와 시간을 줄이고 사용자 경험을 향상시킬 수 있습니다. 반면, 컨텐츠 업데이트 간격이 길거나 사용자 업데이트 간격이 짧으면 캐시 없이 서버에서 많은 양의 데이터를 반복적으로 가져와 비용을 증가시킵니다.

시나리오 2: 그 결과 인터넷 연결이 없거나 지하철에 인터넷이 너무 나빠서 데이터를 로드할 수 없을 때 사용자에게 빈 페이지를 남기는 것은 정말 무책임하다. 또한 APP 의 주소록, 채팅 기록 보기, 알림 정보, 문장 목록 등 많은 기능을 네트워크에 연결하지 않고도 사용할 수 있습니다. 사용자가 APP 를 열면 새 정보를 볼 필요가 없고 이전 정보 (일부 이전 정보 사용자가 보지 못했을 수도 있음) 를 다시 볼 수 있으므로 적절한 캐싱으로 더 많은 사용자 장면을 만족시킬 수 있습니다.

시나리오 3: 돈 어느 날, 한 사용자가 앱을 설치했다는 것을 알게 되었고, 트래픽은 매우 빠르게 사용되었습니다. Ta 는 이 앱을 영원히 냉궁에 넣을 수 있으며, 캐시를 늘리는 것은 트래픽을 절약하는 한 가지 방법이다. 절약이 많지 않거나 사용자가 의식하지 못하지만, 태도가 있는 제품 매니저로서 더 많은 생각을 해야 한다.

2. 캐시란 무엇입니까?

캐시는 다음 범주로 나눌 수 있습니다.

(1) 캐시를 적용합니다.

(2) 고정 캐시.

(3) 수동으로 정리할 수 있는 캐시.

(4) 수동으로 정리할 수 없는 캐시.

(5) 임시 캐시.

이 중 한 기능 페이지에서 임시 캐시를 사용하여 각 열의 캐시를 보관하는 경우가 많습니다. 같은 함수 내에서 하위 함수는 여러 열로 나뉘며, 이번 사용에서 각 탭 열 아래의 내용은 임시 캐시로 저장할 수 있습니다. 이 함수에서 데이터를 다시 로드하지 않고 열을 토글하고 캐시 표시를 사용합니다.

사용자의 경우 브라우징은 사용 중 원활하게 전환할 수 있으며 서버의 경우 짧은 시간 내에 데이터가 업데이트되지 않으므로 전반적으로 사용자의 정상적인 요구를 충족하고 우수한 사용 환경을 얻을 수 있습니다. (데이비드 아셀, Northern Exposure (미국 TV 드라마), Northern Exposure (미국 TV 드라마), 성공명언)

임시 캐시 정리 메커니즘은 이 기능 모듈을 종료한 후 이전 캐시를 지우는 것입니다. 즉, 다음에 이 기능 모듈에 들어가면 데이터를 다시 가져와야 합니다.

우리는 임시 캐시를 자주 사용한다. 정보가 정말 그렇게 중요하지 않기 때문에 반복적인 검사가 필요하지 않기 때문이다. 우리가 자주 사용하는 정보에 대해 반복적으로 검사해야 하는 정보에 대해, 말은 우리에게 고정 캐시를 가져와 로컬에 보관하라고 건의하며, 다음에 탐색할 때 더 이상 서버에 데이터를 요청할 필요가 없다.

고정 캐시의 경우 수동 정리 가능 캐시와 수동 정리 불가능 캐시로 세분화됩니다.

첫 번째는 우리가 가장 흔히 볼 수 있는 캐시로, 거의 모든 제품에 채택된다. 일반적으로 사용자가 문장 및 아틀라스를 탐색하여 로드한 데이터는 이 형식으로 로컬에 캐시되므로 다음에 이 문장 및 아틀라스를 다시 볼 때 로드할 필요가 없습니다. 이러한 캐시를 수동으로 지워서 공간을 확보할 수도 있습니다.

상대적으로 고정 된 데이터와 같은 일부 특수 시나리오의 경우 처음부터 App 에 포장하고 싶지 않습니다. 너무 많은 용량을 차지하여 패키지가 커지거나 페이지를 입력 할 때마다 서버에 정보를 로딩하고 싶지 않습니다. 우리가 무엇을 할 수 있을까요? 제안된 해결책은 한 번 로드하여 로컬에 영구적으로 보관할 수 있다는 것입니다. 이렇게 하면 설치 패키지가 크지 않아 나중에 로드할 필요가 없습니다. (데이비드 아셀, Northern Exposure (미국 TV 드라마), 예술명언)

3. 캐시를 지우려면 어떻게 해야 합니까?

일반적으로 App 는 설정에서 캐시를 지우는 기능을 제공하고 한 번의 클릭으로 공간을 확보합니다. 또한 App 는 두 가지 차원으로 설계할 수 있는 자동 정리 메커니즘을 설계하는 것이 좋습니다.

(1), 시간

고정 시간을 설정하거나 사용자의 사용 주기에 따라 시간을 유연하게 설정하여 캐시를 비웁니다. 각 제품의 장면은 다르며 사용자의 사용 빈도도 다릅니다. 이 메커니즘을 설정할 때 실제 상황과 결합하여 고려해야 한다.

(2) 용량

일반적으로 스택 설계 원리를 사용하여 캐시를 비우는 용량 제한을 설정합니다. 스택을 넘친 오래된 데이터는 자동으로 지워집니다.

1, 페이지 로드

시나리오 1: 한 페이지 전체 로드

이 로드는 비교적 간단하며, 일반적으로 페이지 내용이 비교적 간단한 경우 모든 데이터를 한 번에 로드한 후 내용을 표시하는 데 사용됩니다. 단일 페이지 로드 실패 상태는 비교적 쉽게 처리할 수 있습니다.

시나리오 2: 단일 페이지 블록 로드

이 방안은 사용자가 단계별로 내용을 볼 수 있게 해 주며, 이 점진적인 과정에서 자신의 불안을 줄일 수 있는 것이 특징이다.

모듈 간에 연관이 있는 경우 상위 컨텐츠를 로드한 다음 하위 컨텐츠를 로드하는 것으로 나눌 수 있습니다. 유쿠 (Youku) 인 경우, 먼저 열을 로드한 다음 각 열의 내용을 로드합니다.

모듈 간에 절대 종속성이 없으면 각 모듈의 컨텐츠를 독립적으로 로드하여 요청 속도에 따라 별도로 표시할 수 있습니다. 이 프로세스는 사용자가 데이터를 완전히 칠하지 않고 대중의 평론, 타오바오 클라이언트와 같은 필요한 기능을 찾을 수 있는 기회를 제공합니다.

프레임이 고정되어 있고 내용이 업데이트된 경우 프레임을 먼저 표시한 다음 다양한 iOS apps 와 같이 각 모듈을 표시하는 데이터를 개별적으로 로드할 수 있습니다.

이 모듈 로드는 로드 실패 상태에 특별한주의를 기울여야합니다. 결국, 각 모듈은 로드가 실패했다는 것을 알려주기 때문에, 재시도를 클릭하는 것은 매우 실망스러운 일이다. 정보의 우선 순위에 따라 기본 상태를 사용하는 데이터 실패와 실패 프롬프트를 사용하는 데이터를 결정할 수 있습니다.

장면 3: 스프레드 로드

상위 페이지&; 하위 페이지 또는 동일한 app 내에서 페이지 사이의 필드를 재사용할 수 있으며 하위 페이지를 로드할 때 새 데이터를 다시 로드할 필요가 없습니다.

시나리오 4: 예하 중

이 로드 방식은 한 페이지의 내용을 로드하는 동안 사용자의 다음 보행을 예측하는 것이 특징이며, 다음 단계에서 사용해야 할 페이지의 내용을 로드하여 로드를 기다리지 않고 다음 작업에서 즉시 정보를 얻을 수 있도록 하는 것입니다. (데이비드 아셀, Northern Exposure (미국 TV 드라마), Northern Exposure (미국 TV 드라마), 스포츠명언)

사전 설치는 사용자에게 원활한 제품 사용 환경을 제공하여 사용자가 중단 없이 제품을 사용할 수 있도록 합니다.

구체적인 예는 다음과 같습니다.

아틀라스를 탐색할 때 첫 번째 그림을 보면 배경에서 두 번째, 세 번째, 네 번째 그림이 자동으로 로드되므로 사용자가 첫 번째 그림을 다 살펴본 후 두 번째 그림으로 전환할 때 기다리는 과정이 없습니다.

뉴스 목록을 탐색할 때 각 뉴스의 내용은 백그라운드에서 미리 로드됩니다. 사용자가 뉴스를 보기로 선택하면, 그들은 즉시 내용을 읽을 수 있다.

하지만 이 방안도 많은 문제에 직면해야 한다. 말이 바다에 가장 직접적인 문제는 트래픽이라고 생각하는데, 이는 많은 사용자가 전혀 사용하지 못할 수 있는 데이터 트래픽을 자동으로 달리기 때문이다. 따라서 일반적으로 말은 와이파이 환경에서 이 로드 모드를 설정할 것을 권장합니다. 또는 주요 컨텐트만 미리 로드할 수 있고 일부 보조 컨텐트는 사용자가 실제로 사용하는 경우에만 로드할 수 있도록 로드 규칙을 설정합니다. 예를 들어, 뉴스 문자를 미리 로드하는 경우 문자 정보만 로드할 수 있으며, 사용자가 내부 페이지로 들어가야 그림 정보를 로드할 수 있습니다. 이러한 사전 로드와 블록 로드의 조합은 다양한 장면에도 광범위하게 적용됩니다.

또한 사전 로드에 시간이 걸립니다. 다만 클라이언트에서는 사용자에게 보여주지 않고 백그라운드에서 묵묵히 조작한다. 사용자가 로드 전 정보를 사용할 때 특별한 고려가 필요하므로 사전 로드를 설계할 때 이 상황에 적합한 또 다른 일반적인 로드 방법을 고려해야 합니다.

사전 로드는 특정 시나리오에 따라 설계되고, 정보 우선 순위를 설정하고, 다양한 유형의 정보에 대한 구체적인 크기와 트래픽을 종합적으로 고려하고, 사전 로드 방식을 전체적으로 고려해야 하며, 이를 신중하게 분석하고 생각해야 합니다.

네트워크 환경이 발전함에 따라 사전 로드는 향후 제품을 로드하는 일반적인 방법이 될 것이며, 사용자에게 제공되는 원활한 사용 환경을 통해 제품의 가용성을 크게 향상시킬 수 있습니다.

2. 작업 부하

페이지를 로드해야 하는 정보 외에도 서버에 요청을 보내 페이지의 작업을 기록해야 합니다.

시나리오 1: 하중 층

한 번의 작업 후에 모달 프롬프트 레이어가 팝업되어 사용자에게 로드 중임을 알립니다. 모달 프롬프트는 주로 프로세스 중에 다른 작업을 수행하지 못하도록 하여 현재 로드 오류를 발생시키는 데 사용됩니다. 모달 프롬프트 및 네트워크 상의 이유로 오랫동안 로드 상태에 있을 수 있으므로 닫기 작업을 제공하여 로드를 일시 중지하고 App 사용 가능 상태를 재개하는 것이 좋습니다. 로드에 실패할 경우 현재 부동 레이어에서 실패 프롬프트로 변환할 수 있습니다. 모달 프롬프트 레이어는 가장 안전한 방법이지만 사용 중에 끊어진 느낌을 줄 수 있습니다.

장면 2: 컨트롤 자체의 로드 상태

이 방법은 작업 로드의 상태와 제어 스타일을 결합합니다. 컨트롤을 조작한 후 컨트롤이 로드된 상태로 변경되고 이 시점에서 컨트롤을 반복할 수 없습니다. 이 로드 방법은 컨트롤 자체의 상태이며 다른 작업에 영향을 주지 않기 때문에 사용자는 페이지에서 다른 작업을 수행할 수 있습니다. 이로 인해 여러 요청이 동시에 발생할 수 있으며 로드 실패 위험이 커질 수 있습니다. 이것도 이 모델의 단점이지만, 이런 극단적인 상황은 거의 발생하지 않는다. 요청이 실패하면 Toast 프롬프트를 사용하여 사용자에게 실패 이유를 알릴 수 있습니다.

시나리오 3: 백그라운드 로드

사용자 작업 후 클라이언트는 작업이 성공했다는 피드백을 즉시 받고 요청을 백그라운드로 배치하여 서버와 상호 작용합니다. 이 프로세스는 사용자가 이해하거나 기다릴 필요가 없습니다. 일반적으로 검증은 매우 좋다.

그러나 극단적인 상황에서는 알 수 없는 상황이 발생할 수 있다. 요청은 백그라운드에서 기록되고 서버와 상호 작용하기 때문에 실제 요청의 성공 여부, 클라이언트가 설명하지 않고 모두 작업 성공으로 표시됩니다. 이로 인해 사용자가 작업이 성공했다고 착각하게 됩니다. 실제로 다음 번에는 성공하지 못합니다.

따라서 이 로드 방식은 특정 사용 시나리오에 따라 균형을 맞춰야 합니다. 일부 중요한 작업의 경우 모달 로드를 사용하는 것이 좋습니다. 점찬, 가입, 관심과 같은 작은 작업의 경우 백그라운드 로드를 사용할 수 있습니다.

3. 다음 페이지 또는 현재 업로드를 업로드합니다.

사용자가 홈페이지로 들어가 본격적으로 경험의 첫걸음을 내디다. 다음 단계는 사용자의 목표에 따라 인터페이스 간에 이동하는 것입니다. 인터페이스 점프를 완료하는 로드 전략에는 여러 가지가 있지만 어떤 형식이든' 다음 페이지 로드' 와' 현재 페이지 로드' 로 나눌 수 있습니다.

(1) "다음 페이지 로드" 는 사용자가 미리 엿보는 요구를 충족합니다.

우리는 페이지를 "점" 으로 봅니다. 페이지 트래픽은 이러한 점을 연결하는 "선" 입니다. 우리는' 사용자가 청바지 한 벌 사고 싶다' 는 장면에서 간단한 눈동연구를 했다. 앱에서 상품 브라우징까지, 그리고 상품 확인까지 다음 페이지로 넘어가면, 사용자가 선보이는 동공 계단은 E>D>C & gtB& gt；; A. 이런 현상을 설명하기 위해 피실험자와의 교류를 통해 사용자들이 브라우징보다는 보고 싶은 것을 더 기대하고 있다는 것을 알게 되었다. 따라서 이 시점에서 "다음 페이지 로드" 는 사용자가 미리 엿보는 요구를 충족시키는 데 적합합니다.

(2) 등등! 나는 생각할 필요가있다.

마찬가지로, 우리는 또한' 알리페이로 휴대폰을 충전하는 장면' 을 연구했다. 1 차 지불부터 2 차 확인 지불까지 사용자가 제시한 동공이 비교적 크다. 즉 A 와 B 가 대략 같다. 인터뷰를 통해' 증분 체험 스트림' 과는 달리, 사용자가 논리를 판단하는 인터페이스를 만났을 때 사용자는 다음 페이지에 포함된 것을 서둘러 보지 않고 0, 즉 1 의 검증 심리를 서두르지 않는 것으로 나타났다. 그래서 판단논리 인터페이스에서 콘텐츠 엿보기에 대한 사용자의 요구는 그리 강하지 않고, 내용도 없고, 작은 토스트일 수도 있고, 간단한 정보 피드백 인터페이스 (여기서' 다음 페이지 로드' 는 닭갈비) 일 수도 있다. 반면, 0 이 아닌 1 에 대한 사용자 인증 수요는 강렬하며 결과를 기다리는 동안 긴장과 흥분을 동반합니다. 따라서 현재 페이지 로드 인터페이스를 통해 시스템이 사용자가 제공한 명령을 처리하려고 시도하고 있으며, 결과-"처리 성공", 0 이 아닌 만족, 즉 1 검증을 완료할 때까지 사용자가 긴장하고 흥분하게 됩니다.

4. 먼저 업로드하거나 먼저 표시합니다

로드 기능이 필요한 경우 로드 전에 표시할 수 있고, 내용을 로드해야 하는 경우에는 표시할 수 있습니다.

타오바오

APP 를 여는 첫 페이지는 함수이므로 로드하기 전에 보여 줍니다.

모듈 (메뉴를 클릭하지 않음) 을 클릭하기만 하면 내용 (상품) 이 아래에 표시되므로 로드한 후 표시, 로드한 후 표시:

징둥

마찬가지로 로드하기 전에 기능 모듈이 표시됩니다.

컨텐츠를 로드한 후 표시 완료:

이 두 가지 방법은 각각 장단점이 있다.

먼저 를 표시한 다음 로드:

장점: 사용자에게 0 을 기다리는 착시.

단점: 현재 데이터는 사용자 작업의 마지막 단계가 발견될 때까지 올바르지 않을 수 있습니다.

먼저 로드한 다음 다음을 표시합니다.

장점: 데이터의 품질과 정확성을 보장합니다.

단점: 네트워크가 좋지 않을 때 대기를 일으킬 수 있습니다.

기능 모듈은 한 제품에 고정되어 있으며 단기간에 거의 업데이트되지 않기 때문에 이 데이터가 잘못되었거나 현재 상태와는 다른 확률이 훨씬 낮습니다. 그래서 선쇼 후 입는 방식을 채택할 수 있습니다.

반면에 내용, 특히 상품 데이터는 가장 쉽게 변할 수 있다. 모든 소비자가 보는 데이터가 가장 진실하고 정확하도록 전시하기 전에 로드해야 합니다.

1, 빈 페이지를 새로 고치지 못했습니다. 힌트가 있습니다.

요즘 앱은 모두 콘텐츠 중심으로 표방되어 있어 빈 페이지를 최대한 피한다. 대부분의 응용 프로그램에서 가장 좋은 방법은 캐시를 사용하는 것입니다. 페이지에 들어가면 이전 캐시를 표시한 다음 내용을 새로 고칩니다. 둘째, 빈 페이지를 제거하는 두 번째 방법은 시스템 추천을 제공하여 교체하는 것입니다. 그러나 일부 페이지의 경우 페이지 내용은 사용자의 사용 상태와 밀접한 관련이 있으므로 빈 페이지가 나타나는 것은 불가피합니다. 이때 안내 수업의 작은 기교로 페이지를 풍부하게 하여 사용자가 콘텐츠를 생성할 수 있도록 할 것이다.

하지만 일간지를 보는 것과 같은 일부 정보 앱은 기본적으로 빈 페이지를 열고 내용을 로드합니다. (이 설정은 잘 모르겠습니다.) 콩꽃잎 순간, 모노와 같은 다른 앱은 매일 앱에 들어갈 때도 빈 페이지가 있다. 두 번째 유형의 응용 프로그램이 나타나는 이유는 다음과 같습니다. 이들의 내용 * * 엄격하게 일 단위로 매일 고정 시간에 콘텐츠를 선택한다. 그들은 네가 매일 그날의 물건만 보길 바랄 것이다. 그래서 일단 다음날이 되면 어제의 내용은 번거롭다. 그래서 매일 처음으로 앱에 들어갈 때 매일이 완전히 새로운 시작이라는 것을 상징하는 빈 페이지가 있습니다. 빈 새로 고침 논리가 나타납니다.

빈 새로 고침에 해당하는 장면은 사용자가 콘텐츠를 새로 고치려고 합니다. 사용자는 여기서 새 콘텐츠를 새로 고칠 수 있다는 것을 알고 있지만 새로 고침은 성공하지 못합니다. 이때 사용자에게 교대를 해야 한다. 그래서 사용자에게 힌트를 주어야 합니다. 동시에, 사용자에게 메시지를 표시한 후, 우리는 사용자에게' 클릭 다시 시도' 라는 해결책을 주어야 한다.

2. 프롬프트 없이 캐시 페이지를 새로 고치지 못했습니다.

지식, 인터넷 뉴스, 호기심 일간지, 위챗 위챗 모멘트 등 흔히 볼 수 있는 앱. , 모두 캐시 형태를 취합니다. 설정하면 캐시 내용이 표시되고 서버에 요청이 전송됩니다. 내용이 업데이트되면 내용이 자동으로 한 번 업데이트되고 업데이트된 내용이 현재 내용을 직접 덮어씁니다. 업데이트 실패 후 프롬프트가 없습니다. 하지만 사전, 펭귄 FM, 넷이즈 클라우드 뮤직 등과 같은 응용도 있습니다. , 업데이트 실패 후 메시지가 표시됩니다.

이 두 응용 프로그램의 차이점은 다음과 같습니다.

적용 빈도

컨텐츠의 시간 연속성

인터페이스 간의 긴밀한 관계.

예를 들어, NetEase News 는 시간을 죽이는 도구로 매일 자주 사용되기 때문에 사용자가 들어와서 업데이트가 있는지 확인하고 싶습니다. 둘째, NetEase 뉴스의 내용은 지속적으로 업데이트되므로 사용자는 현재 표시된 내용이 내가 보고 처리한 것임을 알 수 있습니다. 마지막으로, 뉴스 목록 페이지에는 사용자가 세부 정보 페이지로 들어가는지 여부를 신속하게 확인할 수 있는 요약이 표시되어 사용자가 마지막 사용 장면을 기억하는 데 도움이 됩니다.

따라서 이는 사용자가 업데이트가 있는지 확인하고 싶었기 때문에' 새로운 내용 없음' 에 대한 심리적 기대치가 높아졌기 때문에 콘텐츠를 업데이트할 수 없어도 사용자가 너무 많이 생각하지 않을 수 있는 장면입니다. 반대로, 잘못된 힌트를 주면 사용자가 낙담할 수 있다. 그는 지금 내용이 있다는 것을 알고 있지만, 인터넷 때문에 쇄신하지 않았기 때문에, 그가 하고 싶은 임무는 외부 요인에 의해 방해를 받아 미묘한 좌절감을 불러일으켰다.

3. 캐시 페이지 새로 고침에 실패했음을 표시합니다.

또 다른 응용 프로그램은 사용 빈도가 그리 높지 않거나, 콘텐츠에 시간 연속성이 없거나, 현재 인터페이스가 사용자의 마지막 사용 장면을 불러일으키지 못하는 응용 프로그램입니다. 그렇다면 너의 실패에 대한 첫 번째 암시를 줄 필요가 있다.

예를 들어 펭귄 FM 은 주파수가 낮을 운명이다. 시각 수신 정보는 청각을 통해 받는 것보다 더 빠르고 더 많은 정보를 받을 수 있고, 동시에 오디오류는 환경에 대한 요구가 더 높기 때문이다. (예: 이어폰을 사용할 때 환경이 그렇게 시끄럽지 않고 밖에서 놀려면 사적인 곳에서 놀아야 하기 때문이다.) (알버트 아인슈타인, Northern Exposure (미국 TV 드라마), 스포츠명언) 둘째, 이러한 애플리케이션은 실시간으로 권장되며, 시간 연속성에 문제가 없으므로 사용자가 콘텐츠를 시간에 따라 읽었는지 여부를 확인할 수 없습니다. 그리고 제목도 빨리 판단하는 데 도움이 되지 않는다. 그래도 들어가서 들어야 내용이 무엇인지 알 수 있다. 마지막으로, 사용자에게 상기시키지 않으면, 세부 정보 페이지에 들어가 알림을 받을 때 응용 프로그램이 사용자의 시간을 낭비한다고 느낄 수 있습니다. 그래서 이런 내용의 경우 새로 고침에 실패했다는 것을 상기시켜야 한다.