作者：餓了麼 顧誠
為什麼我們選擇了快應用
在很長一段時間裡，原生餓了麼應用對於新使用者來說體驗成本略高，對於迫切想要點餐的老使用者操作有點繁瑣；而 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 應用的輕量化、低成本。