Android应用模型的设计思想取自web2.0的Mashup概念(混搭
Mashup 构造应用的三要素:组件(Component)(核心部分)、链接、配置
组件:界面组件Activity、服务组件service、数据源组件Content Provider、触发器组件Broadcast Receiver。
链接:组件间的通信信道。例:与界面组件通过Intent对象,与数据源组件通信用URI
配置:配置是用来描述组件的功能和实现特征的信息。一个组件只有把相关信息写到配置文件里才会被系统承认
Android的组件管理服务就是通过配置文件中的信息去了解每个组件的特征,
Android中组建的执行时的最小聚合单元是任务
R类相当于应用资源的目录列表,通过它可以定位到界面所需的资源。通过Activity.setContentView()来将资源信息设置到界面的内容区域中
大致分两类: 回调 和 监听
上述的交互界面首次构造后会放入缓存 以此来减少反复构建和销毁资源 提升用户体验
首先Android是个多任务的操作系统,为保证充足的内存空间来执行任务,会在任务过多时自动结束掉部分应用和组件
Android采用的是进程托管的策略,后台的应用进程在内存紧张时会被终止
作为开发者就要根据组件的生命周期来妥善维护好相关的状态
同一任务中的界面组件会按照栈模型线性排列
没用到过。。。不说了
例如键盘消隐、屏幕朝向、语言etc
通过Activity配置项configChanges来设置组件不随某个配置信息变化进行销毁重建,
可以在Activity.onConfigurationChanged函数中更精细的处理相关配置的变化事件
Activity类派生自android.content.Context类
Context类提供了应用运行的基本环境是个组件和系统服务通信的桥梁
运行模式上:没有运行在独立的进程或者线程中 ,构造于应用进程中,跟其它组件一样都运行在进程的主线程(UI线程)上。
在服务组件中执行耗时操作可能会岛主主线程阻塞或者界面假死
使用方式上: 与前端界面组件建立双相连接 提供数据和功能支持,还可以单向接受Intent请求,进行数据的分析处理和功能调度
构造一个扮演调用角色的服务组件需要实现的函数是 Service.onStartCommand。
当调用组件通过Context.startService发出请求后对应服务组件的Service.onStartCommand就会被调用,
耗时操作要放入独立线程中处理
1.)配置文件中加 process参数
2.)服务组件中另起一个独立线程
3.)通过android.app.IntentService来执行(最简单
IntentService实现:启东市会在Service.onCreate函数中建立一个后台线程,在后台等待事件。
当onStartCommand接到相关的Intent参数时 主进程会将其打包发送到后台线程中,在Service.onHandleIntent函数中进行处理
当调用者通过Context.bindService函数来帮顶服务组件建立连接,onStartCommand函数将不再会被调用,调用的是onBind函数
----------------------
activity 调用一对方法最后是 ContentResolver.requestSync(mAccount, authority, bundle);//authority 是一个文件,
在manifest.xml文件中通过它找到对应的service,然后service中会找到 有一腿的AbstractThreadedSyncAdapter 的派生类,
在派生类里会发现跟他有一腿的client 及apiClient。。。到这里事就办完了。(补一嘴,apiClient去取来的数据 要序列化处理)
触发器被狗仔出来后通常只执行BroadcastReceiver.onReceive方法,便结束了其生命周期,故触发器通常被当做函数使用
跑在主线程这光溜大道上
两种监听事件的方法,(1)冷插拔-->将触发器组件的相关信息写到应用的配置文件里。(多用于后台监听
(2)热插拔->通过Context.registerReceiver和Context.unregisterReceiver,
在Activity.onResume函数中注册触发器,在onPause中注销
出发频率较高的适合用热插拔。
两个方法 Context.sendBroadcast和 Context.sendOrderedBroadcast
前者,所有注册了该广播的事件触发器组件都会得到事件通知
后者,一招优先级来依次处理事件,中间某个操蛋的可以通过BroadcastReceive.abortBroadcasrt方法终止掉这个广播,就没后边排队的触发器什么事了
在有序广播事件的传递过程中可以通过BroadcastReceive.setResult等函数在事件消息中附加额外数据,用getResultData等来得到数据
默认触发器组件。。。名字就很说明问题了,就是怕没人管。只要没有被提前终止,该触发器就会在最后响应一下这事件
存在就是为了各个应用间共享数据!
通过URI俩定位通过SQL来描述具体的操作
URI分四块,(1)类型描述:表明这个URI指向的是一个数据源组件
(2)地址描述:表示数据源地址。常用java包模式进行命名
(3)操作描述(可选)
(4)参数描述(可选):一个ID值,表示该操作下的一条数据
例:content://com.duguhome.provider.sample/items
content://com.duguhome.provider.sample/items/1
数据源接口集合了REST标准和数据库设计的概念
数据源接口中的一些参数都是按照SQL的方式和语法来提供的
对于查询操作Android返回的是一个数据指针android.database.Cursor的对象,只有被使用的数据才读出,好处:就是好!!
在配置文件中必需有authorities信息
没用Intent机制 他跟调用者耦合最大
数据源组件也构造与主线程中,so。。。
可以用android.content.AsyncQueryHandler对象来实现对数据源组件的异步访问
细说AsyncQueryHandler:
每个对象都会启动一个后台线程,、
不说了 ....上图:
有一个很重要的类 android.content.ContentResolver,干的活是将各URI定位到具体的数据源组件,并进行增产改查等操作
ContentResolver对象还有个小三-->ProviderMap(数据源组件的缓存对象,哈希表一个)
这里可以选择串行执行和并发执行(只提一嘴 详细的再看
大数据的时候也不用怕,android采用了数据窗口的模式,数据指针对象android.database.Cursor中有一个android.database.CursorWindow对象
它会在调用者的一端缓存部分数据(指针指向未知相关的若干条数据)这部分为了效率用C++做的
它将应用所包含的组件各组件的能力和配置一级应用环境介绍给Android框架层的各个服务
可以定义第三方访问其中组件和资源所需要的权限,同时也可以通过配置文件声明其所需的权限
定义了权限还要部署到对应的组件上才能生效!
权限死锁:被调用的组件需要性数据源中读取信息,蛋挞并不能提前知晓并声明对数据源的使用权限,从而就够蹭了一个无法解开的死锁
权限赦免机制:调用第三方组件是可以在Intent对象的标志位(flag)中添加 Intent.FLAG_GRANT_READ_URI_PERMISSION等权限赦免相关的标志位
临时允许这个被调用的组件跳过权限约束直接访问特定URI路径下的资源信息
题外:android为保障用户不受侵扰 还用了其他相关系统
(1)应用数据的私有性,利用linux本身的权限机制,Android为买个应用开设一个独立的Linux账户,有独立的home目录
(2)签名机制,Android使用其定义的java包名来区分的,但包相同时后者会覆盖前者,加上签名就需要两者都一直才可以覆盖了
etc....
安装时会验证当前设备是否满足应用配置文件生命的环境信息
当设置的兼容SDK版本 比当前版本低的时候就需要处理一下两个版本间的接口变更问题
java虽然有运行时与此变异的机制但是它运行时加载单元式类
所以在编写SDK版本相关代码是要用类而不是函数为隔离单位,
class MethodInLowSdk {
public static void amethod();
};
class MethodInHighSdk {
public static void amethod();
};
----================
使用时 android.os.Build.VERSION.SDK_INT来判断SDK版本
基本信息:类名name、组件名label、组件图标icon etc
接口描述:
运行模型描述:默认在主进程,特殊爱好的用process项来设置特定的进程
权限描述:权限配置中定义的权限若要应用在具体组件上,用permission参数进行设置
元数据描述:任意存 键值对信息 用于告知系统为组建附件一些系统功能 用
可用性:没错跟你想的不太一样。应用中一些数据为合理设置 某些组件在应用安装后会处于不可用状态,设置enable,只让应用本身用设置exported为false
4.) 你猜