4

前言

虽然说本系列中架构篇是第一章,但实际过程中是在慢慢演化的第二版中才有这个概念,
经过不断的迭代,演化才逐步稳定

明确目标

首先明确需要做成一个什么样的框架?

大致就是:

  • 一套API规范(统一AndroidiOS),所有API异步调用(防止阻塞)
  • 提供大部分原生功能的API(包括很多常用的功能给H5使用)
  • 原生需要能调用到H5中注册的方法(用关于原生主动通知)
  • 部分API需要支持H5环境(譬如alert需要在AndroidiOS、浏览器中同时运行)
  • API类别需要包括事件监听(如网络变化),页面跳转(如打开页面,关闭通过回调回传值),UI显示(调用后立即执行)等

整体架构

其中:

  • quick API指的就是quick hybrid框架提供给H5调用的JS API
  • 最外层的统一JSAPI规范就是quick API
  • 多平台支持的意思是-譬如调用了quick.ui.alert,在quick hybrid容器中会有响应(原生的弹窗),

同时在浏览器中也会有响应(H5实现的弹窗),或者在其它容器中(如DD)也会有响应(其它容器实现的弹窗)

  • 多平台支持并不是所有API都会支持,而是指一些常用的API在多个平台下都有实现(比如UI类API一般都会支持,但是原生设备相关就不会在浏览器支持)

【目标分析】需要哪些工作

根据quick hybrid的整体架构与目标,我们需要先分析需要实现哪一些内容:

  • 【核心工作】制定quick平台下前端和原生容器的交互规则(JSBridge
  • 【核心工作】前端和原生(Android/iOS)分别实现JSBridge交互(包括互相调用,回调等机制)
  • 【核心工作】完成前端调用多平台的支撑(API在不同平台下有不同实现,并会根据不同环境自动转换)
  • 【重要工作】规划功能API(需要提供哪些功能,并且每一个功能应该在哪些平台下有实现)
  • 【重要工作】前端和原生(Android/iOS)分别实现这些功能API(第一步根据二八原则实现重点API即可)
  • 【重要工作】处理好短期API(即调即用,立即回收),长期API(一个页面中能被多次触发,如导航了按钮监听),事件监听API(整个应用生命周期内监听,如网络变化)等不同类型
  • 【优化完善】原生API实现的优化,前端代码的优化,权限认证,本地资源等等

然后就可以基于这些目标,逐步完成每一个规划的内容

【分解目标】总体规划

  • 【quick hybrid】JSBridge的实现
  • 【quick hybrid】H5和原生的职责划分
  • 【quick hybrid】API的分类:短期API、长期API
  • 【quick hybrid】API规划

拓展:

  • 【quick hybrid】H5和Native交互原理

【分解目标】API的实现

  • 【quick hybrid】API多平台支撑的实现
  • 【quick hybrid】组件(自定义)API的实现
  • 【quick hybrid】JS端的项目实现
  • 【quick hybrid】Android端的项目实现
  • 【quick hybrid】iOS端的项目实现

【分解目标】优化与完善

  • 账号体系、Cookie还是Token?
  • hybrid容器的优化与完善

返回根目录

源码

github上这个框架的实现

quickhybrid/quickhybrid


撒网要见鱼
9.7k 声望5.8k 粉丝

你才25岁,你可以成为任何你想成为的人。