【快应用篇01】快应用它来了！带你了解什么是快应用！

分享人：夏燕飞

近期由于需求与bug比较多，所以有些拖更了。很是抱歉，那么今天的干货开始了。。。

该篇为“快应用”第一篇。欢迎你们阅读！

自快应用问世，到如今也已经有一年多了。快应用和微信小程序相似。都是用户体验介于网页与原生APP之间的新型应用模式。微信小程序我想你们都用过，可是快应用却不必定。首先微信小程序问世要比快应用早一年，并且靠着微信的用户社交粘性和闭环，以及小程序支持安卓与ios端。使得小程序到目前为止，依旧发展得比快应用好。但将来不必定。

快应用能够说是9大手机厂商为了避免使微信小程序抢占应用流量而出现的吧。

毕竟微信小程序是以微信为载体，是一种二级应用，打开小程序前必需要打开微信的占用内存。而快应用是手机厂商出品的，不须要以某个为载体，直接操做系统打开，属于一级应用。能够直接调用底层系统功能。其实厂商可根据其优点，提高手机的原生性能，使得其强于微信小程序的体验也是能够的，不过这得待后期发展了。

如今咱们从技术角度来讲说开发快应用吧！

项目结构

按快应用脚手架工具初始化的项目基本能知足通常的项目开发需求了。好比如今初始化一个

hap init hiquick

项目：

获得一个以下结构的项目目录：

├── sign //rpk包签名模块

├── src

│   ├── Common //公用的资源和组件文件

│   ├── Demo //页面目录

│   │  └── index.ux //页面文件，可自定义页面名称

│   ├── app.ux //APP文件，可引入公共脚本，暴露公共数据和方法等

│   └── manifest.json //项目配置文件，配置应用图标、页面路由等

其中 Demo 目录便是一个页面目录，包含一个 ux 后缀的页面文件。项目构建运行以后，还会产生 build/、dist/ 两个目录。build 是打包构建后生成的 js 文件、dist 则是 rpk 安装包。

在咱们实际项目中因为业务比较复杂，会建立不少页面，这样平铺在根目录下，形成文件夹过多不易管理维护。

因而咱们新建一个文件夹 pages 专门存放页面，这样项目结构就变成了：

├── sign 

├── src

│   ├── common //公用资源、全局配置

│   ├── components //公用组件

│   ├── pages                  

│   │  ├── index //页面目录

│   │  │  └── index.ux //页面文件

│   │  └── login

│   ├── app.ux

改造后的目录结构更直观、简洁。不过要记得去修改默认的页面路由配置：router.pages、display.pages 两项的页面键值要改和页面路径一致。如这里首页的配置就是 pages/index。

除了新增 pages 目录，还新增了 components 文件夹和更改 common 文件夹的用途。

新增的 components 文件夹专门存放公用的组件文件，而 common 则专门用来存放公共资源、工具方法和全局配置等文件。这样使得目录的功能区分更明白了，也为后面的代码复用做好了基础准备。

其中全局配置的配置项皆以模块化输出，既对变量有一个统一的维护管理，也方便在业务直接引入调用，一箭双雕，很是高效。

页面划分

上面已经说了咱们为全部页面专门创建了一个 pages 文件夹。从中能够看出应用中的全部页面是平级划分的。虽然在业务逻辑上可能存在父子关系，但实际页面不必分出从属，那样只会增长页面关系的复杂度。

但这里有一个特殊页面仍是设计了父子关系。这么作也偏偏想代表页面间从属关系。这就是 pages/index 页面，为了不概念混淆，这里先称之为索引页。由于它正是起着索引导航做用的，并非常规意义上的首页。

一般，一个APP的界面是这样的：

在界面底部会有一个导航菜单栏，叫作 TabBar，然而快应用并无这种组件。虽然利用页面路由能够作导航，但效果并不理想，切换过来的页面都须要从新加载。因为页面中已经使用了 tabs 组件，使用tabs组件实现也不可行。

剩下就须要本身动手打造了。既要实现页面导航，又要实现页面缓存的功能。

简要分析下组件的设计思路。

1. 在单页内实现不一样页面的切换，功能至关于一个Tab。

2. 功能区分为tab标签栏和tab内容区。

3. 标签的项目不能写死，要能够自由扩展。

4. 每一个标签对应的页面以组件形式引入。

在 index.ux 页面须要引入 TabBar 页面组件。做为子组件，为方便管理，咱们把这些子页面组件做为子文件夹放在 index/ 下管理维护，一目了然地代表页面的从属关系，总体项目的页面切分工做也完成了。

│   ├── pages                  

│   │  ├── index //索引导航目录

│   │  │  ├── subpages //子页面目录

│   │  │  │  ├── featured //子页面

│   │  │  │  │  └── index.ux  //子页面组件文件

│   │  │  │  └── member

│   │  │  │       └── index.ux

上面 TabBar 的功能设计还忽略一点，就是子页面组件更新的问题。为此作了监听标签切换及页面 onShow 事件触发组件更新的处理，这里不作详细说明。

公共代码

下面着重来讲下公共代码部分，公共代码及组件化向来都是项目中的重点部分，这部分做好了，会使得项目代码越写越少，越写越高率。相反，若是这部分没有作好，不只会让项目代码变得一团糟，不断地重复工做，还极有可能会埋下一些潜在的危险。

好比项目中公用的一个参数，分别写在各个地方，等到须要更改时，极可能改了一个地方而忘了另外一个地方，等到出错还不容易排查问题出在哪里。若是统一在一处配置好，其它全部地方只引入这个配置，则会从根本上规避这个低级错误。

固然这只是作好公共管理的优势之一。

公共代码和组件化开发应该深刻到任何项目的任何角落，应该时刻保持这种意识。

在快应用项目中咱们将公共资源、公共代码都放在了 common 文件夹下。包含全局基础样式文件、图片资源、配置项文件、和工具方法。

配置项文件 config.js 集中管理全局使用的常量和API接口地址，并对依赖不一样域名环境下的配置项作自动切换处理。

工具方法 utils.js 将可复用的工具函数方法抽象出来，并以模块化形式导出，方便其它模块中按需引入，而不须要在不一样的地方重复地写同一个工具方法了。

再来讲说组件化，这也是项目开发中的重点。

组件化应该是在项目一开始就须要着手考虑的事情，原则上在交互稿评审阶段就须要开始了。分析出哪些部件能够提取抽象出公共组件。这样多人协做的项目中，共同开发将变得很是有效率。

快应用项目目前拆分出的公共组件有图文展现组件、TitleBar页面标题栏组件、错误状态提示组件、章节目录组件等（排除快应用框架自身的组件）。

TitleBar组件实现自定义的头部标题样式，在默认的标题栏不知足需求时可使用该组件实现。

错误状态提示也是复用较高的组件，在处理无网络、暂无数据等状态下均可以直接引用。大大减小代码的重复开发工做。

体验、性能的优化

除了以上的改造优化外，性能的优化也是没法绕开的。开发过程当中除了基本该作的优化要作到以外，能发现的性能问题也应该寻找方案解决。固然若是时间不容许或者暂无方案解决则另当别论。

那快应用项目中所作的性能优化工做列举几点以下。

TabBar页面导航优化

前面说了TabBar的设计思路，也提到了设计的意义，涉及的主要优化有：

1. 按需加载，首次只加载默认标签页。

2. 页面缓存，避免切换时页面的重复加载。

3. 返回键退出应用，避免路由链路过长。

TabBar配置的标签项，默认只会加载其中一个页面，这个初始展现的页面由配置项 currentTabName 决定。点击其它标签后，才加载对应的页面。页面加载完成后，再次切换标签，已加载的页面则是显示或隐藏，不会从新加载渲染。提升了用户使用体验的同时，也节约了不必的网络请求。

前面也提到直接使用路由跳转也是能够实现相似的效果。使用路由来实现，技术复杂度会大大下降，但使用感觉也比较糟糕。除了切换时页面重复加载渲染以外 ，页面栈也会随着不断切换而加大，这时若是想返回则会走很长的连接。虽然能够经过设置replace路由替换规避，但页面重复加载渲染是避免不了的。

快应用与web组件的通讯优化

快应用的订购环节因为技术限制，须要引用web组件来加载HTML页面实现订购。交易环节事关重大，功能上容不得半点差错，性能上要保证稳定可靠。技术上涉及到快应用与HTML之间的通讯。而在调试过程当中却发现了通讯机制的一个Bug。

起始在开发中发现web组件存在通讯不稳定的问题，初步断定为可能页面还未加载完成。为保证通讯的可靠性，咱们在页面加载完成的回调事件 onpagefinish 中发起通讯。然而web组件会自动触发两次 onpagefinish 回调。缘由暂时不明确，问题也和官方沟经过。总之这会形成HTML中监听通讯的请求也发送两次。因而想办法去阻止web组件二次触发回调事件。

在 onpagefinish 事件中设置回调状态，若是判断状态为true 则代表web已经完成加载，就不用再次发起通讯。这样处理以后，发现不会再二次触发了，并且在调试和测试过程当中观察通讯成功率达到100%。

总结

项目技术选型、架构设计及优化工做都是开发过程的重要因素。一个合理的项目架构会让开发过程变得省力有趣。相反则会低效，既影响开发体验也对优化及后续维护、优化不利。

若是各位对咱们有什么意见或建议，欢迎回复咱们哦。

以为不错的童鞋们请记得点赞、转发、关注三连哦！！！

从如今起咱们的公众号已更名为“大前端早读”内容范围围绕大前端，也开启系列篇，更多原创文章请关注咱们，

并点击内容系列--原创篇，学习更多：