올해 초 저는 WebGLGap이라는 PhoneGap 실험 플러그인을 작성했습니다. 이론적으로 모든 JS 호출을 플러그인 코드로 전달하여 PhoneGap 애플리케이션에서 WebGL 지원을 활성화 할 수 있습니다. 불행히도 Javascript와 플러그인 사이의 다리는 거대한 병목 현상 이었기 때문에 버렸습니다. 모든 것들 (정점 데이터 포함)은 거대한 문자열로 문자열로 변환되어 플러그인으로 전달 된 다음 JSON으로 구문 분석되어 원시 플러그인 코드로 읽혀집니다. 분명히 이것은 꽤 쓸모 없게 만들었습니다.PhoneGap 2.2 : 새 브리지는 어떻게 작동합니까?
그러나 PhoneGap 2.2에는 10 시간 이상 빠른 새 브리지가 있습니다. 정확히 어떻게 작동합니까? 그것은 쇠퇴를 피하는가? 브릿지가 충분히 효율적이라면 WebGLGap을 새로 볼 가치가 있습니다.
아직 모든 문자열입니다. 차이점은 XHR_WITH_PAYLOAD가 XHR_NO_PAYLOAD가 아닌 XHR_NO_PAYLOAD가 아닌 XMLHttpRequest를 사용하여 XHR을 사용하여 대기열 읽기를 트리거하거나 IFRAME_NAV를 사용할 수 있다는 것입니다. IFRAME_NAV는 사용 가능한 더 빠른 메소드 중 하나 였지만 터치 스크롤과 충돌합니다. 사파리 버그로 인해 iOS 5
빠른 요청을 처리하는 버그가 수정 된 후 XHR_WITH_PAYLOAD가 2.2에서 기본값으로 설정되었습니다 (https://issues.apache.org/jira/browse/CB-1404). 그러나 브리지가 여전히 사용 중이면 약간 더 느린 방법으로 폴백해야하므로 정상적인 사용을 위해 성능이 향상되지만 주 렌더링 루프에 넣을 항목이 아닙니다.
이와 같은 특별한 요구 사항에 대해서는 사용자 정의 브리지가 더 이해할 수 있습니다. 많은 데이터를 전송하는 데 훨씬 좋은 다른 방법 (예 : 요청 및 응답을위한 본문 내용의 XHR)이 있지만, 표준 브리지와 같은 일반적인 솔루션으로 작동합니다.
답변 해 주셔서 감사합니다. 어느 곳에서나 나는 현저하지 않은 다리를 만드는 법에 대해 더 많은 것을 알 수 있거나 그것에 대한 별도의 질문을 게시해야합니까? – AshleysBrain
당신이 일하는 다른 누군가를 찾을 가능성이있는 일종의 확실하지 않습니다. 최선의 선택은 아마도 xhr 브리지에 대한 코드로 시작하는 것입니다. 일종의 직렬화가 여전히 필요하지만 특정 데이터를 최적화 할 수 있다면 성능을 상당히 향상시킬 수 있습니다. –