对Android的恶意吐槽(勿看,有毒)

CSDN博客:http://blog.csdn.net/niu_gao

我觉得android系统中有一个特恶心人的大败笔。就是这个大败笔造成了android系统的卡卡卡不停。

这个大败笔就是对activity的设计。

Android对activity的设计原则是:必须是执行时独立的。

你不能直接创建activity并启动它,必须由系统帮你这样干。你要启动activity。必须用一个Intent请求系统帮忙。

所以你要在manifest文件里声明app中的每一个activity。假设你有多个activity声明为可启动的而且指定了intent-filter,那么每一个activity都有可能成为你app的入口。

既然每一个activity都可能成为入口,那每一个activity必须是功能独立。自我圆满的。也就是说淡化了进程的概念,一个activity假设destroy了。即使它所在的app进程没有退出且又启动了新的activity。也应该视为这个activity的app退出了。

CSDN博客:http://blog.csdn.net/niu_gao

然而理想太丰满,现实不鸟你。有几个人能有如此共产主义思想与精力把自己的每一个activity都搞成像系统的打电话发短信这样的app?大部分activity都是内部使用的。每一个都被搞得非常独立太费劲了。尤其是app内部的activity之间共享数据时更麻烦,按其原则应把数据放到intent的附加数据中,以startActivityForResult()启动下一个activity。而且在onActivityResult()中接收下一个activity返回的数据,然而假设搞成全局静态数据的话多省事?

这样的设计是不是太过分了?你能够杀死与前台app无关的activity或进程,但你怎么能杀死前台app中的activity呢?与其让系统谋杀它还不如让程序猿自己去杀它。再说了假设系统内存连一个app的正常执行都维持不住了,那是不是这个app设计得太差了?

另一个更混乱之极的情况:最新的android系统中提倡导航栏(难道是要跟苹果学,省掉一个键?),于是在导航栏中就有了返回button。可是当从Activity A中启动B。然后在B的导航栏上点返回button返回A时(在manifest文件里将A指定为B的爸爸),实际上A已经不是原来的A了,而是又一次创建了一个。这事是不是太扯蛋了?这样的情况下A中的onActivityResult()是永远不会被执行!所以要注意,点导航栏上的返回button与点设备的返回键。其效果是不同的,不同的。不同的。。

。扯蛋的事情说三遍!

还有。android的开发文档中明白说假设activity中开了后台线程,应该在onDestroy中关闭它。

好吧,一般一个app都由多个页面导航完毕操作流程,也就是说开多线程的activity在隐藏和显示之间切换时要不停地开关开关开关多线程?

那有没有办法解决问题呢?有!能够利用另一个功能独立。自我圆满的组件:service。利用service做后台事务,activity在显隐之间就不会影响到后台任务了,但又要做activity与service之间的通讯,好麻烦。

但有解决的方法总比没有强!

还没完,由于这样的设计原则带来了更混乱的activity生命周期管理问题!看一下这个图,activity的生命周期多么恐怖。

对Android的恶意吐槽(勿看,有毒)

还有这个图:

对Android的恶意吐槽(勿看,有毒)

(关于Activity的生命周期。详见: http://blog.csdn.net/niu_gao/article/details/7101178

CSDN博客:http://blog.csdn.net/niu_gao

复杂就算了,更操蛋的是不一致性!本来我们以为onStop()一定相应onStart(),谁知道半路杀出个onRestart()。onStart()之后还不算执行状态,还要再来的onResume() 才算。onCreate()事实上并非相应onDestroy(),而是相应onStop(),我X。能够骂人吗?

但最最扯蛋的是,假设你要保存activity上控件的状态,你须要在onPause()中做!有看官说了,不是onPause(),而是onSaveInstanceState()。

是的。实际上是onSaveInstanceState()中,可是onSaveInstanceState()的调用时机是紧跟onPause()的。所以从时机来说与在onPause()中也没多少差别。这就是为什么android界面卡卡卡了!骨子里带的,无法解决!仅仅要引起onPause()调用,必定会伴随硬盘(存储器)操作!也就是再小的activity切换,都会引起硬盘操作!

但事实上在执行一个app的过程中。这样的操作百分之99是不须要的。由于activity跟本没有destroy!全部的控件都在内存中保持着它们的状态呢!为什么IOS界面顺?由于IOS里没有这样操蛋的设计。IOS里的ViewController与activity非常类似。但却没有要求必须保持执行时独立性。

android如今有抄IOS的地方,比ListView的替代品:RecycleVeiw,其item的重与机制与IOS的UITableView的cell非常类似了,为什么不把activity的设计也向IOS学一下呢?

另一个扯蛋的设计:就是屏幕旋转时。activity会被destroy再create。跟据前面所讲。能够知道destroy和create过程中的代价有多大。这个过程中app进程跟本没有退出,为毛我要在屏幕旋转过程关闭线程再开启?为毛我要关掉网络再重连?而IOS呢?仅仅是通过一个回调方法给出通知。全然不会关掉view controller再重建。当然由于重建activity,android就有了比IOS更牛B的能力:横屏和竖屏能够有全然不同的layout。事实上IOS也能够啊,仅仅要你实现响应屏幕旋转的回调方法,在当中自己用代码调整layout即可了。

我觉得android已经认识都是这个错误,所以推出了Fragment这个东西。fragment尽管也有生命周期,可是它不会被系统主动杀死,仅仅要它所在的activity不死。它就一直存在,而且事实上你也能够让它离开activity依旧活着。而且你也能够决定fragment的生死,假设你想省内存。你能够主动干掉fragment。

有了fragment,你的app能够仅仅有一个activity,建多个fragment,页面切换就是fragment间切换。这样除了屏幕旋转时。大部分情况下不存在销毁和重建问题。不信吗?你能够看到管理fragment的API中,有将fragment增加后退栈的方法。后退栈与导航栏上的后退button不正好能够配合写出高效的向导类型的界面吗?所以大家以后要多用fragment少用activity。android推出fragment,就是想让你这样做,仅仅只是不好意思把自己原来的设计全局否定,打自己的脸吧了。

(要详细了解fragment,请见:http://blog.csdn.net/niu_gao/article/details/7163263

以上都是个人偏见,人外有人天外有天。希望有高手来打我的脸。

CSDN博客:http://blog.csdn.net/niu_gao

最后再说一下关于android程序的优化:

  • 首先就是按上面所说:多用fragment,少用activity。事实上这一条就够了。其他的优化都是针对自己应用的逻辑进行特殊的优化,详细问题详细分析。
  • 其次是用最新的API。新开发包总会带来一些优化,或提供新的更高效的组件,比方用RecycleView取代ListView和GridView 。
  • 再次是能用C和C++就多用C和C++吧。事实上这一条我并不推荐。由于从代码维护角度讲,还是能用java就用java。

    但假设你非要优化到极限,那就多用C和C++(喜欢NDK和c++而且基础非常差的同学能够增加这个群:*535807023)*。

  • 最后,假设你不怕麻烦。就自己处理屏幕旋转,大体例如以下:

    为你的manifest文件里的activity元素增加属性:
android:configChanges=“orientation|keyboardHidden”
然后在activity中响应回调方法:
public void onConfigurationChanged (Configuration newConfig) 

CSDN博客:http://blog.csdn.net/niu_gao

希望在新的版本号中,andorid重拾进程的概念。让大家能*决定是否将activity搞成执行时独立,进一步向IOS学习,将activity的pause改成“进入后台”,将resume改成“成为前台”,除了生命周期中最基本的create和destroy外,其余的该改名改名,该去掉的去掉。如此则它好我们也好,反正是极好的。

上一篇:W10破解LoadRunner时出现管理员阻止程序运行问题


下一篇:【树莓派】树莓派网络配置:静态IP、无线网络、服务等