Android讀串口數(shù)據(jù)阻塞怎么辦

我這邊也在做Android和硬件設(shè)備的串口通信。

為長寧等地區(qū)用戶提供了全套網(wǎng)頁設(shè)計制作服務(wù)，及長寧網(wǎng)站建設(shè)行業(yè)解決方案。主營業(yè)務(wù)為網(wǎng)站設(shè)計、成都網(wǎng)站設(shè)計、長寧網(wǎng)站設(shè)計，以傳統(tǒng)方式定制建設(shè)網(wǎng)站，并提供域名空間備案等一條龍服務(wù)，秉承以專業(yè)、用心的態(tài)度為用戶提供真誠的服務(wù)。我們深信只要達(dá)到每一位用戶的要求，就會得到認(rèn)可，從而選擇與我們長期合作。這樣，我們也可以走得更遠(yuǎn)！

我的通信方式很簡單，我這邊發(fā)送數(shù)據(jù)，接收數(shù)據(jù)（接收數(shù)據(jù)的內(nèi)容中有標(biāo)識位讓我判斷這次接收到的數(shù)據(jù)的相應(yīng)處理動作）

讀數(shù)據(jù)的時候我做的是一個清空的辦法，每一次讀取數(shù)據(jù)，如果讀到的數(shù)據(jù)準(zhǔn)確則進(jìn)行處理，如果有誤就清空了在讀。

如果說接收的數(shù)據(jù)要對應(yīng)上發(fā)送的數(shù)據(jù)，你可以在Android這邊發(fā)送數(shù)據(jù)后不在發(fā)送數(shù)據(jù)只讀取，并開啟一個計時器，當(dāng)這段時間內(nèi)么有接收到返回值就繼續(xù)你的發(fā)送和讀取功能

Android如何阻塞一個線程讓其等待一個時間發(fā)生之后再繼續(xù)執(zhí)行？

你所謂的線程阻塞是指的ui線程嗎？這應(yīng)該是從你在開發(fā)的經(jīng)驗以及測試當(dāng)中去體驗的，如果你說是用代碼去判斷線程阻塞的話，估計比較復(fù)雜，也沒那個必要，android的機(jī)制在出現(xiàn)ui線程阻塞的話會出現(xiàn)anr給予用戶提示，出現(xiàn)這樣的情況是開發(fā)者在開發(fā)過程中就得去避免的！

Android廣播阻塞、延遲問題

? 最近項目中，多次碰到app研發(fā)人員反饋廣播從發(fā)送到接收器接收，間隔時間太長，要求系統(tǒng)進(jìn)行優(yōu)化，特別是開機(jī)階段。對此，專門閱讀了一下廣播從發(fā)送到接收這個流程的源碼，以徹底搞明白怎樣讓自己發(fā)送的廣播盡快到達(dá)接收器。

涉及到的源碼類不多，主要就是ActivityManagerService.java 和?BroadcastQueue.java。發(fā)送廣播進(jìn)程調(diào)用發(fā)送接口，通過IPC到達(dá)AMS,AMS根據(jù)Intent是否配置Intent.FLAG_RECEIVER_FOREGROUND，選擇當(dāng)前廣播加入前臺廣播隊列還是后臺廣播隊列。根據(jù)當(dāng)前廣播是否有序，將廣播加入廣播隊列的串行列表還是并行列表。廣播隊列和廣播隊列中的廣播列表是影響廣播接收時間的主要因素。

BroadcastQueue廣播隊列，負(fù)責(zé)將廣播發(fā)送給廣播接收器。AMS中有兩個成員變量，?

BroadcastQueue mFgBroadcastQueue;//前臺廣播隊列

BroadcastQueue mBgBroadcastQueue;//后臺廣播隊列

前臺廣播隊列和后臺廣播隊列的區(qū)別有兩處：1 超時時間，前臺10s，后臺60s. 2 是否延遲廣播等待前一個廣播進(jìn)程完成。這兩個區(qū)別已經(jīng)說明前臺廣播對廣播接收器要求更高，響應(yīng)時間更短，如果廣播要排隊，時間上前臺廣播更短。同時系統(tǒng)默認(rèn)使用后臺廣播隊列，所以前臺廣播隊列處理的廣播要少，避免了可能的大量廣播排隊情況。

廣播隊列中的列表

//存放無序并發(fā)送給動態(tài)廣播接收器的廣播任務(wù)

final ArrayListBroadcastRecord mParallelBroadcasts = new ArrayListBroadcastRecord();

//存放無序發(fā)送給靜態(tài)廣播接收器的廣播任務(wù)或者存放有序廣播任務(wù)

final ArrayListBroadcastRecord mOrderedBroadcasts = new ArrayListBroadcastRecord();

mParallelBroadcasts 此列表中存放的是無序廣播動態(tài)廣播接收器任務(wù)，廣播隊列會在處理任務(wù)時通過嵌套循環(huán)，把每個廣播通過ipc發(fā)送到關(guān)注它的所有進(jìn)程。所有無序廣播+動態(tài)廣播接收器，廣播不需要排隊。這種情況是最快能讓廣播到達(dá)目標(biāo)進(jìn)程的方式。

mOrderedBroadcasts存放的廣播任務(wù)特點：廣播有序，或者廣播接收器是靜態(tài)注冊的。此種類型的廣播全部要在mOrderedBroadcasts中排隊，廣播之間按時間先后，同一個廣播不同廣播接收器按優(yōu)先級。mOrderedBroadcasts存放的廣播必須等一個廣播任務(wù)處理完畢才能處理下一個，中間可能包含進(jìn)程的啟動等。

由此可見，廣播最快的情況是前臺廣播、無序廣播、動態(tài)注冊廣播接收器。最糟糕的情況是：后臺廣播、有序或靜態(tài)注冊廣播接收器、廣播接收器優(yōu)先級低。如果一個應(yīng)用只是簡單的靠注冊一個靜態(tài)廣播接收器拉起進(jìn)程，對應(yīng)的正是最糟糕的情況。如果又發(fā)生在開機(jī)階段，自然延遲嚴(yán)重。

如果必須注冊靜態(tài)廣播接收器，縮短時間的辦法為：配置Intent.FLAG_RECEIVER_FOREGROUND，加入前臺廣播隊列，設(shè)置廣播優(yōu)先級

源碼：

廣播發(fā)送：Context .sendBroadcast -ActivityManagerNative.broadcastIntent-ActivityManagerService.broadcastIntent-ActivityManagerService.broadcastIntentLocked.到此階段，跟發(fā)送廣播的進(jìn)程通信結(jié)束。此階段AMS完成的工作主要是根據(jù)Intent查找該廣播對應(yīng)的動態(tài)廣播接收器、靜態(tài)廣播接收器、以此發(fā)送該廣播使用的廣播隊列。

private final int broadcastIntentLocked(

......//權(quán)限檢查

......//特殊系統(tǒng)廣播進(jìn)行必要處理

if (sticky) {//粘性廣播處理

......

//查找靜態(tài)注冊的接收器

receivers = collectReceiverComponents(intent, resolvedType, users);

if (intent.getComponent() == null) {

// 查找動態(tài)廣播接收器

? ? ? ? registeredReceivers = mReceiverResolver.queryIntent(intent,

? ? ? ? ? ? ? ? resolvedType, false, userId);

? ? }

//動態(tài)廣播接收器

? ? int NR = registeredReceivers != null ? registeredReceivers.size() : 0;

? ? if (!ordered NR 0) {?

//確定隊列

? ? ? ? final BroadcastQueue queue = broadcastQueueForIntent(intent);

//創(chuàng)建廣播任務(wù)BroadcastRecord

? ? ? ? BroadcastRecord r = new BroadcastRecord(queue, intent, callerApp,

? ? ? ? ? ? ? ? callerPackage, callingPid, callingUid, resolvedType, requiredPermission,

? ? ? ? ? ? ? ? appOp, registeredReceivers, resultTo, resultCode, resultData, map,

? ? ? ? ? ? ? ? ordered, sticky, false, userId);

......

//廣播任務(wù)加入并行列表中

? ? ? ? ? ? queue.enqueueParallelBroadcastLocked(r);

//啟動異步發(fā)送廣播任務(wù)

? ? ? ? ? ? queue.scheduleBroadcastsLocked();

registeredReceivers = null;

? ? ? ? NR = 0;

......

while (it NT ir NR) {

......

//根據(jù)優(yōu)先級排序

? ? ? if (curt == null) {

? ? ? ? ? ? ? ? curt = (ResolveInfo)receivers.get(it);

? ? ? ? ? ? }

? ? ? ? ? ? if (curr == null) {

? ? ? ? ? ? ? ? curr = registeredReceivers.get(ir);

? ? ? ? ? ? }

? ? ? ? ? ? if (curr.getPriority() = curt.priority) {

? ? ? ? ? ? ? ? // Insert this broadcast record into the final list.

? ? ? ? ? ? ? ? receivers.add(it, curr);

//獲取廣播隊列

? ? ? ? BroadcastQueue queue = broadcastQueueForIntent(intent);

//創(chuàng)建廣播任務(wù)

? ? ? ? BroadcastRecord r = new BroadcastRecord(queue, intent, callerApp,

? ? ? ? ? ? ? ? callerPackage, callingPid, callingUid, resolvedType,

? ? ? ? ? ? ? ? requiredPermission, appOp, receivers, resultTo, resultCode,

? ? ? ? ? ? ? ? resultData, map, ordered, sticky, false, userId);

//加入到廣播隊列串行列表中

? ? ? ? ? ? queue.enqueueOrderedBroadcastLocked(r);

//啟動異步發(fā)送任務(wù)

? ? ? ? ? ? queue.scheduleBroadcastsLocked();

廣播隊列處理廣播：

final void processNextBroadcast(boolean fromMsg) {

......

//并行列表,遍歷廣播任務(wù)

? ? ? ? while (mParallelBroadcasts.size() 0) {

final int N = r.receivers.size();

//遍歷接收器

? ? ? ? ? ? for (int i=0; iN; i++) {

//IPC調(diào)用發(fā)送給目標(biāo)進(jìn)程

deliverToRegisteredReceiverLocked(r, (BroadcastFilter)target, false);

}

}

//有串行廣播任務(wù)正在執(zhí)行

if (mPendingBroadcast != null) {

? ? ? ? ?//接收廣播的目標(biāo)進(jìn)程正常

? ? ? ? ? ? if (!isDead) {

? ? ? ? ? ? ? ? // It's still alive, so keep waiting 繼續(xù)等待目前進(jìn)程反饋

? ? ? ? ? ? ? ? return;

? ? ? ? ? ? }

}

? ? ? ? ?//取出第一個廣播

? ? ? ? ? ? r = mOrderedBroadcasts.get(0);//判斷是否超時，

? ? ? ? ? ? ? ? if ((numReceivers 0) ?

? ? ? ? ? ? ? ? ? ? ? ? (now r.dispatchTime + (2*mTimeoutPeriod*numReceivers))) {

? ? ? ? ? ? ? ? ? ? ?//廣播超時

? ? ? ? ? ? ? ? ? ? ? broadcastTimeoutLocked(false);//超時處理，終止當(dāng)前廣播，啟動下一個任務(wù)。

? ? ? ? ? ? ? ? ? ? ? }

if (r.receivers == null || r.nextReceiver = numReceivers

? ? ? ? ? ? ? ? ? ? || r.resultAbort || forceReceive) {

? ? ? ? ? ? ?//所有廣播任務(wù)執(zhí)行完畢

}

int recIdx = r.nextReceiver++;//下一個廣播接收器

r.dispatchTime = r.receiverTime;//設(shè)置派發(fā)時間

setBroadcastTimeoutLocked(timeoutTime);//啟動超時計時

if (nextReceiver instanceof BroadcastFilter){//動態(tài)廣播接收器

deliverToRegisteredReceiverLocked(r, filter, r.ordered);//發(fā)送

return;

}

.//靜態(tài)廣播

? ? ? ? ResolveInfo info =

? ? ? ? ? ? (ResolveInfo)nextReceiver;

......

//檢查進(jìn)程是否已啟動

? ? ? ? ProcessRecord app = mService.getProcessRecordLocked(targetProcess,

? ? ? ? ? ? ? ? info.activityInfo.applicationInfo.uid, false);

? ? ? ? if (app != null app.thread != null) { /進(jìn)程啟動

? ? ? ? ? ?processCurBroadcastLocked(r, app);//發(fā)送靜態(tài)廣播

? ? ? ? ? ?return;

? ? ? ? }

?if ((r.curApp=mService.startProcessLocked(targetProcess,//啟動進(jìn)程

? ? ? ? ? ? ? ? info.activityInfo.applicationInfo, true,

? ? ? ? ? ? ? ? r.intent.getFlags() | Intent.FLAG_FROM_BACKGROUND,

? ? ? ? ? ? ? ? "broadcast", r.curComponent,

? ? ? ? ? ? ? ? (r.intent.getFlags()Intent.FLAG_RECEIVER_BOOT_UPGRADE) != 0, false, false))

? ? ? ? ? ? ? ? ? ? ? ? == null) {

? ? ? ? ? ? ? ? ? //進(jìn)程啟動失敗

? ? ? ? ? ? ? }

? ? ? ? ?//標(biāo)志正在發(fā)送的串行廣播

? ? ? ? mPendingBroadcast = r;

? ? ? ? mPendingBroadcastRecvIndex = recIdx;//正在發(fā)送的廣播任務(wù)對應(yīng)的接收器索引

}

android12 局域網(wǎng)播放 卡死

首先查看是否是網(wǎng)絡(luò)問題或者是系統(tǒng)問題。

1、CPU使用過高；

2、系統(tǒng)內(nèi)存使用過高；

3、UI阻塞。

android開發(fā)中卡頓問題一直是個比較棘手又重要的問題，嚴(yán)重影響了用戶的體驗感。解決卡頓的問題就要對APP進(jìn)行優(yōu)化了，而優(yōu)化是一個任重而道遠(yuǎn)的過程，必須在意每一個環(huán)節(jié)，否則當(dāng)你想要優(yōu)化的時候，發(fā)現(xiàn)到處都是坑，已經(jīng)不知道填補(bǔ)哪里了，所以我們必須一點一滴的做起。

android 阻塞ui多長時間宕機(jī)

android是一個多任務(wù)的系統(tǒng)，每個APP都會有自己的堆內(nèi)存，一般的UI 阻塞不會出現(xiàn)死機(jī)或重啟的，5秒會出現(xiàn)ANR, 即程序無響應(yīng)，只會造成APP本身掛掉。