Developing for Android VII The Rules: Framework
2015-06-07 21:45
507 查看
This section details important details related to Android framework APIs and usage patterns.
Application components (activities, services, providers, receivers) are interfaces for your application to interact with the operating system; don’t take them as a recommendation of the facilities you should architect your entire application around. Each of
these components has very specific semantics with the operating system, and should typically only be used when those semantics are desired:
Activity is a top-level UI entry point into your application. It corresponds roughly to the main() entry of a traditional operating system (that is, what runs when the user clicks
on your app’s icon), except Android allows you to have multiple such entry-points for different purposes. You should implement an Activity when you want to allow others to launch specific parts of your app, such as for executing a share operation or opening
some content contained in the app. If you have UI that is only going to be launched by your own app, there is no need to implement it as an Activity, you can just as well do this by transforming the state of the currently shown UI (such as through fragments).
Before fragments existed in the platform, architecting an application around multiple activities was fairly standard, but it is no longer necessary unless you need that specific design.
Service is how an application indicates to the operating system that it needs to perform a longer-running operation outside of the normal Activity UI flow. It may be self-running
(through Context.startService()), or running on behalf of of another process (through Context.bindService()). If you do not need either of these behaviors, you should not use a Service.
For example, if you have background work to do that does not need to keep itself running (such as downloading content for your UI that you could resume later when the user returns to the UI) you should use local threading primitives such as AsyncTask, Loader, HandlerThread,
etc. Using a Service is much more resource-intensive (as your service needs to be tracked as part of the global system state) and opens the door to all kinds of bad bugs where your services is left running when it shouldn’t be (this is a very common problem
in Android apps, and is harmful to the system). Likewise, if you want to have an association between two pieces of code but they are running in the same local process, don’t use bindService(); instead, use regular callbacks and other facilities. This will
be easier to write, easier to understand, and less resource-intensive.
Also, beware a common gotcha with AsyncTask: given the asynchronous nature of AsyncTask, it’s possible that an Activity may finish by the time that results come back in. Make sure that you check the status of the Activity before using those results.
Broadcast Receiver is how an application can indicate that it is interested in certain events that may happen, and have itself run when they occur.
Use Service either as a bound-service or as a started-service, avoid blending both styles.
If necessary, a bound-service may self-start in order to continue performing work in the background, but it must also finish itself when that work is completed. (This is somewhat error-prone as it may conflict with external requests to start-service.)
Use broadcasts for delivering independent events; use services for processes with state and on-going lifecycle.
Objects are copied as their are serialized through the Binder, so the larger the object, the longer the process of passing it through.
The activity manager on Android will aggressively kill activities when the system is resource-constrained. If your activity is tied too closely to its background service, you could get into a situation where killing one made the other unusable. An example of
good separation of functionality includes a music app with a UI app and a service for playing content, where the UI activity could be killed without affecting music playback from its background service.
Avoid Architecting Around Application Components
Application components (activities, services, providers, receivers) are interfaces for your application to interact with the operating system; don’t take them as a recommendation of the facilities you should architect your entire application around. Each ofthese components has very specific semantics with the operating system, and should typically only be used when those semantics are desired:
Activity is a top-level UI entry point into your application. It corresponds roughly to the main() entry of a traditional operating system (that is, what runs when the user clicks
on your app’s icon), except Android allows you to have multiple such entry-points for different purposes. You should implement an Activity when you want to allow others to launch specific parts of your app, such as for executing a share operation or opening
some content contained in the app. If you have UI that is only going to be launched by your own app, there is no need to implement it as an Activity, you can just as well do this by transforming the state of the currently shown UI (such as through fragments).
Before fragments existed in the platform, architecting an application around multiple activities was fairly standard, but it is no longer necessary unless you need that specific design.
Service is how an application indicates to the operating system that it needs to perform a longer-running operation outside of the normal Activity UI flow. It may be self-running
(through Context.startService()), or running on behalf of of another process (through Context.bindService()). If you do not need either of these behaviors, you should not use a Service.
For example, if you have background work to do that does not need to keep itself running (such as downloading content for your UI that you could resume later when the user returns to the UI) you should use local threading primitives such as AsyncTask, Loader, HandlerThread,
etc. Using a Service is much more resource-intensive (as your service needs to be tracked as part of the global system state) and opens the door to all kinds of bad bugs where your services is left running when it shouldn’t be (this is a very common problem
in Android apps, and is harmful to the system). Likewise, if you want to have an association between two pieces of code but they are running in the same local process, don’t use bindService(); instead, use regular callbacks and other facilities. This will
be easier to write, easier to understand, and less resource-intensive.
Also, beware a common gotcha with AsyncTask: given the asynchronous nature of AsyncTask, it’s possible that an Activity may finish by the time that results come back in. Make sure that you check the status of the Activity before using those results.
Broadcast Receiver is how an application can indicate that it is interested in certain events that may happen, and have itself run when they occur.
Services Should Be Bound or Started, Not Both
Use Service either as a bound-service or as a started-service, avoid blending both styles.If necessary, a bound-service may self-start in order to continue performing work in the background, but it must also finish itself when that work is completed. (This is somewhat error-prone as it may conflict with external requests to start-service.)
Prefer Broadcast over Service for Independent Events
Use broadcasts for delivering independent events; use services for processes with state and on-going lifecycle.
Avoid Passing Large Objects Through Binder
Objects are copied as their are serialized through the Binder, so the larger the object, the longer the process of passing it through.
Isolate UI processes from Background Services
The activity manager on Android will aggressively kill activities when the system is resource-constrained. If your activity is tied too closely to its background service, you could get into a situation where killing one made the other unusable. An example ofgood separation of functionality includes a music app with a UI app and a service for playing content, where the UI activity could be killed without affecting music playback from its background service.
相关文章推荐
- Developing for Android VI The Rules: Storage
- Android ActionBar的基本用法
- Android 自定义Dialog样式
- android触摸事件处理流程
- android SQLite数据库的简单用法
- Android ActionBar 一步一步分析 (转)
- android中多选ListView的实现
- java(android)多线程下载,和多线程断点下载
- Android应用防止截屏
- java用正则表达式判断字符串中是否仅包含英文字母、数字和汉字 分类: Android JAVA 2015-06-07 21:08 31人阅读 评论(0) 收藏
- android 判断字符串是否为数字或中文或字母
- android 判断字符串是否为数字或中文或字母 分类: Android JAVA 2015-06-07 21:07 29人阅读 评论(0) 收藏
- Android的DrawText详解
- Android 绘图和shape圆形
- Developing for Android V: The Rules: Language and Libraries
- android实现边框圆角
- Android内核开发:图解Android系统的启动过程
- Android内核开发:图解Android系统的启动过程
- Android应用AsyncTask处理机制详解及源码分析
- Android Bitmap回收 注意事项