androidsignal
1. 如何查看Android手機信號強度
首先，進鏈敗派入設置選項，在主屏界面中按下Android手機Menu鍵，在彈出的進階菜單中選擇最後一項「Settings」;
將滑動條拖動至最下方，點擊「About Phone」分類;
選擇第二項「Status」分類;
這時，就能夠看到「Signal Strength」選項，前面的-xx(這枯絕是一個負數數字)dBm則是手機信號強度。一般「0」—「-50」之間都是一個非常不錯的信號強度，而數值越小則棚賀代表著信號越差。
2. 篇文章會先對照binder機制與linux的通信機制的區別，了解為什麼android會另起爐灶
1）從性能的角度
數據拷貝次數：Binder數據拷貝只需要一次，而管道、消息隊列、Socket都需要2次，但共享內存方式一次內存拷貝都不需要；從性能角度看，Binder性能僅次於共享內存。
（2）從穩定性的角度
Binder是基於C/S架構的，簡單解釋下C/S架構，是指客戶端(Client)和服務端(Server)組成的架構，Client端有什麼需求，直接發送給Server端去完成，架構清晰明朗，Server端與Client端相對獨立，穩定性較好；而共享內存實現方式復雜，沒有客戶與服務端之別， 需要充分考慮到訪問臨界資源的並發同步問題，否則可能會出現死鎖等問題；從這穩定性角度看，Binder架構優越於共享內存。
僅僅從以上兩點，各有優劣，還不足以支撐google去採用binder的IPC機制，那麼更重要的原因是：
（3）從安全的角度
傳統Linux IPC的接收方無法獲得對方進程可靠的UID/PID，從而無法鑒別對方身份；而Android作為一個開放的開源體系，擁有非常多的開發平台，App來源甚廣，因此手機的安全顯得額外重要；對於普通用戶，絕不希望從App商店下載偷窺隱射數據、後台造成手機耗電等等問題，傳統Linux IPC無任何保護措施，完全由上層協議來確保。
Android為每個安裝好的應用程序分配了自己的UID，故進程的UID是鑒別進程身份的重要標志，前面提到C/S架構，Android系統中對外只暴露Client端，Client端將任務發送給Server端，Server端會根據許可權控制策略，判斷UID/PID是否滿足訪問許可權，目前許可權控制很多時候是通過彈出許可權詢問對話框，讓用戶選擇是否運行。Android 6.0，也稱為Android M，在6.0之前的系統是在App第一次安裝時，會將整個App所涉及的所有許可權一次詢問，只要留意看會發現很多App根本用不上通信錄和簡訊，但在這一次性許可權許可權時會包含進去，讓用戶拒絕不得，因為拒絕後App無法正常使用，而一旦授權後，應用便可以胡作非為。
針對這個問題，google在Android M做了調整，不再是安裝時一並詢問所有許可權，而是在App運行過程中，需要哪個許可權再彈框詢問用戶是否給相應的許可權，對許可權做了更細地控制，讓用戶有了更多的可控性，但同時也帶來了另一個用戶詬病的地方，那也就是許可權詢問的彈框的次數大幅度增多。對於Android M平台上，有些App開發者可能會寫出讓手機異常頻繁彈框的App，企圖直到用戶授權為止，這對用戶來說是不能忍的，用戶最後吐槽的可不光是App，還有Android系統以及手機廠商，有些用戶可能就跳果粉了，這還需要廣大Android開發者以及手機廠商共同努力，共同打造安全與體驗俱佳的Android手機。
Android中許可權控制策略有SELinux等多方面手段，下面列舉從Binder的一個角度的許可權控制：
Android源碼的Binder許可權是如何控制？ -Gityuan的回答
傳統IPC只能由用戶在數據包里填入UID/PID；另外，可靠的身份標記只有由IPC機制本身在內核中添加。其次傳統IPC訪問接入點是開放的，無法建立私有通道。從安全形度，Binder的安全性更高。
說到這，可能有人要反駁，Android就算用了Binder架構，而現如今Android手機的各種流氓軟體，不就是干著這種偷窺隱射，後台偷偷跑流量的事嗎？沒錯，確實存在，但這不能說Binder的安全性不好，因為Android系統仍然是掌握主控權，可以控制這類App的流氓行為，只是對於該採用何種策略來控制，在這方面android的確存在很多有待進步的空間，這也是google以及各大手機廠商一直努力改善的地方之一。在Android 6.0，google對於app的許可權問題作為較多的努力，大大收緊的應用許可權；另外，在Google舉辦的Android Bootcamp 2016大會中，google也表示在Android 7.0 （也叫Android N）的許可權隱私方面會進一步加強加固，比如SELinux，Memory safe language(還在research中)等等，在今年的5月18日至5月20日，google將推出Android N。
（4）從語言層面的角度
大家多知道Linux是基於C語言(面向過程的語言)，而Android是基於Java語言(面向對象的語句)，而對於Binder恰恰也符合面向對象的思想，將進程間通信轉化為通過對某個Binder對象的引用調用該對象的方法，而其獨特之處在於Binder對象是一個可以跨進程引用的對象，它的實體位於一個進程中，而它的引用卻遍布於系統的各個進程之中。可以從一個進程傳給其它進程，讓大家都能訪問同一Server，就像將一個對象或引用賦值給另一個引用一樣。Binder模糊了進程邊界，淡化了進程間通信過程，整個系統彷彿運行於同一個面向對象的程序之中。從語言層面，Binder更適合基於面向對象語言的Android系統，對於Linux系統可能會有點「水土不服」。
另外，Binder是為Android這類系統而生，而並非Linux社區沒有想到Binder IPC機制的存在，對於Linux社區的廣大開發人員，我還是表示深深佩服，讓世界有了如此精湛而美妙的開源系統。也並非Linux現有的IPC機制不夠好，相反地，經過這么多優秀工程師的不斷打磨，依然非常優秀，每種Linux的IPC機制都有存在的價值，同時在Android系統中也依然採用了大量Linux現有的IPC機制，根據每類IPC的原理特性，因時制宜，不同場景特性往往會採用其下最適宜的。比如在Android OS中的Zygote進程的IPC採用的是Socket（套接字）機制，Android中的Kill Process採用的signal（信號）機制等等。而Binder更多則用在system_server進程與上層App層的IPC交互。
(5) 從公司戰略的角度
總所周知，Linux內核是開源的系統，所開放源代碼許可協議GPL保護，該協議具有「病毒式感染」的能力，怎麼理解這句話呢？受GPL保護的Linux Kernel是運行在內核空間，對於上層的任何類庫、服務、應用等運行在用戶空間，一旦進行SysCall（系統調用），調用到底層Kernel，那麼也必須遵循GPL協議。
而Android 之父 Andy Rubin對於GPL顯然是不能接受的，為此，Google巧妙地將GPL協議控制在內核空間，將用戶空間的協議採用Apache-2.0協議（允許基於Android的開發商不向社區反饋源碼），同時在GPL協議與Apache-2.0之間的Lib庫中採用BSD證授權方法，有效隔斷了GPL的傳染性，仍有較大爭議，但至少目前緩解Android，讓GPL止步於內核空間，這是Google在GPL Linux下 開源與商業化共存的一個成功典範。
3. 如何調試分析Android中發生的tombstone
Android中較容易出現以下三類問題:Force close / ANR / Tombstone
前兩者主要是查看當前的進程或者系統框架層的狀態和堆棧就基本可以分析出來，本文主要討論一下tombstone的情況。
tombstone一般是由Dalvik錯誤、狀態監視調試器、C層代碼以及libc的一些問題導致的。
當
系統發生tombstone的時候，kernel首先會上報一個嚴重的警告信號（signal）,上層接收到之後，進程的調試工具會把進程中當時的調用棧
現場保存起來，並在系統創建了data/tombstones目錄後把異常時的進程信息寫在此目錄裡面，開發者需要通過調用棧來分析整個調用流程來找出出
問題的點。
基本工具：
prebuilt/linux-x86/toolchain/arm-eabi-4.4.0/bin
在分析的時候仔細讀取匯編會獲得更多有用的異常發生時的信息。
1.arm-eabi-addr2line 將類似libxxx.so 0x00012345的調用棧16進制值翻譯成文件名和函數名
arm-eabi-addr2line -e libxxx.so 0x00012345
2.arm-eabi-nm 列出文件的符號信息
arm-eabi-nm -l -C -n -S libdvm.so > dvm.data
3.arm-eabi-objmp 列出文件的詳細信息
arm-eabi-objmp -C -d libc.so > libc.s
通過以上工具的分析 ，我們可以得到較完整的調用棧以及調用邏輯的匯編碼。
然後需要結合ARM架構及ARM匯編的知識（有些情況下可能需要使用gdb）
來分析出現tombstone的原因，以下是本人遇到過的一些tombstone的情況：
1.無效的函數指針：指針為NULL或者已經被重新賦值
2.strlen崩潰：導致不完全的棧信息，棧被破壞
3.FILE操作：因為stdio並非線程安全的，多線程操作時，容易出現異常。
望採納。