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

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

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

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

《写一个易于维护使用方便性能可靠的Hybrid框架(四)—— 框架构建》

前言

上一篇在实现通讯的基础上,咱们还实现了对native端功能的插件化,本篇延续上一篇主要从插件配置做为切入点进行分析。提及插件配置,native端Cordova框架基于一个xml格式的配置文件,在xml里面配置咱们编写的插件相关信息。这种方式在咱们实际开发应用中报漏出不少弊端,咱们每每有的时候就忘记了插件怎样配置,以致于咱们每开发出一个插件还要从新分析对应关系,由于它毕竟不像咱们写业务代码那么频繁,时间久了一些配置的事情就可能会忘记。那么它第二个弊端就是咱们配置过的插件,一旦插件再也不使用或者插件类名等信息有所修改,咱们还要进入xml中进行从新配置,或者进行增删的操做。固然Cordova中配置信息不删除也不影响框架使用,但那不是咱们想要的,咱们就想插件拔出去了,那工程里就不要再有和它相关的东西了。前端

在咱们平时开发中,xml文件的方式去配置信息应该是大部分人最后的选择,在这以前咱们能够选择json文件,也能够选择plist文件,甚至能够选择+load中去配置,固然+load中配置咱们还要考虑是否须要异步加载是否会影响应用启动性能等等。linux

就在我苦思冥想一想要找个更好的方式注册插件的时候,恰巧前天美团技术团队发了篇文章《iOS App冷启动治理:来自美团外卖的实践》,恰巧我又看了里面的第五条,灵感来了。那么本篇插件配置我选择了另外一种方式,经过宏来进行,它的好处就是操做简单,看着直观,不与其余产生耦合,也解决了上面所提到的痛点。固然这只是我本身的想法,主要也是依照一篇的思想来进行设计,确定还有不少欠妥或者更优解,也但愿大佬们能多指导。git

目录

  • 插件注册过程
  • 经常使用插件预加载

1、插件注册过程

那咱们分析阶段就到这里,接下来进入正题,其实代码没有多少,主要是想在造轮子的同时提炼好的思想,踩在巨人肩膀上不断完善。github

在正式进行插件注册以前,咱们先学习一个知识,说实话这个知识咱们平时工做很难遇到,可是它就恰恰能解决咱们工做中遇到的难题,web

编译器编译代码后生成的文件叫作目标文件,从文件结构上来说,它已是可执行的目标文件了,咱们的程序要跑起来,那么它的可执行文件的格式要能被操做系统所理解,好比ELF是linux下可执行文件的格式,PE32是windows下的可执行文件格式,那么对于iOS来讲Mach-O就是它可执行文件的格式。关于Mack-O的分析网上文章不少,也很深不是很容易理解,因此这里就不详细探讨了,实际上Mack-O可执行文件中有不少段,其中一个就是咱们要用到的数据段,也就是说咱们注册的插件信息要存储在Mack-O可执行文件的data段中。clang编译器提供了不少编译器函数,其中就有section()函数,section()函数就提供了二进制段的读写能力,它能够将一些编译期就能够肯定的常量写入到数据段中。那么咱们就利用这个能力在编译期将插件信息写进数据段。而后找一个合适的节点,咱们再将数据段中存储的注册了的插件信息取出来完成注册过程。json

基于此,框架内也封装了一个宏供插件使用:windows

#define SHRMWebPlugins "SHRMWebPlugins"
#define SHRMWebPluginDATA(sectname) __attribute((used, section("__DATA,"#sectname" ")))
#define SHRMRegisterWebPlugin(servicename,impl) \
class SHRMWebViewEngine;char * k##servicename##_service SHRMWebPluginDATA(SHRMWebPlugins) = "{ \""#servicename"\" : \""#impl"\"}";
复制代码

若是有人看过蜂巢的代码或许会很熟悉,但毕竟不是全部人都看过,仍是详细说一下这个宏的解释,__attribute((used, section("__DATA,"#sectname" ")))表示在项目的Mach-o文件的名字为__DATAsegment中添加一个名字为sectnamesection,并将其值设置为字符串"{ \""#servicename"\" : \""#impl"\"}"__attribute第一个参数used,它的做用是告诉编译器,我声明的这个符号是须要保留的。被used修饰之后,意味着即便函数没有被引用,在Release下也不会被优化。若是不加这个修饰,那么Release环境连接器会去掉没有被引用的段。固然这确定不是咱们想要的。这段宏目的只有一个,那就是在编译期将servicenameimpl经过section()函数写入到数据段中存储。缓存

若是上面的理解了,那么咱们接下来的使用就很容易了。咱们在把native端插件编写好后,只须要加一个@SHRMRegisterWebPlugin()就能够了,别的什么都不须要作,不须要引入头文件,不须要解析配置文件,只须要加一行代码就OK了,粘下代码:bash

#import "SHRMMsgCommand.h"
@interface SHRMFetchPlugin : NSObject
- (void)nativeFentch:(SHRMMsgCommand *)command;
@end

@SHRMRegisterWebPlugin(SHRMFetchPlugin, 0)
@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
复制代码

这仍是基于上一篇咱们模拟的fetch插件,实际上若是咱们要把fetch插件注册到咱们的Hybird框架中,只须要在插件里面写入@SHRMRegisterWebPlugin(SHRMFetchPlugin, 0)这行代码就能够了,没有配置文件,没有配置文件,没有配置文件架构

那注册完了,框架内是怎么使用注册好的插件的呢?带着这个问题,再看下我在SHRMWebViewEngine中作的事情。

- (instancetype)init {
    if (self = [super init]) {
        _webViewhandleFactory = [[SHRMWebViewHandleFactory alloc] initWithWebViewEngine:self];
        _webViewDelegate = [[SHRMWebViewDelegate alloc] initWithWebViewEngine:self];
        _webPluginAnnotation = [[SHRMWebPluginAnnotation alloc] initWithWebViewEngine:self];
        _pluginObject = [NSMutableDictionary dictionary];
        [self loadStartupPlugin];
    }
    return self;
}

- (void)loadStartupPlugin {
    [_webPluginAnnotation getAllRegisterPluginName];
}
复制代码

在使用框架的人调用了init的时候,我基于上一篇新增了loadStartupPlugin方法,实际上注册过的插件加载的过程都在SHRMWebPluginAnnotation里面实现的,看下代码:

- (void)getAllRegisterPluginName {
    _dyld_register_func_for_add_image(dyld_callback);
}

static void dyld_callback(const struct mach_header *mhp, intptr_t vmaddr_slide) {
    NSArray<NSString *> *services = ReadConfiguration(SHRMWebPlugins,mhp);
    for (NSString *map in services) {
        NSData *jsonData =  [map dataUsingEncoding:NSUTF8StringEncoding];
        NSError *error = nil;
        id json = [NSJSONSerialization JSONObjectWithData:jsonData options:0 error:&error];
        //省略了部分代码...
        //执行注册的插件处理...
    }
}

NSArray<NSString *>* ReadConfiguration(char *sectionName,const struct mach_header *mhp) {
    NSMutableArray *configs = [NSMutableArray array];
    unsigned long size = 0;
#ifndef __LP64__
    uintptr_t *memory = (uintptr_t*)getsectiondata(mhp, SEG_DATA, sectionName, &size);
#else
    const struct mach_header_64 *mhp64 = (const struct mach_header_64 *)mhp;
    uintptr_t *memory = (uintptr_t*)getsectiondata(mhp64, SEG_DATA, sectionName, &size);
#endif
    
    unsigned long counter = size/sizeof(void*);
    for(int idx = 0; idx < counter; ++idx){
        char *string = (char*)memory[idx];
        NSString *str = [NSString stringWithUTF8String:string];
        if(!str)continue;
        
        NSLog(@"config = %@", str);
        if(str) [configs addObject:str];
    }
    return configs;
}
复制代码

对于这段代码,看过蜂巢源码的会比较熟悉,这里咱们须要了解两件事情,_dyld_register_func_for_add_image函数当dyld连接符号时,就会调用此回调函数,如今我选择在运行时手动调用。getsectiondata()拿到的menory就是咱们上面利用section()函数存储在data段的数据。这样咱们就完成了整个过程。

2、经常使用插件预加载

有些经常使用的或者首屏渲染须要用到的可能咱们要特殊处理下,好比标题所说的预加载,也就是插件对象提早初始化,而不是在调用的时候再初始化。基于这个想法,在插件注册的时候,除了注册了插件名字之外,还额外增长了一个onload参数,若是onload为0,那么认为这个插件不须要提早初始化,在调用的时候在初始化就能够,若是为1那么就认为须要在webView加载的时候就把插件也跟着初始化。看代码:

- (void)registerStartupPluginName:(NSString *)pluginName onload:(NSNumber *)onload {
    if ([onload boolValue]) {
        [self getCommandInstance:pluginName];
    }
}

- (id)getCommandInstance:(NSString*)pluginName {
    id obj = [_pluginObject objectForKey:[pluginName lowercaseString]];
    if (!obj) {
        obj = [[NSClassFromString(pluginName) alloc] init];
        if (obj != nil) {
            [_pluginObject setObject:obj forKey:[pluginName lowercaseString]];
        }else {
            NSLog(@"(pluginName: (%@) does not exist.", pluginName);
        }
    }
    return obj;
}
复制代码

经过代码就很直观,若是[onload boolValue]那么才会往下执行,pluginObject为插件实例的缓存可变字典,一旦有缓存,那么插件直接在缓存取,而没必要每次调用都要初始化一个实例出来。

总结

目前为止hybrid框架文章已是第三篇了,不论是总结也好仍是学习也好,挺费精力的,那么到如今,咱们的hybrid框架在native端已经具有了开篇所讲的功能:

  • 1.插件化(native端实现,js端还未实)
  • 2.可配置性 (native端实现,js端还未实现)
  • 3.前端接口统一 (还未实现)
  • 4.通讯基于WKWebView (已实现)
  • 5.性能调优 (有一些优化,可是这一块坑很深)

第三篇就到这里了,native端也基本完成了,目前是五个类外加一个接口。后续除了优化之外不会再进行native的工做了,后续这个hybird轮子主要设计工做是前端方向了。

代码已经上传到github 《SHRMJavaScriptBridge》,欢迎issue,欢迎star。

参考

《Mach-O文件介绍之loadcommand》

《iOS App冷启动治理:来自美团外卖的实践》

《BeeHive —— 一个优雅但还在完善中的解耦框架》