写一个易于维护使用方便性能可靠的Hybrid框架(二)
栏目: JavaScript · 发布时间: 6年前
内容简介:继上一篇之后,我反复思来想去,我下一篇该怎么写,那么想法有了,我应该怎么去落实,框架在代码层面我要怎么设计,怎么样才能使用起来尽可能的方便,那么好吧,我深深的觉得,上一篇我给自己挖了个大坑,最近的思想一直依托于Cordova框架的设计模式,说实话想跳出来很难,我真的很难很难想出一个比它插件化部分更好设计,所以插件化这一块,我依旧延续Cordova思想,精简掉平时工作用不到的部分,偏向于更方便的方向设计,所以,今天我写了个简短的demo,基本实现了js和native端的通讯,下面依托demo来写我的Hybr
继上一篇之后,我反复思来想去,我下一篇该怎么写,那么想法有了,我应该怎么去落实,框架在代码层面我要怎么设计,怎么样才能使用起来尽可能的方便,那么好吧,我深深的觉得,上一篇我给自己挖了个大坑,最近的思想一直依托于Cordova框架的设计模式,说实话想跳出来很难,我真的很难很难想出一个比它插件化部分更好设计,所以插件化这一块,我依旧延续Cordova思想,精简掉平时工作用不到的部分,偏向于更方便的方向设计,所以,今天我写了个简短的demo,基本实现了js和native端的通讯,下面依托demo来写我的Hybrid框架第二篇,先聊聊native端插件化部分。
正题
在框架使用层面和js-bridge方面,依旧延续上篇 写一个易于维护使用方便性能可靠的Hybrid框架(一) 提到的两篇博文,也就是框架内不提供webView,webView由使用者自己实现,webView的一切我不关心,我只负责给你的webView提供Hybrid能力。第二点是通信上基于 WKWebView的addScriptMessageHandler
方式,弃用UIWebView的URL拦截方式。
还是简单说一下WKWebView的 addScriptMessageHandler
的通信问题,只是简单介绍下就不详细讲解它的通信过程了,WKWebView初始化时,有一个参数叫 configuratio
n,它是 WKWebViewConfiguration
类型的参数,而 WKWebViewConfiguration
有一个属性叫 userContentController
,它又是 WKUserContentController
类型的参数。 WKUserContentController
对象有一个方法 -addScriptMessageHandler:name:
,第一个参数是 userContentController
的代理对象,第二个参数对应着js端 postMessage
的对象(本篇看完你就明白了没啥说的)。既然设置了代理对象,当然还要实现它的代理方法,也就是W KScriptMessageHandler
协议提供的 userContentController:didReceiveScriptMessage:
函数,有了他俩,我们就可以进行通信了,WKWebView通信就是这么简单。
先看一下我的Hybrid框架是怎么使用的,当然思想还是基于上篇提到的大佬,直接看代码吧:
#import "ViewController.h" #import <WebKit/WebKit.h> #import "SHRMWebViewEngine.h" @interface ViewController ()<WKNavigationDelegate> @property (strong, nonatomic) WKWebView *webView; @end @implementation ViewController - (void)viewDidLoad { [super viewDidLoad]; WKWebViewConfiguration *configuration = [[WKWebViewConfiguration alloc] init]; WKPreferences *preferences = [WKPreferences new]; preferences.javaScriptCanOpenWindowsAutomatically = YES; preferences.minimumFontSize = 40.0; configuration.preferences = preferences; self.webView = [[WKWebView alloc] initWithFrame:self.view.frame configuration:configuration]; /***/ SHRMWebViewEngine *jsBridge = [[SHRMWebViewEngine alloc] init]; jsBridge.delegate = self; [jsBridge bindBridgeWithWebView:self.webView]; /***/ NSString *urlStr = [[NSBundle mainBundle] pathForResource:@"index.html" ofType:nil]; NSURL *fileURL = [NSURL fileURLWithPath:urlStr]; if (@available(iOS 9.0, *)) { [self.webView loadFileURL:fileURL allowingReadAccessToURL:fileURL]; } else { // Fallback on earlier versions } [self.view addSubview:self.webView]; } @end 复制代码
这其实应该是框架使用者要编写的代码,看上去很常规,中间多了三行代码, SHRMWebViewEngine *jsBridge = [[SHRMWebViewEngine alloc] init];jsBridge.delegate = self;[jsBridge bindBridgeWithWebView:self.webView];
,实际上这三行代码就让你的webView具有了Hybird的能力了,用起来是不是很方便,其实这没啥说的,这个思想也是之前大佬提过的了,我就当是做了个总结吧。那再通过代码看一下我在里面都做了什么吧。
#import "SHRMWebViewEngine.h" #import "SHRMWebViewDelegate.h" #import "SHRMWebViewHandleFactory.h" @interface SHRMWebViewEngine () @property (nonatomic, strong) SHRMWebViewDelegate *webViewDelegate; @property (nonatomic, strong) SHRMWebViewHandleFactory *webViewhandleFactory; @end @implementation SHRMWebViewEngine - (instancetype)init { if (self = [super init]) { _webViewhandleFactory = [[SHRMWebViewHandleFactory alloc] initWithWebViewEngine:self]; _webViewDelegate = [[SHRMWebViewDelegate alloc] initWithWebViewEngine:self]; } return self; } - (void)bindBridgeWithWebView:(WKWebView *)webView { self.webView = webView; if (![_delegate conformsToProtocol:@protocol(WKUIDelegate)]) { self.webView.UIDelegate = _webViewDelegate; } if (![_delegate conformsToProtocol:@protocol(WKNavigationDelegate)]) { self.webView.navigationDelegate = _webViewDelegate; } webView.configuration.userContentController = [[WKUserContentController alloc] init]; [webView.configuration.userContentController addScriptMessageHandler:self name:@"SHRMWKJSBridge"]; } - (void)userContentController:(WKUserContentController *)userContentController didReceiveScriptMessage:(WKScriptMessage *)message { if ([message.body isKindOfClass:[NSArray class]]) { [_webViewhandleFactory handleMsgCommand:message.body]; } } #pragma mark - SHRMWebViewProtocol - (void)sendPluginResult:(NSString *)result callbackId:(NSString*)callbackId { NSString *jsStr = [NSString stringWithFormat:@"fetchComplete('(%@)','%@')",callbackId,result]; [self.webView evaluateJavaScript:jsStr completionHandler:^(id _Nullable result, NSError * _Nullable error) { NSLog(@"%@----%@",result, error); }]; } - (void)runInBackground:(void (^)(void))block { dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), block); } #pragma mark - dealloc - (void)dealloc { [self.webView.configuration.userContentController removeScriptMessageHandlerForName:@"SHRMWKJSBridge"]; } @end 复制代码
1. SHRMWebViewHandleFactory
对象,负责执行native端插件的调用过程,内部将来会做成工厂。
2. SHRMWebViewDelegate
对象,负责WKWebView的代理实现,我的思路是如果开发者没有自己实现WKWebView的代理,那么默认我会走框架内提供的代理方法,包括进度条等。
3. bindBridgeWithWebView:
函数做了webView的绑定和代理的绑定,主要还是为了拿到想要获得Hybrid能力的webView。拿到这个webView,我们就可以做接下来的通信了。 SHRMWKJSBridge
为自定义的js端postMessage的对象(和上面提到的匹配上了),是jsBridge的统一入口,这个 SHRMWKJSBridge
一会下面还会说到,再对比下就更清楚了。
4. userContentController:didReceiveScriptMessage:
拿到js传递过来的参数,参数怎么传递过来的一会会粘js端的代码。
5. SHRMWebViewProtocol:
提供了两个接口,一个是native回调js接口,一个是开辟子线程执行耗时操作接口。通过代码可以看到native回调js使用的是 evaluateJavaScript:completionHandler:
函数,这是WKWebView之后提供的,天然异步执行,不需要像UIWebView那样要开发者手动处理js端回调native端的异步问题。
那么实际上 SHRMWebViewEngine
核心类目前只做了这几件事情,当然这只是我今天写的demo,后续会对代码进行优化和对通信调优,我们先一步一步来。
@protocol SHRMWebViewProtocol <NSObject> /** native call back js @param result simulate data @param callbackId callbackId */ - (void)sendPluginResult:(NSString *)result callbackId:(NSString*)callbackId; /** background @param block long running */ - (void)runInBackground:(void (^)(void))block; @end 复制代码
这个就是我们刚才看到的接口定义的地方,今天一直在想,Cordova在插件处理的时候,我们自定义插件都是需要继承自 CDVPlugin
基类的(没用过没关系,就理解为一个提供了js回调native接口的基类就行了),它的回调接口实现类CDVPlugin基类里面有提供,所以它可以通过CDVPlugin基类来进行native端对js的回调。关于这一块我做了简单改造,移除了CDVPlugin基类,因为我们的插件完全可以不用继承任何其他的类,只需要继承自NSObject就好,还是看代码:
@class SHRMMsgCommand; @interface SHRMFetchPlugin : NSObject - (void)nativeFentch:(SHRMMsgCommand *)command; @end @implementation SHRMFetchPlugin - (void)nativeFentch:(SHRMMsgCommand *)command { NSString *method = [command argumentAtIndex:0]; NSString *url = [command argumentAtIndex:1]; NSString *param = [command argumentAtIndex:2]; NSLog(@"(%@):%@,%@,%@",command.callbackId, method, url, param); [command.delegate sendPluginResult:@"fetch success" callbackId:command.callbackId]; } @end 复制代码
不可避免,我还是需要 SHRMMsgCommand
这个对象,不然插件无法和框架构成联系。 SHRMMsgCommand
上面没有说干嘛的,它实际上只是js传递过来的参数接受者,存储着参数信息供插件使用。 command.delegate
实际是 id <SHRMWebViewProtocol> delegate
类型的对象,因为我目前是把回调接口是现在了 SHRMWebViewEngine
里面,实际上这个delegate就是它。这么做的目的主要是为了解耦合,这样 SHRMMsgCommand
完全不必引用 SHRMWebViewEngine
的头文件了。这个就是模拟网络请求native端提供的插件,什么是插件,顾名思义,就是不跟框架产生耦合,实际上框架内是不需要引入SHRMFetchPlugin的,如果说哪天这个插件不用了,直接把这个类删了就可以了。
到这里我们在native端的简单插件化基本实现了,js与native间基于WKWebView的通信也实现了。这样我在js端直接调用
window.webkit.messageHandlers.SHRMWKJSBridge.postMessage(['13383445','SHRMFetchPlugin','nativeFentch',['post','https:www.baidu.com','user']]); 复制代码
就可以实现js call native了, SHRMWKJSBridge
(这个到这里就很明白了吧)就是我上面定义的发送 postMessage
的对象,当然native回调js是需要js提供一个全局函数供给native来调用的,我在demo里面定义了一个 fetchComplete
函数:
function fetchComplete(id,result) { } 复制代码
再来看下上面回调js的代码:
- (void)sendPluginResult:(NSString *)result callbackId:(NSString*)callbackId { NSString *jsStr = [NSString stringWithFormat:@"fetchComplete('(%@)','%@')",callbackId,result]; [self.webView evaluateJavaScript:jsStr completionHandler:^(id _Nullable result, NSError * _Nullable error) { NSLog(@"%@----%@",result, error); }]; } 复制代码
一目了然了吧,这样整个调用过程就结束了,当然 window.webkit.messageHandlers.SHRMWKJSBridge.postMessage
和 fetchComplete
后期我们会把他们单独封装起来,对于前端开发者来说只会给他们统一的调用接口和回调接口,这个后面再说。如果说只是为了简单实现功能其实到这里就可以了,但是毕竟我们是在构建一个框架,所以这样是远远不行的,二篇就先到这吧(PS:主要是demo就写到了这,另外时候不早了得睡了)。
总结
总结一下,本篇简单实现了native端的插件化,基于WKWebView通信的构建,框架内不提供webView的实现三个功能这与我们上一篇的预期也是相符合的,但是远远不够,那么我们后续第三篇再继续。那么下篇会着重介绍native端插件的可配置和js端接口的封装(这点真是难为了我这个未入门的前端了)。
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网
猜你喜欢:- 写一个易于维护使用方便性能可靠的Hybrid框架(一)
- 写一个易于维护使用方便性能可靠的Hybrid框架(三)
- 使用drawio进行画图真的很方便
- 单元测试中使用Spring的ReflectionTestUtils更方便
- LaravelPlus —— 基于 Laravel 魔改,为方便实际业务使用
- 使用ImpromptuInterface反射库方便的创建自定义DfaGraphWriter
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。