多activity还是单activity的选择 appuiactivity 解决方案 » 免费领取超大流量手机卡，每月29元包185G流量+100分钟通话, 中国电信官方发货 ..........好吧，至少我是一个页面一个activity 我知道大部分人好像都是一个页面一个activity，但是我用单个activity用的很舒服啊，反而觉得多个很麻烦，所以想听听懂的人是怎么看的。 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本身变并没有销毁。当然上面只是我的理解，有什么不对欢迎指出，暂时想到这些 所以你是几十个activity吗？ 我的话就是几十个view了 我这套做法是我2年前做app的时候自己弄的，中间呢停了一年没弄android，搞web去了，现在又回来弄android，以前做的时候是在2.1的版本上开发，现在都到5.0了，感觉自己可能落后了。闲话说完，突然想到我这个做法还有一个好处：比如我在一个页面输了很多数据，或者说我动态改变了一个页面的布局，然后去了下个页面，但是当我返回上个页面的时候，希望还是原来的样子，输入的数据还在，改变的布局也还在，如果是activity就比较麻烦，需要先保存数据，然后用onActivityResult把数据传回上个页面，再去填充页面改变布局等等。我用view就不需要顾虑这个问题，因为每个view存在viewflipper中，类似于activity的栈，我从一个view返回上个view时，依然是原来的状态，因为view本身变并没有销毁。当然上面只是我的理解，有什么不对欢迎指出，暂时想到这些你页面跳转正常情况下（非内存不够）是执行onpause、onstop方法不会销毁activity的具体的view也不会销毁，返回回去还是原来的样子 我这套做法是我2年前做app的时候自己弄的，中间呢停了一年没弄android，搞web去了，现在又回来弄android，以前做的时候是在2.1的版本上开发，现在都到5.0了，感觉自己可能落后了。闲话说完，突然想到我这个做法还有一个好处：比如我在一个页面输了很多数据，或者说我动态改变了一个页面的布局，然后去了下个页面，但是当我返回上个页面的时候，希望还是原来的样子，输入的数据还在，改变的布局也还在，如果是activity就比较麻烦，需要先保存数据，然后用onActivityResult把数据传回上个页面，再去填充页面改变布局等等。我用view就不需要顾虑这个问题，因为每个view存在viewflipper中，类似于activity的栈，我从一个view返回上个view时，依然是原来的状态，因为view本身变并没有销毁。当然上面只是我的理解，有什么不对欢迎指出，暂时想到这些你页面跳转正常情况下（非内存不够）是执行onpause、onstop方法不会销毁activity的具体的view也不会销毁，返回回去还是原来的样子你说的是对的。 想了想，这里我弄错了。 CSDN这么垃圾么，爬你妹的，手动点都会出现。也太频繁了。 我记得我在看Mars老师的视频的时候，介绍Activity的那一集视频中说，一个应用中最好用尽量少的activity，一个应用中有5、6个activity就已经多的不得了。 我以前也用过viewflipper，只是做分类切换，感觉第一次进入时间有点长，后来没有了。如果你整个app就是用它来进行所有的布局切换，那么你第一进入的时间不长吗，还是做了什么特殊处理。 继续说说，我的APP结构是这样的：由2个activity组成，LoginActivity和MainActivity，LoginActivity完成登陆操作之后，跳转到MainActivity同时finish掉LoginActivity。MainActivity的layout.xml中放置了一个ViewFlipper，ViewFlipper中的第一个view是个导航页，通往不同的功能模块。跳转到下一个页面的时候，将新的view添加到ViewFlipper，再给跳转添加动画，自己实现数据传递的方法，退回到上个view时，将ViewFlipper中最后一个view remove 出去。弱弱的画了一张图，如下：画的是丑了点，应该看的懂吧。这样的结构我个人感觉很舒服，整体只由少数activity组成，我起初就是对繁多的activity感到烦躁，才想到了用这种方式。 activity的好处就是，你一旦finish掉，资源就被释放掉了，如果需要手动释放的写在onDestory里面，如果是view的话是不是每次释放资源都要手动呢 用一个activity的话，个人认为，如果是一个简单的应用的话，会方便一些，少去了一些数据信息的交换，等于说有一个一个共享的对象用来存储运行时数据。但是对于复杂的应用来说就不是很适合，首先一个activity结构就不合适，让所有的UI天然的耦合在一起。这样以来，UI的逻辑，数据的初始化，每一个细节都要自己考虑到，因为共享数据 ，所以数据访问控制，多线问题就会变的越来越麻烦。所以小应用可以用，大一些的应用不建议，个人认为。 先谢谢你的回答，不过第二段听的不是很明白。多activity UI的逻辑，数据的初始化不也是需要自己考虑，自己控制吗？对的，因为是用一个activity，所以view是共用一个context的，这会对数据访问控制，多线问题造成什么麻烦吗？希望您能说的具体一点 公司项目java代码十多W行，写一个activity里面咋维护，而且一个activity怎么分工，不是很容易发生冲突么，反正我是一个java文件代码达到2000行就看得头大了 这种写法对机子的要求高，少点VIEW还行，多VIEW多资源的那种，适配低配置机子就不流畅了。 逻辑都是在各自的view里进行的，activity仅仅是个入口，代码就一两百行而已 恩，这个我想过的，不过我做的那个app层级最多只到4级，而且每次退出页面我自己手动释放资源，不过具体性能上跟activity自己释放比哪个好，倒没测试过，不是很清楚了 恩，这个我想过的，不过我做的那个app层级最多只到4级，而且每次退出页面我自己手动释放资源，不过具体性能上跟activity自己释放比哪个好，倒没测试过，不是很清楚了都是胡说八道的 google这套activity根本就是莫名其妙，没必要分。就一个activity，像你说的分view就最好，否则你会遇到数不清的麻烦，google他自己设计这一套的时候都没想清楚。我就提一个例子:假设你的应用有网络连接，当有错误的时候你想弹出提示框怎么办？你根本没办法知道当前展示的是哪个activity，但是弹出窗口是需要基于activity的至于资源释放的问题，那更加扯淡了。你只要不缓存view，照样会被释放掉。至于图片什么的问题，你就是用activity也解决不了它被cache住的问题。至于说机子性能，你分view跟分activity是一样的效果。只要你不上来将ui文件全部展开就没事。我的观点就是：你分view是对的，应该往这个方向走，分activity反而是没必要的。 我这套做法是我2年前做app的时候自己弄的，中间呢停了一年没弄android，搞web去了，现在又回来弄android，以前做的时候是在2.1的版本上开发，现在都到5.0了，感觉自己可能落后了。闲话说完，突然想到我这个做法还有一个好处：比如我在一个页面输了很多数据，或者说我动态改变了一个页面的布局，然后去了下个页面，但是当我返回上个页面的时候，希望还是原来的样子，输入的数据还在，改变的布局也还在，如果是activity就比较麻烦，需要先保存数据，然后用onActivityResult把数据传回上个页面，再去填充页面改变布局等等。我用view就不需要顾虑这个问题，因为每个view存在viewflipper中，类似于activity的栈，我从一个view返回上个view时，依然是原来的状态，因为view本身变并没有销毁。当然上面只是我的理解，有什么不对欢迎指出，暂时想到这些这个问题很好解决，估计就是因为你的view在oncreateview里重复创建 了。用下面代码就行if (view!=null) { ViewGroup parent = (ViewGroup) view.getParent(); if (parent!=null) { parent.removeAllViews(); } return view; }根据需要添加 我们的项目都是FragmentActivity+Fragment 除了登陆是个activity之外 就用 了这2个activity看需要 主要是对队列的管理 这个给不了，自己做的一个完整app不能随便给吧，而且外面已经在使用了 恩，这个我想过的，不过我做的那个app层级最多只到4级，而且每次退出页面我自己手动释放资源，不过具体性能上跟activity自己释放比哪个好，倒没测试过，不是很清楚了都是胡说八道的 google这套activity根本就是莫名其妙，没必要分。就一个activity，像你说的分view就最好，否则你会遇到数不清的麻烦，google他自己设计这一套的时候都没想清楚。我就提一个例子:假设你的应用有网络连接，当有错误的时候你想弹出提示框怎么办？你根本没办法知道当前展示的是哪个activity，但是弹出窗口是需要基于activity的至于资源释放的问题，那更加扯淡了。你只要不缓存view，照样会被释放掉。至于图片什么的问题，你就是用activity也解决不了它被cache住的问题。至于说机子性能，你分view跟分activity是一样的效果。只要你不上来将ui文件全部展开就没事。我的观点就是：你分view是对的，应该往这个方向走，分activity反而是没必要的。其实我想知道官方有没有什么这方面的建议？当初我选择用单activity是因为觉得activity比较臃肿，而且它的作用不是仅仅用来呈现界面，而我的view只是用来显示界面的，剩下的事情就交给一个activity来处理 那其实跟我的结构差不多，只不过我用的是viewFlipper 我觉得吧,使用多个activity的好处在于,内存可以局部收回 考虑到内存回收后的重新载入，用一个activity会导致onSaveInatanse（）很复杂 viewflipper没用过，都是多个activity的 先谢谢你的回答，不过第二段听的不是很明白。多activity UI的逻辑，数据的初始化不也是需要自己考虑，自己控制吗？对的，因为是用一个activity，所以view是共用一个context的，这会对数据访问控制，多线问题造成什么麻烦吗？希望您能说的具体一点首先说一下结构，你之前说用一个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要多做多少控制。 先谢谢你的回答，不过第二段听的不是很明白。多activity UI的逻辑，数据的初始化不也是需要自己考虑，自己控制吗？对的，因为是用一个activity，所以view是共用一个context的，这会对数据访问控制，多线问题造成什么麻烦吗？希望您能说的具体一点首先说一下结构，你之前说用一个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要多做多少控制。+1，个人认为软件的弱耦合很重要，某些涉及到重用页面很多的APP，用单activity多view的方式要自己控制处理很多，而把view装进activity，每次都是一个新的独立页面，逻辑控制更轻松，这对于软件的二次开发和维护都有很好的帮助。 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就得适应，毕竟人在矮檐下，不得不低头啊。 各有好处吧，你一个Activity怎么处理Back按键呢？ 现在一般用Activity+Fragment。要做到你说的返回时数据还在，只要控制Fragment的hide/show即可，其他资源存储/释放方法和Activity差不多，毕竟Fragment也有一套自己的完整生命周期。 先谢谢你的回答，不过第二段听的不是很明白。多activity UI的逻辑，数据的初始化不也是需要自己考虑，自己控制吗？对的，因为是用一个activity，所以view是共用一个context的，这会对数据访问控制，多线问题造成什么麻烦吗？希望您能说的具体一点首先说一下结构，你之前说用一个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要多做多少控制。 恩，你说的也有道理。 back键只要判断一下viewFlipper里是不是只剩一个view了，如果不是就调用viewFlipper的showPrevious()，还是好控制的。 对啊，出了新东西只能学习，我之前的做法是在2.1上，还是2年多前的时候写的，最近刚回归android，所以才提出来看看大家的看法，现在我也在考虑用Activity+Fragment的方式做。你说的那个bug我没有遇到过，而且最早我也是在实机上先测试过ViewFlipper加载view多了会不会卡顿之类的，发现速度还不错才这么做的 android平台可以实现蓝牙多对多的聊天吗 关于sqlite数据库的纠结问题，新手请教 闹钟问题 怎么停止系统自身的铃声播放？ 这么多Unknown Source Android 如何设置 Setting 中的默认选项 关于xml的出错。新手求大神解救。 编写好的安卓程序闪退 Unexpected response code 500 for android studio 混淆aar的问题 fragment里面的EditText控件编辑不了 android开发怎么用代码去重启手机
好吧，至少我是一个页面一个activity
我知道大部分人好像都是一个页面一个activity，但是我用单个activity用的很舒服啊，反而觉得多个很麻烦，所以想听听懂的人是怎么看的。
如果单单是麻烦，可以用android studio开发会便捷点，比如能自动在AndroidManifest中注册
我这套做法是我2年前做app的时候自己弄的，中间呢停了一年没弄android，搞web去了，现在又回来弄android，以前做的时候是在2.1的版本上开发，现在都到5.0了，感觉自己可能落后了。闲话说完，突然想到我这个做法还有一个好处：
比如我在一个页面输了很多数据，或者说我动态改变了一个页面的布局，然后去了下个页面，但是当我返回上个页面的时候，希望还是原来的样子，输入的数据还在，改变的布局也还在，如果是activity就比较麻烦，需要先保存数据，然后用onActivityResult把数据传回上个页面，再去填充页面改变布局等等。我用view就不需要顾虑这个问题，因为每个view存在viewflipper中，类似于activity的栈，我从一个view返回上个view时，依然是原来的状态，因为view本身变并没有销毁。
当然上面只是我的理解，有什么不对欢迎指出，暂时想到这些
所以你是几十个activity吗？
我的话就是几十个view了
我这套做法是我2年前做app的时候自己弄的，中间呢停了一年没弄android，搞web去了，现在又回来弄android，以前做的时候是在2.1的版本上开发，现在都到5.0了，感觉自己可能落后了。闲话说完，突然想到我这个做法还有一个好处：
比如我在一个页面输了很多数据，或者说我动态改变了一个页面的布局，然后去了下个页面，但是当我返回上个页面的时候，希望还是原来的样子，输入的数据还在，改变的布局也还在，如果是activity就比较麻烦，需要先保存数据，然后用onActivityResult把数据传回上个页面，再去填充页面改变布局等等。我用view就不需要顾虑这个问题，因为每个view存在viewflipper中，类似于activity的栈，我从一个view返回上个view时，依然是原来的状态，因为view本身变并没有销毁。
当然上面只是我的理解，有什么不对欢迎指出，暂时想到这些
你页面跳转正常情况下（非内存不够）是执行onpause、onstop方法不会销毁activity的具体的view也不会销毁，返回回去还是原来的样子
我这套做法是我2年前做app的时候自己弄的，中间呢停了一年没弄android，搞web去了，现在又回来弄android，以前做的时候是在2.1的版本上开发，现在都到5.0了，感觉自己可能落后了。闲话说完，突然想到我这个做法还有一个好处：
比如我在一个页面输了很多数据，或者说我动态改变了一个页面的布局，然后去了下个页面，但是当我返回上个页面的时候，希望还是原来的样子，输入的数据还在，改变的布局也还在，如果是activity就比较麻烦，需要先保存数据，然后用onActivityResult把数据传回上个页面，再去填充页面改变布局等等。我用view就不需要顾虑这个问题，因为每个view存在viewflipper中，类似于activity的栈，我从一个view返回上个view时，依然是原来的状态，因为view本身变并没有销毁。
当然上面只是我的理解，有什么不对欢迎指出，暂时想到这些
你页面跳转正常情况下（非内存不够）是执行onpause、onstop方法不会销毁activity的具体的view也不会销毁，返回回去还是原来的样子你说的是对的。 想了想，这里我弄错了。
如果你整个app就是用它来进行所有的布局切换，那么你第一进入的时间不长吗，还是做了什么特殊处理。
由2个activity组成，LoginActivity和MainActivity，LoginActivity完成登陆操作之后，跳转到MainActivity同时finish掉LoginActivity。
MainActivity的layout.xml中放置了一个ViewFlipper，ViewFlipper中的第一个view是个导航页，通往不同的功能模块。跳转到下一个页面的时候，将新的view添加到ViewFlipper，再给跳转添加动画，自己实现数据传递的方法，退回到上个view时，将ViewFlipper中最后一个view remove 出去。弱弱的画了一张图，如下：
画的是丑了点，应该看的懂吧。
这样的结构我个人感觉很舒服，整体只由少数activity组成，我起初就是对繁多的activity感到烦躁，才想到了用这种方式。
但是对于复杂的应用来说就不是很适合，首先一个activity结构就不合适，让所有的UI天然的耦合在一起。这样以来，UI的逻辑，数据的初始化，每一个细节都要自己考虑到，因为共享数据 ，所以数据访问控制，多线问题就会变的越来越麻烦。所以小应用可以用，大一些的应用不建议，个人认为。
先谢谢你的回答，不过第二段听的不是很明白。多activity UI的逻辑，数据的初始化不也是需要自己考虑，自己控制吗？
对的，因为是用一个activity，所以view是共用一个context的，这会对数据访问控制，多线问题造成什么麻烦吗？希望您能说的具体一点
逻辑都是在各自的view里进行的，activity仅仅是个入口，代码就一两百行而已
恩，这个我想过的，不过我做的那个app层级最多只到4级，而且每次退出页面我自己手动释放资源，不过具体性能上跟activity自己释放比哪个好，倒没测试过，不是很清楚了
恩，这个我想过的，不过我做的那个app层级最多只到4级，而且每次退出页面我自己手动释放资源，不过具体性能上跟activity自己释放比哪个好，倒没测试过，不是很清楚了
都是胡说八道的 google这套activity根本就是莫名其妙，没必要分。
就一个activity，像你说的分view就最好，否则你会遇到数不清的麻烦，google他自己设计这一套的时候都没想清楚。
我就提一个例子:
假设你的应用有网络连接，当有错误的时候你想弹出提示框怎么办？
你根本没办法知道当前展示的是哪个activity，但是弹出窗口是需要基于activity的
至于资源释放的问题，那更加扯淡了。你只要不缓存view，照样会被释放掉。至于图片什么的问题，你就是用activity也解决不了它被cache住的问题。
至于说机子性能，你分view跟分activity是一样的效果。只要你不上来将ui文件全部展开就没事。
我的观点就是：你分view是对的，应该往这个方向走，分activity反而是没必要的。
我这套做法是我2年前做app的时候自己弄的，中间呢停了一年没弄android，搞web去了，现在又回来弄android，以前做的时候是在2.1的版本上开发，现在都到5.0了，感觉自己可能落后了。闲话说完，突然想到我这个做法还有一个好处：
比如我在一个页面输了很多数据，或者说我动态改变了一个页面的布局，然后去了下个页面，但是当我返回上个页面的时候，希望还是原来的样子，输入的数据还在，改变的布局也还在，如果是activity就比较麻烦，需要先保存数据，然后用onActivityResult把数据传回上个页面，再去填充页面改变布局等等。我用view就不需要顾虑这个问题，因为每个view存在viewflipper中，类似于activity的栈，我从一个view返回上个view时，依然是原来的状态，因为view本身变并没有销毁。
当然上面只是我的理解，有什么不对欢迎指出，暂时想到这些这个问题很好解决，估计就是因为你的view在oncreateview里重复创建 了。用下面代码就行
if (view!=null) {
ViewGroup parent = (ViewGroup) view.getParent();
if (parent!=null) {
parent.removeAllViews();
}
return view;
}根据需要添加
看需要 主要是对队列的管理
这个给不了，自己做的一个完整app不能随便给吧，而且外面已经在使用了
恩，这个我想过的，不过我做的那个app层级最多只到4级，而且每次退出页面我自己手动释放资源，不过具体性能上跟activity自己释放比哪个好，倒没测试过，不是很清楚了
都是胡说八道的 google这套activity根本就是莫名其妙，没必要分。
就一个activity，像你说的分view就最好，否则你会遇到数不清的麻烦，google他自己设计这一套的时候都没想清楚。
我就提一个例子:
假设你的应用有网络连接，当有错误的时候你想弹出提示框怎么办？
你根本没办法知道当前展示的是哪个activity，但是弹出窗口是需要基于activity的
至于资源释放的问题，那更加扯淡了。你只要不缓存view，照样会被释放掉。至于图片什么的问题，你就是用activity也解决不了它被cache住的问题。
至于说机子性能，你分view跟分activity是一样的效果。只要你不上来将ui文件全部展开就没事。
我的观点就是：你分view是对的，应该往这个方向走，分activity反而是没必要的。其实我想知道官方有没有什么这方面的建议？
当初我选择用单activity是因为觉得activity比较臃肿，而且它的作用不是仅仅用来呈现界面，而我的view只是用来显示界面的，剩下的事情就交给一个activity来处理
那其实跟我的结构差不多，只不过我用的是viewFlipper
先谢谢你的回答，不过第二段听的不是很明白。多activity UI的逻辑，数据的初始化不也是需要自己考虑，自己控制吗？
对的，因为是用一个activity，所以view是共用一个context的，这会对数据访问控制，多线问题造成什么麻烦吗？希望您能说的具体一点首先说一下结构，你之前说用一个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要多做多少控制。
先谢谢你的回答，不过第二段听的不是很明白。多activity UI的逻辑，数据的初始化不也是需要自己考虑，自己控制吗？
对的，因为是用一个activity，所以view是共用一个context的，这会对数据访问控制，多线问题造成什么麻烦吗？希望您能说的具体一点首先说一下结构，你之前说用一个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要多做多少控制。
+1，个人认为软件的弱耦合很重要，某些涉及到重用页面很多的APP，用单activity多view的方式要自己控制处理很多，而把view装进activity，每次都是一个新的独立页面，逻辑控制更轻松，这对于软件的二次开发和维护都有很好的帮助。
Activity首先 7大声明周期帮助你管理，你可以都用上，也可以选择使用。
如果用View的话，加载，缓存，释放等等都需要自己控制，稍有不当，就会出现OOM等问题。（智者千虑必有一失啊）其次，你说你用了viewflipper,这个东西如果你一次性加载全部的View进去，那View的多少就决定了你的等待时间，不过，这个可以用异步加载解决，还有你用viewflipper有没有出现不是你预期的效果的情况，比如：你从右向左滑正常，从左往右滑会出现不正常的效果，其实这个viewflipper就是个图片数组，如果涉及到用索引的话，从左往右滑就会出现”BUG“，但是，细想下那个不是BUG只是不好控制，例如：做相册的时候，用GridView和ViewFlipper那么从GridView到viewflipper就涉及到索引问题，当时我就出现了上面说的那个问题，后来用其他方法解决了。
当然，Activity如果太多了也不太好，比如说：Manifest文件就会很臃肿，所以用fragment，Android更新是发现了有新东西可以代替旧的东西，或者是提出什么东西可以解决什么问题，要不然他没事老更新做什么，吃饱了没事干吗？所以，我们既然选择了用Android就得适应，毕竟人在矮檐下，不得不低头啊。
先谢谢你的回答，不过第二段听的不是很明白。多activity UI的逻辑，数据的初始化不也是需要自己考虑，自己控制吗？
对的，因为是用一个activity，所以view是共用一个context的，这会对数据访问控制，多线问题造成什么麻烦吗？希望您能说的具体一点首先说一下结构，你之前说用一个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要多做多少控制。 恩，你说的也有道理。 back键只要判断一下viewFlipper里是不是只剩一个view了，如果不是就调用viewFlipper的showPrevious()，还是好控制的。
对啊，出了新东西只能学习，我之前的做法是在2.1上，还是2年多前的时候写的，最近刚回归android，所以才提出来看看大家的看法，现在我也在考虑用Activity+Fragment的方式做。
你说的那个bug我没有遇到过，而且最早我也是在实机上先测试过ViewFlipper加载view多了会不会卡顿之类的，发现速度还不错才这么做的