饿了么快应用初体验

做者：饿了么 顾诚

为何咱们选择了快应用

在很长一段时间里，原生饿了么应用对于新用户来讲体验成本略高，对于迫切想要点餐的老用户操做有点繁琐；而 Web 版的饿了么应用在体验、速度、功能支持上都没法达到原生应用的水平，所以迫切须要一个功能上足够支撑饿了么服务体验、体验上足够轻量化的平台，而快应用刚好知足了咱们的需求。

1. 由于由厂商（小米等）直接引导、推广，在系统平台上拥有足够的支持，各种系统接口、服务完善， 也能够轻松实现和原生应用同样的功能逻辑。
2. 轻量化、免安装的模式使得不论是新用户想要体验，仍是老用户想要快速点餐，均可以在很短的时间内，以极低的成本快速点餐。
3. 与厂商系统平台的紧密结合使得新应用成为原生应用、Web 应用以外一个有效、可靠的流量渠道。

新应用对比原生应用、Web 应用

新应用在开发的角度来讲，开发过程更接近于 Web 应用，然而从应用架构设计上，应该更接近于原生应用。

1. 开发过程 新应用选择了类 Vue/Weex 的技术体系，所以熟悉这一块技术的开发人员能够很是轻松的进入开发状态，语法简单清晰，系统接口完备、功能明确，而且整个服务平台对应用内部架构也很是宽容，能够最大程度按照开发者本身的思路来实现。 以饿了么应用为例，在开发饿了么新应用应用的过程当中，不少逻辑都直接复用了原先 Web 应用（基于 Vue 的体系）的逻辑、代码，迁移、改造过程很是平滑，甚至部分组件直接有原先的 Vue 组件转换而来，开发体验很是好。 而在接入各项系统服务的过程当中，最须要的数据存储、地理位置、网络服务、消息提醒以及支付等服务、接口都很是完备，而且对接很是简单，接口设计符合 Web 开发人员认知，对接过程基本没有遇到阻碍。 基于以上因素，对于一名 Web 开发人员，完成一个新应用的应用开发，是很是轻松、高效的过程。

2. 应用设计 前面提到，新应用在应用架构设计上，更加接近于原生应用，这是很是有趣的一点，也要求开发人员主动去思考。

3. 系统层面，有效利用快应用平台的各项系统功能、接口。 如利用数据存储实现应用的初始化加速、用户信息缓存，节约用户时间成本。 利用地理位置服务实现更加精确的用户定位。

4. 组件层面，按照原生应用的设计形式实现组件视图层、逻辑层。 虽然继承了了类 Vue 形式的模板，可是实际在视图层布局上，也应当有正确的布局思路。 以服务提供的 stack 组件为例，对于普通 Web 开发者来讲，可能很难有层的概念，例如浮动导航栏，在 Web 开发中咱们习惯于使用 fixed, sticky 这样的全局定位属性来实现，在非必要状况下，对于 zIndex 这样的属性，很难意识到各个 Web 组件之间的层级关系。而在快应用中，stack 用来实现相似的布局，其实就是要求组件层级的合理利用。 一样的还有长列表组件 List，在长列表场景下，优先考虑使用 List 组件实现，可以得到更好的性能和体验。 另外在实现视图、逻辑的过程当中，更多地按照原生应用的形式去考量，使得用户体验更加接近于原生应用也是很是重要的。

问题举例

在开发快应用的过程当中，也遇到过一些问题，这里列举几个。

1. 遮罩层的实现 在弹窗等场景，须要实现一个遮罩层，而咱们尝试了绝对定位、stack 层叠等几种形式，遇到了包括部分机型样式异常（绝对定位）、层叠关系异常（stack）等等问题。

2. 系统服务调用的统一管理 针对定位、网络等常见系统调用，为了兼顾开发的高效和实际业务逻辑的适配，对接口调用作了必定封装，在完善封装的过程当中，也遇到了如错误信息的处理、不一样组件调用数据的共享等等问题。

3. storage 与 $app 的取舍 在记录用户使用状态的过程当中，一些须要全局共享的信息，咱们也遇到了存储到数据系统仍是挂载到 $app 对象上的抉择。存储到数据系统更加可靠，同时能够离线，不受用户和应用状态的影响，缺点是不够灵活；而挂载到 $app 对象上，天生与应用生命周期捆绑，对于只在本次生命周期内共享的数据显然更加适合，而且结合生命周期的各阶段钩子，也能够随时存储到数据系统，更加灵活。

小结

整体而言，通过屡次版本迭代以后，我的认为快应用是一个很是优秀的原生应用、Web 应用以外的选择，兼顾了原生应用的高性能、良好体验和 Web 应用的轻量化、低成本。