js 엔진 이 javascriptCore 또는 v8 로 판 단 됩 니 다.

이유
  순 전 히 지루 하 다. 자 바스 크 립 트 코어 와 Spider Monkey 의 정 보 를 검색 해 왔 지만 본의 아니 게 ios 의 UIWebView 에서 js 분석 엔진 을 판단 하 는 방법 을 배 웠 다.

if (window.devicePixelRatio) { //If WebKit browser
    var st = escape(navigator.javaEnabled.toString());
    if (st === 'function%20javaEnabled%28%29%20%7B%20%5Bnative%20code%5D%20%7D') {
        document.write('V8 detected');
    } else {
        document.write('JSC detected');
    }
} else {
    document.write("Not a WebKit browser");
}

  위 코드 만 있 으 면 ios 에 서 는 자 바스 크 립 트 코어 의 커 널 이 고 안 드 로 이 드 에 서 는 v8 엔진 입 니 다.  이전 글 obsc 와 js 통신 실현 - WebViewJavascriptBridge 에 서 는 cordova 의 브리지 메커니즘 - UIWebView 를 통 해 stringby Evaluate JavascriptString 방법 으로 통신 하 였 으 나 이 를 통 해 우 리 는 내 장 된 jsc 엔진 으로 js 코드 를 실행 할 수 있 지만 더 세밀 하 게 자 바스 크 립 트 가 실 행 될 때 코드 를 실행 할 수 없습니다.가장 직접적인 표현 은 'oc 에서 실 행 된 js 에 대해 잘못된 통 제 를 할 수 없습니다. 예 를 들 어 이상 처리 체제' 입 니 다.javascriptCore 를 추가 로 도입 하거나 연결 함으로써 c 차원 에서 iOS 와 통신 할 수 있어 효율 이 크게 향상 되 었 습 니 다.
대비
  1, iOS 에서 UIWebView 구성 요소 의 stringByEvaluate JavascriptString: (NSString *) 방법 으로 호출 합 니 다.그러나 이런 방식 에는 몇 가지 폐단 이 있다.    1) oc 호출 js 는 반환 값 이 있 고 동기 호출 에 속 합 니 다.한편, js 호출 oc 는 iframe 을 만 들 고 src, oc 엔 드 의 UIWebVIEW 차단 요청 을 설정 한 다음 에 stringByEvaluate JavascriptString 을 통 해 js 엔 드 를 실행 하 는 방법 으로 js 의 매개 변수 (직렬 화 된 json 문자열) 를 얻 고 oc 엔 드 에서 반 직렬 화 를 한 다음 에 oc 의 함 수 를 호출 합 니 다.    2) oc 엔 드 의 stringByEvaluate JavascriptString 은 js 코드 를 실행 할 때 js 엔 드 코드 의 실행 을 막 습 니 다.    3) 1) 절 차 를 통 해 알 수 있 듯 이 UIWebView 를 통 해 이 루어 진 bridge 메커니즘 의 성능 이 걱정 되 고 상호작용 이 아프다.    4) UIWebView 를 통 해 js 코드 세그먼트 를 실행 하 는 데 몇 가지 제한 이 있 습 니 다. ios 는 우리 에 게 UIWebView 를 통 해 자바 script 이 실 행 될 때의 권한 을 주지 않 았 기 때문에 stringByEvaluate 자바 script String 을 통 해 잘못된 js 코드 를 실행 하 더 라 도 우 리 는 oc 에서 오류 메 시 지 를 얻 을 수 없고 리 셋 함수 에 대해 서 는 말 할 수 없습니다.그러나 이런 방식 의 장점 은 메모리 관리 와 관련 이 없다 는 것 이다.   2. 현재 oc 와 js 통신 을 실현 하 는 세 가지 방안 이 있 는데 첫 번 째 는 cordova 의 통신 체 제 를 계속 사용 하 는 것 이다. 즉, 현재 비교적 유행 하 는 UIWebView 이다.두 번 째 는 React Native 의 통신 체 제 를 사용 하여 iOS 7 에 내 장 된 javascriptCore 엔진 을 사용 하고 js, oc 2 층 에 브리지 를 구축 하 며 층 마다 똑 같은 설정 표를 가지 고 있 습 니 다. 표 마다 js, oc 투 출 된 API 를 기록 하고 iOS 의 이벤트 체 제 를 결합 하여 oc 와 js 의 상호 조정 을 완성 합 니 다.세 번 째 는 iOS 7 에 내 장 된 javascriptCore 프레임 워 크 를 사용 합 니 다. React Native 와 달리 jsc 가 제공 하 는 통신 체 제 를 사용 합 니 다. 이 체 제 는 안 드 로 이 드 에서 WebView 인 코딩 방식 과 유사 합 니 다. oc 단 은 JSexpose 프로 토 콜 만 실현 하면 이 프로 토 콜 을 실현 하 는 대상 을 현재 의 상하 문 에 투과 합 니 다. 예 를 들 어 UIWebView 컨트롤 에서 webview 에 대응 하 는 문맥 을 바 꾸 고 h5 페이지 가 전환 되 더 라 도.문맥 이 여전히 변 하지 않 으 니 하나의 사례 로 이해 할 수 있다.  3. 세 가지 방안 을 종합해 보면 첫 번 째 대가 가 가장 낮 고 절차 가 완선 하 며 체계 화 되 었 으 나 성능 은 경상 이다.두 번 째 는 매우 좋 은 참고 이다. RN 의 방식 은 javascriptCore 뿐만 아니 라 SpiderMonkey 와 같은 다른 엔진 에 도 적용 된다. 그러나 RN 의 방안 을 사용 하려 면 구체 적 인 실현 디 테 일과 기 교 를 파악 하 는 데 더 많은 시간 이 걸 릴 수 있 고 난이도 가 약간 높다.세 번 째 는 비교적 무해 하고 실현 난이도 가 높 지 않 은 방안 입 니 다. 현재 iOS 에 iOS 7 이상 의 장치 만 설치 되 어 있 기 때문에 iOS 6 및 이하 장 치 를 호 환 할 필요 가 없습니다 (제3자 javascriptCore 도입). 또한 내 장 된 js 엔진 과 oc 를 사용 하여 통신 하면 c / c + 차원 의 효율 이 크게 향상 될 것 입 니 다.(UIWebview 에 비해) 단점 은 현재 사용 하고 있 는 bridge 통신 방식 을 다시 해 야 하고 구조 재 설계 가 필요 하 다 는 것 이다.