android文件分析

① Android系統文件夾結構詳細解析！

\\system\\app
這個裡面主要存放的是常規下載的應用程序，可以看到都是以APK格式結尾的文件。在這個文件夾下的程序為系統默認的組件，自己安裝的軟體將不會出現在這里，而是\\data\\文件夾中。下面是詳細的介紹:
\\system\\app\\AlarmClock.apk 鬧鍾
\\system\\app\\AlarmClock.odex
\\system\\app\\Browser.apk 瀏覽器
\\system\\app\\Browser.odex
\\system\\app\\Bugreport.apk Bug報告
\\system\\app\\Bugreport.odex
\\system\\app\\Calculator.apk 計算器
\\system\\app\\Calculator.odex
\\system\\app\\Calendar.apk 日歷
\\system\\app\\Calendar.odex
\\system\\app\\CalendarProvider.apk 日歷提供
\\system\\app\\CalendarProvider.odex
\\system\\app\\Camera.apk 照相機
\\system\\app\\Camera.odex
\\system\\app\\com.amazon.mp3.apk 亞馬遜音樂
\\system\\app\\Contacts.apk 聯系人
\\system\\app\\Contacts.odex
\\system\\app\\DownloadProvider.apk 下載提供
\\system\\app\\DownloadProvider.odex
\\system\\app\\DrmProvider.apk DRM數字版權提供
\\system\\app\\DrmProvider.odex
\\system\\app\\Email.apk 電子郵件客戶端
\\system\\app\\Email.odex
\\system\\app\\FieldTest.apk 測試程序
\\system\\app\\FieldTest.odex
\\system\\app\\GDataFeedsProvider.apk GoogleData提供
\\system\\app\\GDataFeedsProvider.odex
\\system\\app\\Gmail.apk Gmail電子郵件
\\system\\app\\Gmail.odex
\\system\\app\\GmailProvider.apk Gmail提供
\\system\\app\\GmailProvider.odex
\\system\\app\\GoogleApps.apk 谷歌程序包
\\system\\app\\GoogleApps.odex
\\system\\app\\GoogleSearch.apk 搜索工具
\\system\\app\\GoogleSearch.odex
\\system\\app\\gtalkservice.apk GTalk服務
\\system\\app\\gtalkservice.odex
\\system\\app\\HTMLViewer.apk HTML查看器
\\system\\app\\HTMLViewer.odex
\\system\\app\\IM.apk 即使通訊組件包含MSN、yahoo通
\\system\\app\\ImCredentialProvider.apk
\\system\\app\\ImProvider.apk
\\system\\app\\ImProvider.odex
\\system\\app\\Launcher.apk 啟動載入器
\\system\\app\\Launcher.odex
\\system\\app\\Maps.apk 電子地圖
\\system\\app\\Maps.odex
\\system\\app\\MediaProvider.apk 多媒體播放提供
\\system\\app\\MediaProvider.odex
\\system\\app\\Mms.apk 簡訊、彩信
\\system\\app\\Mms.odex
\\system\\app\\Music.apk 音樂播放器
\\system\\app\\Music.odex
\\system\\app\\MyFaves.apk T-Mobile MyFaves程序
\\system\\app\\MyFaves.odex
\\system\\app\\PackageInstaller.apk apk安裝程序
\\system\\app\\PackageInstaller.odex
\\system\\app\\Phone.apk 電話撥號器
\\system\\app\\Phone.odex
\\system\\app\\Settings.apk 系統設置
\\system\\app\\Settings.odex
\\system\\app\\SettingsProvider.apk 設置提供
\\system\\app\\SettingsProvider.odex
\\system\\app\\SetupWizard.apk 設置向導
\\system\\app\\SetupWizard.odex
\\system\\app\\SoundRecorder.apk 錄音工具
\\system\\app\\SoundRecorder.odex
\\system\\app\\Street.apk 街景地圖
\\system\\app\\Street.odex
\\system\\app\\Sync.apk 同步程序
\\system\\app\\Sync.odex
\\system\\app\\Talk.apk 語音程序
\\system\\app\\Talk.odex
\\system\\app\\TelephonyProvider.apk 電話提供
\\system\\app\\TelephonyProvider.odex
\\system\\app\\Updater.apk 更新程序
\\system\\app\\Updater.odex
\\system\\app\\Vending.apk 製造商信息
\\system\\app\\Vending.odex
\\system\\app\\VoiceDialer.apk 語音撥號器
\\system\\app\\VoiceDialer.odex
\\system\\app\\YouTube.apk Youtube視頻
\\system\\app\\YouTube.odex

\\system\\bin
這個目錄下的文件都是系統的本地程序，從bin文件夾名稱可以看出是binary二進制的程序，裡面主要是linux系統自帶的組件，Android手機網就主要文件做下簡單的分析介紹：
\\system\\bin\\akmd
\\system\\bin\\am
\\system\\bin\\app_process 系統進程
\\system\\bin\\dalvikvm Dalvik虛擬機宿主
\\system\\bin\\dbus-daemon 系統BUS匯流排監控
\\system\\bin\\debuggerd 調試器
\\system\\bin\\debug_tool 調試工具
\\system\\bin\\dexopt DEX選項
\\system\\bin\\dhcpcd DHCP伺服器
\\system\\bin\\mpstate 狀態抓取器
\\system\\bin\\mpsys 系統抓取器
\\system\\bin\\dvz
\\system\\bin\\fillup
\\system\\bin\\flash_image 快閃記憶體映像
\\system\\bin\\hciattach
\\system\\bin\\hcid HCID內核
\\system\\bin\\hostapd
\\system\\bin\\hostapd_cli
\\system\\bin\\htclogkernel
\\system\\bin\\input
\\system\\bin\\installd
\\system\\bin\\itr
\\system\\bin\\linker
\\system\\bin\\logcat Logcat日誌列印
\\system\\bin\\logwrapper
\\system\\bin\\mediaserver
\\system\\bin\\monkey
\\system\\bin\\mountd 存儲掛載器
\\system\\bin\\netcfg 網路設置
\\system\\bin\\ping Ping程序
\\system\\bin\\playmp3 MP3播放器
\\system\\bin\\pm 包管理器
\\system\\bin\\qemud QEMU虛擬機
\\system\\bin\\radiooptions 無線選項
\\system\\bin\\rild RIL組件
\\system\\bin\\sdptool
\\system\\bin\\stil
\\system\\bin\\service
\\system\\bin\\servicemanager 服務管理器
\\system\\bin\\sh
\\system\\bin\\ssltest SSL測試
\\system\\bin\\surfaceflinger 觸摸感應驅動
\\system\\bin\\svc 服務
\\system\\bin\\system_server
\\system\\bin\\telnetd Telnet組件
\\system\\bin\\toolbox
\\system\\bin\\wlan_loader
\\system\\bin\\wpa_cli
\\system\\bin\\wpa_supplicant

\\system\\etc
從文件夾名稱來看保存的都是系統的配置文件，比如APN接入點設置等核心配置。
\\system\\etc\\apns-conf.xml APN接入點配置文件
\\system\\etc\\AudioFilter.csv 音頻過濾器配置文件
\\system\\etc\\AudioPara4.csv
\\system\\etc\\bookmarks.xml 書簽資料庫
\\system\\etc\\dbus.conf 匯流排監視配置文件
\\system\\etc\\dhcpcd
\\system\\etc\\event-log-tags
\\system\\etc\\favorites.xml 收藏夾
\\system\\etc\\firmware 固件信息
\\system\\etc\\gps.conf GPS設置文件
\\system\\etc\\hcid.conf內核HCID配置文件
\\system\\etc\\hosts 網路DNS緩存
\\system\\etc\\init.goldfish.sh
\\system\\etc\\location 定位相關
\\system\\etc\\mountd.conf 存儲掛載配置文件
\\system\\etc\\NOTICE.html 提示網頁
\\system\\etc\\permissions.xml 許可權許可
\\system\\etc\\pvplayer.conf
\\system\\etc\\security
\\system\\etc\\wifi WLAN相關組件
\\system\\etc\\dhcpcd\\dhcpcd-hooks
\\system\\etc\\dhcpcd\\dhcpcd-run-hooks
\\system\\etc\\dhcpcd\\dhcpcd.conf
\\system\\etc\\dhcpcd\\dhcpcd-hooks\\01-test
\\system\\etc\\dhcpcd\\dhcpcd-hooks\\20-dns.conf
\\system\\etc\\dhcpcd\\dhcpcd-hooks\\95-configured
\\system\\etc\\firmware\\brf6300.bin
\\system\\etc\\location\\gps
\\system\\etc\\location\\gps\\location 定位相關
\\system\\etc\\location\\gps\\nmea GPS數據解析
\\system\\etc\\location\\gps\\properties
\\system\\etc\\security\\cacerts.bks
\\system\\etc\\security\\otacerts.zip OTA下載驗證
\\system\\etc\\wifi\\Fw1251r1c.bin
\\system\\etc\\wifi\\tiwlan.ini
\\system\\etc\\wifi\\wpa_supplicant.conf WPA驗證組件

\\system\\fonts
字體文件夾，除了標准字體和粗體、斜體外可以看到文件體積最大的可能是中文字型檔，或一些unicode字型檔，從T-Mobile G1上可以清楚的看到顯示簡體中文正常，其中DroidSansFallback.ttf文件大小
\\system\\fonts\\DroidSans-Bold.ttf
\\system\\fonts\\DroidSans.ttf
\\system\\fonts\\DroidSansFallback.ttf
\\system\\fonts\\DroidSansMono.ttf
\\system\\fonts\\DroidSerif-Bold.ttf
\\system\\fonts\\DroidSerif-BoldItalic.ttf
\\system\\fonts\\DroidSerif-Italic.ttf
\\system\\fonts\\DroidSerif-Regular.ttf

\\system\\framework
framework主要是一些核心的文件，從後綴名為jar可以看出是是系統平台框架。
\\system\\framework\\am.jar
\\system\\framework\\am.odex
\\system\\framework\\android.awt.jar AWT庫
\\system\\framework\\android.awt.odex
\\system\\framework\\android.policy.jar
\\system\\framework\\android.policy.odex
\\system\\framework\\android.test.runner.jar
\\system\\framework\\android.test.runner.odex
\\system\\framework\\com.google.android.gtalkservice.jar GTalk服務
\\system\\framework\\com.google.android.gtalkservice.odex
\\system\\framework\\com.google.android.maps.jar 電子地圖庫
\\system\\framework\\com.google.android.maps.odex
\\system\\framework\\core.jar 核心庫，啟動桌面時首先載入這個
\\system\\framework\\core.odex
\\system\\framework\\ext.jar
\\system\\framework\\ext.odex
\\system\\framework\\framework-res.apk
\\system\\framework\\framework-tests.jar
\\system\\framework\\framework-tests.odex
\\system\\framework\\framework.jar
\\system\\framework\\framework.odex
\\system\\framework\\input.jar 輸入庫
\\system\\framework\\input.odex
\\system\\framework\\itr.jar
\\system\\framework\\itr.odex
\\system\\framework\\monkey.jar
\\system\\framework\\monkey.odex
\\system\\framework\\pm.jar 包管理庫
\\system\\framework\\pm.odex
\\system\\framework\\services.jar
\\system\\framework\\services.odex
\\system\\framework\\ssltest.jar
\\system\\framework\\ssltest.odex
\\system\\framework\\svc.jar 系統服務
\\system\\framework\\svc.odex

\\system\\lib
lib目錄中存放的主要是系統底層庫，如平台運行時庫。
\\system\\lib\\libaes.so
\\system\\lib\\libagl.so
\\system\\lib\\libandroid_runtime.so Android運行時庫
\\system\\lib\\libandroid_servers.so 系統服務組件
\\system\\lib\\libaudio.so 音頻處理
\\system\\lib\\libaudioeq.so EQ均衡器
\\system\\lib\\libaudioflinger.so 音頻過濾器
\\system\\lib\\libbluetooth.so 藍牙組件
\\system\\lib\\libc.so
\\system\\lib\\libcamera.so 超相機組件
\\system\\lib\\libcameraservice.so
\\system\\lib\\libcorecg.so
\\system\\lib\\libcrypto.so 加密組件
\\system\\lib\\libctest.so
\\system\\lib\\libcutils.so
\\system\\lib\\libdbus.so
\\system\\lib\\libdl.so
\\system\\lib\\libdrm1.so DRM解析庫
\\system\\lib\\libdrm1_jni.so
\\system\\lib\\libdvm.so
\\system\\lib\\libexif.so
\\system\\lib\\libexpat.so
\\system\\lib\\libFFTEm.so
\\system\\lib\\libGLES_CM.so
\\system\\lib\\libgps.so
\\system\\lib\\libhardware.so
\\system\\lib\\libhgl.so
\\system\\lib\\libhtc_ril.so
\\system\\lib\\libicudata.so
\\system\\lib\\libicui18n.so
\\system\\lib\\libicuuc.so
\\system\\lib\\liblog.so
\\system\\lib\\libm.so
\\system\\lib\\libmedia.so
\\system\\lib\\libmediaplayerservice.so
\\system\\lib\\libmedia_jni.so
\\system\\lib\\libnativehelper.so
\\system\\lib\\libnetutils.so
\\system\\lib\\libOmxCore.so
\\system\\lib\\libOmxH264Dec.so
\\system\\lib\\libpixelflinger.so
\\system\\lib\\libpvasf.so
\\system\\lib\\libpvasfreg.so
\\system\\lib\\libpvauthor.so
\\system\\lib\\libpvcommon.so
\\system\\lib\\libpvdownload.so
\\system\\lib\\libpvdownloadreg.so
\\system\\lib\\libpvmp4.so
\\system\\lib\\libpvmp4reg.so
\\system\\lib\\libpvnet_support.so
\\system\\lib\\libpvplayer.so
\\system\\lib\\libpvrtsp.so
\\system\\lib\\libpvrtspreg.so
\\system\\lib\\libqcamera.so
\\system\\lib\\libreference-ril.so
\\system\\lib\\libril.so
\\system\\lib\\librpc.so
\\system\\lib\\libsgl.so
\\system\\lib\\libsonivox.so
\\system\\lib\\libsoundpool.so
\\system\\lib\\libsqlite.so
\\system\\lib\\libssl.so
\\system\\lib\\libstdc++.so
\\system\\lib\\libsurfaceflinger.so
\\system\\lib\\libsystem_server.so
\\system\\lib\\libthread_db.so
\\system\\lib\\libUAPI_jni.so
\\system\\lib\\libui.so
\\system\\lib\\libutils.so
\\system\\lib\\libvorbisidec.so
\\system\\lib\\libwbxml.so
\\system\\lib\\libwbxml_jni.so
\\system\\lib\\libwebcore.so
\\system\\lib\\libwpa_client.so
\\system\\lib\\libxml2wbxml.so
\\system\\lib\\libz.so
\\system\\lib\\moles
\\system\\lib\\moles\\wlan.ko

② android中怎麼解析復雜的xml文件

本文主要講解Android開發中如何對XML文件的解析，由於XML文件具有與平台無關，廣泛應用於數據通信中，因此解析XML文件就顯得很有意義。Android對XML文件解析的方法主要有3種。 通常有三種方式:DOM、SAX和PULL，下面就分別針對這三種方式來進行討論。

文件內容如下所示：
那麼就是要對此XML文件做解析。下面我們就分別用DOM,SAX和PULL三種方式，分別對此XML文件做解析。

DOM方式

DOM方式解析xml是先把xml文檔都讀到內存中，然後再用DOM API來訪問樹形結構，並獲取數據。由DOM解析的方式可以知道，如果XML文件很大的時候，處理效率就會變得比較低，這也是DOM方式的一個缺點。
現在我們來解析上文中提到的有關天氣預報信息相關的xml文件。什麼是解析呢？說的通俗一點，就是將這個帶標簽的XML文件識別出來，並抽取一些相關的，對我們有用的信息來給我們使用。那在這個文件里，時間，天氣，溫度，以及圖標對我們來說是需要得到的。我們要對其做解析。
解析的具體思路是：
1. 將XML文件載入進來。
2. 獲取文檔的根節點
3. 獲取文檔根節點中所有子節點的列表
4. 獲取子節點列表中需要讀取的節點信息
根據這4個步驟，我們進行開發：
首先就是如何載入XML文件，假設此文件來源於網路。

SAX方式

SAX是Simple API for XML的縮寫。是一個包也可以看成是一些介面。
相比於DOM而言SAX是一種速度更快，更有效，佔用內存更少的解析XML文件的方法。它是逐行掃描，可以做到邊掃描邊解析，因此SAX可以在解析文檔的任意時刻停止解析。非常適用於Android等移動設備。
SAX是基於事件驅動的。所謂事件驅動就是說，它不用解析完整個文檔，在按內容順序解析文檔過程中，SAX會判斷當前讀到的字元是否符合XML文件語法中的某部分。如果符合某部分，則會觸發事件。所謂觸發事件，就是調用一些回調方法。當然android的事件機制是基於回調方法的，在用SAX解析xml文檔時候，在讀取到文檔開始和結束標簽時候就會回調一個事件，在讀取到其他節點與內容時候也會回調一個事件。在SAX介面中，事件源是org.xml.sax包中的XMLReader，它通過parser()方法來解析XML文檔，並產生事件。事件處理器是org.xml.sax包中ContentHander、DTDHander、ErrorHandler，以及EntityResolver這4個介面。
這四個介面的詳細說明如下：

事件處理器名稱

事件處理器處理的事件

XMLReader注冊方法

ContentHander

XML文檔的開始與結束，
XML文檔標簽的開始與結束，接收字元數據，跳過實體，接收元素內容中可忽略的空白等。

setContentHandler(ContentHandler h)

DTDHander

處理DTD解析時產生的相應事件

setDTDHandler(DTDHandler h)

ErrorHandler

處理XML文檔時產生的錯誤

setErrorHandler(ErrorHandler h)

EntityResolver

處理外部實體

setEntityResolver(EntityResolver e)

我們用來做內容解析的回調方法一般都定義在ContentHandler介面中。
ContentHandler介面常用的方法：
startDocument()
當遇到文檔的開頭的時候，調用這個方法，可以在其中做一些預處理的工作。
endDocument()
當文檔結束的時候，調用這個方法，可以在其中做一些善後的工作。
startElement(String namespaceURI, String localName,String qName, Attributes atts)
當讀到開始標簽的時候，會調用這個方法。namespaceURI就是命名空間，localName是不帶命名空間前綴的標簽名，qName是帶命名空間前綴的標簽名。通過atts可以得到所有的屬性名和相應的值。
endElement(String uri, String localName, String name)
在遇到結束標簽的時候，調用這個方法。
characters(char[] ch, int start, int length)
這個方法用來處理在XML文件中讀到的內容。例如：<high data="30"/>主要目的是獲取high標簽中的值。
第一個參數用於存放文件的內容，後面兩個參數是讀到的字元串在這個數組中的起始位置和長度，使用new String(ch,start,length)就可以獲取內容。
注意：
SAX的一個重要特點就是它的流式處理，當遇到一個標簽的時候，它並不會紀錄下之前所碰到的標簽，即在startElement()方法中，所有能夠知道的信息，就是標簽的名字和屬性，至於標簽的嵌套結構，上層標簽的名字，是否有子元屬等等其它與結構相關的信息，都是不知道的，都需要你的程序來完成。這使得SAX在編程處理上沒有DOM方便。
現在我們截取一段XML文件來做解析，其調用方法是這樣的：
<?xml version="1.0"?> ----------> startDocument()
<weather> ----------> startElement
<forecast_information> ----------> startElement
<city> ----------> startElement
beijing ----------> characters
</city> ----------> endElement
</forecast_information > ----------> endElement
</weather > ----------> endElement
文檔結束 ----------> endDocument()
SAX的解析步驟：
首先需要注意的是：
SAX還為其制定了一個Helper類：DefaultHandler它實現了ContentHandler這個介面，但是其所有的方法體都為空，在實現的時候，你只需要繼承這個類，然後重載相應的方法即可。
使用SAX解析XML文件一般有以下五個步驟：
1、創建一個SAXParserFactory對象；
2、調用SAXParserFactory中的newSAXParser方法創建一個SAXParser對象；
3、然後在調用SAXParser中的getXMLReader方法獲取一個XMLReader對象；
4、實例化一個DefaultHandler對象
5、連接事件源對象XMLReader到事件處理類DefaultHandler中
6、調用XMLReader的parse方法從輸入源中獲取到的xml數據
7、通過DefaultHandler返回我們需要的數據集合。
我們仍然來解析上述那個天氣預報的XML文件。
編寫代碼如下：

[java] view plain
mySAX.setOnClickListener(new Button.OnClickListener(){
@Override
public void onClick(View v) {
try{
String url = "http://www.google.com/ig/api?&weather=beijing";
DefaultHttpClient client = new DefaultHttpClient();
HttpUriRequest req = new HttpGet(url);
HttpResponse resp = client.execute(req);
HttpEntity ent = resp.getEntity();
InputStream stream = ent.getContent(); //將文件導入流，因此用InputStream

SAXParserFactory saxFactory = SAXParserFactory.newInstance(); //獲取一個對象
SAXParser saxParser = saxFactory.newSAXParser();//利用獲取到的對象創建一個解析器
XMLContentHandler handler = new XMLContentHandler();//設置defaultHandler
saxParser.parse(stream, handler);//進行解析
stream.close();//關閉流
/*XMLReader xmlReader = saxFactory.newSAXParser().getXMLReader(); //獲取一個XMLReader
xmlReader.setContentHandler(handler);
xmlReader.parse(new InputSource(stream));
stream.close();*/
}catch(Exception e){
e.printStackTrace();
}
}
});
}
public class XMLContentHandler extends DefaultHandler {
private static final String TAG = "XMLContentHandler";

@Override
public void characters(char[] ch, int start, int length)
throws SAXException {
Log.i(TAG, "解析內容："+new String(ch,start,length));
}
@Override
public void endDocument() throws SAXException {
super.endDocument();
Log.i(TAG, "文檔解析完畢。");
}
@Override
public void endElement(String uri, String localName, String qName)
throws SAXException {
Log.i(TAG, localName+"解析完畢");
}
@Override
public void startDocument() throws SAXException {
Log.i(TAG, "開始解析... ...");
}
@Override
public void startElement(String uri, String localName, String qName,
Attributes attributes) throws SAXException {
Log.i(TAG, "解析元素："+localName);

if(localName.equals("high")){
Log.i(TAG, "解析元素："+localName);
i++;
if(i==2){
highestTmp.setText(String.valueOf((Integer.parseInt(attributes.getValue(0))-32)*5/9));
}
}
}
}

上面的那段注釋：

[java] view plain
/*XMLReader xmlReader =saxFactory.newSAXParser().getXMLReader(); //獲取一個XMLReader
xmlReader.setContentHandler(handler);
xmlReader.parse(newInputSource(stream));
stream.close();*/

是用XMLReader來做解析的另外一種方法。效果是一樣的。這里可以傳流，也可以傳一個字元串，如下所示：是傳字元串。
[java] view plain
xmlReader.parse(new InputSource(new StringReader(xmlStr)));
PULL方式
除了可以使用 SAX和DOM解析XML文件，也可以使用Android內置的Pull解析器解析XML文件。 Pull解析器的運行方式與 SAX 解析器相似。它也是事件觸發的。Pull解析方式讓應用程序完全控制文檔該怎麼樣被解析。比如開始和結束元素事件，使用parser.next()可以進入下一個元素並觸發相應事件。通過Parser.getEventType()方法來取得事件的代碼值，解析是在開始時就完成了大部分處理。事件將作為數值代碼被發送，因此可以使用一個switch對感興趣的事件進行處理。
Pull解析是一個遍歷文檔的過程，每次調用next()，nextTag(), nextToken()和nextText()都會向前推進文檔，並使Parser停留在某些事件上面，但是不能倒退。然後把文檔設置給Parser。
Android中對Pull方法提供了支持的API，主要是
org.xmlpull.v1.XmlPullParser;
org.xmlpull.v1.XmlPullParserFactory;
二個類，其中主要使用的是XmlPullParser，XmlPullParserFactory是一個工廠，用於構建XmlPullParser對象。
應用程序通過調用XmlPullParser.next()等方法來產生Event，然後再處理Event。
我們仍然拿上述天氣預報的XML文件的一部分來做例子。
例如：需要解析的XML文件是：

[java] view plain
<forecast_conditions>
<day_of_week data="周三"/>
<low data="22"/>
<high data="29"/>
<icon data="/ig/images/weather/chance_of_rain.gif"/>
<condition data="可能有雨"/>
</forecast_conditions>

這部分XML文件中day_of_week,low,high等是TAG，data是ATTRIBUTEA。當然，如果有<></>夾在開始和結束符號之間的部分，則為TXET。
要想解析文檔先要構建一個XmlPullParser對象。

[java] view plain
final XmlPullParserFactory factory = XmlPullParserFactory.newInstance();
factory.setNamespaceAware(true);
final XmlPullParser parser = factory.newPullParser();
parser.setInput(new StringReader("xmlStr");

這里的xmlStr就是上邊的XML文件。
此時，文檔剛被初始化，所以它應該位於文檔的開始，事件為START_DOCUMENT，可以通過XmlPullParser.getEventType()來獲取。然後調用next()會產生
START_TAG，這個事件告訴應用程序一個標簽已經開始了，調用getName()會返回" day_of_week ";若有TEXT，則再next()會產生TEXT事件，調用getText()會返回TEXT，由於此處沒有，所以再next()，會產生END_TAG，這個告訴你一個標簽已經處理完了，再next()直到最後處理完TAG，會產生END_DOCUMENT，它告訴你整個文檔已經處理完成了。除了next()外，nextToken()也可以使用，只不過它會返回更加詳細的事件，比如COMMENT, CDSECT, DOCDECL, ENTITY等等非常詳細的信息。如果程序得到比較底層的信息，可以用nextToken()來驅動並處理詳細的事件。需要注意一點的是TEXT事件是有可能返回空白的White Spaces比如換行符或空格等。
nextTag()--會忽略White Spaces，如果可以確定下一個是START_TAG或END_TAG，就可以調用nextTag()直接跳過去。通常它有二個用處：當START_TAG時，如果能確定這個TAG含有子TAG，那麼就可以調用nextTag()產生子標簽的START_TAG事件；當END_TAG時，如果確定不是文檔結尾，就可以調用nextTag()產生下一個標簽的START_TAG。在這二種情況下如果用next()會有TEXT事件，但返回的是換行符或空白符。
nextText()--只能在START_TAG時調用。當下一個元素是TEXT時，TEXT的內容會返回；當下一個元素是END_TAG時，也就是說這個標簽的內容為空，那麼空字串返回；這個方法返回後，Parser會停在END_TAG上。

小結一下，如果在一個XML文檔中我們只需要前面一部分數據，但是使用SAX方式或DOM方式會對整個文檔進行解析，盡管XML文檔中後面的大部分數據我們其實都不需要解析，因此這樣實際上就浪費了處理資源。使用PULL方式正合適。
當點擊三種方式的任何一個按鈕時，均能夠得到相同的結果

③ Android之dropbox 分析

簡介

adb查詢

app介面

dropbox啟動

dropbox日誌路徑：/data/system/dropbox

記錄的系統錯誤
1.系統正常啟動後的自檢工作
1)SYSTEM_BOOT
開機一次，記錄一次

2)SYSTEM_RESTART
如果system_server在設備運行過程中異常，則會有記錄

3)SYSTEM_LAST_KMSG
kernel異常。
pstore是persistent storage的縮寫，內核發生異常通過此把異常日誌記錄下來，方便定位問題。
ramoops指的是採用ram保存oops信息(kernel 異常信息)的一個功能，利用pstore技術實現。

4)SYSTEM_TOMBSTONE
TOMBSTONE 是 Android 用來記錄 native 進程崩潰的 core mp 日誌, 系統服務在啟動完成後會增加一個 Observer 來偵測 tombstone 日誌文件的變化, 每當生成新的 tombstone 文件, 就會增加一條 SYSTEM_TOMBSTONE 記錄到 DropBoxManager 中.

5)SYSTEM_RECOVERY_LOG/SYSTEM_RECOVERY_KMSG
SYSTEM_RECOVERY_KMSG：recovery kerenl日誌
SYSTEM_RECOVERY_LOG：recovery 升級或恢復出廠設置等等日誌

6)SYSTEM_FSCK
文件系統完整性校驗日誌

7)SYSTEM_AUDIT
kernel 異常信息的查漏補缺日誌

2.java/native crash。-- crash/native_crash
java/native層異常的區分在於eventType:crash/native_crash

3.anr 異常。-- anr
這里涉及廣播、Service、Provider等組件的anr以及觸摸按鍵事件的anr

4.wtf(What a Terrible Failure)。--- wtf
android.util.Log.wtf(String, String)，應用可調用布局異常點

5.strict mode。---**_strictmode
嚴格模式，主要為性能監測使用
StrictMode (嚴格模式), 顧名思義, 就是在比正常模式檢測得更嚴格, 通常用來監測不應當在主線程執行的網路, 文件等操作. 任何 StrictMode 違例都會被 ActivityManagerService 在 DropBoxManager 中記錄為一次 strict_mode 違例.

6.lowmem。低內存報告

7.watchdog
如果 WatchDog 監測到系統進程(system_server)出現問題, 會增加一條 watchdog 記錄到 DropBoxManager 中, 並終止系統進程的執行.

8.其他
1)netstats_error/netstats_mp
NetworkStatsService 負責收集並持久化存儲網路狀態的統計數據, 當遇到明顯的網路狀態錯誤時, 它會增加一條 netstats_error 記錄到 DropBoxManager.

2)BATTERY_DISCHARGE_INFO
BatteryService 負責檢測充電狀態, 並更新手機電池信息. 當遇到明顯的 discharge 事件, 它會增加一條 BATTERY_DISCHARGE_INFO 記錄到 DropBoxManager.

3)storage_benchmark/storage_trim
StorageManagerService 負責存儲設備管理，例如sdcard或usb mass storage
fstrim提升磁碟性能，緩解Android卡頓

4)network_watchlist_report
NetworkWatchlistService

5)incident
frameworks/base/cmds/incidentd

6)keymaster
system/security/keystore

參考學習

④ Android 開發之系統 packages 文件解析

Android 系統中保存 app 信息的兩個配置文件， packages.xml 和 packages.list ，此兩個文件的初始路徑為： /data/system/packages.xml 和 /data/system/packages.list 。系統中所有安裝的app的基本信息在這里都能體現出來。這里以Android 6.0為基礎來分析, 不同的Android版本, 可能內容會稍有出入, 但是基本上是相同的。

packages.list 文件位於 /data/system 目錄下，該文件記錄了系統中所有應用程序的基本信息，包含如下基本信息：

該文件的內容和格式相對簡單，內容格式如下：

打開 packages.xml 文件，會發現這個文件非常的長，所以先列出這個文件的框架，以便對它有個整體的認知。

2.1 permissions

permissions塊的類容如下:

它裡面定義了系統中所有的申明的許可權信息, 每個 item 塊代表一個許可權。name 表示許可權的名字, package 表示申明許可權的package, protection表示許可權的級別, 如normal, dangerous之類的

2.2 keyset-settings

先看看keyset-settings塊的內容:

另:

2.3 package

package 塊內容如下:

package 塊里包含了每個 app 的詳細信息, 具體說明如下:

2.4 shared-user

以 android.uid.system 為例。

2.5 updated-package： 代表更新後的包信息。舉個栗子：

⑤ Android-trace分析工具

1.TraceView

官方說明文檔:

https://developer.android.google.cn/studio/profile/cpu-profiler

android CPU profiler

CPU profiler可以實時檢查應用的CPU使用率和線程activity,並記錄函數跟蹤，以便於您可以優化和調試您的應用程序.

Flame Chart如果出現問題 顏色也會加深

2.systrace

簡介:

systrace是Android4.1版本之後推出的，對系統Performance分析的工具。systrace的功能包括跟蹤系統I/O操作,內核工作隊列,CPU負載以及Android各個子系統的運行狀況等。

主要由三部分構成:

1.內核部分

systrace採用了linux Kernel的ftrace功能，所以如果要使用systrace的話，必須開啟Kernel和ftrace相關的模塊.

2.數據採集部分

Android中定義了一個trace類,應用程序可以使用該類把統計信息輸出給trace,同時，android有一個atrace程序，它可以從ftrace中讀取統計信息然後交給數據分析工具來處理.

3.數據分析工具

Android提供一個systrace.py用來配置數據採集的方法(如採集數據的標簽，輸出文件名等)和收集ftrace統計數據並生成一個結果網頁文件供用戶查看。

簡單的說,當機器以60幀/秒顯示，用戶會感知機器流暢。如果出現顯示時丟幀的情況，就需要知道系統在做什麼?Systrace是用來收集系統和應用的數據信息和一些中間生成數據的細節，在Android4.1和4.2系統之後出現。Systrace在分析一些顯示問題上特別有用，如應用畫圖慢，顯示動作或者動畫時變形。

抓取systrace

進入本地Android/Sdk/platform-tools/systrace目錄下,執行python systrace.py view --time = 10

python腳本的option

⑥ android 怎麼解析tra文件

對於從事Android開發的人來說，遇到ANR(Application Not Responding)是比較常見的問題。一般情況下，如果有ANR發生，系統都會在/data/anr/目錄下生成trace文件，通過分析trace文件，可以定位產生ANR的原因。產生ANR的原因有很多，比如CPU使用過高、事件沒有得到及時的響應、死鎖等，下面將通過一次因為死鎖導致的ANR問題，來說明如何通過trace文件分析ANR問題。
對應的部分trace文件內容如下：
"PowerManagerService" prio=5 tid=24 MONITOR
| group="main" sCount=1 dsCount=0 obj=0x41dd0eb0 self=0x5241b218
| sysTid=567 nice=0 sched=0/0 cgrp=apps handle=1380038664
| state=S schedstat=( 6682116007 11324451214 33313 ) utm=450 stm=219 core=1
at com.android.server.am.ActivityManagerService.broadcastIntent(ActivityManagerService.java:~13045)
- waiting to lock <0x41a874a0> (a com.android.server.am.ActivityManagerService) held by tid=12 (android.server.ServerThread)
at android.app.ContextImpl.sendBroadcast(ContextImpl.java:1144)
at com.android.server.power.PowerManagerService$DisplayBlankerImpl.unblankAllDisplays(PowerManagerService.java:3442)
at com.android.server.power.DisplayPowerState$PhotonicMolator$1.run(DisplayPowerState.java:456)
at android.os.Handler.handleCallback(Handler.java:800)
at android.os.Handler.dispatchMessage(Handler.java:100)
at android.os.Looper.loop(Looper.java:194)
at android.os.HandlerThread.run(HandlerThread.java:60)
"Binder_B" prio=5 tid=85 MONITOR
| group="main" sCount=1 dsCount=0 obj=0x42744770 self=0x58329e88
| sysTid=3700 nice=-20 sched=0/0 cgrp=apps handle=1471424616
| state=S schedstat=( 1663727513 2044643318 6806 ) utm=132 stm=34 core=1
at com.android.server.power.PowerManagerService$DisplayBlankerImpl.toString(PowerManagerService.java:~3449)
- waiting to lock <0x41a7e420> (a com.android.server.power.PowerManagerService$DisplayBlankerImpl) held by tid=24 (PowerManagerService)
at java.lang.StringBuilder.append(StringBuilder.java:202)
at com.android.server.power.PowerManagerService.mp(PowerManagerService.java:3052)
at android.os.Binder.mp(Binder.java:264)
at android.os.Binder.onTransact(Binder.java:236)
at android.os.IPowerManager$Stub.onTransact(IPowerManager.java:373)
at android.os.Binder.execTransact(Binder.java:351)
at dalvik.system.NativeStart.run(Native Method)
"android.server.ServerThread" prio=5 tid=12 MONITOR
| group="main" sCount=1 dsCount=0 obj=0x41a76178 self=0x507837a8
| sysTid=545 nice=-2 sched=0/0 cgrp=apps handle=1349936616
| state=S schedstat=( 15368096286 21707846934 69485 ) utm=1226 stm=310 core=0
at com.android.server.power.PowerManagerService.isScreenOnInternal(PowerManagerService.java:~2529)
- waiting to lock <0x41a7e2e8> (a java.lang.Object) held by tid=85 (Binder_B)
at com.android.server.power.PowerManagerService.isScreenOn(PowerManagerService.java:2522)
at com.android.server.wm.WindowManagerService.(WindowManagerService.java:7749)
at com.android.server.wm.WindowManagerService.setEventDispatching(WindowManagerService.java:7628)
at com.android.server.am.ActivityManagerService.updateEventDispatchingLocked(ActivityManagerService.java:8083)
at com.android.server.am.ActivityManagerService.wakingUp(ActivityManagerService.java:8077)
at com.android.server.power.Notifier.sendWakeUpBroadcast(Notifier.java:474)
at com.android.server.power.Notifier.sendNextBroadcast(Notifier.java:455)
at com.android.server.power.Notifier.access$700(Notifier.java:62)
at com.android.server.power.Notifier$NotifierHandler.handleMessage(Notifier.java:600)
at android.os.Handler.dispatchMessage(Handler.java:107)
at android.os.Looper.loop(Looper.java:194)
at com.android.server.ServerThread.run(SystemServer.java:1328)
從trace文件看，是因為TID為24的線程等待一個TID為12的線程持有的鎖，TID為12的線程等待一個TID為85的線程持有的鎖，而TID為85的線程確等待一個TID為24的線程持有的鎖，導致了循環等待的現象，對應的trace文件的語句如下：
TID 24：- waiting to lock <0x41a874a0> (a com.android.server.am.ActivityManagerService) held by tid=12 (android.server.ServerThread)
TID 12： - waiting to lock <0x41a7e2e8> (a java.lang.Object) held by tid=85 (Binder_B)
TID 85：- waiting to lock <0x41a7e420> (a com.android.server.power.PowerManagerService$DisplayBlankerImpl) held by tid=24 (PowerManagerService)
既然是死鎖，那麼先看各線程都有那些鎖。
先看TID=24的線程的棧頂，ActivityManagerService的broadcastIntent函數代碼如下:
public final int broadcastIntent(IApplicationThread caller,
Intent intent, String resolvedType, IIntentReceiver resultTo,
int resultCode, String resultData, Bundle map,
String requiredPermission, boolean serialized, boolean sticky, int userId) {
enforceNotIsolatedCaller("broadcastIntent");
synchronized(this) {
intent = verifyBroadcastLocked(intent);
final ProcessRecord callerApp = getRecordForAppLocked(caller);
final int callingPid = Binder.getCallingPid();
final int callingUid = Binder.getCallingUid();
final long origId = Binder.clearCallingIdentity();
int res = broadcastIntentLocked(callerApp,
callerApp != null ? callerApp.info.packageName : null,
intent, resolvedType, resultTo,
resultCode, resultData, map, requiredPermission, serialized, sticky,
callingPid, callingUid, userId);
Binder.restoreCallingIdentity(origId);
return res;
}
可以看到TID=24需要ActivityManagerService這個鎖。再看TID=12線程的棧頂，PowerManagerService的isScreenOnInternal函數代碼如下：

private boolean isScreenOnInternal() {
synchronized (mLock) {
return !mSystemReady
|| mDisplayPowerRequest.screenState != DisplayPowerRequest.SCREEN_STATE_OFF;
}
}
可以看到需要PowerManagerService的mlock這個鎖。最後看TID=85線程的棧頂，同樣在PowerManagerService裡面，內部類DisplayBlankerImpl的toString函數：

public String toString() {
synchronized (this) {
return "blanked=" + mBlanked;
}
}
這是在內部類DisplayBlankerImpl裡面實現的，所以需要DisplayBlankerImpl這個鎖。
對應的表格如下：
表一 各線程等待的鎖情況
從表一來看，沒有出現死鎖現象，似乎並不是我們所想的那樣。難道不是死鎖？開始有點小懷疑自己了，難道別的原因導致的。也許只看調用堆棧的頂端可能不行，棧頂只能看出各線程需要的鎖，不能僅看自己要什麼吧！一味索取可不好！人不是這樣做的！看一下整個的堆棧調用流程，看看自己擁有了那些鎖。
跟蹤TID=24線程的堆棧，在PowerManagerService內部類DisplayBlankerImpl的unblankAllDisplays函數中持有鎖：
public void unblankAllDisplays() {
synchronized (this) {
nativeSetAutoSuspend(false);
nativeSetInteractive(true);
mDisplayManagerService.();
mBlanked = false;
///M: add for tvout and hdmi
mTvOut.tvoutPowerEnable(true);
mHDMI.hdmiPowerEnable(true);
///@}
if (DEBUG) {
Slog.d(TAG_P, "unblankAllDisplays out ...");
}
if (mBootCompleted) {
Intent intent = new Intent(ACTION_LOCK_SCREEN_SHOW);
mContext.sendBroadcast(intent);
}
}
}
最後發送廣播的代碼，是我們自己添加的。根據unblankAllDisplays函數和broadcastIntent函數，可以看到TID=24的線程此時持有了DisplayBlankerImpl鎖(unblankAllDisplays)，等待ActivityManagerService鎖(broadcastIntent)釋放。
同樣，跟蹤TID=12線程的堆棧，在ActivityManagerService的wake_up函數中持有鎖：
public void wakingUp() {
if (checkCallingPermission(android.Manifest.permission.DEVICE_POWER)
!= PackageManager.PERMISSION_GRANTED) {
throw new SecurityException("Requires permission "
+ android.Manifest.permission.DEVICE_POWER);
}
synchronized(this) {
Slog.i(TAG, "wakingUp");
mWentToSleep = false;
updateEventDispatchingLocked();
comeOutOfSleepIfNeededLocked();
}
}
根據wakingUp函數和isScreenOnInternal函數，可以看到TID=12的線程持有ActivityManagerService鎖(wakingUp)，等待PowerManagerService.mLock鎖(isScreenOnInternal)。到這，似乎看到了希望，迷霧要撥開了，有點小自信是死鎖導致的，但還不能最終下結論。
一鼓作氣，跟蹤TID=85線程的堆棧，在PowerManagerService的mp有持有鎖的操作：
protected void mp(FileDescriptor fd, PrintWriter pw, String[] args) {
....
synchronized (mLock) {
...
}
根據toString函數和mp函數，可以看到TID=85線程此時持有PowerManagerService.mLock鎖(mp)，需要DisplayBlankerImpl(toString)。

⑦ 安卓啟動流程(一) - rc文件初步解析

init進程的一個核心部分，是通過解析rc文件，執行Action和啟動Service。在分析init進程前，有必要先學習rc文件的配置和解析的原理。

/system/core/init/init.cpp

/system/core/init/init.cpp

通過 CreateParser , 創建了 Parser 解析器對象，其解析規則如下：

然後開始執行解析過程

最後調用 Parser 解析器的 ParseConfig 函數執行解析。

下一篇： 安卓啟動流程(二) - Parser解析器

⑧ Android Studio 導入LeakCanary文件進行分析

Android Studio打開profile崩潰解決方案
Android Studio 使用Profile官方指南
LeakCanary檢測內存泄露案例分析
前面我們說道使用LeakCanary進行了初步的內存分析。接下來我們說一下，如何通過Android Studio自帶的Proflie進行深度分析
1.首先，需要把手機裡面的leak收集到的hprof文件進行導入。
導入方式如下：
路徑是：
Physical#手機#Actions#文件夾#storage#sdcard0#Download#leakcanary-xxx(包名)#選中需要導出的文件#Save as#對應保存的路徑

2.從電腦導入對應需要分析的hprof文件
路徑是：
Profiler#SESSIONS#+#load from file

3.如何分析，如圖

主要看Depth深度，如果大於0。那麼我們就需要謹慎分析處理可能存在的引用關系

⑨ 如何用android解析docx文檔

android上查閱word類型文檔的方式主要有幾種，下載諸如wps，office等應用，用戶可以直接打開需要查看的word文檔，對於應用開發者來說，如何在自己的應用中集成word文檔查閱功能，使自己的app不受限於第三方應用有沒有安裝，有時候還是需要考慮的。
集成app閱讀word功能也可以通過幾種方式實現，例如購買專門的sdk包，像Aspose等（money啊）或者伺服器端處理成圖片或者html，然後android端去請求訪問等方式。對於大部分個人開發者而言，這兩種方式就顯得比較重量級了。
下面介紹兩種專門解析docx文件的方式：docx4j 以及poi
Docx4j
github地址：https://github.com/plutext/AndroidDocxToHtml
這個是官網demo，基本可以直接使用，解析出來的格式比較全，樣式也比較接近原文檔，就是解析速度令人不敢恭維，手機上測試的話，一般一份兒docx文檔都需要30s以上甚至更多，有時候測試文檔明明就只有幾十k大小而已，對於比較大，比較復雜的文檔，時間就更是讓人崩潰。解析速度不是令人滿意。
解析測試中遇到的bug
1.表格丟失，內容丟失：內嵌表格（表格中還有表格的這種）的內容和樣式會有部分丟失現象
2.表格（又是我？）樣式：假如文檔中的表格在word文檔中排版時超出了該文檔的邊界線，你會發現超出邊界的內容又不見了
3.目錄亂碼：如果文檔中有目錄，目錄會被加上一些超鏈接，需要手工處理去掉
4.圖片無法解析：有一些格式的圖片無法解析，比如EMF，WMF這種類型的
5.批註無法顯示：目前沒有找到批註顯示的地方，暫且算丟失吧，後面在試試
6.。。。其它暫時還沒被發現的問題
POI
poi是apache的一個開源項目，不多說，直接上官網去下載就可以
官網地址：http://poi.apache.org/
如果你是android studio用戶：那就很簡單了
只需要引入依賴（版本號不一定哦，gradle會自己把相關依賴包下載到位）：
compile 'fr.opensagres.xdocreport:org.apache.poi.xwpf.converter.xhtml:1.0.5'

那如果你是eclipse用戶（伙計，趕緊用studio吧）
需要手工引入以下jar包，包括：
poi , poi-ooxml , ooxml-schema,org.apache.poi.xwpf.converter.xhtml,org.apache.poi.xwpf.converter.core

實現代碼如下
{
InputStream is = new FileInputStream(file);
XWPFDocument docx = new
XWPFDocument(is);
OutputStream os = new ByteArrayOutputStream();
String imgDesPath = "/sdcard/img";
File imgFile = new File("/sdcard/img");
this.baseUrl = this.getDir("image", Context.MODE_PRIVATE).toURL().toString();
if (!imgFile.exists()) {
file.mkdirs();
}

poi解析的問題
速度比docx4j要稍快一點，會有文檔內容解析不全樣式丟失的情況
流程
調用介面將docx轉化為html，然後app中通過webview載入該html即可顯示
轉化代碼如下（我就想問下，這代碼格式到底該怎麼調啊～好煩躁）：
try {
InputStream is = new FileInputStream(file);
XWPFDocument docx = new
XWPFDocument(is);
OutputStream os = new ByteArrayOutputStream();
String imgDesPath = "/sdcard/img";
File imgFile = new File("/sdcard/img");
this.baseUrl = this.getDir("image", Context.MODE_PRIVATE).toURL().toString();
if (!imgFile.exists()) {
file.mkdirs();
}
XHTMLOptions options = XHTMLOptions.create().URIResolver(new BasicURIResolver(imgDesPath));
options.setExtractor(new FileImageExtractor(imgFile));
options.setIgnoreStylesIfUnused(false);
options.setFragment(true);
XHTMLConverter.getInstance().convert(docx, os, options);
**os.write("/sdcard/xxx/html文件")**
} catch (Exception e) {
Log.d(TAG, "catch " + e.getMessage());
}

webview 裡面直接load 上面生成的html文件就可以了

⑩ Android生成APK後目錄中META-INF目錄文件解析

Android開發環境對每一個需要Release的APK都會進行簽名，在APK文件被安裝時，Android系統會對APK的簽名信息進行比對，以此來判斷程序的完整性，最終確定APK是否可以正常安裝使用，一定程度上達到安全的目的。

給一個APK文件的後綴名從.apk改為.zip或者.rar，然後利用解壓工具進行解壓，我們會在META-INF目錄下看到四個文件： MANIFEST.MF、CERT.SF、INDEX.LIST、CERT.RSA

MANIFEST.MF（摘要文件）： 程序遍歷APK包中的所有文件，對非文件夾非簽名文件的文件，逐個用SHA1生成摘要信息，再用Base64進行編碼。如果APK包的文件被修改，在APK安裝校驗時，被修改的文件與MANIFEST.MF的校驗信息不同，程序將無法正常安裝。

CERT.SF（對摘要文件的簽名文件）： 對於生成的MANIFEST.MF文件利用SHA1-RSA演算法對開發者的私鑰進行簽名。在安裝時只有公共密鑰才能對其解密。解密之後將其與未加密的摘要信息進行比對，如果相符則文件沒有被修改。

INDEX.LIST APK索引文件目錄

CERT.RSA   保存公鑰、加密演算法等信息。

在APK進行安裝時，可以通過MANIFEST.MF文件開始的環環相扣來保證APK的安全性。但這些文件或者密鑰如果被攻擊者得到或者被攻擊者通過某些技術手段攻破，則Android操作系統無法驗證其安全性。