微信在Github開源了Hardcoder，對Android開發者有什麼影響？

本文首發自公衆號「承香墨影（ID：cxmyDev）」，歡迎關注。

今年一月微信公開課 Pro 2019 上，提到的微信性能優化框架「Hardcoder」，近日終於開源了。

微信開源的東西，做爲 Android 開發，固然是雙擊 666 了。

可是做爲一名 Android 開發者，我更關心的是 Handcoder 究竟是什麼？對咱們 Android 開發者有什麼影響？

什麼是 Hardcoder?

Hardcoder 在 18 年微信就放出了消息，簡單來講，Hardcoder 是微信研發的一款性能優化框架。

若是看了這麼一句話，簡單去理解的話，好像只要等微信開源以後，咱們在 App 內也接入 Hardcoder，就能夠如微信般絲滑。

但理想老是很豐滿的…

Hardcoder 自己也是業務發展的產物，在微信愈來愈複雜後，常規的性能優化，帶來的提高已經愈來愈小了。可是從廠商的角度，微信這種國民 App，就應該秒開無卡頓，作到極致的優化。

打個比方說，若是那個廠商的手機，被發現微信很差用了，用戶確定是以爲這個手機有問題，而不是微信有問題。

有句話怎麼說的，「當你強大，整個世界都會對你和顏悅色」。

廠商也意識到了這一點，因此部分廠商早期是會針對微信，作一些小優化，其中比較典型的就是「暴力提頻」。系統在識別當前微信正在運行，會粗暴的提升 CPU 頻率，從而提高 App 的運行性能。

要知道，全部「一刀切」的事情，都是在暴露一些問題。

「暴力提頻」也是同樣。過多的提升 CPU 頻率，必然會對手機的功耗形成影響，最直接的影響，就是你發現你的手機耗電更快了。

廠商對硬件資源的限制，自己有一部分，也是從功耗的角度考慮的，隨着手機功能愈來愈豐富，其實電池技術是跟不上的，一款功能強大但離不開電源的手機，確定不會是用戶的理想選擇。

因此手機廠商就會對硬件作出一些限制，在不須要那麼多資源的時候，就減小資源的給予。可是資源的減小，必然會引發一些體驗上的問題，例如卡頓，而這種用戶體驗的問題，廠商也並不肯意。

畢竟誰卡，誰不卡，用戶心理天然有一杆秤。

但這其中有個難點，廠商之因此選擇一刀切這種暴力提頻的方案，根本緣由在於，做爲手機，沒有辦法準確知道 App 當前在幹什麼，是否須要資源。畢竟如今 App 的功能太豐富了，靠手機自身沒法作到精準的優化。

既然廠商想優化體驗，微信又有優化 App 性能的需求，那真是一拍即合，就誕生了 Hardcoder。Hardcoder 構建了 App 與系統（ROM）之間可靠的通訊框架，讓系統知道 App 的需求。

以前廠商也不知道何時該給資源，何時該省資源，真是又怕他不來又怕他亂來。

如今好了，有了 Hardcoder，既然系統不知道，就由 App 主動告訴它，等於微信主動告訴手機系統，我如今在什麼場景下，或者我接下來要幹什麼了，這個場景須要一些系統資源來加持，才能保證速度嗖嗖的，不會卡頓。

到這裏你們應該就理解了，Hardcoder 更像是一個通訊框架，能夠經過它告知操做系統，我接下來要作複雜操做了，請給我資源。

Hardcoder 自己與廠商，已經預設了一些場景值，能夠直接使用。

int APP_SCENE_UNDEFINE = 0;                 //未定義場景
int APP_SCENE_STARTUP = 1;                  //進程啓動，APP啓動
int APP_SCENE_WINDOW_SWITCH = 2;            //UI頁面切換（同一進程），activity，fragment切換
int APP_SCENE_WINDOW_SCROLL = 3;            //UI頁面滑動
int APP_SCENE_DATA_LOADING_AND_PROCESS = 4; //數據加載和處理任務，指APP本地先後臺任務
int APP_SCENE_MULTI_MEDIA_PROCESS = 5;      //多媒體相關業務
int APP_SCENE_COMMUNICATE = 6;              //APP/服務端通訊
int APP_SCENE_SYSTEM_DEVICE = 7;            //調用系統服務
複製代碼

固然你也能夠自行定義。

Hardcoder 的原理

知道了 Hardcoder 都幹了什麼，再簡單瞭解一下它的設計。

Hardcoder 在 App 和系統之間，構建了一個可靠的通訊框架，跳出以前 App 只能調用系統標準 API，而沒法直接調用系統底層硬件資源的問題，讓 Android App 與 系統之間，能夠實現實時的通訊。

利用 Hardcoder，App 能夠在必要的時候，向系統申請更多的硬件資源，例如 CPU 頻率、大小核、GPU 頻率等資源來提高 App 的性能。

Hardcoder 框架，分爲 Client 端和 Server 端，本次開源的就是 Client 端，Server 端則交由廠商系統側自行實現。

Hardcoder Client 端和 Server 端之間，採用的是 LocalSocket 的通訊方式，等於 App 若是須要資源，經過 Hardcoder 的 Client 端向系統實現的 Server 發請求，系統側接到請求以後，按需調整不一樣的系統資源，例如給更大的 CPU 頻率，把系統綁定到大核運行等等。

說到 LocalSocket，我想 Android 開發應該比較熟悉。由於在 Java 層，Android 自己提供了一套 LocalSocket 的 API，可是呢 Hardcoder 沒用它。由於 Hardcoder 主要是採用 Native 實現的，因此微信在 C 層，使用 Linux 的 Socket 接口，又本身實現了一套 LocalSocket。

這大概就是大佬的世界，用不了就本身寫。

那利用 Hardcoder 到底對性能有多少提高呢？

從官方里給出的數據來看，平均優化效果達 10%~30%，而又由於微信自己對資源的申請也比較精細和準確，因此功耗上僅增長了 2% 的耗電，至關於用 2% 的功耗，換來了 20% 性能的提高。這份數據在廠商來看，應該是能夠接受的。

Hardcoder 框架的覆蓋的設備量也很是的大，目前已接入 OPPO、vivo、華爲、小米、三星、魅族等主流手機廠商，覆蓋 4.6 億+ 設備量。

到這裏你們應該都明白了。說白了 Hardcoder 就是一個 App 與系統的通訊框架，以前說的性能優化框架，但實際上真正的起做用的邏輯，都在 Server 端。你想申請資源，你就用 Hardcoder 申請你的，系統給不給你，徹底由系統側自身決定。

普通開發者看 Hardcoder

體量決定了複雜度，再簡單的技術，用在 10w 用戶和用在 10 億用戶上，就是天差地別。

有些事情，微信能作到的，你就算拿到了微信的源碼，你也作不到。主要仍是由於微信這樣的用戶體量，讓廠商一路給開綠燈。

從文檔中瞭解到，Hardcoder 目前國內的主流廠商都已經支持了，而且有些已經開放出權限申請方式。

VIVO 這種商務渠道的申請，應該是比較困難的，可是自助註冊的 OPPO 以及華爲這種無需註冊的，就能夠用到 Hardcoder 了。

但 Hardcoder 本質上仍是一個與系統通訊的框架，至於系統是否響應你申請資源的請求，徹底拒絕於系統側自身的邏輯，你這個申請資源的消息發過去了，對方受不受理，就不是咱們能決定的。

文檔裏也提到，Hardcoder Server 端也會對應用請求資源作必定的限制，例如當前 App 在前臺或者在後臺，就會有不一樣的處理邏輯。

站在微信的視角，Hardcoder 是性能優化框架，站在普通開發者的角度，它可能僅僅是一個通訊框架，而且仍是那種單向通訊的框架，是否有做用，徹底取決於廠商，這部分堪稱是玄學。

可能你在 A 手機上很差使，換到 B 手機上就好使了，也可能你在測試機上有效，換到自用機上就無效了。

不過話說回來，提高用戶體驗一直也是廠商的目標，這和大部分 App 開發者的目標上一致的，因此長期來看 Hardcoder 仍是有價值的。但在國內全家桶 App 的環境下，自然的讓廠商不信任 App，將廠商與 App 推到了對立面。

可是若是廠商有一套標準的檢驗流程，能夠檢驗出 App 開發者是否真的作到「誠實」，在須要的時候作到精確控制，只在須要的時候申請，不須要的時候不亂申請。就可讓 App 和廠商愉快的玩耍了。

而 Hardcoder 發佈以前也並不僅有微信在使用，騰訊系的很多產品已經在使用它了，例如 QQ、企業微信、每天快報等。等於微信此次開源了 Hardcoder，若是廠商想開放出來讓廣大開發者使用，其實成本是很是低的。

說到底 Hardcoder 是否有效的主動權仍是在廠商，因此在這件事情期待後續廠商的發聲。

最後我提一句，Hardcoder 在 Github 上開源的文檔，仍是值得 Android 開發者讀一讀的，能夠學到很多東西。

你對 Hardcoder 有什麼見解，歡迎留言討論。

---

references:

https://github.com/Tencent/Hardcoder

本文對你有幫助嗎？留言、轉發、收藏是最大的支持，謝謝！

---

公衆號後臺回覆成長『成長』，將會獲得我準備的學習資料。