效果图如下：
以下适当的修改就可以使用
package net.ossrs.yasea.demo.Activity.Uitls;
import android.app.Activity;
import android.content.Context;
import android.content.ContextWrapper;
import android.graphics.Rect;
import android.graphics.drawable.Drawable;
import android.widget.RadioButton;
public class RadioButtonUtil
{
private RadioButton[]rb;
private Drawable[]drawables;
/**
* 图片要缩小的比例molecule:Denominator
* @param rbid
* @param context
* @param molecule
* @param Denominator
*/
public RadioButtonUtil(int[] rbid, Context context,int molecule,int Denominator)
{
//定义RadioButton数组用来装RadioButton，改变drawableTop大小
rb =new RadioButton[rbid.length];
//将RadioButton装进数组中
for (int i=0;i
{
int rb_id=rbid[i];
// View view=LayoutInflater.from(context).inflate(viewId,null);
try {
rb[i] = (RadioButton)getActivity(context).findViewById(rb_id);
}catch (Exception e) {
e.printStackTrace();
}
}
//for循环对每一个RadioButton图片进行缩放
for (int i =0; i
{
//挨着给每个RadioButton加入drawable限制边距以控制显示大小
drawables =rb[i].getCompoundDrawables();
//获取drawables
Rect r =new Rect(0,0,drawables[1].getMinimumWidth() * molecule / Denominator,
drawables[1].getMinimumHeight() * molecule / Denominator);
//定义一个Rect边界
drawables[1].setBounds(r);
//给每一个RadioButton设置图片大小
rb[i].setCompoundDrawables(null,drawables[1],null,null);
}
}
private Activity getActivity(Context context)throws Exception {
while (!(contextinstanceof Activity) && contextinstanceof ContextWrapper) {
context = ((ContextWrapper) context).getBaseContext();
}
if (contextinstanceof Activity)
{
return (Activity) context;
}
throw new Exception("Unable to get Activity.");
}
}
传入四个参数：/**
* 图片要缩小的比例molecule:Denominator
* @param rbid
* @param context
* @param molecule
* @param Denominator
*/
这些注释里叫的也相对明白。所以就不多解释了，context转activity涉及到的东西蛮多的。
Android应用模型是基于组件的应用设计模式，组件的运行要有一个完整的Android工程环境，在
这个环境下，Activity、Service等系统组件才能够正常工作，而这些组件并不能采用普通的Java对象
创建方式，new一下就能创建实例了，而是要有它们各自的上下文环境，也就是我们的Context。
源码中的注释是这么来解释Context的：Context提供了关于应用环境全局信息的接口。它是一个抽象类，
它的执行被Android系统所提供。它允许获取以应用为特征的资源和类型，是一个统领一些资源（应用程序环境变量等）
的上下文。就是说，它描述一个应用程序环境的信息（即上下文）；是一个抽象类，
Android提供了该抽象类的具体实现类；通过它我们可以获取应用程序的资源和类
（包括应用级别操作，如启动Activity，发广播，接受Intent等）。
Context类本身是一个纯abstract类，它有两个具体的实现子类：ContextImpl和ContextWrapper
一个负责实现一个负责包装
Activity，Application，Service虽都继承自ContextWrapper
（Activity继承自ContextWrapper的子类ContextThemeWrapper），
但它们初始化的过程中都会创建ContextImpl对象，由ContextImpl实现Context中的方法。
在应用程序中Context的具体实现子类就是：Activity，Service，Application。那么Context数量=Activity数量+Service数量+1。
当然如果你足够细心，可能会有疑问：我们常说四大组件，这里怎么只有Activity，Service持有Context，那Broadcast Receiver，
Content Provider呢？Broadcast Receiver，Content Provider并不是Context的子类，他们所持有的Context都是其他地方传过去的，
所以并不计入Context总数。上面的关系图也从另外一个侧面告诉我们Context类在整个Android系统中的地位是多么的崇高，
因为很显然Activity，Service，Application都是其子类，其地位和作用不言而喻。爸比一样的存在！
因此在绝大多数场景下，Activity、Service和Application这三种类型的Context都是可以通用的。
不过有几种场景比较特殊，比如启动Activity，还有弹出Dialog。
通常我们想要获取Context对象，主要有以下四种方法
1：View.getContext,返回当前View对象的Context对象，通常是当前正在展示的Activity对象。
2：Activity.getApplicationContext,获取当前Activity所在的(应用)进程的Context对象，通常我们使用Context对象时，要优先考虑这个全局的进程Context。
3：ContextWrapper.getBaseContext():用来获取一个ContextWrapper进行装饰之前的Context，可以使用这个方法，这个方法在实际开发中使用并不多，也不建议使用。
4：Activity.this 返回当前的Activity实例，如果是UI控件需要使用Activity作为Context对象，但是默认的Toast实际上使用ApplicationContext也可以。
上面说到获取当前Application对象用getApplicationContext，不知道你有没有联想到getApplication()，这两个方法有什么区别？相信这个问题会难倒不少开发者。
Application本身就是一个Context，所以这里获取getApplicationContext()得到的结果就是Application本身的实例。那么问题来了，
既然这两个方法得到的结果都是相同的，那么Android为什么要提供两个功能重复的方法呢？实际上这两个方法在作用域上有比较大的区别。
getApplication()方法的语义性非常强，一看就知道是用来获取Application实例的，但是这个方法只有在Activity和Service中才能调用的到。
那么也许在绝大多数情况下我们都是在Activity或者Service中使用Application的，但是如果在一些其它的场景，
比如BroadcastReceiver中也想获得Application的实例，这时就可以借助getApplicationContext()方法了。
但Context并不能随便乱用，用的不好有可能会引起内存泄露的问题
1：当Application的Context能搞定的情况下，并且生命周期长的对象，优先使用Application的Context。
2：不要让生命周期长于Activity的对象持有到Activity的引用。
3：尽量不要在Activity中使用非静态内部类，因为非静态内部类会隐式持有外部类实例的引用，如果使用静态内部类，将外部实例引用作为弱引用持有
总之Context在Android系统中的地位很重要，它几乎无所不能，但它也不是你想用就能随便用的，谨防使用不当引起的内存问题。
（总结：使用前需要清楚应用的对象的生命周期，否则就才采用 软引用 SoftReference，弱引用 WeakReference，虚引用 PhantomReference，这种·可以被GC掉引用）
