【quickhybrid】如何实现一个Hybrid框架

时间 2019-11-16

标签 quickhybrid 如何实现一个 hybrid 框架栏目 Hybrid 繁體版

原文原文链接

章节目录

一些感慨

踏入前端领域满打满算也两年多了。到如今，主要方向已是由Android原生转到了偏前端领域。html

期间，不提本身的技术进步、视野拓宽，最大的产出之一应该就是从0开始构建了一个Hybrid框架了。前端

正值最近开始进行技术梳理，所以就准备写一系列文章沉淀起来。html5

本系列包含的内容清单

Hybrid框架的原理以及架构系列
JavaScript部分的原理以及源码系列（包括部分API的多容器的兼容）
Android部分的原理以及源码系列（仅覆盖核心实现以及API部分，不包含实际业务代码）
iOS部分的部分原理（一些坑会特别提出，理论上根据原理应该能够还原出）git
- 因为本人没写过iOS应用，所以目前没有直接提供源码，后续有时间能够考虑进一步提供

什么样的`Hybrid`框架？

核心宗旨：__H5页面基于该框架能够替代80%以上的原生业务页面。__github

更详细一点：api

适用于须要开发大量项目级APP的场景
不是用于彻底替代原生开发，而是替代里面的80%原生业务页面（模式是：原生部分 + H5部分）
框架人员至少须要一名Android原生，一名iOS原生，一名前端架构（若是全栈，能够考虑合一）
部分API（如UI显示类）考虑到了H5的兼容
并无作到产品级别的优化（需求优先级别较低）

之因此不基于第三方框架而是本身从新实现，是由具体的环境与需求决定的。譬如要求本身必须彻底掌握源码，某些功能必须经过特定安全检测等。安全

另外，本系列不与任何市面上的其余框架进行比较，仅是本身的经验总结。架构

此框架是否有实践经验？

此框架不是平地起高楼而来的，而是在接近两年的项目实战中慢慢演化出的，内部已经迭代过多个版本app

另外，它已经在一个项目型公司全面推广使用了。（N+级别）框架

这里要说明下：

实际项目中，Hybrid框架仅仅是其中的一部分，还会包括一些原生通用组件，业务模块等
可是本系列仅止步于Hybrid框架（处于诸多因素考虑，包括核心实现以及API实现）

如何应用与本身的项目中？

最后的源码部分仅提供核心实现以及API部分，对于一些简单项目来讲，其实也就够用了，
可是若是功能较复杂的，确定须要进一步封装本身的原生功能。

实际上推荐使用如下人员配置：

一名资深Android原生（负责Android容器）
一名资深iOS原生（负责iOS容器）
一名资深前端（前端部分不要小觑，要配合排查问题的）
总架构（推荐是以上三人中的一人担任，譬如本系列是由前端来统一架构的-但前提是必须懂点原生原理，不然抓瞎）

由于每个人精力有限，因此除非特别厉害和全能，不然不建议一人担任两职
（譬如像我转入前端后，之前的Android就遗忘的很快，可是若是重点兼顾Android，前端水准确定没法快速提高）

在N+项目时的模式大体以下：

三名框架人员负责核心框架容器部分(框架还须要提供一些通用模块与组件)
各个业务线的APP中能够专门分配不一样的原生人员负责打包APP（1对N，协助排查各自可能的业务问题）
每个APP中能够有若干H5业务开发人员(由不一样的复杂度而定，主要业务都是线上的H5形式)
三名对于的框架人员负责处理过滤后的真正框架BUG（由业务负责人过滤）

注意，以上是最小配置。（譬如能够分配更多的框架人员，优化提高等）

最后，以上是实际的经验总结，仅作参考。

框架更新与迭代

实际上不一样框架的更新迭代方式都是不同的，好比本系列中就是基于需求迭代

也就是说遇到问题才修复，优化，累积一段时间后开始考虑下一代的优化提高（迫于投入的窘迫性）

通常来讲，总体的交互架构以及API是由对于的负责人规划的，而后安排给对于的容器实现

版本号的化仍然是如下经典形式：

大版本.小版本.修正版

譬如本框架在两年内迭代了多个大版本（涉及到底层），
使用起来变化较大就会变更小版本，
平时个别API新增和修复是修正版

这里因人而异，好比有的喜欢将API新增也变为小版本更新

借鉴与不足

本框架中在实现是吸收了很多市面上已有框架的经验，譬如：

钉钉（API设计上，惋惜没法看到它底层实现...）
phonegap,html5+,apicloud,appcan等都有接触过（但参考的很少）
一些github开源库，譬如marcuswestin/WebViewJavascriptBridge等

另外，在文章总结时，参考了一些博文，包括我之前写的文章（会在参考来源中）

源码

github上这个框架的实现

quickhybrid/quickhybrid