H5为主的Hybrid App技术方案的设想

本人从阿里出来，现在在杭州一家创业公司(杭州菲助科技:公司现有的产品:英语趣配音/老外趣聊/少儿趣配音,用户量已经达到400万)，有兴趣一起工作的直接联系QQ:421134693

现状和背景：

目前的应用基本都是原生的，虽然有hybrid的成分，但比例很低，主要用于活动页面一类。
这在几年前是可以理解的，移动设备的性能还没有那么强。随着硬件的飞快发展，现在的移动设备虽然和PC还有差距，但已经足够支持复杂的H5内容。

设想：

主要思路

• APP以H5实现为主，而不是仅限于活动页面
• 不使用比较流行的SPA（single page application）方式
• 每个界面对应一个H5页面，等效Activity/ViewController+布局的职能
• 每个界面（包括原生的）都有一个唯一的URL，通过url跳转
• 模板在App渲染，前后端分离将在APP而不是服务端，APP更具动态性
• 预置资源，使加载过程更快

APP将会分为以下三个层次：

• 容器：以原生方式提供H5尚不支持或者支持得不好的功能（比如视频和音频播放），管理页面切换，与服务器的数据交互，页面渲染，预置资源，缓存策略等。容器应该模块化，构建时可插拔
• H5框架：轻量的H5框架,再加一些支持APP通用功能（比如动画效果，手势交互，通用的ui组件等）
• H5业务层：所有的业务逻辑分在不同的页面实现

其中前两个层次可以形成框架，造福人类。在同一领域下，第三层次也可以抽象出有共享的组件或库

优点：

相对于原生应用，

• APP更加动态化，可以减少APP升级，只有容器改动，才需要用户升级。页面变化，无需升级
• 跨平台，iOS和Android公用一套页面（未来可能还有PC，Widows Phone一类）
• 减少技术需求，前端可以很快上手

相对于SPA

• 各个页面之间相互更独立，避免所有js代码在一个上下文里执行，可以不要过重的UI框架，单个页面的问题不会干扰其他页面，也不需要过分复杂的dom结构
• 和原生APP的玩法不冲突，可以互为补充。比如APP可以部分页面是原生，部分是H5（当然尽量多用H5实现）。

问题

调试比纯原生应用困难一些。但如果单纯在模拟器上调试H5，用Safari和Chrome远程调试都比Native应用调试灵活。
体验比原生APP还有差距，主要表现在操作响应时间，动画效果等方面。但大多数情况下和原生APP相比，已经感受不到差距了。
安全性方面还需要研究方案
过多页面并存的时候，内存消耗大