关于在美拓的简短的总结与体会
概要：
这仅仅是个人的一点心得体会与总结，本登不得大雅之堂，然而我作为一个对于手机开发完全的零起点对于其中的艰难与痛苦有着切肤的体会，这一切促使我不敢身藏浅陋将一些零星琐碎公之于众，即作为自己在美拓的简短人生经历的一个总结，如果能给后来者提供一点点地借鉴也心满意足了。
1． 关于编译环境的认识体会
首先面对程序员的就是相对复杂的编译环境及其繁琐的配置工作。高通平台分为仿真和实际的arm编译两个截然不同的编译环境，其中有些相同有些不兼容。
a) 仿真编译
仿真完全使用vc6的编译机制，高通的例子是把一个个小applet编译成为dll动态库，我们的工程应该是把brew的模拟器作为静态库链接到meta的工程里面，模拟器的配置在win32/bin/brew_emu.dat中，在其中可以指定外观即devicepack配置文件，以及applet运行的文件系统路径，及其相应的mif文件所在路径。 PhoneFile=H:\CDMA\L200\Win32\DevicePack1\L200\DevicePack1.dpk
AppletDir=H:\CDMA\L600-new\Resource\FileSystem
MIFDir=H:\CDMA\L600-new\Resource\FileSystem
Vc6能够自动解析源文件的相应的依赖关系省却了程序员写makefile的痛苦，但是如何创建vc6的工程文件是一个很繁琐的工作。
美拓的代码统统使用cfg文件管理机制可以很方便地依靠gendsp.cmd工具加入工程组，也就是说每个源代码模块都定义了一个.cfg文件，里面列明了模块的头文件.h，源文件.c/.cpp，以及链接库.lib/.a。
[IncludeFiles]
$(METAMMI)/apps/Java/jblendia_jvm/include/settings/Meta_Java_Settings.h
[SourceFiles]
$(METAMMI)/apps/Java/jblendia_jvm/port/amsui/Meta_AmsUI.c
[LinkFiles]
!ifeq ($(META_TARGET),Arm)
$(METAMMI)/3Parts/JBlend/library/ajsc/ajsc_arm_ads.a
!else
$(METAMMI)/3Parts/JBlend/library/ajsc/ajsc_win32_msvc.lib
以上就是.cfg文件的格式，于是，运行win32/build目录下的gendsp.cmd就会运行一个perl的脚本gencfgmin.pl来读取metammi.cfg文件，这个文件列表了所有工程要包含的meta的模块cfg文件，然后通过这些cfg文件列明的.h,.c,.lib文件就被加入了工程，也就是加入了simulator.dsp的vc6的工程文件。
但是代码里面的include头文件是一个很麻烦的事情，首先，有些工程人员喜欢把其中的头文件名前面加上相对的路径，但是这个对于编译确实很麻烦的事情，因为编译器寻找这些路径是从一个运行的相对路径开始，然后按照编译设定的搜索路径和系统环境变量比如/include项下的路径搜索，一旦工程文件位置变动就有可能搜索不到，同时过多的设定搜索路径会减慢编译速度，因为编译器会不停在各个路径下搜索，而在系统环境变量中设置弊端更多因为有可能把不同项目的同名头文件包含进来，这才是程序员的噩梦。因此
美拓的做法是include统统使用双引号并且不带路径，并在遍历.cfg的时候把这些相应的头文件都拷贝到win32/build/include目录下，所以，你在vc6的工程里面看到的头文件在编译器看来却是在使用另外一个在build/include目录下的同名头文件，你要改动必须修改工程原路径下的重新编译才能更新拷贝，否则修改build/include下的拷贝都被覆盖掉了。
cfg机制对于非高通的meta的代码很方便，但是高通是采用一个min文件的方式来建立makefile的，添加到vc6工程就没有那么方便了，幸好不是很经常修改高通代码，因此，我们可以在simulator.dsp的源头template.dsp里面修改，就是把需要应用的高通的.c文件加到template.dsp文件里面，运行gendsp.cmd就更新了simlator.dsp。但是头文件是不能拷贝进来的，只能使用vc6的头文件搜索路径添加：ADD BASE CPP /nologo /MD /W3 /GX /O2 /I "..\..\binstore"
这里的/I就是搜索头文件的路径，头文件的名字自然是在代码里面的了。
链接的链接库也是类似的使用# ADD LINK32 libjpeg_win32_msvc.lib /LIBPATH:"..\..\Source\Meta\3Parts\JBlend\library\libjpeg\lib"
其中的/LIBPATH就是指示编译器搜索库的路径。
因此，如果要添加一个新的代码文件模块或者链接库，使用高通的方式很麻繁，不如使用meta的办法在cfg里面定义，同时这个方式是仿真和arm通用的，不需要再手动修改template.dsp。 （即便是高通的代码我们也可以使用cfg方式，只不过高通自己有一套编译顺序我们不应该干扰他。）
我们要添加定义的宏怎么办呢？原本meta的设计是在一系列的custXX.h文件里面作，这个cust头文件在source/qualcomm/build/ms目录下主要是定义了一系列的所谓feature的开关，其中的XX原本被设计成项目代号，这样就可以在不同项目打开不同的所谓feature开关编译，但是我对这个方法是有保留意见的，因为他的宏定义有一个小问题，他的所谓FEATURE_OFF/FEATURE_ON被定义为了0/1，在代码中的宏判断是#if(FEATURE_STATUSBAR_ONLYIDLE == FEATURE_OFF)可是使用宏最危险的就是它有可能因为编译顺序或遗漏include还没有定义，如果FEATURE_OFF还没有定义，默认也是0，所以这个宏就可能被误读。 还有一个仿真添加宏定义比如至关重要的META_EDIT宏的定义，这个也可以放在template.dsp里面# ADD BASE CPP /nologo /MD /W3 /GX /O2 /D "FEATURE_BREW_DOWNLOAD" 其中的/D就是宏定义的开关。
搜索template.dsp有如下
# Begin Custom Build - Checking all include files...
InputPath=.\res\Simulator.ico
"copy.log" : $(SOURCE) "$(INTDIR)" "$(OUTDIR)"
call ..\..\Source\Qualcomm\build\ms\ads12.bat make -f gendsp.mak copyincfile
# End Custom Build
这里就是以上提及的copy include代码到我们的build/include目录的地方，这是利用了vc6的custom-build的机制，在编译前调用perl脚本。
这里要顺便提一下ads12.bat的重要性，因为高通的编译机制大量地使用perl脚本因此如何初始化perl的运行环境至关重要，因此在所有调用perl脚本前都要先调用这个批命令。同时perl运行于linux/unix环境依靠cygwin才得以运行于windows环境，所以也需要初始化cygwin的环境变量，然而linux/window毕竟有很大区别，比如文件系统就还是有区别，如果你在运行arm编译看到类似于什么as.exe不能正确执行的错误即便你的ads12.bat已经正确运行了很有可能是因为你没有把as.exe的文件属性加上system，比如attrib +s as.exe
b) arm编译
arm编译和仿真编译有着巨大的差别，要复杂的多。首先要从编译资源做起。资源包括图片，文字存放在resource/meta下的image,string,theme目录下，给每个资源编写资源id是一件很繁琐的事情，这里也是依靠了工具运行ImageResConv.bat把image下的所有图片都编篡相应的资源id，比如一个图片文件input_123.png最后就在MetaImg.brh里面变成了
#define IDI_PNG_INPUT_123 8145
命名的原则就是IDI_TYPE_FILENAME,其中type应该是文件类型即扩展名，8145是程序顺序产生无关紧要。这样程序员在代码中按照这个命名原则就省却了更新命名资源id的烦恼了。这个metaImg.brh最终被放在source/meta/res/project目录下，其中project未当前的项目代号，这个必须要在build_res.bat里面设定了比如 @set PROJECT=0803_L201。最终这个metaimg.brh成为metammi.cfg的一栏。文字和图片稍有不同，就是把中文字串资源“T_Yes 是”和英文资源“T_Yes Yes”进行统一编号为metaStr.brh里的“#define T_Yes 3”而相应的实际资源文件则是#define CHINESE_RES_FILE "Chinese.bar"变成了高通的资源文件。
这一切的编译工作都是在一个resource/meta/Build_Res.bat下完成的。
需要提醒注意的是，image路径下任何文件都回被搜罗当作资源图片文件，因此如果使用svn需要删除svn文件或者把图片拷贝出来编译。
编译完资源后就可以开始编译了，但是首先要做的还是设置好ads12.bat，这个的重要性前面已经讲过了，每个人都有可能不同要根据自己的安装路径来设置。运行arm/prj_code.bat其中prj_code代表当前的项目代号，因此相应的在/source/qualcomm/build/ms目录下你要有相同项目代号的prj_code.cmd, prj_code.mak，cust_prj_code.h，同时在/source/meta/res/prj_code/下要有相应的资源文件以便链接。正是编译同样使用meta的收集cfg的方式生成实际的makefile，高通的编译器是支持c++编译的，比如tcpp.exe就是c++编译器，在dmss_rules.min里面有perl脚本根据代码文件扩展名自动选择编译器的规则，因此你也完全可以写c++代码只要你使用.cpp文件扩展名。
高通使用min文件来定义每个小模块包含的源文件，其中还包含了.s文件，这个是一个对大多数pc程序员的巨大的surprise，这里要从程序运行谈起。因为pc的程序的运行地址一般都是relocable的，也就是说运行起在哪里是不需要关心的，是由操作系统的loader加载同时修改代码的偏移地址完成在任意物理地址运行的，但是手机程序的静态加载模块地址却是定死的，当然各个模块的地址可以依靠.scl的文件来调整，这个是linker的一个配置文件，它规定了各个模块的boot内存地址的相对关系，比如以/source/qualcomm/build/ms/q60x0a_rom.scl为例，
BB_RAM +0x0
{
dloadarm.o (+RW)
dloadusb.o (+RW)
}
/////////////////////////////////////////////
// added by nick for jvm
//Add liaohs.amoi.com.cn for JAVA
JBLEND_RAM +0x0
{
jblend_*.o (+RW)
}
//End liaohs for JAVA
// added by nick for jvm
/////////////////////////////////////////////
这里实际上规定了dloadarm.o和dloadusb.o的模块的相对位置，同时也隐含着输出了一个地址symbol BB_RAM，同样的java虚拟机的起始地址JBLEND_RAM会在回编码里编成两个symbol: Image$$JBLEND_RAM$$Base和 Image$$JBLEND_RAM$$Length，注意这里使用的$$符号是arm编译器内部使用的，和普通的c程序变量名不兼容，为了能够让c程序在链接时候引用这两个地址相关的变量名，需要一个所谓的.s文件来转换。在source/qualcomm/driver/boot目录下的bootmem.c里面可以使用extern来声明
extern byte *Image__ JBLEND_RAM __Base;
extern byte *Image__ JBLEND_RAM __Length;
在boot_data.s文件里面把这些变量名从汇编码的”$“形式转换为”_”：
IMPORT |Image$$JBLEND_RAM$$Base|
IMPORT |Image$$JBLEND_RAM$$Length|
EXPORT Load__JBLEND_RAM__Base
EXPORT Image__JBLEND_RAM__Length
他们的定义是这样子的：
Image__JBLEND_RAM__Base
Image__JBLEND_RAM__Length
而这个所谓的.s文件是在相应的boot.min文件里包含了。这种机制的核心就是为了能够让java虚拟机在起始运行阶段记录相应的内存地址，而这一切都是由于静态加载的地址在编译器就决定了。
b) 关于组键编程
高通的组键模型编程基本上和微软的COM机制类似，只不过搞通为了方便嵌入式程序员大多不熟悉c++语法以及某些效率的考虑才使用纯c语法模拟实现，但是微软的COM机制博大精深，高通仅仅借用了其中内存资源释放管理与组建创建的很小一部分。
任何一个组键一定要实现最基本的三个接口方法，即AddRef,Release,QueryInterface，这三个方法看似简单，但是meta的代码的写法似乎都有不妥之处。
第一， 这三个方法都应该是完全对外调用的不应该随随便便当作内部方法来使用，比如有的人在组件的
constructor，也就是所谓component_new方法里面不设定nRef计数为1，却调用QueryInterface来
增加引用计数，虽然效果看上去一样，实际却是有令人混淆的嫌疑，我以为在constructor里面直