@(反编译)
instant running的影响
如果你猴急，那么可以直接看结论:
xposed只能hook住本来就已经存在在apk中的代码，简单来说，如果你的apk是采用动态加载的话，那么xposed是不能hook住动态加载的代码的，所以采用instant running方式安装的xposed插件在Android L上可能不生效，要解决这个问题，只能打包一个完整的apk进行安装或者关闭instant running。
某天，在我给几台手机装上xposed的插件的时候，前几台都没有问题，在最后一台小米6.0上却出现了插件不能正常工作的问题，一台之前还能好好工作的手机，突然不能正常运行了，别逗我，我今天有准时上班的。
首先，我就开始怀疑插件出现bug了，但是经过其他几台能正常工作的手机的测试，插件是没有问题的。
然后，我就开始怀疑是xposed框架的问题了，要知道xposed在Android Lollipop之后是很容易出现问题，其次，这是一台小米手机，官方的xposed framework好像不支持还是怎么样（具体的我忘记了），后来还是在这里找到据说是一个支持小米Android L以上的framework，于是我就怀疑是xposed的这个framework出现问题了，然后重新一次卸载框架，重新安装，结果还是不行，然后在这个框架下安装旧版的插件，是可行的，所以也不是xposed 的framework的问题
到这里，总结一下，其他几台Android 4.x版本的手机都可以（包括万恶的华为），然后小米Android 6.x不行？别逗我，当时也是花了半天找适配小米4的recovery和适合小米4 android 6.0.1 的xposed framework，难道就跪在这里？
好吧，今天确实迟到一点点。。。。。。
然后，最后睡了一个午觉，醒来突然间就想到会不会是instant running的影响呢？最近好像确实是升级到2.x的AndroiStudio，想来应该就是了，intant running是针对android 5.0以上，完全符合所有条件，接着重新用打包一个完成的apk包， adb install xxx.apk搞掂了。
故事就到此结束了，是不是觉得有点抑扬顿挫的感觉呢？
没有？你仔细看看？还是没有？
好吧，确实是没有!!
到结局之前都是好好的，为什么突然就想到了instant running，为什么突然就解决了问题，为什么前面说了得和结尾解决问题的方案一点铺垫的意思都没有，别问我为什么，你看2016年4月番的动画，后期的剧情都开始神TM转折了(连黑马RE到11集之后，剧情直转下降）
扯远了。。。
xposed只能hook住本来就已经存在在apk中的代码，简单来说，如果你的apk是采用动态加载的话，那么xposed是不能hook住动态加载的代码的，所以采用instant running方式安装的xposed插件在Android L上可能不生效。要解决这个问题，只能打包一个完整的apk进行安装或者关闭instant running。
xposed相关类的处理
xposed的实际代码其实在我们正确安装好xposed框架的时候，就需要我们导入xposed的源码到系统中，然后我们开发的时候，仅仅是使用provided的方式导入仅仅只有api方法，但是实际没有任何实现的jar or aar
provided 'de.robv.android.xposed:api:81'
provided 'de.robv.android.xposed:api:81:sources'
这种方式下的导入就等价于我们编译时是用到xposed的部分方法的，但是实际我们打包app的时候，xposed这些对外的方法/类/接口等是不会打包进apk里面的，于是假设你的MainActivity的onCreate中就已经使用了xposed的方法，那么可能就会引发用户一打开app就会崩溃的问题，因为app根本就没有这个方法
所以在开发xposed插件的时候，正常从桌面打开app的时候，绝对不能有操作到xposed相关的方法/类等的地方，xposed相关的方法/类应该写在xposed入口之后才能到达的类中。app和你的xposed相关的代码最好是通过文件交互进行控制，比如，你的app中存在一个是否模拟imei的单选开关，那么你应该在用户点击了这个开关之后，将结果保存到文件中，然后xposed的初始化入口中读取文件中的这个结果。
关于SharePreference的使用
正如上面所说，要让我们的用户能通过我们的app控制我们的xposed插件（比如是否开启这个xposed插件的功能），那么我们一般是通过文件这个中介，正常的app代码将用户的期望操作保存到文件中，然后我们的xposed代码入口中，读取里面的内容进而判断接下来要hook什么之类的。
而一般情况下，我们第一时间想到的可能就是用SharePreference做这个文件中介。
正常android使用SharePreference的时候，基本需要携带上下文context，比如下面代码：
SharedPreferences sp = context.getApplicationContext().getSharedPreferences("123", Context.MODE_WORLD_READABLE);
而在xposed中，要获取自己的app的上下文context的我这边试了网上几种方法都不太行（如果你们知道，希望留言解答下），而xposed中本身存在一个类XSharedPreferences，专门用来读取自身应用的SharePreference，可以免context
XSharedPreferences xsp = new XSharedPreferences(BuildConfig.APPLICATION_ID, "123");
// 令文件全局可读
xsp.makeWorldReadable();
到这里，估计就可以结束正常app和xposed关于SharePreference的使用过程。
But
你可能注意到在app中使用sp的时候，我们指定的权限是Context.MODE_WORLD_READABLE了，即其他app也可以读取到这个文件
为什么不指定Context.MODE_PRIVATE呢？说到底，其实也是我们自己的插件app在使用，应该可以用Context.MODE_PRIVATE吧。
如果你的app指定了以Context.MODE_PRIVATE模式进行修改/读取sp文件的话，那么在你进行完这个读取或者修改之后，xposed框架中是没法继续读取到修改后的sp文件的。
因此android原生自带的AppCompatPreferenceActivity，PreferenceFragment这套快速设置界面是用不到的，因为默认是使用Context.MODE_PRIVATE模式的。
除非你的app的设计为：用户在设置界面修改了之后，需要重启才能生效这么操蛋的设计咯（比如：XPrivacy）
