一、Hardcoder 的誕生
隨着微信愈來愈複雜,性能優化變得愈來愈難作,優化所帶來的效果提高也愈來愈不明顯。因此咱們⼀直在思考,該如何突破這個優化的極限?
直到有一次與廠商的交流咱們瞭解到,部分廠商會針對微信作一些小改動,其中比較典型的就是「暴力提頻」。系統在識別到微信啓動,頁面切換等場景時,會粗暴地提升 CPU 頻率,從而提高 APP 運行的性能。
但因爲廠商沒法準確判斷微信場景,暴力提頻效果並不理想;而若是過多地提升 CPU 頻率,又對手機的功耗有影響。這一方案啓發了咱們,咱們何不跳出軟件的範疇,在手機硬件的層面上挖掘更多的性能優化空間呢?因而 Hardcoder 框架應運而生。
二、Hardcoder 是什麼
廠商暴力提頻效果不理想是因爲在目前 Android 框架下,手機沒有辦法準確獲知 APP 須要資源的時機。若是咱們須要挖掘手機硬件層面的性能優化,就須要跳過 Android 操做系統的應用框架,在應用開發者和硬件之間打開一個通道,讓硬件能夠直接根據應用開發者的須要進行資源的調度。
Hardcoder 構建了 APP 與系統(ROM)之間可靠的通訊框架,突破了 APP 只能調用系統標準 API,沒法直接調用系統底層硬件資源的問題,讓 Android APP 和系統能實時通訊。
利用 Hardcoder,APP 能充分調度系統資源如 CPU 頻率,大小核,GPU 頻率等來提高 APP 性能,系統可以從 APP 側獲取更多信息以便更合理提供各項系統資源。同時,對於 Android 缺少標準接口實現的功能,APP 和系統間也能夠經過該框架實現機型適配和功能拓展。
三、Hardcoder 框架通訊流程
Hardcoder 框架分爲 Server 端和 Client 端。其中 Server 端在廠商系統側實現,Client 端以 aar 形式合入到 APP中。
APP 在須要資源的時候,向 Hardcoder 的 Client 端發出請求。Hardcoder Client 端接收到請求後向 Hardcoder Server 端發出請求。Server 端接受到請求後會根據請求參數向硬件申請不一樣的資源,好比調整 CPU 頻率,把線程綁定到大核運行等,實現了 APP 到系統的通訊。
同時系統也可把當前系統的狀態經過 Hardcoder Client 在 Server 端註冊的接口回調通知到 Client 端,從而 APP 能夠獲取到系統狀態,實現系統到 APP 的通訊。
Hardcoder Client 端與 Server 端採用的是 LocalSocket 的通訊方式,因爲 Hardcoder 採用 Native 實現,於是在 C 層使用 Linux 的 socket 接口實現了一套 LocalSocket 機制做爲 Client 端與 Server 端之間的通訊方式。

Hardcoder 通訊框架有如下特色:
- 1)系統服務爲 optional,實現上能夠徹底支持或者部分支持;
- 2)框架實現不依賴於特定 Android 系統,如 API level 限制;
- 3)APP 的功能和業務特性不依賴於該框架。
四、Hardcoder 適用場景和效果
Hardcoder 框架有效提高了微信啓動、發送視頻、小程序啓動等重度場景的速度,朋友圈的滑動流暢性也明顯提高,平均優化效果達 10%-30%。
此外,因爲微信做爲主動請求方能夠在場景資源把控上作得更精細和準確,Hardcoder 在性能獲得提高的同時僅增長了 2% 的電量消耗,至關於用 2% 的功耗換取平均 20% 的性能提高。
Hardcoder 框架目前已接入 OPPO、vivo、華爲、小米、三星、魅族等主流手機廠商,覆蓋 4.6 億+ 設備量。
五、Hardcoder 開源
從微信技術開放共享的理念出發,咱們在騰訊內部進行了 Hardcoder 框架的宣傳和推廣,包括手機 QQ、企業微信、每天快報等多個應用團隊接入。其中手機 QQ 接入 Hardcoder 後,在啓動、打開聊天界面、發送圖片等場景的平均優化效果達 10%-50%。
咱們現將 Hardcoder 框架開源,讓更多 Android 開發者享受到 Hardcoder 框架的價值,解決你們在性能優化和機型適配上的煩惱。
六、如何使用 Hardcoder
- 1)下載 Hardcoder 工程編譯 aar;
- 2)項目 build.gradle 引入 Hardcoder aar;
- 3)進程啓動時調用 initHardCoder 創建 socket 鏈接(通常進程啓動時須要請求資源,於是推薦在進程啓動時調用)。每一個進程都是獨立的,都須要調用 initHardCoder 創建 socket 鏈接,創建鏈接後每一個進程維持一個 socket,進程退出時 socket 也會斷開;
- 4)initHardCoder 回調成功後調用 checkPermission,傳入 APP 已申請的各個廠商鑑權值;
- 5)在須要請求資源的場景調用 startPerformance,傳入請求資源的參數。若場景位於進程啓動階段,好比 APP 啓動,須要在 initHardCoder 的回調成功之後再調用 startPerformance,確保鏈接已成功創建,或者判斷 HardCoderJNI 的 isConnect() 檢查 socket 是否已鏈接。
- 6)場景結束時主動調用 stopPerformance,傳入對應場景 startPerformance 時的返回值 hashCode 做爲參數,中止本次請求。
- 7)測試性能,APP 可對打開/關閉 Hardcoder 的狀況作對比實驗,測試性能是否有提高。
5、發佈帶 Hardcoder 功能的 APP。
附錄: github的wiki 文檔連接