对于MMI工程师在BREW上的开发需求，往往是以Applet为单位的。Brew上的Applet就是一个应用程序，和Application的概念类似。

大多数Applet都需要UI界面（Daemon程序的需求往往很少），他们往往需要完成一定的功能，所以有逻辑的部分，如计算器程序，就是要处理用户输入的数据并给出计算结果；另外，我们需要提供显示界面和用户进行交互，越是动感越是绚丽的界面效果越能赢得用户的喜爱。话说回来，MMI层次上开发的应用，逻辑上大多比较简单，不需要复杂的算法。开发者不必了解太多的底层知识和硬件知识，只要有扎实的程序语言开发功底（BREW上多数用C，也有用C++的），基本上都能写出一般的应用来。另外，逻辑部分的代码变动性不强，而界面效果在不同的工程间则可以相差很大，还是拿计算器程序来举例，我们在不同的手机上看到的计算器程序，有的界面效果看上去很一般，而有的则很漂亮，但是他们完成的功能是差不多的。而对于一个公司来讲，他们往往希望同一套代码能够适应不同工程项目上的需求，这样可以在很大程度上减少工作量。其实这是客制化的一部分，最理想的客制化是不需要修改代码，只要替换图片资源、字符串资源和其他一些资源如音频资源即可达到目的。但是如果差异较大，光靠资源的替换是很难满足需求的，还是需要修改到代码的。我们会希望尽量少地改动到逻辑代码，最好是只需要修改到一些数据，而不用去修改实质性的代码，而功能逻辑上的一致性给了我们一定的可能。说了这么多，其实是说：我们在设计的时候尽量考虑通用性，以提高代码的复用率以及风格变换的简易性。

目前，在Brew上开发界面，主要使用BUIW。在BUIW中，主要有Form, RootForm, Container, Widget, Decorator, Model等概念。下面简单介绍一下这些基本概念：

Model：其实Model是一个用来存放数据的结构。它提供专门的接口让用户设置Model的值或得到Model的值。另外Model还负责维护Listener List，并提供接口允许对象监听它（将Listener加入到Listener List中）。当用户通过Model提供的设置数据的接口改变Model的值的时候，Model就会逐个给监听它的Listener对象发送消息（实际上是直接调用Listener注册的回调函数），监听的对象再做出相应的动作，如使用新设置进来的数据更新画面等。其实这里应用了设计模式中的观察者模式（Abserver Pattern）。Model分很多种，比较常用的有Value Model, Interface Model, Vector Model等，不同种类的Model存放的数据类型不同。一般情况下，一个Widget会关联上一种Model，并监听Model数据的改动。

Widget：Widget是BUIW中一个最小的UI元素，可以理解成控件，比如按钮(Button Widget)、图片（Image Widget）、静态文本框（Static Widget）、可编辑文本框（Text Widget）、滚动条（Scroolbar Widget）等。它们会根据需要关联Model，如Static Widget，它需要记录显示的字符串内容，所以会关联一个Value Model，而对于Image Widget，则关联Interface Model。一般Model存放的是一些允许用户设置或修改的数据，比如一个Static Widget，有的时候显示“你好”，有的时候显示“这是一段文本”，这些不确定的可随时修改的数据就存放在它关联的Model中。这样当这些数据更改的时候，Model会通知Widget你需要更新你的长相，和你的数据保持同步了。当然监听者对于数据的改动也可以做出不同的反应。

Container：一个个Widget创建好之后，它们该怎么摆放是一个问题。因为Widget只知道自己长什么样子，却不知道自己该站在什么地方。Container就是Widget的家，它是用来组织管理Widget的，一个个Widget会依次插入到Container合适的位置去（什么是合适的位置？就是在这个Container中，除了相对于Container的相对位置以外，还有Z轴方向上的叠放次序，也就是说在垂直于屏幕的方向上，Widget之间还是有先后顺序的，位于上层的Widget有可能挡住位于其下的Widget，这就是Z-Order的概念）。Widget本身是有大小的，Container本身也是有大小的，所谓大小就是矩形区域的意思。所以位于Container中的Widget与它的Parent Container有一定的位置关系，分别是完全位于Container中、与Container一部分相交和完全位于Container外部。位于Container外部的那部分是肯定不会被显示出来的，而位于Container内部的那部分如果在其上没有被其它Widget遮挡住，就可以显示出来。Container同样根据定位方式可以分成以下几种：
        XYContainer，这是一种最简单的Container，通过Widget的左上角位置和Container的左上角位置的偏移量确定Widget的相对位置。这里水平方向为X方向，向右为正，竖直方向为Y方向，向下为正（一般程序中坐标系都是这么定的）。
        PropContainer：这里的Prop是Proportion的缩写，也就是比例的意思。所以PropContainer实际上就是通过给它包含的Widget在空间上按照比例分配大小来实现定位的。PropContainer需要指定是在X方向上的按比例分配还是Y方向上的按比例分配，不能同时在X方向和Y方向按比例分配。PropContainer的好处是在不同分辨率的情况下，它都能够布局得很好。
       ConstrainContainer：这是通过约束来实现定位的Container，Widget可以通过相对于Parent Container的上下左右边界的距离或者相对于Sibling Widgets边界的距离进行定位，使用起来比XYContainer和PropContainer都来得复杂，在特殊场合会比较有用，平时一般用得比较少。
        CardContainer：CardContainer很特殊，也很简单，因为它只考虑Z方向的叠放次序，而忽略X方向和Y方向的位置距离。它就像一叠堆放整齐的纸牌，我们只能看到最上面的一张，而位于下面的是无法看到的。前面提到的3种Container，其实我们都是在X方向和Y方向对它们进行定位，CardContainer根本不需要，所以它最简单。CardContainer的典型应用是和TabWidget的搭配。
        所有的Container在Z方向的叠放次序都是在插入的时候指定的。另外，我们可以把一个Container看成是一个比较复杂的Widget，因为我们可以通过ISHELL_QueryInterface(, AEEIID_WIDGET,)获取到与它相应的IWidget*，然后当做是一个简单的Widget调用WIDGET提供的方法。正因为如此，我们可以把Container作为Child Widget插入到另一个Container中，来实现比较复杂的界面组织。也正因为如此，我们可以把Container作为WID_FORM插入到Form中，作为Form的Widget。若不是如此，界面结构将是多么单调，所以对于Container来说，它本身可以作为Widget来使用是极具意义的。

Decorator：Decorator和Container类似，也可以往里面装入Widget，只是Decorator只能往里面装入一个Widget。它也不是用来给Widget布局的，而只是为Widget提供修饰服务的。Decorator同样可以被看成是一个Widget，通过ISHELL_QueryInterface(, AEEIID_WIDGET,)获取到与它相应的IWidget*。MMI在开发Applet设计Form的时候，一般不会用到Decorator。它主要在设计某些Widget的时候被用到，如Border Widget, TabWidget, ScrollbarWidget等。所以这里也不讨论其具体用法。

FORM：比较传统的理解可以这样认为：每个界面差不多都是一个FORM，正常情况下它包括顶上标题Title、底部的软键SoftKeys和中间的那个ID为WID_FORM的Widget（前面提到过了），这个WID_FORM的Widget是Form中最重要的一部分，设计和创建Form的时候，主要在设计和创建这个Widget（前面说过多数情况下它是Container，里面可以包含多个Widget和子Container，这种包含关系是树形结构）。但是其实也可以这么理解，其实Form只是保存着一部分用来显示的信息，包括Title, WID_FORM的Widget和Softkeys等相关的数据；另外一部分重要的功能就是处理事件（IFORM 是直接从 IHANDLER继承下来的，本身没有增加任何方法），像IFORM_GetWidget(), IFORM_GetRootForm之类的接口实际上都不是IFORM虚函数表中的实现，都只是普通的inline函数。Form的很多功能包括显示都是依赖RootForm的。

ROOTFORM：比较传统的理解可以这样认为：RootForm继承自Form，基本上每个Applet（只后台运行的Daemon程序除外）都会创建一个属于自己的RootForm，负责维护应用中所有创建出来的Form。事实上，我们看到的Applet画面就是RootForm绘制的，也可以理解成我们看到的是RootForm，因为RootForm才真正创建了........（待续）.......

3.1 信号量和P、V操作

信号量：表示资源使用情况的一种数据结构

struct{
	int n; //正数表示当前可用的资源个数，负数表示等待该种资源的进程个数
	PCB* pcbList; //等待该种资源的进程(PCB)列表
}

信号量的值仅由P、V操作来改变

原语：机器指令的延生，往往是为完成某些特定功能而编制的一段系统程序，其操作具有不可分割性（一次性完成）

P操作P(S)：也叫wait操作，S为相应的信号量

S = S - 1;
if (S < 0)
{
    //资源不足，得不到分配的情况
    将本进程链入 S 的队尾；
    阻塞本进程；
}
else
{
    本进程继续执行；
}

V操作V(S): 也叫signal操作

S = S + 1;
if (S > 0)
{
    //说明目前没有进场在等待该资源
    本进程继续执行；
}
else
{
    //说明有进程在等待该资源
    释放S队列上的第一个PCB；
    本进程继续执行；
}

3.2 同步机制的应用

使用PV操作实现进程互斥

• 在每个进程中，P(mutex)和V（mutex）必须成对出现，并且先P后V
• 互斥信号量mutex的初值一般为1

使用PV操作实现简单同步

例如 ： 供者和用者共同使用缓冲区的问题

分析和解答：供者和用者两个需要合作来完成，它们之间的桥梁是缓冲区，它们之间的动作需要按照一定的先后顺序才能顺利进行，它们之间的关系是同步。临界资源是缓冲区，因为供者在向缓冲区写入数据的时候，用者不能从缓冲区读数据，同样，在缓冲区数据写满后，用者开始读缓冲区数据，这时供者不能往缓冲区里写数据，直到用者从缓冲区中取完数据。缓冲区有两个临界状态，一是空了，一是满了。使用两个信号量来表示，E表示空了的状态，F表示满了的状态，初始状态下缓冲区是空着的，所以E = 1, F = 0。对于供者，先用P操作获得空着的缓冲区，在写满数据之后，再用V操作释放一个满了的缓冲区的信号量；而用者则使用P操作获得写满的缓冲区，在取完数据之后，再用V操作释放清空的缓冲区的信号量。 所以供者的程序如下：
P(E);
写数据到缓冲区;
V(F);
用者的程序如下：
P(F);
将缓冲区中的数据全部取走;
V(E);

不难理解为什么P操作又叫wait操作，而V操作又叫signal操作。因为P操作会确保获得满足信号量要求的临界资源，如果暂时没有，会等待直到其他进程释放出该临界资源并得到后再继续执行；V操作会释放出一种临界资源，发出一个信号，如果有其他进程在等待该资源，会将该资源交给队列最前面的那个进程。

这里有个比较容易混淆的问题：既然临界资源只有缓冲区一种，为什么使用两个信号量E和F？回顾一下什么是信号量,信号量并不代表临界资源，而是临界资源的状态，既然临界资源有两种状态空着和满了，就可以用两个信号量来表示。另外初始值E = 1表示有一个空着的缓冲区，而不是表示缓冲区是空着的，F = 0 表示没有满了的缓冲区，而不是表示缓冲区没有满（或者是空着的）。

使用PV操作的说明：

• 确定彼此关系和信号量种类
• 设定信号量初值
• 同一信号量的PV操作要成对出现，只是互斥的PV操作在同一进程中成对出现，而同步的PV操作在不同进程中成对出现。

同步互斥的经典例子：生产者和消费者

生产者和消费者的问题和上面提到的供着和用者的例子类似，只是供着和用者只有一个缓冲区，而生产者和消费者有N个缓冲区，构成缓冲池。当N=1时候，本问题就成为了供者和用者的问题，可见，供者和用者的问题只是本问题的一个特例而已。

1、消费者只有在生产者生产出产品之后才能消费（缓冲池中有满的缓冲区时才可以让消费者从缓冲区取走产品消费）
2、生产者在缓冲池满了以后要暂停生产，直到有空的缓冲区出现
3、为避免混乱，生产者和消费者互斥使用缓冲池

上面的1、2点讲的就是供者和用者中提到的同步问题，第3点讲的是互斥问题。

同步问题同样设E和F两个信号量，E表示缓冲池中空缓冲区的数目，初始状态下E = 0; F表示缓冲池中满了的缓冲区的个数，初始状态下F = N。另外增加缓冲池的互斥信号量M， 初始状态下M = 1(表示只用一个缓冲池可供使用）

对于生产者，他要做的事情是：1、等待获得空缓冲区；2、等待获得缓冲池的使用权；3、往空缓冲区中放入产品；4、释放缓冲池使用权（通知缓冲池可以使用了）；5、通知新增一个满的缓冲区（一个新产品）

对于消费者，他要做的事情是：1、等待获得满的缓冲区；2、等待获得缓冲池的使用权；3、从满的缓冲区中取走产品；4、释放缓冲池使用权（通知缓冲池可以使用了）；5、通知新增一个空的缓冲区

生产者和消费者都要做5步动作，其中他们的第4步和第5步都是可以互换的，但是其他步骤是不能改变顺序的，尤其是第一步和第二步。如果第一步和第二步颠倒，很可能发生锁住的问题（死锁），导致生产者和消费者都不能往下进行。举个例子：假如消费者先获得了缓冲池的使用权，然后等待获得满的缓冲区，不过当时没有满的缓冲区，它就在一直占用缓冲池的情况下处于等待状态；而生产者因为得不到缓冲池的使用权，也无法让缓冲区变慢，这样消费者也就永远无法获得满的缓冲区（产品），于是生产者和消费者谁也干不了活了。不过有个原则是：互斥信号量的PV操作要成对出现在临界区的前后，所以第4步和第5步最好不要颠倒，既便于记忆，又避免出错。

上面的步骤中凡是使用了”等待获得“来描述的，都是P操作，要获得的东西是P操作的信号量；凡是用到了”释放“或”通知“的步骤都是V操作，释放或通知的东西就是V操作的信号量。

注意：

• P(mutex)和V(mutex)分别出现在临界区的前后
• 各信号量的P、V操作都要成对出现
• 两个P操作的顺序不能颠倒

2.1 进程的概念

资源的分配单位、并发执行的基本单位、能独立运行的单位

进程：程序在并发环境中的执行过程。

程序本身是具有顺序性的（顺序执行），它的并发执行是通过进程来实现的。

一个程序可由多个进程共用，一个进程可顺序执行多个程序。

特征：

• 动态性
• 并发性
• 调度性：资源的分配单位
• 异步性：（走走停停）
• 结构性： PCB

进程的组成：

• 进程控制块PCB
• 程序
• 数据集合

进程和PCB的关系：

• 每个进程有唯一的PCB
• OS依赖PCB管理进程
• 利用PCB实现进程的动态和并发
• PCB是进程存在的唯一标志

2.2 进程的状态及其转换

• 状态存在于PCB
• 基本状态
  • 运行态：分到CPU，真正在运行
  • 就绪态：万事具备，只差CPU
  • 阻塞态：等待设备资源

2.3 进程的同步与互斥

进程活动中会相互制约

• 所有进程均相互独立
• 以异步方式并发执行

同步：进程间共同完成一项任务时直接发生相互作用的关系

举例：供者和用者的关系（供者把数据放入缓冲区，用者从缓冲区提取数据）

说明：

• 同步进程间具有合作关系
• 在执行顺序上须按照一定的顺序协调进行

互斥：并发执行的多个进程由于竞争同一资源而产生的相互排斥的关系

说明：

• 互斥进程在逻辑上是完全无关的
• 他们的运行不具有时间次序的特征（对同一资源的使用并无谁先谁后的规定）

2.4 临界资源和临界区

临界资源（Critical Resource）：一次仅允许一个进程使用的共享资源（包含硬件资源和软件资源）

临界区（Critical Section）:在每个进程中访问临界资源的那段程序（简称CS区）

进入临界区的准则：

• 单一进入：进入临界区的进程在任何时候最多只能有一个
• 独自占用：进入临界区的进程单独占用临界资源
• 尽快退出：使用完临界资源后尽快释放临界资源并退出临界区
• 等则让权：在等待临界资源的时候，需让出CPU使用权

操作系统的功能：

• 存储器管理
  • 内存分配
  • 地址映射：把逻辑地址映射为内存的物理地址
  • 内存保护：各程序之间的内存如何做到不冲突
  • 内存扩充：提供虚拟内存
• 处理机管理
  • 作业调度
  • 进程调度
  • 进程控制
  • 进程通信
• 设备管理
  • 缓冲区管理
  • 设备分配
  • 设备驱动
  • 设备无关性：方便编程使用
• 文件管理
  • 文件存储空间管理
  • 文件操作
  • 目录管理
  • 读写管理和存取控制
• 用户接口
  • 命令界面
  • 程序界面
  • 图形界面

操作系统的特点：

• 并发（宏观上的，与并行相区分）
• 共享
• 异步

操作系统的类型：

• 批处理系统：单道+多道（作业）批处理系统
  • 多道批处理系统虽然多个作业成批进行，但是缺乏与用户的交互性
• 分时系统
  • 分时：若干并发程序对CPU时间的共享
  • 多个用户终端共用主机
  • 特点：
    • 同时性：多个用户同时使用
    • 交互：用户可控制程序的运行
    • 独立：用户感觉不到其它用户的存在，感觉自己在独立使用计算机
    • 及时：计算机对命令及时响应
• 实时系统
  • 响应时间更短，比分时系统的“及时”更为“及时”
  • 特点：
    • 专用
    • 实时
    • 高可靠
• 个人机系统
  • 分类
    • 单用户操作系统
    • 多用户操作系统
• 网络操作系统
  • 多个主机通过网络互联
  • 特征
    • 分布式
    • 自治性：各台主机可自行运行
    • 互连性
    • 可见性：知道对方计算机地址
• 分布式操作系统
  • 特征
    • 分布式处理
    • 模块化结构
    • 利用信息通信
    • 实施整体控制
  • 特点
    • 透明：不知道资源位于何处
    • 灵活：得益于模块化结构，系统的修改很方便
    • 可靠：一部分发生故障并不影响整体的使用
    • 高性能
    • 可扩充

右击任务栏角上的小喇叭，选择Recording devices（录音设备），可以看到下图窗口：

如果不能看不到上图中的麦克风和立体声混音，在窗口内部空白处右击，在弹出的右键菜单中选中"Show Disconnected Devices（显示未连接设备）"即可。

以下几张图是麦克风的属性设置：

此处关键，usage必须选中“Use this device (enable)”（使用此设备）

此处关键，必须选中“Listen to this device（监听此设备）”。其实原理就是监听麦克风的输入，通过回放设备（扬声器）进行播放。以后要不要播放麦克风的声音，就是在这里控制切换的。


 

如果按照以上设置，你就可以对这麦克风说话，你的声音就直接从扬声器上播出了。只不过效果肯定没KTV的好，它会有一定的滞后（不过不怎么严重），用来说话扩音是没有问题的，如果是K歌的话，可能会影响你的发挥。

其实C语言课上的时候，老师也分析过strcpy，甚至老师将该函数体的循环部分简化为一个语句。另外，本人也一直对自己的编码风格、C语言和一些比较常见的算法都很自信的，不过今天自己写了strcpy()这个函数，回来后发现自己还是载在了这个上面（其实也不是太影响面试结果）。反省一下！

当时写strcpy函数的时候，有几个没有记清的地方的：
1、strcpy会不会主动给strDest的末尾加上'\0'，当时当成不加了来处理。
2、参数是否该去检测NULL，因为strcpy作为比较常用的库函数，感觉程序员理应为主动为其保证正确性（现在想起来林锐当时好像用的是assert），不过我们写嵌入式的好像不怎么习惯用assert，也可能是我个人的情况。），即使可以保证指针为有效的地址值，也无法保证strDest分配的空间是足够的。不过这个判断语句还是写上了，因为写上去至少不会说是错。
3、其他错误（如果调试运行一下就可以发现）。

不怕丢脸，贴出我写的那个错误版本的strcpy函数：

1. char* strcpy(char *strDest, const char *strSrc)
2. {
3.     char *p = strSrc;
4.     if (NULL == strDest || NULL == strSrc)
5.         return NULL;
6.     while ('\0' != *p)
7.     {
8.         *strDest = *p;
9.         strDest++;
10.         p++;
11.     }
12.     return strDest;
13. } 

函数中申请了临时变量p，不过没有用它来存放strDest。当初只想着把传入的strDest返回去就好了，结果忽略了过程中把它移动了。所以，其实这个是最大的错误，但是调试运行一下是很容易发现的。当时给strSrc设置了个变量的原因是因为const，其实我知道这里const修饰的是char*，也就是说地址strSrc指向的那片空间的数据在本函数中是不可以去修改的。但是当时也是为了“双保险”，就来了个char* p = strSrc; 。实际上这句话是有warning的，如果当时调试了，估计就把它删除掉了（因为我更讨厌强转，且这句话是非必须的）。

在讨论到要不要判断入参是否为NULL的时候，主考官的说法是：必须要，因为如果用户传入的是NULL，向0地址写数据，那会引起系统崩溃。本来是想和他说系统应该会有保护的，不过因为没有经过测试，也就只说了程序员在调用该函数的时候在调试过程会发现的。 所以晚上故意测试了一下，在windows上，这样做会导致程序本身不能运行，并不会导致系统崩溃，所以我那系统有保护的想法是正确的。其实这跟系统是否提供保护机制有关系。（不过肯定的是：对入参是应该进行有效性检测的）。

其实第6到第11行可以简化为一行，不过因为不会提高执行效率，反而会降低可读性，所以就没那么写，同时也降低了出错的机率。

另外经过测试库函数strcpy发现：它是会给strDest的最后加上字符串结束符的（测试方法很简单，使用局部变量char str[n]，不要给他初始化就直接strcpy后输出，看后面是不是有乱码输出——这里必须使用局部变量，因为申请到的局部变量的初始值是随机的，而全局变量或静态变量是会被初始化为0的）。

最后本人修改函数如下：

1. char* strcpy1(char *strDest, const char *strSrc)
2. {
3.     char *p = strDest;
4.     if (NULL == strDest || NULL == strSrc)
5.         return NULL;
6.     while ('\0' != *strSrc)
7.     {
8.         *strDest = *strSrc;
9.         strDest++;
10.         strSrc++;
11.     }
12.     *strDest = '\0';
13.     return p;
14. } 

其实在这类函数中使用assert比判断指针是否为空更好，因为assert是用来调试的，而判断指针是否为空是防错性编程。所以第4行和第5行可以修改为：
assert(NULL != strDest && NULL != strSrc);
其实判断多个指针都不能为NULL，还可以优化为：if (NULL != p1 | p2 | p3 | ... | pn)

其实这道题目考的不是算法，而是编程习惯，所以我在这题上的得分基本上是0分。

如果其他算法题目，大家在笔试的时候是不需要完全做正确的（当然了，如果能够完全正确是最好不过的），因为那个主要考的是你的思路，是你的逻辑思维能力，当然还有你的编码风格。之所以说不需要完全正确是因为，在不调试的情况下，如果算法不怎么简单，是很少有人一写就正确的。当然写好后最好再检查一遍（类似Code Review），这样可以发现一些笔误和一些简单的逻辑错误。但是还是可能会有一些错误是你一时发现不了的。

刚才我抽取了两道在展讯做的算法题，竟然发现没有错误，欣喜！
而运行了在今天面试的那家公司的排序算法题，其中方法一也没有错误，方法二有逻辑错误，少了一句break（其实是当时考虑遗漏的地方）。虽然这错误影响运行结果，这个break在该函数中的作用也是举足轻重的，但是我个人认为：这不算失败，在没有调试的情况下，一个较复杂的算法有这样一个未察觉的错误是正常的现象。

算了，想想还是把我做的这个题贴出来吧，反正也没有告诉大家这是哪家公司的题目：

1. int *getASCArray(int srcArray[], int len)
2. {
3.     int i, j;
4.     int *destArray = (int*) malloc(sizeof(int) * len);
5.     if (NULL == destArray)
6.         return NULL;
7.     
8.     destArray[0] = srcArray[0];
9.     for (i = 1; i < len; i++)
10.     {
11.         if (srcArray[i] >= destArray[i - 1])
12.         {
13.             destArray[i] = srcArray[i];
14.         }
15.         else
16.         {   
17.             for (j = i - 1; j >= 0; j--)
18.             {
19.                 if (srcArray[i] >= destArray[j])
20.                 {
21.                     destArray[j + 1] = srcArray[i];
22.                     break; //完成该数的插入
23.                 }
24.                 else
25.                 {
26.                     //直接把数据往后移一步
27.                     destArray[j + 1] = destArray[j];
28.                 }
29.             }
30.         }
31.     }
32.     return destArray;
33. } 

其中第22行的break是晚上调试后补充上的，其他代码是在笔试的时候做的。

毕业后买了这台笔记本，是联想的Y530，Pei的那一款，P8600的CPU，9600m gs的显卡，4g的DDR3内存。想起大学里玩的那款游戏，后来发现原来名叫FarCry，中文名为孤岛惊魂。当是在vista下下载并安装了FarCry的Demo版，就几百兆的，是英文版的（估计也没人愿意给他汉化），如果把配置调高了，会玩不起来（画面不正常），但是如果合理地选择高级视频选项，还是可以玩起来的（多数设置成中或低）。后来下了个中文版，不管怎么设置都玩不起来。

后来安装了windows 7，前几天又更新了驱动程序（包括显卡驱动程序）。在更新驱动之前（使用Vista上的驱动），Windows Experience Index（Windows体验指数）的各项分数如下：
Prosessor（处理器）：5.9
Memory(RAM)（内存）：5.5
Graphics（Aero图像）：4.9
Gaming graphics（游戏画面）：4.8
Primary hard disk（主硬盘）：5.5
综合分数为4.8（以最低分数计算的），而在vista下的综合分数是5.0的，可能是因为给显卡做了一些设置（比如选择了最好画面，打开了各种效果）的原因。
更新驱动之后的各项分数如下：
Prosessor（处理器）：5.9
Memory(RAM)（内存）：5.5
Graphics（Aero图像）：4.9
Gaming graphics（游戏画面）：6.2
Primary hard disk（主硬盘）：5.5
综合分数为4.9，可以看到其他都没有变化，但是游戏画面的分数却变得高。感觉游戏性能会提高不少，安装孤岛惊魂v1.4中文版，发现玩起来还是很吃力，虽然设置第一点可以玩。于是猜测是不是人家汉化得不好，导致游戏运行性能大大下降。于是又找了个英文版的（网上中文版的容易找到，英文版资源相对少些），安装后验证了我的猜测。

只要把纹理质量设置成低（不然近处的草地是黑色的），其他的都可以设置成最高。各种设置如下图（不知道为什么游戏内置的F12截图功能无效，所以窗口化后截了整个桌面的图片）：
视频选项（抗锯齿开到8x后，玩的时候有时候会小卡，实际上效果也并不会提高多少，因为显卡本身就打开了抗锯齿功能）：

高级视频选项(其中的Texture Quality纹理质量设置成低，其它都设置生最高的)：

声音选项：

游戏选项：

效果图：





 

如果你的计算机配置不是很高，想玩这款游戏的话，建议安装英文版的试试。如果你的配置很高，也建议玩英文版的，至少可以减少发热量，哈哈。

电脑一玩这游戏，风扇就会吱吱吱地吹起来，所以要保证它的散热才行，尤其是笔记本，一般笔记本散热都不会太理想。