踏入前端领域满打满算也两年多了。到现在,主要方向已经是由 Android 原生转到了偏前端领域。
期间,不提自己的技术进步、视野拓宽,最大的产出之一应该就是从 0 开始构建了一个 Hybrid 框架了。
正值最近开始进行技术梳理,因此就准备写一系列文章沉淀起来。
核心宗旨:H5 页面基于该框架可以替代 80% 以上的原生业务页面。
更详细一点:
之所以不基于第三方框架而是自己重新实现,是由具体的环境与需求决定的。譬如要求自己必须完全掌握源码,某些功能必须通过特定安全检测等。
另外,本系列不与任何市面上的其他框架进行比较,仅是自己的经验总结。
此框架不是平地起高楼而来的,而是在接近两年的项目实战中慢慢演化出的,内部已经迭代过多个版本
另外,它已经在一个项目型公司全面推广使用了。(N + 级别)
这里要说明下:
最后的源码部分仅提供核心实现以及 API 部分,对于一些简单项目来说,其实也就够用了,
但是如果功能较复杂的,肯定需要进一步封装自己的原生功能。
实际上推荐使用以下人员配置:
因为每一个人精力有限,所以除非特别厉害和全能,否则不建议一人担任两职
(譬如像我转入前端后,以前的 Android 就遗忘的很快,但是如果重点兼顾 Android,前端水准肯定无法快速提升)
在 N + 项目时的模式大致如下:
注意,以上是最小配置。(譬如可以分配更多的框架人员,优化提升等)
最后,以上是实际的经验总结,仅做参考。
实际上不同框架的更新迭代方式都是不一样的,比如本系列中就是基于需求迭代
也就是说遇到问题才修复,优化,累积一段时间后开始考虑下一代的优化提升(迫于投入的窘迫性)
一般来说,整体的交互架构以及 API 是由对于的负责人规划的,然后安排给对于的容器实现
版本号的化仍然是以下经典形式:
- 大版本.小版本.修正版
譬如本框架在两年内迭代了多个大版本(涉及到底层),
使用起来变化较大就会变动小版本,
平时个别 API 新增和修复是修正版
这里因人而异,比如有的喜欢将 API 新增也变为小版本更新
本框架中在实现是吸取了不少市面上已有框架的经验,譬如:
来源: http://www.cnblogs.com/dailc/p/8093450.html