现状和背景： 目前的应用基本都是原生的，虽然有hybrid的成分，但比例很低，主要用于活动页面一类。 这在几年前是可以理解的，移动设备的性能还没有那么强。随着硬件的飞快发展
现状和背景：
目前的应用基本都是原生的，虽然有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相比，已经感受不到差距了。 安全性方面还需要研究方案 过多页面并存的时候，内存消耗大