餓了麼快應用初體驗

做者：餓了麼 顧誠

爲何咱們選擇了快應用

在很長一段時間裏，原生餓了麼應用對於新用戶來講體驗成本略高，對於迫切想要點餐的老用戶操做有點繁瑣；而 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 應用的輕量化、低成本。