多activity还是单activity的选择

Ycloud520 2014-12-01 10:34:02
加精
大家在开发APP的时候是用多个activity(例如一个页面一个activity),还是整个程序只用了一个activity(页面用view来呈现)?
它们的优点和缺点各是什么呢?
小弟不才,特来求解

我自己做的APP除了登陆用一个activity,整个主程序只用了一个activity,页面跳转用viewflipper来实现,每个页面都是一个view,所有的页面都继承自自定义的一个抽象类BaseView,里面实现了页面之间的数据传递和一些共用的方法。
主要我觉得每个activity都有自己的生命周期,而且每次需要AndroidManifest中注册一遍感觉好麻烦,就自己想了这个办法,具体哪个好其实我自己也说不上来,哪位大神给小弟解释一下?
...全文
2496 54 打赏 收藏 转发到动态 举报
写回复
用AI写文章
54 条回复
切换为时间正序
请发表友善的回复…
发表回复
地豆app 2015-06-03
  • 打赏
  • 举报
回复
activity控制层,view界面
地豆app 2015-06-03
  • 打赏
  • 举报
回复
activity控制层,view界面
fajuary 2014-12-27
  • 打赏
  • 举报
回复
单一的activity不容易造成ui阻塞!
Ycloud520 2014-12-09
  • 打赏
  • 举报
回复
引用 42 楼 u012137924 的回复:
Activity 4大组件之一,也是之首,4大组件都需要在Manifest文件中注册,这个类似 C/C++的include 头文件。注册后,才能在APP中找到相应的Activity。 Activity首先 7大声明周期帮助你管理,你可以都用上,也可以选择使用。 如果用View的话,加载,缓存,释放等等都需要自己控制,稍有不当,就会出现OOM等问题。(智者千虑必有一失啊) 其次,你说你用了viewflipper,这个东西如果你一次性加载全部的View进去,那View的多少就决定了你的等待时间,不过,这个可以用异步加载解决,还有你用viewflipper有没有出现不是你预期的效果的情况,比如:你从右向左滑正常,从左往右滑会出现不正常的效果,其实这个viewflipper就是个图片数组,如果涉及到用索引的话,从左往右滑就会出现”BUG“,但是,细想下那个不是BUG只是不好控制,例如:做相册的时候,用GridView和ViewFlipper那么从GridView到viewflipper就涉及到索引问题,当时我就出现了上面说的那个问题,后来用其他方法解决了。 当然,Activity如果太多了也不太好,比如说:Manifest文件就会很臃肿,所以用fragment,Android更新是发现了有新东西可以代替旧的东西,或者是提出什么东西可以解决什么问题,要不然他没事老更新做什么,吃饱了没事干吗?所以,我们既然选择了用Android就得适应,毕竟人在矮檐下,不得不低头啊。
对啊,出了新东西只能学习,我之前的做法是在2.1上,还是2年多前的时候写的,最近刚回归android,所以才提出来看看大家的看法,现在我也在考虑用Activity+Fragment的方式做。 你说的那个bug我没有遇到过,而且最早我也是在实机上先测试过ViewFlipper加载view多了会不会卡顿之类的,发现速度还不错才这么做的
Ycloud520 2014-12-09
  • 打赏
  • 举报
回复
引用 45 楼 oHeHeHou 的回复:
现在一般用Activity+Fragment。要做到你说的返回时数据还在,只要控制Fragment的hide/show即可,其他资源存储/释放方法和Activity差不多,毕竟Fragment也有一套自己的完整生命周期。
对的,那个只是我之前想错了、
Ycloud520 2014-12-09
  • 打赏
  • 举报
回复
引用 39 楼 tiantang198707 的回复:
[quote=引用 21 楼 Ycloud520 的回复:] [quote=引用 18 楼 tiantang198707 的回复:] 用一个activity的话,个人认为,如果是一个简单的应用的话,会方便一些,少去了一些数据信息的交换,等于说有一个一个共享的对象用来存储运行时数据。 但是对于复杂的应用来说就不是很适合,首先一个activity结构就不合适,让所有的UI天然的耦合在一起。这样以来,UI的逻辑,数据的初始化,每一个细节都要自己考虑到,因为共享数据 ,所以数据访问控制,多线问题就会变的越来越麻烦。 所以小应用可以用,大一些的应用不建议,个人认为。
先谢谢你的回答,不过第二段听的不是很明白。多activity UI的逻辑,数据的初始化不也是需要自己考虑,自己控制吗? 对的,因为是用一个activity,所以view是共用一个context的,这会对数据访问控制,多线问题造成什么麻烦吗?希望您能说的具体一点[/quote] 首先说一下结构,你之前说用一个antivity可以方便解决startActivityForResult的问题,这个就要看什么结构,一般的这样的做法使得界面间产生了外部数据耦合,这是一种高耦合,是软件设计不建议的。而startActivityForResul是通过参数列表,是一种弱耦合,是可以的。 但是在一些模块,比如支付流程,会有第一步,第二步到支付完成,这个整体上是一个复杂的模块,使用Activity+viewpager+fragment,用fragment显示每一步的界面,接受用户数据,用activity汇总数据,用viewpager实现界面切换,然后在最后一步实现和服务器的整体数据交互,这样在一个模块里,我认为这样做是可以的 所以,不是什么情况都适合用一个activity,很多时候,android一个界面就是一个模块,这个时候把不相关的多个模块用一个activity展示,个人认为,不是很合适 一个activity,数据是私有的,在oncreate里初始化,随着activity的销毁而销毁。而如果在activity里有多个View的公有数据,又有通过公有数据的数据传递的话,那什么时候触发初始化,什么时候数据失效就需要自己管理了。 如果你在activity里存放公有数据,只是通过activity来控制显示逻辑,把数据和逻辑都封装在View里,那你这样是用activity做了系统的activity stack的工作,view做了系统activity的工作。 而我认为activity stack控制的导航挺好的,没必要自己控制,比如用户按back键,你用View+activity要多做多少控制。[/quote] 恩,你说的也有道理。 back键只要判断一下viewFlipper里是不是只剩一个view了,如果不是就调用viewFlipper的showPrevious(),还是好控制的。
燕昭王 2014-12-09
  • 打赏
  • 举报
回复
大神真多,学习下各位的思想,赞一个
robake 2014-12-09
  • 打赏
  • 举报
回复
引用 24 楼 abcmsnet 的回复:
这种写法对机子的要求高,少点VIEW还行,多VIEW多资源的那种,适配低配置机子就不流畅了。
赞同这个看法,每个view都有自己的生命周期的,如果都堆在一个view里,那需要将多内容加载到内存里?中国的山寨机明显很多,这样的环境下,不是内存无限的,特别是在机器性能达不到的时候,用户第一反应就是软件太垃圾了,然后才会是说机器慢。。。。
Happysch 2014-12-09
  • 打赏
  • 举报
回复
大神真多,学习下各位的思想,赞一个
dong120840 2014-12-08
  • 打赏
  • 举报
回复
mark,讲得都有道理
网络咖啡 2014-12-08
  • 打赏
  • 举报
回复
各有好处吧,你一个Activity怎么处理Back按键呢?
山鹰1985 2014-12-08
  • 打赏
  • 举报
回复
Activity 4大组件之一,也是之首,4大组件都需要在Manifest文件中注册,这个类似 C/C++的include 头文件。注册后,才能在APP中找到相应的Activity。 Activity首先 7大声明周期帮助你管理,你可以都用上,也可以选择使用。 如果用View的话,加载,缓存,释放等等都需要自己控制,稍有不当,就会出现OOM等问题。(智者千虑必有一失啊) 其次,你说你用了viewflipper,这个东西如果你一次性加载全部的View进去,那View的多少就决定了你的等待时间,不过,这个可以用异步加载解决,还有你用viewflipper有没有出现不是你预期的效果的情况,比如:你从右向左滑正常,从左往右滑会出现不正常的效果,其实这个viewflipper就是个图片数组,如果涉及到用索引的话,从左往右滑就会出现”BUG“,但是,细想下那个不是BUG只是不好控制,例如:做相册的时候,用GridView和ViewFlipper那么从GridView到viewflipper就涉及到索引问题,当时我就出现了上面说的那个问题,后来用其他方法解决了。 当然,Activity如果太多了也不太好,比如说:Manifest文件就会很臃肿,所以用fragment,Android更新是发现了有新东西可以代替旧的东西,或者是提出什么东西可以解决什么问题,要不然他没事老更新做什么,吃饱了没事干吗?所以,我们既然选择了用Android就得适应,毕竟人在矮檐下,不得不低头啊。
呵呵后 2014-12-08
  • 打赏
  • 举报
回复
现在一般用Activity+Fragment。要做到你说的返回时数据还在,只要控制Fragment的hide/show即可,其他资源存储/释放方法和Activity差不多,毕竟Fragment也有一套自己的完整生命周期。
只为搞笑 2014-12-07
  • 打赏
  • 举报
回复
引用 39 楼 tiantang198707 的回复:
[quote=引用 21 楼 Ycloud520 的回复:] [quote=引用 18 楼 tiantang198707 的回复:] 用一个activity的话,个人认为,如果是一个简单的应用的话,会方便一些,少去了一些数据信息的交换,等于说有一个一个共享的对象用来存储运行时数据。 但是对于复杂的应用来说就不是很适合,首先一个activity结构就不合适,让所有的UI天然的耦合在一起。这样以来,UI的逻辑,数据的初始化,每一个细节都要自己考虑到,因为共享数据 ,所以数据访问控制,多线问题就会变的越来越麻烦。 所以小应用可以用,大一些的应用不建议,个人认为。
先谢谢你的回答,不过第二段听的不是很明白。多activity UI的逻辑,数据的初始化不也是需要自己考虑,自己控制吗? 对的,因为是用一个activity,所以view是共用一个context的,这会对数据访问控制,多线问题造成什么麻烦吗?希望您能说的具体一点[/quote] 首先说一下结构,你之前说用一个antivity可以方便解决startActivityForResult的问题,这个就要看什么结构,一般的这样的做法使得界面间产生了外部数据耦合,这是一种高耦合,是软件设计不建议的。而startActivityForResul是通过参数列表,是一种弱耦合,是可以的。 但是在一些模块,比如支付流程,会有第一步,第二步到支付完成,这个整体上是一个复杂的模块,使用Activity+viewpager+fragment,用fragment显示每一步的界面,接受用户数据,用activity汇总数据,用viewpager实现界面切换,然后在最后一步实现和服务器的整体数据交互,这样在一个模块里,我认为这样做是可以的 所以,不是什么情况都适合用一个activity,很多时候,android一个界面就是一个模块,这个时候把不相关的多个模块用一个activity展示,个人认为,不是很合适 一个activity,数据是私有的,在oncreate里初始化,随着activity的销毁而销毁。而如果在activity里有多个View的公有数据,又有通过公有数据的数据传递的话,那什么时候触发初始化,什么时候数据失效就需要自己管理了。 如果你在activity里存放公有数据,只是通过activity来控制显示逻辑,把数据和逻辑都封装在View里,那你这样是用activity做了系统的activity stack的工作,view做了系统activity的工作。 而我认为activity stack控制的导航挺好的,没必要自己控制,比如用户按back键,你用View+activity要多做多少控制。[/quote] +1,个人认为软件的弱耦合很重要,某些涉及到重用页面很多的APP,用单activity多view的方式要自己控制处理很多,而把view装进activity,每次都是一个新的独立页面,逻辑控制更轻松,这对于软件的二次开发和维护都有很好的帮助。
liujhgit 2014-12-03
  • 打赏
  • 举报
回复
我觉得吧,使用多个activity的好处在于,内存可以局部收回
Ycloud520 2014-12-03
  • 打赏
  • 举报
回复
引用 32 楼 liufangmeng 的回复:
我们的项目都是FragmentActivity+Fragment 除了登陆是个activity之外 就用 了这2个activity 看需要 主要是对队列的管理
那其实跟我的结构差不多,只不过我用的是viewFlipper
Ycloud520 2014-12-03
  • 打赏
  • 举报
回复
引用 30 楼 sniffer12345 的回复:
[quote=引用 28 楼 Ycloud520 的回复:] [quote=引用 24 楼 abcmsnet 的回复:] 这种写法对机子的要求高,少点VIEW还行,多VIEW多资源的那种,适配低配置机子就不流畅了。
恩,这个我想过的,不过我做的那个app层级最多只到4级,而且每次退出页面我自己手动释放资源,不过具体性能上跟activity自己释放比哪个好,倒没测试过,不是很清楚了[/quote] 都是胡说八道的 google这套activity根本就是莫名其妙,没必要分。 就一个activity,像你说的分view就最好,否则你会遇到数不清的麻烦,google他自己设计这一套的时候都没想清楚。 我就提一个例子: 假设你的应用有网络连接,当有错误的时候你想弹出提示框怎么办? 你根本没办法知道当前展示的是哪个activity,但是弹出窗口是需要基于activity的 至于资源释放的问题,那更加扯淡了。你只要不缓存view,照样会被释放掉。至于图片什么的问题,你就是用activity也解决不了它被cache住的问题。 至于说机子性能,你分view跟分activity是一样的效果。只要你不上来将ui文件全部展开就没事。 我的观点就是:你分view是对的,应该往这个方向走,分activity反而是没必要的。[/quote] 其实我想知道官方有没有什么这方面的建议? 当初我选择用单activity是因为觉得activity比较臃肿,而且它的作用不是仅仅用来呈现界面,而我的view只是用来显示界面的,剩下的事情就交给一个activity来处理
Ycloud520 2014-12-03
  • 打赏
  • 举报
回复
引用 29 楼 u013716334 的回复:
求你的Demo,notedwei@gmail.com
这个给不了,自己做的一个完整app不能随便给吧,而且外面已经在使用了
liufangmeng 2014-12-03
  • 打赏
  • 举报
回复
我们的项目都是FragmentActivity+Fragment 除了登陆是个activity之外 就用 了这2个activity 看需要 主要是对队列的管理
liufangmeng 2014-12-03
  • 打赏
  • 举报
回复
引用 5 楼 Ycloud520 的回复:
[quote=引用 3 楼 s715575807 的回复:] activity+fragment,fragment ui灵活、重用性强、切换轻量、适配不同屏幕。不过activity也用的挺多的,viewflipper没怎么用,每个activity都有自己的生命周期也便于根据具体实际进行控制,毕竟不同页面功能不同,在相应生命周期完成的任务也会有区别。 如果单单是麻烦,可以用android studio开发会便捷点,比如能自动在AndroidManifest中注册
我这套做法是我2年前做app的时候自己弄的,中间呢停了一年没弄android,搞web去了,现在又回来弄android,以前做的时候是在2.1的版本上开发,现在都到5.0了,感觉自己可能落后了。闲话说完,突然想到我这个做法还有一个好处: 比如我在一个页面输了很多数据,或者说我动态改变了一个页面的布局,然后去了下个页面,但是当我返回上个页面的时候,希望还是原来的样子,输入的数据还在,改变的布局也还在,如果是activity就比较麻烦,需要先保存数据,然后用onActivityResult把数据传回上个页面,再去填充页面改变布局等等。我用view就不需要顾虑这个问题,因为每个view存在viewflipper中,类似于activity的栈,我从一个view返回上个view时,依然是原来的状态,因为view本身变并没有销毁。 当然上面只是我的理解,有什么不对欢迎指出,暂时想到这些[/quote] 这个问题很好解决,估计就是因为你的view在oncreateview里重复创建 了。用下面代码就行 if (view!=null) { ViewGroup parent = (ViewGroup) view.getParent(); if (parent!=null) { parent.removeAllViews(); } return view; } 根据需要添加
加载更多回复(33)

80,337

社区成员

发帖
与我相关
我的任务
社区描述
移动平台 Android
androidandroid-studioandroidx 技术论坛(原bbs)
社区管理员
  • Android
  • yechaoa
  • 失落夏天
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧