[TOC]
關于鴻蒙開發(fā)中的HAP、HSP荆忍、HAR包的區(qū)別和思考
背景聲明
- 博主9年安卓開發(fā)格带，Web前端撤缴、Java棧的后臺和node棧后臺開發(fā)亦有涉獵，目前已加入鴻蒙領航者計劃叽唱，正在學習鴻蒙OS NEXT開發(fā)屈呕。
- 僅討論Stage模型下的開發(fā)
概念講解
HAP
全稱是Harmony Ability Package，這里且簡單翻譯為鴻蒙能力包棺亭，理解為模塊化分包虎眨。
如果類比安卓開發(fā)，可以理解為android多模塊項目中的module镶摘。（這里說一下差異嗽桩，在項目的源代碼上都是類似的結構，一個文件夾是一個module凄敢，但在打包編譯上碌冶，安卓是全部合并，鴻蒙則是每個HAP是獨立的贡未，最終打包成一個應用）
HAP有兩種類型种樱，一種是entry，是應用的主模塊俊卤，作為應用的入口嫩挤，提供了應用的基礎功能 （注意這里，也就是說消恍，應用的主入口和一些基本功能都應該放到這個模塊中來編寫代碼岂昭，這里應該是關系到應用啟動以及自由流轉功能是否快速且流暢）
另外一種是feature，特性狠怨，或者可以理解為功能模塊约啊。
總的來說HAP是將安裝包的不同功能進行模塊化分包的操作。
值得注意的是佣赖，HAP并不支持導出接口和ArkUI組件給其他模塊使用恰矩，也就意味著模塊之間是相互隔離的，這里和安卓開發(fā)完全不同憎蛤，安卓的多個模塊之間依然可以有層級關系（雖然這樣并不是一個好的做法）
HSP
全稱是Harmony Shared Package外傅，官方稱為動態(tài)共享包
HSP要求要和宿主應用具有相同的包名，如果需要給公司內(nèi)部的其他應用使用俩檬，需要了解集成態(tài)HSP(建議需要用到再研究)
使用HSP的優(yōu)勢：
- 多個HAP/HSP共用的代碼和資源放在同一個HSP中萎胰，可以提高代碼、資源的可重用性和可維護性棚辽，同時編譯打包時也只保留一份HSP代碼和資源技竟，能夠有效控制應用包大小。
- HSP在運行時按需加載屈藐，有助于提升應用性能榔组。
- 同一個組織內(nèi)部的多個應用之間熙尉，可以使用集成態(tài)HSP實現(xiàn)代碼和資源的共享。
根據(jù)官方文檔中的工具-DevEco Service-ohpm-repo私倉搭建工具-快速開始文中有段話：
三方庫包含靜態(tài)共享包 HAR 包和動態(tài)共享包 HSP 包搓扯，可以通過 ohpm 命令行工具和使用 Web 頁面兩種方式發(fā)布骡尽。
可以得知：HSP可以發(fā)布（只能發(fā)布到私倉，在發(fā)布HAR的文檔部分有提及:鏈接）
需要注意的是：HSP可以依賴其他HAR或HSP擅编，不支持循環(huán)依賴，也不支持依賴傳遞
HAR
全稱是Harmony Archive箫踩，官方稱為靜態(tài)共享包爱态。
官方的設定的職責是：通過HAR可以實現(xiàn)多個模塊或多個工程共享ArkUI組件、資源等相關代碼境钟。
使用場景主要是：作為二方庫锦担，發(fā)布到OHPM私倉，供公司內(nèi)部其他應用使用慨削；或作為三方庫洞渔，發(fā)布到OHPM中心倉，供其他應用使用缚态。
同樣的磁椒，需要注意的是：HAR可以依賴其他HAR，不支持循環(huán)依賴玫芦，也不支持依賴傳遞（HAR可以依賴HSP浆熔，但依賴HSP之后HAR僅支持應用內(nèi)共享。出處桥帆。這種用法應該并不常見）
三者區(qū)別
| 規(guī)格 | HAP | HAR | HSP |
|---|---|---|---|
| 支持在配置文件中聲明UIAbility組件與ExtensionAbility組件 | √ | × | × |
| 支持在配置文件中聲明pages頁面 | √ | × | √ |
| 支持包含資源文件與.so文件 | √ | √ | √ |
| 支持依賴其他HAR文件 | √ | √ | √ |
| 支持依賴其他HSP文件 | √ | √ | √ |
| 支持在設備上獨立安裝運行 | √ | × | × |
思考和討論
Q1：為什么會有HAP医增、HSP、HAR這樣的設計區(qū)分老虫？
我認為這種設計叶骨，是源于分布式系統(tǒng)的理念，具體體現(xiàn)為一次開發(fā)多端部署和自由流轉兩部分能力上的設計需要祈匙。
這種粒度的分包忽刽，我認為有以下優(yōu)勢：
- 能夠提升應用的啟動速度，應用啟動時菊卷，可以進行部分加載缔恳、按需加載。
- 實現(xiàn)一次開發(fā)多端部署洁闰，能夠按不同粒度的包歉甚，對應不同端，進行不同的包的替換扑眉、增加或減少纸泄，實現(xiàn)不同端的公共功能和不同特性的針對性整合赖钞。
- 自由流轉的功能上，應該是在目標設備并沒有安裝這個應用的情況下聘裁，這種分包設計能夠體現(xiàn)出最大優(yōu)勢雪营，通過網(wǎng)絡把必須的包進行傳遞，將運行內(nèi)存同步之后理論上就可以正常接續(xù)工作了（這里是分析猜測衡便，具體的實現(xiàn)應該有更精妙的策略）
那么順便總結一下各種包的實際用處：
- HAP主要用于按模塊封包不同的功能献起，方便按需加載。
- HSP主要用于多模塊的資源镣陕、代碼段等共用谴餐，但是只局限于應用內(nèi)部或者公司內(nèi)部的不同應用。HSP在應用打包時僅保留一份呆抑，并且不同模塊加載時會按需加載HSP岂嗓。
- HAR主要用于二方庫或三方庫的封裝，能夠被HAP和HSP依賴和使用鹊碍，但HAR會被重復打包進HSP和HAP中厌殉。
實際使用中應該是這樣的：
- 項目分為多個模塊（HAP）,每個模塊管理自己的依賴（HSP、HAR）
- 多模塊共用的資源侈咕、代碼段等公罕，在項目建立library或者新建項目，打包為HSP
- 項目內(nèi)部或者公司內(nèi)部共用的工具包一類耀销，建立項目熏兄，打包發(fā)布為HSP
- 開源共用的二方庫或三方庫，打包發(fā)布為HAR（不開源的官方還是推薦以HSP的形式使用）
Q2：為什么編譯HAP和HSP時树姨，會把他們所依賴的HAR直接編譯到HAP和HSP中摩桶？
我認為是為了自由流轉的按需加載的時候，保持一定大小的顆粒度帽揪，減少包的數(shù)量硝清，一方面在傳輸上每個包都會是一個新的傳輸，不如減少包的數(shù)量转晰，從而增加單位時間內(nèi)平均的傳輸速度芦拿，也就是數(shù)據(jù)量。（參考我們ohpm install的時候的操作對比就可以了解了）查邢。
還有就是裝載包蔗崎，比如確保我裝載入口HAP以及必要的HSP之后，程序就可以開始運行了
在開發(fā)上扰藕，因為依賴不傳遞缓苛，每個模塊可以聲明自己需要的依賴可以避免模塊依賴不需要的sdk（勉強算是一個好處）
另外因為HSP和HAR都是依賴不傳遞的，HAR編譯打包到HSP中邓深，這樣HAP依賴HSP的時候就不用單獨添加HSP依賴的HAR了（但是這個并不是主要原因未桥，并且HAP需要使用HAR時笔刹，還需要顯式的添加依賴，并且HAR會再次打包進HAP）
翻譯過來就是項目中的模塊冬耿，添加HSP依賴的時候舌菜，不用把HSP的依賴也添加一遍了（HSP完整）
Q3：能不能有更理想的方案？
我還是覺得依賴不傳遞亦镶，HAR重復打包的這種設定日月，不是一個最理想的方案，因為這些工作不應該也沒必要推給開發(fā)者缤骨，同時這三個概念對開發(fā)者形成了一定的學習成本山孔，在開發(fā)上，依賴的管理也成了一個負擔荷憋。
問題1，依賴不能傳遞
依賴不能傳遞是不是一種不得已的設定褐望？這是明確不利于封裝和共用的勒庄，如果項目足夠復雜，每個模塊的依賴清單可能就要難以管理了瘫里。
更理想的想法來說实蔽，能不能實現(xiàn)依賴傳遞，比如在添加依賴時谨读，開發(fā)者自己能夠決定依賴是否傳遞局装，但IDE能夠在編譯階段，自動判斷劳殖，自動依賴铐尚，而打包模式實際不變，這樣重復的手動配置依賴的操作就減少了哆姻。
問題2宣增，HAR重復打包
同樣的HAR重復打包，我理解為是一種為了分布式系統(tǒng)的一種設計矛缨，有優(yōu)勢爹脾，也有妥協(xié)。整體來說箕昭，已經(jīng)是先進的了灵妨，遙遙領先 : P。
對于重復打包的這種情況落竹，能不能有更理想的方案泌霍，比如說支持依賴傳遞，然后在不同的HAP進行重復打包述召∨氤常或者可以進行獨立的包管理碉熄，每個依賴都是一個包，其中的依賴關系肋拔，加載關系锈津，在打包時進行預置（接問題3）。
問題3凉蜂，包的流轉優(yōu)化
假設依賴支持傳遞并且打包進行獨立的包管理的前提下：自由流轉時的依賴包流轉琼梆，是不是可以在目標設備建立包管理庫，按包名窿吩、版本茎杂、hash等進行比對，對包進行計數(shù)和復用管理纫雁。自由流轉到目標設備時煌往，已存在的直接復用，可以減少包傳輸轧邪，減少流轉耗時刽脖，以及減少設備機身存儲占用。
以上關于依賴傳遞和打包方案的思考和討論忌愚，各位讀者是否有更好的思路曲管，歡迎評論區(qū)討論 : P。
