1. 程式人生 > >快應用之開發體驗紀要

快應用之開發體驗紀要

DJI Mavic Air何謂「快應用」呢?它是基於手機硬體平臺的新型應用形態,標準是由主流手機廠商組成的快應用聯盟聯合制定。其標準的誕生將在研發介面、能力接入、開發者服務等層面建設標準平臺,以平臺化的生態模式對個人開發者和企業開發者全品類開放。快應用具備傳統 APP 完整的應用體驗,無需安裝、即點即用覆蓋 10 億裝置與作業系統深度整合,探索新型應用場景。快應用 ──複雜生活的簡單答案,讓生活更順暢 ── 來自 快應用官方網站 | 傾城之鏈

快應用特點

下面列出些關於「快應用」特點,這將有助於對它有更深刻的理解;

  • 基於手機硬體平臺,標準由主流手機廠商組成的快應用聯盟制定;
  • 無需安裝、即點即用,且具備傳統 APP 完整的應用體驗;
  • 與作業系統深度整合,一鍵直達;
  • 更新直接推送,新版本直接更新到後臺,使用者無感知快應用的技術實現;
  • 基於前端技術棧開發、可快速迭代;
  • 通過全新的引擎,將系統原生的渲染機制和介面能力提供給上層應用;
  • 執行在框架應用程序中,對每個快應用會開一個 Launcher 程序快應用的開發、釋出和使用流程;
  • 開發者需要在快應用官網註冊,上傳至快應用官網,測試並通過稽核後即可進行分發;
  • 使用前端技術棧進行開發,經過編譯、簽名後最終產出 rpk 檔案;
  • 開發者需登入快應用官網進行上傳和釋出,釋出前會經過稽核快應用與小程式的對比;
  • 快應用使用 native 渲染,效能體驗會比較好,而小程式是使用 webview
    渲染 ;
  • 快應用的系統級能力更強,能呼叫更多系統級 API;

與小程式對比

── 開發技術 渲染方式 硬體資源扶持 系統級能力 桌面留存
小程式 前端技術棧 webview 渲染
快應用 前端技術棧 native 渲染

以上這些比對,皆是從兩者的出生角度而言;可以肯定的是,「快應用」得益於其與生俱來的優勢,將在更多應用場景發揮作用,它的崛起,將會給 Android 使用者帶來更多的便捷。同時作為後起之秀,其開發體驗上,是明顯優於小程式的;但目前的小程式,已經有長足的發展,而「快應用」才處於剛起步階段,在經驗累積、應用數量、分發傳播、社群建設等方面,兩者之間還存在些差距;後續故事將會如何,讓我們將拭目以待。

開發 & 除錯

環境搭建

  • 鑑於「快應用」基於前端技術棧來開發,因此需要安裝 Node.js (>= 6.0);yarn (推薦使用)。
  • 安裝 hap-toolkit ;它是針對「快應用」衍生出的開發者工具; JavaScript
    123 yarn globaladd hap-toolkit// 檢測是否成功安裝 hap-toolkithap-V
  • 手機安裝「快應用」偵錯程式 ── 一個 Android 應用程式,它可以連線到手機系統內的快應用執行環境,包含掃碼安裝本地安裝線上更新開始除錯、等功能;

掃碼安裝:配置 HTTP 伺服器地址,下載 rpk 包,並喚起平臺執行 rpk 包; 本地安裝:選擇手機檔案系統中的 rpk 包,並喚起平臺執行 rpk 包; 線上更新:重新發送 HTTP 請求,更新 rpk 包,並喚起平臺執行 rpk 包; 開始除錯:喚起平臺執行 rpk 包,並啟動遠端除錯工具;

備註:當您的手機系統尚未內建快應用執行平臺,或您想在開發過程中體驗快應用尚未正式釋出的新功能、新特性,您可以安裝 ,這是一個包含了快應用基礎功能的 Android 應用程式。下載安裝成功後,通過快應用偵錯程式可以選擇在快應用預覽版執行 rpk包,開發測試對應平臺的 api 和功能。更詳細的敘述,請參見快應用開發文件 | 環境搭建

開發環境

在「快應用」中,對程式碼編輯配置做了說明;你可以使用 VsCodeSublime TextWebStorm 等工具來開發。鑑於官方針對 VsCode 推出了 Hap Extension 擴充套件,這裡推薦使用 VsCode 來編寫快應用程式碼(據悉,專門用於開發「快應用」的編輯器,尚在開發中 18-08-15)。

開發除錯

在開發文件除錯工具一節,對此有詳細說明;從一般性開發角度總結而言,只需執行以下兩個命令: npm run servernpm run watch;前者會在終端會輸出一個二維碼,用手機上啟動快應用偵錯程式,點選掃碼安裝掃描,即可下載安裝 apk 包,並執行之;而後者將會啟動檔案監視器,每次修改工程檔案時,會自動編譯並在手機端重新整理,速度蠻快;至於日誌檢視,可利用 devtools 除錯介面 console 輸出,也可利用 adb 工具,在終端進行檢視:

JavaScript
1 adb logcat-sJsConsole

快應用示例

在安裝 Toolkit 工具後,可通過全域性 hap 命令建立一個專案模板,如下所示:

JavaScript
1 hap init<YourProjectName>

鑑於其內建的 Demo 專案示例,尚處於入門級專案設定(@18-08),不便於使用者著手開發,且不利於高效編寫、維護;因此,有將編寫的快應用 nicelinks-quick-app 開源,藉此以探索新型應用設計;此外,也是在探索如何構建優質快應用,希望可以在此事兒上提供些參考。其程式碼組織結構如下:

JavaScript
123456789101112131415 ├──sign#儲存rpk包簽名模組;│├──debug#除錯環境證書/私鑰檔案│└──release#正式環境證書/私鑰檔案└── src│   ├── assets          # 公用的資源(Images/Styles/字型...)││├──images#儲存png/jpg/svg等公共圖片資源││└──styles#存放less/css/sass等公共樣式資源│├──helper#專案自定義輔助各類工具││├──apis#儲存與後臺請求介面相關(已封裝好)││├──ajax.js#對系統提供的fetch api進行鏈式封裝││└──util.js#存放專案所需公共工具類方法│├──pages#統一存放專案頁面級程式碼│├──app.ux#應用程式程式碼的人口檔案│└──manifest.json#配置應用基本資訊└──package.json#定義專案需要的各種模組及配置資訊

有必要談及的是,此專案秉承在高效開發 Web 單頁應用解決方案中所傳遞的理念:為高效開發而設計;相比於內建 Demo,她具有以下諸多優點:

  • 對專案結構進行優化;如上組織結構所示,將各資源模組,更專業的分門別類,使之可以便捷的去編寫、維護、查詢,同時也是基於前端開發既定共識去設計,更容易為初接觸者所理解 & 上手;
  • 更優雅的處理資料請求;採用 Promise 對系統內建請求 @system.fetch 進行封裝,並丟擲至全域性,使得可以極簡的進行鏈式呼叫,同時便捷地處理返回資料;
  • 內建了樣式處理方案;「快應用」支援 less, sass 的預編譯;這裡採取 less 方案,並內建了部分變數,以及常用混合方法,使得可以輕鬆開啟樣式編寫、複用、修改等;
  • 優化本地開發埠設定;「快應用」預設埠為 12306,雖說可自定義埠,但使用體驗卻不夠友好;此處參考 creat-react-app 設定,對本地開發地址埠使用進行優化:如果?️定埠(預設: 8080)被佔用,則向上遞增尋找新的可用埠(如:8081 / 8082 / … );
  • 瀏覽器開啟除錯主頁二維碼;執行 npm run server,會啟動 HTTP 除錯伺服器,並將該地址在命令列終端顯示,手機端用快應用偵錯程式掃碼,即可下載並執行 rpk 包;當終端積累的資訊流多了,就造成掃碼不便;故增設在瀏覽器開啟除錯主頁二維碼;如想不使用此功能,在 command/server.js 檔案中,將 autoOpenBrowser 設定為 false 即可;
  • 會持續探究,逐步將更多好用姿勢整合 ……

關於快應用の釋出

關於快應用釋出,有必要談下的理由是,其釋出流程說簡單卻也複雜,說快也慢;這是因為涉及多家廠商,且有著不同規則,導致變數橫生;倘若經歷過之後,這個流程就可以描述為:說複雜也簡單,說慢也快;就以個人開發者來聊下相關經驗:

  • 首先需要開發一款快應用;務必確認好 minPlatformVersion 版本,應用命名稱也該有所考究,最好都是中文(利推廣);
  • 快應用官網註冊,完善相關資料之後(須手持身份證反面照片,需清晰),即可建立 & 提交你的快應用(有些資料要填寫);
  • 廠商稽核;對於華為、OPPO、小米等廠商,必須先繫結其開放者賬號才可以(Vivo 無需),所以得先到廠商註冊,並繫結賬號;
  • 繫結賬號,應用提交之後,接下來就是坐等;不同平臺稽核結果許有不同:如華為還需上傳免責函簽名至版權處等等;
  • 修正稽核提到的問題,如指出應用提交分類錯誤(HuaWei)、應用介面單一、功能過於簡單(OPPO)等,繼續提交,坐等即可(速度還行);

個人開發的傾城之鏈-快應用版已於 09-05 日,釋出上架;目前在 Vivo 廠商已稽核通過,可在支援快應用手機的負一屏、瀏覽器等搜尋傾城之鏈即可率先體驗,之後將持續迭代升級,敬請期待。

快應用存在的缺陷

從上面快應用特點,應該對其優點有所感受;接下來不妨‘揣測’下它或將是缺陷的存在(當然,在年與時馳間,隨著版本的不斷迭代升級,某些現在看來是缺陷,日後興許就蕩然無存,也說不定)。

  • 若要執行「快應用」,須要手機出廠時在底層支援;否則就須要先安裝平臺預覽版;
  • 使用前端技術棧開發,native 渲染,標籤、樣式、功能等都需要一一對映處理,目前來看支援不夠完善;長期迭代情況將會好轉;
  • 暫不支援使用主流前端框架(Eg: vuereact)進行開發,且很多功能需要填補;長期迭代情況將會好轉;
  • 相比於其他‘競品’而言,文件、周圍生態系統、等都需要亟待完善;長期迭代情況將會好轉;
  • 由國內 Android 手機廠商聯合推出的,不支援 IOS 作業系統,目測以後也無法給予支援;
  • 社交:「快應用」缺乏微信的社交場景能力和傳播手段,推廣拉新,成本不低;再有上一條先天不足,現在來看,不容樂觀。
  • ……

如何看待「快應用」?

就目前來看,在移動裝置市場,充盈各種型別的應用,大有“諸子百家爭鳴”之基礎;以技術棧來分,有原生型、混合型、Web 型、小程式、「快應用」…… 百花齊放;從類別上看,有支付寶這般豐富的超級 App,亦有許多精品級小眾應用;就使用者而言,不僅能享受其便捷性,同時也能體驗市場的多元化;而各種不同型別應用間良性競爭,對更一步改善使用者體驗也是大有裨益。如此,看來「快應用」的誕生,從外部環境來看,有其成長的土壤;而具有體量的公司都參與的事情(如閃充、全面屏),便是不錯的趨勢,至少不會輸,受影響的是舊的模式 ── 原生應用。

出於業務需求以及使用者拉新等方面訴求,Native VS Web 這個由來已久之爭,如今愈發向前端技術棧傾斜,且已佔上風;雖然說,技術的發展,同時有給 Native 和 Web 兩種模式,都提供了利好(對 Web,硬體提升使得體驗越來越好;於 Native,越來越大的儲存空間使得使用者裝 APP 成本下降),但“即點即用”這種快捷模式的橫空出世,附帶以前端技術棧開發的低成本,將打破固有局面,修改使用者原有習慣,從而漸變整個格局。

談及「快應用」,微信小程式是無法繞過的點;兩者肯定存在競爭關係,同時也可算是夥伴:如同兩部同時上映的電影,雖有競爭,也會是彼此之助力,共同把盤子做大,吸引更多的使用者傾斜,從而變更未來的應用格局。再有,都是基於前端技術棧,如能有互轉工具給予鋪成,對於開發者而言,即可實現一次編寫,多平臺執行;將會為這種模式提升更多競爭力。

上面已經從出生層面,對「快應用」和小程式做了對比;「快應用」使用 Native 渲染,而非小程式基於 Webview 渲染,再加上硬體資源扶持,體驗上則能更上一層樓。況且,對於已經司空見慣的事物,新鮮感在如今看來,也極具誘惑,如子彈簡訊的出現;就小程式而言目前火熱程度,已有百萬應用,漸成壟斷之勢,從過往歷史來看,這對於使用者來講,絕不都是好事;而對於開發商來說,也盡是受制於人(騰訊有絕對控制權),無法主導自己命運,多個渠道,則多份活路;況且,兵無常勢,水無常形,在大時代的拉鋸之下,微信又豈會是永恆的王者?獨立的才是自己的,而小程式並不提供這方面紅利;對於個人開發者來講,加入「快應用」陣營,藉助廠商流量扶持,為自己獨立平臺倒量,不失為更明智的抉擇;現在來看「快應用」,機遇與挑戰並存,未來它將如何,朋友你怎麼看?

@2018-08-06 於深圳.福田 Last Modify:2018-09-02

@2018-08-06 於深圳.福田 Last Modify:2018-09-02