원칙 분석
개발 중에 "Breakpoint Continuous Transmission"의 기능은 매우 실용적이고 일반적이며 "표준"도 더 많이 들립니다. 그래서 우리는 일반적 으로이 기능이 어떻게 구현되는지 연구하는 데 관심이 있습니까?
Java에서는 인터넷에서 유사한 기능 구현에 대한 많은 정보를 찾을 수 있습니다. 그러나 대부분은 데모를 제공하고 소스 코드를 게시합니다. 구현 원칙에 대한 자세한 설명은 거의 없습니다.
우리가 처음 접촉했을 때, 우리는 CRTL + c/v 코드를 직접 사용한 다음 땜질을 할 수 있지만 마침내 효과를 얻을 수 있습니다. 그러나 초보자 일 때이 작업을 수행하는 것은 분명히 좋고 나쁘다.
장점은 많은 소스 코드와 설명이 거의 없다는 것입니다. 우리가 열심히 일할 의향이 있다면, 우리는 정보를 검색하고 다른 사람들이 게시 한 코드에서 이해하지 못하는 것을 연구 할 것입니다. 결국, 당신은 아마 많은 보상을 얻을 것입니다.
단점도 분명합니다. 초보자로서, 많은 소스 코드에 직면 할 때 많은 것들이 익숙하지 않아서 어려운 일이 쉽습니다. 결국 사용법을 대략적으로 이해하더라도 구현 원칙을 반드시 이해하지는 못할 수도 있습니다.
오늘날 가장 기본적인 관점에서 시작하여 소위 "브레이크 포인트 연속"이 실제로 "고급"인지 확인하겠습니다.
실제로, 새로운 "사물"과 접촉 할 때, 당신은 그것을 우리가 참조하고 비교하고 배우는 데 더 익숙한 것으로 바꿀 수 있습니다. 일반적으로 절반의 노력으로 결과의 두 배가됩니다.
우리가 "브레이크 포인트 연속 전송"이라는 개념에 방금 노출되면 명확하게 1, 2 및 3을 명확하게 설명하기가 어려울 것입니다. 그러면 우리는 "게임 플레이"에 확실히 익숙 할 것입니다.
자, 이제 "클리어 레벨 RPG 게임"이 있다고 가정 해 봅시다. 이런 종류의 게임을 할 때 우리가 일반적으로하는 일에 대해 생각해보십시오.
첫날에 우리는 피의 전투와 싸웠고 우리가 마침내 네 번째 레벨에 도착했다고 가정하면서 모든 사람을 죽였다는 것은 분명합니다. 치열한 전투는 본격적으로 진행되었지만 벽의 시계를 보았을 때 이미 오전 12시 였고 침대에 갈 시간이었습니다.
지금은 매우 창피했습니다. 다음에 우리가 플레이 할 때 게임의 진전에 성공적으로 보조를 맞추기 위해 어떻게해야합니까?
매우 간단합니다. 우리는 게임을 끄지 않고 잠자리에 들고 다음날 계속 플레이합니다. 이것은 괜찮지 만 사람들을 불편하게 만드는 것이있는 것 같습니다.
따라서 현재 게임에 "저장"이라는 기능이 있으면 매우 중요합니다. 아카이브를 직접 선택하고 아카이브 이름 "4 단계"를 입력 한 다음 게임을 닫을 수 있습니다.
다음에 게임을 할 때 "네 번째 레벨"저장을 직접 찾은 다음 파일을 읽은 다음 계속 게임을 할 수 있습니다.
현재 소위 "브레이크 포인트 연속 전송"은 이해하기 쉽습니다. "게임 재생"에 대한 이전 아이디어를 따르합시다.
지금 다운로드해야 할 파일이 있다고 가정하십시오. 우리가 그 일부를 다운로드하면 다음과 같은 상황이 발생합니다 : 컴퓨터 충돌, 전원이 나오고 네트워크가 중단됩니다.
사실, 이것은 우리가 전에 게임을했을 때와 같습니다. 우리는 갑자기 잠자리에 들고 12시에 휴식을 취해야했습니다. 좋아,이 시점의 상황은 다음과 같습니다.
• 게임을 저장할 수 없다면 다음에 우리가 플레이 할 때, 이번에 통과 한 4 레벨의 진행 상황이 손실되고 게임을 따라갈 수 없다는 것을 의미합니다.
• 이에 따라 "다운로드"동작 이이 다운로드의 진행 상황을 기록 할 수없는 경우. 그런 다음이 파일을 다시 다운로드하면 다시 시작할 수 있습니다.
이 시점에서, 우리는 위에서 언급 한 행동의 열쇠가 " 계속 "이라는 단어라는 것을 실제로 발견했습니다!
연결이 끊어진 동작을 "계속"하는 목적을 달성하기 위해 키는 "미디어"가 동작에 "중단"이있는 노드의 정보를 기록하고 읽을 수있는 것입니다.
프로그래밍 세계로 변환하십시오
실제로 이것은 "브레이크 포인트 연속 전송"의 가장 기본적인 원칙입니다. 명백한 말로, 다운로드 동작이 중단 될 때 인터럽트 위치 정보를 기록한 다음 다음 동작에서 읽어야합니다.
이 위치 정보를 통해 우리가해야 할 일에 대해 생각해보십시오. 예, 매우 간단합니다. 새로운 다운로드 동작이 시작되면이 레코드 위치에서 직접 콘텐츠를 다운로드하고 더 이상 처음부터 시작하지 않습니다.
글쎄, 우리는 평범한 언어로 오랫동안 원칙에 대해 이야기 해 왔으며 지루해지기 시작했습니다. 따라서 결국 요약 한 다음 원칙을 프로그래밍 세계로 어떻게 전환 해야하는지 살펴 보겠습니다.
• "업로드 (다운로드) 동작"이 중단되면이 업로드 (다운로드)의 위치 (위치)를 기록해야합니다.
• "계속"동작이 시작되면 게시물로 직접 이동하여 계속 업로드 (다운로드).
분명히, 문제의 열쇠는 소위 "위치"에 있습니다. "통과 레벨 게임"에서 우리는이 위치의 단위로 "어떤 레벨"을 사용할 수 있습니다.
따라서 소위 "Breakpoint Continuous Transmission"으로 전환하면 "위치"를 측정하는 데 무엇을 사용해야합니까? 분명히, 여기의 본질은 파일을 읽고 쓰는 것 이상이기 때문에 바이너리로 돌아갑니다.
그런 다음 나머지 작업은 매우 간단합니다. 첫째, 데이터 (메모리, 파일, 데이터베이스)의 지속성 일 뿐이며 여러 가지 방법이 있기 때문에 말할 가치가없는 것으로 보이는 위치를 기록하십시오.
또 다른 열쇠는 "계속 된"동작이 시작될 때 지난번에 기록한 위치에서 읽기 및 쓰기 작업을 시작해야하므로 "포인터"기능과 비슷한 것이 필요하다는 것입니다.
물론, 우리는 그러한 "포인터"를 구현할 수있는 방법을 찾을 수 있지만, Java가 그러한 클래스, 즉 RandomAccessFile을 제공 한 것에 대해 행복합니다.
이 클래스의 기능은 직관적으로 그 이름에 반영되며 파일에 무작위로 액세스 할 수 있습니다. API 문서 에서이 클래스의 설명을 살펴 보겠습니다.
이 클래스 지원 인스턴스는 무작위로 액세스 한 파일을 읽고 씁니다. 파일에 대한 무작위 액세스는 파일 시스템에 저장된 대형 바이트 어레이처럼 작동합니다.
파일이 읽기/쓰기 모드에서 무작위로 액세스되면 출력 작업도 사용할 수 있습니다. 출력 작업은 파일 포인터로 시작하여 바이트가 작성 될 때 파일 포인터를 발전시킵니다.
암시 적 배열의 현재 끝에 쓰인 후 출력 작업은 배열이 확장됩니다. 파일 포인터는 getFilePointer 메소드를 통해 읽고 Seek 메소드를 통해 설정할 수 있습니다.
API 지침을 읽은 후 우리는 웃었다. 예, 이것이 우리가 원하는 것이 아닌가? 글쎄, 우리는 오랫동안 칼을 날카롭게 해왔습니다. 왜 우리는 나무를 자르지 않습니까?
예제 데모
파일의 "브레이크 포인트 연속"을위한 것이므로 먼저 파일을 만들 것입니다. 오디오 파일, 이미지 파일 등이 좀 더 고급스러워 보일 수 있습니다.
그러나 우리는 이미 큰 컴퓨터 형제들의 눈으로 결국 "바이너리"로 돌아갈 것이라고 말했습니다. 따라서 TXT는 이해에 더 도움이되기 때문에 간단한 "txt"파일을 여기에 만들 것입니다.
디스크 D의 루트 디렉토리에서 "test.txt"라는 파일을 만듭니다. 파일 내용은 그림과 같이 매우 간단합니다.
맞습니다. 우리가 입력 한 것은 6 개의 간단한 영어 편지입니다. 그런 다음 → 속성을 마우스 오른쪽 버튼으로 클릭합니다.
파일의 크기가 6 바이트 인 것을 알 수 있습니다. 그렇기 때문에 우리는 모든 것이 "바이너리"와 분리 할 수 없다고 말합니다.
그렇습니다. 우리 모두는 6 개의 영어 편지를 입력했기 때문에 이해하고, 영어 문자 1 개가 차지할 저장 공간은 1 바이트 (예 : 8 비트)입니다.
지금까지 우리가 본 것은 기본적으로 말도 안되는 일이기 때문에 지루하고 컴퓨터 지식을 가진 사람들은이 지식을 알고 있기 때문입니다. 걱정하지 마세요, 계속합시다.
Java로 파일을 읽고 쓰기 쉽습니다. 현재 요구 사항이 "Drive D에서 Drive e 까지이 파일을 작성"하면 키보드를 들어 올리고 완료합니다!
그러나 소위 파일의 소위 "업로드 (다운로드)"가 아닌가? 유일한 차이점은 행동이 "원주민 간"에서 "원주민 간", "원주민 사이의"파일 읽기와 쓰기로 바뀌는 것입니다.
현재 우리는 "촉구를 멈추십시오. 모두가 이러한 것들을 알고 있습니다. '브레이크 포인트 연속 전송'은 어떻습니까?" 사실, 이미 여기에서 매우 간단합니다. 우리는 중단 점 연속 전송에서 우리가해야 할 일이 다음과 같습니다.
이전 읽기 및 쓰기 동작에 중단이있는 경우, 이번에 읽고 쓴 파일 내용의 위치 정보를 기록하십시오. "연속이 시작되면"포인터를 직접 이동하고 읽기 및 쓰기 작업을 계속 시작하십시오.
원리에 대한 반복적 인 강조는 실제로 원칙이 이해되는 한 나머지는 단지 움직임이기 때문입니다. 이것은 무술 소설의 "9 번 9 번으로의 복귀"달마와 같습니다. 가장 높은 수준은 원래 소스로 돌아가는 것입니다.
복잡한 것의 원리를 이해하는 한, 우리는 그것을 제거하고 간단한 것들로 줄일 수 있습니다. 마찬가지로, 논리적 조합을 통해 일련의 단순한 것들이 복잡한 것들을 형성합니다.
다음으로, 우리는 곧 혼돈으로 돌아가서 가장 기본적인 형태로 "브레이크 포인트 연속 전송"을 시뮬레이션 할 것입니다. 여기서 우리는 서버 코드를 작성하지 않으며 로컬 테스트 클래스를 통해서만 수행합니다.
우리가 달성하려는 효과는 매우 간단합니다. 디스크 d에 "test.txt"파일을 디스크 e로 작성하지만 프로세스 중간에서 "인터럽트"동작을 시뮬레이션 한 다음 다시 업로드하여 전체 프로세스를 완료합니다.
다시 말해, 우리는 "d drive"를 여기에서 컴퓨터로 간주하고 "e drive"를 서버로 직접 간주합니다. 그런 다음 더 이상 HTTP 프로토콜과 반 센트와 관련이 없을 것입니다 (물론 실제 개발과 관련하여 여전히 관련이 있어야합니다). 따라서 파일을 읽고 쓰는 데 "브레이킹"및 "계속"의 가장 기본적인 원칙에 대해서만 관심이 있습니다.
비교를 통해 우리의 이해를 심화시키기 위해, 우리는 먼저 정상적인 코드를 작성합니다. 즉, 방해없이 정상적으로 읽고 씁니다.
public class test {public static void main (String [] args) {// 소스 및 대상 파일 파일 소스 파일 = 새 파일 ( "d :/", "test.txt"); 파일 targetFile = 새 파일 ( "e :/", "test.txt"); // 입력 및 출력 스트림 FILEINPUTSTREAM FIS = NULL; fileoutputStream fos = null; // 데이터 버퍼 바이트 [] buf = 새로운 바이트 [1]; try {fis = new FileInputStream (sourceFile); fos = 새 파일 아웃 putStream (targetFile); // 데이터 읽기 및 쓰기 while (fis.read (buf)! = -1) {System.out.println ( "쓰기 데이터 ..."); fos.write (buf); }} catch (filenotfoundException e) {System.out.println ( "지정된 파일이 존재하지 않음"); } catch (ioexception e) {// todo : handing exception} 마지막으로 {try {// 입력 및 출력 스트림을 닫습니다. (fis! = null) fis.close (); if (fos! = null) fos.close (); } catch (ioexception e) {e.printstacktrace (); }}}} 이 코드가 실행되면 "test.txt"사본이 디스크에 성공적으로 복사되었음을 알 수 있습니다.이 코드는 매우 간단합니다.
우리는 BUF, 즉 버퍼의 크기가 1이라는 것을 알 수 있습니다. 이는 실제로 읽을 때마다 바이트의 데이터 (예 : 영어 문자 1 개)를 읽는다는 것을 의미합니다.
이제 읽기 및 쓰기 인터럽트의 동작을 시뮬레이션하겠습니다. 우리는 다음과 같이 이전 코드를 완성 할 것입니다.
import java.io.file; import java.io.fileInputStream; import java.io.filenotfoundException; import java.io.fileoutputStream; import java.io.ioexception; import java.io.randomaccessfile; public static int position = -1; public static void main (String [] args) {// 소스 및 대상 파일 파일 소스 파일 = 새 파일 ( "d :/", "test.txt"); 파일 targetFile = 새 파일 ( "e :/", "test.txt"); // 입력 및 출력 스트림 FILEINPUTSTREAM FIS = NULL; fileoutputStream fos = null; // 데이터 버퍼 바이트 [] buf = 새로운 바이트 [1]; try {fis = new FileInputStream (sourceFile); fos = 새 파일 아웃 putStream (targetFile); // 데이터 읽기 및 쓰기 while (fis.read (buf)! = -1) {fos.write (buf); // 파일 콘텐츠의 3 바이트가 업로드되면 네트워크 인터럽트와 예외가 발생합니다. 새로운 fileaccessexception ()을 던지십시오. }}} catch (fileaccessexception e) {keepgreing (sourcefile, targetfile, position); } catch (filenotFoundException e) {System.out.println ( "파일 지정이 존재하지 않음"); } catch (ioexception e) {// todo : handing exception} 마지막으로 {try {// 입력 및 출력 스트림을 닫습니다. (fis! = null) fis.close (); if (fos! = null) fos.close (); } catch (ioexception e) {e.printstacktrace (); }}} private static void keepgreing (파일 소스, 파일 target, int position) {try {thread.sleep (10000); } catch (InterruptedException e) {// todo 자동 생성 캐치 블록 e.printstacktrace (); } try {randomaccessfile readfile = new randomAccessFile (소스, "rw"); randomAccessFile writeFile = 새로운 randomAccessFile (target, "rw"); readfile.seek (위치); writefile.seek (위치); // 데이터 버퍼 바이트 [] buf = 새로운 바이트 [1]; // 데이터 읽기 및 쓰기 while (readfile.Read (buf)! = -1) {writefile.write (buf); }} catch (filenotfoundException e) {// todo 자동 생성 캐치 블록 e.printstacktrace (); } catch (ioexception e) {// todo 자동 생성 캐치 블록 e.printstacktrace (); }}} 클래스 FILEACCESSException 확장 예외 {}요약하면, 우리 가이 변화에서 어떤 일을했는지 :
• 먼저, 인터럽트가 발생할 때 읽기 및 쓰기가 완료된 위치를 기록 할 변수 위치를 정의합니다. (이것은 편의를위한 것입니다. 실제로이 값은 끈기를 위해 파일 또는 데이터베이스에 저장되어야한다고 말해야합니다).
• 파일 읽기 및 쓰기의 while 루프에서 인터럽트 동작의 발생을 시뮬레이션합니다. 여기서 TargetFile의 파일 길이가 3 바이트 인 경우 사용자 정의 한 예외를 던지는 것을 시뮬레이션합니다. (실제 다운로드에서는 "x"바이트의 내용이 업로드 (다운로드)되었고 현재 네트워크가 중단되었으므로 네트워크 인터럽트가 제외 한 예외에서 "x"를 기록 할 것입니다).
• 나머지는 앞에서 말했듯이, "연속"동작이 시작된 후, 우리는 randomAccessfile 클래스를 통해 파일을 랩핑 한 다음, Seek를 통해 읽기 및 쓰기를 위해 이전 인터럽트가 발생한 위치에 대한 포인터를 지정합니다.
(실제 파일 다운로드 및 업로드의 경우 물론 저장된 인터럽트 값을 서버에 업로드해야합니다.이 방법은 일반적으로 httpconnection.setRequestProperty ( "범위", "bytes = x")입니다.
우리의 코드에서, "계속 된"행동, 즉, 유지 방법 : 우리는 스레드를 10 초 동안 잠들게하기 시작합니다. 이는 정확하게 프로그램을 실행하고 효과를 볼 수 있도록합니다.
이제 프로그램을 실행 했으므로 파일은 "D 디스크에서 E 디스크로 업로드하는 프로세스"를 시작합니다. 먼저 E 디스크를 클릭하고 실제로 추가 Test.txt 파일이 있음을 알 수 있습니다. 그것을 열고 다음과 같이 컨텐츠를 찾으십시오.
맞습니다. 현재 우리는 콘텐츠에 "ABC"만 있다는 것을 알았습니다. 파일이 3 바이트로 업로드 될 때 프로그램 시뮬레이션이 중단되기 때문에 이것은 우리의 기대 내에 있습니다.
자, 10 초 동안 조용히 기다린 다음 파일을 클릭하여 성공할 수 있는지 확인하십시오.
스크린 샷을 통해 컨텐츠가 실제로 "ABC"가되었으므로 연속이 완료된 것을 발견했습니다.
위는이 기사의 모든 내용입니다. 모든 사람의 학습에 도움이되기를 바랍니다. 모든 사람이 wulin.com을 더 지원하기를 바랍니다.