鴻蒙 Next 上好用的投屏工具？

最近研究了一段時間 hypium 和一些 devecho 開發工具的 jar 包，各種反編譯，逆向啥的，找了一些方案，大概整理下。

現在可以找到的：
deveco testing 的投屏工具，使用 uitest 命令載入一個 so，名字叫 “libscrcpy_server.z.so”。
1、執行命令：/system/bin/uitest start-daemon singleness --extension-name libscreen_recorder.z.so -p 5001 -m 1，這句命令大概就是在 5001 開放一個 grpc 服務。
2、按介面定義 proto 獲取資料，看了下投屏工具的使用效果，我猜測大機率是在瘋狂截圖，然後 h5 渲染的圖片，事件轉發用的 uiinput，用起來很卡頓。

觀察到上面的效果，我看名字既然包含 scrcpy，那我是不是可以嘗試安卓 scrcpy 的路子，安卓的路子大概這樣：
1、使用系統反射獲取螢幕，編碼為 h264 流，開一個 socket 服務，把碼流丟到這個 socket 服務上
2、客戶端檢視的時候，接收 socket 的碼流，解碼渲染
3、這種流暢度比截圖要高出不少，應為只傳送變化的部分，單位時間內傳送的資料少很多
4、然後第一步是用 Java 實現，做成安卓虛擬機器支援的可執行檔案格式：dex，使用 app_process 執行

於是，我在鴻蒙一番探索，首先是不走 app 的方式，因為這種方式最方便，我嘗試了 2 個路子：
1、C、C++ 編譯可執行檔案，因為 HM-next 本身支援 native 開發和 ts（js）開發，一頓操作猛如虎，一上真機執行不了，提示沒許可權（這裡可能有人說你沒 chmod 777，別說了，我試過了），模擬器可以執行
2、ts 之路，這個路子試過了，ts 可以編譯為 abc（可以類比於為 dex 檔案），但是鴻蒙上沒有執行這個檔案的命令。。。
結論：眼看著這路子不通，只能繞彎了，我只能想個不用 app 的辦法

思路如下:
1、既然反射、內部 api 啥的走不通，那暫時只能用截圖（鴻蒙內建 2 個截圖：snapshot_display 和 uitest screenCap，前者效率比後者搞很多）
2、檔案傳輸通道：走 pipe 通道，就是先截圖、然後編碼為 base64
3、h5 渲染，img 標籤渲染
4、h5 獲取使用者事件，轉發給裝置（uiinput 命令）

有人說，你這個和 devecho testing 不是一樣麼，一不一樣我不知道，但是我只知道，我比他稍微流暢那麼一丟丟。因為原生能力不行，所以只能策略來湊，比如我想到以下 magic：
1、首先截圖方式：前面說了系統內建 2 個截圖命令，snapshot_display 和 uitest screenCap，根據我 10W 次測試情況看，snapshot_display 效率高，所以截圖用這個
2、圖片截圖解析度，沒必要或者原螢幕解析度，可以縮到原來的 30~40%，這樣傳輸的檔案大小由原來的 100+kb 就縮小到 10+kb，理論上可以提高幀率
3、截圖拉取的方式，沒必要拉到本地，可以直接在機器上轉換為 base64 直接走 pipe 獲取
4、在電腦（客戶端）上渲染，可以考慮一些高效率的解碼渲染方式，不用 h5

以上就是 4 個最佳化小妙招，有興趣的可以一塊折騰。