作者：餓了麼 顧誠

為什麼我們選擇了快應用

在很長一段時間裡，原生餓了麼應用對於新使用者來說體驗成本略高，對於迫切想要點餐的老使用者操作有點繁瑣；而 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 應用的輕