淺析APP之間相互交互的原理
APP之間相互調用并且傳輸數據經常會出現在實際需求中,我們應該對這樣的基本功能的實現原理有一個簡單的認識,這樣也方便工作中和程序哥哥們的溝通。
在產品設計中,經常會遇到APP之間相互調用的功能設計,比如:
- 實現三方登錄。用QQ賬號快速登錄,如果安裝了 QQ,那么應用會調用QQ的快速登錄界面,確認后, QQ會回調到原來的應用,同時將登錄的狀態信息返回給了原應用。
- 實現分享。選擇應用內的可分享內容,點擊分享, 選擇朋友圈,于是微信的朋友圈被調起,并將這張圖片發了出去,并詢問你是返回原應用還是留在微信,如果你選擇了返回原應用,那么原來的應用又會被調起。
- 實現第三方支付。選擇應用內要支付的內容,選擇支付方式,一般會提供支付寶或微信,點擊后跳轉到支付寶或微信的付款頁面,完成支付后回到該應用。
- 實現手機網頁引導并打開應用功能。在推廣的H5頁面上,加入打開APP的按鈕,點擊后直接調起我們的APP,并且可以根據參數信息, 在本地應用中還原用戶的瀏覽場景。
這些過程實現的原理就是利用?URL Scheme。
什么是URL Scheme
URL Scheme就是一個可以讓app相互之間可以跳轉的協議。每個app的URL Scheme都是不一樣的,如果存在一樣的URL Scheme,那么系統就會響應先安裝那個app的URL Scheme,因為后安裝的app的URL Scheme被覆蓋掉了,是不能被調用的。
應用之間跳轉原理
一個應用能打開另一個應用的必然條件是,另一個應用必須配置一個scheme(協議),這樣應用程序才能根據協議找到需要打開的應用。
APP應用在系統中通過注冊Scheme的方式注冊自己,常見的Scheme就是 http:,聲明了這個Scheme的應用就是聲稱自己支持http協議,能夠打開網頁了。還有一些常見的Scheme比如 file:(傳輸文本), tel:(通話)等。
當然,APP應用不僅可以聲明這些標準的Scheme,也能聲明自己獨有的Scheme,比如微信的就是 weixin:, QQ 的是 mqq: 。
如果多個應用都聲明相同的Scheme呢?比如應用a、b、c都聲明自己能發短信,這時系統會有一定的策略來保證公平性,比如在Android系統中,就會彈出支持的應用列表,讓用戶選擇, iOS則替用戶選擇近打開過的支持應用。
應用之間傳遞數據
了解了應用之間調用的方法,那么后面數據傳遞就簡單了,只需要在Scheme后面攜帶上需要傳遞的信息作為參數就可以了。
比如,發起調用的是應用A,被調用的是應用B。yingyongB://action=sendmessage,message=”xxx”,后面的數據會帶到應用B中,但是應用B接到了信息不知道該信息是哪個應用發的,回信息給哪個應用。如何進行回調呢?發起調用的應用A在Scheme后面加一個參數backScheme=yingyongA: ,這樣應用B就知道了需要返回信息給應用A,應用A和B這種自定義協議也可以叫做偽協議,只要雙方應用能識別處理就可以。
同樣,我們也可以實現跳轉到指定頁面的功能。想要跳轉到指定界面,必定是上一個app告訴下一個app(被跳轉的app)需要跳轉到哪個界面,而如何告訴它這里便涉及到兩個app的通信。兩個app之間的跳轉只需要配置一個Scheme,通過協議即可實現。
最后上一段iOS測試代碼:
//進入更多界面(上一個APP)
– (IBAction)intoMore:(id)sender {
NSURL *url = [NSURL URLWithString:@”test://more”]; ? //test://more是要跳轉的頁面名稱
if ([[UIApplication sharedApplication] canOpenURL:url]) {
[[UIApplication sharedApplication] openURL:url]; //是否安裝應用,url是跳轉頁面的地址
}else{
NSLog(@”沒有安裝應用”); //沒有安裝則提示相應信息
}
}
在被調用的APP中,就會監聽方法,對進入的頁面進行判斷。
總結
以上就是應用之間進行交互原理的簡單總結,不同平臺會有自己一些獨特的應用交互方式,用Scheme這種方式可以減少一些跨平臺開發適配的成本,同時也有利于網頁和Native之間的相互調用。
作者:流年,互聯網產品設計師,4年互聯網產品設計經驗。
本文由 @流年 原創發布于人人都是產品經理。未經許可,禁止轉載。
大佬,贊贊!
111