Android 开发
Android
Android 工程师

在Android开发过程中搭建一个自己的应用框架有几个步骤？需要注意什么？

如:对application/baseactivity，图片加载，数据库等进行分析，谢谢
关注者
1,371
被浏览
61,899

9 个回答

每个人对应用框架的理解不相同，但是最终达到的效果应该是一样：

  • 降低项目的复杂性
  • 易扩展、易修改、可重用性强、可维护性强
  • 职责单一，功能清晰

在android开发项目中，我们首先要考虑的是这个项目或者说这个产品的核心功能是什么。比如，图片处理和展示类app,我们更多考虑对大量图片的处理，防止OOM等等；如果是理财营销类软件，比如微众银行、同花顺这种大量采用H5页面的app,考虑需要对webview控件优化和Js交互框架的搭建；总之，框架是为了便于业务的展开，是为业务而服务的，框架的选择是和业务需求紧密相连的。

那么有没有一些通用的东西可以抽取呢？从自己的一些实践经验来回答题主的一些问题，权当抛砖引玉。

  1. 项目工程搭建
App工程结构搭建：几种常见Android代码架构分析

总结了一些关于项目工程搭建的范例。我们在搭建工程结构的时候可以尽量抽取一些共用的东西，例如，数据库操作、base、task、事件观察者、通用的工具类、UI公共组件等等，这些东西应该表现在代码结构中。

这些包名的作用一目了然，在别人接手这个项目的时候就会相对简单。

  • adapter 适配器，如果业务复杂，根据不同的业务可以添加子包来进行分类；
  • base 用来存放View的基类，例如BaseAcitivity、BaseFragment，甚至可以添加某些不同actionbar主题的Base类；
  • common 当然是存放一些共用的配置类信息，常量等等；
  • controller 控制器，将一部分的业务类需求放到里面，充当db和View交互的中间层，减少Activity中业务的复杂性；
  • db数据库类
  • event 观察者模式，事件通知；
  • task一些AsyncTask任务类
  • view一些自定义组件
  • vo 值对象，其实就是给各个组件使用的对象，比如ListView的Item对象等等
  • widget UI界面
  • AppContext 自定义Application类

另外，根据自己的一些业务需求，我们可能需要单独的抽取一些核心的包类。比如，理财类软件在搭建工程结构的时候，可以单独抽出了2个JS相关的核心包类：

2.AppContext 的处理

Application本身在一个应用中只会存在一个实例，所以它一般用来存储一些全局的变量和一些只需要处理一次的数据。

  • context的管理。这个和BaseActivity组合使用，将每一个Activity放到一个列表中，需要的时候直接使用即可；
  • 初始化和记录一些app信息，例如app的版本信息、设备信息等等；
  • 初始化特定的业务需求，例如有盟统计类、分享SDK、推送等等
  • 记录应用启动次数、是否第一次安装等等，如果在第一个版本不加，到后面版本使用次记录会很麻烦（血泪教训……）
  • 记录是否开启处于调试模式。

在输出日志、错误消息的时候有用。

 public final static boolean DEBUG=BuildConfig.DEBUG;

3.Base的处理

对BaseActivity的处理好坏一定程度上会影响项目的代码可读性，在Base里面做一些规范化处理将会大大减少代码的书写量和提高可读性。

  • 将其Base类定义成抽象类，增加一些抽象方法，例如findView的处理、onClick的处理、初始化数据的处理。例如可以重载setContentView方法来规范子类的行为：
    @Override
    public void setContentView(int layoutResID) {
        super.setContentView(layoutResID);
        findView();
        initView();
        setOnClick();
    }
   /**
     * 获取布局控件
     */
    protected abstract void findView();

    /**
     * 初始化View的一些数据
     */
    protected abstract void initView();

    /**
     * 设置点击监听
     */
    protected abstract void setOnClick();

通过这种规范可以大大减少后期代码的混乱，onCreat方法中存在大量杂乱无章的代码;

4.数据库的处理

个人建议在处理数据库的时候采用ContentProvider的方式，有2个优点：

  • 采用URI的方式访问，更加符合我们的使用习惯；
  • 随时可以提供给其它应用访问数据库；

5.图片的处理

对图片处理的文章很多，其实你只要把基本的一些开源框架原理搞清楚，对普通应用其实足够了。

最近在做一个开源项目

daliyan/MyBlog · GitHub

需要的可以参考参考，期待大牛的回答。

这几天没事在找一些比较酷炫的效果，毕竟App也要看脸=_=,就放几个绝对干货吧。

material icon lib:

code-mc/material-icon-lib · GitHub

,可不是官方图标集合哦，库简介：Library containing over 1000 material vector icons that can be easily used as Drawable or as a standalone View.

List of Android UI/UX Libraries：

wasabeef/awesome-android-ui · GitHub

，反正我见没见过，做没做过的效果全在这儿看到了，精美可用的loading anim,图表控件，特效什么的全收集了。

尽情使用吧！

---------------------原答案-----------------------------------------

回答的好少啊，我先抛砖引玉一下吧。

Application,BaseActivity这个没什么好说的，但是一定要熟练，太常用了。

想快速写App:

继承Application类（存放全局数据，注意同步，一些SDK也要求在这初始化）

+创建BaseActivity（做好页面的缓存策略，别对Bundle savedInstanceState视而不见）

+Volley（网络通信）

+Fresco（图片加载）

+ORMLite（ORM,不多说）

+EventBus(为了解耦)

1、在搭自己的框架之前，你需要熟练应用别人的框架。用多了别人的框架，自己再写的时候，就可以想怎么做可能像别人的那样易用。

2、设计模式的熟练应用，为了自己好写（易拓展），别人好用（易定制）。

  • 单例模式进行初始化，防止资源泄露。

像IM类、音视频通信类、通用的网络请求等框架，都需要全局的一个初始化，一般涉及到后台的 一个独立进程或线程。举一个具体的栗子,Volley的使用： 

mRequestQueue =  Volley.newRequestQueue(this);

一个典型的单例模式，我们看一下Volley的源码，它的里面确实不像一般的单利模式写法：

注意到一个queue.start();//请求队列的start

跟进去：

一个stop(),是不是算一个单例啊？

不用猜了，下面的那些调用start()方法的实例全是线程实例。

  • 抽象工厂模式进行最外层的包装，主要照顾老用户。

在框架升级时，增添一个新的FactoryMethod就可以了，API接口基本不许变动。

比如，我要做一个音视频处理工具，原来只有音频处理能力：

AudioVideoProcessor audioProcessor = AudioVideoProcessorFactory.CreateAudioProcessor();//抽象工厂创建
audioProcessor.openFile(...);//打开文件
audioProcessor.encode(EncodeEnginer encoderEnginer);//调用编码器
audioProcessor.sendRtpStream(...);//发送Rtp流

我现在也做了视频处理部分，那就只需要加一个新的工厂方法就可以了，其他API不需要变动。

  • 建造者模式满足小白与高阶用户。

小白用户有上面的抽象工厂创建实例，直接调用，做个demo骗骗导师，水水论文结果神马的还 是不错的！

但我们对于一些高阶的用户需要一些有逼格的功能，他们在做产品中需要更多的个性化，这时候 就应该拿出建造者模式了，接着上面的例子：

AudioVideoProcessorBuilder audioVideoProcessorBuilder = new AudioVideoProcessorBuilder()//建造者模型精细的把握各项参数
.setResize(ResizeStyleOptions.W_H_16_9)//长宽比
.setMaxBitrate(BitRateOptions.64_K)//码流率
.setP2PMode(P2PModeOptions.NAT);//p2p穿透方式
AudioVideoProcessor videoProcessor = audioVideoProcessorBuilder.getVideoProcessor();

是不是人民群众喜闻乐见的库的调用方式！

  • 策略模式进行容错处理。

为了框架使用者不骂你，多样化的容错处理是必要的。

再次拿Volley开刀！

对于Volley这样的网络请求框架来说，必要的重连机制是必不可少的，你看：

当然，再次照顾小白（主要水作业的学生党），Volley也提供了


默认的重连策略。

容错的具体处理委托给这些策略类。

目前就想到这么多，其他的再补。