android同步請求
❶ android原生登錄使用webview訪問h5 同步登錄狀態
目前使用的方案：
h5通過js和app交互調用app的token
2.拿到token後使用ajax做非同步登錄並刷新頁面
目前的缺點：
1.會多次刷新頁面
2.通過js調用時H5需要做部分改動
優化的方向：
A.APP登陸狀態的變化是請求頁面,登錄後使用webview調用對應域名下的介面實現H5的登錄
B.每次請求H5url增加get登陸的信息，例如訪問 index.php變成 index.php?a=xxx 通過附加信 息同步登錄狀態
優化的方案不知道那個更好一點
❷ Android網路請求庫【OkHttp4.9.3】基本用法與原理分析
OkHttp是一套處理 HTTP 網路請求的依賴庫，由 Square 公司設計研發並開源，目前可以在 java 和 Kotlin 中使用。對於 Android App 來說，OkHttp 現在幾乎已經占據了所有的網路請求操作，Retrofit + OkHttp實現網路請求似乎成了一種標配。因此它也是每一個 Android 開發工程師的必備技能，了解其內部實現原理可以更好地進行功能擴展、封裝以及優化。
OkHttp的高效性體現在：
第一步：創建OkHttpClient，創建OkHttpClient有兩種方式：
OkHttpClient提供了豐富的配置方法，例如添加攔截器、指定連接池、設置請求超時等等。
第二步：創建請求
使用Request.Builder() 構建Request實例
第三步：發起網路請求
OkHttp支持同步和非同步兩種請求方式
OkHttp的使用方法非常簡單，三步操作就可以發起一個簡單的同步或非同步請求。我們也可以很輕松地對網路請求進行配置，例如添加請求頭、設置請求方式、設置請求超時等等，這些配置參數會在源碼分析過程中詳細介紹。
現在我們已經學會了三步操作發起網路請求，接下來以這三個步驟為切入點，深入到源碼中學習OkHttp的實現原理，廢話少說馬上開車。
OkHttpClient創建方式有兩種，我們看看兩種方式有什麼區別。
第一種直接使用默認構造函數，內部依然是使用建造者模式
第二種使用建造者模式
兩種方式最終都是調用構造函數OkHttpClient(builder:Builder)，由參數builder負責所有的參數配置工作。
當您創建單個OkHttpClient實例並將其用於所有 HTTP 調用時，OkHttp 性能最佳。 這是因為每個OkHttpClient都擁有自己的連接池和線程池，重用連接和線程可減少延遲並節省內存。 相反，為每個請求創建一個客戶端會浪費空閑池上的資源。
Request同樣使用建造者模式來創建，這里貼上部分重要源碼，很簡單就不細說了。
OkHttp發起網路請求分為同步請求和非同步請求兩種方式，我們只分析非同步請求流程，因為只要理解了非同步請求過程，基本上也就明白同步請求是怎麼一回事了。
RealCall是連接應用層與網路層的橋梁，負責處理連接、請求、響應和數據流。
Dispatcher維護著一套非同步任務執行策略，分析策略之前先介紹幾個重要概念：
client.dispatcher.enqueue(AsyncCall(responseCallback)) 執行步驟為：
AsyncCall實現了Runnable介面，因此一旦被線程池中的線程處理就會調用它的run()方法：
話休絮煩，我們開始分析攔截器責任鏈：
責任鏈執行流程：首先獲取當前攔截器interceptor，並且調用interceptor.intercept(next)執行攔截器操作。這里的next表示的是index+1後的責任鏈對象，攔截器的intercept()方法內部會調用next.proceed(request)方法再次進入到責任鏈，由於此時index已經加1，所以處理的是下一個攔截器。
如此循環往復，直到處理完責任鏈上最後一個攔截器為止。
注意除最後一個攔截器CallServerInterceptor不會調用chain.proceed(request)方法之外，其他攔截器都應該至少調用一次chain.proceed(request)方法。
為了驗證上面的結論，我們進入到RetryAndFollowUpInterceptor的intercept()方法一探究竟：
可以看到注釋1處重新進入責任鏈處理下一個攔截器。
有興趣可以自行查看最後一個攔截器CallServerInterceptor源碼，此處只給出本人閱讀源碼後得出的結論：
以上就是攔截器責任鏈的工作流程，我們再通過流程圖仔細感受一下。
分析完攔截器責任鏈，我們繼續分析AsyncCall#run()方法：
我們看到，如果()方法成功獲得服務端返回的數據，則調用responseCallback.onResponse(this@RealCall, response)方法完成非同步回調；如果服務端數據獲取失敗（請求異常），則調用responseCallback.onFailure(this@RealCall, canceledException)方法完成非同步回調
需要注意的是，responseCallback回調是在子線程中完成的，所以如果想把數據顯示到UI上，需要切換回主線程進行UI操作。
OkHttp發起網路請求全過程：
【知識點】OkHttp 原理 8 連問
❸ 如何實現android客戶端與服務端數據同步
android客戶端不能直接與伺服器資料庫連接，拿sqlserver來說，安裝之後有幾個G那麼大，android程序是跑在手機上的，想讓程序直接訪問sqlserver，那手機需要非常大的內存。但是可以通過webservice這樣一個橋梁來間接訪問SQLServer。
即在伺服器運行一個服務端程序，該服務端程序通過接收來自android客戶端的指令，對資料庫進行操作。客戶端與服務端直接的數據傳輸主要通過http協議發送和接收json數據或者xml數據，服務端接收到客戶端的json數據之後，進行json解析，再按一定的邏輯對資料庫進行增、刪、改、查。客戶端的http請求可以通過 HttpClient類實現，在anddroid 4.0之後，客戶端的網路請求已經不被允許在主線程中運行，所以題主還需注意另開啟一個子線程進行網路請求。
❹ 如何實現 javascript 「同步」調用 app 代碼
在 App 混合開發中，app 層向 js 層提供介面有兩種方式，一種是同步介面，一種一非同步介面（不清楚什麼是同步的請看這里的討論）。為了保證 web 流暢，大部分時候，我們應該使用非同步介面，但是某些情況下，我們可能更需要同步介面。同步介面的好處在於，首先 js 可以通過返回值得到執行結果；其次，在混合式開發中，app 層導出的某些 api 按照語義就應該是同步的，否則會很奇怪——一個可能在 for 循環中使用的，執行非常快的介面，比如讀寫某個配置項，設計成非同步會很奇怪。
那麼如何向 js 層導出同步介面呢？
我們知道，在 Android 框架中，通過 WebView.addJavascriptInterface() 這個函數，可以將 java 介面導出到 js 層，並且這樣導出的介面是同步介面。但是在 iOS 的 Cocoa 框架中，想導出同步介面卻不容易，究其原因，是因為 UIWebView 和 WKWebView 沒有 addJavascriptInterface 這樣的功能。同時，Android 這個功能爆出過安全漏洞，那麼，我們有沒有別的方式實現同步調用呢？我們以 iOS UIWebView 為例提供一種實現，WKWebView 和 Android 也可以參考。
為了找到問題的關鍵，我們看一下 iOS 中實現 js 調用 app 的通行方法：
首先，自定義 UIWebViewDelegate，在函數 shouldStartLoadWithRequest:navigationType: 中攔截請求。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
- (BOOL) webView:(UIWebView* _Nonnull)webView
shouldStartLoadWithRequest:(NSURLRequest* _Nonnull)request
navigationType:(UIWebViewNavigationType)navigationType {
if ([request.HTTPMethod compare:@"GET" options:NSCaseInsensitiveSearch] != NSOrderedSame) {
// 不處理非 get 請求
return YES;
}
NSURL* url = request.URL;
if ([url.scheme isEqualToString:@'YourCustomProtocol']) {
return [self onMyRequest:request];
}
return YES;
}
這種做法實質上就是將函數調用命令轉化為 url，通過請求的方式通知 app 層，其中 onMyRequest: 是自定義的 request 響應函數。為了發送請求，js 層要建立一個隱藏的 iframe 元素，每次發送請求時修改 iframe 元素的 src 屬性，app 即可攔截到相應請求。
1
2
3
4
5
6
7
8
9
10
11
12
13
/**
* js 向 native 傳遞消息
* @method js_sendMessageToNativeAsync
* @memberof JSToNativeIOSPolyfill
* @public
* @param str {String} 消息字元串，由 HybridMessage 轉換而來
*/
JSToNativeIOSPolyfill.prototype.js_sendMessageToNativeAsync = function (str) {
if (!this.ifr_) {
this._prepareIfr();
}
this.ifr_.src = 'YourCustomProtocol://__message_send__?msg=' + encodeURIComponent(str); }
當 app 執行完 js 調用的功能，執行結果無法直接返回，為了返回結果，普遍採用回調函數方式——js 層記錄一個 callback，app 通過 UIWebView 的 函數調用這個 callback（類似 jsonp 的機制）。
注意，這樣封裝的介面，天然是非同步介面。因為 js_sendMessageToNativeAsync 這個函數會立即返回，不會等到執行結果發回來。
所以，我們要想辦法把 js 代碼「阻塞」住。
請回憶一下，js 中是用什麼方法能把 UI 線程代碼「阻塞」住，同時又不跑滿 CPU？
1
2
3
4
var async = false;
var url = 'http://.com';
var method = 'GET';<br>var req = new XMLHttpRequest();<br>
req.open(method, url, async);<br>req.send(null);
「同步」ajax（其實沒這個詞，ajax 內涵非同步的意思）可以！在 的響應沒返回之前，這段代碼會一直阻塞。一般來說同步請求是不允許使用的，有導致 UI 卡頓的風險。但是在這里因為我們並不會真的去遠端請求內容，所以不妨一用。
至此實現方式已經比較清楚了，梳理一下思路：
使用同步 XMLHttpRequest 配合特殊構造的 URL 通知 app層。
app 層攔截請求執行功能，將結果作為 Response 返回。
XMLHttpRequest.send() 返回，通過 status 和 responseText 得到結果。
那麼，如何攔截請求呢？大家知道，UIWebViewDelegate 是不會攔截 XMLHttpRequest 請求的，但是 iOS 至少給了我們兩個位置攔截這類請求——NSURLCache 和 NSURLProtocol。
一、NSURLCache 是 iOS 中用來實現自定義緩存的類，當你創建了自定義的 NSURLCache 子類對象，並將其設置為全局緩存管理器，所有的請求都會先到這里檢查有無緩存（如果你沒禁掉緩存的話）。我們可以藉助這個性質攔截到介面調用請求，執行並返回數據。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
- (NSCachedURLResponse*) cachedResponseForRequest:(NSURLRequest *)request {
if ([request.HTTPMethod compare:@"GET" options:NSCaseInsensitiveSearch] != NSOrderedSame) {
// 只對 get 請求做自定義處理
return [super cachedResponseForRequest:request];
}
NSURL* url = request.URL;
NSString* path = url.path;
NSString* query = url.query;
if (path == nil || query == nil) {
return [super cachedResponseForRequest:request];
}
LOGF(@"url = %@, path = %@, query = %@", url, path, query);
if ([path isEqualToString:@"__env_get__"]) {
// 讀環境變數
return [self getEnvValueByURL:url]; //*
} else if ([path isEqualToString:@"__env_set__"]) {
// 寫環境變數
return [self setEnvValueByURL:url];
}
return [super cachedResponseForRequest:request];
}
注意注釋有 ＊ 號的一行，即是執行 app 介面，返回結果。這里的結果是一個 NSCachedResponse 對象，就不贅述了。
❺ 蘋果手機在哪裡設置同步呢
首先我們點擊打開手機的設置功能
手動將其設置為打開，然後在彈出的對話窗口選擇「保留在我的iphone」，這樣就成功的將自動同步功能打開了。
❻ 蘋果5s同步功能在哪裡
iphone5s可以通過以下方法同步：
一、Google賬號的聯系人同步
1、依次進入「功能表-工具-同步處理-選項-新同步情景模式-編輯。
2、同步情景模式名稱處填寫：Google Sync
3、進入「應用程序」，選擇名片夾，填寫如下：
是否同步--選擇「是」。
遠程資料庫處填寫：Conetacts。
同步類型：雙向
4、進入連接設置
伺服器版本：1.2。
伺服器識別碼：這里很關鍵「一定是Google，注意第一個字母大寫」，否則「系統錯誤」。
數據承載方式選擇：互聯網。
接入點：如果用Wi-Fi的話，建議先把Wi-Fi連接好，其它的無所謂。
註：Google Sync支持Wi-Fi，CMNET，CMWAP和3GNET等接入點，在「主機地址」處輸入：https://m.google.com/syncml
5、埠：443
6、在「用戶名」處輸入注冊好的Google賬號，此處不許輸入後綴@gmail.com
7、輸入Google賬戶的密碼。
允許同步請求-是；
接受所有同步請求-是；
網路鑒定-否。
8、在「用戶名」處輸入注冊好的Google賬號
9、輸入Google賬戶的密碼
10、選擇「是」，進入下一步，只選中「名片夾」，取消其他項目，選擇「選項-同步」即可開始同步。
而Android手機的備份就簡單多了，直接登陸常用的Market，一般默認系統是開啟賬號同步功能的。
二、91手機助導入
使用91手機助手就很簡單了。不過導入到蘋果手機裡面，那就先要先越獄了。
打開91手機助手iphone版，選擇資料管理-聯系人-導入聯系人。這樣就可以把備份好的手機名片導入到新手機里了。還可以導出Android手機的名片夾。不過要下載Android版。
三、sim卡中通訊錄導入方法
1、sim卡中通訊錄的導入方法相信很多網站都曾經教過，但是並沒有配圖文不夠細致。具體方法如下，插入卡後找到iPhone中的設置選項，進入後找到「郵件、通信錄、日歷」選項。
2、點擊進入後再找到通訊錄欄目下的「導入sim卡通訊錄」即可。
四、QQ同步助手
很多用戶的手機導出通訊錄後並不能存成csv或Vcard格式，這時需要使用到的軟體就是QQ同步助手。
首先在舊手機中下載QQ同步手機助手，以三星手機為例，下載QQ同步手機助手後登陸QQ號，點擊「同步」按鈕上傳至雲服務端。
再拿出iPhone，同樣下載一個QQ同步手機助手，同樣等了剛剛所登陸的QQ，這時會發現自己QQ號內的「雲」已經備份了一份通訊錄，只要點導入即可。
❼ android 如何關閉NTP網路時間同步
Linux停止ntp服務即可關閉時間同步。
①關閉ntp服務（臨時設置重啟後自動開啟）
service ntpd stop
②設置永久關閉ntp服務（重啟後也是關閉的）
chkconfig ntpd off
❽ android網路請求數據是同步還是非同步
非同步請求,因為UI線程(主線程)不允許有5秒以上的耗時操作.在主線程網路請求會導致阻塞,看起來程序就像假死了一樣.所以都是非同步請求.
❾ Android-Choreographer 垂直同步 Vsync
view.requestLayout 調用的是 parent.requestLayout，直到 DecorView 最終到 ViewRootImpl.requestLayout 方法。
提示: requestLayout() 跟 invalidate() 區別在於 PFLAG_FORCE_LAYOUT、PFLAG_INVALIDATED，invalidate 不會重新測量布局，只會重新繪制
調用棧：mChoreographer.postCallback(int callbackType, Runnable action, Object token) --> postCallbackDelayed() --> postCallbackDelayedInternal()
至此從調用 requestLayout 到請求 Vsync 信號過程已經結束。
下面看收到 Vsync 信號後，如何處理 mTraversalRunnable 任務。
doTraversal()方法則是 測量、布局、繪制 入口，此處不做分析。
Vsync 垂直同步：
涉及到垂直刷新脈沖、vsync 、gpu 緩沖區 Frame Buffer、Back Buffer 三重緩存，跟 Choreographer
gpu 像素柵格化
垂直同步使得顯卡的輸出幀數和屏幕的刷新速度保持一致，其中 vsync 用來同步信息，buffer 緩存數據，當 vsync 出現時，cpu 會立即處理下一幀數據寫入到緩存中，
之後gpu再渲染數據寫在同一個緩存中，當vsync時，下一幀的 buffer 跟當前幀所在的buffer數據交換，當如果之前幀未顯示完，是不會進行數據交換的。屏幕掃描下一次的數據顯示。
當一個信號來時，假設a b buffer都被佔用，此時gpu使用c緩存下一幀的數據，可以有效減少掉幀的幾率。
1、view.requestLayout 調用的是 parent.requestLayout ,直到 DecorView 最終到 ViewRootImpl.requestLayout 方法。
2、首先判斷正在測量布局，沒有則 checkThread 檢驗當前是否在主線程。在 scheleTraversals 首先中執行同步屏障，其次再將任務 postCallback 給 Choreographer，Choreographer 將任務保存在 mCallbackQueues 中，同時發送 MSG_DO_SCHEDULE_CALLBACK 的同步消息給FrameHandler。FrameHandler 的優先執行 CALLBACK 同步消息調用 doScheleCallback，mCallbackQueues 不為空且 callback 不是延遲執行，調用 scheleFrameLocked 方法請求 Vsync 信號。當運行在 Looper 線程，則立刻調度 vsync，否則，發送消息到UI線程再調度 vsync。其中是通過 FrameDisplayEventReceiver 調度 vysnc。
FrameDisplayEventReceiver 有兩個作用，一個是 scheleVsync 請求調度，另一個是接收 vsync 信號回調 onVsync，當接收到 vsync 信號時，調用doFrame 方法，開始渲染下一幀。
doFrame 可以分為三步：一是計算掉幀邏輯，二是記錄幀繪制信息，三是處理多種 callback，依次是 input 調用棧,會回調到 DecorView 的 dispatchTouchEvent。
二是 animation 調用棧，執行動畫；三是 Traversal 調用棧，即最發送給 Choreographer 的任務
動畫如何流暢執行： 調用animation.start時，最終在AnimationHandler會給Choreographer.FrameCallback 回調 doFrame，裡面 post了自己。
❿ android 可以監聽okhttp的網路請求嗎
1、首先 創建 一個mOkHttpClient = new OkHttpClient()對象；
2、構建Request請求對象（根據get和post不同的請求方式分別創建）；
3、如果是 post請求還需要 構建 請求參數 Params，RequestBody requestBody = buildFormData(params); builder.post(requestBody).build;；
4、進行網路非同步請求 mOkHttpClient.newCall(request).enqueue(new Callback() {} ），如果是同步請求，則改為 Response response = mOkHttpClient.newCall(request).execute()進行 ；
具體實現就不細說了，直接上代碼如下：
[html] view plain
public class OkHttpManager {
private static OkHttpManager mOkHttpManager;
private OkHttpClient mOkHttpClient;