写一个易于维护使用方便性能可靠的Hybrid框架（二）—— 插件化

写一个易于维护使用方便性能可靠的Hybrid框架（一）—— 思路构建

写一个易于维护使用方便性能可靠的Hybrid框架（三）—— 配置插件

前言

继上一篇之后，我反复思来想去，我下一篇该怎么写，那么想法有了，我应该怎么去落实，框架在代码层面我要怎么设计，怎么样才能使用起来尽可能的方便，那么好吧，我深深的觉得，上一篇我给自己挖了个大坑，最近的思想一直依托于Cordova框架的设计模式，说实话想跳出来很难，我真的很难很难想出一个比它插件化部分更好设计，所以插件化这一块，我依旧延续Cordova思想，精简掉平时工作用不到的部分，偏向于更方便的方向设计，所以，今天我写了个简短的demo，基本实现了js和native端的通讯，下面依托demo来写我的Hybrid框架第二篇，先聊聊native端插件化部分。

正题

在框架使用层面和js-bridge方面，依旧延续上篇提到的两篇博文，也就是框架内不提供webView，webView由使用者自己实现，webView的一切我不关心，我只负责给你的webView提供Hybrid能力。第二点是通信上基于WKWebView的addScriptMessageHandler方式，弃用UIWebView的URL拦截方式。

还是简单说一下WKWebView的addScriptMessageHandler的通信问题，只是简单介绍下就不详细讲解它的通信过程了，WKWebView初始化时，有一个参数叫configuration，它是WKWebViewConfiguration类型的参数，而WKWebViewConfiguration有一个属性叫userContentController，它又是WKUserContentController类型的参数。WKUserContentController对象有一个方法-addScriptMessageHandler:name:，第一个参数是userContentController的代理对象，第二个参数对应着js端postMessage的对象(本篇看完你就明白了没啥说的)。既然设置了代理对象，当然还要实现它的代理方法，也就是WKScriptMessageHandler协议提供的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) {
                asyncAlert(result);
                document.getElementById("returnValue").value = (id) + result;
            }
            
            function asyncAlert(content) {
                setTimeout(function(){
                           alert(content);
                           },1);
            }

再来看下上面回调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就写到了这，另外时候不早了得睡了）。

image

总结

总结一下，本篇简单实现了native端的插件化，基于WKWebView通信的构建，框架内不提供webView的实现三个功能这与我们上一篇的预期也是相符合的，但是远远不够，那么我们后续第三篇再继续。那么下篇会着重介绍native端插件的可配置和js端接口的封装（这点真是难为了我这个未入门的前端了）。

最后编辑于 ：
©著作权归作者所有,转载或内容合作请联系作者
  • 人面猴
    序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
    沈念sama阅读 196,200评论 5赞 462
  • 死咒
    序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
    沈念sama阅读 82,526评论 2赞 373
  • 救了他两次的神仙让他今天三更去死
    文/潘晓璐 我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
    开封第一讲书人阅读 143,321评论 0赞 325
  • 道士缉凶录：失踪的卖姜人
    文/不坏的土叔 我叫张陵，是天一观的道长。 经常有香客问我，道长，这世上最难降的妖魔是什么？ 我笑而不...
    开封第一讲书人阅读 52,601评论 1赞 267
  • 港岛之恋（遗憾婚礼）
    正文 为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
    茶点故事阅读 61,446评论 5赞 358
  • 恶毒庶女顶嫁案：这布局不是一般人想出来的
    文/花漫 我一把揭开白布。 她就那样静静地躺着，像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上，一...
    开封第一讲书人阅读 46,345评论 1赞 273
  • 城市分裂传说
    那天，我揣着相机与录音，去河边找鬼。 笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。 我是一名探鬼主播，决...
    沈念sama阅读 36,753评论 3赞 387
  • 双鸳鸯连环套：你想象不到人心有多黑
    文/苍兰香墨 我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
    开封第一讲书人阅读 35,405评论 0赞 255
  • 万荣杀人案实录
    序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
    沈念sama阅读 39,712评论 1赞 294
  • 护林员之死
    正文 独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 34,743评论 2赞 314
  • 白月光启示录
    正文 我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 36,529评论 1赞 326
  • 活死人
    序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
    沈念sama阅读 32,369评论 3赞 315
  • 日本核电站爆炸内幕
    正文 年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
    茶点故事阅读 37,770评论 3赞 300
  • 男人毒药：我在死后第九天来索命
    文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,026评论 0赞 19
  • 一桩弑父案，背后竟有这般阴谋
    文/苍兰香墨 我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 30,301评论 1赞 251
  • 情欲美人皮
    我被黑心中介骗来泰国打工， 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。 一个月前我还...
    沈念sama阅读 41,732评论 2赞 342
  • 代替公主和亲
    正文 我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
    茶点故事阅读 40,927评论 2赞 336