WO2015135221A1 - 基于Android的应用层的进程间通信方法及基础应用通信系统 - Google Patents

基于Android的应用层的进程间通信方法及基础应用通信系统 Download PDF

Info

Publication number
WO2015135221A1
WO2015135221A1 PCT/CN2014/073496 CN2014073496W WO2015135221A1 WO 2015135221 A1 WO2015135221 A1 WO 2015135221A1 CN 2014073496 W CN2014073496 W CN 2014073496W WO 2015135221 A1 WO2015135221 A1 WO 2015135221A1
Authority
WO
WIPO (PCT)
Prior art keywords
application
ipcservice
daemon
communication
service
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/CN2014/073496
Other languages
English (en)
French (fr)
Inventor
郭尚锋
吕伟龙
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Shenzhen Chuangwei RGB Electronics Co Ltd
Original Assignee
Shenzhen Chuangwei RGB Electronics Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Shenzhen Chuangwei RGB Electronics Co Ltd filed Critical Shenzhen Chuangwei RGB Electronics Co Ltd
Priority to US14/906,563 priority Critical patent/US9923992B2/en
Priority to AU2014386583A priority patent/AU2014386583B8/en
Publication of WO2015135221A1 publication Critical patent/WO2015135221A1/zh
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/50—Service provisioning or reconfiguring
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/60—Subscription-based services using application servers or record carriers, e.g. SIM application toolkits

Definitions

  • the present invention relates to the field of data communications, and in particular, to an application communication technology based on Android. Background technique
  • Android devices represented by smart phones have mushroomed and prospered. Since the launch of the Android system, it has gradually expanded its market share with obvious advantages. In China, the application of Android system has not only been limited to the mobile phone industry. In recent years, it has rapidly expanded to adjacent areas, such as tablet PCs, car systems, TV STBs, Smart appliances, intelligent conference systems, etc.
  • each resource module After adopting the SOCKET mechanism, the coupling of each resource module can be reduced.
  • the independent module can implement an independent resource interface, so that the system can still operate normally after a module crashes.
  • due to the versatility of the SOCKET interface its transmission efficiency is low and the overhead is large. It is not suitable for real-time communication between multiple processes, and is more suitable for data transmission and communication between different machines.
  • each module After adopting the SOCKET mechanism, each module needs a port number to communicate with each other, so that when the third-party application is integrated, the port number needs to be assigned, and if each system application needs to communicate with the third-party application, It is possible to communicate after going to the port number of each application, which greatly hinders the development of the software platform and the access of rich third-party applications. So use the SOCKET mechanism to build the system.
  • the mechanism of the level application has obvious drawbacks.
  • the main object of the present invention is to provide an Android-based application communication scheme.
  • the present invention proposes an inter-process communication method based on the application layer of Android, creating a framework encapsulation Application in which a system-level application and a user application communicate with each other, and virtualizing as a client; creating a daemon IPCService for the process
  • the communication service is virtualized as the server side; the application registers the binding with the IPCService, and each of the applications implements communication between the applications through the IPCService.
  • the present invention proposes a basic application communication system based on Android, which includes:
  • Application a framework package for system-level applications and user applications to communicate with each other, virtual as a client
  • the daemon IPCService used for interprocess communication services, virtual for the server;
  • the application registers a binding with the IPCService, and each of the applications implements communication between the applications through the IPCService.
  • the present invention proposes an intelligent terminal that uses the above-described Android-based application layer-to-process communication method or basic application communication system to realize mutual communication of applications.
  • the present invention proposes a smart television terminal which is solidified with the above-described Android-based basic application communication system.
  • the present invention proposes an electronic data carrier storing a computer program for implementing the above-described Android-based application layer inter-process communication method.
  • the communication scheme of the Android application of the invention is composed of a specific application and a daemon process.
  • a set of communication mechanism can be established quickly and safely, and communication of each system application is more convenient.
  • the system can easily and easily integrate third-party applications, and greatly facilitate the development of free developers on the system platform This will not only enrich the application of the system platform, but also reduce the application development cost.
  • the invention is based on the communication scheme of the Android application, quickly establishes a set of communication mechanism between each application on the Android system, and realizes communication not only between the application processes but also to an Activity or Service of the application. To make interprocess communication less mysterious and difficult to apply.
  • the development of the application on the communication system based on the solution will be very simple, and the application can be implemented as an independent Android application, which can form a system, a suite form to the user, more concise and orderly, user experience I don't feel a lot of apps, it's messy.
  • FIG. 1 is a schematic diagram of system communication of a basic application communication system of the present invention
  • FIG. 1 Schematic diagram of the Binder mechanism in the present invention
  • FIG. 3 shows the process of binding an Application IPCService service in the embodiment of the present invention
  • FIG. 4 is a schematic diagram of a registration mechanism of an embodiment of the present invention.
  • FIG. 5 is a schematic structural diagram of a data packet according to an embodiment of the present invention.
  • FIG. 6 is a schematic diagram of a process of receiving data according to an embodiment of the present invention.
  • FIG. 7 is a schematic flowchart of sending data according to an embodiment of the present invention.
  • FIG. 8 is a flow chart of communication of an Activity and a Service according to an embodiment of the present invention.
  • Application mainly refers to a specific application or Android Application object.
  • this application mainly refers to the system level (that is, the basic application on which user applications can be developed).
  • the Application layer which refers to the application layer, contains Application and IPCService.
  • IPCService the daemon, used for interprocess communication services.
  • Activity Android application component that provides a screen that users can use to interact.
  • Service service one of the Android components, runs an application component that performs time-consuming operations in the background without a user interface.
  • ServiceManager service management an important process of Android, used to manage the services in the system.
  • the invention adopts the communication mode of C/S (Client/Server, client/server).
  • C/S Client/Server, client/server.
  • Fig. 1 is composed of Application and IPCService, registers with IPCService through Application, and then implements each Application. The process of communicating with each other.
  • the inter-process communication method of the Android-based application layer in this example is implemented by creating an Android-based basic application (referred to as all system applications and user applications) communication system, including:
  • Binding service mainly refers to the Application layer in the Activity and Service in oncreated () (one of the seven life cycle related functions, is the first time the activity is executed, mainly to initialize some variables;) Send a request for the IPCService service to the ServiceManager. Please use the Binder mechanism of Android as shown in Figure 2 and Figure 3.
  • IPCService requests to create a Binder entity First, IPCService applies to the Binder driver to create an IPCService Binder entity in its own process;
  • the Binder driver creates the IPCService service:
  • the Binder driver creates the IPCService Binder entity node and the Binder reference for the IPCService in the kernel. It actually informs the ServiceManager to register a service called IPCService for the interprocess communication service.
  • Association lookup table After the ServiceManager receives the data packet, it extracts the IPCService name and reference from it, and fills in a lookup table;
  • Application applies for and obtains the binding service of IPCService: Application initiates a request to the ServiceManager to apply for the IPCService service, then the ServiceManager can find the reference of IPCService in the lookup table, and IPCService returns the Binder reference to Application.
  • each Application layer saves each instance object inherited from Sky Activity and SkyService in a corresponding table to receive data. It can be distributed to each specific Activity and Service object. By saving the specific instance object, the data can be accurately transferred to the specified Activity and the specified Service of the specified application, and the logical structure of the accurate transmission communication is realized.
  • the two tables used in this example Specifically, each Application stores a corresponding table, which is a collection of its own Service and Activity; and IPCService's lookup table, a communication platform, saves all of the platform Application reference, etc. This is completely absent in the prior art solutions.
  • Android itself can implement Activity to Activity or Service communication, but its shortcomings are too obvious. It implements process-to-process communication, adopts a process-to-process table, and if there are multiple services in one process. And activity, there is no way to achieve specific communication or activity communication, so only point-to-point communication can be achieved, the communication data can only be the basic type of data structure (int, String, Li S t, etc.); After saving the concrete instance object, it is equivalent to placing all the applications on a communication platform, not only peer-to-peer, but also communicating with each other at multiple points.
  • Binder is used to communicate between processes, and the reference to the return must be IBinder. If Application A needs to communicate with the application Application B, the IBinder of Application B must be saved. If Application A is to communicate with Application C, Then Application A also needs to save Application C's IBinder. The more points that Application A needs to communicate, the more times Application A needs to bind, the more references are saved, and if these applications need to communicate with each other, then Every application has to save all references except itself, which is very cumbersome and complicated. And subject to the interface of the Binder mechanism, the structure of the communication data is also limited to the basic data structure of Android communication, and basically uses String to communicate.
  • the core of the Binder mechanism is the communication between two processes or two components. After the package and utilization of this case, it can be oriented to one platform, and the complexity of upper-layer application development is greatly reduced, but at the same time, multiple points of the upper layer application are realized. Communication. After the byte stream is directly used in this case, the user can adopt any data structure, and only need to ensure that both sides of the communication can be serialized and deserialized normally, and many complex data structures of Java also support byte serialization and deserialization. , greatly reducing the performance consumption of the data structure to String conversion.
  • Send data the data to be communicated by the Application is encapsulated into the data structure as shown in FIG. 5, which is mainly composed of a header header and a data body, and the header mainly includes the sender identity information from, the destination to, the communication command.
  • Cmd priority priority, reply to needack and other fields; body is mainly the byte stream of the message; the meaning of each field of the header is as follows:
  • 3.1. from mainly contains the package name, Activity or Service name of the sending data party, which is automatically assembled and obtained by the Application layer.
  • the specific user can not care;
  • 3.2. to mainly refers to the data to be sent to an Activity or Service in a package, which is passed by the user who specifically sends the command;
  • priority mainly refers to the priority of the command, and distinguishes the priority when the IPCService processes the command;
  • the assembled data packet can be directly sent to the IPCService, and then processed and forwarded by the IPCService. Moreover, in this case, the data is re-encoded and compressed in the form of a byte stream.
  • the byte stream can be directly transmitted; whereas most of the prior art interfaces are characters. Strings, or a negotiated data structure, are not universal and flexible. Byte is the basic unit of transmission. The user (that is, the user who uses this communication) has the right to determine its own data structure and serialization mode.
  • the user's requirements for serialization and other operations are limited. After opening the byte stream to the user, the user can decide which way to serialize according to his own needs, which way to deserialize, not limited to the serialization of Java, or the serialization of Android, or A custom serialization, etc., allows the user to adopt a more diverse data structure, which is no longer limited to the underlying data structure, breaking the communication mode of the fixed data structure.
  • the received data packet is dropped into a command pool, which is a package for the existing Java thread pool. Mainly implements the control processing for the request; the command pool is dedicated to processing the received data packet, and a thread will continuously fetch the data packet from the command pool, parse the header of the data packet, and then according to the specific Activity name or Service name, query the specific Activity instance from the corresponding saved table, and then hand it to the specific Activity instance to process the specific data package.
  • IPCService manages all the services provided by Application, that is, all the Binders that receive Data by Application. IPCService saves the package name of all communication applications while managing all Application services, and corresponds the application package name to Binder reference. It forms a lookup table and implements any packet-to-packet communication. This greatly facilitates the integration and development of third-party applications, because it is no longer limited to the communication of existing system applications, and extends the scope to any application that uses this framework, whether it is self-developed or a third party. Integrated.
  • the IPCService responds to all Application requests and assigns corresponding services to them.
  • the IPCService fetches the requested Binder reference according to the package name, and then calls the Binder interface to forward the data.
  • IPCService sends data to Application B.
  • IPCService receives the request from Application A, it processes the header of the sent packet, parses the object of to, that is, Application B, and then extracts Application B from the saved lookup table.
  • the Binder reference then call Application B's reference, so the data is sent to Application B. If there is no object sent to the lookup table, it means that Application B is not started, and the data packet can be directly discarded, because all applications that inherit from the communication mechanism will initiate registration and binding services to IPCService at startup.
  • the application request is easy to manage.
  • the connection to the IPCService can be established, and the IPCService function can be implemented in a very small amount of time.
  • the communication scheme based on the Android system-level application of this example is composed of a specific application and a daemon process, and solves some drawbacks of inter-process communication of each application on the Android system, and can quickly and safely establish itself.
  • a set of communication mechanisms and not only to achieve communication between the various application processes, but also to the application of an Activity or Service, so that inter-process communication is no longer so mysterious and application difficulties.
  • it is very simple to develop an application on a communication system based on the solution, and it can realize that the application is no longer an independent Android application, and can form a system, a suite form is presented to the user, so that the user does not I will feel that the application is very messy.
  • a unique system can be made more simple and open. And very good scalability, no longer a single system, but an open platform.
  • Activity and P Service are initialized and saved in a corresponding table by Application in OnCreateO. If there are 2 Activity and 3 Service in the application A, then the corresponding relationship of the saved table is as follows. All the Activity and Service of the application are saved in two HashMaps, forming an application corresponding table, including the application. The package name and class name of all base components (the order of key and value can be changed).
  • the table records all the activities and services created by the process that need to communicate; when the Activity and Service are initialized, the Application takes its own instance package name as a parameter,
  • the ServiceManager sends a request to apply for the IPCService service; after receiving the request, the ServiceManager returns a reference to the IPCService to the Application; and at the same time, the IPCService saves the reference of the binder (that is, Application) in a lookup table,
  • the table includes information about the bearer's package name, the services provided, and so on.
  • a hashmap ⁇ Stmg, ICmdReceiver> consisting of an instance of the ICmdReceiver interface returned by the package name corresponding to the binder application forms a lookup table in the IPCService.
  • the reason why the communication framework is encapsulated in the application layer is that on the basis of Android, the first component of the application runtime will create a process for the application, and first instantiate the specified
  • Blocking the call mode the main process is to send commands and data to the receiver, while waiting for the return of the receiver to process, at this point the sender's thread is blocked until the call returns.
  • the non-blocking mode when the command and data are sent to the receiver, the command is processed by the thread in the framework first, and the sender does not wait for the command to return; the thread pool in the framework will thread according to the priority and time of the command. All commands in the pool are handed over to the receiver in order of priority.
  • this example has been applied in the process of reconstruction and optimization of the Tianci system.
  • the solution proposed by the present invention can be applied not only to television, but also to any Android-based system.
  • the program conducts inter-process communication and in-depth development and system development of the system.
  • the solution is re-encapsulated and innovated on the basis of the communication mechanism of the Android system, which makes the development of the application simpler, and makes the application differentiation work for different platforms easier to carry out, so that the platform is simplified and unified. Apply a diversified goal. In short, this solution realizes the simplicity and openness of system application communication.
  • Embodiment 3 realizes the simplicity and openness of system application communication.
  • This example is an intelligent terminal, in which an inter-process communication method based on the Android-based application layer in the first embodiment or a program of the basic application communication system is built in. By enabling the program, each application in the intelligent terminal can communicate with each other. . It realizes the simplicity and openness of system application communication, and is easy for third-party application development to achieve the goal of diversification of applications.
  • Smart terminals include, but are not limited to, smart TVs, smart phones, personal computers, tablets, or cloud system personal terminals.
  • the example is a smart TV terminal, wherein the program for implementing the inter-process communication method of the Android-based application layer in the first embodiment or the basic application communication system is solidified.
  • the program for implementing the inter-process communication method of the Android-based application layer in the first embodiment or the basic application communication system is solidified.
  • each application of the intelligent terminal can be realized. Communication.
  • this basic application communication system it is easy for third parties to develop user applications and achieve the goal of diversification of applications.
  • third-party developers don't even have to understand the framework, they only need two steps to call some interfaces of the system.
  • the third-party applications such as iQiyi and Youpeng in the Skyworth Tianci system can easily and quickly realize the same cloud collection and other functions for different applications.
  • Embodiment 5 Embodiment 5
  • the example is a computer-readable electronic data carrier, including but not limited to an optical disk, a flash disk, a hard disk, a network disk, etc., in which an inter-process communication method for implementing the Android-based application layer in the first embodiment is stored or A computer program for a basic application communication system. It can be used for personalized upgrade of operating system based on Android-based smart terminal, and it can also be used for application development by third parties.
  • Smart terminals include, but are not limited to, smart TVs, smart phones, personal computers, tablets, or cloud system personal terminals.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

本发明公开了一种基于Android的应用层的进程间通信方法及基础应用通信系统，按照客户机/服务器的通信模式，创建系统级应用和用户应用相互通信的框架封装Application，并虚拟为客户机端；创建守护进程IPCService，并虚拟为服务器端；通过Application向IPCService注册绑定，实现各个Application的互相通信。采用本发明的方案，在各个应用进行进程间通信时，可以快速安全地建立起自己的一套通信机制，不仅各系统应用的通信更加方便，而且让系统具有了简单性和开放性，可以简便地融合第三方应用，也极大方便了自由开发者在系统平台上开发应用，既丰富了系统平台的应用，也可以降低应用开发成本。

Description

基于 Android的应用层的进程间通信方法及基础应用通信系统 技术领域
本发明涉及数据通信领域， 特别涉及一种基于 Android的应用通信技术。 背景技术
随着科技的迅猛发氣以智能手机为代表的 Android设备如雨后春笋般迅速发 展壮大。 Android 系统自推出以来,就以明显的优势逐渐扩大市场份额，在国内， Android 系统的应用已不仅局限于手机产业,几年来其迅速扩张到相邻领域,例如 平板电脑、 车载系统、 电视 STB、 智能电器、 智能会议系统等。
但是对于采用 Android系统的各个开发厂商和互联网企业而言，不能仅仅满 足于在 Android的原生系统上开发出各种各样的应用，还需要深层次地定制带有 自己特色的 Android系统； 尤其对于各大电视厂商来说， 独具特色的系统显得非 常重要， 而且也可以快速适应芯片的迭代和更新。那么， 如何定制和创建一套上 层开发可用的系统， 成了各大厂商开发的首要任务和难题。
要创建一套基于 Android的系统级应用，或者说需要定制一套有自己特色的 Android系统，那么不可避免要用到进程间通信等通信方法。众所周知，在 Android 系统上， 各个应用的通信方法无非两种， Binder机制和 SOCKET通信机制。 当 前， 大多数电视厂商都采用了单一的 Binder机制或 SOCKET机制， 甚至广播机 制。但是这些做法都有一定的缺陷， 不能完全满足一个基于可开放平台的系统要 求。
采用 SOCKET机制之后， 可以降低各个资源模块的耦合性， 独立的模块可 以实现独立的资源接口，这样可以在某个模块崩溃之后，系统仍然可以正常运行。 但是， 由于 SOCKET接口的通用性， 导致其传输效率低， 开销大， 不适合用来 多进程之间的相互实时通信， 更适合不同机器间的数据传输和通信。 同时， 采用 了 SOCKET机制之后， 由于每个模块都需要一个端口号， 才能互相通信， 这样 在第三方应用集成进来的时候， 需要分配端口号，各个系统应用如果需要和第三 方应用通信，还得先后去各个应用的端口号之后才能通信， 很大程度上阻碍了软 件平台的开发和丰富的第三方应用的接入。 所以采用 SOCKET机制来建立系统 级应用的机制存在明显缺陷。
而采用 Binder机制之后，由于单一的采用 Binder机制和 AIDL的调用方式， 上层应用为了可以正常调用到所有可用的资源接口，将所有的模块功能捆绑在了 一个 service进程上， 这样就导致了一个问题， 系统的耦合性太强， 如果核心提 供资源接口的 Service进程挂掉， 那么整个系统将不能运作， 给用户带来很大的 不便， 用户体验较差。 发明内容
本发明的主要目的是： 提供一种基于 Android的应用通信方案。
为此， 首先， 本发明提出一种基于 Android的应用层的进程间通信方法， 创 建系统级应用和用户应用相互通信的框架封装 Application, 并虚拟为客户机端； 创建守护进程 IPCService, 用于进程间通信服务， 并虚拟为服务器端； 所述 Application向 IPCService注册绑定， 各个所述 Application通过所述 IPCService实现 各个应用的互相通信。
其次， 本发明提出了一种基于 Android的基础应用通信系统， 包括：
Application, 为系统级应用和用户应用相互通信的框架封装， 虚拟为客户机
¾ ;
守护进程 IPCService, 用于进程间通信服务， 虚拟为服务器端；
所述 Application向 IPCService注册绑定， 各个所述 Application通过所述 IPCService实现各个应用的互相通信。
再次， 本发明提出了一种智能终端， 应用上述的基于 Android的应用层的进 程间通信方法或基础应用通信系统， 实现各个 Application的互相通信。
同时， 本发明提出一种智能电视终端， 固化有上述的基于 Android的基础应 用通信系统。
最后，本发明提出了一种电子数据载体，存储有用于实现上述的基于 Android 的应用层的进程间通信方法的计算机程序。
本发明 Android应用的通信方案， 由具体的应用和一个守护进程组成， 在 Android系统各个应用进行进程间通信时， 可以快速安全地建立起自己的一套通 信机制， 不仅各系统应用的通信更加方便， 而且让系统具有了简单性和开放性， 可以简单方便的融合第三方应用，也极大方便了自由开发者在系统平台上开发应 用， 这样既丰富了系统平台的应用， 也可以降低应用开发成本。
本发明基于 Android应用的通信方案， 在 Android系统上各个应用间快速安 全地建立起自己的一套通信机制， 并且实现了不仅各个应用进程间的通信， 更可 以精准到应用的某个 Activity或者 Service,让进程间通信不再那么神秘和应用困 难。而且， 基于本方案实现的通信系统上开发应用会显得非常简单， 并且可以实 现应用不再是独立的一个 Android应用， 可以形成一个体系， 一个套件的形式展 现给用户， 更简洁有序， 用户体验不会感觉到应用很多、 很杂乱。
【附图说明】
图 1 本发明的基础应用通信系统的系统通信概要图；
图 2 本发明中 Binder机制示意图；
图 3 本发明实施例中 Application绑定 IPCService服务的流程；
图 4 本发明实施例的注册机制示意图；
图 5 本发明实施例的数据包结构示意图；
图 6 本发明实施例的接收数据流程示意图；
图 7 本发明实施例的发送数据流程示意图；
图 8 本发明实施例的 Activity和 Service的通信流程图。
【具体实施方式】
下面通过具体的实施例并结合附图对本发明作进一步详细的描述。
技术名词解释： Application 主要指某个具体的应用或者 Android 的 Application对象， 本申请中， 主要指系统级（即能在其上开发用户应用的基础应 用） 应用和用户应用相互通信的框架封装。
Application层， 泛指应用层， 包含 Application禾 P IPCService。
IPCService, 守护进程， 用于进程间通信服务。
Activity Android应用程序组件， 提供一个屏幕， 用户可以用来交互。 Service服务， Android组件之一， 没有用户界面的在后台运行执行耗时操作 的应用组件。
ServiceManager服务管理， Android的重要进程，用于管理系统中的 Service。 本发明采用 C/S (Client/Server, 客户机 /服务器） 的通信模式， 总体框架请 参阅图 1 的系统通信概要图， 由 Application和 IPCService两部分组成， 通过 Application向 IPCService注册， 然后实现各个 Application互相通信的过程。 实施例一：
本例的基于 Android的应用层的进程间通信方法，通过创建一个基于 Android 的基础应用 （泛指所有系统应用和用户应用） 通信系统来实现， 包括：
首先， 创建系统级（即能在其上开发用户应用的基础应用）应用和用户应用 相互通信的框架封装应用 Application, 实现绑定服务、 保存对象、 发送数据、 接 收数据等主要重要步骤。
1.绑定服务， 主要指 Application层在 Activity和 Service在 oncreated()(7个 与生命周期有关的函数之一， 是 activity第一次启动时被执行的， 主要是初始化 一些变量;)的时候， 向 ServiceManager发送申请 IPCService服务的请求， 请结合 图 2和图 3所示， 利用了 Android的 Binder机制；
511. IPCService申请创建 Binder的实体： 首先， IPCService在自己的进程中 向 Binder驱动申请创建一个 IPCService的 Binder的实体；
512. Binder驱动创建 IPCService的服务： Binder驱动为 IPCService创建为 了内核中的 IPCService 的 Binder实体节点以及 Binder的引用， 实际上是通知 ServiceManager注册一个叫做 IPCService的服务， 用于进程间通信服务；
513. 关联查找表： ServiceManager 收到数据包之后， 从中取出 IPCService 的名字和引用， 填入一张查找表中；
514. Application 申请并获得 IPCService 的绑定服务： Application 向 ServiceManager发起申请 IPCService服务的请求，那么 ServiceManager就可以在 查找表中找到 IPCService的引用， IPCService把 Binder引用返回给 Application
2.保存对象， 如图 4注册机制中的虚线框中所示， Application层在绑定服务 成功之后， 将各个继承自 Sky Activity和 SkyService的实例对象保存在一张对应 表中， 以便接收数据的时候可以分发到各个具体的 Activity和 Service对象。 通 过保存具体的实例对象， 就可以准确传输数据到指定应用的指定 Activity和指定 Service中， 实现了精准传输通信的逻辑结构。 本例采用的两张表： 具体来说就是， 每个 Application都保存了一张对应表， 该表是自身 Service和 Activity的集合； 而 IPCService的查找表， 一个通信平台 一个， 保存该平台的所有 Application的引用等。 这在现有技术的方案中是完全 没有的。现有技术中， Android自身虽然可以实现 Activity到 Activity或者 Service 的通信， 但是其缺点过于明显， 实现的是进程对进程的通信， 采用进程对进程的 一张表，如果一个进程中有多个 service和 activity,就没法实现具体到哪个 service 或者 activity的通信， 故只能实现点对点之间的通信， 通信的数据只能是基本类 型的数据结构 （int,String,LiSt 等）； 而本例保存了具体的实例对象后， 相当于将 所有的应用置于了一个通信平台，不仅仅是点对点，还可以多个点之间互相通信。
现有技术中，利用 Binder在进程间通信， 限定了返回的引用必须是 IBinder, 应用 Application A如果要和应用 Application B通信， 就得保存 Application B的 IBinder, Application A如果还要同 Application C 通信，那么 Application A也得保 存 Application C 的 IBinder, Application A要通信的点越多， 导致 Application A 需要绑定的次数也越多， 保存的引用也越多， 并且这些 Application之间如果要 互相通信， 那么每个应用都得保存一份除自身之外的所有引用， 非常繁琐复杂。 并且受 Binder机制的接口约束，通信数据的结构也局限于 Android通信的基本数 据结构， 基本都是采用 String进行通信。
Binder机制的核心就是两个进程或者两个组件的通信，采用本案的封装和利 用后， 可以面向一个平台， 并且大大减少了上层应用开发的复杂性， 但同时又实 现了上层应用的多点互相通信。本案直接采用字节流之后，用户就可采用任何数 据结构， 只需要确保通信的双方可以正常序列化和反序列化即可， 并且 Java的 很多复杂数据结构也支持字节序列化和反序列化， 大大减少了数据结构向 String 转换的性能消耗。
3.发送数据，由 Application将要通信的数据封装成如图 5所示的数据结构中， 主要由包头 header和数据体 body组成， header主要包括了发送方身份信息 from、 发送目的地 to、 通信命令 cmd、 优先级 priority、 回复 needack等字段； body主 要是消息的字节流； header的各个字段的含义如下：
3.1. from,主要包含发送数据方的包名， Activity或者 Service名，由 Application 层自动组装和获取， 具体的使用者可以不用关心； 3.2. to, 主要指数据要发送到某个包中的某个 Activity或者 Service, 由具体 实现发送命令的使用者传递参数；
3.3. cmd, 主要是双方用来通信的协议， 代表某一协商好的含义， 具体为一 个字符串；
3.4. priority, 主要是指命令的优先级， 在 IPCService处理命令的时候区分优 先级；
3.5. needack, 是否需要立即回复的标识， 表示该命令是否需要立即返回一个 result (通信的一个标签)；
在 Application组装好数据之后， 由于绑定服务已经获取到了 IPCService的 Binder 的引用， 就可以直接将组装好的数据包发送给 IPCService , 然后由 IPCService处理和转发。 而且， 本案采用了字节流的形式对数据进行再次编码和 压缩， 在 Application对外开放的通信接口上， 应用如果需要通信， 直接传递字 节流即可； 而现有技术大多对外接口都是字符串， 或者一种协商好的数据结构， 不够通用和灵活。 字节是基本的传输单位， 用户 （也就是采用本通信的使用者） 有权决定自身的数据结构和序列化方式，如果采用一种固定的数据结构限定了用 户对于序列化等操作的要求； 面向用户开放字节流之后，用户就可以自己根据自 己的需求决定采用哪种方式序列化，采用哪种方式反序列化， 不必限定于非要采 用 Java的序列化， 或者 Android的序列化， 或者某种自定义的序列化等， 让使 用者可以采用的数据结构更加多样化， 不再局限于基础的数据结构， 打破了固定 化数据结构的通信模式。
4.接收数据，如图 6接收数据机制所示，在 Application层接收到数据包以后， 会将接收到的数据包丢入一个命令池里面， 该命令池是对 Java现有线程池的封 装， 主要实现对于请求的控制处理； 该命令池专用来处理接收到的数据包的， 有 一个线程会不断的从该命令池中取数据包，解析数据包的头部，然后根据具体的 Activity名或者 Service名，从一开始保存的对应表中查询出具体的 Activity实例， 然后交给具体的 Activity实例去处理具体的数据包。
其次， 创建一个守护进程 IPCService, 作为处理和转发数据包的核心服务， 虽然从 Android的架构角度来讲处于用户空间， 但是对于用户来说是不可见的， 用户和使用者不必关心 IPCService 需要具体处理哪些事务。 其主要包含两个功 一方面， IPCService管理所有 Application提供的服务， 即所有 Application 接收数据的 Binder弓 I用； IPCService在管理所有 Application服务的同时， 保存 了所有通信应用的包名， 将应用的包名和 Binder引用一一对应起来形成一查找 表， 实现了任何包对包的通信。这样极大方便了第三方应用的集成和开发， 因为 此时不再局限于已经存在的系统应用的通信，同时将范围大大扩展到了任何采用 本框架的应用， 不管是自行开发的， 还是第三方集成的。
另一方面， IPCService响应所有 Application的请求并为之分配对应的服务。
IPCService在接收到 Application的请求时， 根据包名取出所请求的 Binder引用， 然后调用该 Binder的接口， 转发数据。
这样就实现了一个发送数据的流程， 如图 7所示：
假设 Application A 向 Application B 发送数据， 当 IPCService 接收到 Application A的请求时， 处理发送到的数据包的头部， 解析出 to的对象， 也就 是 Application B， 然后从保存的查找表中取出 Application B 的 Binder引用， 然 后调用 Application B的引用，这样数据就发送到了 Application B。如果查找表中 没有发送到的对象， 说明 Application B没有启动， 就可以直接丢弃数据包， 因 为所有继承自该套通信机制的应用都会在启动的时候向 IPCService 发起注册和 绑定服务。
采用本方案提出的通信机制之后， Application的请求便于管理， 另一方面， 只需要 Application启动的时候， 向 IPCService建立连接即可， 就可以花费非常 少的时间去实现 IPCService的功能。
综上所述， 本例的基于 Android系统级应用的通信方案， 由具体的应用和一 个守护进程组成，解决了在 Android系统上各个应用进行进程间通信的一些弊端， 可以快速安全地建立起自己的一套通信机制，并且不仅实现了各个应用进程间的 通信， 更可以精准到应用的某个 Activity或者 Service, 让进程间通信不再那么神 秘和应用困难。 最重要的是， 在基于本 方案实现的通信系统上开发应用会显得 非常简单， 并且可以实现应用不再是独立的一个 Android应用， 可以形成一个体 系， 一个套件的形式展现给用户， 让用户不会感觉到应用很多、 很杂乱。 基于本 方案实现的通信系统上，可以让一个独具特色的系统更加具有了简单性、开放性 以及非常好的可扩展性， 不再是一个单一的系统， 而是一个可开放的平台。 实施例二：
依据实施例一的方案， 将其具体应用在创维的智能电视操作系统-天赐系统 的重构版本中， 详细说明如下：
首先， 实现一个全局的 Application, 包含在框架层， 并且封装成 jar包。 编 写一个全局的单例模式的 My Application继承自 Application 由于在应用层无法 直接对原生 Application进行更改，更改也违背了 Android开放性和通用性的要求； 创建一个继承自 Application的 My Application是为了实现对事物的普通性和特殊 性的需求， 再次创建的 MyApplication既是一个普通的 Android应用， 但同时又 实现了自身对于通信的需求。 MyApplication实现通信框架层的封装， 主要包含 绑定服务、 保存对象、 发送数据、 接收数据等重要步骤。 各个步骤的具体实施方 案同实施例一所述。 如图 4， 完整地表示了整个 Application层通信的处理流程： Activity禾 P Service在 OnCreateO的时候，被初始化并被 Application保存在一张 对应表。 假如应用 A中有 2个 Activity, 3个 Service, 那么保存的表对应关系如 下所示， 该应用所有的 Activity和 Service均被保存在两个 HashMap中， 形成一 个 Application的对应表，包含有该应用所有基础组件的包名和类名 （key和 value 的顺序可以调换）。
Figure imgf000010_0001
该表记录了该进程所有创建的需要通信的 Activity和 Service; 在 Activity和 Service初始化的时候， Application将自身的实例包名作为参数， 向
ServiceManager发送申请 IPCService服务的请求； ServiceManager在接收到请求 之后， 将 IPCService的引用返回给 Application; 并且与此同时， IPCService会将 绑定者（也就是 Application)的引用保存在一张查找表中， 该表包括绑定者的包 名、提供的服务等信息。如下，一个由包名对应 binder应用返回的 ICmdReceiver 接口实例组成的 hashmap<Stmg, ICmdReceiver>, 形成 IPCService中的查找表。
Key Value
com.test.testl Testl应用的 ICmdReceiver 实现
com.test.test2 Test2应用的 ICmdReceiver
实现
com.test.test3 Test3应用的 ICmdReceiver
实现 之所以在应用层实现通信框架的封装， 是因为在 Android基础上， 应用程序 第一个组件运行时将会为应用创建一个进程， 并且首先实例化所指定的
Application, 此时就会执行绑定 IPCService的服务， 从而建立 Application禾口 IPCService的通信；
然后， 实现 IPCService的守护进程：
创建一个守护进程的 service, 提供注册、 发送数据的 Binder引用， 再创建 一张保存所有已经注册的 Application的 Binder查找表，最后根据数据包的包头， 从查找表查找获取对应 Binder的引用来实现数据转发。
上述步骤实现了基本通信的框架系统，那么对于具体的各个基础应用或者用 户应用来说， 要做的事情就更简单了， 只需要三个简单的步骤， 即可实现整个系 统各个 Activity和 Service的通信。
Sl， 所创建的应用依赖系统框架 jar包；
52, 所有需要通信的 Activity和 Service继承自 SkyActivity和 SkyService;
53 , 在 androidmanifest.xml中配置 Application选项， 其中 name后面为框架 jar包中 Application的路径， 如下所示：
<application android： name="a.b .c. My Application" ></ application
通过以上三个简单的步骤， 就可以在任意继承自 SkyActivity和 SkyService 的类中处理和收发数据包， 并且可以实现阻塞和非阻塞两种调用方式。 阻塞调 用方式， 主要流程是将命令和数据发送到接收方， 同时同步等待接收方处理的 返回， 此时发送方的线程被阻塞， 直到调用的返回。 非阻塞调用的方式， 将命 令和数据发送到接收方时， 命令先由框架中的线程时处理， 发送方不会等待命 令的返回； 框架中的线程池会根据命令的优先级和时间将线程池中的所有命令 按照优先顺序依次交给接收方处理。
综上所述，本例在天赐系统的重构和优化过程中得到了应用， 同时本发明提 出的方案不仅仅可以应用于电视上，任何一个基于 Android的系统都可以采纳本 方案进行进程间通信以及系统的深入开发与体系开发。 而且， 本方案在 Android 系统通信机制的基础上进行了再次封装和创新， 让应用的开发更加简单， 也让针 对不同平台的应用差异化工作更容易开展， 做到了让平台简单化， 统一化， 应用 多元化的目标。 总之， 本方案实现了系统应用通信的简单性、 开放性。 实施例三
本例是一种智能终端，其中内置了实现实施例一中的基于 Android的应用层 的进程间通信方法或基础应用通信系统的程序，通过启用该程序，可实现智能终 端中各个 Application的互相通信。 实现了系统应用通信的简单性、 开放性， 易 于第三方进行应用开发， 实现应用多元化的目标。智能终端包括但并不限于智能 电视、 智能手机、 个人电脑、 平板电脑或云系统个人终端等。 实施例四
本例是一种智能电视终端，其中固化有实现实施例一中的基于 Android的应 用层的进程间通信方法或基础应用通信系统的程序，通过启用该程序，可实现智 能终端中各个 Application的互相通信。 在此基础应用通信系统的基础上， 易于 第三方进行用户应用开发， 实现应用多元化的目标。 比如， 第三方开发者甚至不 用理解该框架， 只需要两个步骤即可调用系统的一些接口。 比如目前创维天赐系 统中的爱奇艺、有朋等第三方应用，可以非常容易和快速地实现不同的应用的同 一个云端收藏等功能。 实施例五
本领域技术人员可以理解，上述实施方式中各种方法的全部或部分步骤可以 通过计算机程序来指令相关硬件完成。 本例是一种计算机可读的电子数据载体， 包括但不限于光盘、 闪存盘、硬盘和网盘等， 其中存储了用于实现实施例一中的 基于 Android的应用层的进程间通信方法或基础应用通信系统的计算机程序。可 以供基于 Android的智能终端进行操作系统的个性化升级， 也可供第三方进行应 用开发。 智能终端包括但并不限于智能电视、 智能手机、 个人电脑、 平板电脑或 云系统个人终端等。 以上内容是结合具体的优选实施方式对本发明所作的进一步详细说明，不能 认定本发明的具体实施只局限于这些说明。对于本发明所属技术领域的普通技术 人员来说， 在不脱离本发明构思的前提下， 还可以做出若干简单推演或替换， 都 应当视为属于本发明的保护范围。

Claims

权 利 要 求 书
1.一种基于 Android的应用层的进程间通信方法， 创建系统级应用和用户应用相互通信的 框架封装 Application, 并虚拟为客户机端； 创建守护进程 IPCService, 用于进程间通信服务， 并虚拟为服务器端； 所述 Application向守护进程 IPCService注册绑定， 各个所述 Application通 过所述守护进程 IPCService实现各个应用的互相通信。
2.如权利要求 1所述的应用层的进程间通信方法， 其特征是： 具体包括：
所述框架封装 Application, 实现绑定服务、 保存对象、 发送数据和接收数据步骤； 所述守护进程 IPCService, 管理所有所述 Application服务， 保存所有通信应用的包名， 将应用的包名和 Binder引用一一对应， 实现任何包对包的通信； 响应所有所述 Application的 请求并为之分配对应的服务， 在接收到所述 Application 的请求时， 根据包名取出所请求的 Binder引用， 然后调用该 Binder的接口， 转发数据。
3.如权利要求 2所述的应用层的进程间通信方法， 其特征是：
所述绑定服务步骤中， 所述 Application在 Activity和 Service在 oncreatedO时， 向
ServiceManager发送申请守护进程 IPCService服务的请求， 利用 Binder机制， 由 ServiceManager 绑定所述 Application和守护进程 IPCService之间的服务机制。
4. 如权利要求 3所述的应用层的进程间通信方法， 其特征是： 所述绑定服务的具体流程 包括：
511. 守护进程 IPCService在自己的进程中向 Binder驱动申请创建一个守护进程 IPCService 的 Binder的实体；
512. Binder驱动为守护进程 IPCService创建成为内核中的守护进程 IPCService的 Binder实 体节点以及 Binder的引用， 即通知 ServiceManager注册一个用于进程间通信服务的守护进程 IPCService;
SI 3. ServiceManager收到数据包之后， 从中取出 IPCService的名字和引用， 填入查找表中； S14.Application向 ServiceManager发起申请守护进程 IPCService服务的请求，
ServiceManager在所述查找表中找到守护进程 IPCService的引用， 并把 Binder弓 |用返回给
Application
5. 如权利要求 3或 4所述的应用层的进程间通信方法， 其特征是： 所述保存对象步骤中， Application在与守护进程 IPCService绑定服务成功之后， 将各个继承自某一 Activity和某一 Service的实例对象保存在对应表中， 以便接收数据的时候可以分发到各个具体的 Activity和 Service对象。
6. 如权利要求 3或 4所述的应用层的进程间通信方法， 其特征是： 所述发送数据的具体流 程包括： 由 Application将要通信的数据封装成包括包头 header和数据体 body的数据结构中； 将 组装好的数据包发送给守护进程 IPCService, 然后由守护进程 IPCService处理和转发。 7. 如权利要求 5所述的应用层的进程间通信方法， 其特征是： 所述接收数据步骤中， Application接收到数据包以后， 将接收到的数据包放入一个用于处理接收到的数据包的命令 池里， 由一个线程从该命令池中取数据包， 解析数据包的头部， 根据具体的 Activity名或者 Service名， 从所述对应表中查询出具体的 Activity实例，然后交给具体的 Activity实例去处理具 体的数据包。
8. 如权利要求 5所述的应用层的进程间通信方法，其特征是： Application A向 Application B 发送数据的具体流程包括： Application A向守护进程 IPCService发出服务请求， 守护进程 IPCService接收到 Application A的请求时， 处理发送到的数据包的头部， 解析出被发送的对象 Application B，然后从保存的调用表中取出 Application B的 Binder引用，调用 Application B的引 用， 数据被发送到了 Application B。
9. 如权利要求 6所述的应用层的进程间通信方法， 其特征是： 所述包头 header包括发送方 身份信息、 发送目的地、 通信命令、 优先级、 回复字段，
发送方身份信息， 包含发送数据方的包名， Activity或者 Service名， 由应用层自动组装和 获取；
发送目的地， 指数据要发送到某个包中的某个 Activity或者 Service, 由具体实现发送命 令的使用者传递参数；
通信命令， 代表某一协商好的、 双方用来通信的协议；
优先级， 命令的优先级， 区分守护进程 IPCService处理命令的优先级；
回复， 是否需要立即回复的标识。
10. 一种基于 Android的基础应用通信系统， 包括：
Application, 为系统级应用和用户应用相互通信的框架封装， 虚拟为客户机端； 守护进程 IPCService, 用于进程间通信服务， 虚拟为服务器端；
所述 Application向守护进程 IPCService注册绑定， 各个所述 Application通过所述守护进程 IPCService实现各个应用的互相通信。
11.如权利要求 10所述的基础应用通信系统， 其特征是： 所述框架封装 Application, 用于 实现绑定服务、 保存对象、 发送数据和接收数据步骤；
所述守护进程 IPCService, 管理所有 Application服务， 保存所有通信应用的包名， 将应 用的包名和 Binder引用一一对应， 实现任何包对包的通信； 响应所有 Application的请求并为 之分配对应的服务， 在接收到 Application的请求时， 根据包名取出所请求的 Binder引用， 然 后调用该 Binder的接口， 转发数据。
12. 如权利要求 11所述的基础应用通信系统， 其特征是：
所述绑定服务步骤中， Application在 Activity和 Service在 oncreated()时， 向 ServiceManager 发送申请 IPCService服务的请求， 利用 Binder机制， 由 ServiceManager绑定所述 Application和 IPCService之间的服务机制。
13. 如权利要求 12所述的基础应用通信系统， 其特征是： 所述绑定服务的具体流程包括:
511.守护进程 IPCService在自己的进程中向 Binder驱动申请创建一个守护进程 IPCService 的 Binder的实体；
512. Binder驱动为守护进程 IPCService创建成为内核中的守护进程 IPCService的 Binder实 体节点以及 Binder的引用， 即通知 ServiceManager注册一个用于进程间通信服务、 称为守护进 程 IPCService的服务；
S 13. ServiceManager收到数据包之后， 从中取出守护进程 IPCService的名字和引用， 填入 查找表中；
S14.Application向 ServiceManager发起申请守护进程 IPCService服务的请求，
ServiceManager在所述查找表中找到守护进程 IPCService的引用， 并把 Binder弓 |用返回给 Application
14. 如权利要求 12或 13所述的基础应用通信系统， 其特征是： 所述保存对象步骤中， Application在与守护进程 IPCService绑定服务成功之后， 将各个继承自某一 Activity和某一 Service的实例对象保存在对应表中， 以便接收数据的时候可以分发到各个具体的 Activity和 Service对象。
15. 如权利要求 12或 13所述的基础应用通信系统， 其特征是： 所述发送数据的具体流程 包括： 由 Application将要通信的数据封装成由包头 header和数据体 body组成的数据结构中； 将 组装好的数据包发送给守护进程 IPCService, 然后由守护进程 IPCService处理和转发。
16. 如权利要求 14所述的基础应用通信系统，其特征是：所述接收数据步骤中， Application 接收到数据包以后， 将接收到的数据包放入一个用于处理接收到的数据包的命令池里， 由一 个线程从该命令池中取数据包， 解析数据包的头部， 根据具体的 Activity名或者 Service名， 从 所述对应表中查询出具体的 Activity实例， 然后交给具体的 Activity实例去处理具体的数据包。
17. 如权利要求 14所述的应用通信系统， 其特征是： Application A向 Application B发送数 据的具体流程包括： Application A向守护进程 IPCService发出服务请求， 守护进程 IPCService 接收到 Application A的请求时， 处理发送到的数据包的头部， 解析出被发送的对象 Application B， 然后从保存的调用表中取出 Application B的 Binder引用， 调用 Application B的引用， 数据 被发送到了 Application B。
18. 如权利要求 15所述的基础应用通信系统， 其特征是： 所述数据头 header包括发送方身 份信息、 发送目的地、 通信命令、 优先级、 回复字段，
发送方身份信息， 包含发送数据方的包名， Activity或者 Service名， 由 Application层自动 组装和获取； 发送目的地， 指数据要发送到某个包中的某个 Activity或者 Service, 由具体实现发送命 令的使用者传递参数；
通信命令， 代表某一协商好的、 双方用来通信的协议；
优先级， 命令的优先级， 区分守护进程 IPCService处理命令的优先级；
回复， 是否需要立即回复的标识。
19.一种智能终端， 应用如权利要求 1-9中任一项所述的基于 Android的应用层的进程间 通信方法， 实现各个 Application的互相通信。
20.—种智能电视终端， 固化有如权利要求 10-18中任一项所述的基于 Android的基础应 用通信系统。
21. 一种电子数据载体，存储有用于实现如权利要求 1-9中任一项所述的基于 Android的 应用层的进程间通信方法的计算机程序。
PCT/CN2014/073496 2014-03-12 2014-03-17 基于Android的应用层的进程间通信方法及基础应用通信系统 Ceased WO2015135221A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US14/906,563 US9923992B2 (en) 2014-03-12 2014-03-17 Inter-process communication method based on application layer of android and basic application communication system
AU2014386583A AU2014386583B8 (en) 2014-03-12 2014-03-17 Inter-process communication method based on application layer of android and basic application communication system

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201410090696.1A CN103902390B (zh) 2014-03-12 2014-03-12 基于Android的应用层的进程间通信方法及基础应用通信系统
CN201410090696.1 2014-03-12

Publications (1)

Publication Number Publication Date
WO2015135221A1 true WO2015135221A1 (zh) 2015-09-17

Family

ID=50993728

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2014/073496 Ceased WO2015135221A1 (zh) 2014-03-12 2014-03-17 基于Android的应用层的进程间通信方法及基础应用通信系统

Country Status (4)

Country Link
US (1) US9923992B2 (zh)
CN (1) CN103902390B (zh)
AU (1) AU2014386583B8 (zh)
WO (1) WO2015135221A1 (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113326067A (zh) * 2021-05-11 2021-08-31 深圳市捷视飞通科技股份有限公司 命令执行方法、系统、计算机设备和存储介质
CN113378166A (zh) * 2021-06-25 2021-09-10 北京百度网讯科技有限公司 调用操作系统的应用程序接口api的方法和装置
CN115098076A (zh) * 2022-07-18 2022-09-23 扬州航盛科技有限公司 一种用于Android系统的代码生成方法

Families Citing this family (39)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103826156B (zh) * 2014-03-17 2017-09-19 华为技术有限公司 终端遥控方法、机顶盒、移动终端及网页服务器
CN104486389B (zh) * 2014-12-04 2018-02-13 上海斐讯数据通信技术有限公司 一种窗口管理服务与app间的通信通道建立方法和系统
CN104461555A (zh) * 2014-12-22 2015-03-25 浪潮软件集团有限公司 一种Home应用中直接操控各个播放应用的方法
US9674465B2 (en) * 2015-06-03 2017-06-06 Omnivision Technologies, Inc. Non-visible illumination scheme
CN106469089A (zh) * 2015-08-21 2017-03-01 百度在线网络技术（北京）有限公司 用于使得终端上的非系统应用实现系统级别接口调用的方法及装置、终端
CN105204951A (zh) * 2015-10-10 2015-12-30 上海斐讯数据通信技术有限公司 一种安卓系统中Activity间通信的方法和装置
CN105354081B (zh) * 2015-11-26 2018-06-12 北京奇虎科技有限公司 同步绑定服务的方法及装置
CN105550049A (zh) * 2015-12-16 2016-05-04 汉柏科技有限公司 一种通信系统及其使用方法
CN106027365A (zh) * 2016-04-29 2016-10-12 乐视控股（北京）有限公司 一种信息交互的方法及装置
CN106250165A (zh) * 2016-06-12 2016-12-21 杭州无量网络科技有限公司 应用程序组件管理方法及系统
CN106354573A (zh) * 2016-08-29 2017-01-25 汉柏科技有限公司 一种基于优先级队列的进程间通信方法及装置
CN106547631B (zh) * 2016-09-26 2021-04-20 腾讯科技（深圳）有限公司 基于安卓平台的跨进程通信方法和装置
CN106547567A (zh) * 2016-11-25 2017-03-29 山东大学 一种安卓系统中多业务下进程间通信系统及其实现方法
CN106708634B (zh) * 2016-12-09 2020-08-25 福建省天奕网络科技有限公司 Vr应用设备与厂家设备的通讯方法及其系统
CN106933636B (zh) * 2017-03-16 2020-08-18 北京奇虎科技有限公司 启动插件服务的方法、装置和终端设备
CN108804236B (zh) * 2017-05-04 2022-05-03 Tcl科技集团股份有限公司 一种aidl文件的共享方法及系统
CN107172197A (zh) * 2017-06-26 2017-09-15 努比亚技术有限公司 一种业务处理方法、系统及设备
FR3069669B1 (fr) * 2017-07-25 2019-10-18 Worldline Un systeme de communication et un procede d'acces et de deploiement des microservices ephemeres sur une plateforme heterogene
CN108829391B (zh) * 2018-05-04 2021-08-31 武汉极意网络科技有限公司 一种Fragment中控件识别方法及系统
CN109062705B (zh) * 2018-06-29 2021-06-01 Oppo（重庆）智能科技有限公司 进程间通信的监控方法、电子装置以及可读存储介质
CN109117340B (zh) * 2018-06-29 2022-03-29 Oppo（重庆）智能科技有限公司 一种移动终端及其进程间通信的监控方法、存储介质
CN109117278B (zh) * 2018-06-29 2021-02-26 Oppo（重庆）智能科技有限公司 一种移动终端及其进程间通信的限制方法、存储介质
CN109144745B (zh) * 2018-06-29 2021-04-27 Oppo（重庆）智能科技有限公司 进程间通信的监控方法、电子装置以及可读存储介质
CN109634573A (zh) * 2018-12-18 2019-04-16 宁夏隆基宁光仪表股份有限公司 Android操作系统App开发方法、装置及介质
CN109933443B (zh) * 2019-03-07 2021-06-25 腾讯科技（深圳）有限公司 进程间通信方法、装置、计算机设备及可读存储介质
CN110121197A (zh) * 2019-06-19 2019-08-13 深圳市沃特沃德股份有限公司 多卡通信系统、方法及装置
CN110275790A (zh) * 2019-06-26 2019-09-24 北京金山安全软件有限公司 应用程序中的进程间通信同步回调方法、系统及相关设备
CN110784404B (zh) * 2019-10-08 2022-03-25 烽火通信科技股份有限公司 一种多网口设备应用程序发包策略的调整方法及装置
CN112947993B (zh) * 2019-12-31 2021-12-07 深圳市明源云链互联网科技有限公司 系统框架的重构方法、装置、电子设备及存储介质
CN111339541B (zh) * 2020-02-20 2022-08-02 Oppo广东移动通信有限公司 基于binder驱动的进程间通信IPC机制的复用方法及装置
CN111443961B (zh) * 2020-03-24 2023-04-11 广州方硅信息技术有限公司 终端设备及其跨进程通信方法
CN111640191B (zh) * 2020-06-05 2023-04-21 南京爱奇艺智能科技有限公司 基于vr一体机的投录屏画面采集处理方法
CN111756846B (zh) * 2020-06-24 2023-09-29 杭州安森智能信息技术有限公司 一种轻量型机器人跨进程通信的方法
CN112783675B (zh) * 2021-01-29 2023-08-22 中汽创智科技有限公司 Ipc通信方法
CN114726905B (zh) * 2022-03-07 2023-09-15 中科创达软件股份有限公司 一种Tbox网络接入Android系统的方法、装置、设备及存储介质
CN115437706A (zh) * 2022-08-17 2022-12-06 中国银联股份有限公司 一种应用软件中服务能力调用方法和装置
CN116775161B (zh) * 2023-07-12 2024-10-15 深圳技威时代科技有限公司 一种Android平台跨进程音视频加载方法
CN119536966A (zh) * 2023-08-29 2025-02-28 华为技术有限公司 系统服务的控制方法、电子设备及可读存储介质
CN119556994A (zh) * 2023-09-01 2025-03-04 中兴终端有限公司 双系统控制方法、电子设备和计算机可读存储介质

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101141742A (zh) * 2007-10-12 2008-03-12 中兴通讯股份有限公司 一种终端的应用通信方法
WO2011032453A1 (zh) * 2009-09-16 2011-03-24 研祥智能科技股份有限公司 一种cpci热插拔系统
CN102833080A (zh) * 2011-06-15 2012-12-19 康佳集团股份有限公司 一种应用软件的进程间通信方法和系统

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101739300A (zh) * 2008-11-18 2010-06-16 中兴通讯股份有限公司 一种多媒体终端进程间通讯的方法和系统
US9389877B2 (en) * 2009-07-20 2016-07-12 Google Technology Holdings LLC Multi-environment operating system
WO2012044546A2 (en) * 2010-10-01 2012-04-05 Imerj, Llc Auto-waking of a suspended os in a dockable system
CN102520936B (zh) * 2011-11-30 2017-02-08 厦门雅迅网络股份有限公司 一种在Android上实现Socket通讯服务共享的方法
CN102591726B (zh) * 2011-12-31 2014-04-09 青岛海信宽带多媒体技术有限公司 一种多进程通信方法
US9063792B2 (en) * 2012-04-18 2015-06-23 Entrata Systems, Inc. Managing mobile execution environments
US9405562B2 (en) * 2012-10-18 2016-08-02 Broadcom Corporation Set top box application in a concurrent dual environment
CN103593225B (zh) * 2013-10-30 2016-10-05 浙江大学 移动虚拟化场景中多Android系统复用Binder IPC机制的方法
US9361163B2 (en) * 2013-11-28 2016-06-07 Good Technology Corporation Managing containerized applications on a mobile device while bypassing operating system implemented inter process communication

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101141742A (zh) * 2007-10-12 2008-03-12 中兴通讯股份有限公司 一种终端的应用通信方法
WO2011032453A1 (zh) * 2009-09-16 2011-03-24 研祥智能科技股份有限公司 一种cpci热插拔系统
CN102833080A (zh) * 2011-06-15 2012-12-19 康佳集团股份有限公司 一种应用软件的进程间通信方法和系统

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113326067A (zh) * 2021-05-11 2021-08-31 深圳市捷视飞通科技股份有限公司 命令执行方法、系统、计算机设备和存储介质
CN113326067B (zh) * 2021-05-11 2024-02-06 深圳市捷视飞通科技股份有限公司 命令执行方法、系统、计算机设备和存储介质
CN113378166A (zh) * 2021-06-25 2021-09-10 北京百度网讯科技有限公司 调用操作系统的应用程序接口api的方法和装置
CN113378166B (zh) * 2021-06-25 2024-05-31 北京百度网讯科技有限公司 调用操作系统的应用程序接口api的方法和装置
CN115098076A (zh) * 2022-07-18 2022-09-23 扬州航盛科技有限公司 一种用于Android系统的代码生成方法

Also Published As

Publication number Publication date
AU2014386583B2 (en) 2019-02-14
AU2014386583A1 (en) 2016-02-18
AU2014386583A8 (en) 2019-02-21
US20160344846A1 (en) 2016-11-24
US9923992B2 (en) 2018-03-20
CN103902390B (zh) 2017-04-19
AU2014386583B8 (en) 2019-02-21
CN103902390A (zh) 2014-07-02

Similar Documents

Publication Publication Date Title
WO2015135221A1 (zh) 基于Android的应用层的进程间通信方法及基础应用通信系统
EP3964953B1 (en) Containerized vnf deployment method and related device
CN102520936B (zh) 一种在Android上实现Socket通讯服务共享的方法
JP7100154B2 (ja) プロセッサコアのスケジューリング方法、装置、端末及び記憶媒体
CN101207568B (zh) 多协议适配器及其对多种业务实现适配处理的方法
US20200052982A1 (en) In situ triggered function as a service within a service mesh
CN109815025B (zh) 一种业务模型调用方法、装置及存储介质
WO2017049945A1 (zh) 加速器虚拟化的方法、装置及集中资源管理器
CN114039930B (zh) 数据包处理方法及系统
WO2025002287A1 (zh) 一种计算资源的提供方法、系统、电子设备及存储介质
CN112783675A (zh) Ipc通信方法
WO2022206770A1 (zh) 一种设备间应用协同工作的方法及设备
JP2004310298A (ja) 情報処理システム、情報処理装置、セッション管理方法及びプログラム
CN114205866A (zh) 确定性信息上报、下发方法、装置、存储介质及电子设备
WO2017028399A1 (zh) 通信数据传输方法及系统
CN114462388B (zh) 句柄管理或通信方法、电子设备、存储介质及程序产品
WO2024099036A1 (zh) 用于面向服务的网络的装置、方法、设备、及介质
CN102761545B (zh) 服务处理方法、服务处理器及服务处理系统
CN110071839B (zh) 支持数字信号处理器的corba通信装置
CN109669793B (zh) 中间件进程内对象调用方法
CN120448308A (zh) 基于rdma的数据传输方法、设备、存储介质及程序产品
CN114356602A (zh) 一种基于arinc653分区的rpc通信方法
WO2024145862A1 (zh) 一种数据传输方法及相关装置
CN100391150C (zh) 数据传送装置及数据传送方法
CN107463438B (zh) 用于多Openstack环境的信息处理方法、装置和系统

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 14885296

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 14906563

Country of ref document: US

ENP Entry into the national phase

Ref document number: 2014386583

Country of ref document: AU

Date of ref document: 20140317

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 30.01.2017)

122 Ep: pct application non-entry in european phase

Ref document number: 14885296

Country of ref document: EP

Kind code of ref document: A1