2019独角兽企业重金招聘Python工程师标准>>> 
Remote procedure calls (RPC) using Android’s inter-process communications largely
replace the use of the Java Native Interface (JNI) in Android. In almost all cases, a
remote procedure call is efficient enough to make it a superior alternative to loading a
library—especially one that dynamically allocates a significant amount of memory—
into the Java virtual machine’s address space. And if a process exposing an RPC interface
fails, it is less likely to bring down the Android UI with it.
Android inter-process communication behaves a lot like JNI: the caller’s thread is
blocked until the result is returned. Marshalling data across the IPC boundary is about
the same amount of work as data conversions in JNI. But Binder-based remote procedure
calls have a significant advantage over JNI: if non-Java code crashes or runs out
of memory, the caller of a remote procedure call gets an error that must be handled,
but the Java application does not crash. Remote procedure calls are a more robust way
to call “external” libraries and subject the Java application to fewer risks in the form of
clashing memory management strategies and other differences between Java applications
and libraries implemented in languages other than Java.
What Binder Doesn’t Do
There are at least three things Binder doesn’t do, compared with other systems capable
of providing similar functionality:
• Binder does not manage version information.
• Binder does not traverse networks.
• It does not enable applications to discover interfaces.
Some inter-process communications systems enable the two sides of an inter-process
API to negotiate version compatibility. Binder, along with the higher-level mechanisms
built on Binder, does not do this. This means APIs built on Binder should remain compatible
with older versions if the APIs are open for other applications to use, and it
means that consumers of remote APIs should be resilient to failures caused by incompatibilities.
Make sure to handle those exceptions!
Binder-based inter-process communication is also limited to a single node: it won’t take
you across the network to other Android systems. This is a limitation, to be sure, but
it is appropriate to a mobile handset, where endpoint-to-endpoint data connections are
rarely used and often blocked by the routing in a mobile data network.
Binder and Linux
Binder is not a widely used IPC mechanism in Linux. D-BUS is the most widely used
IPC mechanism, and has become commonly used in both server and desktop Linux
distributions and in numerous applications and daemons. In contrast, Binder was developed
by Palm, abandoned, open-sourced as OpenBinder, and subsequently adopted
by Google for Android.
Binder may not be the choice of most other Linux distributions, but it isn’t a bad choice:
Binder is used throughout Android, including performance-critical parts of Android,
such as the Surface Flinger, Android’s system for sharing the screen among multiple
processes. Binder is simple and performant. It is also an example of the ways in which
Android diverges from the typical use of Linux in mobile handsets and other small
devices.
Android is not a shrunken desktop Linux. The use of Binder, the way Linux user IDs
are used to “sandbox” applications, the unique 2D graphics library, and other design
decisions are all in the service of making Android an ideal platform for running Android
applications. It is debatable whether every design decision that diverges from standards
was worth it, and developers who have started porting and extending Android actively
debate these issues, but some things are certain:
• Android performs well. None of the unique design decisions that went into Android
were to the detriment of performance. Android performance is good enough
to allow multitasking—something Apple abjures in iPhone so as not to risk the
multimedia user experience.
• Android is not attempting to set a general direction for Linux, or even for embedded
Linux. Android has, of course, charted a radically different course for application
development. Android is consciously different and optimized for a range of smartphone
hardware: big and powerful enough to run a browser, but not encroaching
on the laptop format enough to need a multiwindow user interface. Android, as a
whole, is meant to be just right for its intended purpose.
Why Android
Execution Environment
Components of an Android Application
Android Activity Lifecycle
Android Service Lifecycle
Setting Up Your Android Development Environment
Setting Up Your Development Environment
Hello, Android
Writing HelloWorld
Using the Android Development Environment for Real Applications
Main Sample Application
Downloading the MJAndroid Code
Building and Running the MicroJobs Application
Digging a Little Deeper
Running an Application
Startup Code and Resources in the MJAndroid Application
Startup Code and Resources in the MJAndroid Application
Initialization in MicroJobs
More Initialization of MicroJobs.
Debugging Android Applications
Debugging Android Applications
The Debugger
Logcat
Writing your own logcat entries
Dalvik Debug Monitor Service
The ApiDemos Application
The ApiDemos Application
Finding the Source to an Interesting Example
Adding Your Own Examples to ApiDemos
Signing and Publishing Your Application
Signing and Publishing Your Application
Attach an End User License Agreement If Desired
Getting a Signing Certificate for an Application You Are Going to Ship
Getting a Signing Certificate While Debugging
Signing Your Application
Persistent Data Storage
Persistent Data Storage
Basic Structure of the MicroJobsDatabase Class
Reading Data from the Database
Updating data already in the database
Content Providers
Content Providers
Consuming a Content Provider
Update data
Delete data
Location and Mapping
The Google Maps Activity
MapView and MyLocationOverlay Initialization
Pausing and Resuming a MapActivity
Controlling the Map with the KeyPad
Connecting to a Location Provider
Updating the Emulated Location
Building a View
Assembling a Graphical Interface
Wiring Up the Controller
Listening to the Model
Listening for Touch Events
Alternative Ways to Handle Events
The Menu
A Widget Bestiary
A Widget Bestiary
Adapters and AdapterViews
ViewGroups
ScrollView
Layouts
TableLayout
Drawing 2D and 3D Graphics
Drawing 2D and 3D Graphics
Arrangement
Matrix transformations
Drawables
Bling
Animation
OpenGL Graphics
Inter Process Communication
Inter Process Communication
Getting a Result via Inter Process Communication
Android Interface Definition Language
Classes Underlying AIDL
Android IPC Compared with Java Native Interface
Simple Phone Calls
Simple Phone Calls
Exploring the Phone Code Through the Debugger
Exception Handling
Telephony State Information and Android Telephony Classes
Telephony State Information and Android Telephony Classes
Android Telephony Internals
The android Package
Exploring Android Telephony Internals
APPENDIX
Wireless Protocols - See more at: http://www.developer.am/android/?page=Android%20IPC%20Compared%20with%20Java%20Native%20Interface#sthash.JcQ1gLHs.dpuf
replace the use of the Java Native Interface (JNI) in Android. In almost all cases, a
remote procedure call is efficient enough to make it a superior alternative to loading a
library—especially one that dynamically allocates a significant amount of memory—
into the Java virtual machine’s address space. And if a process exposing an RPC interface
fails, it is less likely to bring down the Android UI with it.
Android inter-process communication behaves a lot like JNI: the caller’s thread is
blocked until the result is returned. Marshalling data across the IPC boundary is about
the same amount of work as data conversions in JNI. But Binder-based remote procedure
calls have a significant advantage over JNI: if non-Java code crashes or runs out
of memory, the caller of a remote procedure call gets an error that must be handled,
but the Java application does not crash. Remote procedure calls are a more robust way
to call “external” libraries and subject the Java application to fewer risks in the form of
clashing memory management strategies and other differences between Java applications
and libraries implemented in languages other than Java.
What Binder Doesn’t Do
There are at least three things Binder doesn’t do, compared with other systems capable
of providing similar functionality:
• Binder does not manage version information.
• Binder does not traverse networks.
• It does not enable applications to discover interfaces.
Some inter-process communications systems enable the two sides of an inter-process
API to negotiate version compatibility. Binder, along with the higher-level mechanisms
built on Binder, does not do this. This means APIs built on Binder should remain compatible
with older versions if the APIs are open for other applications to use, and it
means that consumers of remote APIs should be resilient to failures caused by incompatibilities.
Make sure to handle those exceptions!
Binder-based inter-process communication is also limited to a single node: it won’t take
you across the network to other Android systems. This is a limitation, to be sure, but
it is appropriate to a mobile handset, where endpoint-to-endpoint data connections are
rarely used and often blocked by the routing in a mobile data network.
Binder and Linux
Binder is not a widely used IPC mechanism in Linux. D-BUS is the most widely used
IPC mechanism, and has become commonly used in both server and desktop Linux
distributions and in numerous applications and daemons. In contrast, Binder was developed
by Palm, abandoned, open-sourced as OpenBinder, and subsequently adopted
by Google for Android.
Binder may not be the choice of most other Linux distributions, but it isn’t a bad choice:
Binder is used throughout Android, including performance-critical parts of Android,
such as the Surface Flinger, Android’s system for sharing the screen among multiple
processes. Binder is simple and performant. It is also an example of the ways in which
Android diverges from the typical use of Linux in mobile handsets and other small
devices.
Android is not a shrunken desktop Linux. The use of Binder, the way Linux user IDs
are used to “sandbox” applications, the unique 2D graphics library, and other design
decisions are all in the service of making Android an ideal platform for running Android
applications. It is debatable whether every design decision that diverges from standards
was worth it, and developers who have started porting and extending Android actively
debate these issues, but some things are certain:
• Android performs well. None of the unique design decisions that went into Android
were to the detriment of performance. Android performance is good enough
to allow multitasking—something Apple abjures in iPhone so as not to risk the
multimedia user experience.
• Android is not attempting to set a general direction for Linux, or even for embedded
Linux. Android has, of course, charted a radically different course for application
development. Android is consciously different and optimized for a range of smartphone
hardware: big and powerful enough to run a browser, but not encroaching
on the laptop format enough to need a multiwindow user interface. Android, as a
whole, is meant to be just right for its intended purpose.
Why Android
Execution Environment
Components of an Android Application
Android Activity Lifecycle
Android Service Lifecycle
Setting Up Your Android Development Environment
Setting Up Your Development Environment
Hello, Android
Writing HelloWorld
Using the Android Development Environment for Real Applications
Main Sample Application
Downloading the MJAndroid Code
Building and Running the MicroJobs Application
Digging a Little Deeper
Running an Application
Startup Code and Resources in the MJAndroid Application
Startup Code and Resources in the MJAndroid Application
Initialization in MicroJobs
More Initialization of MicroJobs.
Debugging Android Applications
Debugging Android Applications
The Debugger
Logcat
Writing your own logcat entries
Dalvik Debug Monitor Service
The ApiDemos Application
The ApiDemos Application
Finding the Source to an Interesting Example
Adding Your Own Examples to ApiDemos
Signing and Publishing Your Application
Signing and Publishing Your Application
Attach an End User License Agreement If Desired
Getting a Signing Certificate for an Application You Are Going to Ship
Getting a Signing Certificate While Debugging
Signing Your Application
Persistent Data Storage
Persistent Data Storage
Basic Structure of the MicroJobsDatabase Class
Reading Data from the Database
Updating data already in the database
Content Providers
Content Providers
Consuming a Content Provider
Update data
Delete data
Location and Mapping
The Google Maps Activity
MapView and MyLocationOverlay Initialization
Pausing and Resuming a MapActivity
Controlling the Map with the KeyPad
Connecting to a Location Provider
Updating the Emulated Location
Building a View
Assembling a Graphical Interface
Wiring Up the Controller
Listening to the Model
Listening for Touch Events
Alternative Ways to Handle Events
The Menu
A Widget Bestiary
A Widget Bestiary
Adapters and AdapterViews
ViewGroups
ScrollView
Layouts
TableLayout
Drawing 2D and 3D Graphics
Drawing 2D and 3D Graphics
Arrangement
Matrix transformations
Drawables
Bling
Animation
OpenGL Graphics
Inter Process Communication
Inter Process Communication
Getting a Result via Inter Process Communication
Android Interface Definition Language
Classes Underlying AIDL
Android IPC Compared with Java Native Interface
Simple Phone Calls
Simple Phone Calls
Exploring the Phone Code Through the Debugger
Exception Handling
Telephony State Information and Android Telephony Classes
Telephony State Information and Android Telephony Classes
Android Telephony Internals
The android Package
Exploring Android Telephony Internals
APPENDIX
Wireless Protocols - See more at: http://www.developer.am/android/?page=Android%20IPC%20Compared%20with%20Java%20Native%20Interface#sthash.JcQ1gLHs.dpuf