Android平台GRPC C++源码构建及库使用技术问询

1. 移除libgrpc_unsecure/libgrpc++_unsecure才能避免初始化卡住 #

这是因为gRPC的secure与unsecure库存在符号冲突，Android环境下同时链接两类库时，初始化阶段会因符号解析混乱导致死锁或卡住。解决逻辑很简单：只保留业务实际需要的版本——如果需要TLS加密通信（比如HTTPS、加密gRPC链路），就只保留带secure后缀的库；如果是完全信任的内部网络场景、无需加密，就只保留unsecure版本，绝对不要同时链接两类。

2. libprotobuf与libprotobuf-lite的区别及选择 #

核心差异 #

• libprotobuf（完整版）：支持Protobuf全量特性，包括反射、JSON序列化/反序列化、动态消息（DynamicMessage）、自定义选项等。
• libprotobuf-lite（精简版）：砍掉了反射、动态消息等重量级功能，仅保留核心的静态消息序列化/反序列化能力，体积更小、运行时开销更低。

选择建议 #

• 若业务用到Protobuf反射（比如gRPC服务反射、动态解析消息）、JSON格式转换，或需要动态创建消息结构，必须选libprotobuf。
• 若仅用Protobuf做基础数据序列化/反序列化，无上述高级需求，优先选libprotobuf-lite，更适配Android这类资源受限平台。

3. 动态库(.so)与静态库(.a)的使用问题 #

• 静态库符号缺失原因：静态库需要手动链接所有依赖的子库（比如gRPC依赖的Protobuf、SSL、zlib等），漏链就会出现函数找不到的情况；而动态库会自动处理依赖链，因此不会有这个问题。
• 是否需要同时使用：完全不需要，二选一即可。如果用.so动态库，无需再链接.a静态库。
• 仅构建.so的方法：构建gRPC时通过CMake参数指定只生成动态库，示例构建参数：

  cmake .. -DBUILD_SHARED_LIBS=ON -DBUILD_STATIC_LIBS=OFF
  

  这样构建后只会产出动态库文件。

额外：gRPC各库用途与适用场景 #

gRPC官方对核心库的定位明确，无需逐个查符号，按需选择即可：

• libgrpc/libgrpc++：核心gRPC库，支持TLS加密的标准通信，是绝大多数生产场景的首选。
• libgrpc_unsecure/libgrpc++_unsecure：无加密gRPC库，适用于完全信任的内部网络，无需TLS加密的场景。
• grpc++_reflection：服务反射库，允许客户端在运行时获取服务的Protobuf定义（比如用grpc_cli调试服务）。如果服务不需要支持调试反射，或已通过其他方式分发Protobuf定义，可忽略此库。
• 其他辅助库（如grpc_channelz通道监控库、grpc++_codegen代码生成依赖）：根据业务监控、代码生成的具体需求选择。

内容的提问来源于stack exchange，提问作者yonutix