Hardcoder简介

Hardcoder是腾讯开源的一套Android APP 与系统间的通信解决方案，Hardcoder有效的解决了 APP 只能调用系统标准 API，无法直接调用系统底层硬件资源的问题，让 Android APP 和系统能够实现实时通信。

按照官方的说法，APP 能充分调度系统资源如 CPU 频率，大小核，GPU 频率等来提升 APP 性能，系统能够从 APP 侧获取更多信息以便更合理提供各项系统资源。同时，对于 Android 缺乏标准接口实现的功能，APP 和系统也可以通过该框架实现机型适配和功能拓展。

之所以要研发这一框架，是因为微信在很多的低端机型上，一些常用的优化手段都使用到了极致，所以微信的开发者一直在思考，该如何突破这个优化的极限？直到有一次与厂商的交流时候了解到，部分厂商会针对微信做一些小改动，其中比较典型的就是【暴力提频】。系统在识别到微信启动，页面切换等场景时，会粗暴地提高 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 的通信方式，关于LocalSocket，读者可以看这一篇文章的介绍：Android LocalSocket简介。由于 Hardcoder 采用 Native 实现，因而在 C 层使用 Linux 的 socket 接口实现了一套 LocalSocket 机制作为 Client 端与 Server 端之间的通信方式。

可以发现，Hardcoder有如下一些优点或者说特性。

• 系统服务为 optional，实现上可以完全支持或者部分支持；
• 框架实现不依赖于特定 Android 系统，如 API level 限制；
• APP 的功能和业务特性不依赖于该框架。

总而言之，由于Hardcoder是腾讯主导的，所以我们不用太担心兼容性问题，腾讯会和手机厂商进行洽谈并提供解决方案，并且目前已经支持Hardcoder框架的手机厂商有OPPO、vivo、华为、小米、三星、魅族等。

Hardcoder 性能优化技术方案

Hardcoder 优化基础

Hardcoder 在Android系统侧主要优化的方法有提高 CPU 频率、提高 IO 频率， CPU 锁核以及提高 GPU 频率。

提高 CPU 频率

一般来说，移动设备为了降低功耗，会不同程度地抑制 cpu 频率，同时内核会根据当前的负载动态调整 cpu 频率。这就导致 APP 在执行一些需要资源的操作的时候，不能最大限度利用到 cpu 资源，可能出现卡顿等情况。

在Android系统中，通过修改Android内核配置，就可以达到提高 cpu 频率的目标。我们可以使用下面的命令来查看当前系统的 cpu 核数。

ls -l  /sys/devices/system/cpu

如果要查看 cpu 支持的频率，可以使用下面的命令。

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies

上面的命令是查看某个核（cpu0）支持的频率。主流的 cpu 都会有大小核的区分，所以并不能保证每个核的支持频率是一样的。一般来说，大核支持更高的频率。要修改某个核的频率，需要有 root 权限。以下操作就是直接 echo 指定频率到 cpu0 上，以达到提频的效果。

echo 1440000  > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq

一般来说，为了方便测试，我们会禁用某些核，甚至只给系统留下一个核，以方便做些基准测试，下面的命令可禁用某个指定的内核。

echo 0 > /sys/devices/system/cpu/cpu0/online 

同理，我们可以把 0 改成 1，即可启用对应的内核。

提高 IO 频率

就 Hardcoder 项目与部分厂商的沟通过程中，发现厂商并不把 IO 提频看作重点，认为 IO 提频本身效果有限，且必须同时提高 cpu 频率效果才会明显，而部分厂商比如 vivo 则把 IO 频率长期锁定为高频状态。

cat /sys/class/mmc_host/mmc0/clk_scaling/enable

如果值为1 , 则 emmc 运行在 50MHz 和 200MHz 之间变化； 如果值为0 , 则 emmc 运行在 200MHz 上，也就是高频上了，如使用下面的提频命令即可。

echo 0 > /sys/class/mmc_host/mmc0/clk_scaling/enable

CPU 锁核

锁核操作实际上操作的是 cpu 亲和度，设置某个线程的 cpu 亲和度，即可变相把线程锁定在某个大核上运行。实际操作中，线程可固定在某个核上运行，但不独占，也就是这个核同样可以执行其他线程的指令。这样就减少了内核切换带来的性能开销。

提高 GPU 频率

GPU主要用于渲染图像，部分厂商提供了调节 GPU 芯片参数的能力，提高 GPU 频率，从而更好地支持对 GPU 需求较高的场景。

Hardcoder 通讯方式 —— LocalSocket

Hardcoder 采用 LocalSocket 实现手机本地双方 Native 层实时通信机制，关于LocalSocket可以自行查阅相关的资料。Android中的LocalSocket其实是Linux中Socket进行了封装，采用JNI方式调用，进而实现进程间通信。与普通的Socket不同，LocalSocket实现的是Android和Framework直接的通信。

LocalSocket 通信框架

目前在 Android 上进程通信的 IPC 机制主要有 Binder（Java INTENT/AIDL）、共享内存、Socket（TCP/UDP）等，同时在 Java 层 Android 提供了一套 LocalSocket 的API。LocalSocket 的本质是基于对 Linux 层 Socket 的封装，用来进行进程间的通信。LocalSocket 根据是否命名分为两种类型：非命名 LocalSocket 只能在父进程和子进程之间通信（因为其他进程无法获得 Server 端 Socket 名，只有保存了未命名 Socket 的文件描述符的父子进程之间可以使用）；命名的 LocalSocket 则可以在任意进程间进行通信。

Android 中的 LocalSocket 在 Unix 域名空间创建一个 Socket 进行通信。Unix 域名空间 Socket 是在 Socket 基础上衍生的 IPC 通信机制，因此 LocalSocket 是为了解决同一台主机上不同进程间的通信问题，其对应接口和 TCP 等跨网络 Socket 方式一致，但是无需实现复杂的 TCP/IP 协议栈，不需要打包拆包、计算校验，只需通信双方协商好套接字地址（Android 上即为文件描述符）即可。因而 LocketSocket 在 Android 系统中作为 IPC 通信手段被广泛使用，如常见的Binder、Ashmem和LocalSocket等。

由于 Hardcoder 采用 Native 实现，自然无法直接使用 Android SDK 提供的 Java 类的 LocalSocket 和 LocalSocketServer API。当然在 Hardcoder 的设计预期中，使用者无需关心通信细节，所以项目在 C 层使用 Linux 的 Socket 接口实现了一套类 Java 类的 LocalSocket 机制。

Hardcoder 子项目 libapp2sys 中 localsocket.h 定义了C++类 Localsocket 用于实现对通信流程的接口封装和逻辑控制，工作流程如下所示。

基类 Localsocket

基类 Localsocket 定义了作为 Socket 双方通信的基本行为接口，主要包括创建接口、循环处理收发数据和回调函数。

CreateSocket() 创建接口

int createSocket(const char *localPath, const char *remotePath)    

其中，CreateSocket() 创建套接字，传入参数为 Server 端的 Socket 名。

对 Server 端，传入的 Socket 名为空，则默认创建 Server 端。先新建套接字 new Socket()，然后 bind() 绑定地址，再调用 listen() 监听端口，一系列系统调用成功后，则进入 loop() 循环等待处理数据。

对 Client 端，传入的 Socket 名有效，则创建 Client 端。先新建套接字 new Socket()，然后 connect() 尝试通过 Socket 名连接 Server 端。连接成功后，Client 端创建子线程进入 loop() 循环等待处理数据。

Loop() 循环处理收发数据

int loop(const int isServer) 

Client 端和 Server 端分别维护一个发送队列 sendQueue，当发送队列不为空则发送数据，否则调用 select() 判断是否有待处理的接收数据，如果有则调用 read() 读取数据然后处理接收数据。对 Server 端该函数还会调用 accept() 处理 Client 端的连接请求。

RecvEvent()回调函数

int recvEvent(Event event, int fd, uid_t uid, const char *path, uint8_t *data, int len)

RecvEvent() 为虚函数，数据接收处理完后回调上层进行对应的业务处理，具体实现由各自派生类自行完成。

客户端 LocalsocketClient

客户端 LocalsocketClient 继承自 LocalSocket，是 Client 端实现的 LocalSocket 类，实现在 client.h 文件。除了包括基类的基础函数外，主要包括 start() 方法创建连接。LocalSocketClient 对应实例 Client 由客户端代理类负责创建，主要方法包括初始化和启动。

初始化 init()

int init(const char *remote, const int port, const char *local, IC2JavaCallback *callback)

上层 JNI 入口调用初始化创建 Client 端，当前版本 Localsocket 实现会忽略 port 和 local 两个参数（UDP 历史实现遗留）， remote 为约定的 Server 端 Socket 名，callback 为 APP 端 Java 层监听 server 端回调函数。

启动函数 tryStartEngine()

int tryStartEngine()

启动函数 tryStartEngine() 创建本地的 LocalSocketClient 引擎实例 clientEngine，并调用 LocalSocketClient 类 start() 方法创建连接并负责断开超时重连逻辑。

服务端 LocalsocketServer

服务端 LocalsocketServer 继承自 LocalSocket，是 Server 端实现的 LocalSocket 类，实现在 server.h 文件，对应实例由服务端代理类负责创建。其创建和 start() 方法由实现了相应服务能力接口的系统级别进程负责调用。

Native 层实现的 LocalSocket 流程

对 Server 端，创建 Socket 后，调用 bind() 绑定地址和 listen() 监听端口，进入 loop() 循环。首先通过 accept() 处理来自 Client 端的连接请求，通过 recvEvent() 的回调通知 Client 端是否连接成功；然后检查发送队列 sendQueue 是否有待发送数据，若有则调用 send() 发送数据；再调用 select() 查找是否有待处理的接收数据，有则调用 read() 读取数据进行相应处理；然后重新进行 loop() 循环。

对 Client 端，创建 Socket 后，调用 connect() 通过 Socket 名尝试连接 Server 端，从 recvEvent() 回调获取是否连接成功。若连接成功，则进入 loop() 循环，与 Server 端类似循环 send()、select()、read() 过程。

Hardcoder 数据格式 —— proto + JSON

Hardcoder 使用 LocalSocket 机制完成 C/S 双向实时通信，client 端到 server 端传输数据简称为请求（request），server 端到 client 端数据简称为响应（response）。双向数据包均由包头和包体两部分组成，考虑到为本地通信且已通过 UID 方式实现鉴权认证，当前版本所有数据均无加密。

请求数据格式

请求的数据格式如下所示。

--------------------------------------------------------
| AMCReqHeaderV2 | body(业务请求结构体序列化数据)         |
--------------------------------------------------------

AMCReqHeaderV2 定义在 libapp2sys 子项目的 header.h 中。

const static uint16_t HEADER_PROTOCAL_VERSION_2 = 16;
const static uint32_t HEADER_BEGIN = 0x48444352;

typedef struct AMCReqHeaderV2 {
    uint32_t begin;     // 包头其起始字段
    uint16_t version;   // 协议版本
    uint16_t funcid;    // 请求对应的function ID
    uint32_t bodylen;   // 包体序列化数据长度
    int64_t    requestid;  // 当前请求包ID
    uint32_t callertid; // 上层JNI调用者所在线程ID
    int64_t timestamp;  // 当前请求时间戳
    uint32_t headerlen; // 包头数据长度（Ver2新增）
    uint32_t bodyformat; //包体数据序列化格式枚举值（Ver2新增）

}__attribute__ ((packed)) AMCReqHeaderV2;

其中：

• begin 字段固定标识 Hardcoder 通信。
• version 字段支持协议版本扩展。
• funcid 定义在 protocol.h，表明本次客户端请求对应的系统操作，例如申请 CPU 提频或者线程锁核等。

const static uint32_t FUNC_BASE = 1000;

const static uint32_t FUNC_CHECK_PERMISSION = FUNC_BASE + 1;

const static uint32_t FUNC_CPU_HIGH_FREQ = FUNC_BASE + 2;
const static uint32_t FUNC_CANCEL_CPU_HIGH_FREQ = FUNC_BASE  + 3;

const static uint32_t FUNC_CPU_CORE_FOR_THREAD = FUNC_BASE + 4;
const static uint32_t FUNC_CANCEL_CPU_CORE_FOR_THREAD = FUNC_BASE + 5;

const static uint32_t FUNC_HIGH_IO_FREQ = FUNC_BASE + 6;
const static uint32_t FUNC_CANCEL_HIGH_IO_FREQ = FUNC_BASE + 7;

const static uint32_t FUNC_SET_SCREEN_RESOLUTION = FUNC_BASE + 8;
const static uint32_t FUNC_RESET_SCREEN_RESOLUTION = FUNC_BASE + 9;

const static uint32_t FUNC_REG_ANR_CALLBACK = FUNC_BASE + 10;

const static uint32_t FUNC_REG_PRELOAD_BOOT_RESOURCE = FUNC_BASE + 11;

const static uint32_t FUNC_TERMINATE_APP = FUNC_BASE + 12;

const static uint32_t FUNC_UNIFY_CPU_IO_THREAD_CORE = FUNC_BASE + 13;
const static uint32_t FUNC_CANCEL_UNIFY_CPU_IO_THREAD_CORE = FUNC_BASE + 14;

static const uint32_t FUNC_REG_SYSTEM_EVENT_CALLBACK = FUNC_BASE + 15;

static const uint32_t FUNC_GPU_HIGH_FREQ = FUNC_BASE + 16;
static const uint32_t FUNC_CANCEL_GPU_HIGH_FREQ = FUNC_BASE + 17;

static const uint32_t FUNC_CONFIGURE = FUNC_BASE + 18;
static const uint32_t FUNC_GET_PARAMETERS = FUNC_BASE + 19;

其中，requestid 字段从 0 开始递增保持唯一性。headerlen 字段为包头长度。bodyformat 为包体序列化格式，当前取值为：1-raw（byte数组）、2-protobuf 序列化字节流 、3-JSON 序列化字节流。

请求 body 部分如果使用 google protobuf 协议格式实现（C 库），请参见项目amc.proto 文件中请求结构体定义，例如申请 CPU 提频的业务请求结构体：

message RequestCPUHighFreq{
    required int32 scene = 1;
    required int32 level = 2;
    required int32 timeoutMs = 3;
    required int64 action = 4;
}

编译后会自动在 gen/cpp/amc.pb.h 文件中生成对应的 C++ 类，主要公开成员函数为序列化/反序列化接口，以及数据属性的 get/set 访问接口。

class RequestCPUHighFreq : public ::google::protobuf::MessageLite {

    RequestCPUHighFreq* New() const;
    void CheckTypeAndMergeFrom(const ::google::protobuf::MessageLite& from);
    void CopyFrom(const RequestCPUHighFreq& from);
    void MergeFrom(const RequestCPUHighFreq& from);

    // required int32 scene = 1;
    inline bool has_scene() const;
    inline void clear_scene();
    static const int kSceneFieldNumber = 1;
    inline ::google::protobuf::int32 scene() const;
    inline void set_scene(::google::protobuf::int32 value);
    
    //...

｝

调用 header.h 的静态函数 genReqPack 即可以完成请求数据包的完整封包逻辑。

static int64_t genReqPack(uint32_t funcid, uint8_t *data, int dataLen, uint8_t **outPack, uint32_t *outLen, uint32_t callertid, int64_t timestamp)

如果采用 JSON 格式，则使用 key-value 方式，其中 key 统一为字符串，当前版本已有属性定义如下：

• "funcid" 和包头中的 funcid 保持一致，int32 格式。
• "scene" 场景值，int32 格式，表示 APP 具体业务场景，和 Ver1 已有定义保持一致。
• "status" 状态值，int32 格式，表示该操作是一个请求/置位（1）还是取消/复位（2）操作。
• "timouts" 超时值，int32 格式，表示该操作任务最长时间，单位 ms。
• "cpulevel" 请求 cpu level 值，分为 Level 0~3，具体定义请参见 protocol.h。
• "iolevel" 请求 io level 值，分为 Level 0~3，具体定义请参见 protocol.h。
• "gpulevel" 请求 gpu level 值，分为 Level 0和 Level 1，具体定义请参见 protocol.h。
• "bindtids" 需要绑核的线程，int32格式数组。
• "unbindtids" 需要解绑的线程，int32格式数组。

响应数据格式

响应数据的格式如下：

-------------------------------------------------
| AMCRespHeaderV2 |     payload               |

AMCRespHeaderV2 同样定义在 libapp2sys 子项目的 header.h 中。

typedef struct AMCRespHeaderV2 {
    uint32_t begin;            // 包头其起始字段
    uint16_t version;        // 协议版本
    uint16_t funcid;        // 响应请求对应的function ID 
        uint32_t retCode;        // 请求处理结果
    uint32_t bodylen;        // 包体序列化数据长度
    int64_t requestid;    // 响应对应的请求包ID
    int64_t timestamp;    // 当前响应时间戳
    uint32_t headerlen; // 包头数据长度（Ver2新增）
        uint32_t bodyformat;//包体数据序列化格式枚举值（Ver2新增）
}__attribute__ ((packed)) AMCRespHeaderV2;

begin、version、bodylen、timestamp、headerlen 和 bodyformat 等字段含义与 AMCReqHeader2 中各字段一样用于标识响应包自身属性，而 funcid、requestid 则表示其对应处理的请求包属性，便于请求端确认；如果请求包在解包或者校验方面不通过，则对应的 retCode 会返回响应的全局错误码（负值，定义在 protocal.h），否则返回 0 值或者是具体业务处理结果。

const static int32_t RET_OK = 0;

//requestCpuHighFreq，requestHighIOFreq 直接返回level n
const static int32_t RET_LEVEL_1 = 1;
const static int32_t RET_LEVEL_2 = 2;
const static int32_t RET_LEVEL_3 = 3;

//预留返回值最后三位作为level，倒数第四位代表cpu level，倒数第五位代表io level，新增值继续左移
const static int32_t RET_CPU_HIGH_FREQ = 1 << 3;// 1000，即8
const static int32_t RET_HIGH_IO_FREQ = 1 << 4; // 10000，即16


//requestUnifyCpuIOThreadCore使用复合标识位
const static int32_t RET_CPU_HIGH_FREQ_LEVEL_1 = RET_CPU_HIGH_FREQ | RET_LEVEL_1;   //Unify接口返回cpu level 1，1000 | 01 = 1001
const static int32_t RET_CPU_HIGH_FREQ_LEVEL_2 = RET_CPU_HIGH_FREQ | RET_LEVEL_2;   //Unify接口返回cpu level 2，1000 | 10 = 1010
const static int32_t RET_CPU_HIGH_FREQ_LEVEL_3 = RET_CPU_HIGH_FREQ | RET_LEVEL_3;   //Unify接口返回cpu level 3，1000 | 11 = 1011

const static int32_t RET_HIGH_IO_FREQ_LEVEL_1 = RET_HIGH_IO_FREQ | RET_LEVEL_1;     //Unify接口返回io level 1，10000 | 01 = 10001
const static int32_t RET_HIGH_IO_FREQ_LEVEL_2 = RET_HIGH_IO_FREQ | RET_LEVEL_2;     //Unify接口返回io level 2，10000 | 10 = 10010
const static int32_t RET_HIGH_IO_FREQ_LEVEL_3 = RET_HIGH_IO_FREQ | RET_LEVEL_3;     //Unify接口返回io level 3，10000 | 11 = 10011


const static int32_t ERR_UNAUTHORIZED = -10001;
const static int32_t ERR_FUNCTION_NOT_SUPPORT = -10002;
const static int32_t ERR_SERVICE_UNAVAILABLE = -10003;
const static int32_t ERR_FAILED_DEPENDENCY = -10004;
const static int32_t ERR_PACKAGE_DECODE_FAILED = -10005;
const static int32_t ERR_PARAMETERS_WRONG = -10006;
const static int32_t ERR_CLIENT_UPGRADE_REQUIRED = -10007;

const static int32_t ERR_CLIENT_DISCONNECT = -20001;
const static int32_t ERR_CLIENT_RESPONSE = -20002;

请求 body 部分如果使用 protobuf 定义，请参见项目amc.proto 文件中响应结构体定义；如果采用 JSON 格式，属性定义与 AMCReqHeaderV2 保持一致。调用 header.h 的静态函数 genRespPack 即可以完成响应数据包的完整封包逻辑。

static int64_t genRespPack(uint32_t funcid, uint32_t retCode, uint64_t requestid, uint8_t *data, int dataLen, uint8_t **outPack, uint32_t *outLen) 

Native 层实现的 LocalSocket 鉴权方式

由于 Native 层实现的 LocalSocket 通信方案为本地进程间通信，因而只需要在 Server 端接收到 Client 端请求时，通过调用 getsockopt() 方法获取到 Client 端的 UID，然后通过 UID 反查出 Client 端对应的 APP 信息，进而完成响应的鉴权处理。

Hardcoder 厂商接入指南

Hardcoder 项目工程中提供了 Server 端的实现例子，代码主要参见 server.h ，server.cpp 以及 protocol.h。

设置系统属性

APP 判断手机是否支持 Hardcoder 会读取 persist.sys.hardcoder.name 的 property，若不为空则手机取 property 字段作为 server 端 socket name 请求建立 socket 连接。厂商侧需设置 persist.sys.hardcoder.name 属性为系统 server 侧 socket name。

实现主要接口函数

protocol.h 的 HardCoder 类定义了所有 Hardcoder 接口为虚函数，厂商侧需继承 HardCoder 类实现相关接口。代码例子中 server.h 的 ManufacturerCoder 继承了 HardCoder 实现了相关接口，例子中为空函数，具体实现需要厂商侧编写。此部分接口可同时参照 Hardcoder 接入指南中接口说明。

int getUidByAddress(const char *ip, int port);

获取 APP UID，每次在 socket 连接中收到 APP 请求都会检查 APP UID。由于 UID 有唯一性，可作为鉴权用。

bool checkPermission(std::vector<std::string> manufactures, std::vector<std::string> certs, int funcid, int uid, int callertid, int64_t timestamp);

checkPermission方法的作用是否允许 APP 使用 Hardcoder，允许返回 true，否则返回 false。若允许所有 APP 使用，直接返回 true 即可。

若需要限制 APP 接入，应实现对应的 checkPermission，其中 manufactures 为厂商名数组，certs 为鉴权值数组，可提供鉴权值给允许使用的 APP 作为参数传入。注意若限制应用使用，需告知 APP 开发者如何申请权限接入。

int requestCpuHighFreq(int scene, int64_t action, int level, int timeoutms, int callertid, int64_t timestamp);

requestCpuHighFreq的主要作用是提高CPU频率。其中，scene参数为APP 场景值；action参数为APP 场景值扩展，为保留字段；level，请求的 CPU level，定义在 protocol.h；目前共分为三个 level，LEVEL 0 为不变，LEVEL 1 最高，默认为 CPU 最高频率，LEVEL 2 次之，LEVEL 3 最低，但仍比当前频率会提高，LEVEL 2 和 LEVEL 3 具体频率可由厂商自行决定。timeoutms，从 timestamp 开始请求 timeoutms 时间的资源；callertid，请求线程 id；timestamp，请求时间戳；如果要取消提频请求，可以使用下面的函数。

int cancelCpuHighFreq(int callertid, int64_t timestamp);

如果要请求绑定指定线程到cpu大核，可以使用下面的函数。

int requestCpuCoreForThread(int scene, int64_t action, std::vector<int>bindtids, int timeoutms, int callertid, int64_t timestamp);

其中，bindtids，需要绑定到大核的线程 id 数组。参考实现，部分厂商会直接把请求线程所在进程的所有线程同时绑定到大核。

int cancelCpuCoreForThread(std::vector<int>bindtids, int callertid, int64_t timestamp);

上面的方法用于取消绑定线程请求。

int requestHighIOFreq(int scene, int64_t action, int level, int timeoutms, int callertid, int64_t timestamp);

requestHighIOFreq方法用于提高 IO 频率请求。当然，我们还可以使用混合请求，同时请求提高 CPU 频率，提高 IO 频率，提高 GPU 频率以及线程绑核。

int requestUnifyCpuIOThreadCoreGpu(int scene, int64_t action, int cpulevel, int iolevel, std::vector<int>bindtids, int gpulevel, int timeoutms, int callertid, int64_t timestamp);

取消的时候使用cancelUnifyCpuIOThreadCoreGpu方法。

int cancelUnifyCpuIOThreadCoreGpu(int cancelcpu, int cancelio, int cancelthread, std::vector<int>bindtids, int cancelgpu, int callertid, int64_t timestamp);

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 的情况做对比实验，测试性能数据。

编译 Hardcoder aar

Hardcoder项目给开发环境为 AndroidStudio，采用 gradle 构建，其中 Native 部分代码使用 CMAKE 编译。编译aar的步骤如下：

1. 根目录下运行命令行 gradlew assembleDebug 触发子工程 libapp2sys 编译，编译成功后生成 Hardcoder aar， 输出目录为hardcoder/libapp2sys/build/outputs/aar/libapp2sys-debug.aar；
2. 若需要把 aar publish 到本地 maven 库，以便自身项目使用，在根目录下运行如下命令行./gradlew publishToMavenLocal，输出 aar 目录为 User
   目录/.m2/repository/com/tencent/mm/hardcoder/app2sys/。

当然，也可以使用Android Studio自带的Gradle工具进行构建，构建完成后可以在outputs/aar目录下看到生成的aar。

App 引入 Hardcoder aar

Hardcoder 工程以 aar 方式引入，把 hardcoder:app2sys 添加到主工程目录下的 build.gradle 文件的依赖库中。

dependencies {
    api('com.tencent.mm.hardcoder:app2sys:1.0.0')
}

其中 1.0.0 为当前 Hardcoder 版本号，当前版本号在 Hardcoder 主工程目录下 gradle.properties 文件。

HC_VERSION_NAME=1.0.0

Hardcoder 方法

HardCoderJNI.java 中提供了 App 需要调用的接口。带 native 关键字的函数为 jni 接口，为 Hardcoder Client 端与 Server 端约定的所有通信接口。一般不建议直接使用 JNI 接口，HardCoderJNI.java 提供了封装的 JAVA 层接口，其中比较常见的方法有如下一些。

初始化 initHardCoder
InitHardCoder 负责建立 socket 连接。调用 initHardCoder 前，请确保已正确设置了 hcEnable （上层接口是否开启 Hardcoder 功能开关，默认为 true）和 hcDebug （Hardcoder 组件是否打印 debug log，默认为 false）标志位。所有与系统间通信都需要依赖 socket 连接，所以调用请求前确保已调用 initHardCoder 接口 初始化了InitHardCoder，如下所示。

public static int initHardCoder(String remote, int port, String local, HCPerfManagerThread hcPerfManagerThread, HardCoderCallback.ConnectStatusCallback callback)

InitHardCoder中参数的含义如下。

• remote 为 Hardcoder server 端 socket name，默认调用 HardCoderJNI.readServerAddr() 读取；
• port 为 Hardcoder server 端端口值，可传入任意 int 值；
• local 为 Hardcoder client 端 socket name，主要用于标识 client 端，可传入任意非空字符串；
• hcPerfManagerThread 为运行 HCPerfManager 的线程，可传入 null，默认由 Hardcoder 新建一个线程运行；若使用 APP 已有线程池中线程，请传入接口HardCoderJNI.HCPerfManagerThread 的实现类；
• callback 为 initHardCoder 回调，获取连接建立成功/失败回调，不需要回调时可传入 null。建议在回调成功建立 socket 后再发起请求，否则可能存在请求时 socket 未成功连接导致请求失败的情况。
• InitHardCoder 为异步执行，返回值不代表连接是否建立成功，调用 initHardCoder 成功返回 0，若返回ERROR_CODE_NOT_ENABLE = -3，代表 setHcEnable 未设置为 true（默认为 true，上层可用来控制 Hardcoder 是否打开）；

InitHardCoder 连接是否建立成功通过 HardCoderCallback.ConnectStatusCallback 返回值获取到，ConnectStatusCallback接口如下所示。

public interface ConnectStatusCallback {
    void onConnectStatus(boolean isConnect);
}

鉴权 checkPermission
CheckPermission 接口传入厂商名与鉴权值，用于厂商鉴权 APP 是否有权限使用并接入了 Hardcoder 功能。

CheckPermission 必须在 initHardCoder 建立 socket 成功后调用。此接口用于传输鉴权值给厂商，对需要验证鉴权值的厂商（比如 OPPO），必须调用 checkPermission 把鉴权值传入才可使用 Hardcoder；对没有实现 checkPermission 接口的厂商，系统对 checkPermission 请求没有 callback，因而后续请求调用不应依赖于 checkPermission 的回调，若厂商不返回 checkPermission callback也可以调用请求。

public static long checkPermission(String[] manufactures, String[] certs, HardCoderCallback.FuncRetCallback callback)

对于checkPermission鉴权接口，参数的含义如下。

• manufactures 为字符串数组，传入厂商名；
• certs 为字符串数组，传入对应 manufactures 中的厂商的鉴权值；
• callback 为 checkPermission 回调，如下所示

public interface FuncRetCallback {
    void onFuncRet(final int callbackType, final long requestId, final int retCode,
                   final int funcId, final int dataType, final byte[] buffer);
}

其中，retCode 代表鉴权是否成功，retCode 为 0 表示成功，否则失败。

请求资源 startPerformance
StartPerformance 用于向系统申请提高 cpu 频率、io 频率、gpu 频率、线程绑核等操作，分别对应 JNI 接口requestCpuHighFreq、requestGpuHighFreq、requestCpuCoreForThread、requestHighIOFreq 以及混合接口 requestUnifyCpuIOThreadCoreGpu，为方便调用，只需要调用统一接口 startPerformance 即可申请所有资源，对不同资源传入不同参数即可。

StartPerformance 在需要申请资源处调用，返回值为请求的 hashcode，上层可保存返回值，在调用stopPerformance 时传入，指定停止此次请求的资源。

public static int startPerformance(final int delay, final int cpuLevel, final int ioLevel, final int gpuLevel, final int[] tids, final int timeout, final int scene, final long action, final int callerTid, final String tag);

delay 单位 ms，当前请求延迟多久调用，一般为 0。当连续调用 initHardcoder 和 startPerformance 时，若Hardcoder 此时未连接成功，请求会被丢弃，此时可以使用 delay 参数推迟调用。

cpuLevel 本次请求的 cpu 等级，分为：

public static final int CPU_LEVEL_0 = 0;//不变
public static final int CPU_LEVEL_1 = 1;//最高频，一般用于重度场景，会把cpu频率提到厂商设置的最高值，适用于能明确知道结束时间的场景（比如启动，进入某个界面，结束后会主动调用stopPerformance）
public static final int CPU_LEVEL_2 = 2;//次高频，一般适用于不知道明确结束时间的场景，比如列表滑动等，不调用stopPerformance，通过手动设置timeout值设置结束时间
public static final int CPU_LEVEL_3 = 3;//也会比正常运行频率要高

ioLevel 本次请求的 io 等级，分为：

public static final int IO_LEVEL_0 = 0;//不变
public static final int IO_LEVEL_1 = 1;//最高级
public static final int IO_LEVEL_2 = 2;
public static final int IO_LEVEL_3 = 3;

gpuLevel 本次请求的 gpu 等级，分为：

public static final int GPU_LEVEL_0 = 0;//不变
public static final int GPU_LEVEL_1 = 1;//最高级

参数的含义如下：

• tids 需要绑定到大核上的线程，为 int[] 数组，可传入单个或多个线程线程号。部分厂商会直接把线程对应的进程的所有线程同时绑定到大核；
• timeout 单位 ms，本次请求超时值。若请求未主动调用 stopPerformance，超过 timeout 时间后系统会主动释放资源；若请求超过 timeout 时间仍未被执行（请求过多情况下有可能出现），请求会被移出请求队列；
• scene int 值，APP 侧定义的场景值；
• action long 值，APP 侧定义的动作值，扩展字段，APP 侧如果只需要使用到 scene 值可以任意传入 action 值；
• callerTid 本次请求方的线程号；
• tag String 类型，APP 侧定义的 tag，主要用于日志。

结束请求 stopPerformance
场景结束时调用 stopPerformance 方法释放本次请求资源的调用，如下所示。

public static int stopPerformance(int hashCode);

hashCode 对应 startPerformance 的返回值，声明结束本次请求的资源；返回值表示此次调用是否成功，有ERROR_CODE_SUCCESS 和 ERROR_CODE_FAILED。

参考：腾讯Hardcoder