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

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

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

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

目录

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

一、插件注册过程

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

在正式进行插件注册之前，我们先学习一个知识，说实话这个知识我们平时工作很难遇到，但是它就偏偏能解决我们工作中遇到的难题，

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

基于此，框架内也封装了一个宏供插件使用：

#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 文件的名字为 __DATA 的 segment 中添加一个名字为 sectname 的 section ，并将其值设置为字符串 "{ \""#servicename"\" : \""#impl"\"}" 。 __attribute 第一个参数 used ,它的作用是告诉编译器，我声明的这个符号是需要保留的。被used修饰以后，意味着即使函数没有被引用，在 Releas e下也不会被优化。如果不加这个修饰，那么Release环境链接器会去掉没有被引用的段。当然这肯定不是我们想要的。这段宏目的只有一个，那就是在编译期将 servicename 和 impl 通过 section() 函数写入到数据段中存储。

如果上面的理解了，那么我们接下来的使用就很容易了。我们在把native端插件编写好后，只需要加一个 @SHRMRegisterWebPlugin() 就可以了，别的什么都不需要做， 不需要引入头文件，不需要解析配置文件，只需要加一行代码就OK了 ，粘下代码：

#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段 的数据。这样我们就完成了整个过程。

二、常用插件预加载

有些常用的或者首屏渲染需要用到的可能我们要特殊处理下，比如标题所说的预加载，也就是插件对象提前初始化，而不是在调用的时候再初始化。基于这个想法，在插件注册的时候，除了注册了插件名字以外，还额外增加了一个 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轮子主要设计工作是前端方向了。

注：本文属于原创，转载注明出处。