以WKWebView为媒介解决一个实际项目中的硬需求。这个标题几乎是所有iOS开发者的必修课但它背后隐藏的细节比大多数人想象的多得多。今天这篇东西我不讲API怎么查文档只讲在项目里真正跑通、踩平坑之后留下的那套最稳的写法以及每一步背后的逻辑。1. 项目背景与交互方案选型思路先说清楚这个场景到底在解决什么问题。现在做原生App动不动就要嵌H5页面无论是运营活动、电商详情还是复杂表单WebView都是绕不开的。原生代码和网页里的JavaScript互相通信是实现混合开发的基础能力。而WKWebView从iOS 8开始取代了老旧的UIWebView内存占用小、加载速度快、自带JS高性能引擎说白了就是官方亲儿子到现在已经完全看不到UIWebView的影子了。OC与JS交互本质上是两种语言运行在两个完全隔离的进程空间里。OC语言跑在App的native层拥有系统能力、私有数据、完整API权限JS跑在WebContent进程里受沙箱限制只能操作DOM和浏览器提供的API。交互的核心就是在两者之间建立一道受控的桥梁让数据以安全的方式跨过这道边界。在我处理过的项目里交互需求大致分三种网页需要获取用户原生信息比如设备型号、版本号、登录令牌这时候OC主动“塞”给JS网页触发了按钮点击需要原生响应比如打开相机、调起支付、跳转新页面这时候JS主动“喊”OC双方互传数据比如H5带着业务参数来OC处理完又带回结果去。方案选型上业界主流就两条路一是用JSBridge框架比如某著名开源桥接库成熟但重适合大型项目二是自己手写一套轻量桥接代码量不大、完全可控适合大多数中小型项目。我偏向后者理由很简单依赖越少出问题时排查越容易而且苹果官方API已经提供了相当完善的基础能力没必要把几十KB的库硬塞进包体里。这个方案的核心能力点在于利用WKScriptMessageHandler接收JS发来的消息利用evaluateJavaScript(_:completionHandler:)执行JS代码。看懂这两个API的底层实现所有交互业务都能往里面套。2. 基础配置与环境搭建2.1 从UIWebView迁移到WKWebView的必经之路如果你是从老项目翻新过来的第一步就是把UIWebView全部替换成WKWebView。别小看这一步两者虽然用起来都差不多但底层完全不同。UIWebView的JS执行速度慢、内存管理一塌糊涂而且UIWebView的JS上下文也就是JSContext没法稳定监听JS异常和异步回调。WKWebView把这些坑基本都填平了。创建一个基础WKWebView代码非常直白#import WebKit/WebKit.h WKWebViewConfiguration *config [[WKWebViewConfiguration alloc] init]; // 允许内联播放视频但禁止自动播放 config.allowsInlineMediaPlayback YES; if (available(iOS 10.0, *)) { config.mediaTypesRequiringUserActionForPlayback WKAudiovisualMediaTypeAll; } // 偏好设置JS开关 WKPreferences *preferences [[WKPreferences alloc] init]; preferences.javaScriptEnabled YES; preferences.javaScriptCanOpenWindowsAutomatically YES; config.preferences preferences; WKWebView *webView [[WKWebView alloc] initWithFrame:self.view.bounds configuration:config]; webView.navigationDelegate self; webView.UIDelegate self; [self.view addSubview:webView];这里有个容易忽略的点preferences.javaScriptCanOpenWindowsAutomatically如果设成NO那么JS里调用window.open就无声无息地失败排查起来特别隐蔽。加载远端HTML没问题但如果涉及到本地HTML资源要注意WKWebView不允许直接读file://协议必须用loadFileURL:allowingReadAccessToURL:方法加载否则页面空白。2.2 一定要做的UserAgent定制很多H5端为了区分App环境会校验UserAgent里的自定义标识。WKWebView默认的UA只是Safari的完全看不出是原生壳。定制UA的方法比较隐秘正常情况下在WKWebView初始化之前设置// 获取默认UA NSString *originalUA [[WKWebView new] valueForKey:userAgent]; NSString *customUA [originalUA stringByAppendingString: AppName/1.0.0]; [[NSUserDefaults standardUserDefaults] registerDefaults:{UserAgent: customUA}];注意这个设置必须在创建webView之前而且[[WKWebView new] valueForKey:userAgent]这段代码会在主线程动态生成一个webView如果没设置成功后面H5识别不了环境就会走错分支。3. JS调用OC的实现机制与实操3.1 WKScriptMessageHandler的工作原理这是整个交互链路里最有技术含量的一环。JS调用OC不是直接调用而是借助一个叫WKUserContentController的中介。OC先注册一个“命名通道”然后把通道名注入到JS的window.webkit.messageHandlers对象里。JS那边发起调用时消息会通过IPC机制传给原生层由代理方法接收。注册代码WKUserContentController *userContentController [[WKUserContentController alloc] init]; [userContentController addScriptMessageHandler:self name:nativeBridge]; config.userContentController userContentController;这行代码一执行JS环境里就自动出现了window.webkit.messageHandlers.nativeBridge这个对象。JS发消息的时候只需要这样写window.webkit.messageHandlers.nativeBridge.postMessage({ action: openCamera, params: { source: profile } });执行完postMessage之后OC这边的代理方法就跟闹钟一样响- (void)userContentController:(WKUserContentController *)userContentController didReceiveScriptMessage:(WKScriptMessage *)message { if ([message.name isEqualToString:nativeBridge]) { // message.body 就是上面传下来的对象 NSDictionary *payload (NSDictionary *)message.body; NSString *action payload[action]; // 分发到对应处理逻辑 } }这里要提醒一句message.body可以接收任意类型数字、字符串、字典、数组都可以但强烈建议统一用字典格式并且固定为{action: xxx, params: {...}}这种结构。别问为什么我接手过一个项目JS那边传参格式五花八门一个规范不统一OC这边解析逻辑能写成屎山。交互接口的报文格式跟服务端API一样必须一视同仁地设计。3.2 处理完JS消息后的响应回调很多场景JS那边不只是“通知”OC还需要OC给个返回值。比如JS要查询APP登录状态处理完之后要告诉JS“是”或“否”。最简单直接的方案是OC拿到回执后直接再执行一段JS回调代码NSString *jsCallback [NSString stringWithFormat:window.onNativeResponse window.onNativeResponse(%), resultJSONString]; [webView evaluateJavaScript:jsCallback completionHandler:nil];但这种方式有个致命伤回调函数名写死了。如果页面同时有多个交互并发比如用户快速点击了好几个按钮每个回调都往window.onNativeResponse塞值H5端根本分不清哪个回执对应哪个请求。更稳的方案是采用回调ID机制JS发消息时自带一个随机生成的callbackIdvar requestId Date.now().toString(36) Math.random().toString(36).slice(2); window.webkit.messageHandlers.nativeBridge.postMessage({ action: checkLoginStatus, params: {}, callbackId: requestId }); window.bridgeCallbacks window.bridgeCallbacks || {}; window.bridgeCallbacks[requestId] function(result) { /* 处理结果 */ };OC处理完后把callbackId原样返回NSString *jsCallback [NSString stringWithFormat:window.bridgeCallbacks[%] window.bridgeCallbacks[%](%), callbackId, callbackId, resultJSONString];这样每个请求都有唯一IDH5端就能精确匹配到对应的回调闭包彻底解决并发混乱问题。3.3 常见参数传递的类型陷阱JS传递多层嵌套的字典时有个极其容易踩的坑如果参数里包含NSNull类型OC端做字典转JSON字符串时会直接崩溃。JS的null到了OC里变成NSNull而NSJSONSerialization只支持NSString、NSNumber、NSArray、NSDictionary、NSNull这几种类型如果传了其他对象或者字典里有null序列化成JSON时没问题但反序列化回字典后取值的逻辑容易忽略空值判断。我的习惯是在所有入口做一层“净化”// 递归去除NSNull - (id)removeNullObjects:(id)data { if ([data isKindOfClass:[NSDictionary class]]) { NSMutableDictionary *mutableDict [NSMutableDictionary dictionary]; for (NSString *key in data) { id value [self removeNullObjects:data[key]]; if (value) { mutableDict[key] value; } } return mutableDict; } else if ([data isKindOfClass:[NSArray class]]) { NSMutableArray *mutableArray [NSMutableArray array]; for (id item in data) { id cleanItem [self removeNullObjects:item]; if (cleanItem) { [mutableArray addObject:cleanItem]; } } return mutableArray; } return data; }这个removeNullObjects:方法我会放在所有JS消息处理的入口先跑一遍脏数据在起点就拦掉后面业务逻辑就干净得多。4. OC调用JS的实现与细节控制4.1 evaluateJavaScript的正确打开方式OC调用JS苹果给的标准方法是evaluateJavaScript。这个方法可以执行任意JS语句并且通过执行结果拿到返回值。最简单的用法[webView evaluateJavaScript:document.title completionHandler:^(id _Nullable result, NSError * _Nullable error) { // result 就是页面标题 }];要注意的是这个方法的回调不在主线程UI操作必须手动切回主线程。刻意写成这样来演示一下[webView evaluateJavaScript:getUserInfo() completionHandler:^(id result, NSError *error) { dispatch_async(dispatch_get_main_queue(), ^{ // 在这里处理UI更新 }); }];JS里的函数返回值无论是字符串、数字、布尔值还是JSON对象只要JSON.stringify能出来的类型evaluateJavaScript的result都能原样拿到这个衔接得很顺手。但有个大坑如果JS函数返回的是undefinedresult就是nilerror反而是nil别把error当成功依据。要判断执行成功得同时看result是否为nil。4.2 构造JS代码字符串时的转义细节拼接JS字符串是OC调用JS时最容易翻车的地方。好多新人在这一步被整疯因为字符串里该转义的地方没转义不该转义的却画蛇添足。原则是在OC里拼接JS代码JS字符串字面量内的引号必须转义但OC的字符串包裹符要避免冲突。举个例子要传一个用户名字符串给JS函数NSString *userName 张三; NSString *jsCode [NSString stringWithFormat:updateUserName(%), userName]; [webView evaluateJavaScript:jsCode completionHandler:nil];这段代码初看没问题但万一userName本身包含单引号或换行符JS代码就被炸了。更稳妥的方式是用JSON字符串作为中间载体因为NSJSONSerialization生成的JSON字符串天然就是合法的JS字面量。NSDictionary *userInfo {name: userName, age: 18}; NSError *jsonError; NSData *jsonData [NSJSONSerialization dataWithJSONObject:userInfo options:0 error:jsonError]; NSString *jsonString [[NSString alloc] initWithData:jsonData encoding:NSUTF8StringEncoding]; // jsonString 形如 {name:张三,age:18} NSString *jsCode [NSString stringWithFormat:updateUserInfo(%), jsonString]; [webView evaluateJavaScript:jsCode completionHandler:nil];把JSON数据直接作为JS的对象字面量传入这招是从实际项目中打出来的省掉了所有转义神坑。4.3 页面加载完成的时机配合OC调用JS有个天然的时序问题如果页面还没加载完就要执行JS脚本会找不到函数定义。所以通用做法是在webView:didFinishNavigation:代理回调后再去跟webView沟通。- (void)webView:(WKWebView *)webView didFinishNavigation:(WKNavigation *)navigation { // 只有在这里执行evaluateJavaScript才稳妥 [webView evaluateJavaScript:onAppReady() completionHandler:nil]; }但有些场景比如JS报错后需要降级处理或者页面内自己管理生命周期那就需要JS侧配合主动暴露一个“ready”信号OC这边等信号来了再发数据。这更像双方握手协议而不是单方面套时机。5. 关键场景与完整代码示例5.1 一个通用JSBridge的抽象为了把上面的所有逻辑收拢到一起我在项目里会封装一个JSBridgeManager类。它负责消息注册、分发、回调管理以及OC向JS发送数据的功能。这种封装思路适合所有中等规模的项目避免把交互代码散落在控制器里。先看头文件接口#import Foundation/Foundation.h #import WebKit/WebKit.h NS_ASSUME_NONNULL_BEGIN typedef void(^JSBridgeHandler)(NSDictionary *payload, void(^callback)(NSDictionary *response)); interface JSBridgeManager : NSObject WKScriptMessageHandler - (instancetype)initWithWebView:(WKWebView *)webView; - (void)registerHandler:(NSString *)action handler:(JSBridgeHandler)handler; - (void)callJS:(NSString *)functionName data:(NSDictionary *)data; - (void)removeAllHandlers; end NS_ASSUME_NONNULL_END这个接口把“通道名”和“handler字典”解耦开调用方只需关心业务action不需要理会底层消息机制。这样写还有一个好处如果以后要换桥接库换掉manager内部实现即可业务层纹丝不动。5.2 实现里的细节要点再看实现要点interface JSBridgeManager () property (nonatomic, weak) WKWebView *webView; property (nonatomic, strong) NSMutableDictionaryNSString *, JSBridgeHandler *handlers; end implementation JSBridgeManager - (instancetype)initWithWebView:(WKWebView *)webView { self [super init]; if (self) { _webView webView; _handlers [NSMutableDictionary dictionary]; // 注册消息通道 [webView.configuration.userContentController addScriptMessageHandler:self name:nativeBridge]; } return self; } - (void)registerHandler:(NSString *)action handler:(JSBridgeHandler)handler { self.handlers[action] handler; } - (void)userContentController:(WKUserContentController *)userContentController didReceiveScriptMessage:(WKScriptMessage *)message { if (![message.name isEqualToString:nativeBridge]) return; NSDictionary *body (NSDictionary *)message.body; if (![body isKindOfClass:[NSDictionary class]]) return; NSString *action body[action]; NSString *callbackId body[callbackId]; NSDictionary *params body[params]; JSBridgeHandler handler self.handlers[action]; if (!handler) { // 未注册的action可记录日志 return; } handler(params, ^(NSDictionary *response) { // 根据回调ID回传结果给JS if (callbackId self.webView) { NSError *jsonError; NSData *jsonData [NSJSONSerialization dataWithJSONObject:response options:0 error:jsonError]; if (jsonError) return; NSString *jsonString [[NSString alloc] initWithData:jsonData encoding:NSUTF8StringEncoding]; NSString *jsCode [NSString stringWithFormat:window.bridgeCallbacks window.bridgeCallbacks[%] window.bridgeCallbacks[%](%), callbackId, callbackId, jsonString]; dispatch_async(dispatch_get_main_queue(), ^{ [self.webView evaluateJavaScript:jsCode completionHandler:nil]; }); } }); } - (void)callJS:(NSString *)functionName data:(NSDictionary *)data { NSError *jsonError; NSData *jsonData [NSJSONSerialization dataWithJSONObject:data options:0 error:jsonError]; if (jsonError) return; NSString *jsonString [[NSString alloc] initWithData:jsonData encoding:NSUTF8StringEncoding]; NSString *jsCode [NSString stringWithFormat:%(%), functionName, jsonString]; dispatch_async(dispatch_get_main_queue(), ^{ [self.webView evaluateJavaScript:jsCode completionHandler:nil]; }); } - (void)removeAllHandlers { [self.handlers removeAllObjects]; [self.webView.configuration.userContentController removeScriptMessageHandlerForName:nativeBridge]; } end这段代码有几个用心的地方webView用weak修饰避免双向循环引用回调通过callbackId精确匹配所有JS执行都切回主线程。如果你的项目交互风格跟这个一致可以整段抄走再根据业务扩展action即可。5.3 外部接入示意接入的地方也非常轻self.bridgeManager [[JSBridgeManager alloc] initWithWebView:self.webView]; [self.bridgeManager registerHandler:openCamera handler:^(NSDictionary *payload, void (^callback)(NSDictionary *)) { // 打开相机逻辑 callback({code: 0, message: ok}); }]; [self.bridgeManager registerHandler:share handler:^(NSDictionary *payload, void (^callback)(NSDictionary *)) { // 分享逻辑 callback({code: 0, message: 分享成功}); }];一句话总结所有JS可以调用的原生功能都在这个manager里集中注册不让控制器直接参与这样页面销毁时清理监听关系才干净利落。6. 内存管理与循环引用的大坑6.1 解决ScriptMessageHandler的retain cycle交互模块最隐蔽的炸弹就是内存泄漏。addScriptMessageHandler方法中的handler对象会被WKWebView强引用如果这个对象又强引用了webView形成webView - handler - webView的环页面dismiss后谁也不会释放。实际开发中很多人就直接把控制器self传进去做handler了结果控制器永远不释放严重一点的每打开一个H5页面内存就涨一截多开几个页面直接闪退警告。解决办法就是在页面销毁前必须移除handler而且移除时机一定要卡准。- (void)dealloc { [webView.configuration.userContentController removeScriptMessageHandlerForName:nativeBridge]; }但dealloc本身不可靠更好的做法是在页面可见生命周期专门处理- (void)viewWillDisappear:(BOOL)animated { [super viewWillDisappear:animated]; if (self.isBeingDismissed || self.navigationController.isBeingDismissed) { [self.bridgeManager removeAllHandlers]; } }如果handler本来就放在bridgeManager对象里那就在manager里的removeAllHandlers统一移除外部只管调方法不用记太多细节。6.2 JS回调闭包里引用外部对象的注意点注册handler时回调闭包如果引用了self而闭包又长期保存在manager里也会形成保留环。比如__weak typeof(self) weakSelf self; [self.bridgeManager registerHandler:openCamera handler:^(NSDictionary *payload, void (^callback)(NSDictionary *response)) { __strong typeof(weakSelf) strongSelf weakSelf; [strongSelf openCameraWithParams:payload]; }];对于使用block的地方这种weak-strong模式是最稳妥的。养成习惯别省真出了问题查内存泄漏图查到怀疑人生。7. 问题排查与避坑指南7.1 JS执行报错的常见原因清单交互开发中最常见的当属“JS可以调OC但OC调JS没反应”。排查路径无非这么几条JS函数名写错。这看起来是低级错误但在动态拼接函数名的实现里极易发生比如参数透传来透传去函数名被多套了一层引号。通过evaluateJavaScript的completionHandler里的error信息能迅速定位。调用时机太早页面还没创建函数。这个就必须等didFinishNavigation后再调用或者JS主动告知就绪信号。WKWebView正在加载新页面时执行脚本新的navigation会把旧页面内容替换掉脚本执行对象已经是新页面了。所以如果要跳转得在跳转前先把数据发完。看error信息很重要evaluateJavaScript的NSError里会包含一条非常详细的JavaScript执行异常描述包括异常发生位置和堆栈学会读这个堆栈排查效率能提高一半以上。7.2 应用后台时的JS调用陷阱还有一类问题特别折磨人App切到后台或webView进入无响应状态时evaluateJavaScript的回调永远不执行。这其实不是bug而是系统在某种状态下暂停了JavaScript的执行。我在一个视频播放页面就碰到过页面推入后台JS定时器全停了等回到前台才继续跑。对策很简单重要数据交互尽量App回到前台后再发或者至少不要依赖回调做关键链路的节点判断。7.3 拦截链接与解决新窗口无法打开WKWebView默认不允许window.open方法弹新页面因为缺少UIdelegate的实现。很多H5页面里点“查看帮助”按钮跳了个新窗口结果原生端一片空白。解决办法是实现UIDelegate代理- (WKWebView *)webView:(WKWebView *)webView createWebViewWithConfiguration:(WKWebViewConfiguration *)configuration forNavigationAction:(WKNavigationAction *)navigationAction windowFeatures:(WKWindowFeatures *)windowFeatures { // 打开新页面样式由自己控制 if (!navigationAction.targetFrame.isMainFrame) { [webView loadRequest:navigationAction.request]; } return nil; }这段代码的处理逻辑类似“拦截所有非主框架的跳转统一在当前页面加载”实践中很有效。7.4 常用排查工具与标志推荐一个硬核技巧在WKWebView里动态注入Log函数让H5的日志串回原生控制台。在WKUserScript注入时机为WKUserScriptInjectionTimeAtDocumentStart时加入如下代码window.console.log function(...args) { window.webkit.messageHandlers.nativeBridge.postMessage({ action: consoleLog, params: { log: args.map(String).join( ) } }); };OC端注册一个consoleLog的handler把日志直接打出来。以后H5跑了什么逻辑原生这边一眼就能看到不用每次都开Safari开发者工具远程调试。另外WKWebView还自带一个网页内容检查器在debug环境下可以通过webView.setValue:forKey:开启一些调试开关不过在项目发布前一定要确认关掉了。这个用起来比较深度日常开发用前面那套方案基本就够了。8. 性能优化与安全加固扩展8.1 拦截与禁用危险方法只要暴露了桥接通道理论上面向公众的H5都可以调用。就算不是恶意页面里不小心写了个postMessage传了超大对象OC这边也会很不爽。所以桥接层必须做安全校验。第一层校验是域名校验只允许当前正在加载可信域名页面时才响应对应消息。- (void)userContentController:(WKUserContentController *)userContentController didReceiveScriptMessage:(WKScriptMessage *)message { if (![message.name isEqualToString:nativeBridge]) return; NSURL *pageURL self.webView.URL; NSString *host pageURL.host; if (![host isEqualToString:trusted.example.com]) { return; } // 其余处理 }第二层校验是参数校验看看action是否在白名单内参数里有没有非法的URL scheme等。这里提到的“可信域名”是个示例实际项目替换成自己的可信域名即可。8.2 阻止自动播放与弹窗的体验问题还有很多交互体验细节容易被忽略。有些H5页面一进来视频就开始带声音地播放或者弹窗不停。这通常需要靠配置和UIDelegate双管齐下在WKWebViewConfiguration里设置mediaTypesRequiringUserActionForPlayback为所有类型禁止任何媒体自动播放实现webView:runJavaScriptAlertPanelWithMessage:initiatedByFrame:completionHandler:时自己要处理alert弹窗。如果忽略这个方法JS的alert()会直接无效H5的开发人员会找你兴师问罪。- (void)webView:(WKWebView *)webView runJavaScriptAlertPanelWithMessage:(NSString *)message initiatedByFrame:(WKFrameInfo *)frame completionHandler:(void (^)(void))completionHandler { UIAlertController *alert [UIAlertController alertControllerWithTitle:提示 message:message preferredStyle:UIAlertControllerStyleAlert]; [alert addAction:[UIAlertAction actionWithTitle:确定 style:UIAlertActionStyleDefault handler:^(UIAlertAction *action) { completionHandler(); }]]; [self presentViewController:alert animated:YES completion:nil]; }这个代理不实现alert弹窗就不出来很多新人会以为是自己调用姿势不对。9. 交互规范的工程化落地经验9.1 报文协议尽量向服务端API靠拢这套桥接交互本质就是一个私有API。既然是API就得有协议。我建议在项目工程文档里固定一张表把action名称、方向、参数、返回值全部列清楚。像下面这样action方向参数返回值openCameraJS - OCsource: String{code: Int, imageUrl: String}getLoginTokenJS - OC无{code: Int, token: String}updateTitleOC - JStitle: String无onPageReadyOC - JSappVersion: String无这张表不是摆设而是双方联调的契约。谁改了参数表格必须同步更新。我见过不少项目表格躺在文档里吃灰结果接口变了前端后知后觉线上问题一批批出。9.2 按版本号做兼容H5页面在App内嵌容器里版本不随App发版。换句话说App已经上线了1.0但H5页面在1.2甚至2.0的接口已经被服务端偷偷切了。这就必须做版本兼容。我习惯在构造桥接环境时把一个nativeVersion字段注入到JS环境里NSDictionary *envInfo {appVersion: 1.0.0, platform: iOS}; NSString *jsonString [self jsonStringFromDict:envInfo]; NSString *injectJS [NSString stringWithFormat:window.NativeEnv %;, jsonString]; WKUserScript *script [[WKUserScript alloc] initWithSource:injectJS injectionTime:WKUserScriptInjectionTimeAtDocumentStart forMainFrameOnly:YES]; [userContentController addUserScript:script];H5端就可以根据自己的需求判断是否使用新接口或走旧逻辑回退。9.3 日志链路贯通交互问题排查难的不是技术而是双方信息不对称。你的代码里弹了个错误但H5那边完全不知道。我强烈建议交互模块里统一加日志上报OC侧记录所有进出的动作名、时间戳、参数摘要JS侧也埋点一起上报。全网日志一对谁的问题清清楚楚再也不用互相甩锅。10. 项目上线后的复盘与心得这个交互方案在我手上跑过多个版本期间的坑和优化攒了一些肺腑之言。第一桥接协议一定得从业务中来到业务中去。市面上那些万能桥接框架虽然功能齐全但带来的心智负担不小配置项动辄几十个。自己封装一个只满足业务需求的桥代码量控制在两三百行内后维护的人半小时能看懂全貌这比任何“优雅的架构”都实在。第二JS端的所有回调必须有超时兜底逻辑。OC这边处理一个原生能力比如请求相册权限用户可能半天不点击弹窗JS那边就永远等不到回调。这时候H5端一般会有个loading转圈用户等到天荒地老。JS侧对每个桥接请求设置10秒超时超时就显示失败状态交互体验会稳很多。第三多留接口别急着精简。开发过程中常发现H5需要一个当前定位的接口或者一个分享缩略图的接口。这些接口按业务场景登记到协议表里反正复用成本低一次做对后面改起来就顺了。第四别迷信内存泄漏检测工具。桥接循环引用问题工具能检测到的往往晚一步等波及页面性能时已经晚了。最好的办法是形成代码习惯凡是addScriptMessageHandler就必须在对应生命周期移除就像打开文件必须关闭一样。写代码的时候就把规则钉进去别等野指针来教育你。第五WKWebView的后台执行能力是有限的不要期待它像浏览器一样完整。很多H5页面依赖setInterval做轮询切到后台后会被系统自动暂停。如果你的业务强依赖后台轮询比如订单状态查询优先走原生后台请求而不是让页面扛着WebView存活。回头看看这套实现其实没有一个技术点是崭新的。WKScriptMessageHandler、evaluateJavaScript、WKUserScript都是苹果文档里写明的能力。真正的价值在于把它们拼装成一个可维护、可扩展、能落地的工程方案。过程中我最大的体会是交互方案设计得再好也不如双方约定好一个简单直接的协议来得有效。把通信格式固定下来把回调机制设计清楚把内存隐患从源头堵住剩下的业务只是往框架里填代码而已。如果你正打算在新项目里搞OC和JS交互建议从这篇文章里的基础封装开始不要一上来就引第三方库。自己先跑通一次踩过那几个经典的坑你就明白整个链路里哪些地方容易出问题、为什么时机这么重要。这对后续排查线上问题帮助非常大。