Android 系统上的 Xposed 框架中都有哪些值得推荐的模块？
绿色守护、x隐私什么的都不错嘛，模块资源大多是英文的看起来吃力，来用中文介绍一些不错的模块吧
按票数排序
GravityBox 超强劲的界面修改应用，CyanogenMod有的功能它都有，甚至还更全面。（ kitkat版本）（ jelly bean版本）XuiMod 可以更改特效什么的。（）Greenify（又名）『绿色守护』帮助你甄别那些对系统全局性能和耗电量有不良影响的应用程序，并通过独特的『绿色化』技术，阻止它们消耗您的电池电量，占用您的宝贵内存。经过『绿色化』工艺处理的应用，在您没有主动启动它们的时候，无法『偷偷』运行，而在您正常启动它们时仍然拥有完整的功能和体验，正如iPhone应用那样！AppOpsXposed 这个是专门给4.4的，可以解除Google 对Ops权限管理接口的封锁，还可以在app 详情界面的action bar 上添加一个导向Ops 的按钮。（）BootManager 开机自启动进程管理，反正我是不会去用360什么的。（）InstagramDownloader 下载Instagram上你中意的照片，推荐给Instagram的死忠粉。（）Tinted Status Bar 利用它搭配 Thyrus KitKat Light UI 主题能玩出很不错的花样（）效果图如下=================号电脑课补充=======================XHaloFloatingWindow 是一款桌面漂浮空间，自定义后可以在桌面快速的开启应用。（）XBlast Tools（原Status Bar Clock Color Mod）能够在不修改apk 的情况下允许你改变颜色的状态栏和通知栏时钟颜色。（）Immerse Me 可以强迫所有app 进入扩展桌面模式 （）=================号电脑课补充=======================XPrivacy 优秀的权限管理，不过4.3+用Ops 的朋友们可以无视。（）DisableCriticalBatteryShutdown 可以阻止系统在低电量时自动关机，榨干你的电池，不过记得保存数据！！！！（）LBE Security Master - Translation International 这个是送给LBE安全大师的用户的，为LBE提供了更多语言翻译（虽然发在这里貌似没啥用）（）XForceEnter 强制使用键盘回车键来打开Hangouts 中的emoji 表情键盘（）=================号在家里补充=======================YouTube AdAway 可以去除YouTube 里的广告（推荐给墙外用户）（）NoSafeVolumeWarning 去除耳机插入时候的音量警报，在部分国外地区可能会违反当地法律，不推荐给有小孩的知友使用（）Remove Moto G Second SIM icons 花钱买了一部Moto G 结果被双卡的两个信号栏喷了一脸狗血有木有！！！这个模块可以隐藏Moto G 的第二个信号栏（）
利益相关：我是所介绍的插件的开发者。 让你设备里几乎所有Twitter客户端可以用上API。因为打开之后就一个设置对话框，两个设置项，所以应该不需要介绍太多…… 有红领巾帮我写好了教程。
竟然没有我写的SwipeBack模块。===EDIT===本模块已被支付宝客户端列入黑名单
终于又碰到一个可回答的了，激动……先上截图，简单的我就不介绍了，大家自己看描述。第一个，Acdisplay不是Xposed模块，只是支持Xposed而已，一个熄屏通知的软件，好用不费电，5星好评。酷市场链接：Play：第二个，ActivityForceNewTask让每一次调用的其他程序都在“最近任务列表”里面出现。比如，在知乎里面点击一个外链，跳转到浏览器。这个模块可以让浏览器出现在“最近任务列表”里面。酷市场：第三个，App Settings我就不说了，简介很详细了。为每一个App打造自己的配置。不能配置声音有点遗憾。酷市场：第四个，ChromePie喜欢原生自带的那个蓝色浏览器的手势功能吗？现在chrome也可以用了哦，而且可以自定义。酷市场：第五个，Complete Action Plus管理“分享”，“打开为”这类菜单的东东。可以让你在自定义弹出选择菜单，能去除选项同时隐藏不需要的app。还可以改变风格、透明度等等。酷市场：第六个，重力工具箱不多说，神器。恩，分4.4和其他版本。酷市场：第七个，Instagram Downloader下载Instagram 里面你喜欢的图片。自己在Xposed框架安装器里面搜索安装。第八个，MinMinGuard去广告的，说实话没有发现多有效。个人感觉去广告最好用的还是LBE，不过现在不用了。酷安：第九个，NFC开启屏幕好东西，可以用你指定的nfc卡片在你熄屏的情况下触发，也可以点亮屏幕。不用蛋疼地点亮屏幕之后再刷nfc了。酷安：第十个，Native Clip Borad好东西，本地增强剪切板。长按输入框里面的“粘贴”按钮会弹出之前复制过的所有内容，然后你选取一个粘贴就行了。第十一个，Screenshot Delay去除系统自带截图时候的延迟，秒截。第十二个，Statusbar Scroll to Top点击状态栏，可以将你正在阅读的滑动区域滑动到最上面，动画效果看着忒爽。酷安：第十三个，StopSwitchDelay看介绍是去除什么延时的，不过我自己安装了没发现什么区别……第十四个，ViewInPlay好东西，在”最近任务栏“，”详细应用信息“里面添加一个按钮，可以直接跳转到当前应用的Play页面。第十五个，WiFiKeyView在你的wifi列表里面，长按一个wifi，会多出一个按钮，可以显示这个wifi的密码。第十六个，X状态栏农历日期在状态栏显示农历，作者是国人。酷安：第十七个，XToast调整你的Toast信息的风格、位置、颜色、是否显示图标、是否显示应用名称等等第十八个，Xposed Custom Error可以自定义应用崩溃、应用失去响应的文字提示信息第十九个，变色状态栏神器，让你的状态栏颜色和应用的顶部颜色一致。还可以自定义每个应用的颜色，不一致也没关系。第二十个，应用内谷歌地图纠偏解决国内应用内谷歌地图偏移的情况第二十一个，智能拨号-T9拼音让原生系统支持T9拨号第二十二个，绿色守护不讲，神器第二十三个，蓝牙解锁让你的设备可以接收任何格式的文件，不用再在传apk之前改文件名后缀了。—————————————————————————————————————其实还有很多，慢慢地感觉没必要用就删了。JayXon大大的应用集：经常逛逛Xposed框架安装器里面的下载部分，也有惊喜的发现。还有Xposed框架吧： 也经常有收货，不过经常碰到汉化不留原应用名和作者名的，有点看不惯。
分享几个我现在常用的吧。
o 去广告 MinMinGuard
o 权限管理 Xprivacy
o 禁止低电量自动关机 DisableCriticalBatteryShutdown //这个多数情况下还是蛮实用的
o 休眠省电 Greenify
o 开机自启管理 BootManager
o 下载instagram照片和视频 InstagramDownloader
o Mi-tools // 最大程度最小成本修改MIUI
Xdictionary 吧，对学英语的同学有帮助。只要长按想要翻译的单词，然后选择define，就可以立刻得出翻译(暂时只有英英翻译，估计不久就会出英汉的)，然后词典是离线词典。以下放截图。使用效果：软件界面：我现在使用的是第二种显示方式，第三方作者还没开发出来，估计后续版本或有。如果使用的是第一种方法，则会打开浏览器查询单词。～～～～～～～～～～～～～手机作答，排版不太好，见谅
GravityBoxGreenify
我手上用的是moto X，我就说一下我现在用的模块吧：app setting：用来取消某些软件全屏运行时无法沉浸导航栏（例如某些游戏和浏览器）boot manager：自启管理软件，不多说gravity box(KK)：很多非常多实用功能，但是不会像Xblast那样修改的面目全非，而且还是挺稳定的，强烈推荐grernify：绿色守护，Up知道了我就不细说了，切断路径休眠功能超好用minminguard：去广告软件，基本gms的都能去，一些内嵌太厉害的有几率不行，这点adblock做的不够minminguard好所以不推荐Xprivacy：超级强大的权限管理软件，比CM官方更强，但是设置有点复杂，建议如果不是中文的话用app setting转成中文再设置gesture navigation：又名手势导航，一个自定义各种快捷手势的模块以上都是平时常用的，强烈建议先安装试用最后再推荐几个好用的但非必须的模块：Xtoast：一个个性化设置toast的软件smartdial with T9 pinyin：原生T9拨号模块X statusbar lunar date：状态栏农历显示tinted status bar：又名状态栏变色龙，这个由于是有点污染代码（听说），而且有点bug，不知道支持别的好不好，但是我用来防止烧屏还是挺不错的再加一个，xuimod，用来改动画特效，效果不错以上，全部爪机手打，格式问题望见谅
tinted status bar 可以修改状态栏颜色 契合app的主色调 看起来舒服点我觉得
难道就没人推荐BlackList和 4.x Airplane Mode Helper么。。前者可以让4.4 也能够短信拦截，后者可以让4.2以后的版本自动开关飞行模式
升级Kitkat之后，不允许系统程序以外的apps随意访问外置SD卡的根目录，这样第三方文件管理器之类的都废了。解决方案是安装以下module：
AppSettings 可以解决aosp的相机禁止旋屏后不能旋屏的问题 修改一些DIP
GravityBox 自己探索吧 我用这个来禁止锁屏状态栏下拉并在状态栏添加网速显示
XuiMod可以更改特效什么的
1. XPrivacy，权限管理利器。摆脱“XX 手机助手”、LBE 之流的不二之选；2. Android Navigation Bar，在 Android 4.4 上直接实现 Android L 的虚拟按键效果；3. X 时钟文字扩展：系统时钟前缀、后缀、样式定制。我只用它的一个功能：时间居中显示；4. xSuite：任意修改 app 图标、重命名 app 的 icon label。
1. 强烈推荐原生拨号T9，是greenify的作者编写的。注意：激活重启后，还要要清除拨号软件的数据并重启，才有效。2. Gravity Box
必备佳品，综合多个rom的特点
目前使用的是：app settingswanam xposed绿色守护（付费版）
1：Xprivacy这个可以虚拟设备信息来欺骗app（灰常赞啊）2：SNC用它可以设置其他号码来欺骗app（又是欺骗）
GravityBox：浮动通知，解决全屏下消息通知一览（可设置透明度，可切掉）；去电接通震动；状态栏流量指示（无流量可自动隐藏）及月日显示；自定义电池风格；自定义虚拟键及实体键（我设置成长按返回键截图，长按音量减手电筒开关）；自定义导航环添加app；音量面板及各属性分别控制。绿色守护：切断连带唤醒路径，这个很实用。app settings：在禁止自动翻转下，对某些app强制横屏。
我也來提幾個：Shadowsocks VPN模式用戶可以使用VpnDialog Xposed Module，作用就是在連接shadowsocks時的確認對話框裡自動選擇信任。XPrivacy這個真的很讚，禁用某些app的權限的方式是模擬一個假的結果返回欺騙之。3455人阅读
真不想讨论这个问题。MVC，TDD一类，是被炒作过的概念，实际上已经具有了特殊性，并不能用普通的方式来验证它的正误。专家说它好未必真好，因为那是专家，有人说他好未必真好，因为可能已经被洗脑了。本来嘛，只要是个东西，就肯定有支持派和反对派，但是在炒作氛围内，反对派的声音是听不到的。
所以这种时候，能够相信的只有自己。
以下也是我个人的看法，同意或者不同意，悉听尊便。
什么是MVC？
不知道从什么时候起，这个问题变成了一个与“一万人眼里有一万个哈姆雷特” 类似的命题。可能是因为嘴仗太多而没有结果，最终妥协成了这个样子吧。MVC只是一个词，在这个词下可以涵盖各种意义，事到如今，谁知道它最初的意思是什么？按字面意思， MVC就是(Model View Controller)模型－视图－控制器，是一个设计模式（也可以称为架构模式），但目前在大部分人眼里显然并不只有这点意义。受到各种MVC框架的影响，消息通信，依赖注入，隔离编译等等概念现在都加入到了MVC的概念里，而且因为应用上的重叠和相似性，还常常和三层架构的概念混淆。
一个名词的意义，是由人们的理解来决定的。既然有那么多人认为必须发布消息，必须通过反射获取实例，模型修改必须更新到试图才能算MVC，那MVC就是这样的东西。但这样就几乎无法讨论了。因此这里我就返璞归真一下，从最基本的概念入手，或者还能稍微说出点名堂。
对于一个用于显示的程序，最开始，只有View（视图）。
我们要获得一个数据并显示，就是写段代码调用接口，获得数据，然后根据数据更新视图。而这里的数据只是一个临时变量，或者存在于视图的某个属性中。显然，这样做的话，数据是依赖于视图的，如果不通过视图，或者视图根本不存在的时候，其他模块就访问不到这个已经返回的数据，则需要重新调用一次，这显然是一种浪费，而且也不便利。因此我们在这里将数据保存到别处，和视图不共享同一生命周期，那么这分离出来的数据则被规定为Model（模型）
（在这里我必须打断说明下，模型!=数据，仅仅是在这个简化例子里模型==数据。模型是为视图提供内容的单独模块，具体内部是什么情况则是各种各样的，提供数据只是它的功能之一）
至此，就是最基本的分离表现层的原则。然而，有个地方却是分不开的——原来控制加载数据的这部分代码。它负责的是获取数据，并指示视图根据数据更新的任务，而它的去向有两个选择：要不加到视图上（这是通常的做法），要不加在模型上（如果需要模型对应多个视图），反正他不可能因为分离就凭空消失。那么我们把这部分代码提出来作为单独的部分，就是Controller（控制器）
一旦分离出了控制器，联系模型和视图的具体代码就不再处于两者之上（当然调用代码还是有的），而是一个独立的部分。它有自己的名字，而且不会和其他不相关的内容混合在一起，非常清晰，容易定位。而模型和视图从此也只关心控制器，而不关心对方。他们的代码都是处理自己的事情，别人的事情全部交给控制器去办，这使得他们自己的功能也非常独立，减少了需要考虑的要素。
这只是代码位置的移动，但是这样移动后，将牵涉内容最多最易变，但是代码量最少的代码单独放入控制器中，并妥善管理。相当与将分散在房间各处的开关集中于一处，排列整齐并标注名字，做成遥控器在手里把玩，从此就能从奔波于房间各个位置，寻找隐藏在角落里的小突起的日常活动中解放出来。其意义，不言而喻。
而这，作为MVC的作用，已经足够了。
一旦我们将视图，模型，控制器分离后，可以做到什么呢？
因为视图和模型都只用处理自己的事情，对控制器的调用只是一句代码而已，那么，它们实际上就可以被隔离出去。负责这部分代码的人只需要关心自己的事情，而不需要关心整个环境。同样的，编写控制器的人只需要知道视图和模型的对外接口，而不需要了解它们的具体实现，也就是只需要关心环境。这使得不同开发者需要的知识被分隔开，每人只需要了解有限的少量知识，最终却又能顺利合并在一起。
这是就是协作分工的基础。
在这之后，三者的关系只存在简单的调用代码。那么为了能够彻底的分离和解耦，就可以将调用代码改为发送消息或者其他的动态形式，这样就能在没有其他部分的时候独立编译。由不同人在不同的工作环境独立完成自己的部分，并在最后发布时候简单合并在一起，这确实是最理想的协作模式。
做到这点需要一个消息框架，而这就是MVC框架的主要任务。除此之外，各种不同的框架还会加入其它设计模式，提供各种附加功能，自动依赖注入就是其中一项。还可能加入其它的中间件，进一步分割层次，诸如分离出视图其中的逻辑部分，使得绘图和位置代码不会和逻辑代码混合，方便分工以及修改。使用观察者模式，使得数据部分的修改可以自动同步到视图上，如此这般……MVC框架指的是“实现MVC的框架”，而非“只实现MVC的框架”，仅仅实现MVC，这个框架的功能太过贫乏了，毕竟MVC也就是那种程度的东西。
最终，完成了这些之后，就成为了一般人表面看到的东西。虽然各式各样，我们都将其称之为“MVC框架”。
命名怎么都可以，实现的功能才是唯一重要的。
MVC并不是3-Tier（三层架构）
在这里必须插入做一个补充说明，如果不将MVC和三层架构的关系说清楚，后面将会产生大量误解。
这两个东西只是听起来各个部分的名字比较像而已，MVC是视图-控制器-模型，三层架构是表现-业务-数据访问，此外没有任何相似之处。实际上就是完全不同的两个东西。但是因为用了MVC的架构往往也实现了三层架构，所以不少人以为前者已经包含了后者，实际上完全没这回事。
我们可以认为，三层架构的逻辑层和数据层代表了MVC中的模型，也可以认为MVC架构是三层架构中的表现层部分。实际上，MVC一直都被称为表现层架构。
所以不要再把什么“表现层和业务层分离，容易更换服务端语言，数据库这类东西”放在MVC头上来了，尽管它听起来和“视图和模型分离，容易更换服务接口”差不多，实际上一点关系都没有。
不少flasher认为服务端已经用了框架，FLASH部分作为视图没有必要自己在内部重复实现一次MVC，也是基于这个误解。FLASH部分处于三层架构的表现层，而不是MVC中的视图。既然使用了FLASH替换了原本的HTML/JS部分，服务端原来的MVC部分的内容也自然也无法实现（被替换了），只剩下业务和数据访问层。因此这是完全不相冲的。
MVC属于表现层架构，而表现层的任务是将数据呈现出来，所有交互也都是为了呈现数据。虽说并不是只能呈现数据，但它的确是因此而生的。
MVC框架的优点与缺点
关于优点，上面也说了一些，基本上就是：
l 结构清晰，定位迅速
l 控制器可方便地插接
l 各部分皆可独立移植，替换
l 模块职责明确，利于工程化管理
l 容易进行单元测试
然后缺点都是这么说的：
l 较复杂，难实施
l 类多，代码多，工作量会增加
l 稍微有点慢
l 不利于整体调试
l 一般情况无法获得IDE的辅助
我对于通信框架的观点
关于这个，我稍微有点自己的想法，但是抱歉的是，说的是反面意见。毕竟MVC的正面观点已经被说到不用说的程度了，我也不想再复述一遍了。而这个意见，也是直指目前MVC最重要的一个部分——通信框架。
现在的MVC框架有一个共有的特征，一定会通过消息通信来解耦，使得三部分内容可以隔离开。这看起来很理想，但是实现解耦本身这个行为就是有成本的。现在的消息解耦都是通过添加共同的第三者来完成的，而现在这个第三者就是标示他们的字符串。而且，不同的框架，还会有各种不同的中间者，而这些中间环节越多，出错的几率自然也就越高，要知道，这些中间者都是编译期间（甚至运行期间）都不会产生错误的。而且缺乏IDE辅助，你在阅读别人代码，包括编写自己代码时都会有一定困难，由于调用关系复杂，在各个模块中转换多次跳转会浪费时间。而修改时，由于不会产生错误，也可能无意破坏模块之间的联系，另一方却毫不知情。
因此，需要更完善的制度来弥补这个缺陷，比如更加详细的文档，更严格的版本控制，更标准的开发流程。甚至于，最好严格执行单元测试，因为即使是修改时简单的拼写错误都会导致未知的问题发生。总之，需要开发者更多的精力，更多的开发成本，和它们相比，写的代码数量多点都是小事了。于是乎，MVC框架未必总是能提高开发效率。它的主要作用是使你的开发过程条理化清晰化，使多人开发时能更好的并行操作，避免因此大幅降低效率。但如果你不用它一样可以条理化清晰化，并行开发用SVN/GIT就能简单完成，那么使用它得到的好处就非常有限，成本提高将无法忽略。
所以才会说，MVC框架不适合小型项目乃至部分中型项目，因为他们即使不依赖MVC框架的这些特性依然可以做的很好，一样可以分割模块制定接口，即使有部分分工重叠，因为人数少，也可以用SVN进行妥善管理。
此外，还有很重要的一点：理想和现实是有距离的。如果你的开发人员都非常优秀，可以正确使用MVC框架，在适当的情况下，的确可以利用到它所带来的好处。但是如果不是这样呢？MVC框架一般都只提供了功能，而没有限制你使用功能。你同样可以将模型需要的逻辑写在视图里，将本该放在Command中的逻辑放在其他的地方，以及实现各种古怪的写法，然后机械地套用一遍框架，这样一来，不仅必须承担框架带来的不便，还一点好处都得不到。所以，必须对人员进行培训，对培训也没用的人进行筛选，这又是不小的一笔成本。
更糟糕的是，使用MVC框架的团队未必能够意识到这些。他们可能没有文档，不进行版本控制，没有制定开发流程，甚至，他们找来进行MVC方面培训的人，培训的内容是完全错误的。
MVC框架并不是平民可以玩的东西，它本来就是为大型项目设计的。对于大型项目，人员，制度，管理，流程，这些都不是问题，有问题的是项目规模大所导致的混乱。于是乎，上面说的缺点，都不再是缺点。
中小型项目，真不好说。
但是，如果MVC框架不实现消息通信，也就是不对三部分实现完全的解耦的话，那就是另一回事了，上面出现的问题其实主要都是通信框架的问题，而不是MVC本身分层的问题。不过，因为所有的MVC框架都实现了消息通信，所以，如果你想避免上面的问题，就只能自己开发MVC框架。而这也是现在很多游戏团队实际在做的。
FLASH与传统环境的不同点
MVC最早在1979年的时候第一次被人提出。不过，当时还不存在网络应用的概念。之后当万维网诞生之后，又过了很长时间……
它并不是自诞生就开始流行的，而改变的原因很简单——因为两个极其流行的开发框架包含了这种模式，它们就是：Struts 和 Ruby on Rails。之后，模仿者蜂拥而至。所以，在人们眼里看来，实际上是先有的Struts，然后才有的MVC，也无怪乎MVC的概念会始终沾染着Web概念，乃至和一些框架附加内容牵涉不清。
因为Struts很好用，别的不说，至少让HTML显得干净了很多。所以很多人都在用Struts，这未必是因为需要MVC模式，而是因为他们需要Struts。因此，当环境变化后，我们不使用Struts而是在使用一些其他的框架的时候，是否还应该像以前那样使用MVC框架就成为了一个问题。因为环境不同，即使在其他语言中使用MVC框架很普遍，也不代表在新环境里同样应该是如此。
AS3与传统语言的不同点：
l AS3是单一语言环境，多层代码混在一起问题没那么严重。
l AS3正常情况都是一次性编译全部代码，即使用了MVC框架还是需要一起编译。单独编译一个模块减少编译时间有别的办法，不需要依赖MVC。
l AS3本身的事件和动态特性和一些框架的功能重复。
l AS3目前的框架还很不成熟，没有提供比较醒目的功能。
结果是，至少，目前AS3的MVC框架比起传统语言并没有那么突出的作用，就算用了，也不会像Struts那样有质的变化。而且，至少在我看来，AS3的框架使用成本却不见得比Struts低。两者相减，结果就很麻烦了。
而且，AS3在不使用框架的时候有它自己的优势，使用框架会毁掉这些优点：
l 有一个相对还可以的调试器，使用了框架会在调试上产生麻烦，主要体现在单步调试步骤变多的问题上。
l 阻碍使用IDE的功能。以Flex Builder为例，你可以通过Ctrl+单击（F4）跳转到指定方法的具体实现，通过搜索引用面板从方法的实现跳转到调用方法的位置。使用框架后，这些功能都会失效。
l Flex framework相关功能会难以使用，诸如绑定。而且，Flex Builder支持拖拽式的将数据接口绑定到视图的功能，可以部分实现零代码编程，框架也会阻碍这个过程。
此外，企业应用和网站还好说，游戏还有另一种情况。游戏的结构并不同于原来的专门用于呈现数据的结构，可能也就是其中的用户界面(User Interface)部分和以前的结构比较类似，其他的诸如地图，诸如人物，无论怎么想也无法套用MVC框架，首先从效率上就说不过去。举个例子，一个项目有3个客户端人员在开发，一个在做地图，一个在做战斗，一个在做UI。前两者都和MVC没什么关系，结果只有一个人在用MVC框架开发界面……而且，开发前两者的时候，开发以及协作难度其实是比开发界面要高的，既然他们都搞定了，为什么开发界面的人还必须靠框架辅助才能解决这个问题？
当然，对于一些UI开发人员很多的团队，的确有那么点意义。但是在游戏开发团队里，这类人员的人数至少会比以往更低。如果其他人都是商量好接口并按功能模块分工，为什么UI就不可以呢？
这使得FLASH比起一般的情况，会更加不适合使用MVC框架。
是否使用框架应当理性对待
程序员都是理科生，应当用理科生的思考方式（当然我并没有让你们都去模仿Sheldon）。在使用MVC框架的过程中，不管是觉得好，还是差，都要考虑清楚问题的源头在哪。
觉得MVC框架不好用，降低效率，是否曾经有过平行对比的例子，你能否确认不用它效率就确实能提高？效率低有没有可能是框架之外的原因？
觉得MVC框架好用，提高效率，是否有平行对比的例子？你怎么就知道是使用了框架的功劳，而不是规范了代码结构，制定了新的协作流程，甚至是开发人员水平提高的功劳？怎么知道MVC框架并没有起了反效果？
使用了框架，看到了结果，然后根据结果的好话直接判定框架的好坏，这太武断了，作为一个理科生，我们绝对不能这样做。至于那类连比较都不进行，而是以“我用了框架，项目依然完成了，没有因为用了框架而失败”这种理由来支持使用某个框架的人，我无言以对。
不使用现有框架并非无法实现MVC
既然我在说框架不好用。那么不用框架，我们又该怎么做呢？
实际上，如果你只是想实现单纯的模型—视图—控制器(Model View Controller)分工职守，它只是一个架构模式而已。将模型和视图的代码分开，并提出控制器的代码，然后互相调用各自方法就算完事了。Model的全部引用放在固定的位置，或者单例，View的引用使用静态属性储存或者用管理类管理，Command可以作为函数或者类直接初始化并执行，亦可以通过反射。这并不需要专门的工具类来辅助，附加成本也比较小，自然就可以适用于任何规模的项目。
当然，你也可以实现一个简单的通信框架，提供必要的功能，如果你需要的话。
MVC是非常好的架构模式，不管什么样的项目都建议尝试使用，但是非要强调完全的解耦，一定要使用某个现有框架的话，请务必谨慎。
关于最简的，无视耦合的MVC，最近看到一个让人很囧的例子。不过这个例子对大家理解MVC的概念是有帮助的。
这玩意的确……基本算是MVC，只差一点而已。MVC是架构模式，至少结构上要分开，即使不分文件至少要让能看得出来谁是谁（原文可没有红字），所以只需要把这些代码分成三个文件，那就可以称得上是最简的MVC了。
这是我在他的下面补充的代码。
结果是，View只关心与自己相关的Model和Command，Command只关心与自己相关的View和Model，Model谁都不关心，这和一般情况的需求是一致的。虽然这样的确不能算解耦了……但是至少在思路和逻辑分离上是做到了，仅仅是协作方面存在问题，比如无法实现自由的并行开发，而这个加入简单的反射也可以解决。
所以，单纯的MVC并不困难，没什么要不要放弃一说。还有就是上面只是极端例子，但就算是这种东西，比起完全不实现MVC，也至少实现了50%以上的内容。
就算是使用MVC框架也不需要完全解耦
解耦是一个扩展性要求，但扩展性要求并不是越多越好的。
这是一个普遍的误区。诸如使用pureMVC的人，很多都纠结于完全的解耦，以至于用了Command，在Command中改变View的时候还是必须要发一遍Notification。
Command这种类，一般都是在相关的View，Model完成后才开始编写的。比如普通的StartupCommand，OpenWindowCommand，没有对象又如何编写？它在编写顺序上应该是，就算不是也是可以放在View和Model之后的。那么在协作关系上，他就可以直接访问所有相关类，不需要为了这种原因而解耦。
虽然pureMVC将消息全局化了，但是消息实际上是分局部和全局的。比如一个Proxy发生变化要求所有监听某个消息的View更新，那么当然应该发一个叫做I_AM_CHANGED的Notification，并由不同的View来监听这个消息并更新，这个就应该是全局消息。但有些消息就是局部的，是一对一的，比如一个叫做SEND_DATA_TO_WINDOW1的消息，按它的字面意思就应该是刷新WINDOW1，那么由它来触发的Command，就应该直接耦合WINDOW1这个View来设置值，而不是再发个类似REFRESH_WINDOW1的消息，因为SEND_DATA_TO_WINDOW1的名字已经确定是针对这个View了，如果最终它却没有操作这个View，那才是有问题的吧？
解耦归解耦，但是对于已经有了意义上的联系的模块，结果却不耦合，在任何时候都是没有意义的。即使需求变化，逻辑变化了，使得SEND_DATA_TO_WINDOW1最终不是改变WINDOW1的数据，而是WINDOW2的数据，那么这个Command连带相关Notification的名字就必须修改，也就是说，意义上的紧密联系，在实际操作上和耦合了是一回事。既然已经是这样了，再做成不耦合，给自己制造麻烦的又有什么意义呢？
除了上面的情况，我们也要考虑，真的有必要将项目拆得那么细致么，有没有必要为了1%以下的可能性来解耦两个相关性很强的部分？比如一个叫做ShopPanel的View和一个叫做ShopModel的Model，到底在什么情况下，ShopPanel会不去调用ShopModel，而是别的东西？而且Panel上可能还有各种文字，使得自己意义上只能调用商店的数据。真是要调别的东西，应该重新制作一个新的View吧？而且别忘了pureMVC是可以多个Mediator套用一个View的。这种情况下，我们直接在Mediator中耦合ShopModel，有什么不可以的？当然，反过来，ShopModel被多个View调用的情况很普遍，所以我们不能让它来耦合ShopPanel。
这些规则实际上是很明确的，是完全可以预知的。就算预知错误，也是很容易修正的。
解耦是手段，而不是目的。盲目的最求“无”耦合，只会让自己的程序变成一盘散沙。正是适量的耦合，程序才能拥有一个确定的形态，才不会变成史莱姆。
推荐MVC框架
我并没有完全反对使用MVC框架。这要看你的项目类型，规模，人数。满足条件的时候当然可以使用。尤其是在企业应用里，如果你有幸出现六个客户端的话，没有MVC框架可能还真是会出问题。
pureMVC和Cairngorm是两个较早出现的框架，目前我不建议再使用它们。pureMVC的问题在于过于强调分离而缺乏实际功能，提供的便利很难抵消它本身的消耗，性价比较低。Cairngorm的问题则在于过于强调模型更新视图的流程，限制太多，灵活程度不够。
后出的几个框架就好多了，Mate使用了一个全局事件定义，配合FLEX写法非常简略。Swiz则是用控制反转+依赖注入，也就是Spring的做法，而且元标签注入的方式很有趣，感兴趣的可自行查阅资料。
我这里要说的是Robotlegs。这是一个和Swiz非常相似的框架，但也有一些自己的特点。首先它是基于pureMVC的，你依然可以像pureMVC这样来使用它，对于相信pureMVC的团队它是很容易接受的代替品。他让pureMVC也同样拥有了控制反转和依赖注入，包装了大部分功能，配置代码大大减少，而且不管用不用FLEX framework都可以很自然地使用它。
Robotlegs的教程可以看这里：
/view/42a08b409c60.html
但我得提醒大家，虽然我觉得Robotlegs很便利以及有趣，但是并没有在项目里使用它，因为我的项目规模不大，而且是游戏。实际上，我甚至自己实现了一个依赖注入框架，可以很简单的加入到现在的项目中，成本几乎为零，却依然没有去用。使用一个东西要看是否需要去用，而不是可以用就用，更不是“因为用了没有遇到问题所以就用”。用一个东西必须有收益才可以，尤其是在明明看到有损失的时候。仅仅是用“看起来更正规”这类自我满足的理由来决定自己的行为，太愚蠢了。
当然，如果你需要它，那就应该毫不犹豫的使用。不要受到抱怨框架的人影响，他们大部分都有自己的问题，提出的理由也未必是正确的，你并不一定会赴他们后尘——前提是你真的需要它，而且，要将使用框架需要的条件全部补齐。
其实现在使用框架的人群里，真的能够发挥框架长处的确实比较少，尤其是在水平层次较低的Action Script开发人员之中。一方面，这污染了框架的名声，同时也是不建议使用框架的理由之一，因为人员水平限制也是实际项目中不可回避的现实问题。
如果你决定使用MVC框架，就必须提高自己的认识。我拣几个最常见的问题来说吧。
l 并不是用了消息通信就算用了MVC
消息通信只是一个手段，只使用框架的通信功能在View之间发送消息的话，而将其他功能全部抛弃的话，直接使用事件更好，那还套一个MVC框架就是在没事找事了。
MVC关键还是在于代码逻辑的分配，通信只是个附赠品而已。要了附赠品而扔了原来的商品——咱们买的不是小浣熊干脆面，对吧。
但是如果你的目的就是赠品，其实也没什么。比如你就是想用的这个通信框架来发发消息，就不打算用它的MVC，又或者MVC部分是自己实现的。那么我还是建议你把消息部分干脆也自己实现了，别人的始终没有自己的好。
l 既然用了MVC框架，就不要图省事
要清楚，松散耦合不仅仅是一个形式，目的在于减少模块间的联系。因此，如果你一方面在解除两个模块之间的耦合，一方面自己又没头没脑的将其他模块的内容耦合进来，就会使得你的行为变得没有意义。
现在一些人一方面在硬套框架，一方面又图省事而随意引入其他类，就属于这样的行为。那些类是可以引入，但你这样做，框架本身的意义就没有了。要不你就不用框架，要不就别这样干，这里只能二选一。
l 是Mediator知道View的一切，View完全不知道Mediator，而不是相反
对于使用pureMVC的同僚们，我真是不明白你们到底是怎么把这个反过来理解成“View知道Mediator的一切，而Mediator完全不知道View”的，因为官方实例上写的很明白。估计是把mediator当成通信专用的模块类了吧。但是如果你放弃了mediator分离View代码的特性，只是用来通信的话，至少要保留原来的通信功能，就是让Mediator依然可以直接访问View。否则既然Mediator是用来通信的，它却不能操作View，结果还得设法和View再通信一次……
pureMVC要求“View完全不知道Mediator”是为了能够在不修改View的情况下更换Mediator，但这种需求并不多（多的是在Mediator不变的情况更换View，这个需要用接口或者条件判断解决），所以可以放宽点让他们互相引用，这样两者通信都能畅通。
pureMVC实现“View完全不知道Mediator”的方法是用Mediator直接去监听View的某个组件的鼠标事件。这只需要监听一次，也不需要传递消息。Mediator存在的期间，按pureMVC的标准View应该是没有任何与通信相关的，也就是会向外的逻辑的。
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：458727次
积分：8178
积分：8178
排名：第688名
原创：327篇
转载：44篇
评论：252条
(5)(1)(1)(1)(1)(8)(5)(3)(7)(4)(1)(1)(3)(12)(1)(21)(10)(4)(7)(1)(1)(1)(2)(6)(14)(17)(14)(2)(31)(7)(15)(8)(5)(5)(1)(4)(33)(36)(23)(50)