Question

先把 app 常用的功能进行抽象，主要从 Activity Fragment Service 等控件进行考虑。

其次完善相关的工具类。主要从代码封装、迭代、可维护性等方面考虑。

抽象

Activity 的抽象

Activity 抽象主要目的是简化具体功能界面的工作量。主要通过代码封装的方式来达到效果。

同时需要处理网络请求、UI 刷新等操作

Fragment 的抽象

Fragment 的抽象与 activity 类似。但不同的是需要处理多个 Fragment 之间的互相调用，传参方式也不太一样。

工具类

App 需要一个管理 Activity 或者 Fragment 的工具类，对其做全局的操作（方法调用) 为了减少代码的耦合度。不建议在 Activity 中直接加 static 引用。可以通过写一些工具类间接的实现。

Activity 中访问网络请求以及回调刷新 UI 是一件比较繁琐的事儿。常规的做法是 new 一个 Thread 是传入一个 Handler 对象，网络请求完成以后 sendMessage 刷新。但是这种做法耦合度比较强，而且好多业务逻辑都需要在 Activity 中处理，代码臃肿

private Handler handler;

protected void onCreate(BundlesavedInstanceState){
     super.onCreate(savedInstanceState);
     handler= new handler(){
           publicvoid handlerMessage(){
              if(msg.what== 1){
                   //do sth
              }
           }
     }
}

public class NetRunnable implementsRunnable{
     privateHandler handler;
     publicNetRunnable(Handler handler){
           this.handler= handler;
     }
     publicvoid run(){
           //do sth 处理网络等
           Messagemsg = Message.obtain();
           msg.what= 1;
           msg.obj= “网络请求结果”;
           this.handler.sendMessage(msg);
     }
}

建议将网络请求的代码封装一下，封装后续

ActivityMgr

这个类的作用主要是保存 app 中所有正在运行的 Activity 的引用。

private static Stack<BaseActivity>activities = new Stack<BaseActivity >;
public static void push(BaseActivityactivity){
     activities.push(activity);
}

public static void remove(BaseActivityactivity){
     activities.remove(activity);
}

public class BaseActivity extends Activity

public void onCreate(BundlesaveInstanceState){
     ActivityMgr.push(this);
}

public void onDestroy(){
     ActivityMgr.remove(this);
}

解析一下为什么 onDestroy 的时候采用 remove 方法而不是 pop()

防止 acitivty AB, A 启动 B 如果此时 A#finish 调用 Stack#pop 则会把 B 的引用移除

Fragment 的工具类先略过