阐述下项目 Xut.js 开发中一个比较核心的优化技术点，这是一套平台代码，并非某一个插件功能或者框架可以直接拿来使用，核心代码大概是6万行左右(不包含任何插件) 。这也并非一个开源项目，微信h5鱼虾蟹源码搭建不能商业使用，只是为了作者开发方便同步修改代码而上传的源码


描述下，项目提出的概念“无需程序员编程”可批量制作app应用。分２大块，１块是客户端(PPT)，默认扩展插件提供用户编辑的界面，平台会把设计逻辑与界面数据编译成前端数据资源包(前端能处理的js、css、图片等资源了)，另一个大块就是纯前端部分(Xut.js)，简单来说：前端通过读取数据包资源后，翻译出用户设计出的交互行为与可视效果。可以这样想象，苹果iTunes是一个平台，里面有超多的交互应用类型的app，每个app都是程序员开发的，现在每个app都可以通过我们这套平台生成了，但是实际上精细度与性能当然无法跟原生相比了，只能是尽可能的靠拢。在这种平台结构下前端的最大难点在于未知性，编辑数据的复杂度与数量是不可控的，可以想象下设计一个简单儿童类型的闯关游戏需要多少细节？项目介绍可以看我以前写过的一篇文章 Hybrid App技术批量制作APP应用与跨平台解决方案。


数据的未知性，会导致应用性能呈现反比例关系，当应用数据结构越复杂运行的实际性能越差。在这种设计下，一定会印证“墨菲定律”如果你担心某种情况发生，那么它就更有可能发生，在真机上开始大批量崩溃了。这篇文章我着重描述下项目前端方面“地基”的优化，好比建房，100层与200层的地基结构肯定是不一样的，只有地基建好了，房子才能建的更高。这里所涉及的问题以及角度只是个人观点与方案，篇幅有点长，有耐心可以看看。


上传了平台生成的一个简单的SPA单页面测试应用，简单看看 “猜谜语”


开发环境


1. 基于ES6规范编写，加入了flow静态检测环境
2. 开发调试基于webpack2，上线发布基于rollup+gulp
3. 编写了全套基于node的build，开发、调试、压缩、发布


核心特性


1. 单页面结构设计，采用ES6编写，加入了eslint检测与flow静态规则
2. 采用面向对象设计，继承、封装、多态
3. 设计模式,包含单例、工厂、策略、代理、迭代器、观察者、命令、中介、适配、装饰等等
3. 管理上引入了场景的概念，按场景与容器分层，层层细分管理职责，尽量做到了高内聚低耦合
4. 针对不同的设备不同的平台，提供了多种功能自动适配的方案，e.g. 显示区、图片尺寸、视频、音频、事件、动画等等
5. 项目几乎大部分运用了目前前端所能接触的到一些H5、CSS3、JS所有发布的新的特性(webgl动画也有实现,性能问题暂未直接使用)


前端的核心问题：体验与性能


用户体验与高性能是一个矛盾体，就好像软件的可维护性与高性能一样，为了追求易维护、易扩展或多或少会牺牲更多的性能为代价，当然这个只是相对而言 。回到主题，因为是跨平台，需要更多的考虑移动端的性能支持，这里不仅仅只某个功能，或某个效果或者动画，最大的问题就是“当量变堆积积累到一定程度总会产生质变”，这就是所谓的“量变产生质变”，移动设备分配给浏览器的资源总是有限的。举个例子：我们有制作一个2500页面的app应用，大概有几百兆的体积，这个不算夸张，如果是做epub甚至会出现1G以上的数据包，我们可以分解下会产生的问题
在移动端app应用上，用户交互的行为一般就3种：滑动页面、点击跳转与组合形式


点击跳转：这个相对容易处理，而且方案也很多，页面为单位，可以单页面实现，通过路由支持，这样的框架很多了
滑动翻页：与点击跳转最大的不同点就是页面的“连续性”与“页面的无缝连接”
组合形式：点击跳转与滑动翻页的行为的组合方式
点击跳转看起来更像一个原生态的APP应用设计，但是我们是平台就需要对各种不同环境各种使用进行考量，重点分析下2500页面滑动翻页。


首先滑动翻页的“连续性”与“无缝连接”就让我只能选择单页面的设计实现(这里我们必须抛开所有原生的支持情况，因为我是前端)。由于博客园上传受限，简单录了一张gif效果图 动态＋多任务超快翻页


页面的拼接问题


1. 页面的复杂度


大多数前端都做过这种拼接页面，用一个swipe.js 分分钟就OK了，没啥技术难度，我只能说因为量小，而且内容简单。不服吗？来辩。我们的应用一个页面结构是这样的：其实我也不知道一个页面有多少内容，因为是平台，内容的制作是交给编辑的，理论上是无限塞进去，当然我见过最复杂的一个页面有几百个DOM节点的。简单来说，如果把这些DOM节点看做一个个对象，那么在页面上可以直观显示为，人物，动物，物品，风景各种可视的图片，每个对象上可以交叉组合绑定包含各种视频，音频，动画，事件交互等等这些不可见的行为，同时对象之间也可以相对调用，形成多对多的关系，因为实际上的交互应用就是这样设计的。DOM的组成还不止是图片，数据也可能SVG的矢量图，也有可能是文本文字或者蒙版组合，还有很多就不多说了，那么假如这样的页面有2500个呢？实际上正是因为出现过，才有了现在这篇文章。


2. 场景页


我习惯把整个结构展现用“场景”划分，在我看来，整个应用就像一个电影，每个页面就是戏剧中的场面，每个页面场景可以上演一台自己的场景戏，每个场景页中的每个对象扮演了自己的角色。当有2500个这样的场景页时，不管是用户体验还是性能如果单纯靠swipe.js是无法满足。最直接的影响“在加载中直接崩溃”“加载的时间会无限延长”，不管哪种情况都是不应该出现的。这里不做机器的性能数据对比的了，因为都是真实的教训与经验


3. 动态加载


多页面或者是大数据优化，业内的方案“懒加载”，类似瀑布流一样方案，可以用到再加载。甚至可以继续优化下，动态加载，加下一个页面，删除上一个页面。让整个结构上永远只保留3个页面结构：前页面，可视区页，后一页