微信开源了 Hardcoder，旨在解决手机「卡成狗」，但开发者先别高兴。

今年一月微信公开课 Pro 2019 上，提到的微信性能优化框架「 Hardcoder 」，近日终于开源了。

微信开源的东西，作为 Android 开发，当然是双击 666 了。

但是作为一名 Android 开发者，我更关心的是 Hardcoder 到底是什么？对我们 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

本文对你有帮助吗？ 留言、转发、点好看 是最大的支持，谢谢！

「 联机圆桌 」:point_left:推荐我的知识星球，一年 50 个优质问题，上桌联机学习。

公众号后台回复成长『 成长 』，将会得到我准备的学习资料。