标签:
转自 http://www.jianshu.com/p/5f6d79323923
关于底层的知识点不是在一篇文章中能讲解清楚,参见本人的Android底层研究系列,不断更新中。
下面精选了较为常见的知识点,坚决杜绝简单罗列答案
的方式,因为那样理解不了也记不住。所以尽量以层层递进而简单粗暴
的方式来表达。耐心点看,一定能帮你应对大多数面试问题。
Tips:可以先阅读自己熟悉的知识点,然后再去看那些不太熟悉的。
什么是启动Activity?
一般而言是先创建一个Activity对象,然后把Activity放入一个Task堆栈里进行管理(包括切换、关闭等)。那么问题来了,如果该堆栈里已经有这个Activity对象呢,我还要不要创建一个新的对象呢?Android提供了四种选择方案:
standard模式
singleTop模式
singleTask模式
singleInstance模式
(即只创建一个实例,单独放在一个task堆栈里给别的task栈共享)Activity(组件)之间何时需要通信?
一般当需要从一个Activity(组件)向其他的Activity(组件)传递数据时,就会涉及到通信机制。例如打开一个新的Activity并向其传递数据。
如何来通信/传递数据?
较常用的是android系统的信使:Intent
。
Intent的作用是,带上要传递的数据,然后出发前往指定的目的地。
那么问题来了,如果带上各种各样的数据呢?又如何导航去找到目的地呢?
如何带上各种各样的数据?
就像发信一样,你不可能把一堆凌乱的信纸直接塞给信使让人家送,而会用信封把信都装起来。
android里也一样,会把数据先打包,再给信使,这里就涉及到 bundle
。对,我们把一堆凌乱的数据放在一个bundle
里,然后把bundle给Intent
就可以了。
如何导航找到目的地呢?
如果你想邮寄东西有两种方式:1、在信封上写好详细地址
;2、如果你想邮寄没用的棉被书籍给灾区,但你又无所谓寄给哪个灾区,你就可以写帮我随便寄到一个灾区去
,然后邮局管理员会在全国范围内查询,如果查到了灾区如汶川,那就邮寄到那。
android里也一样,有显式Intent和隐式Intent,前者会指定特定组件名,如指定目标activity;后者不指定名称,只给一个描述(Intent-Filter)。然后android会依据这个描述去搜索。
但是,关于数据打包,有个问题是,如果传递普通数据可以直接放入bundle中,但 如果要传递对象呢。
如何在bundle中打包并传递对象呢!?
前面已经知道了,我们要在组件间通信时会先用bundle对数据打包,然后交给信使intent。那么问题来了?
bundle如何打包数据呢?
这里的数据我们分成两种,一种是原型数据
,如int、string等,可以直接打包并传递。打包方式如下:
bundle.putInt("key1", 20);
bundle.putString("key2", "hello");
另一种是java对象
,这是不能直接给bundle的,而要通过序列化
后再给bundle,然后对象会以二进制流形式传输,直到目标组件接受到bundle后,要对该对象二进制数据反序列化
才能获取真实的的对象。
那么如何对对象进行序列化呢?
两种方法。
bundle.putSerializable(Key, Object);
bundle.putParcelable(Key, Object);
那么
这两种机制有何区别?
存储
在外部设备,在需要
时重新生成
对象(采用java反射
机制)。主要用于外部设备保存对象状态,网络传输对象等场景。缺点是产生很多中间对象及造成一定的GC(垃圾回收),简而言之Serialize更慢
;移动设备
的轻量级高效
对象序列化机制。整个过程均在内存进行,不涉及外部设备,反序列化时读取的就是原对象,而不会创建新对象。简单来说Parcel更快
;不过它使用复杂
。这一步我们知道,要对对象进行序列化后才可以放入bundle由intent传递给其他组件,那么,
为什么需要对对象序列化后才能通过intent在组件间传递呢!?
以startActivity(intent)为例,该函数作用时从A Activity中启动B Activity,同时把数据打包给intent并传递给B。也就是说,如果intent里的数据有java对象,那就要序列化这个对象才能传递给B。
下面直接给出原因:(详细可参见从源码角度轻松学习Intent机制)
因为在启动B Activity过程中,需要离开应用程序所在进程
,转而调用native方法,进入linux kernel进程
中去执行activity切换的实际操作。完成后再重新把传输数据带回到应用程序进程
中,对原始打包数据进行解析。
也就是说,在启动B Activity过程中,所打包的数据要经过不同进程:应用程序->linux kernel->应用程序
,而java对象是无法直接在进程间传输的
(见下文),所以,我们需要提前序列化java对象,才能让它经得住后面跨进程传输
的考验。
什么是进程?
简单来说,一个进程往往代表一个应用程序。操作系统会为每一个进程分配一定的内存空间
等资源,然后进程就在这块内存里跑。
什么是进程间通信?
一般而言,为了保证安全,进程获得的内存空间时一块抽象的内存,然后会映射到实际的某一块物理内存,从而,每个进程都无法访问其他进程所在内存里的数据
。比如手机上开了qq和某银行客户端,操作系统会为他俩创建两个独立的内存区供运行,而qq进程是无法访问到银行客户端数据的,这就保证了数据的安全性。
但是,带来的缺陷是,进程间无法直接进行数据传输,所以要引入特有的进程间通信机制。
进程间可以直接传递对象吗?
前面知道,不同进程间通信,也就意味着在两块不同的物理内存间传递数据
。首先,原生的数据如int string数据是可以传递的,只要你说明这个数据时什么类型,那么就可以在目标进程里复原。但是对象数据,如果直接把对象传递过去,目标进程是无法复原的
,因而也无法识别。
Android系统中不同应用程序之间通信示意图。一个进程代表一个应用程序。
附加:IPC机制中很重要的是Binder机制,利用Binder实现不同进程间传递。这部分内容面试一般不会问的太难。
目前本人还在整理该部分内容,继续更新中。
前面提到了进程间通信,下面讲解下Android里的多线程管理,后面会讲解线程间通信。
首先,线程基本概念此处不过多讲解,只要知道线程是轻量级进程,在有限的进程内存空间资源中去执行实际操作。
什么是Main Thread 和 Worker Thread?
当应用程序开启时会自动创建一个主线程 (Main Thread),也叫UI线程,主要功能是完成UI界面绘制和与用户交互
。除主线程之外的其他线程称为子线程或Worker Thread。这些线程往往用执行耗时操作
如网络通信或数据库访问等。
如果在主线程中执行耗时操作,那么在执行过程中,就无法绘制界面或响应用户操作,在用户看来就是卡顿
,可能造成ANR现象,破坏用户体验。
主线程是线程不安全的
网上很多地方解释线程不安全
并非解释原因,而是在‘解释’结果,即:(因为主线程是线程不安全的,所以)UI控件只能在主线程中操作,而不能在其他线程中操作,否则多个线程同时操作一个控件会出错。
这种解释不仅没解释为何主线程是线程不安全的,反而让人感觉android系统里限定了只能在主线程操作ui元素,容易误解为那不是很安全吗?
我的解释是:
首先我们是的的确确可以通过代码,在子线程里操作UI元素,然后引发程序崩溃。假设主线程是安全的,那么安全的情况是:即使我们不小心
在子线程操作UI也不用担心,因为系统会屏蔽这种操作。而实际上系统并未屏蔽
,只要开发者在子线程操作UI元素,很有可能会导致崩溃。所以我们才说android系统里主线程并不安全。
附加知识:什么是线程安全/不安全?
在多线程环境里,往往一段代码会被多个线程分别执行。而常见的情况是一个线程执行了该段代码的一部分后,
会被另一个线程抢走时间片又去执行这段代码,并修改其中变量。
当原线程再次回来继续运行时,其实里面的变量已经被别人改动了但它却不知,最后会导致错误。
这种线程就是不安全的。而安全的线程在执行一段代码时,只要没执行完,
其他线程就不能来执行这段代码或修改变量知道它执行完。
那么
多个线程间时如何通信的呢?
这里就涉及到另一套机制handler、looper、MessageQueue机制,在本人另一篇文章中有生动详细
的描述,见Handler实现机制
简单来说,每个线程拥有上面这三个东西,如线程A想发送消息给线程B,那么在线程A中调用线程B的handler
来发送消息,消息会自动发送线程B的消息队列
中,同时线程B的looper在不断遍历这个队列
,如果发现有新消息就会自动去处理。
常见问题:
如何避免发生ANR(Application Not Response)现象呢?
尽量在子线程中执行耗时操作(如网络请求或数据库读取等)或者资源开销较大的操作,当子线程执行完毕后,利用handler通知主线程做出更新。
前面提到了,每个应用程序运行在独立的进程中(实际是一个独立的Dalvik进程),而且系统会为它分配固定的内存。在内存使用中常常会发生内存泄漏
(memory leak)和内存溢出
(OOM),其中,内存溢出非常严重,往往会导致程序崩溃。所以,合理有效的管理内存非常的重要。
详细的管理(包括面试重点:图片缓存机制)均可以参考本人另一篇文章:Android之内存管理及优化
此处不再赘述。
只说一下三种图片缓存思路:
文章还在继续更新中,读者有感兴趣的话题可以在评论里回复
标签:
原文地址:http://www.cnblogs.com/xinmengwuheng/p/5790845.html