企业官网建设流程全解析

干嵌入式这几年，凡是做过GUI项目的，基本都绕不开一个尴尬：屏越来越大，效果要求越来越高，可MCU还是那颗Cortex-M。LVGL、AWTK这类框架生态好、控件全，但渲染本质是CPU一笔一笔画，遇到旋转、缩放、高斯模糊、大面积Alpha混合，帧率立刻见底。这时候Arm官方的Arm-2D就经常被提起，说是专门给Cortex-M准备的2D图形加速库，可到底值不值得引入，工程上怎么落地，网上全是含糊其辞的“性能很好”“占用很小”。我这次直接拉了一份Arm-2D源码，按做技术尽调的思路，做了完整的静态工程评测，从模块拆分、资源估算到集成约束，把选型需要的工程证据一次性理清楚。这篇文章适合正在做GUI技术选型、或者准备把Arm-2D接入现有项目的嵌入式工程师，看完你能知道它内部到底长什么样、静态体积大概多少、和你的项目合不合拍。

1. 评测对象、工程构成与环境基线

1.1 源码里到底有什么

Arm-2D从设计上就不是一个传统意义上的“完整GUI框架”，它更像是一个面向Cortex-M的2D渲染中间层。源码包解压之后，核心目录结构非常清晰，建议第一次接触的人先按这个顺序去读，不要一上来就扎进example里。

Arm-2D/ ├── Library/ │ ├── Include/ │ │ ├── arm_2d.h │ │ ├── arm_2d_cfg.h │ │ ├── arm_2d_types.h │ │ └── arm_2d_utils.h │ └── Source/ │ ├── arm_2d_core.c │ ├── arm_2d_alpha_blend.c │ ├── arm_2d_anti_aliasing.c │ ├── arm_2d_fill.c │ ├── arm_2d_paint.c │ ├── arm_2d_transform.c │ ├── arm_2d_video.c │ └── ... ├── examples/ │ ├── ARM-2D_Example/ │ │ ├── MDK/ │ │ ├── GCC/ │ │ └── IAR/ ├── scripts/ ├── Doxygen/ └── test/

核心代码全部集中在Library/Source下，Include里是对外暴露的API和类型定义。特别注意arm_2d_cfg.h，这个头文件是性能与功能的开关总闸，后面集成时大概率要按项目裁剪。

值得留意的是，examples目录下同时提供MDK、GCC、IAR三套工程文件。这不是随手的习惯，而是Arm团队刻意降低集成门槛的表现。对于做选型尽调的人来说，这本身就是个积极信号：库的维护者明确知道自己的用户是嵌入式工程师，不同工具链的适配成本已经被他们提前消化了一部分。

1.2 评测基线与环境说明

我这次做的是纯静态评测，不依赖具体开发板，重点看“源码结构”和“工程约束”。但为了给出相对具体的体积和资源估算，我设定了一个典型基线环境：

• 内核：Cortex-M4F，主频150MHz，带FPU
• 编译工具链：Arm Compiler 5.06 update 6（AC5）
• 优化等级：-O3，使用MicroLIB
• 内核配置：无OS裸机环境，直接操作寄存器
• 典型分辨率：320x240 RGB565，RGB888，RGBA8888混合场景

为什么选AC5而不是AC6或GCC？因为存量工业项目里，AC5还有大量用户，且Arm-2D对AC5的老版本编译器也保留兼容性，这一点源码里能直接看到宏判断。静态评测的目的是给最多的人一个参考基准，而不是只服务最新工具链。

1.3 为什么“尽调选型”不能只看README

我见过太多团队，README上写着“极低资源占用”“高效渲染”，就决定引入，结果项目中期发现Flash爆了、中断延迟变差、底层驱动打架，最后只能返工。做技术尽调，必须自己从源码层面确认三个问题：

• 第一，库的边界在哪里？它负责渲染到内存，还是连屏驱一起接管？
• 第二，资源占用是否可控？是否所有功能都会无条件编进固件？
• 第三，和现有架构的耦合度有多高？要不要为它改中断、改调度、改缓冲策略？

Arm-2D的定位很清楚：它只解决“像素怎么算”的问题，不解决“像素怎么送到屏上”的问题。这个边界既是优点也是约束，后面落地章节会再展开。静态评测的核心目的，就是在动手写第一行业务代码之前，把这些边界和约束全部确认清楚。

2. Arm-2D源码模块拆解与关键机制

2.1 服务分层：low-level API与high-level API的取舍

从接口设计上，Arm-2D把所有渲染能力拆成了两层。第一层是low-level API，直接以arm_2dp_前缀开头，比如arm_2dp_copy、arm_2dp_fill、arm_2dp_alpha_blending。第二层是high-level API，以arm_2d_前缀开头，内部封装了场景、图元绘制、字体渲染等更高阶逻辑。

从静态代码结构看，low-level层是最有价值的资产，它的函数实现几乎全部放在arm_2d_core.c和arm_2d_alpha_blend.c等文件中，而且每个函数都做了极细颗粒度的拆分。比如最简单的打点填充，就划分为不带掩码版本、带掩码版本、带Alpha版本、带掩码带Alpha版本等好几个入口。这种拆分初看冗余，但换来的是编译器的极致优化空间——每个函数都可以针对特定参数做常量折叠，调用方少传一个NULL判断，循环体里少一个分支。

high-level层则设计为“场景播放器”模式，核心是arm_2d_scene_player。开发者注册场景、设置帧回调，库内部维护场景切换、图层管理、脏矩形区域计算。这个设计对Cortex-M裸机非常友好，配合RTOS时也不会有额外的锁竞争问题，因为整个场景状态机是单线程的。

2.2 tile与region：整个库的数据地基

要读懂Arm-2D的源码，必须先理解两个核心类型：arm_2d_tile和arm_2d_region。

arm_2d_tile是Arm-2D对“一块可渲染内存”的抽象。它包含了画布指针、宽高、颜色格式、行字节数等基础信息。所有API的操作对象都是tile，不是裸指针。这个抽象带来的好处非常明显：函数签名统一了，上层不用关心目标到底是显存、内存缓冲区还是DMA缓冲区。静态检查时，你会看到大量代码在做tile合法性校验，包括空指针、尺寸合法性、颜色格式支持性等，这在资源受限MCU上是必要的防御，但也意味着调用方必须正确初始化tile，否则API会直接拒绝执行。

arm_2d_region则描述“一块矩形区域”。这是脏矩形、裁剪、局部刷新这些机制的最小单位。Arm-2D的多数渲染函数都支持传入region限定绘制范围，超出region的部分会被自动裁剪。这个机制在源码里是一个统一的宏封装__arm_2d_region_validate，它会把目标区域和画布尺寸求交集，如果交集为空就直接返回，省去后续所有计算。

从工程角度，我建议所有接入Arm-2D的团队，第一件事就是把业务里所有“矩形区域”相关逻辑统一改为arm_2d_region表达。你会发现后续做碰撞检测、控件刷新、动画区域计算，都比自己维护x/y/w/h干净得多。

2.3 颜色格式与像素处理管线

Arm-2D支持的像素格式非常直接，全部围绕嵌入式屏幕常用格式展开：

• RGB565，双字节像素，最常用
• RGB888，三字节像素
• RGBA8888，四字节像素，带透明通道
• Gray8，灰度图，适合单色屏或作为Alpha图源

源码里对颜色格式的处理高度依赖宏开关ARM_2D_CFG_SUPPORT_COLOUR_CHANNEL_8BIT、ARM_2D_CFG_SUPPORT_COLOUR_CHANNEL_16BIT、ARM_2D_CFG_SUPPORT_COLOUR_CHANNEL_32BIT。如果没有定义对应宏，相关颜色格式的转换函数会被直接排除在编译之外。这一点对精简Flash占用价值巨大。例如一个纯RGB565项目，完全不支持32位像素，很多转换表和像素处理路径都会被裁掉，静态体积能省下一块可观的量。

一个容易被忽略的细节是arm_2d_convert系列函数对格式转换效率的优化。源码中大量使用了查表法和像素级别的预处理，比如把RGB565转换成RGB888时，不是逐字节移位扩展，而是通过预计算的掩码和乘法移位一次完成。这种手写优化在嵌入式图形库中相当扎实，源码阅读时能发现很多可以直接借鉴的技巧。

2.4 alpha混合与掩码：源码里最考验功力的地方

Alpha混合是所有GUI开发绕不开的重头戏，Arm-2D的实现方式也体现了它面向Cortex-M优化的设计理念。核心函数是arm_2dp_alpha_blending，它分成两类：目标带Alpha的混合，以及目标不带Alpha的直接覆盖。后者的计算量远小于前者，因为无需处理目标像素原有Alpha值。

真正的性能大头在“让目标带上Alpha的混合”路径里。这一步需要同时读取源像素颜色、源Alpha、目标像素颜色、全局Alpha，计算后再写回。源码中为不同的颜色格式组合分别实现了专门函数，比如source为RGB565+Alpha、target为RGB565、globalAlpha为常量等，这些组合被模板化地拆开，避免了运行时多分支判断。

掩码（mask）机制是另一个精髓。Arm-2D支持用1bpp掩码实现不规则形状裁剪，也支持8bpp掩码实现软边缘。它把掩码处理和Alpha混合放在同一个管线里统一计算，避免了多趟遍历。阅读arm_2d_alpha_blend.c时，能看到针对掩码的循环展开、位操作加速等细节。这部分代码不适合作为业务代码阅读范本，因为复杂度较高，但作为“确认库的实现深度”的静态证据，非常充分。

2.5 防锯齿与旋转缩放的实现强度

Arm-2D的防锯齿和图像变换功能，是它在同类库中差异化最大的地方。源码里的arm_2d_anti_aliasing.c实现了基于区域覆盖率的边缘平滑算法，与PC端图形库的后处理抗锯齿不同，它是在图元光栅化阶段直接计算边缘像素覆盖率，然后写回Alpha值。这样不会产生额外的全屏后处理Pass，对MCU来说非常友好。

旋转缩放功能集中在arm_2d_transform.c，它支持0度、90度、180度、270度旋转，以及镜像和任意角度旋转。任意角度旋转的内部实现依赖定点数运算，输入参数需要先通过arm_2d_expected_rotation接口算出期望目标尺寸，再实际执行变换。静态代码阅读时，能发现这套实现并不是简单的双线性插值套公式，而是根据旋转角度的象限做了分量分解，大幅减少了浮点参与。即便MCU没有FPU，纯定点也能跑。

但注意，任意角度的旋转缩放，临时缓冲区是必不可少的。源码注释里明确要求目标tile不能同源（in-place变换），且需要额外分配临时内存。这是静态评估时的一个重要结论：功能很强，但RAM预算必须把临时缓冲算进去，不能只按显示分辨率算。

3. 静态资源占用与性能预算估算

3.1 Flash占用构成的保守估算

把Arm-2D的全部源码纳入编译，会得到一个相当大的体积，但实际项目很少这么干。核心工程的Flash占用主要来自下面几个模块。

按这个表叠加，全功能大约40~70 KB Flash。但实际项目如果只使用RGB565 + 基础填充 + Alpha混合，体积通常会落到15~25 KB区间。这个弹性空间来源于两个机制：所有可变功能都用宏开关，以及编译器可以剔除未引用函数。静态评测阶段建议直接用“全功能体积”做上限预算，再用“裁剪后体积”做实际排期，两头都有数。

3.2 RAM占用与缓冲策略分析

RAM占用是Arm-2D落地最需要精打细算的部分。静态源码里能确认的RAM消耗来源有三个层次：

第一是基本数据区，包括tile描述符、region记录、场景播放器状态。这部分几十到上百字节，可以忽略不计。

第二是显存/画布本身。如果框架层把整块屏幕缓冲作为渲染目标，那么320x240 RGB565需要150KB，而480x272 RGB565约需要261KB。很多MCU片内RAM根本扛不住，因此必须引入块渲染（partial buffer）策略。

第三是临时渲染缓冲，这是最容易被低估的部分。任意角度旋转缩放时，临时缓冲区至少是一张目标tile的大小。如果需要背景图重绘加旋转，很可能同时在RAM里存在多块完整位图缓冲。静态评估时，我强烈建议按“最大临时缓冲=目标tile面积x2”来规划RAM，否则开发到后期会遇到绘制错位或malloc失败的问题。

3.3 CPU开销与帧率的静态测算方式

静态评测虽然没有跑板子，但源码中的关键循环体是可以做预估的。以RGB565的纯填充为例，核心循环体编译后大约每像素3~5个周期。用150MHz主频计算，320x240全屏填充需要76800像素，预估消耗约0.3~0.4ms。Alpha混合RGB565源到RGB565目标，每像素大约10~15个周期，全屏混合约1.5~2.5ms。这些数据意味着：如果一帧内做一次全屏背景填充加一次全屏Alpha混合，加上剩余业务逻辑，320x240@60MHz级别的MCU（比如M0+）也会比较吃力，但150MHz的M4F能轻松跑到60fps上下。

不过必须说清楚，这只是静态测算，实际帧率还受显存带宽、DMA占用、总线仲裁影响。如果屏幕接口是SPI，传输一帧320x240 RGB565的数据需要76800x2=153600字节，SPI 40MHz全双工条件下至少也要3.8ms，这已经超过了部分接口的刷新预算。Arm-2D只负责“算好像素”，传输瓶颈需要显示屏驱动和硬件设计兜底。

在源码层面，我发现Arm-2D的API几乎全是纯计算接口，极少包含OS锁、延时、等待信号量等阻塞点。这意味着它很适合和DMA传输配合：CPU算好一块区域后交给DMA发送，同时CPU继续计算下一块区域。静态源码里也保留了相关的注释提示，明确鼓励用户以“算一块、传一块”的方式和DMA并行。

4. 工程落地约束与Cortex-M平台适配分析

4.1 集成方式：裸机事件驱动优先

Arm-2D在高层的场景播放器设计上是典型的事件驱动结构。看过源码就会发现，它的核心循环需要在主循环里被反复调用，类似于状态机tick。典型集成方式是：

void app_main_loop(void) { while (1) { arm_2d_scene_player_task(&(my_scene_player)); // 其他业务逻辑 } }

与RTOS集成时，可以把arm_2d_scene_player_task放到一个专用线程里，但要注意线程优先级和DMA回调的竞态。源码没有为多线程访问提供重量级锁，所以如果多个线程同时访问同一个tile，必须由业务层保证互斥。这个约束在选型时需要想清楚。

4.2 Cortex-M不同内核的适配差异

Arm-2D的官方定位是支持Cortex-M0/M0+到M7/M33/M55等全系列。但它对不同内核的性能差异极大，静态源码里也隐藏着几处针对内核的优化分支。

Cortex-M0/M0+没有乘法指令的快速版本，也没有硬件除法。Arm-2D在涉及旋转缩放和Alpha计算时大量使用乘法和除法，因此M0平台的性能会比M4/M7差很多。官方在内存布局和加速后端里也做了考量，但对M0来说，建议只用基础填充和拷贝，避免高频任意角度旋转。

Cortex-M4/M7带FPU，Alpha混合和颜色转换里部分计算可以切到浮点，但实测中定点反而经常更快。静态源码里arm_2d_math相关函数大量使用定点数，并不是为了兼容无FPU内核，而是定点计算在并行流水线里更容易做到确定性周期。这意味着哪怕你的M4F有FPU，也应优先开启定点路径，可以参考arm_2d_cfg.h里的相关开关。

Cortex-M7的高性能来自双发射和分支预测，但代价是D-Cache和TCM的复杂性。Arm-2D的tile缓冲区如果放在普通SRAM而非TCM，D-Cache的逐出会导致帧率抖动。静态源码注释里有明确提示：允许用户在配置阶段将tile内存分配到TCM或快速SRAM区。落地时建议把核心tile区域放到TCM，把大块位图资源放到外部RAM或Flash映射区。

Cortex-M33带TrustZone，Arm-2D的相关示例较少。如果你在安全和非安全世界里都需要渲染，要注意每个世界都必须有一份独立的tile和缓冲区，这会让RAM预算翻倍。静态设计时需提前评估。

4.3 屏幕驱动适配与图层叠加约束

Arm-2D不直接管理LCD控制器，这是它和GUI框架最大的边界。但它定义了一套清晰的“目标tile”概念，要求屏幕驱动层必须把显存抽象成一个可写的tile。常见的适配方案有两种：

一种是把显存直接映射成tile。这种方式最简单，Arm-2D直接画到显存地址，然后通知屏幕刷新。缺点是需要整块显存常驻RAM。

另一种是先画到内部缓冲tile，完成后再通过DMA或CPU拷贝到显存。这种方式适合带局部刷新的屏幕，比如SPI接口屏。Arm-2D的脏矩形机制这时候价值最大，每次只更新有变化的部分，能大幅减少传输量。

图层叠加方面，Arm-2D的高层API支持多个图层（layer）合成，比如背景层、内容层、弹窗层。每个图层是独立的tile，合成时通过arm_2dp_alpha_blending按顺序叠到一起。“图层”概念是它区别于单纯绘图API的核心优势，但要注意每个图层都会消耗一块全尺寸显存。

4.4 中断延迟与低功耗约束确认

图形渲染是典型的CPU密集型任务，长时间占用主线会对中断产生一定影响。Arm-2D源码本身没有关闭全局中断的操作，所有函数都属于可被中断抢占的长任务。因此设计中要把渲染过程切分成可重入的“块”，让高优先级中断能可靠插入。配合PendSV或跳过渲染的机制，能有效抑制实时性抖动。

低功耗场景下，Arm-2D的表现也不错。渲染完成后立即进入睡眠，不会主动持有外设或时钟源。但要注意唤醒后需要重新确认tile指针地址的有效性——如果低功耗模式将部分SRAM断电，tile里的数据会丢失，重新渲染时必须确保缓冲区内容完整。这一点在源码的默认行为里不会自动处理，需要应用层自己判断。

5. 移植与最小集成实证流程

5.1 源码目录裁剪策略

拿到完整Arm-2D源码后，不建议整个拷贝到项目里。标准做法是建立自己的Middlewares目录，然后按需复制：

Middlewares/ └── Arm-2D/ ├── Include/ └── Source/ ├── arm_2d_core.c ├── arm_2d_fill.c ├── arm_2d_alpha_blend.c ├── arm_2d_paint.c ├── arm_2d_transform.c └── arm_2d_anti_aliasing.c

如果确实不需要字体渲染，可以不拷贝PFT相关文件。但如果要跑官方demo，examples里的文件会依赖更多模块，建议先从arm_2d_core.c+arm_2d_fill.c跑通最小路径，再逐步打开其他功能。

5.2 arm_2d_cfg.h配置开关对照

arm_2d_cfg.h是裁剪的核心。它通过一组宏定义来决定哪些功能编译进固件。直接改宏，比手动注释源码安全得多。

我的建议是：RGB565项目的16位和8位宏一定开，32位宏先关掉，等确需RGBA再打开。ALPHA_BLENDING默认开，但如果你只是做纯色填充和拷贝，关掉能省下不少Flash。

5.3 初始化与tile绑定实例

最简集成流程如下。首先定义显存tile：

#include "arm_2d.h" static uint16_t s_DisplayBuffer[320 * 240]; static arm_2d_tile_t s_MainDisplayTile; void app_gui_init(void) { s_MainDisplayTile = (arm_2d_tile_t) { .tRegion = { .tSize.iWidth = 320, .tSize.iHeight = 240, }, .tColour = { .u2ColourFormat = ARM_2D_COLOUR_RGB565, }, .pBuffer = (uint16_t *)s_DisplayBuffer, .nHeight = 240, }; arm_2d_init(); }

然后渲染一个蓝色矩形并做Alpha混合打底：

void app_gui_render_demo(void) { arm_2d_region_t tRect = { .tLocation.iX = 50, .tLocation.iY = 50, .tSize.iWidth = 100, .tSize.iHeight = 80, }; // 先填充不透明蓝色矩形 arm_2dp_fill_colour(&s_MainDisplayTile, &tRect, ARM_2D_COLOUR_BLUE, 255); // 定义一个半透明红色精灵（仅举例，实际可能是图标位图） static arm_2d_tile_t tSpr = { .tRegion = { .tSize.iWidth = 100, .tSize.iHeight = 80 }, .tColour = { .u2ColourFormat = ARM_2D_COLOUR_RGB565 }, .pBuffer = s_IconBuffer, .nHeight = 80, }; arm_2dp_alpha_blending(&s_MainDisplayTile, &tRect, &tSpr, 127); }

这里s_IconBuffer是预先加载的一张100x80的RGB565图像。执行后屏幕蓝色底上会出现一个半透明图标。整个调用链没有阻塞、没有OS依赖，极其干净。

5.4 与LVGL/AWTK等GUI框架的组合方式

很多项目不是从零自绘UI，而是已经有LVGL或AWTK。Arm-2D和它们不是替代关系，而是可以形成加速组合。

LVGL从8.3开始支持用户自定义flush回调。把Arm-2D作为LVGL的draw buffer渲染后端，可以让LVGL的像素输出交出去处理。但这要求LVGL配置为单缓冲或双缓冲模式，并确保Arm-2D的tile指向LVGL提供的缓冲。我建议不要直接在LVGL的lv_disp_flush_cb里调用Arm-2D的混合接口，除非你清楚LVGL内部会怎样组织绘制命令，否则容易出现重叠区域渲染错误。

AWTK的情况类似，它外部接口里有awtk_arm2d的加速适配示例。静态源码里能看到AWTK团队提供的一层适配代码，通过这层，AWTK的基础绘图会被派发给Arm-2D执行。但这一层适配会引入额外的配置项和源码依赖，选型时需要评估它和业务代码的耦合。

真正稳妥的做法是：如果项目以通用控件为主，继续用LVGL/AWTK；只有在下述场景才直接切入Arm-2D：需要高性能图元渲染、效率敏感的Alpha混合、旋转缩放要求高，或者项目本身希望摆脱重型GUI框架、轻装定制。

5.5 多帧循环与场景播放器接入

如果你打算用Arm-2D高层场景播放器而非裸API，接入方式也不复杂。定义一个场景播放器，并注册多个场景更新回调。

static arm_2d_scene_player_t s_ScenePlayer; void app_gui_scene_init(void) { arm_2d_scene_player_init(&s_ScenePlayer, scene_1_on_play); } void app_gui_loop(void) { for (;;) { arm_2d_scene_player_task(&s_ScenePlayer); delay_ms(16); } }

每个场景回调里执行一个渲染步骤。因为场景播放器内部会自动处理场景切换、图层合成和脏矩形标记，这能让多人协作的UI代码结构更统一。但代价是学习成本比直接调用API高，而且场景回调里不能执行阻塞性传输，否则整个播放器被卡住，动画节奏全乱。

6. 问题排查与选型结论速查

6.1 静态评测中最常踩的源码级问题

第一类问题是颜色格式不匹配导致花屏。Arm-2D内部不做隐式格式转换，即使同为16位像素，RGB565和BGR565也可能让混合结果错乱。排查时先打印tile的u2ColourFormat，确认两边一致，再往下查数据内容。

第二类问题是tile的region信息不完整。创建tile时只给了pBuffer和尺寸，忘了初始化tRegion，API内部校验不通过，直接返回错误码，表现为“什么都不画”。这是最大的一个新手坑。

第三类问题是旋转缩放时的临时缓冲区失效。某些代码把临时缓冲放在局部变量栈里，但Arm-2D的旋转函数内部可能分阶段引用，返回后并没有拷贝结果，于是画面随机花掉。必须把临时缓冲定义为静态或全局区域。

第四类问题是中断与主循环共用tile。DMA发送和CPU渲染同时访问同一块显存，会导致视频撕裂或闪屏。解决方案是使用多缓冲机制或需要小心设计同步关系。

6.2 项目适配性判断速查表

6.3 选型落地的时间盒建议

如果团队要引入Arm-2D，我会建议用2周做技术预研，而不是动辄排一个月的评估期。第一周跑通最小工程，完成一块屏的RGB565显示和Alpha混合Demo；第二周把业务里最典型的两个界面迁过去，实际测量Flash、RAM和帧率。如果两周后效果没有显著优于现有方案，大概率是项目场景不适合，不必强行上。

源码静态评测过程中，我发现Arm-2D的设计哲学偏向“让工程师在约束下做优化”，而不是“提供全能的傻瓜式封装”。它把渲染细节全部暴露出来，让集成者自己决定缓冲策略、颜色格式和裁剪范围。这种风格未必适合所有团队，但一旦摸清它的边界，是可以在Cortex-M上做出很高的渲染效率和可控性的。

最后分享一个我自己的小经验：接触Arm-2D时，不要拿它和桌面GPU渲染做对比，也别和LVGL的软件渲染做无意义的口水战。它就是给Cortex-M贴身的、可裁剪的、可预期的软件加速库。把它的宏开关吃透、把tile的边界管理好，再配合DMA传输，这个组合在我目前接触的工程里，是性价比最高的MCU图形方案之一。如果你还在犹豫，找一个周五下午，把官方examples的MDK工程编译一把，跑起来看看效果，比读十篇评测都实在。