18年元旦三天内和朋友突击了下，勉强是将雏形做出来了，后续的API慢慢完善。（当然了，主力还是那个朋友，本人只是初涉iOS，勉强能看懂，修修改改而已）

前言 前文中就有提到，Hybrid模式的核心就是在原生，而本文就以此项目的Android部分为例介绍Android部分的实现。 提示，由于各种各样的原因，本项目中的Android容器确保核心交互以及部分重要API实现，关于底层容器优化等机制后续再考虑完善。 大致内容如下： JSBridge核心交互部分 ui、page、navigator等部分常用API的实...

在最初的版本中，其实整个前端库就只有一个文件，里面只规定着如何实现JSBridge和原生交互部分。但是到最新的版本中，由于功能逐步增加，单一文件难以满足要求和维护，因此重构成了一整个项目。

为什么叫组件？可以这样理解，模块更多的是H5前端的叫法（因为在前端看来不同API分别属于不同的模块下），而组件则是原生那边加强的理解概念（因为，每一个组件都是可以在项目中单独存在的，譬如项目A中有组件pay，但项目B却不一定集成有）

前言 在JSBridge实现后，前端网页与原生的交互已经通了，接下来就要开始规划API，明确需要提供哪一些功能来供前端调用。 但是在这之前，还有一点重要工作需要做： 明确H5与Native的职责划分，确定哪一些功能可以由H5实现，哪一些功能只能由原生实现 Native与H5职责划分 使用Hybrid模式，用H5开发页面的本质是： 减少工作...

当一切就绪后，就要开始进行API规划，这一块是整个Hybrid框架中非常重要的内容，毕竟对于前端页面来说，只会通过JS API来调用功能。基本上，API调用起来是否方便简洁影响着整个体验。

为什么要多平台支撑？核心仍然是复用代码，比如在微信下，在钉钉下，在quick容器下，如果没有多平台支撑，那么quick.ui.alert只能用于quick容器下，钉钉和微信下就得分别用其它代码实现，代码复用率低，如果实现了多平台支撑。那么三个平台中同一个功能的代码则是一样的。

首先申明下，这个是在实际框架演变过程中自创的一个概念，其它混合框架可能也会有这个概念，但应该是会在原生底层来实现，而不是前端实现。。而这里由于是前端驱动，所以相比其它混合框架，前端多了一个处理引擎（包括多平台适配，API处理等等）

前言 本文介绍quick hybrid框架的核心JSBridge的实现 由于在最新版本中，已经没有考虑iOS7等低版本，因此在选用方案时没有采用url scheme方式，而是直接基于WKWebView实现 交互原理 具体H5和Native的交互原理可以参考前文的H5和Native交互原理 交互原理图如下： 预计的最终效果 如果一步一步来分析，最后再看效果，可能...

原生和前端的交互有两种方式：url scheme以及JavaScriptCore（在Android中是addJavascriptInterface）

前言 虽然说本系列中架构篇是第一章，但实际过程中是在慢慢演化的第二版中才有这个概念，经过不断的迭代，演化才逐步稳定 明确目标 首先明确需要做成一个什么样的框架？ 大致就是： 一套API规范（统一Android与iOS），所有API异步调用（防止阻塞） 提供大部分原生功能的API（包括很多常用的功能给H5使用） 原生需要能调...

章节目录 【quickhybrid】如何实现一个跨平台Hybrid框架 【quick hybrid】架构一个Hybrid框架 【quick hybrid】H5和Native交互原理 【quick hybrid】JSBridge的实现 【quick hybrid】H5和原生的职责划分 【quick hybrid】API的分类：短期API、长期API 【quick hybrid】API规划 【quick hybrid】API多平台支撑的实现 【qu...