作者：饿了么顾诚

为什么我们选择了快应用

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

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

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

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

开发过程新应用选择了类 Vue/Weex 的技术体系，因此熟悉这一块技术的开发人员可以非常轻松的进入开发状态，语法简单清晰，系统接口完备、功能明确，并且整个服务平台对应用内部架构也非常宽容，可以最大程度按照开发者自己的思路来实现。以饿了么应用为例，在开发饿了么新应用应用的过程中，很多逻辑都直接复用了原先 Web 应用（基于 Vue 的体系）的逻辑、代码，迁移、改造过程非常平滑，甚至部分组件直接有原先的 Vue 组件转换而来，开发体验非常好。而在接入各项系统服务的过程中，最需要的数据存储、地理位置、网络服务、消息提醒以及支付等服务、接口都非常完备，并且对接非常简单，接口设计符合 Web 开发人员认知，对接过程基本没有遇到阻碍。基于以上因素，对于一名 Web 开发人员，完成一个新应用的应用开发，是非常轻松、高效的过程。
应用设计前面提到，新应用在应用架构设计上，更加接近于原生应用，这是非常有趣的一点，也要求开发人员主动去思考。
系统层面，有效利用快应用平台的各项系统功能、接口。如利用数据存储实现应用的初始化加速、用户信息缓存，节约用户时间成本。利用地理位置服务实现更加精确的用户定位。
组件层面，按照原生应用的设计形式实现组件视图层、逻辑层。虽然继承了了类 Vue 形式的模板，但是实际在视图层布局上，也应当有正确的布局思路。以服务提供的 stack 组件为例，对于普通 Web 开发者来说，可能很难有层的概念，例如浮动导航栏，在 Web 开发中我们习惯于使用 fixed, sticky 这样的全局定位属性来实现，在非必要情况下，对于 zIndex 这样的属性，很难意识到各个 Web 组件之间的层级关系。而在快应用中，stack 用来实现类似的布局，其实就是要求组件层级的合理利用。同样的还有长列表组件 List，在长列表场景下，优先考虑使用 List 组件实现，能够获得更好的性能和体验。另外在实现视图、逻辑的过程中，更多地按照原生应用的形式去考量，使得用户体验更加接近于原生应用也是非常重要的。

问题举例

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

遮罩层的实现在弹窗等场景，需要实现一个遮罩层，而我们尝试了绝对定位、stack 层叠等几种形式，遇到了包括部分机型样式异常（绝对定位）、层叠关系异常（stack）等等问题。
系统服务调用的统一管理针对定位、网络等常见系统调用，为了兼顾开发的高效和实际业务逻辑的适配，对接口调用做了一定封装，在完善封装的过程中，也遇到了如错误信息的处理、不同组件调用数据的共享等等问题。
storage 与 $app 的取舍在记录用户使用状态的过程中，一些需要全局共享的信息，我们也遇到了存储到数据系统还是挂载到 $app 对象上的抉择。存储到数据系统更加可靠，同时可以离线，不受用户和应用状态的影响，缺点是不够灵活；而挂载到 $app 对象上，天生与应用生命周期捆绑，对于只在本次生命周期内共享的数据显然更加适合，并且结合生命周期的各阶段钩子，也可以随时存储到数据系统，更加灵活。

小结

总体而言，经过多次版本迭代之后，个人认为快应用是一个非常优秀的原生应用、Web 应用之外的选择，兼顾了原生应用的高性能、良好体验和 Web 应用的轻量化、低成本。