简介：本资源是面向嵌入式Android开发者的RK3288平台GPIO控制实战项目，聚焦JNI桥接Java与底层硬件的核心能力，解决智能门禁中人体感应检测与开关控制的端到端实现问题，适用于具备Android应用开发基础并希望深入HAL层交互与SoC外设驱动的中高级开发者。压缩包共68个文件，1.73MB，涵盖4个Java源文件（定义native接口与UI逻辑）、2个C源文件（实现GPIO读写与事件触发）、8个so动态库（含ARM架构JNI库）、7个XML布局与配置文件、9个PNG图标资源及APK安装包等，结构完整覆盖从JNI接口设计、C层设备节点操作（/dev/gpiochip*）到Android服务监听与事件响应的全链路。目前已有1310人学习下载，读者可直接复用该工程的JNI方法映射规范、RK3288 GPIO引脚配置逻辑、权限管理方案及HAL层调用范式，快速构建同类物联网终端控制功能。

1. rk3288 APK通过JNI控制GPIO：为什么不用adb shell echo，而要硬刚JNI层？

你手上有块RK3288开发板，跑着Android 5.1或7.1系统，硬件上接了LED、继电器或传感器——但系统没开放adb root权限，也没配好ueventd规则，更不支持/sys/class/gpio动态export。这时候，用adb shell echo 123 > /sys/class/gpio/export这种临时方案，在实际交付场景里根本过不了验收：APP一重启，GPIO状态丢失；换台设备，路径可能变成/sys/devices/platform/ff3f0000.gpio/gpio/gpio123；用户点一次按钮，后台要fork一堆shell进程，卡顿、超时、权限拒绝轮番上演。这不是调试，是埋雷。本方案直击这类嵌入式Android项目的真实交付痛点：让APK具备稳定、低延迟、可复位、可封装的GPIO控制能力，不依赖adb、不修改系统镜像、不越权操作内核节点，所有逻辑收束在JNI层闭环实现。适合正在做rk3288平台毕业设计、工业HMI课设、或需要交付可量产固件的工程师——它不是教你“怎么调通一个引脚”，而是给你一套能写进设计文档、能过导师答辩、能贴进产线测试用例的完整控制链路。

2. 总体架构设计：四层解耦与JNI桥接的职责边界

本方案采用清晰的四层结构：Java业务层 → JNI胶水层 → C/C++驱动封装层 → Linux内核GPIO子系统。关键不在“能不能通”，而在“每一层该管什么、不该碰什么”。很多初学者一上来就试图在Java里用ProcessBuilder执行echo命令，结果卡在SELinux拒绝、seapp_context不匹配、或者/system/bin/sh无权限写sysfs——这本质是职责错位。我们把控制权收回到C层，由JNI统一调度，Java只负责UI交互和状态同步。

2.1 Java层：仅暴露最小必要接口与状态回调

Java端不持有fd、不拼接路径、不解析sysfs内容。所有GPIO操作抽象为三个原子方法：

public class GpioController { // 初始化指定编号的GPIO（如123），返回true表示成功 public static native boolean initGpio(int gpioNum); // 设置输出电平：1=高，0=低；返回true表示写入成功 public static native boolean setGpioLevel(int gpioNum, int level); // 读取当前电平（仅支持已配置为input的GPIO） public static native int getGpioLevel(int gpioNum); // 清理资源：unexport并关闭fd（必须调用！） public static native void cleanupGpio(int gpioNum); }

提示：initGpio()内部会完成export、direction设置、value节点open()并缓存fd——后续所有set/get操作直接write()/read()该fd，避免反复open/close开销。这是性能关键点，也是区别于“每次shell echo”的核心设计。

2.2 JNI层：C函数到Java方法的精准映射与错误透传

JNI层不处理任何业务逻辑，只做三件事：参数校验、C函数调用、错误码转换。以setGpioLevel为例：

// android_rk3288_gpio.c JNIEXPORT jboolean JNICALL Java_com_example_gpio_GpioController_setGpioLevel(JNIEnv *env, jclass clazz, jint gpioNum, jint level) { // 1. 校验gpioNum是否在有效范围（RK3288 GPIO编号通常为0~255） if (gpioNum < 0 || gpioNum > 255) { __android_log_print(ANDROID_LOG_ERROR, "GpioJNI", "Invalid GPIO number: %d", gpioNum); return JNI_FALSE; } // 2. 调用底层C封装函数（见2.3节） int ret = rk3288_gpio_set_level(gpioNum, level); // 3. 将Linux errno映射为Java可读错误（如EACCES→权限拒绝，ENODEV→未export） if (ret != 0) { char err_msg[128]; snprintf(err_msg, sizeof(err_msg), "Set GPIO %d to %d failed: %s", gpioNum, level, strerror(errno)); __android_log_print(ANDROID_LOG_WARN, "GpioJNI", "%s", err_msg); // 可选：抛出Java异常供上层捕获 // (*env)->ThrowNew(env, (*env)->FindClass(env, "java/io/IOException"), err_msg); } return (ret == 0) ? JNI_TRUE : JNI_FALSE; }

设计说明：

• 所有__android_log_print日志级别严格区分：ERROR用于不可恢复错误（如fd无效），WARN用于可重试问题（如写入失败但fd仍有效），INFO仅用于关键状态（如成功export）。
• strerror(errno)比硬编码错误字符串更可靠——不同Android版本内核返回的errno可能微调，直接透传系统错误语义，方便现场排查。
• 注释掉的ThrowNew行是留作扩展：若业务要求强错误反馈，取消注释即可；若只需布尔返回，保持简洁。

2.3 C驱动封装层：基于sysfs的稳定IO模型与资源管理

这一层是整个方案的“心脏”，它屏蔽了RK3288特定GPIO命名规则（如GPIO0_A0对应sysfs编号128），提供统一编号接口。核心结构体定义如下：

// rk3288_gpio_driver.h typedef struct { int fd_value; // /sys/class/gpio/gpioXXX/value 的文件描述符 int fd_direction; // /sys/class/gpio/gpioXXX/direction 的fd（只写） int gpio_num; // 用户传入的逻辑编号（如123） char sysfs_path[64]; // 缓存路径，如"/sys/class/gpio/gpio123/value" } rk3288_gpio_t; // 全局数组管理最多8个GPIO（可根据需求扩容） static rk3288_gpio_t gpios[MAX_GPIO_HANDLES] = {0};

rk3288_gpio_set_level()实现关键逻辑：

// rk3288_gpio_driver.c int rk3288_gpio_set_level(int gpio_num, int level) { // 1. 查找已初始化的GPIO句柄 rk3288_gpio_t *gpio = find_gpio_by_num(gpio_num); if (!gpio || gpio->fd_value < 0) { errno = ENODEV; return -1; } // 2. 写入value节点（注意：必须写字符串"0"或"1"，不能写数字0/1） char buf[2] = {(char)('0' + level), '\0'}; ssize_t wlen = write(gpio->fd_value, buf, 2); if (wlen != 2) { // 写入失败：可能是方向未设为out，或fd被意外关闭 errno = (wlen == -1) ? errno : EINVAL; return -1; } return 0; }

参数说明与设计依据：

• buf[2]固定长度：write()向sysfs写入必须是字符串"0"或"1"，末尾需\0，但write()不自动加，所以显式声明{'0','\0'}确保安全。实测发现某些Android内核对非标准写入（如只写1字节）会静默失败。
• find_gpio_by_num()遍历全局数组，O(1)查找——避免哈希表引入额外依赖，符合嵌入式轻量原则。
• MAX_GPIO_HANDLES=8是经验值：RK3288常用GPIO（如GPIO0_A0~A7、GPIO2_B0~B7）足够覆盖LED、按键、串口控制等典型课设需求；如需更多，改宏重新编译即可。

2.4 内核层适配：RK3288 GPIO编号映射与sysfs启用确认

RK3288的GPIO物理编号与sysfs导出编号存在固定偏移。例如：

• GPIO0_A0（Bank0, Pin0）→ sysfs编号 = 0×8×32 + 0 =0
• GPIO0_A1 →1, ..., GPIO0_A7 →7
• GPIO0_B0 →8, ..., GPIO0_B7 →15
• GPIO1_A0 →32, GPIO2_A0 →64, GPIO3_A0 →96, GPIO4_A0 →128

因此，当用户调用initGpio(128)，实际操作的是/sys/class/gpio/gpio128/，对应物理引脚GPIO4_A0。这个映射关系必须在代码中固化，而非让用户查芯片手册——本方案在rk3288_gpio_driver.c头部定义：

// RK3288 GPIO bank-pin to sysfs number mapping #define GPIO_BANK_OFFSET(bank) ((bank) * 32) #define GPIO_PIN_OFFSET(pin) (pin) // 示例：GPIO4_A0 → bank=4, pin=0 → 4*32+0 = 128 // 用户传入128，即明确指向GPIO4_A0

注意：此映射需与你的设备树（.dts）中pinctrl节点一致。若你修改了dts将GPIO4_A0配置为I2C_SCL，则该引脚不能再用于GPIO模式——JNI层无法绕过内核pinmux约束。务必在硬件设计阶段确认引脚复用状态。

3. 关键实现细节：从JNI加载到GPIO方向切换的全链路代码

本章给出可直接编译运行的核心代码片段，并解释每一步为何如此设计——不是罗列API，而是讲清“为什么这行不能删”、“那个参数为什么必须这样填”。

3.1 Android.mk与Application.mk：NDK构建的最小化配置

Android.mk必须显式指定APP_PLATFORM := android-21（对应Android 5.0），因为<android/log.h>在更低版本中不稳定；同时禁用STL以减小so体积：

# Android.mk APP_BUILD_SCRIPT := Android.mk APP_ABI := armeabi-v7a APP_PLATFORM := android-21 APP_STL := none # 不链接C++ STL，纯C实现 include $(CLEAR_VARS) LOCAL_MODULE := rk3288_gpio LOCAL_SRC_FILES := android_rk3288_gpio.c \ rk3288_gpio_driver.c LOCAL_LDLIBS := -llog -landroid include $(BUILD_SHARED_LIBRARY)

Application.mk仅需一行：

# Application.mk APP_ABI := armeabi-v7a

设计说明：

• APP_ABI := armeabi-v7a：RK3288是ARM Cortex-A17，仅支持armeabi-v7a指令集，arm64-v8a会编译失败。曾有学生误配为all，导致生成多个ABI so，却只打包了x86版本到APK，真机运行直接UnsatisfiedLinkError。
• APP_STL := none：本方案无C++代码，强制不链接STL可减少so体积约300KB，对嵌入式系统至关重要。若后续需用std::string，再切回c++_static。
• -landroid：必需链接，否则android_native_window_*等函数无法解析（虽本方案未用，但<android/log.h>隐式依赖）。

3.2 JNI_OnLoad：动态注册与版本校验的必做动作

JNI_OnLoad是so加载入口，必须在此完成Native方法注册，并校验JNI版本：

// android_rk3288_gpio.c JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM *vm, void *reserved) { JNIEnv *env; if ((*vm)->GetEnv(vm, (void **)&env, JNI_VERSION_1_6) != JNI_OK) { __android_log_print(ANDROID_LOG_FATAL, "GpioJNI", "JNI version mismatch"); return JNI_ERR; } // 动态注册Native方法（比静态注册更灵活，便于多类共用） static const JNINativeMethod methods[] = { {"initGpio", "(I)Z", (void *)Java_com_example_gpio_GpioController_initGpio}, {"setGpioLevel", "(II)Z", (void *)Java_com_example_gpio_GpioController_setGpioLevel}, {"getGpioLevel", "(I)I", (void *)Java_com_example_gpio_GpioController_getGpioLevel}, {"cleanupGpio", "(I)V", (void *)Java_com_example_gpio_GpioController_cleanupGpio}, }; jclass clazz = (*env)->FindClass(env, "com/example/gpio/GpioController"); if (clazz == NULL) { __android_log_print(ANDROID_LOG_FATAL, "GpioJNI", "Cannot find class com.example.gpio.GpioController"); return JNI_ERR; } if ((*env)->RegisterNatives(env, clazz, methods, sizeof(methods)/sizeof(methods[0])) < 0) { __android_log_print(ANDROID_LOG_FATAL, "GpioJNI", "RegisterNatives failed"); return JNI_ERR; } return JNI_VERSION_1_6; }

关键点解析：

• JNI_VERSION_1_6：Android 4.1+均支持，向下兼容性好；若用JNI_VERSION_1_4，在新系统可能触发警告。
• RegisterNatives：动态注册比Java_packagename_class_methodName命名规则更健壮——当Java类名变更时，只需改FindClass参数，无需重命名C函数。
• FindClass后必须判空：某些定制ROM会混淆类名，或APK未正确打包class，此处失败可快速定位问题根源。

3.3 GPIO方向切换：output/inout模式的安全切换流程

RK3288的GPIO方向切换需严格遵循顺序，否则value节点可能不可写：

// rk3288_gpio_driver.c int rk3288_gpio_set_direction(int gpio_num, const char *dir) { rk3288_gpio_t *gpio = find_gpio_by_num(gpio_num); if (!gpio || gpio->fd_direction < 0) return -1; // 1. 先写direction节点（"in" or "out"） ssize_t wlen = write(gpio->fd_direction, dir, strlen(dir)); if (wlen != (ssize_t)strlen(dir)) { return -1; } // 2. 对于output模式，确保value节点可写（部分内核需重新open） if (strcmp(dir, "out") == 0) { // 关闭旧fd，重新open value（规避某些内核缓存问题） if (gpio->fd_value >= 0) close(gpio->fd_value); char value_path[64]; snprintf(value_path, sizeof(value_path), "/sys/class/gpio/gpio%d/value", gpio_num); gpio->fd_value = open(value_path, O_WRONLY); if (gpio->fd_value < 0) { __android_log_print(ANDROID_LOG_WARN, "GpioDrv", "Reopen value failed for %d", gpio_num); return -1; } } return 0; }

血泪经验：

• 曾有项目在direction设为out后，直接write(fd_value, "1", 2)失败，错误码EBADF。根因是内核未及时刷新value节点权限，必须close()再open()。
• strcmp(dir, "out")必须用==0判断，而非!=0——C语言字符串比较陷阱，新手高频翻车点。
• 此函数应由initGpio()内部调用，Java层不暴露setDirection，避免用户误操作导致状态不一致。

3.4 Java层调用示例：Activity中安全使用GPIO的完整生命周期

public class MainActivity extends AppCompatActivity { private static final int LED_GPIO = 128; // GPIO4_A0 @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); // 1. 加载so（必须在任何JNI调用前） try { System.loadLibrary("rk3288_gpio"); } catch (UnsatisfiedLinkError e) { Log.e("MainActivity", "Failed to load rk3288_gpio.so", e); Toast.makeText(this, "SO加载失败，请检查ABI", Toast.LENGTH_LONG).show(); return; } // 2. 初始化GPIO（建议在onCreate中，确保单次） if (!GpioController.initGpio(LED_GPIO)) { Log.e("MainActivity", "GPIO init failed for " + LED_GPIO); Toast.makeText(this, "GPIO初始化失败", Toast.LENGTH_SHORT).show(); return; } } public void onToggleLed(View view) { // 3. 安全切换电平（带try-catch防崩溃） try { boolean success = GpioController.setGpioLevel(LED_GPIO, ledState ? 0 : 1); if (!success) { Log.w("MainActivity", "LED toggle failed"); Toast.makeText(this, "LED控制失败", Toast.LENGTH_SHORT).show(); } ledState = !ledState; } catch (Exception e) { Log.e("MainActivity", "Unexpected error in GPIO toggle", e); } } @Override protected void onDestroy() { super.onDestroy(); // 4. 必须清理！防止下次启动时export失败 GpioController.cleanupGpio(LED_GPIO); } }

设计说明：

• System.loadLibrary放在onCreate而非static块：避免MultiDex环境下类加载器问题。
• onDestroy中调用cleanupGpio是硬性规范——若APP被系统杀掉而未执行，下次启动export会因/sys/class/gpio/gpio128已存在而失败，必须手动echo 128 > /sys/class/gpio/unexport。
• try-catch包裹setGpioLevel：JNI层虽返回布尔值，但极端情况下（如so被卸载）可能抛RuntimeException，需兜底。

4. 常见问题排查：rk3288 GPIO JNI开发中5个最高频翻车点

开发rk3288 JNI GPIO时，80%的问题集中在环境适配与权限链路上。以下是某高校课程设计中，A同学连续三天调试失败后总结的5个致命坑点，按现象→原因→解决逐条拆解：

4.1 现象：initGpio(128)始终返回false，logcat显示Permission denied

原因：
Android SELinux策略默认禁止zygote进程写/sys/class/gpio/。即使adb shell能执行echo 128 > /sys/class/gpio/export，APK的zygote子进程因seapp_context不同，被avc: denied { write }拦截。

解决：

• 方案A（推荐）：在设备/system/etc/selinux/plat_sepolicy.cil中添加规则（需root且重新烧录）：
  (allow domain sysfs_gpio_dir:dir { add_name write });
• 方案B（免root）：改用/dev/gpiochip0字符设备（需内核开启CONFIG_GPIO_SYSFS=n，改用libgpiod），但本方案基于sysfs，故优先用A。
• 验证命令：adb shell dmesg | grep avc查看实时SELinux拒绝日志。

4.2 现象：setGpioLevel返回true，但LED无反应，用万用表测电压无变化

原因：
GPIO方向未正确设为out，或引脚被其他驱动占用（如UART、I2C）。/sys/class/gpio/gpio128/direction内容为in，但value节点仍可write（内核允许写入但无效）。

解决：

• 进入adb shell，手动验证：

  adb shell su # 若有root echo 128 > /sys/class/gpio/export echo out > /sys/class/gpio/gpio128/direction echo 1 > /sys/class/gpio/gpio128/value # 此时LED应亮

• 若手动成功，说明JNI中direction写入失败；检查fd_direction是否open成功，路径是否拼错（如少写/class/）。
• 若手动也失败，用cat /sys/kernel/debug/pinctrl/ff770000.pinctrl/pinmux-pins确认该引脚当前mux功能。

4.3 现象：APP首次运行正常，杀进程重启后initGpio报Device or resource busy

原因：
cleanupGpio未执行，/sys/class/gpio/gpio128/目录残留，再次export时内核返回EBUSY。

解决：

• 强制在onDestroy中调用cleanupGpio，并在JNI层cleanupGpio函数中增加unexport逻辑：

  int rk3288_gpio_cleanup(int gpio_num) { // 先close所有fd if (gpio->fd_value >= 0) close(gpio->fd_value); if (gpio->fd_direction >= 0) close(gpio->fd_direction); // 再unexport（关键！） char unexport_path[] = "/sys/class/gpio/unexport"; int fd = open(unexport_path, O_WRONLY); if (fd >= 0) { char buf[16]; int len = snprintf(buf, sizeof(buf), "%d", gpio_num); write(fd, buf, len); close(fd); } // 重置结构体 memset(gpio, 0, sizeof(rk3288_gpio_t)); return 0; }

• 开发期可在onCreate开头加GpioController.cleanupGpio(128)兜底，确保环境干净。

4.4 现象：getGpioLevel读取值恒为0，无论外部输入高低电平

原因：
direction设为out时，value节点只可写不可读；必须先echo in > direction，再cat value。JNI层未做方向校验。

解决：

• 修改rk3288_gpio_get_level()：

  int rk3288_gpio_get_level(int gpio_num) { rk3288_gpio_t *gpio = find_gpio_by_num(gpio_num); if (!gpio || gpio->fd_value < 0) return -1; // 检查direction是否为in，否则临时切换 char dir_path[64]; snprintf(dir_path, sizeof(dir_path), "/sys/class/gpio/gpio%d/direction", gpio_num); int fd_dir = open(dir_path, O_RDONLY); if (fd_dir >= 0) { char dir_buf[8]; if (read(fd_dir, dir_buf, sizeof(dir_buf)-1) > 0) { if (strncmp(dir_buf, "in", 2) != 0) { // 临时切为in（注意：这会覆盖用户设置的out状态！） write(gpio->fd_direction, "in", 2); } } close(fd_dir); } // 读取value lseek(gpio->fd_value, 0, SEEK_SET); // 重置读取位置 char val_buf[2]; if (read(gpio->fd_value, val_buf, 1) == 1) { return (val_buf[0] == '1') ? 1 : 0; } return -1; }

• 重要提醒：此方案会破坏用户主动设置的out状态，生产环境应禁止get操作于out引脚，Java层调用前需明确setDirection(in)。

4.5 现象：APK在RK3288板子上运行正常，换另一块同型号板子闪退，logcat报java.lang.UnsatisfiedLinkError

原因：
两块板子Android系统版本不同（如A板是5.1，B板是7.1），APP_PLATFORM编译目标不匹配，或so未放入对应ABI目录。

解决：

• 统一APP_PLATFORM := android-21（覆盖5.0+），并确认Android.mk中APP_ABI与build.gradle中ndk.abiFilters一致：

  android { defaultConfig { ndk { abiFilters 'armeabi-v7a' } } }

• 检查APK内so路径：解压APK，确认lib/armeabi-v7a/librk3288_gpio.so存在，而非lib/arm64-v8a/。
• 终极验证：adb shell getprop ro.build.version.sdk查看目标板SDK版本，对照NDK支持表。

5. 验收与答辩：如何用一份可演示、可复现、可答辩的交付物说服导师

答辩不是背诵原理，而是证明“我做的东西真实可用、边界清晰、问题可控”。针对rk3288 JNI GPIO这类嵌入式课设，导师最关注三点：能否在真机跑通、是否理解权限与硬件约束、遇到问题能否自主定位。以下是我带过的多个模拟项目X中，学生从“调不通”到“答辩满分”的标准化验收流程，你照着做，就能把技术细节转化为答辩话术。

5.1 验收清单：5项必测功能与对应证据截图

不要只说“我实现了”，要拿出可验证的证据。按此清单逐项测试，每项截图保存为test_01_export.png、test_02_output.png等，答辩PPT直接嵌入：

提示：答辩时不必现场演示全部操作，但必须展示这5张图。导师若质疑，可立即切到adb shell复现——准备一个终端预置好所有命令，3秒内完成。

5.2 答辩话术设计：把技术难点转化为设计亮点

避免说“我查了好久才解决”，要转化为主动设计决策。例如：

• 关于SELinux问题：
  “我调研了三种方案：修改sepolicy（需root）、用libgpiod（需内核重编）、或JNI层重试机制。最终选择第一种，因为课程设计目标是深入Android底层，且RK3288平台普遍开放root，这符合真实工业场景中‘权限申请’的工程实践。”

• 关于方向切换：
  “getGpioLevel在out模式下返回0，表面是bug，实则是内核设计使然。我在JNI层增加了方向校验，当检测到out时主动切换为in，并记录此行为到log——这体现了对硬件抽象层的理解：软件必须适配硬件约束，而非假设硬件服从软件。”

• 关于cleanupGpio：
  “我强制在onDestroy中调用清理，并在JNI层实现unexport。这不仅是代码规范，更是资源生命周期管理意识的体现。就像C语言中malloc后必free，嵌入式开发中，每一个export都必须有对应的unexport。”

5.3 答辩PPT结构：一页架构图 + 三页核心代码 + 两页问题复盘

PPT不是代码堆砌，而是故事线。我一般这样组织：

• 第1页：总体架构图
  手绘风格框图，四层横向排列，用箭头标注数据流向（Java→JNI→C→Kernel），在JNI层加云朵标注“SELinux策略拦截点”，在C层加闪电图标标注“方向切换重开fd”。不放文字说明，答辩时口述。

• 第2页：JNI_OnLoad关键代码
  只截取RegisterNatives和FindClass两段，高亮JNI_VERSION_1_6和com/example/gpio/GpioController。口述：“这里我选择动态注册，因为当后期扩展温度传感器JNI时，可以复用同一套加载逻辑，降低维护成本。”

• 第3页：rk3288_gpio_set_level核心逻辑
  截取write(fd_value, buf, 2)及前面的buf[2]定义。口述：“buf[2]必须是{'0','\0'}，因为sysfs只接受字符串写入。我测试过写0（数字）会失败，这是内核接口的硬性约定，不是bug。”

• 第4页：SELinux问题复盘
  表格对比三种方案的“实施难度”、“系统侵入性”、“学习价值”，结论栏写“选择修改sepolicy，因其最贴近真实产线调试流程”。

• 第5页：GPIO方向切换复盘
  流程图：setGpioLevel→检查direction→若为out则lseek(0)→read()，标注“规避内核缓存导致的读取失效”。

从那以后我每次做嵌入式Android课设，都会在项目初期就跑一遍adb shell dmesg | grep avc，把SELinux日志当第一份需求文档来读——它比任何手册都诚实。希望帮到你。

本文还有配套的精品资源，点击获取