章节目录

一些感慨

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

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

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

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

更详细一点：

之所以不基于第三方框架而是自己重新实现，是由具体的环境与需求决定的。譬如要求自己必须完全掌握源码，某些功能必须通过特定安全检测等。

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

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

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

这里要说明下：

最后的源码部分仅提供核心实现以及API部分，对于一些简单项目来说，其实也就够用了，但是如果功能较复杂的，肯定需要进一步封装自己的原生功能。

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

因为每一个人精力有限，所以除非特别厉害和全能，否则不建议一人担任两职（譬如像我转入前端后，以前的Android就遗忘的很快，但是如果重点兼顾Android，前端水准肯定无法快速提升）

在N+项目时的模式大致如下：

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

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

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

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

一般来说，整体的交互架构以及API是由对于的负责人规划的，然后安排给对于的容器实现

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

大版本.小版本.修正版

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

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

本框架中在实现是吸取了不少市面上已有框架的经验，譬如：

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

github上这个框架的实现