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