MTK平台开发总结（全）声明：前阶段进行了近两个月的MTK平台上层开发，由于缺乏技术支持，对于整个平台的认识都是通过简略的文档和浅薄的经验摸索出来的。
其间整理了一些文档。
由于联发科提供的PDF全部是英文，有些名词难以翻译准确，只能凭单方理解和嵌入式开发的词汇习惯进行意译，还请谅解。
系列文章均出自原创，肤浅可笑之处，望海涵。
（一）窗体的重画通过观察可以发现，每个窗体模板都调用这样一个函数：dm_redraw_category_scree n()。
这个函数便是显示窗体的函数。
它内部的实现是这样的：获得该窗体所包含的组件及它们的属性，再根据组件的类型和属性，调用不同的接口，逐一绘制各组件。
详细流程如下图所示：由上面的流程可见，无论是窗体所包含的组件，还是组件的属性，都是根据模板ID获取的。
那么现在摆在面前的有两个问题：一、模板ID是如何传递到这个函数中的；二、模板ID和窗体组件、组件的属性，是如何关联到一起的。
我们逐一解决这两个问题。
一、模板ID是如何传递到这个函数中的模板ID，是Sho wCateg ory..Screen()过程中，所显示的界面的编号，千万不要与EntryNe wScree n(scrID，…) 函数中传入的窗口ID相混淆。
它们以―MMI_‖为前缀，被定义在枚举型结构MMI_CATEGORY_ID_L IST中，又通过结构体d m_data_struct和它的全局结构体变量g_dm_data，在应用程序中被广泛使用。
先看看结构体dm_data_struct的定义：typedef struct{S32 s32ScrId;S32 s32Cat Id;S32 s32fl ags;}其中，s32ScrId是当前窗口ID，也就是我们使用EntryNe wScree n（）时传入的那个参数；而s32Cat Id才是模板ID；最后的flag，是模板需要显示软键盘、清屏等动作时，所置的标志变量，它在上面提到的那个dm_redraw_category_scree n（）函数中被判断。
MTK开发中一些经验总结1. 在确定你的MTK工程完整而且在模拟器和真机上能正常运行之前，不要开始工作。
2. MTK开发 C是唯一选择，不要试图用把C++工程移植到MTK平台 (c++是没有问题的，venus ui就是用c++写的，基于venus ui的wedgit也用c++)。
3. ADS C/C++ COMPILER不同的编译选项可能导致代码的性能差异很大。
ADS使用ARMV4指令集，而真机是Thumb指令集。
4. MMI/GUI的工作尽量用MODIS模拟器。
真机编译很慢，可用分布式编译加速。
5. Image$$ZI$$Limit 错误原因有2种：使用了malloc,free, printf, assert,fopen之类的函数; 定义了过大的静态数组。
6. 适配WIN32和ARMC平台。
文件读写和内存操作函数需要替换成MTK支持的函数。
7. MTK真机内存有限(MED堆内存<800k)，ROM SIZE极其宝贵，尽量优化代码结构，减少内存占用。
8. MTK支持多线程，不过是用TASK替换Thread.9. 真机有watchdog, 函数内LOOP太久会导致阻塞并重启，可以加kal_sleep_task, 给系统一点空闲。
10. 真机重启常见的错误LOG有2种： assert failed: 会显示出错的文件及代码行。
data abort: 一般是数组越界。
11. 重启错误可通过恢复函数栈来大致定位出错函数段。
可在Cacher.exe里Advance>Exception handling查看stack dump ,对应查找\build目录下的.sym文件。
12. 做好代码的内存泄漏检测。
13. 不要频繁的分配小块内存，这样会导致内存碎片。
kal_sleep()为MTK睡眠函数，使用请注意以下问题：在MMI_TASK中请不要随便使用这个函数，在MMI_TASK中用这个函数会导致MMI_TASK睡眠，会影响其他消息的处理如果非必要请尽量不要使用，寻找其他解决方案。
