如果把这三者放在一起比较，先说一下三者的共同点，也就是Model和View：

• Model：数据对象，同时，提供本应用外部对应用程序数据的操作的接口，也可能在数据变化时发出变更通知。Model不依赖于View的实现，只要外部程序调用Model的接口就能够实现对数据的增删改查。

• View：UI层，提供对最终用户的交互操作功能，包括UI展现代码及一些相关的界面逻辑代码。

异

三者的差异在于如何粘合View和Model，实现用户的交互操作以及变更通知

• Controller

Controller接收View的操作事件，根据事件不同，或者调用Model的接口进行数据操作，或者进行View的跳转，从而也意味着一个Controller可以对应多个View。Controller对View的实现不太关心，只会被动地接收，Model的数据变更不通过Controller直接通知View，通常View采用观察者模式监听Model的变化。

• Presenter

Presenter与Controller一样，接收View的命令，对Model进行操作；与Controller不同的是Presenter会反作用于View，Model的变更通知首先被Presenter获得，然后Presenter再去更新View。一个Presenter只对应于一个View。根据Presenter和View对逻辑代码分担的程度不同，这种模式又有两种情况：Passive View和Supervisor Controller。

• ViewModel

注意这里的“Model”指的是View的Model，跟MVVM中的一个Model不是一回事。所谓View的Model就是包含View的一些数据属性和操作的这么一个东东，这种模式的关键技术就是数据绑定（data binding），View的变化会直接影响ViewModel，ViewModel的变化或者内容也会直接体现在View上。这种模式实际上是框架替应用开发者做了一些工作，开发者只需要较少的代码就能实现比较复杂的交互。

Java Compiler Compiler ^tm (JavaCC ^tm) is the most popular parser generator for use with Java ^tm applications. A parser generator is a tool that reads a grammar specification and converts it to a Java program that can recognize matches to the grammar. In addition to the parser generator itself, JavaCC provides other standard capabilities related to parser generation such as tree building (via a tool called JJTree included with JavaCC), actions, debugging, etc.

echo 'java -cp /path/to/javacc.jar $(basename $0) "$@"' > javacc

chmod 755 javacc

ln -s javacc jjtree

ln -s javacc jjdoc

近期，我们根据友盟移动统计分析平台的部分数据，对中国移动应用发展现状进行了研究和分析，并且通过对广大移动应用开发者的调查透视了国内APP开发者的现状。希望能够为移动互联网创业者提供最有价值的参考！

2011年3月——2012年3月 TOP100应用增长趋势

     从2011年的3月份到今年的3月份，移动应用无论是活跃用户还是日启动次数都有了十足的增长。我们按照应用的累计安装量作为排序标准，选取了TOP100的应用作为统计样本，研究后发现活跃用户和日启动均比去年的3月份增长了5倍之多。可见越来越多的用户开始接受并享用移动互联网为人们生活带来的便利。

用户地理分布&联网方式&运营商分布

关于中国移动互联网用户的地理分布，广东、江苏、北京、浙江和福建五省或者直辖市排在了前五名的位置，占据了全国用户份额的40.7%。在2011年第三季度的时候，我们也发布一份数据报告,显示用户份额前五的省份或者直辖市是广东、江苏、浙江、北京和上海，占据全国用户份额的44.6%。另外，2011年第二季度前五名省份或直辖市所占总份额是49.4%。不难看出，移动互联网向二线城市蔓延的趋势依然是持续并且不可逆转的。

关于联网方式和运营商，2G上网依然是一半上网用户的选择，占比51.2%。使用3G和WIFI的用户占比分别为14.6%和34.2%。联通和电信凭借其3G套餐和优惠购机业务，市场份额已经分别占据了20%和9.5%。

国内移动应用开发者现状

友盟一直致力于为国内移动开发者提供最专业的服务，现在已经服务超过20000名开发者和开发团队，为他们提供专业的统计分析、应用联盟和开发组件产品。为了更好的服务移动互联网创业，我们在2012年第一季度邀请了广大移动开发者进行了一次全面的问卷调查。调查的几个重要结论如下：

1.  移动互联网个人开发者占比27%，其余为公司或者工作室
2.  团队人数小于5人的超过65%
3.  超过85%的开发者&团队选择了Android平台
4. 72%以上的开发者开发的应用数量少于5款

在WP7.1中针对Background Agent的新API增加了蛮多非常强大的部分，以下将介绍Scheduled Multi Tasking的部分。

　　Scheduled Multi Tasking主要是让Application支援多工模式来执行任务，让Application不在前景模式下也可以继续在背景执行某些特定的任务，例如：背景下载、背景更新资料、背景唿叫服务…等。

　　然而，WP7.1提供Agent的模式，让开发Application时将要背景执行的逻辑，独立放置于Agent之中透过排程来完成任务。

　　但要注意的是，Agent与Application必竟还是属于不同的专案，因为IsolatedStorage中的IsolatedStorageSettings无法共用，要交换资料需透过IsolatedStorage档案或其他方式来交换。

　　因此，在设计一个支援Background Agent(ScheduledTaskAgent)的Application时，我个人会有几个考量：

　　1. 将背景执行的逻辑独立成一个类别或模组，由该模组完成所有背景的任务;

　　2. 使用设定档(config)的方式，将参数或执行结果独立于档案，提供Application与Agent均可以取得;

　　3. Agent是背景的任务，在背景发生Exception的容错机制需要特别设计，尽量透过通知告知用户;

　　接下来，将细部去讨论Scueduled Tasking由那些重要的元素组成：

　　〉Microsoft.Phone.Scheduler - Scheduled Multi Tasking：

　　WP7.1允许Schedule Task与Background Agent在背景执行它们的任务，然而Schedule Task与Background Agent使用上却有所不同：

　　‧Schedule Task：重点在于指定「週期性/延迟性」执行任务，透过设定Schedule的时间频率重覆地去执行任务;

　　‧Background Agent：根据不同的Agent可在细分使用重点，但较属性一次性任务或接收外部事件所触发的任务;

　　在Microsoft.Phone.Scheculer针对Scheulde提供了Task与Notification的使用，其用法上Schedule Task又是另一种用途，针对Schedule Notification会在另一篇<>进行说明。

　　然而，在Scheulde Task的使用上有几个重要元系一定要去了解的，以下将详细说明：

　　A. ScheduledActionService：

　　专用于管理该设备所有的Scheduled Actions。Scheduled Actions包括了可用于通知的Alarm、Reminder，更包括下方介绍的二个运行于Background Agent的Periodic Task与Resource-Intensive Task。其重要的方法如下：

　　B. PeriodicTask：

　　Periodic(定期) Task是一种定期代理运作的观念，专门针对运作背景任务所需时间较少，而且是执行隔间具有规律週期性的情境。

　　常见的使用情境，例如：定期上传手机的Location资讯、完成少量资料的同步、更新Tile状态…等。

　　B-1. 使用Periodic Task的约束与时间週期建议

　　C. ResourceIntensiveTask：

　　Resource-Intensive(资源密集) Task是针对需要相对较长的处理时间，或是遇到需使用大量手机电源、网路等资源时较为适用的类型。

　　常见的使用情境，例如：同步大量的资料(如App需要下载大量的资料至手机端才能让App运行)…等。

　　C-1. 使用ResourceIntensiveTask的约束与时间週期建议

　　这二个元素其实都是由ScheduleAction与ScheduledTask抽象类别实作出来的，它们分别有自身使用的情境与适用性，

　　二者最大的差别即在于使用情境与需要耗用手机资源的多少，以及resource-intensive task要在萤幕锁定与电力90%以上才能执行。

　　由于使用resource-intensive task要求的限制实在很多，因此，在设计Scheduled Task时需要特别考虑这个部分，至于其他相关的

　　属性就大同小异了，以下简介其较长使用到的属性：

名称	说明
Description	设定/取得有关该Scheduled Task的描述。该描述的内容将会出现于手机「Settings/Applications/Background Tasks Settings」的画面中。  如下图：以Background Scheulde为程式名称：
ExpirationTime	设定/取得Scheduled Task到期的时间。
IsScheduled	取得Scheduled Task状态是否为启动。
LastExitReason	取得Agent执行最近一次Task被结束的理由。
LastScheduledTime	取得Agent执行最近一次Task的时间，以手机时间为主。
Name	取得Scheduled Action的名称。

　　了解了二个元素的基本属性与使用情境后，有几个使用Background Agent要特别注意的：

　　1. 一个Application只能有一个Background agent(ScheduledTaskAgent)，但Agent可以单独使用PeriodicTask、ResourceIntensiveTask

　　或者二个同时使用。要注意的是一个Agent只能有一个PeriodicTask与一个ResourceIntensiveTask。

　　2. Background Agent(ScheduledTaskAgent)：

　　2-1. 透过OnInvoke(ScheduleTask)触发Agent逻辑的部分;

　　2-2. 已成功执行完所有任务时，记得唿叫NotifyComplete()告知Agent已完成任务;

　　2-3. 如果在执行过程发生错误或是无法执行Task时，要记得唿叫Abort()告知Agent接下来取消运作，然而即可以在Application端取得

　　ScheduledTask中的IsScheduled属性为false。但要注意的是如何Abort()之后，要记得使用ShellToast告知用户，以免用户不知道。

　　3. Background Agent在记忆体使用量的控制：

　　3-1. Periodic agents与resource-intensive agents允许在每次执行Task时，不超过6MB记忆体用量。

　　3-2. Audio agents则限制不能超过15MB记忆体用量。

　　3-3. 在Debug模式下则不限制，但可以透过API去查询在每一个部分使用记体忆的状况。

　　4. 预设Agent为二个星期后需要重新安排Scheduled：

　　虽然可以透过ScheduledTask中的LastScheduledTime去确认究竟最近一次执行的Datetime为何，并且使用ExpirationTime去指定Task

　　可运行的时间长度。但是使用ScheduledTask可能因为条件限制(例如遇到执行Task时没网路能力，自动要求Agent延后执行)，造成Task

　　长时间没有被执行，为了确保Task不会一直占住不使用，透过设定2个星期可存活时间，可以自动解决这个问题。设定ExpirationTime可

　　在每一次执行Application于前景状况时，进行判断与设定。

　　5. Scheduled Agent在连续二个Crash后自动取消：

　　由于使用Periodic agents与resource-intensive agetns是交由Agent去控制，因此，当Agent连续出现二次以上的Crash或无法预期的错误，

　　该Agent将会被停止，需透过Application回到前景模式再重新启动它。