第1章　重构，夜未眠

1.1，重新规划Android项目结构

• Activity：存放与业务无关的Activity基类
• BaseActivity封装的是业务无关的公用逻辑
• AppBaseActivity封装的是业余相关的公用逻辑
• net：存放的网络底层封装
• cache：存放的是缓存数据和图片的相关处理
• ui：存放的是自定义控件
• utils：存放的是何种与业务无法的公用方法
• activity：我们按照模块继续拆分，将不同模块的activity划分到不同的包下。
• adapter：所有适配器都放到一起
• entity：将所有的实体都放在一起
• db：SQLLite相关逻辑封装
• engine：将业务相关的类都放在一起
• ui：将自定义控件都放在这个包中
• utils：将所有公共方法都放在这里
• interfaces：真正意义上的接口，命名以 I 作为开头
• listener：基于Listener的接口，命名以On作为开头。

1.2，为Activity定义新的生命周期

同时这三个子方法,要声明为 abstract 的,从而要求所有子类必须实现这三个方法：

• initVariables：初始化变量，包括Intent带的数据和Activ-ity内的变量。
• initViews：加载layout布局文件，初始化控件，为控件挂上事件方法。
• loadData：调用MobileAPI获取数据。

1.3　统一事件编程模型

第一种用法：（不推荐）

使用switch…case…语句来对R.id.btnNext中的值进行判断，我不希望R这个在程序中反复出现，这会扰乱面向对象编程的风格，按照我的设想，我们在initViews方法中一次性把所有的控件都初始化了，今后就再也不会使用R.id了。

第二种用法：（推荐）

Button btnLogin=(Button)findViewById(R.id.sign_in_button);
btnLogin.setOnClickListener(    
    new View.OnClickListener() {        
         @Override        
         public void onClick(View v) {            
            gotoLoginActivity();       
        }   
    })；

这是我比较推崇的方式，有以下两个优点：

1. 直接在btnLogin这个按钮对象上增加点击事件，是面向对象的写法。
2. 将onClick方面的实现，封装成一个gotoLoginActivity方法，如下所示：

private void gotoLoginActivity()  {    
        Intent intent = new Intent(LoginNewActivity.this, 
        startActivity(intent);
}

这样onClick事件方法就不那么臃肿了。设想当我们在initViews方法中声明了10个按钮对象，并都给它们挂上不同的点击方法，那么initViews方法该有多少行代码呢？我写过上千行的，直接感受就是initViews方法很难维护。但是我们把这些点击方法都分别封装到私有方法中，代码就清晰多了。但是，只要在一个团队内部达成了协议，决定使用某种事件编程方式，所有开发人员就要按照同样的方式编写代码。我认为这是没错的。只要不是各有各的编码风格就好。

1.4　JSON解析

1. 推荐使用FastJson进行实体化编程：

JSON.parseObject(content, T.class);

这里说一件非常狗血的事情，就是在我们使用fastJSON后，App四处起火，主要表现为：

1. 加了符号Annotation的实体属性，一使用就崩溃。
2. 当有泛型属性时，一使用就崩溃。

在调试的时候没事，可是每次打签名混淆包，就会出现上述问题。我们几个开发人员曾经查到晚上十点半，最后才发现是混淆文件缺了以下两行代码导致的：

-keepattributes Signature            　// 避免混淆泛型
-keepattributes *Annotation*          // 不混淆注解

2， 在页面跳转中使用实体

• intent传递，序列化传递对象（推荐）
• 全局变量（不推荐，容易存在被系统杀死的情况）

1.5　Adapter模板

public class CinemaAdapter extends BaseAdapter {
        private final ArrayList<CinemaBean> cinemaList;
        private final AppBaseActivity context;

        public CinemaAdapter(ArrayList<CinemaBean> cinemaList,
                             AppBaseActivity context) {
            this.cinemaList = cinemaList;
            this.context = context;
        }

        public int getCount() {
            return cinemaList.size();
        }

        public CinemaBean getItem(final int position) {
            return cinemaList.get(position);
        }

        public long getItemId(final int position) {
            return position;
        }
    }

对于每个自定义的Adapter，都要实现以下4个方法：

• getCount()
• getItem()
• getItemId()
• getView()

此外，还要内置一个Holder嵌套类，用于存放ListView中每一行中的控件。ViewHolder的存在，可以避免频繁创建同一个列表项，从而极大地节省内存，如下所示：

class Holder {    
    TextView tvCinemaName;    
    TextView tvCinemaId;
}

1.6　类型安全转换函数

public final static int convertToInt(Object value, int defaultValue) {
        if (value == null || "".equals(value.toString().trim())) {
            return defaultValue;
        } try {
            return Integer.valueOf(value.toString());
        } catch (Exception e) {
            try {
                return Double.valueOf(value.toString()).intValue();
            } catch (Exception e1) {
                return defaultValue;
            }
        }
    }

我们将这个方法放到Utils类下面，每当要把一个Object对象转换成整型时，都使用该方法，就不会崩溃了：

int result = Utils.convertToInt(obj, 0);

本章小结

• 本章介绍的内容都是为后面的章节打基础。有了AndroidLib这个业务无关的类库，我们将在接下来的章节中封装更多的公用逻辑，比如第2章介绍的网络底层封装，以及第9章介绍的模块化拆分和插件化编程。实体化编程将极大提升代码可读性，从而进一步提高开发效率。而实体生成器的出现，将是解决重复劳动的一大利器。为Activity定义新的生命周期，把onCreate方法中的几百行代码拆分为3个具有不同功用的子方法，也是提升代码可读性的一个手段。
• 相比后面的章节，本章更多内容是写代码的方法，如果整本书都是这个内容，那就没意思了。接下来的各章，我将详细介绍移动App开发领域的常见问题以及解决问题的思路或方法。