Android常用设计模式

1.单例模式:Application,EventBus,UIL
2.工厂模式:BitmapFactory
3.观察者模式:Listener
4.适配器模式:listview
5.组合模式:view和viewgroup
7.代理模式:binder
6.MVC模式:M层:适合做一些业务逻辑处理,比如数据库存取操作,网络操作,复杂的算法,耗时的任务等都在model层处理。 V层:应用层中处理数据显示的部分,XML布局可以视为V层,显示Model层的数据结果。 C层:在Android中,Activity处理用户交互问题,因此可以认为Activity是控制器,Activity读取V视图层的数据(eg.读取当前EditText控件的数据),控制用户输入(eg.EditText控件数据的输入),并向Model发送数据请求(eg.发起网络请求等)。

View 传送指令到 Controller
Controller 完成业务逻辑后,要求 Model 改变状态
Model 将新的数据发送到 View,用户得到反馈

唯一的区别是,它采用双向绑定(data-binding):View的变动,自动反映在 ViewModel,反之亦然

各部分之间的通信,都是双向的。
View 与 Model 不发生联系,都通过 Presenter 传递。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
关于框架有意见 欢迎联系我一起探讨。 问答是happy http://blog.csdn.net/b275518834/article/details/8247685 操作方式:输入文本框设置线程数 点击第一个按钮请求10个地址信息 点击第二个按钮中断10个地址信息 1:判断当前网络环境 2:编写了3套方案 Old_GridViewActivity 简单线程回调 AsyncTask_GridViewActivity 使用android自带的AsyncTask类实现 Demo_GridViewActivity 队列任务管理 线程控制 Demo_GridViewActivity方式 1:队列优先级 (如果想要listview中移动的区域优先被显示,而不是从上到下显示图片,可以把新建的任务提到任务队列前端) 2:实现了:中断任务的功能(比如进入一个Activity会开启大量任务,如果退出这个Activity 则应该停止此Activity中驻留的任务) 3:为何采用drawable不用bitmap bitmap优点是位图运算效率优秀 但drawable的存储体积比bitmap小 4:如果任务被起名字则禁止重复提交任务 (避免某些请求未处理完又被创建) 5:先执行缓存数据后执行请求数据 (缓存性能) 6:使用状态模式 观察者模式更好的处理多线程 最初的想法:网络优化开发框架 (移除任务未完成) 网络稳定,系统运行稳定性,大内存消耗稳定,长时间运行稳定性 (旧的系统症结所在) 开启过多线程,导致系统频繁切换多个线程,导致处理速度过慢,经常出现未响应。 代码经常写的换繁多无序,维护困难。 使用类似银行叫号系统 线程池内等待网络请求的任务=(排队的人) 最大三个线程=(银行柜台处理业务的窗口) 依次处理任务=(将排队的人依次被叫到处理的号,完成业务的窗口叫号后面排队的人) 如果抛出异常则通知相关单位=(如果银行柜台处理不了一个人的业务就打电话给大堂经理) 设置柜台的监听回调=(A委托B去银行请求数据,当B去银行处理业务失败了,通知A。) 设置撤销机制和线程安全= 某机关让A和B去银行申请业务,A在排队,B正在柜台处理业务,此时机关打来电话说, 这申请业务的需求现在不做,A取消排队,B也‘礼貌的退出’ 《例如退出A页面时,终止A页面所有的请求》 任务状态标示-还没处理 处理中 处理结束 处理异常 (有结果但不通知)=(排队人的状态) 任务名 排队人的名字 强制退出 强制退出 抛出强制退出的异常

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值