本文由轉(zhuǎn)轉(zhuǎn)技術(shù)團(tuán)隊(duì)趙衛(wèi)兵分享，原題“鴻蒙新篇章：轉(zhuǎn)轉(zhuǎn) APP 的 HarmonyOS Next 開發(fā)之旅”，下文進(jìn)行了排版優(yōu)化和內(nèi)容修訂。
1、引言
2023 年在華為開發(fā)者大會(huì)（HDC.Together）上，除了面向消費(fèi)者的 HarmonyOS 4 之外，華為還推出了面向開發(fā)者的 HarmonyOS Next 開發(fā)者預(yù)覽。
而在去年的 6 月份華為開發(fā)者大會(huì)上，對(duì)外開啟了 HarmonyOS Next Beta 版，并在當(dāng)年內(nèi)正式推出面向消費(fèi)者的商用版本。
HarmonyOS Next，是鴻蒙生態(tài)的一個(gè)重要拐點(diǎn)。去年的時(shí)候，轉(zhuǎn)轉(zhuǎn)和華為已經(jīng)達(dá)成合作，作為鴻蒙先鋒的一員，加入到鴻蒙應(yīng)用的開發(fā)之中來。
客戶端從 2023 年 11 月份開始，人力開始逐漸的往這個(gè)方向投入，于 2024 年 2 月份正式開始進(jìn)入業(yè)務(wù)開發(fā)，在 6 月 4 號(hào)，對(duì)外正式發(fā)布了基于 HarmonyOS Next 系統(tǒng)的轉(zhuǎn)轉(zhuǎn) App 首個(gè)版本。
從早期的學(xué)習(xí)到最終第一個(gè)版本上線，我們經(jīng)歷了以下幾個(gè)階段：
- 1）前期的熟悉和學(xué)習(xí)過程；
- 2）鴻蒙客戶端基建開發(fā)過程；
- 3）首個(gè)版本需求范圍確定和排期；
- 4）業(yè)務(wù)開發(fā)；
- 5）測(cè)試；
- 6）bug 修復(fù)/性能調(diào)優(yōu)；
- 7）上線。
本文將要分享的是轉(zhuǎn)轉(zhuǎn)APP在開發(fā)全新鴻蒙NEXT端所遇到的一些問題，對(duì)比了鴻蒙開發(fā)和 Android、iOS 的不同，總結(jié)了這次開發(fā)過程中的一些經(jīng)驗(yàn)等等。希望能帶給你啟發(fā)。
2、關(guān)于作者
趙衛(wèi)兵：目前負(fù)責(zé)轉(zhuǎn)轉(zhuǎn)集團(tuán) iOS 和鴻蒙系統(tǒng) App 基礎(chǔ)架構(gòu)和相關(guān)基礎(chǔ)建設(shè)。崇尚開源和分享精神，Sharing is everything ~
轉(zhuǎn)轉(zhuǎn)團(tuán)隊(duì)分享的其它幾篇技術(shù)文章有興趣也可讀一讀：
- 轉(zhuǎn)轉(zhuǎn)平臺(tái)IM系統(tǒng)架構(gòu)設(shè)計(jì)與實(shí)踐(一)：整體架構(gòu)設(shè)計(jì)
- 轉(zhuǎn)轉(zhuǎn)平臺(tái)IM系統(tǒng)架構(gòu)設(shè)計(jì)與實(shí)踐(二)：詳細(xì)設(shè)計(jì)與實(shí)現(xiàn)
- Web端IM聊天消息該不該用瀏覽器本地存儲(chǔ)？一文即懂
- 手把手教你使用網(wǎng)絡(luò)編程抓包神器Wireshark
- 淺談網(wǎng)頁端IM技術(shù)及相關(guān)測(cè)試方法實(shí)踐（包括WebSocket性能測(cè)試）
3、初識(shí)鴻蒙NEXT
3.1 分布式技術(shù)
HarmonyOS Next 具備強(qiáng)大的分布式技術(shù)，能夠?qū)崿F(xiàn)跨設(shè)備協(xié)同工作。用戶可以無縫地在不同的設(shè)備間切換和使用應(yīng)用，無需感知設(shè)備的差異。HDC 大會(huì)中如 WPS Office、高德等 APP，使用了應(yīng)用接續(xù)特性，在不同設(shè)備中進(jìn)行流轉(zhuǎn)，令人印象深刻。這點(diǎn)在 iOS 和 Android 中并不完全具備。
3.2 高性能低時(shí)延
HarmonyOS Next采用輕量級(jí)的微內(nèi)核設(shè)計(jì)。
iOS 使用的內(nèi)核基于 XNU（X is Not Unix）內(nèi)核，XNU 是一個(gè)混合內(nèi)核，結(jié)合了微內(nèi)核（Mach 內(nèi)核）的內(nèi)存管理、任務(wù)調(diào)度、進(jìn)程間通信等特性和宏內(nèi)核（BSD 內(nèi)核）的文件系統(tǒng)、網(wǎng)絡(luò)堆棧、用戶進(jìn)程管理等特性。
Android 內(nèi)核基于修改過的 Linux 宏內(nèi)核，增加了 Binder IPC、電源管理、安全性等模塊和機(jī)制，以更好的支持移動(dòng)設(shè)備。
鴻蒙的微內(nèi)核設(shè)計(jì)，官方稱相比宏內(nèi)核，具備更高的性能和更低的時(shí)延，從而在多任務(wù)處理、設(shè)備響應(yīng)和處理能力上具有明顯優(yōu)勢(shì)。
3.3 自適應(yīng)UI框架
通過 ArkUI和ArkTS，HarmonyOS Next能夠適應(yīng)各種尺寸和形狀的屏幕設(shè)備，提供一致友好的用戶體驗(yàn)。這個(gè)特性在跨設(shè)備協(xié)同時(shí)尤其重要。
3.4 多終端、多OS支持
HarmonyOS Next 不僅僅是一個(gè)手機(jī)操作系統(tǒng)，還能運(yùn)行在平板、智能穿戴設(shè)備、智能家居設(shè)備等多種終端上，統(tǒng)一生態(tài)系統(tǒng)。對(duì)比蘋果的iOS，MacOS，TVOS，WatchOS，確實(shí)有些不同。但對(duì)于應(yīng)用開發(fā)者而言，其實(shí)就是API的能力集合問題，這一點(diǎn)，鴻蒙使用 SysCap 系統(tǒng)能力集合達(dá)到了殊途同歸的效果。
3.5 更優(yōu)秀的安全性
在應(yīng)用安全層面，目前在應(yīng)用的生態(tài)中有以下一些問題：
- 1）誘導(dǎo)用戶下載安裝惡意應(yīng)用；
- 2）竊取用戶數(shù)據(jù)；
- 3）強(qiáng)制推送廣告；
- 4）利用漏洞攻擊其他應(yīng)用程序；
- 5）盜版軟件。
這方面，由于Android 的開放性以及側(cè)載安裝的支持，問題表現(xiàn)的尤為明顯，而 iOS 是一個(gè)可以學(xué)習(xí)的老師。
針對(duì)上面的問題，HarmonyOS Next 又是如何應(yīng)對(duì)的呢？
- 1）做好應(yīng)用質(zhì)量的監(jiān)管，控制應(yīng)用分發(fā)渠道，避免惡意應(yīng)用分發(fā)到用戶設(shè)備上；
- 2）提供安全的數(shù)據(jù)授權(quán)機(jī)制，避免用戶過度授權(quán)造成安全威脅；
- 3）給應(yīng)用程序開放的系統(tǒng)功能做到不被惡意利用；
- 4）幫助應(yīng)用程序最小程度的受到漏洞影響；
- 5）為應(yīng)用程序提供有效的核心數(shù)字產(chǎn)權(quán)保護(hù)手段，避免出現(xiàn)盜版軟件問題。
具體可以看下圖：
（圖片來自《鴻蒙生態(tài)應(yīng)用安全技術(shù)白皮書 V1.0》）
4、和Android、iOS的開發(fā)有何不同？
鴻蒙開發(fā)上，和 Android、iOS 還是有不少相似和不同的地方，我挑選感受比較深刻的幾個(gè)點(diǎn)說下。
4.1 開發(fā)語言和工具鏈
鴻蒙開發(fā)使用的是ArkTS 語言，ArkTS基于 TypeScript 做了一些擴(kuò)展，繼承了 TypeScript 的所有特性，是 TypeScript 的超集。
下面是官方的一些介紹：
ArkTS的一大特性是它專注于低運(yùn)行時(shí)開銷。ArkTS對(duì)TypeScript的動(dòng)態(tài)類型特性施加了更嚴(yán)格的限制，以減少運(yùn)行時(shí)開銷，提高執(zhí)行效率。通過取消動(dòng)態(tài)類型特性，ArkTS代碼能更有效地被運(yùn)行前編譯和優(yōu)化，從而實(shí)現(xiàn)更快的應(yīng)用啟動(dòng)和更低的功耗。
與JavaScript的互通性是ArkTS語言設(shè)計(jì)中的關(guān)鍵考慮因素。鑒于許多移動(dòng)應(yīng)用開發(fā)者希望重用其TypeScript和JavaScript代碼和庫，ArkTS提供了與JavaScript的無縫互通，使開發(fā)者可以很容易地將JavaScript代碼集成到他們的應(yīng)用中。這意味著開發(fā)者可以利用現(xiàn)有的代碼和庫進(jìn)行ArkTS開發(fā)。
在開發(fā)工具上：使用的 IDE 是 DevEco Studio，基于 IntelliJ IDEA Community 開源版本打造，為開發(fā)者提供工程模板創(chuàng)建、開發(fā)、編譯、調(diào)試、發(fā)布等功能。華為在這個(gè) IDE 上針對(duì)鴻蒙開發(fā)易用性上做了大量的工作，包含但不限于編譯器，代碼實(shí)時(shí)預(yù)覽、ArkUI Inspector、Profile 性能分析工具等等。
在包管理上：有點(diǎn)類似前端的 npm 包管理機(jī)制，不過在這塊，是叫 ohpm，整體上非常相似，但是細(xì)節(jié)上有一些不同，譬如 package.json 的文件命名、lock 文件的內(nèi)容信息、獨(dú)立的開源中心倉等等。倉庫這塊也提供了私倉部署的方式，采用套件工具中的 ohpm-repo就可以部署到企業(yè)內(nèi)部服務(wù)器上。
在調(diào)試上：和 Android 的 ADB 類似，鴻蒙這塊提供了一個(gè) hdc 的工具，提供了類似查詢?cè)O(shè)備列表、網(wǎng)絡(luò)、文件、應(yīng)用安裝卸載、shell、日志獲取等常用功能。
4.2 開發(fā)體驗(yàn)
鴻蒙開發(fā)是用 ArkUI，類似 Flutter，SwiftUI 這樣的聲明式 UI，ArkUI 組件的命名和狀態(tài)管理和 SwiftUI 比較類似，上手比較容易。
4.3 開發(fā)資料和交流
Android 從 2008 年谷歌布，iOS 從 2007 年蘋果發(fā)布，距離到現(xiàn)在已經(jīng)有了 16～17 年之久，在這期間，互聯(lián)網(wǎng)上積累了無數(shù)的開發(fā)資料和經(jīng)驗(yàn)分享，也有著大量的開源項(xiàng)目和社區(qū)。
而有關(guān) HarmonyOS Next 方面的資料，目前更多的是官方開發(fā)指南和開源范例（集中在 gitee 上）。
社區(qū)方面，主要是華為開發(fā)者論壇，受限于開發(fā)者版本的迅速迭代，一些帖子討論的內(nèi)容已經(jīng)過時(shí)且不再適用。
而在博客、github 開源上，目前看到的其實(shí)并不多，更多的分享還是比較基礎(chǔ)，深度有價(jià)值的還不多。
目前在這個(gè)階段，更多的是企業(yè)和華為合作的情況下，內(nèi)部使用 Issue 工單系統(tǒng)進(jìn)行溝通交流。交流主要圍繞著需求、Bug 反饋、指南疑問來展開。
譬如：
- 1）指南資料中提供的能力，不滿足訴求，交流是否有更好的解決方案；
- 2）API 、IDE、工具鏈表現(xiàn)不符合預(yù)期，反饋 bug；
- 3）系統(tǒng)能力類比 Android、iOS 缺失的特性，交流是否有替代的解決方案。
截止到本篇文章寫的時(shí)候，轉(zhuǎn)轉(zhuǎn)華為工單交流的總數(shù)已達(dá)到 270+個(gè)。反饋的 bug 和缺失的能力，在后面的開發(fā)者預(yù)覽版本中都被修復(fù)或支持了。
印象比較深刻的一件事是：開發(fā)和測(cè)試期間我們發(fā)現(xiàn)了停留在登錄頁面不動(dòng)，過個(gè)10 分鐘左右，系統(tǒng)就會(huì)卡死重啟，我們一度以為是 App 哪里有 bug。我們通過 hdc hilog 抓取系統(tǒng)輸出的日志，發(fā)現(xiàn)大約過了 10 分鐘左右，log 就會(huì)死循環(huán)打印，很明顯系統(tǒng)底層發(fā)生了一些異常。已經(jīng)晚上快 1 點(diǎn)了，我們興奮的找到和我們對(duì)接這個(gè)問題的華為工程師張老師，將視頻和日志發(fā)送給他，張老師按照復(fù)現(xiàn)的路徑，也成功復(fù)現(xiàn)出來，并且抓取到日志。后面的幾天，經(jīng)過華為伙伴的努力，終于定位到問題所在，是文件句柄 FD 存在泄露的情況，并在下一個(gè)開發(fā)者版本中推送修復(fù)了。
為華為工程師的敬業(yè)和效率豎一個(gè)大拇指，華為之所以強(qiáng)大，從這件事的跟進(jìn)和解決效率上，就能理解到為什么。
5、踩坑后總結(jié)的幾個(gè)經(jīng)驗(yàn)
5.1 類比學(xué)習(xí)
投入鴻蒙開發(fā)的客戶端同學(xué)，有來自 Android 開發(fā)的，也有來自 iOS 開發(fā)的，或多或少對(duì)另外一端的系統(tǒng)了解的不是很全面。
在學(xué)習(xí)的過程中，我們發(fā)現(xiàn)鴻蒙的一些特性和 API 設(shè)計(jì)，有些和 iOS 比較像，而有些和 Android 有些像。我們內(nèi)部經(jīng)常討論交流和理解 HarmonyOS Next 的應(yīng)用層設(shè)計(jì)問題。在方案選擇上，HarmonyOS Next 中都有借鑒和取舍。
這個(gè)階段：我們需要重點(diǎn)理解鴻蒙特有的一些設(shè)計(jì)概念和思想。譬如 Stage 模型，Stage模型是從 API 9 開始新增的模型，是目前主推且會(huì)長(zhǎng)期演進(jìn)的鴻蒙應(yīng)用模型。在該模型中，由于提供了 AbilityStage、WindowStage 等類作為應(yīng)用組件和 Window 窗口的“舞臺(tái)”，這種方式在 Android、iOS 上是不是有類似的概念呢？
如果我們?nèi)缦骂惐?Android、iOS。
AbilityStage 和 WindowStage：
- 1）在 iOS 中，與 UIViewController 和 UIWindow 類似。UIViewController 管理視圖層次和界面行為，而 UIWindow 是應(yīng)用程序的窗口，可以顯示內(nèi)容；
- 2）在 Android 中，可以類比于 Activity 和 Window。Activity 是應(yīng)用的單個(gè)屏幕，負(fù)責(zé)界面的創(chuàng)建和管理，而 Window 是 Activity 的頂層視圖容器。
UIAbility 和 ExtensionAbility：
- 1）UIAbility 可以和 iOS 的 UIViewController 以及 Android 的 Activity 相對(duì)應(yīng)，因?yàn)樗鼈兌际怯糜诠芾砗惋@示用戶界面的基本單元。
- 2）ExtensionAbility 可以類比于 iOS 的 App Extension 和 Android 的 Service。App Extension 提供了將功能擴(kuò)展到系統(tǒng)范圍內(nèi)的能力，而 Service 在 Android 中則是運(yùn)行在后臺(tái)的組件，執(zhí)行長(zhǎng)時(shí)間運(yùn)行的操作。
雖然細(xì)節(jié)有所不同，但大方向上這樣對(duì)比和類比，會(huì)幫助我們快速理解鴻蒙相關(guān)開發(fā)概念。
5.2 項(xiàng)目管理和風(fēng)險(xiǎn)方案應(yīng)對(duì)
首個(gè)版本的開發(fā)，幾乎涉及到了公司所有的業(yè)務(wù)部門，我們通過啟動(dòng)會(huì)拉齊背景信息，前期讓大家梳理到新增一個(gè)鴻蒙終端對(duì)業(yè)務(wù)的影響范圍，以及解決方案。
1）PlanB 方案：
一些三方 SDK 如微信、支付寶等在前期都是沒有的，我們首個(gè)版本需要做好 PlanB 方案。涉及到的包括登錄、支付、分享等業(yè)務(wù)，都需要針對(duì)這些進(jìn)行調(diào)整。
2）有限的測(cè)試機(jī)：
因?yàn)闃I(yè)務(wù)部門參與進(jìn)來的很多，但工程樣機(jī)十分有限。服務(wù)端和前端同學(xué)代碼調(diào)整完畢后如何測(cè)試呢？這個(gè)是我們不得不考慮的一件事情。
新增一個(gè)鴻蒙終端，服務(wù)端調(diào)整后端代碼，在測(cè)試和沙箱測(cè)試時(shí)，除了回歸不要影響 Android 和 iOS 之外，還要能保證針對(duì)鴻蒙的兼容調(diào)整是有效的。鑒于鴻蒙測(cè)試機(jī)器十分有限，我們給 Server 同學(xué)提供了 Android 測(cè)試包，將 Android 測(cè)試包的終端 mock 成鴻蒙終端來供服務(wù)端測(cè)試接口，這樣子測(cè)試下來十分高效。
針對(duì)前端同學(xué)：不能再向剛才那樣做了，畢竟是用 Android 的 WebView。即便我們 WebView 的 UserAgent mock 成 Android 系統(tǒng)，使得通信和交互仍然走類似 Android 的策略，而這樣并不能代表真實(shí)的鴻蒙 WebView 環(huán)境，因?yàn)樵?Next 系統(tǒng)中整個(gè) Native 和 Webview 的通信 Bridge 是全新的一套方案，且鴻蒙的 API 實(shí)現(xiàn)接口也都需要走鴻蒙側(cè)來測(cè)試。針對(duì)這個(gè)情況，我們非常謹(jǐn)慎小心的將各個(gè)業(yè)務(wù)部門的參與進(jìn)來的時(shí)間錯(cuò)開，盡力保證在有限測(cè)試機(jī)的情況下，每個(gè)業(yè)務(wù)輪轉(zhuǎn)參與進(jìn)來的時(shí)候都是有機(jī)器的。
5.3 多和華為伙伴進(jìn)行溝通
這部分的經(jīng)驗(yàn)，具有一定的時(shí)效性。后期商用版本發(fā)布之后，可能這樣的溝通渠道、頻次很難再有了。
為什么要多和華為伙伴時(shí)刻保持密切的溝通？有幾個(gè)印象深刻的例子。
1）第一個(gè)例子：路由
鴻蒙關(guān)于頁面跳轉(zhuǎn)提供了兩套解決方案，一套是頁面路由 router，一套是組件導(dǎo)航 Navigation。前期我們?cè)诨ㄩ_發(fā)期間，采用的頁面路由 router 方案，@zz/router 組件代碼已經(jīng)開發(fā)完畢了，但是到了開發(fā) WebView 的 Hybrid 接口時(shí)，才意識(shí)到一個(gè)嚴(yán)重的問題，就是 router 提供的能力，并不能滿足我們復(fù)雜的頁面棧管理，譬如在頁面棧中多個(gè) WebView，我們需要關(guān)閉指定的 WebView 頁面，router 提供的 API 能力是無法做到的。和華為溝通后才知道，官方是推薦 Navigation 來實(shí)現(xiàn)，且未來 router 方案不再演進(jìn)。我們提出的復(fù)雜頁面棧管理的能力，彼時(shí) Navigation 支持的還不完整，但是伙伴告訴我們，他們會(huì)在 Navigation 上滿足我們的需求。關(guān)閉頁面棧中指定 index 或者 name 的頁面，相信其他開發(fā)者也都會(huì)遇到，應(yīng)該是一個(gè)普遍的需求。
基于這種情況，我們不得不迅速調(diào)整我們的路由組件，基于 Navigation 重新設(shè)計(jì)了一套路由方案，還好項(xiàng)目業(yè)務(wù)還沒有開始大量開發(fā)，要改動(dòng)的地方也不是很多，如果溝通再晚點(diǎn)，恐怕調(diào)整起來代價(jià)會(huì)相對(duì)更高點(diǎn)。此時(shí)的溝通，讓我們少走了彎路，避免在 router 上走投無路死磕方案。
2）第二個(gè)例子：企業(yè)分發(fā)
企業(yè)分發(fā)通常用于企業(yè)內(nèi)部測(cè)試、企業(yè)內(nèi)部 App 等。Dev 證書和 iOS 的 Dev 證書類似，Provisioning Profile（p7b 文件）會(huì)有 100 臺(tái)設(shè)備的限制。考慮到將來，轉(zhuǎn)轉(zhuǎn)也想依賴企業(yè)分發(fā)能力，可以在測(cè)試中采用企業(yè)簽名打包來進(jìn)行測(cè)試。雖說在當(dāng)前階段不是硬性和必要的，但是我們還有一個(gè)轉(zhuǎn)轉(zhuǎn)質(zhì)檢 App，這個(gè) App 我們不能通過 AGC 后臺(tái)上架華為市場(chǎng)，因?yàn)樵谫|(zhì)檢中心，如果不走內(nèi)部分發(fā)安裝，那么我們將會(huì)面臨著外網(wǎng)下載，會(huì)給質(zhì)檢中心的帶寬帶來很大的負(fù)載以及成本。
我們密切關(guān)注者企業(yè)分發(fā)能力的就緒時(shí)間，在今年的 5 月份，AGC 后臺(tái)企業(yè)分發(fā)能力提供之后，立即進(jìn)行了全流程處理，包括申請(qǐng)企業(yè)開發(fā)者、申請(qǐng)證書以及測(cè)試走通下載整個(gè)過程。這種情況下，通過及時(shí)交流，我們可以第一時(shí)間進(jìn)行測(cè)試實(shí)踐，有效降低或者避免了未來方案上的一些風(fēng)險(xiǎn)。
3）第三個(gè)例子：安全控件與系統(tǒng) Picker
相信廣大開發(fā)者今年剛開始介入 HarmonyOS Next 開發(fā)時(shí)，對(duì)于使用到的一些權(quán)限，如讀取剪貼板，讀取或者保存圖片到相冊(cè)等等這些 ACL（Access Control List）訪問控制列表權(quán)限，都是通過在開發(fā)者后臺(tái)勾選這些權(quán)限從而實(shí)現(xiàn)在應(yīng)用中彈窗許可訪問。但是在今年 6 月份的溝通中，我們獲知后面要讓開發(fā)者全部適配到安全控件方案。這些安全控件都是系統(tǒng)提供的選擇器，使用之后，每次需要用戶明確操作才行。
目前在 Android 和 iOS 中，如果想要在應(yīng)用中上傳一張照片，就需要同意該應(yīng)用獲得圖庫的訪問權(quán)限，而帶來的弊端就是，這個(gè)應(yīng)用今后可隨意訪問你圖庫中的所有圖片。相比之前的授權(quán)彈窗許可一次之后，可能造成的權(quán)限濫用，安全控件提升了用戶對(duì)敏感權(quán)限的操作感知，算是 HarmonyOS Next 在保障用戶隱私安全方面的一個(gè)亮點(diǎn)和優(yōu)勢(shì)。
這其中的核心理念便是從權(quán)限管控到數(shù)據(jù)管控。在 Android 和 iOS 原本的權(quán)限管控方案中，比如一旦給了通訊錄權(quán)限，那么相當(dāng)于把通訊錄的鑰匙給予了應(yīng)用開發(fā)者，如果開發(fā)者違規(guī)使用，在用戶不知情的讀取整個(gè)通訊錄，其實(shí)是不符合用戶的隱私要求。而數(shù)據(jù)管控便是不會(huì)再把通訊錄的鑰匙給開發(fā)者，而是你要什么樣的通訊錄數(shù)據(jù)，那么你只能通過通訊錄安全選擇控件中來選擇想要讀取的通訊錄，不再讓應(yīng)用隨意獲取整個(gè)通訊錄數(shù)據(jù)。
關(guān)于安全控件我們進(jìn)行了多次溝通，了解了安全控件在華為側(cè)推進(jìn)的節(jié)奏以及我們整改的期限時(shí)間等，另外我們也提出個(gè)別場(chǎng)景，安全控件還不足以滿足訴求，譬如用戶保存圖片到相冊(cè)，還沒有對(duì)應(yīng)的安全控件能力。這方面的溝通，會(huì)讓我們及時(shí)的對(duì) App 的隱私合規(guī)性做出優(yōu)化調(diào)整，避免后面因?yàn)殡[私權(quán)限問題而影響上架。
及時(shí)溝通對(duì)于了解 Bug 的解決情況，功能交付時(shí)間、華為伙伴的要求等都是很有必要的，因?yàn)檫@些都會(huì)影響到開發(fā)測(cè)試到上線的一個(gè)節(jié)奏。
6、鴻蒙NEXT上的WebView混合頁面開發(fā)
6.1 概述
回到我們大前端來，得提一下大家關(guān)注的 WebView。在 HarmonyOS Next 中仍然沿用之前統(tǒng)一的 WebView 架構(gòu)。
在 V1 版本中，需要做的核心工作包括：
- 1）實(shí)現(xiàn) WebView Core 層；
- 2）JSBridge 層，新增實(shí)現(xiàn) HarmonyOS Next 的 Bridge 通信；
- 3）平移安全層能力；
- 4）實(shí)現(xiàn) Hybrid API 接口，也就是 Ability 層的能力。
需要特別提一下的是：HarmonyOS Next 使用的 Web 瀏覽器基于 ArkWeb（方舟Web內(nèi)核），該內(nèi)核基于 Chrome 114 版本定制，對(duì)于各種 CSS、HTML、JS 屬性在各大瀏覽器中的兼容性情況可以使用 https://caniuse.com/#home 這個(gè)網(wǎng)站進(jìn)行查詢。
6.2 前期如何確定影響范圍和制定方案
Ability 層的接口：轉(zhuǎn)轉(zhuǎn)的 WebView 歷經(jīng)多年的演進(jìn)，Native 與 WebView 的交互 API 是有一定歷史包袱的。我們不希望鴻蒙這次繼續(xù)背著包袱前行，所以我們計(jì)劃趁著這次前端業(yè)務(wù)兼容鴻蒙的機(jī)會(huì)，進(jìn)行一波優(yōu)化，丟棄一些已經(jīng)計(jì)劃不再使用的能力或者接口。比如老的半屏 WebView 方案，導(dǎo)航欄按鈕功能設(shè)置方案、非統(tǒng)跳的頁面跳轉(zhuǎn)接口等。
但一個(gè)方案的確定要充分考慮客戶端實(shí)現(xiàn)的難易程度以及前端大量業(yè)務(wù)側(cè)統(tǒng)一修改的難度代價(jià)，需要做到盡可能的合理平衡。為了確定這點(diǎn)，我們根據(jù)線上最近一個(gè)月中URL 中接口調(diào)用的埋點(diǎn)日志，結(jié)合 URL 查詢所屬業(yè)務(wù)、開發(fā)測(cè)試負(fù)責(zé)人的內(nèi)部接口，整理了一張巨大的二維矩陣表，通過在線表格的過濾、篩選等功能，可以非常直觀的看到所有還在使用中的接口的業(yè)務(wù)調(diào)用分布情況，為我們?cè)u(píng)估方案改造工作量提供了重要的參考。
一個(gè) Hybrid API 在鴻蒙上支持情況，分為下面幾種情況。
a） 直接支持，前端無需修改：提供和 Android、iOS 一樣的接口能力：
- 1）功能對(duì)等：能力實(shí)現(xiàn)和 Andriod、iOS 一樣；
- 2）簡(jiǎn)化：比如瀏覽大圖、奢侈品鑒定，暫時(shí)使用簡(jiǎn)版選圖方案。
b） 推薦使用新方案：
- 1）譬如導(dǎo)航欄相關(guān)按鈕的能力、新半屏能力；
- 2）如 enterChat 等等功能，使用統(tǒng)跳接口來實(shí)現(xiàn)跳轉(zhuǎn)。
c） 不支持：
- 1）業(yè)務(wù)下線：業(yè)務(wù)不再需要，下線處理；
- 2）版本初期不考慮該功能；
- 3）某端特定功能：為了解決某個(gè)問題，某端專門增加的一個(gè) api 供使用；
- 4）系統(tǒng)能力不支持：HarmonyOS Next 沒有該項(xiàng)能力。
最終根據(jù)這些原則，我們確定下來 V1 版本中 WebView API 的需求范圍、涉及業(yè)務(wù)方、改動(dòng)方案。現(xiàn)在回想起來，當(dāng)時(shí)我們做的這一步是非常有必要的，前期這些如果沒有梳理清楚，后面就非常容易造成溝通混亂以及影響開發(fā)進(jìn)度。
6.3 關(guān)于性能
轉(zhuǎn)轉(zhuǎn)前端的頁面主要是 Web 形態(tài)，Hybrid 場(chǎng)景占據(jù)多數(shù)。在過去的幾年中，我們圍繞 Hybrid 形態(tài)，摸索出了一系列 Web 頁面的優(yōu)化方案。從基礎(chǔ)的離線包，到復(fù)雜的預(yù)渲染、預(yù)請(qǐng)求等都有涉及。最終實(shí)現(xiàn)了 Hybrid 頁面與 Native 頁面在電商場(chǎng)景下，相差無幾的體驗(yàn)。
目前鴻蒙在這塊優(yōu)化上，還都沒來得及跟進(jìn)這些優(yōu)化手段。這個(gè)也是后面要繼續(xù)建設(shè)的一個(gè)方向，最終要拉齊到和Android、iOS 一樣的性能優(yōu)化體驗(yàn)。
7、后續(xù)開發(fā)展望
首個(gè)版本上線，只是一個(gè)起點(diǎn)。
在業(yè)務(wù)上，我們將不斷的繼續(xù)追平 Android、iOS 中那些重要的模塊和功能；
在開發(fā)工具體驗(yàn)和支持上，也逐漸補(bǔ)足缺失的能力，比如豐富的Native、WebView小工具能力，進(jìn)一步提升客戶端和前端在 HarmonyOS Next 下的開發(fā)體驗(yàn)。
在性能體驗(yàn)上，持續(xù)的關(guān)注和跟進(jìn)性能問題，優(yōu)化 WebView 以及 Native 的使用體驗(yàn)，提升 App 的流暢度和響應(yīng)速度。
在創(chuàng)新上，我們將持續(xù)探索，將更多的 HarmonyOS Next 下的創(chuàng)新場(chǎng)景，如元服務(wù)、意圖推薦等等融入到轉(zhuǎn)轉(zhuǎn) App 中，提升用戶的購物使用體驗(yàn)。
要做的事情很多，我們會(huì)在后續(xù)迭代中逐步完善起來這些能力，敬請(qǐng)期待。
8、相關(guān)資料
[1] 鴻蒙NEXT官方開發(fā)指南
[2] 一年擼完百萬行代碼，企業(yè)微信的全新鴻蒙NEXT客戶端架構(gòu)演進(jìn)之路
[3] 鴻蒙NEXT如何保證應(yīng)用安全：詳解鴻蒙NEXT數(shù)字簽名和證書機(jī)制
[4] 開源IM聊天程序HarmonyChat：基于鴻蒙NEXT的WebSocket協(xié)議
[5] 微信純血鴻蒙版正式發(fā)布，295天走完微信14年技術(shù)之路！
[6] 即時(shí)通訊框架MobileIMSDK的鴻蒙NEXT端詳細(xì)介紹
[7] 即時(shí)通訊框架MobileIMSDK的鴻蒙NEXT端開發(fā)者手冊(cè)
[8] 轉(zhuǎn)轉(zhuǎn)平臺(tái)IM系統(tǒng)架構(gòu)設(shè)計(jì)與實(shí)踐(一)：整體架構(gòu)設(shè)計(jì)
[9] 轉(zhuǎn)轉(zhuǎn)平臺(tái)IM系統(tǒng)架構(gòu)設(shè)計(jì)與實(shí)踐(二)：詳細(xì)設(shè)計(jì)與實(shí)現(xiàn)
[10] Web端IM聊天消息該不該用瀏覽器本地存儲(chǔ)？一文即懂
[11] 手把手教你使用網(wǎng)絡(luò)編程抓包神器Wireshark
[12] 淺談網(wǎng)頁端IM技術(shù)及相關(guān)測(cè)試方法實(shí)踐（包括WebSocket性能測(cè)試）
（本文已同步發(fā)布于：http://www.52im.net/thread-4820-1-1.html）