adb、fastboot、抓包、热修、插件化——Android 开发日常要碰的一堆工具。

一、设备与调试

Android adb

adb 是 Android 调试桥，把开发机与设备连成可执行 shell、安装包和转发端口的通道。守护进程分 host 与 device 两端，无线调试要先配对。权限在高版本上更严格，用户必须授权。

日常用 logcat、bugreport、install 和 reverse。多设备时用序列号指定目标。root 与生产用户构建能力不同，脚本不要假设一定有 su。大文件传输注意超时。

安全上不要把 adb 对公网暴露。CI 设备农场要隔离账号和调试密钥。抓日志先过滤标签和缓冲，全量 logcat 会把问题淹没。

Android fastboot

fastboot 是 Android 设备在 bootloader 阶段的刷机协议，用于写分区、擦除和解锁。它比 recovery 更靠近硬件，误操作可能变砖。常用命令包括 devices、flash、erase、reboot。

解锁 bootloader 会清数据并可能失去保修，量产设备往往还有解锁码。镜像必须匹配机型和防回滚版本，签名校验失败不要强写。USB 线、驱动和端口供电不足会造成半写状态。

脚本化刷机要校验 sha256 并限制操作员权限。工厂线用一次性令牌，开发机与用户机流程分开。出问题先看 bootloader 日志，而不是反复乱刷。

Android Hierarchy Viewer工具

UI 布局的分析，可以有 2 块，一块就是 Hierarchy Viewer 可以看到View 的布局层

次，以及每个 View 刷新加载的时间。

这样可以很快定位到那块 layout & View 耗时最长。

还有就是通过自定义 View 来减少 view 的层次。

二、抓包、分发与网络状态

Android Reqable 工具

Reqable 是面向移动端与桌面端的 HTTP 调试代理，常被用作 Charles / Fiddler 的替代品。它支持抓取 HTTPS、重写请求、导出 HAR，并能在 Android 上做本机抓包，减少对 USB 反向代理的依赖。

调试 App 时，典型流程是：安装 CA、信任用户证书（或给 debug 包配置 network_security_config）、按域名过滤业务接口、对比请求体与响应码。对于证书钉死、双向 TLS 或自实现的加密体，代理会失败，这时应改看日志或业务层解密逻辑，而不是强行窃取。Reqable 的价值在于把接口变迁可视化，帮助定位超时、重试与错误码。

Android HttpCanary小黄鸟

HttpCanary（小黄鸟）是 Android 上的本机抓包工具，遮盖 HTTP/HTTPS、WebSocket 以及常见 TCP 流量。它不需要电脑做中间人，适合在真机上快速看接口返回、失败码和重定向链。

实战中常用它排查：登录接口是否重复调用、图片上传交界是否过大、某个页面为何突然走了预发环境域名。对 Android 7+ 的系统证书限制，debug 包需要声明用户 CA；发布包则应依赖正式抓包代理或服务端日志。工具只用于自己 App 的联调，不要用来解析第三方应用的加密货运。抓完包尽快导出 HAR 并清除本机证书，避免把调试环境带入生产设备。

蒲公英

蒲公英是国内常见的应用内测分发平台，用来托管 Android APK 与 iOS 企业/测试包，生成二维码和短链给测试同学安装。它还提供崩溃收集、版本历史和下载统计，适合还没上架应用商店的迭代。

使用时注意包体权限与证书：iOS 必须匹配设备 UDID 或企业签，Android 要区分 debug / release 签名。不要把生产密钥或未脱敏日志打进内测包。分发链接应设密码或有效期，避免被搜索引擎收录。正式发布仍走应用商店审核，蒲公英只覆盖内测通道。团队大了之后，可用 CI 自动上传并在变更说明里写清构建号。

Android 应用查询、监控网络连接状态

项目类型

需求程度

实现手段

初创/Demo

⭐

偶尔报错重试即可。

常规工具/社交

⭐⭐⭐

监听 onAvailable / onLost，给出 UI 提示。

中大型商业 App

⭐⭐⭐⭐⭐

全套方案：NetworkCallback + 弱网 RTT 统计 + HTTPDNS + 离线缓存。

ProGuard configuration

三、依赖与功能

Android ButterKnife

ButterKnife 用编译期注解生成 View Binding 代码：@BindView、@OnClick，Activity 里 ButterKnife.bind。曾是 findViewById 的主流替代，现已被 ViewBinding 取代且停止维护。

原理是 APT 生成 *_ViewBinding 类。R8 要 keep 生成类。Fragment 必须在 onDestroyView unbind。库模块要用 butterknife-compiler。

迁移建议直接上 ViewBinding，不必经 DataBinding。遗留项目可先并存。ButterKnife 不支持跨模块 id 很烦。新代码不要再引入。

AppFunction

App Functions 是 Android 上把应用能力暴露给系统助理和 Agent 的机制。应用声明可调用的函数、参数 schema 与执行权限，系统在用户授权后按需调用，而不是让大模型直接操作界面。

实现时要把副作用说清楚：只读查询与会改数据的操作应分开授权。参数校验要在应用进程内完成，不能假设调用方合法。返回值应结构化，便于模型二次组织语言。注意后台限制与用户可见性，敏感操作要二次确认。和普通 Intent 相比，它更强调可发现的功能目录。适配时优先覆盖高频、可撤销的任务。

四、热修与插件化

Android 热更新方案

Android 热更新通常指不发整包、只下发补丁来修缺陷或换资源。常见路径有原生 dex 插桩、资源替换，以及基于 JS/Flutter 的动态下发。应用商店政策对原生代码热更越来越严，很多场景已改走商店常规更新。

若仍自建通道，必须做签名校验、灰度与一键回滚，补丁只覆盖已发布版本。不要把热更新当成功能工厂，大改仍应走发版。统计补丁到达率和崩溃率，失败则停发。调试包与生产包的补丁不能混用。合规上优先使用官方推荐的应用内更新 API，减少私有通道风险。

Android 插件化

1. 什么是插件化？

2. 插件化的优点

  • 减少APK包体积。

  • 动态更新插件。

  • 宿主和插件分开编译，提高开发效率。

  • 解决65535问题。

3. 插件化和组件化的区别

4. 主流插件化框架的对比

5. 插件化架构的实现原理

6. Java类的加载过程

7. Android类的加载

8. 常用类加载器

9. 双亲委派机制

10. 四大组件插件化

11. 资源插件化