背景

从暑假就对默认加载的那些plugin模块非常好奇，开发蓝牙模块的学弟也做过一些研究，还没找到答案就被另外一个组的老师调走了，于是这个问题就搁置下来了。近期重拾蓝牙模块，这个问题再次开始困扰我。

研究过程

上周就尝试了一下，我的方案是从最初的文件新建出发，一步步把过程挖掘出来。首先前端的请求指向了CreateResource.java，在这个类中首先根据参数判断文件是否存在，如果不存在就实例化一个IVResource的对象，对象调用了createNewInstance方法，单从命名上来看过程还是很清楚的，只要弄明白createNewInstance的过程就行了。然而事实并没有这么简单，IVResource是一个接口类，光它的实现就有三个，而且每个实现中都有createNewInstance方法，这下就完全凌乱了。我耐着性子把每个实现都浏览了一遍，发现其中包含了各种不知名类的实例化和奇葩常量的调用，完全摸不着头脑，这条路基本是走不通了。

放弃了这部分，干脆全力突击蓝牙模块。由于之前cordova版本太老导致各种不明错误，于是全面抛弃老版本的文件目录，更换为新版本的目录和插件添加方案，结果顺利调通了蓝牙模块的各个功能。

由于明天就要开会，新功能暂时没有考虑好，就琢磨着默认加载的问题。新建一个文件观察代码，发现并不是所有的插件都被加载进来，只有UDPPlugin。使出了全局搜索大法，结果啥都没搜出来。这个plugin到底做了什么可以如此的与众不同？再次打开chrome观察前端的AJAX请求，发现在CreateResource请求后面还有一个GetPluginRequires的请求，这个请求我还是研究过几次的，打开后浏览，终于在GetRequire方法里面发现了一个requires.txt文件，直觉告诉我就他了。直接进windows文件浏览器搜索，果然在用户目录里找到了（怪不得在项目目录里全局搜索找不到），里面整齐的写了一排模块的名字和url，而且只有UDPPlugin写进去了，修改后重启，成功。

结论和教训

加载plugin和新建工程是两个请求完成的，我一直以为是一个请求，造成忽略了第二个的结果，走了不少弯路。这样看来，组织依赖文件的信息是在后端，但生成最终文件是在前端，具体过程有待考察。

注释大法好，文档大法好，如果前辈吧requires.txt这条写进文档估计也不会绕这么一大圈了，学长的一个笔记就够我们吃老本到现在。以后还是要多多总结，不仅对自己好对学弟学妹们也好。