如何實(shí)現(xiàn) JavaScript “同步”調(diào)用 App 代碼
一、同步與異步接口概述
在 App 混合開(kāi)發(fā)中，與 js 層交互的接口通常分為同步和異步兩種。盡管為了 Web 的流暢性，我們往往傾向于使用異步接口，但在某些情境下，同步接口的需求不容忽視。同步接口的優(yōu)勢(shì)在于：js 層可以通過(guò)返回值直接獲取執(zhí)行結(jié)果，這在某些場(chǎng)景下（如讀寫配置、短暫操作等）更為合理。特別是在那些語(yǔ)義上就應(yīng)該同步執(zhí)行的 API，設(shè)計(jì)成異步會(huì)顯得不合邏輯。
二、WebView 與同步接口的挑戰(zhàn)
我們知道，在 Android 開(kāi)發(fā)框架中，通過(guò) WebView 的 addJavascriptInterface 方法可以輕松地導(dǎo)出同步接口到 js 層。在 iOS 的 Cocoa 框架中，想實(shí)現(xiàn)這一功能并不簡(jiǎn)單。特別是 UIWebView 和 WKWebView 并沒(méi)有提供類似 addJavascriptInterface 的功能。Android 的這一功能曾出現(xiàn)過(guò)安全漏洞，因此我們需要尋找其他方法來(lái)實(shí)現(xiàn)同步調(diào)用。
三、iOS UIWebView 中的同步調(diào)用實(shí)現(xiàn)
為了解決這個(gè)問(wèn)題，我們可以采取以下策略：自定義 UIWebViewDelegate。在這個(gè)過(guò)程中，我們應(yīng)重點(diǎn)關(guān)注 shouldStartLoadWithRequest:navigationType: 這個(gè)函數(shù)。在這個(gè)函數(shù)中攔截請(qǐng)求，實(shí)現(xiàn)同步調(diào)用的機(jī)制。通過(guò)這種方式，我們可以創(chuàng)建一個(gè)消息隊(duì)列或者類似的機(jī)制來(lái)管理同步調(diào)用的請(qǐng)求和響應(yīng)。當(dāng) js 層發(fā)起同步調(diào)用時(shí)，我們可以將請(qǐng)求放入消息隊(duì)列并等待響應(yīng)。一旦 app 層處理完請(qǐng)求并返回結(jié)果，我們可以通過(guò) WebView 將結(jié)果發(fā)送回 js 層。這樣，即使在沒(méi)有 addJavascriptInterface 的情況下，我們也能實(shí)現(xiàn)同步接口的調(diào)用。
四、WKWebView 與 Android 的參考方案
對(duì)于 WKWebView 和 Android 開(kāi)發(fā)環(huán)境，我們也可以參考上述方案。盡管具體的實(shí)現(xiàn)細(xì)節(jié)可能有所不同，但基本思路是一致的：通過(guò)自定義 WebView 的代理或者創(chuàng)建自己的通信機(jī)制來(lái)實(shí)現(xiàn)同步調(diào)用。這可能涉及到更復(fù)雜的編程工作，但只要我們理解了核心原理，就可以在不同的平臺(tái)上實(shí)現(xiàn)同步調(diào)用。
五、總結(jié)與展望
第一章：探索UIWebView的奧秘
在移動(dòng)應(yīng)用開(kāi)發(fā)中，UIWebView是一個(gè)強(qiáng)大的工具，它允許我們?cè)趇OS應(yīng)用中嵌入網(wǎng)頁(yè)內(nèi)容。今天，我們將深入探討UIWebView的一個(gè)關(guān)鍵功能——處理網(wǎng)頁(yè)加載請(qǐng)求。
第二章：解析原始代碼邏輯
原始代碼似乎是一個(gè)關(guān)于UIWebView的方法，它處理網(wǎng)頁(yè)的加載請(qǐng)求。當(dāng)webView開(kāi)始加載一個(gè)新的請(qǐng)求時(shí)，這個(gè)方法會(huì)被觸發(fā)。這里主要處理了非GET請(qǐng)求和特定協(xié)議請(qǐng)求。
第三章：GET與非GET請(qǐng)求的處理邏輯分析
在這段代碼中，如果加載的請(qǐng)求不是GET方法，它將不作處理并直接返回YES，這意味著會(huì)繼續(xù)加載該請(qǐng)求。對(duì)于GET請(qǐng)求，它會(huì)進(jìn)一步檢查URL的協(xié)議。
第四章：自定義協(xié)議與onMyRequest函數(shù)
如果URL的協(xié)議是自定義的協(xié)議（比如'YourCustomProtocol'），那么會(huì)調(diào)用自定義的onMyRequest函數(shù)來(lái)處理這個(gè)請(qǐng)求。這里的onMyRequest函數(shù)是開(kāi)發(fā)者為特定請(qǐng)求定制的響應(yīng)函數(shù)。
第五章：JS層與隱藏的iframe元素交互揭秘
為了實(shí)現(xiàn)上述功能，JavaScript層需要?jiǎng)?chuàng)建一個(gè)隱藏的iframe元素。每次發(fā)送請(qǐng)求時(shí)，只需修改iframe元素的src屬性即可。這樣，app層就能夠通過(guò)攔截這些請(qǐng)求來(lái)獲取相關(guān)信息。這種做法巧妙地將函數(shù)調(diào)用命令轉(zhuǎn)化為URL請(qǐng)求，增強(qiáng)了應(yīng)用的交互性和響應(yīng)能力。
```objc
-(BOOL)webView:(UIWebView _Nonnull)webView shouldStartLoadWithRequest:(NSURLRequest _Nonnull)request navigationType:(UIWebViewNavigationType)navigationType {
// 判斷請(qǐng)求方法是否為GET
if ([request.HTTPMethod compare:@"GET" options:NSCaseInsensitiveSearch] != NSOrderedSame) {
// 對(duì)于非GET請(qǐng)求，不進(jìn)行處理并直接返回YES，表示繼續(xù)加載該請(qǐng)求
return YES;
}
// 獲取請(qǐng)求的URL對(duì)象
NSURL url = request.URL;
// 判斷URL的scheme是否為自定義協(xié)議（YourCustomProtocol）
if ([url.scheme isEqualToString:@'YourCustomProtocol']) {
// 如果是自定義協(xié)議，調(diào)用自定義的onMyRequest方法處理該請(qǐng)求
return [self onMyRequest:request];
}
// 對(duì)于其他情況，默認(rèn)繼續(xù)加載請(qǐng)求并返回YES
return YES;
}
```
通過(guò)這種實(shí)現(xiàn)方式，我們可以將web頁(yè)面的請(qǐng)求轉(zhuǎn)化為可控制的URL形式，并通過(guò)自定義的方式處理這些請(qǐng)求，增強(qiáng)了應(yīng)用的靈活性和響應(yīng)能力。一、JS與Native之間的消息傳遞
JS向Native傳遞消息的方法
在現(xiàn)代的混合應(yīng)用開(kāi)發(fā)中，JavaScript與原生代碼的交互變得日益重要。當(dāng)我們?cè)趙eb視圖中JavaScript需要向Native iOS應(yīng)用傳遞消息時(shí)，一個(gè)名為`js_sendMessageToNativeAsync`的方法在`JSToNativeIOSPolyfill`類中扮演著關(guān)鍵角色。這個(gè)方法允許我們異步地向Native層發(fā)送消息。
方法解析
這個(gè)方法首先檢查是否存在一個(gè)iframe元素（假設(shè)為`ifr_`）。如果不存在，它會(huì)準(zhǔn)備一個(gè)iframe元素，然后設(shè)置其源地址為一個(gè)自定義協(xié)議。這個(gè)地址包含了一個(gè)消息參數(shù)，這個(gè)消息就是由HybridMessage轉(zhuǎn)換而來(lái)的字符串`str`。這個(gè)過(guò)程利用了URL編碼來(lái)確保消息的完整性和安全性。
異步交互的挑戰(zhàn)
當(dāng)app執(zhí)行完js調(diào)用的功能后，執(zhí)行結(jié)果不能直接返回給js層。為了解決這個(gè)問(wèn)題，通常的做法是使用回調(diào)函數(shù)。js層會(huì)記錄一個(gè)回調(diào)函數(shù)，而native層則通過(guò)UIWebView的`stringByEvaluatingJavaScriptFromString`方法來(lái)調(diào)用這個(gè)回調(diào)函數(shù)。這種機(jī)制類似于JSONP。但要注意的是，這種方式本質(zhì)上是異步的。`js_sendMessageToNativeAsync`函數(shù)會(huì)立即返回，而不會(huì)等待執(zhí)行結(jié)果返回。我們需要一種方法來(lái)“阻塞”js代碼的執(zhí)行，直到我們收到native層的響應(yīng)。
如何在JS中實(shí)現(xiàn)阻塞
章節(jié)一：同步AJAX的概念與實(shí)現(xiàn)
在我們的編程實(shí)踐中，“同步AJAX”雖然聽(tīng)起來(lái)有些矛盾，因?yàn)锳JAX本質(zhì)上意味著異步，但特定情境下，同步請(qǐng)求有其應(yīng)用之處。在這段代碼中，我們創(chuàng)建了一個(gè)XMLHttpRequest對(duì)象，并設(shè)置了其為同步模式。這意味著，在baidu的響應(yīng)返回之前，瀏覽器會(huì)被阻塞，無(wú)法進(jìn)行其他操作。盡管同步請(qǐng)求有導(dǎo)致UI卡頓的風(fēng)險(xiǎn)，但在某些特定情況下，如測(cè)試或特定功能需求，我們?nèi)匀豢梢允褂盟?/p>
章節(jié)二：使用XMLHttpRequest配合特殊URL進(jìn)行通知
在這種實(shí)現(xiàn)方式中，我們利用XMLHttpRequest發(fā)送同步請(qǐng)求，并通過(guò)構(gòu)造特殊的URL來(lái)通知應(yīng)用層。應(yīng)用層在接收到這種請(qǐng)求時(shí)，會(huì)執(zhí)行特定功能，并將結(jié)果作為響應(yīng)返回。這樣，我們就可以通過(guò)XMLHttpRequest的send方法發(fā)送請(qǐng)求，并在請(qǐng)求完成后，通過(guò)status和responseText獲取結(jié)果。
章節(jié)三：梳理整體思路
我們的主要思路是利用同步XMLHttpRequest發(fā)送請(qǐng)求，并通過(guò)特殊URL通知應(yīng)用層。應(yīng)用層在接收到請(qǐng)求后，會(huì)執(zhí)行相應(yīng)功能并返回結(jié)果。然后，我們可以通過(guò)XMLHttpRequest的屬性和方法獲取和使用這些結(jié)果。
章節(jié)四：iOS中的請(qǐng)求攔截機(jī)制
在iOS中，雖然我們無(wú)法通過(guò)UIWebViewDelegate來(lái)攔截XMLHttpRequest請(qǐng)求，但我們還有其他方式來(lái)實(shí)現(xiàn)請(qǐng)求攔截。其中之一就是通過(guò)NSURLCache。NSURLCache是iOS中用于實(shí)現(xiàn)自定義緩存的類。當(dāng)我們創(chuàng)建自定義的NSURLCache子類對(duì)象，并設(shè)置為全局緩存管理器時(shí)，所有的請(qǐng)求都會(huì)先到這里進(jìn)行檢查，看是否有緩存可用（如果你沒(méi)有禁用緩存的話）。我們可以利用這個(gè)特性來(lái)攔截接口調(diào)用請(qǐng)求，執(zhí)行并返回?cái)?shù)據(jù)。
章節(jié)五：探索其他攔截方式——NSURLProtocol
除了NSURLCache，iOS還提供了另一種攔截請(qǐng)求的方式——NSURLProtocol。這是一個(gè)更底層的網(wǎng)絡(luò)訪問(wèn)控制類，可以用來(lái)攔截、修改或重定義網(wǎng)絡(luò)請(qǐng)求。通過(guò)創(chuàng)建自定義的NSURLProtocol子類，我們可以對(duì)網(wǎng)絡(luò)請(qǐng)求進(jìn)行深度控制，包括攔截XMLHttpRequest請(qǐng)求。這種方式可能需要更復(fù)雜的編程技能，但它提供了更大的靈活性和控制力。
一、引言
網(wǎng)絡(luò)請(qǐng)求的緩存處理
在數(shù)字時(shí)代，網(wǎng)絡(luò)請(qǐng)求的緩存處理是提升應(yīng)用性能的關(guān)鍵環(huán)節(jié)。對(duì)于特定的GET請(qǐng)求，我們需要進(jìn)行定制化的緩存響應(yīng)處理，以優(yōu)化用戶體驗(yàn)。
二、請(qǐng)求方法識(shí)別
識(shí)別HTTP請(qǐng)求方法
我們需要判斷傳入的請(qǐng)求是否為GET方法。如果不是，則按照默認(rèn)方式處理緩存響應(yīng)。這是為了確保只有特定的GET請(qǐng)求才會(huì)觸發(fā)我們的自定義處理邏輯。
三、URL路徑與查詢分析
分析URL路徑與查詢參數(shù)
獲取請(qǐng)求的URL、路徑和查詢參數(shù)。如果路徑或查詢參數(shù)缺失，則按照默認(rèn)方式處理緩存響應(yīng)。這一步是為了確保我們的處理邏輯只在完整的URL請(qǐng)求下觸發(fā)。
四、特殊路徑處理
特殊路徑下的緩存處理
通過(guò)分析URL路徑，我們可以識(shí)別特定的操作。例如，如果路徑為"__env_get__"或"__env_set__"，則執(zhí)行特定的邏輯。前者用于讀取環(huán)境變量，后者用于寫入環(huán)境變量。這些操作通過(guò)特定的方法`getEnvValueByURL:`和`setEnvValueByURL:`來(lái)實(shí)現(xiàn)。其他路徑則按照默認(rèn)方式處理緩存響應(yīng)。這一設(shè)計(jì)使得我們的緩存處理更加靈活和可定制。
五、日志記錄與結(jié)果返回
日志記錄與結(jié)果反饋
對(duì)于所有的請(qǐng)求，我們都會(huì)記錄日志，包括URL、路徑和查詢參數(shù)。這一步驟有助于我們監(jiān)控和調(diào)試系統(tǒng)的運(yùn)行情況。完成特殊路徑的處理后，返回相應(yīng)的結(jié)果。這些結(jié)果可能是通過(guò)特定的app接口獲取并返回的。需要注意的是，帶有＊號(hào)的注釋行表示執(zhí)行特定的app接口并返回結(jié)果。這一設(shè)計(jì)增強(qiáng)了系統(tǒng)的透明性和可調(diào)試性。
結(jié)語(yǔ)
通過(guò)對(duì)網(wǎng)絡(luò)請(qǐng)求的緩存處理進(jìn)行精細(xì)化設(shè)計(jì)，我們的應(yīng)用能夠更好地適應(yīng)不同的網(wǎng)絡(luò)環(huán)境和用戶需求，提升用戶體驗(yàn)和性能表現(xiàn)。這一設(shè)計(jì)思路體現(xiàn)了現(xiàn)代軟件開(kāi)發(fā)中對(duì)靈活性和可定制性的追求。JavaScript開(kāi)發(fā)App所需知識(shí)與Web App開(kāi)發(fā)與原生App開(kāi)發(fā)的比較
JavaScript開(kāi)發(fā)App需要掌握哪些知識(shí)
隨著JavaScript在Web頁(yè)面中的廣泛應(yīng)用，要想進(jìn)行App開(kāi)發(fā)，以下知識(shí)是必不可少的：
基礎(chǔ)部分
HTML是構(gòu)建App的基礎(chǔ)，掌握基礎(chǔ)的標(biāo)簽和語(yǔ)法是必要的。對(duì)于DHTML，它是JavaScript編程中的宿主對(duì)象，對(duì)其進(jìn)行訪問(wèn)和控制是開(kāi)發(fā)的關(guān)鍵。CSS的樣式設(shè)計(jì)也是提升用戶體驗(yàn)的重要因素。
進(jìn)階知識(shí)
除了上述基礎(chǔ)，后臺(tái)編程語(yǔ)言的掌握，特別是那些與輸出標(biāo)簽相關(guān)的知識(shí)，將有助于與后臺(tái)工程師的順暢合作。對(duì)于XML和數(shù)據(jù)庫(kù)的了解也是必要的，它們?cè)贏pp開(kāi)發(fā)中有著廣泛的應(yīng)用。
在宿主對(duì)象方面，JavaScript不僅僅局限于瀏覽器環(huán)境。了解JavaScript在其他平臺(tái)上的運(yùn)行，如操作系統(tǒng)、Web服務(wù)器等，能夠更好地理解宿主對(duì)象的概念。
至于Flash，了解基本的通訊知識(shí)即可，不必過(guò)于深入。
在框架方面，了解當(dāng)前流行的JavaScript框架，如Yahoo YUI、jQuery、Prototype等，對(duì)于開(kāi)發(fā)會(huì)有很大的幫助。
調(diào)試開(kāi)發(fā)工具也是開(kāi)發(fā)者必備的技能，如Eclipse以及其他專用工具，還有Firebug等瀏覽器插件，都是開(kāi)發(fā)者日常工作的好幫手。
Web App開(kāi)發(fā)和原生App開(kāi)發(fā)哪個(gè)好？
目前市場(chǎng)上的App開(kāi)發(fā)主要有三種方式：原生App、Web App和混合App。對(duì)于開(kāi)發(fā)者而言，了解它們之間的區(qū)別是非常重要的。
功能對(duì)比
原生App是一個(gè)系統(tǒng)性的應(yīng)用程序，可以調(diào)用手機(jī)終端的硬件設(shè)備，如語(yǔ)音、攝像頭、短信、GPS、藍(lán)牙、重力感應(yīng)等。而Web App更多是頁(yè)面展示類的APP，無(wú)法實(shí)現(xiàn)這些功能。
如果追求功能的豐富性和實(shí)用性，原生App更占優(yōu)勢(shì)。
加載速度對(duì)比
原生App的UI元素、數(shù)據(jù)內(nèi)容、邏輯框架均安裝在手機(jī)終端上，訪問(wèn)時(shí)無(wú)需重新下載加載，因此加載速度更快。
而Web App每打開(kāi)一個(gè)頁(yè)面都需要重新加載，訪問(wèn)速度受手機(jī)終端上網(wǎng)的限制。
綜上，Web App開(kāi)發(fā)和原生App開(kāi)發(fā)各有優(yōu)劣。Web App開(kāi)發(fā)具有開(kāi)發(fā)成本較低、易于迭代更新的優(yōu)勢(shì)；而原生App則能提供更好的用戶體驗(yàn)和硬件功能支持。開(kāi)發(fā)者可以根據(jù)具體需求和資源來(lái)選擇合適的方式。 Web APP與原生APP的對(duì)比分析及改進(jìn)建議
一、數(shù)據(jù)加載與用戶體驗(yàn)
Web APP主要依賴于網(wǎng)絡(luò)數(shù)據(jù)加載，其數(shù)據(jù)存儲(chǔ)和處理均在網(wǎng)頁(yè)端進(jìn)行。這種模式下，若數(shù)據(jù)加載不暢，極易導(dǎo)致頁(yè)面卡頓甚至錯(cuò)亂，直接影響到用戶體驗(yàn)。與原生APP相比，Web APP在數(shù)據(jù)加載和處理方面似乎并不占優(yōu)勢(shì)，尤其是在網(wǎng)絡(luò)狀況不佳的環(huán)境下。
二、穩(wěn)定性挑戰(zhàn)
當(dāng)前市場(chǎng)上的Web版APP多基于模板快速開(kāi)發(fā)，雖然模板開(kāi)發(fā)速度快、成本低，但其功能局限、拓展性不足的問(wèn)題逐漸顯現(xiàn)。隨著瀏覽器技術(shù)、前端技術(shù)的不斷進(jìn)步，基于模板的Web APP可能會(huì)出現(xiàn)越來(lái)越多的兼容性和穩(wěn)定性問(wèn)題。相比之下，原生APP采用更為成熟的技術(shù)棧，確保了更穩(wěn)定的性能表現(xiàn)，尤其在長(zhǎng)期運(yùn)營(yíng)和持續(xù)迭代的過(guò)程中。
三、功能拓展與市場(chǎng)需求
原生APP的技術(shù)基礎(chǔ)堅(jiān)實(shí)，能夠支持更復(fù)雜的功能需求和業(yè)務(wù)邏輯拓展。而Web版的APP，由于其基于網(wǎng)頁(yè)的特性，功能相對(duì)固定且難以拓展。盡管其安裝包小、更新成本低，具有一定的市場(chǎng)吸引力，但在需要復(fù)雜交互或高性能的場(chǎng)景下，往往無(wú)法與原生APP競(jìng)爭(zhēng)。
四、市場(chǎng)定位與競(jìng)爭(zhēng)優(yōu)勢(shì)
Web APP因其跨平臺(tái)的優(yōu)勢(shì)，尤其在簡(jiǎn)單圖文閱讀類應(yīng)用中表現(xiàn)出色。對(duì)于這類應(yīng)用，用戶對(duì)于性能的要求相對(duì)較低，更注重便捷性和即時(shí)性。對(duì)于需要高性能、復(fù)雜交互的應(yīng)用場(chǎng)景，原生APP無(wú)疑更具優(yōu)勢(shì)。其出色的穩(wěn)定性和功能拓展性，使其能夠應(yīng)對(duì)更廣泛的用戶需求。
五、未來(lái)發(fā)展趨勢(shì)
隨著技術(shù)的不斷進(jìn)步和用戶需求的變化，原生APP和Web APP的融合或許將成為未來(lái)的趨勢(shì)。利用Web技術(shù)構(gòu)建高效的前端界面，結(jié)合原生技術(shù)確保應(yīng)用的穩(wěn)定性和性能，可能會(huì)成為開(kāi)發(fā)者們的首選方案。對(duì)于不同場(chǎng)景和需求的應(yīng)用，選擇最適合的開(kāi)發(fā)方式和技術(shù)棧，將是確保應(yīng)用成功的關(guān)鍵。
Web APP和原生APP各有優(yōu)劣，關(guān)鍵在于如何根據(jù)應(yīng)用的具體需求和場(chǎng)景選擇合適的開(kāi)發(fā)方式。在提升用戶體驗(yàn)、確保應(yīng)用穩(wěn)定性的還需關(guān)注功能拓展性和市場(chǎng)需求的變化。
