|
为什么我们选择了快应用
在很长一段时间里，原生饿了么应用对于新用户来说体验成本略高，对于迫切想要点餐的老用户操作有点繁琐；而 Web 版的饿了么应用在体验、速度、功能支持上都无法达到原生应用的水平，因此迫切需要一个功能上足够支撑饿了么服务体验、体验上足够轻量化的平台，而快应用恰好满足了我们的需求。
因为由厂商（小米等）直接引导、推广，在系统平台上拥有足够的支持，各类系统接口、服务完善， 也可以轻松实现和原生应用一样的功能逻辑。
轻量化、免安装的模式使得不管是新用户想要体验，还是老用户想要快速点餐，都可以在很短的时间内，以极低的成本快速点餐。
与厂商系统平台的紧密结合使得新应用成为原生应用、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 应用的轻量化、低成本。
| 
