【quick hybrid】H5和原生的职责划分github
踏入前端领域满打满算也两年多了。到如今,主要方向已是由Android
原生转到了偏前端领域。
期间,不提本身的技术进步、视野拓宽,最大的产出之一应该就是从0开始构建了一个Hybrid
框架了。
正值最近开始进行技术梳理,所以就准备写一系列文章沉淀起来。
Hybrid框架的原理以及架构系列
JavaScript部分的原理以及源码系列(包括部分API的多容器的兼容)
Android部分的原理以及源码系列(仅覆盖核心实现以及API部分,不包含实际业务代码)
iOS部分的部分原理(一些坑会特别提出,理论上根据原理应该能够还原出)
Hybrid
框架?核心宗旨:H5
页面基于该框架能够替代80%
以上的原生业务页面。
更详细一点:
适用于须要开发大量项目级APP的场景
不是用于彻底替代原生开发,而是替代里面的80%
原生业务页面(模式是: 原生部分 + H5部分)
框架人员至少须要一名Android
原生,一名iOS
原生,一名前端架构
(若是全栈,能够考虑合一)
部分API(如UI
显示类)考虑到了H5
的兼容
并无作到产品级别的优化(需求优先级别较低)
之因此不基于第三方框架而是本身从新实现,是由具体的环境与需求决定的。譬如要求本身必须彻底掌握源码,某些功能必须经过特定安全检测等。
另外,本系列不与任何市面上的其余框架进行比较,仅是本身的经验总结。
此框架不是平地起高楼而来的,而是在接近两年的项目实战中慢慢演化出的,内部已经迭代过多个版本
另外,它已经在一个项目型公司全面推广使用了。(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
上这个框架的实现