㈠ 如何在两个app之间传递参数
有时候需要从一个APP中启动另外一个APP，比如Twitter/微信等。 如果你不知道那个APP的Activity，但是知道包名(package name)，那么可以使用如下的方法： Intent LaunchIntent = getPackageManager().getLaunchIntentForPackage("com.package.address"); startActivity(LaunchIntent); 如果APP之间有合作关系，可以获得合作APP的清单文件(manifest)，那么可以从该文件中获知package/activity, 可使用如下的方法来启动该APP特定活动界面： Intent intent = new Intent(Intent.ACTION_MAIN); intent.setComponent(new ComponentName("com.package.address","com.package.address.MainActivity")); startActivity(intent); 如果要在启动APP时传递参数，可以在意图(Intent)中设置: intent.putExtra("firstKeyName","FirstKeyValue"); intent.putExtra("secondKeyName","SecondKeyValue");
㈡ 如何在两个程序之间传递消息
一般来说在常用的操作系统中有以下几种方式实现进程间通信
管道法（即把一个程序的输入和另一个程序的输出对接起来，实现方式根据自己使用编程语言的不同各异）
信号法，（利用操樱肆作系统自带的信号操作，让一个程序给戚颂梁另一个发信号高运....但是信号的种类有限，所以很少用
共享数据库，安装数据库软件，两个程序能访问同一个数据库，在数据库里放消息
共享网络端口，（可以理解成一个进程使用一个网络端口，另一个想跟他通信的时候就直接去访问这个端口
㈢ android跨进程通信
本文整理和引用他人的笔记，旨在个人复习使用。
参考链接：
https://blog.csdn.net/fanleiym/article/details/83894399
https://github.com/274942954/AndroidCollection/blob/master/Docs/Android%E7%9F%A5%E8%AF%86%E7%82%B9%E6%B1%87%E6%80%BB.md#%E8%BF%9B%E7%A8%8B%E7%94%9F%E5%91%BD%E5%91%A8%E6%9C%9F
https://www.kaelli.com/4.html
https://carsonho.blog.csdn.net/article/details/73560642?utm_medium=distribute.pc_relevant.none-task-blog--1.e_weight&depth_1-utm_source=distribute.pc_relevant.none-task-blog--1.e_weight
默认情况下，一个app只会运行在一个进程中，进程名为app的包名。
1. 分散内存的占用
Android系统对每个应用进程的内存占用是有限制的，占用内存越大的进程，被系统杀死的可能性就越大。使用多进程可以减少主进程占用的内存，避免OOM问题，降低被系统杀死的概率。
2. 实现多模块
一个成熟的应用一定是多模块化的。项目解耦，模块化，意味着开辟新的进程，有独立的JVM，带来数据解耦。模块之间互不干预，团队并行开发，同时责任分工也很明确。
3. 降低程序奔溃率
子进程崩溃不会影响主进程的运行，能降低程序的崩溃率。
4. 实现一些特殊功能
比如可以实现推送进程，使得主进程退出后，能离线完成消息推送服务。还可以实现守护进程，来唤醒主进程达到保活目的。还可以实现监控进程专门负责上报bug，进而提升用户体验。
android:process 属性的值以冒号开头的就是 私有进程 ，否则就是 公有进程 。当然命名还需要符合规范，不能以数字开头等等。
1. 前台进程
2. 可见进程
3. 服务进程
4. 后台进程
5. 空进程
Android 会将进程评定为它可能达到的最高级别。另外服务于另一进程的进程其级别永远不会低于其所服务的进程。
创建新的进程时会创建新的Application对象，而我们通常在Application的onCreate方法中只是完成一些全局的初始化操作，不需要多次执行。
解决思路：获取当前进程名，判断是否为主进程，只有主进程的时候才执行初始化操作
获取当前进程名的两种方法：
Application中判断是否是主进程（方法1例子）：
Serializable 和 Parcelable是数据序列化的两种方式，Android中只有进行序列化过后的对象才能通过intent和Binder传递。
通常序列化后的对象完成传输后，通过反序列化获得的是一个新对象，而不是原来的对象。
Serializable是java接口，位于java.io的路径下。Serializable的原理就是把Java对象序列化为二进制文件后进行传递。Serializable使用起来非常简单，只需直接实现该接口就可以了。
Parcelable是Google为了解决Serializable效率低下的问题，为Android特意设计的一个接口。Parcelable的原理是将一个对象完全分解，分解成可以传输的数据类型（如基本数据类型）再进行传递。
通常需要存到本地磁盘的数据就使用Serializable，其他情况就使用效率更高的Parcelable。
IPC 即 Inter-Process Communication (进程间通信)。Android 基于 Linux，而 Linux 出于安全考虑，不同进程间不能之间操作对方的数据，这叫做“进程隔离”。
每个进程的虚拟内存空间（进程空间）又被分为了 用户空间和内核空间 ， 进程只能访问自身用户空间，只有操作系统能访问内核空间。
由于进程只能访问自身用户空间，因此在传统的IPC中，发送进程需要通过_from_user（系统调用）将数据从自身用户空间拷贝到内核空间，再由接受进程通过_to_user从内核空间复拷贝到自身用户空间，共需要拷贝2次，效率十分低下。Android采用的是Binder作为IPC的机制，只需复制一次。
Binder翻译过来是粘合剂，是进程之间的粘合剂。
Binder IPC通信的底层原理是 通过内存映射（mmap），将接收进程的用户空间映射到内核空间 ，有了这个映射关系，接收进程就能通过用户空间的地址获得内核空间的数据，这样只需发送进程将数据拷贝到内核空间就可完成通讯。
一次完整的Binder IPC通信：
从IPC的角度看，Binder是一种跨进程通信机制（一种模型），Binder 是基于 C/S 架构的，这个通信机制中主要涉及四个角色：Client、Server、ServiceManager和Binder驱动。
Client、Server、ServiceManager都是运行在用户空间的进程，他们通过系统调用（open、mmap 和 ioctl）来访问设备文件/dev/binder，从而实现与Binder驱动的交互。Binder驱动提供进程间通信的能力（负责完成一些底层操作，比如开辟数据接受缓存区等），是Client、Server和ServiceManager之间的桥梁。
Client、Server就是需要进行通信两个的进程，通信流程：
细心的你一定发现了，注册服务和获得服务本身就是和ServiceManager进行跨进程通信。其实和ServiceManager的通信的过程也是获取Binder对象（早已创建在Binder驱动中，携带了注册和查询服务等接口方法）来使用，所有需要和ServiceManager通信的进程，只需通过0号引用，就可以获得这个Binder对象了。
AIDL内部原理就是基于Binder的，可以借此来分析Binder的使用。
AIDL是接口定义语言，简短的几句话就能定义好一个复杂的、内部有一定功能的java接口。
先看看ICallBack.aidl文件，这里定义了一个接口，表示了服务端提供的功能。
被定义出来的java接口继承了IInterface接口，并且内部提供了一个Stub抽象类给服务端（相当于封装了一下，服务端只需继承这个类，然后完成功能的里面具体的实现）。
参考： https://www.cnblogs.com/sqchen/p/10660939.html
（以下是添加了回调的最终实现，可以看参考链接一步一步来）
为需要使用的类，创建aidl文件。
系统会自动在main文件下生成aidl文件夹，并在该文件夹下创建相应目录。
在java相同路径下创建Student类，这里不能使用@Parcelize注解，否则会报错
创建IStudentService.aidl，定义了一个接口，该接口定义了服务端提供的功能。创建完后rebuild一下项目 （每次创建和修改定义接口文件都要rebuild一下）
创建在服务端的StudentService
可以看见有回调，说明客户端也提供了接口给服务端来回调（双向通信，此时客户端的变成了服务端），即ICallBack.aidl
客户端是通过Binder驱动返回的Binder调用StudentService里的具体实现方法
AIDL使用注意：
Messenger可以在不同进程中传递 Message 对象，在Message中放入我们需要传递的数据，就可以轻松地实现数据的进程间传递了。Messenger 是一种轻量级的 IPC 方案，是对AIDL的封装，底层实现是 AIDL。
使用详见： https://blog.csdn.net/qq951127336/article/details/90678698
㈣ Android APP调起另外一个APP并传值
第一种：
第二种：
setClassName内部也是调用的setComponent。
调用方：
被调用方在AndroidManifest的Activity中添加自定义action：
被调用方数据接收：
第一银败种：
调用方通过点击H5网页上按钮
这种方法存在着弊端就是没办法判断手机上是否安装APP时，更适合打开自己APP中Activity。一般建议js与java进行交互调用原生的方法： WebViewJavascriptBridge 使用简单方便，并且避免了一些js脚本注入漏洞。
第二种：隐式调用
被调用方在AndroidManifest的Activity中添加自定义action：
被调用Activity中数据接收：
注意： 这两种方式只适合针对某个页面，都只是在自己应用中跳转第三方应用，并不是真正的唤醒，比如应用A已经在后台存在了，应用B调用以上两种方式后，只是在应用B中重新打开了一个应用A，此时的应用A是相当与存在两个，一前搏基个是在后台单独存在，一个是依存应用B存在，是添加到应用B的栈中的，当点击A页面里面的跳转按钮时才真正调起跳转到A应慧谨用。
㈤ 如何在两个app之间传递参数
把窗体的某部信息（控件或属性）设置为public static即可。。。
在窗体里的InitializeComponent();初始化方法里。。。你可以找到所有已添加的控件的创建信息。其它在最底部有控件的声明信息。。。你只要把private 改成public static即可。。。
不过还有一个问题。改成static静态成员的话。也相应的要把当前窗体内所有关于该对象的调用的“this.”都删除掉。因为static不属于任何对象。他是公用的对象。
而且，调用该对象的时候，可以用他所在的：类名.static对象名.。。。在该static声明的类中，可以不用类名。static对象名，直接static对象名即可，对象，方法，属性，都可以这样用，这是static的特点。
不过调用static对象的对象也得是static才可以。。。相关更具体对static的了解，你可以到网上查看。
如果你现在在Form1里的某个TextBox控件值改变时，相应的Form2的某个TextBox控件值也相应变化，可以这样写。
Form1:
要把该TextBox1的声明改成:
public static TextBox TextBox1;
指导到TextBox的TextChanged事件。
添加该事件:
private void TextBox1_TextChanged(object sender,Evetn..... e)
{
Form2.TextBox1.Text=Form2.TextBox1.Text;
}
Form2:
要把该TextBox1的声明改成:
public static TextBox TextBox1;
再用以上的代码即可。
㈥ android两个activity之间传值
Activity之间是没有办法直接传递数据的。Android的设计原则是，用Intent在不同的Activity和进程之间进行通信，但是通常来讲，Intent中只能存入基本数据类型和系统默认支持的比如Uri之类的。那么对于用户自己定义的数据结构是无法直接用Intent来传送的，如果想要通过Intent来传递自定义数据，可以让数据结构实现Parcelable接口，这样就可以把数据放入Intent。但是Intent的传送效率也不是很高，特别是当传递一些如Bitmap的大数据，用Intent传递超过500K的Bitmap，就会造成Framework层的Java Binder挂掉，结果就是传递不成功。
这点可以算成是Android的一个弊端，没有很好的解决方案。能做到的就是尽量设计的时候注意，尽量让Activity之间共享基本数据类型。
Android本身的应用中也深受其害，可以看到有很多应用程序的源代码中的主要的类在三千行以上的不在少数，比如Browser中的BrowserActivity有四千多行；Mms中的ComposeMessageActivity也有四千多行，等等。为什么一个类会如此之大，就是因为它们是程序的主页面，是业务的核心逻辑所在，里面也控制着很多的其他的数据结构，而又无法与另外的Activity共享，所以就只能在一个Activity里面做所的事情。
㈦ android开发中跨进程通信有几种方式
Android进程间通信的几种方式 定义多进程
第一：Android应用中使用多进程只有一个办法（用NDK的fork来做除外），就是在AndroidManifest.xml中声明组件时，用android:process属性来指定。
不知定process属性，则默认运行在主进程中，主进程名字为包名。
android:process = package:remote，将运行在package:remote进程中，属于全局进程，其他具有相同shareUID与签名的APP可以跑在这个进程中。
android:process = :remote ，将运行在默认包名:remote进程中，而且是APP的私有进程，不允许其他APP的组件来访问。
第二：多进程引发的问题
静态成员和单例失效：每个进程保持各自的静态成员和单例，相互独立。
线程同步机制失效：每个进程有自己的线程锁。
SharedPreferences可靠性下降：不支持并发写，会出现脏数据。
Application多次创建：不同进程跑在不同虚拟机，每个虚拟机启动会创建自己的Application，自定义Application时生命周期会混乱。
综上，不同进程拥有各自独立的虚拟机，Application，内存空间，由此引发一系列问题。
第三： 进程间通信
Bundle/Intent传递数据：
可传递基本类型，String，实现了Serializable或Parcellable接口的数据结构。Serializable是Java的序列化方法，Parcellable是Android的序列化方法，前者代码量少（仅一句），但I/O开销较大，一般用于输出到磁盘或网卡；后者实现代码多，效率高，一般用户内存间序列化和反序列化传输。
文件共享：
对同一个文件先后写读，从而实现传输，Linux机制下，可以对文件并发写，所以要注意同步。顺便一提，Windows下不支持并发读或写。
Messenger：
Messenger是基于AIDL实现的，服务端（被动方）提供一个Service来处理客户端（主动方）连接，维护一个Handler来创建Messenger，在onBind时返回Messenger的binder。
双方用Messenger来发送数据，用Handler来处理数据。Messenger处理数据依靠Handler，所以是串行的，也就是说，Handler接到多个message时，就要排队依次处理。
AIDL：
AIDL通过定义服务端暴露的接口，以提供给客户端来调用，AIDL使服务器可以并行处理，而Messenger封装了AIDL之后只能串行运行，所以Messenger一般用作消息传递。
通过编写aidl文件来设计想要暴露的接口，编译后会自动生成响应的java文件，服务器将接口的具体实现写在Stub中，用iBinder对象传递给客户端，客户端bindService的时候，用asInterface的形式将iBinder还原成接口，再调用其中的方法。
ContentProvider：
系统四大组件之一，底层也是Binder实现，主要用来为其他APP提供数据，可以说天生就是为进程通信而生的。自己实现一个ContentProvider需要实现6个方法，其中onCreate是主线程中回调的，其他方法是运行在Binder之中的。自定义的ContentProvider注册时要提供authorities属性，应用需要访问的时候将属性包装成Uri.parse("content://authorities")。还可以设置permission，readPermission，writePermission来设置权限。 ContentProvider有query，delete，insert等方法，看起来貌似是一个数据库管理类，但其实可以用文件，内存数据等等一切来充当数据源，query返回的是一个Cursor，可以自定义继承AbstractCursor的类来实现。
Socket：
学过计算机网络的对Socket不陌生，所以不需要详细讲述。只需要注意，Android不允许在主线程中请求网络，而且请求网络必须要注意声明相应的permission。然后，在服务器中定义ServerSocket来监听端口，客户端使用Socket来请求端口，连通后就可以进行通信。
㈧ 怎样把数据从一个程序传给另一个程序
有好几种基本的方法可以完成这项任务----你可以通过文件或内存来传递这些数据。这些方法的步骤都相当简洁：首先，定义在何处存放数据，如何获取数据，以及如何通知另一个程序来获取或设置数据；然后，你就可以获取或设置数据了，尽管使用文件的技术定义和实现起来都比较简单，但它的速度往往比较慢(并且容易引起混乱)。因此，这里重点讨论内存数据转移技术。下面将依次详细地分析这一过程的每一个环节： 定义在何处存放数据。当你编写要共享数据的两个程序时，你应该让程序知道要访问的数据存放在何处。这个环节同样有几种实现方法：你可以在一个(或每个)程序中建立一个固定的内部缓冲区，并在两个程序之间传递指向这个缓冲区的指针；你也可以为数据分配动态内存，并在两个程序之间传递指向该数据的指针；如果要传递的数据很小，你还可以通过CPU的通用寄存器来传递数据(这种可能性很小，因为x86结构的寄存器很少)。分配动态内存是最灵活和模块性最强的方法。 定义获取数据的方法。这个环节非常简洁——你可以使用fmemcpy()或等价的内存拷贝函数。显然，在获取和设置数据时都可以使用这个函数。 定义通知另一个程序的方法。因为DOS并不是一个多任务操作系统，所以其中一个(或两个)程序的一部分必须已经驻留在内存中，并且可以接受来自另一个程序的调用。同样，这个环节也有几种方法可供选择：第一个程序可以是一个列入CONFIG．SYS中的驱动程序，它在系统启动时就被装入内存；第一个程序也可以是一个TSR(终止并驻留)程序，在它退出时会把与第二个程序相互作用的那部分程序驻留在内存中；此外，你也可以在第一个程序中利用system()或spawn()函数(见20．11)来启动第二个程序。你可以根据需要选择合适的方法。因为有关DOS驱动程序的数据传递在DOS文档中已经有详尽的描述，而有关system()和spawn()函数的内容也已经在前文中介绍过，因此下面介绍TSR方法。 下面的例子给出了两个程序：第一个程序是一个完整的TSR程序，但为了突出整个过程中的关键环节，它写得比较单薄(见20．15中的解释)。这个TSR程序先是安装了一个中断63H的中断服务程序，然后调用终止并驻留退出函数，在执行这个TSR程序后，执行下文给出的另一个程序。这个程序只是简单地初始化一个对中断63H的调用(类似于使用中断21H调用)，并且把“Hello There”传送给上述TSR程序 # include <stdlib. h> # include <dos. h> # include <string. h> void SetupPointers (void) ; void OutputString(char * ); # define STACKSIZE 4096 unsigned int near OldStackPtr; unsigned int near OldStackSeg; unsigned int _near MyStackOff ; unsigned int _near MyStackSeg; unsigned char_near MyStack[STACKSIZE]; unsigned char far * MyStackPtr= (unsigned char_far * )MyStack; unsigned short AX, BX,CX, DX,ES; / * My interrupt handler * / void_interrupt_far_cdecl NewCommVector ( unsigned short es, unsigned short ds, unsigned short di, unsigned short si, unsigned short bp, unsigned short sp, unsigned short bx, unsigned short dx, unsigned short cx, unsigned short ax, unsigned short ip, unsigned short cs, unsigned short flags) ; / * Pointers to the previous interrupt handier * / void(_interrupt_far_cdecl * CommVector)(); union REGS regs; struet SREGS segregs ; # define COMM_VECTOR 0x63 / * Software interrupt vector * / / * This is where the data gets passed into the TSR * / char_far * eallerBufPtr; char localBuffer[255]; / * Limit of 255 bytes to transfer * / char_far * localBufPtr=(ehar_far * )loealBuffer; unsigned int ProgSize= 276; / * Size of the program in paragraphs * / void main(int argc,char * * argv) { int i, idx; / * Set up all far pointers * / SetupPointers () ; / * Use a cheap hack to see if the TSR is already loaded tf it is, exit,doing nothing * / comm_veetor =_dos_getvect (COMM_VECTOR) ; if(((long)eomm_vector & 0xFFFFL) == ((long) NewCommVector & OxFFFFL ) ) { OutputString("Error :TSR appears to already be loaded. \n"); return ; / * If everything's set,then chain in the TSR * / _dos_setvect (COMM_VECTOR ,NewCommVector) ; / * Say we are loaded * / OutputString("TSR is now loaded at 0x63\n"); / * Terminate, stay resident * / dos_keep (0, ProgSize ) ; } / * Initializes all the pointers the program will use * / void Set upPointers ( ) { int idx ; / * Save segment and offset of MyStackPtr for stack switching * / MyStackSeg = FP_SEG (MyStackPtr) ; MyStackOff = FP_OFF (MyStackPtr) ; / * Initialize my stack to hex 55 so I can see its footprint if I need to do debugging * / for (idx = 0 ;idx<STACKSIZE ; idx ++ ) { MyStack [idx] = 0x55 ; } } void _interrupt_ far_cdecl NewCommVector ( unsigned short es, unsigned short ds, unsigned short di, unsigned short si, unsigned short bp, unsigned short sp, unsigned short bx, unsigned short dx, unsigned short cx, unsigned short ax, unsigned short ip, unsigned short cs, unsigned short flags) { AX = ax; BX = bx ; CX = cx; DX = dx ; ES = es ; / * Switch to our stack so we won't run on somebody else's * / _asm { ;set up a local stack eli ; stop interrupts mov OldStackSeg,ss ; save stack segment mov OldStackPtr,sp ; save stack pointer (offset) mov ax,ds ; replace with my stack s mov ss,ax ; ditto mov ax,MyStackOff ; replace with my stack s add ax,STACKSIZE-2 ;add in my stack size mov sp ,ax ; ditto sti ; OK for interrupts again } switch (AX) { case 0x10; / * print string found in ES:BX */ / * Copy data from other application locally * / FP_ SEG (callerBufPtr) = ES ; FP_OFF (callerBufPtr) = BX ; _fstrcpy (localBufPtr, callerBufPtr ) ; / * print buffer 'CX' number of times * / for(; CX>0; CX--) OutputString (localBufPtr) ; AX=1; /* show success */ break ; case 0x30: /* Unload~ stop processing interrupts * / _dos_setvect (COMM_VECTOR ,comm_vector) ; AX=2; /* show success */ break ; default : OutputString (" Unknown command\r\n" ) ; AX= 0xFFFF; / * unknown command-1 * / break ; } / * Switch back to the caller's stack * / asm { cli ;turn off interrupts mov ss,OldStackSeg ;reset old stack segment mov sp,OldStackPtr ;reset old stack pointer sti ;back on again } ax=AX; /* use return value from switch() */ } / * avoids calling DOS to print characters * / void OutputString(char * str) { int i ; regs. h. ah = 0x0E ; regs. x. bx = 0 ; for(i=strlen(str) ; i>0; i--,str++){ regs. h. al= * str; int86 (0xl0, ®s, ®s) ; } } 上述程序是这两个程序中的TSR程序。这个程序中有一个NewCommVector()函数，它被安装在中断63H(63H通常是一个可用的向量)处作为中断服务程序。当它被安装好后，它就可以接收命令了。switch语句用来处理输入的命令，并作出相应的反应。笔者随意选择了0x1O和0x30来代表这样两条命令：“从ES：BX处复制数据，并打印到屏幕上，CX中的数值为打印次数”；“脱离中断63H，并停止接收命令”。下面是第二个程序——向中断63H发送命令的程序(注意它必须在Large模式下编译)。 # include <stdlib. h> # include <dos. h> # define COMM VECTOR 0x63 union REGS regs; struct SREGS segregs ; char buffer[80]; char _far * buf=(char_far *)buffer; main (int argc,char * * argv) { intcnt; cnt = (argo= =1 ? 1:atoi(argv[1])) ; strcpy (bur, "Hello There\r\n" ) ; regs. x. ax= 0x10; regs. x. cx=cnt ; regs. x. bx=FP OFF(buf); segregs, es=FP SEG(buf) ; int86x(COMM_VECTOR ,®s, &segregs) ; printf ("TSR returned %d\n" ,regs. x. ax) ; } 你可能会认为这个短小的程序看上去和那些通过调用int 21或int 10来在DOS中设置或检索信息的程序差不多。如果你真的这么想，那就对了。唯一的区别就是现在你所用的中断号是63H，而不是21H或10H。上述程序只是简单地调用前文中的TSR程序，并要求后者把es：bX所指向的字符串打印到屏幕上，然后，它把中断处理程序(即那个TSR程序)的返回值打印到屏幕上。 当字符串"Hello There”被打印到屏幕上后，在两个程序之间传递数据的全部必要步骤就都完成了。这个例子的真正价值在于它能够举一反三。现在你能很轻松地编写一个这样的程序，它将发送一条类似于“把要求你打印的最后一个字符串传递给我”的命令。你所要做的就是在前述TSR程序的switch语句中加入这条命令，然后再写一个程序来发送这条命令。此外，你也可以在第二个程序中利用20．11中所介绍的system()或spawn()函数来启动前述TSR程序。由于TSR程序会检查自己是否已被装入，因此你只需装入一次TSR程序，就可以多次运行第二个程序了。在所有要和前述TSR程序通信的程序中，你都可以使用这里所说的方法。 在建立前述TSR程序时，需要有几个前提条件。其一就是没有其它重要的中断服务程序也在处理中断63H。例如，笔者原来在程序中使用的是中断67H，结果该程序能正常装入并运行，但此后笔者就无法编译程序了，因为Microsoft用来运行C编译程序的DOS扩展程序也要使用中断67H。在笔者发送了命令0x30(让程序卸载自身)后，编译程序又能正常运行了，因为DOS扩展程序的中断处理程序已被该程序恢复了。 第二个前提条件与驻留检查在关。笔者假设永远不会有另一个中断处理程序使用和NewCommVector()相同的近程型地址，尽管这种巧合的可能性极小，但读者应该知道该程序并不是万无一失的。在该程序中，笔者特意让NewCommVector()使用自己的栈，以避免它运行在调用它的程序的栈上，但是，笔者还是假设调用所需的任何函数都是安全的。注意，该程序没有调用printf()，因为它占用较多的内存，并且要调用DOS(int 21)来打印字符。在该程序中，当中断63H发生时，笔者不知道DOS是否可以被调用，因此不能假设可以使用DOS调用。 注意，在该程序中，可以调用那些没有用到DOS int21服务程序的函数来完成所需的任务，如果必须使用一个DOS服务程序，你可以在中断63H发生时检查DOS忙标志，以确定当时DOS是否可以被调用。最后，对dos_keep()作一点说明：该函数要求知道在程序退出时要在内存中保留多少段(每段16字节)数据。在本例这个TSR程序中，提供给该函数的段数(276)稍大于整个可执行程序的大小。当你的程序变大时，提供给该函数的段数也必须增大，否则就会出现一些异常现象。
希望采纳
㈨ Android 进程间通信的几种实现方式
Android 进程间通信的几种实现方式
主要有4种方式：
这4种方式正好对应于android系统中4种应用程序组件：Activity、Content Provider、Broadcast和Service。
主要实现原理：
由于应用程序之间不能共享内存。为了在不同应用程序之间交互数据（跨进程通讯），AndroidSDK中提供了4种用于跨进程通讯的方式进行交互数据，实现进程间通信主要是使用sdk中提供的4组组件根据实际开发情况进行实现数据交互。
详细实现方式：
Acitivity实现方式
Activity的跨进程访问与进程内访问略有不同。虽然它们都需要Intent对象，但跨进程访问并不需要指定Context对象和Activity的 Class对象，而需要指定的是要访问的Activity所对应的Action（一个字符串）。有些Activity还需要指定一个Uri（通过 Intent构造方法的第2个参数指定）。 在android系统中有很多应用程序提供了可以跨进程访问的Activity，例如，下面的代码可以直接调用拨打电话的Activity。
IntentcallIntent=newIntent(Intent.ACTION_CALL,Uri.parse("tel:12345678");
startActivity(callIntent);Content Provider实现方式
Android应用程序可以使用文件或SqlLite数据库来存储数据。Content Provider提供了一种在多个应用程序之间数据共享的方式（跨进程共享数据）
应用程序可以利用Content Provider完成下面的工作
1. 查询数据
2. 修改数据
3. 添加数据
4. 删除数据
Broadcast 广播实现方式
广播是一种被动跨进程通讯的方式。当某个程序向系统发送广播时，其他的应用程序只能被动地接收广播数据。这就象电台进行广播一样，听众只能被动地收听，而不能主动与电台进行沟通。在应用程序中发送广播比较简单。只需要调用sendBroadcast方法即可。该方法需要一个Intent对象。通过Intent对象可以发送需要广播的数据。
Service实现方式
常用的使用方式之一：利用AIDL Service实现跨进程通信
这是我个人比较推崇的方式，因为它相比Broadcast而言，虽然实现上稍微麻烦了一点，但是它的优势就是不会像广播那样在手机中的广播较多时会有明显的时延，甚至有广播发送不成功的情况出现。
注意普通的Service并不能实现跨进程操作，实际上普通的Service和它所在的应用处于同一个进程中，而且它也不会专门开一条新的线程，因此如果在普通的Service中实现在耗时的任务，需要新开线程。
要实现跨进程通信，需要借助AIDL(Android Interface Definition Language)。Android中的跨进程服务其实是采用C/S的架构，因而AIDL的目的就是实现通信接口。
总结
跨进程通讯这个方面service方式的通讯远远复杂于其他几种通讯方式，实际开发中Activity、Content Provider、Broadcast和Service。4种经常用到，学习过程中要对没种实现方式有一定的了解。
㈩ android 组件间、进程间数据传输和限制
1、Bunder 传递对象为什么需要序列化?
1》因为 bundle 传递数据时只支持基本数据类型，所以在传递对象时需要序列化转
换成可存储或可传输的本质状态(字节流)。序列化后的对象可以在网络、IPC
(比如启动另一个进程的 Activity、Service 和 Reciver)之间进行传输，也可以 存储到本地。
2》序列化，表示将一个对象转换成可存储或可传输的状态。序列化的原因基本三种 情况:
1.永久性保存对象，保存对象的字节序列到本地文件中; 2.对象在网络中传递;
3.对象在 IPC 间传递。
2、序列化Serializable 和Parcelable 的区别
Serializable(Java 自带):
1》Serializable 是序列化的意思，表示将一个对象转换成存储或可传输的状态。序列化后的对象可以在网络上进传输，也可以存储到本地。
2》Serializable 会使用反射，序列化和反序列化过蠢腊程需要大量 I/O 操作。
Parcelable(android 专用):
1》除了 Serializable 之外，使用 Parcelable 也可以实现相同的效果，不过不同于将 对象进行序列化，Parcelable 方式的实现原理是将一个完整的对象进行分解，而分解后的每一部分都是 Intent 所支持的数据类型，这也就实现传递对象的功能 了。
2》Parcelable 自已实现封送和解封(marshalled &unmarshalled)操作不需要用反 射，数据也存放在 Native 内存中，效率要快很多。
两者最大的区别在于 存储媒介的不同，Serializable 使用 I/O 读写存储在硬盘 上，而 Parcelable 是直接 在内存中读写。很明显，内存的读写速度通常大于纳激 IO 读写，所以在 Android 中传递数据优先选择 Parcelable。
3、bundle传输的数据是否有限制，是多少，为什么要限制?
1》Intent 在传递数据时是有大小限制的，大约限制在 1MB 之内，你用 Intent 传递 数据，实际上走的是跨进程通信(IPC)，跨进程通信需要把数据从内核 到进程中，每一个进程有一带茄滑个接收内核数据的缓冲区，默认是 1M;如果一次传 递的数据超过限制，就会出现异常。
2》不同厂商表现不一样有可能是厂商修改了此限制的大小，也可能同样的对象在不 同的机器上大小不一样。
3》传递大数据，不应该用 Intent;考虑使用 ContentProvider 或者直接匿名共享内 存。简单情况下可以考虑分段传输。
4、匿名共享内存（https://www.jianshu.com/p/d9bc9c668ba6）