androidhierarchy

A. 怎麼把widget加到window中

獲得System Widget ID 應用程序自身創建的View的ID的結構是：R.id.XXX 而由系統自身創建的View的ID的結構是：com.android.internal.R.id.XXX 可以通過Android的Hierarchyviewer Tools來獲得System Widget的ID 例如，ActionBar相關ID如下： actio...

B. android studio hierarchy viewer 怎麼看布局是否需要優化

工具/原料

android 基礎
91桌面
數據線
android手機
方法/步驟

在手機安裝好91桌面哈，然後將頁面滑到最左面的「快速搜索頁」

hierarchyviewer.bat是sdk自帶的工具，在tools文件夾下。雙擊即可打開

在此頁面，加粗顯示的就是當前進程，點擊load view hierarchy就可以分層查看布局

左邊的大圖，為應用圖層的樹形結構。上面有控制項名稱和id等信息。然後下面三個圓點代表渲染的速度，綠色最快，紅色最慢，其中從左到右依次表示的是測量大小，布局和繪制。再看右下角的那個數字，代表的是此節點在父節點中的索引。

整張圖的右下角，表示的該應用的當前頁面。在左邊的樹形圖中點擊某個節點，會在這里用紅框標出響應的位置。左上角的圖可以查看當前選中節點的具體布局數據，寬高什麼的。

這里可以看出「快速搜索屏」的實現是，
draglayer--孩子--->workspacelayer-----孩子0---workspace；
------孩子1---singleViewGroup;
singleViewGroup就是快速搜索屏的布局view
在網上找到一個圖，覺得很好，介紹的精確完整，貼過來，給大家看看

C. 如何建立ar模型 android

右鍵單擊Project（項目Tab頁）中的Assets文件夾

選擇「Reveal in Finder」(在Window上也有可能是「Reveal in Explorer」）

打開Assets文件夾

創建一個名叫Models新的文件夾（或者可以取別的合乎邏輯的名字）

把模型（包括所有的紋理（Texture）等等）放入到這個文件夾中

返回Unity

Unity會檢測到你對Assets文件夾所做的改動，並會使用最新的信息更新自己的顯示。現在把你的模型拖入到增強顯示場景中，放在前一個模型的上面。確保他在層次結構（Hierarchy）中被的放置在正確的ImageTarget下面。我也拷貝了上一個模型一樣的Transform屬性，所以他們的大小應該相同（只是旋轉角度不同），最終你會得到類似下面的效果。

D. 為什麼 我的android設備 在DDMS中能看到 而在hierarchyViewer中看不到呢（和root無關）

有兩種情況，一種是沒有界面，類是service之類的，所以肯定看不到，還有情況可能你查看的進程不對。

E. android插件化框架哪個好

首先由於我自己也是個新手，也是在學習各種框架然後給公司項目選定相應自動化框架，研究移動自動化測試框架也就近段時間而已，所以我只能從我自己今天為止的認知角度給各個框架抒發我自己的拙見，你看是否能從中接納一二吧（對於我自己的話還需要再花一段時間去學習各個框架才能確定哪個/些是適合我們項目的了,也許到時我會寫個正式的總結)。

根據你的要求，應該不會考慮MonkeyRunner和Robotium，但我還是想跟你說下其實Robotium還是挺不錯的，如果你沒有考慮跨進程調用其他APP的話。至於MonkeyRunner我就不大推薦了，你可以看下我對金陽光老師的一個評論的回復《MonkenRunner通過HierarchyViewer定位控制項的方法和建議》（文章最後我乾脆也貼出來了）。至於Robotium，你對比下本人博客裡面各個框架編寫的Note的測試示例就可以看出來Robotium相對其他框架會簡介很多，況且發展的比UIAutomator和Appium長久很多，所以也應該會更成熟，和Eclipse集成調試起來也很方便。比起後兩者如果有不足的話我覺得就以下幾點吧：

1. 所有的操作抽象到一個Solo類裡面，缺乏面向對象的編程思想，有時會讓人不適應。如果你熟悉C語言等面向過程的語言思想的話應該沒有問題。
2. 獲取控制項的方法比較缺乏，大概就幾種：通過Text，ID， ClassName，Index。沒有後兩者的多種多樣
3. 跨進程：因為底層使用Instrument框架，測試包和被測應用包打包在一起作為一個進程運行而線程間通過instrumentaiton進行通信，導致了逃不出這個進程設沙箱（sandbox)
4. 做不了模擬鍵盤的測試（但同時這個也是Robotium非常巨大的優點，因為不像後兩者那樣需要調用鍵盤導致輸入的各種各樣的問題），因為Robotium輸入讀出其實是直接對控制項的text屬性進行操作沒有通過鍵盤驅動的，你如果做過UI編程應該就明白我的意思了，因為記住你的測試代碼和目標應用是打包在同一個進程中的，同一個進程中想訪問另外一個線程的某個變數，運用相應的IPC（Interprocess Communication)機制當然是沒有問題的了。

然後到了你問的主題UIAutomator和Appium的對比，我個人是這樣看的：

1. UIAutomator是親爹（google）生的，所以可以保證後續的開發維護力量，除非google倒閉（這里我有點不懂的是為什麼google對Monkeyrunner的態度這么讓人摸不著頭腦，具體請看以上我說的對MonkeyRunner的評論）
2. Appium雖然不是親爹生的，但是乾爹實力雄厚把它武裝的無所不能（android，ios，firefox，browser通殺），單單以android來說，底層用得還是UIAutomator，所以只要它能及時跟上UIAutomator的更新，功能上面我不是很擔心。
3. 但是也這是Appium的這種架構：UIautomator/seledroid<->Appium Server<->Selenium/AppiumDriver<->Test Case （《Appium架構框架圖整理》http://blog.csdn.net/zhutian/article/details/39453505）,導致框架有點復雜，當問題出現的時候調試起來比較難以定位，不知道哪個模塊出錯了。但是說道調試，總比UIAutomator好，起碼Appium可以直接集成到eclipse上面進行debug，UiAutomator卻每次都要push到目標機器然後再去執行，怎麼調試呢？到現在為止我知道的只能原始的print了。
4. 向下兼容問題：Appium可以通過底層UIAutomator/Selendroid（不記得是不是這名字了）通殺；UIAutomator只能在API Level
17（包含）以上使用
5.語言支持：appium基本通殺，UIAutomator用java足矣
6.跨平台：如你所說的只是android兩者都沒有問題，如果往後需要擴展到ios，那麼建議appium
7.bug數量：UIAutomator有的問題Appium都會有，UIAutomator沒有的問題Appium也有可能有^_^（不過我還是很看好Appium的）
8. 輸入問題，都有bug，具體請查看我相應blog，特別是中文輸入，這就是為什麼我剛才特意提出Robotum的原因之一
9. WebView支持：UIAutomator據說今年年初已經開始支持，個人沒有這方面要求所以沒研究；Appium的框架用的Selenium本身就是PC上最流行的開源Web測試框架，所以必然支持了。注意這你你要有點android編程知識了，WebView指的不僅是WebView控制項還包含如用sencha+phonegap把webview封裝成一個跨平台app的情況了，具體如果不清楚請google。

其他區別我現在就沒有想到了，希望能幫助到你，從我自己的角度來看，我覺得UIAutomator繼續往前發展是必然的了，但是它不可能最終支持ios。至於Appium我同樣有很大的信心它會繼續往好的方向發展，且考慮到它的跨平台支持，基於node.js（現在非常流行哦），兼容性等，我如果是你的話我會考慮用Appium的（拋開Robotium不說，如果你又要考慮的話就需要你根據我之前說的再總結下了^_^）。

我覺得這個可以類比之前的微軟和Borland的關系，API是Windows，但是IDE是Borland的，各專所長了。可惜（或者慶幸）後來微軟發力一下把Borland打得滿地找牙一蹶不振，不過這是題外話了，略過......

對了，我有可能會對這封郵件整理下發到博客了，也希望其他網友能評點一二給你出主意。今晚本來想看下easy_monkey的知識了，給你寫這個email變成臨時性總結了。^_^

給金陽光老師評論的回復如下（關於MonkeyRunner的個人觀點）
-----------------------------------------------------------------------------------------------------------------
回復haorenmin2008：首先膜拜下，金老師大駕光臨蓬蓽生輝啊！
對於後者，確實如此，UIAutomator需要API Level17（包含）以上。
對於前者，因為還沒有MonkeyRunner的項目經驗，所以是否很強大我就不敢妄加評論了，但是在我近來的tryout過程中，鄙人有以下的一些不成熟的認知：

1. 感覺功能不是很穩定，之前嘗試一個MonkeyDevice的getProperty方法，竟然有時成功有時失敗。
2. 性能不好，特別是當我們要用到hierarchyviewer的功能的時候很明顯。
3. 只能用MonkeyImage的sameAs做截屏的對比，雖然加上hierarchyviewer後可以用它的getText，但還是很有限。
4. 控制項定位方面主要是坐標點和HierarchyViewer提供的根據ID。前這兒在UI布局稍微有調整位置的話就需要跟著變動，沒有像其他控制項類框架那樣做高層抽象除非換控制項不然都不需要怎麼變動；後者的話很多控制項是沒有id或者是有多個控制項id相同的。
5. 可調試性也不強（起碼我摸索了這幾天沒有發現一個很好的調試方法，比如IDE Ecilpse等的集成調試方法）
6. HierarchyViewer的穩定性也讓我擔憂，碰到過幾次取控制項信息的時候報exception的。
7. 資料稀缺，不僅網路，google也一樣
8. Google支持讓人覺得摸不著頭腦，sdk給出的API和官方提供的API竟然不一致，以MonkeyDevice為例子，而sdk多出來的API竟然還不能用，google出來的信息不超過10個page，還要很多都是重復的石沉大海的網友報的問題。
9. 再一個的我真心搞不懂為什麼本身java寫的庫非要搞個jython來調用，首先我不說性能損耗（這點肯定是有的，native庫當然用native語言調用效率最好嘛），我想在eclipse上對以下的"device."做自動補全是做不到的「device = MonkeyRunner.waitForConnection()\n device.",而只有直接調用個構造函數實例化的device = MonkeyDevice（xxx）才能做到，這個我不相信是我配置的問題，換了個jython標准編譯器以調用標准庫問題同樣存在。

F. Android的UI底層是用CPU繪圖的還是GPU繪圖的呢

安卓有2種繪制模型：
一．軟體繪制模型，這里由CPU主導繪圖，視圖按照以下2個步驟繪圖。

讓視圖結構(view hierarchy)失效。
繪制整個視圖結構。
當應用程序需要更新它的部分UI時，都會調用內容發生改變的View對象的invalidate()方法。無效（invalidation）消息請求會在View對象層次結構中傳遞，以便計算出需要重繪的屏幕區域（臟區）。然後，Android系統會在View層次結構中繪制所有的跟臟區相交的區域。但是，這種方法有兩個缺點：
1. 繪制了不需要重繪的視圖（與臟區域相交的區域）
2. 掩蓋了一些應用的bug（由於會重繪與臟區域相交的區域）
注意：在View對象的屬性發生變化時，如背景色或TextView對象中的文本等，Android系統會自動的調用該View對象的invalidate()方法。

二．硬體加速繪制模型，這里由GPU主導繪圖，視圖按照以下3個步驟繪圖。

讓視圖結構失效。
記錄和更新顯示列表（Display List)。
繪制顯示列表。
這種模式下，Android系統依然會使用invalidate()方法和draw()方法來請求屏幕更新和展現View對象。但Android系統並不是立即執行繪制命令，而是首先把這些View的繪制函數作為繪制指令記錄一個顯示列表中，然後再讀取顯示列表中的繪制指令調用OpenGL相關函數完成實際繪制。另一個優化是，Android系統只需要針對由invalidate()方法調用所標記的View對象的臟區進行記錄和更新顯示列表。沒有失效的View對象就簡單重用先前顯示列表記錄的繪制指令來進行簡單的重繪工作。
使用顯示列表的目的是，把視圖的各種繪制函數翻譯成繪制指令保存起來，對於沒有發生改變的視圖把原先保存的操作指令重新讀取出來重放一次就可以了，提高了視圖的顯示速度。而對於需要重繪的View，則更新顯示列表，然後再調用OpenGL完成繪制。
在這種繪制模型下，我們不能依賴一個視圖與臟區(dirty region)相交而導致它的draw()方法被自動調用，所以必須要手動調用該視圖的invalidate()方法去更新顯示列表。如果忘記這么做可能導致視圖在改變後不會發生變化。

G. Android核心模塊結構層次有哪些呢

Android作為一個移動設備的平台，其軟體層次結構包括了一個操作系統（OS），中間件（MiddleWare）和應用程序（Application）。

根據Android的軟體框圖，其Android核心模塊結構自下而上分為以下幾個層次：

第一、操作系統層（OS）

第二、各種庫（Libraries）和Android 運行環境（RunTime）

第三、應用程序框架（Application Framework）

第四、應用程序（Application）

H. android 主線程和子線程有什麼區別

本文較為深入的分析了android中UI主線程與子線程。分享給大家供大家參考。具體如下：
在一個Android 程序開始運行的時候，會單獨啟動一個Process。默認的情況下，所有這個程序中的Activity或者Service（Service和 Activity只是Android提供的Components中的兩種，除此之外還有Content Provider和Broadcast Receiver）都會跑在這個Process。
一個Android 程序默認情況下也只有一個Process，但一個Process下卻可以有許多個Thread。在這么多Thread當中，有一個Thread，我們稱之為UI Thread。UI Thread在Android程序運行的時候就被創建，是一個Process當中的主線程Main Thread，主要是負責控制UI界面的顯示、更新和控制項交互。在Android程序創建之初，一個Process呈現的是單線程模型，所有的任務都在一個線程中運行。因此，我們認為，UI Thread所執行的每一個函數，所花費的時間都應該是越短越好。而其他比較費時的工作（訪問網路，下載數據，查詢資料庫等），都應該交由子線程去執行，以免阻塞主線程。
那麼，UI Thread如何和其他Thread一起工作呢？常用方法是：誕生一個主線程的Handler物件，當做Listener去讓子線程能將訊息Push到主線程的Message Quene里，以便觸發主線程的handlerMessage（）函數，讓主線程知道子線程的狀態，並在主線程更新UI。
例如，在子線程的狀態發生變化時，我們需要更新UI。如果在子線程中直接更新UI,通常會拋出下面的異常：
11-07 13:33:04.393: ERROR/JavaBinder(1029):android.view.ViewRoot$:Only the original thread that created a view hierarchy can touch its views.
意思是，無法在子線程中更新UI。為此，我們需要通過Handler物件，通知主線程Ui Thread來更新界面。
如下，首先創建一個Handler,來監聽Message的事件：

private final int UPDATE_UI = 1;
private Handler mHandler = new MainHandler();

private class MainHandler extends Handler {
@Override
public void handleMessage(Message msg) {
switch (msg.what) {
case UPDATE_UI: {
Log.i("TTSDeamon", "UPDATE_UI");
showTextView.setText(editText.getText().toString());
ShowAnimation();
break;
}
default:
break;
}
}
}

或者：

private Handler mHandler = new Handler(){
@Override
public void handleMessage(Message msg) {
switch (msg.what) {
case UPDATE_UI: {
Log.i("TTSDeamon", "UPDATE_UI");
showTextView.setText(editText.getText().toString());
ShowAnimation();
break;
}
default:
break;
}
}
}

當子線程的狀態發生變化，則在子線程中發出Message，通知更新UI。

mHandler.sendEmptyMessageDelayed(UPDATE_UI, 0);

在我們的程序中，很多Callback方法有時候並不是運行在主線程當中的，所以如果在Callback方法中更新UI失敗，也可以採用上面的方法。

I. android開發一般都使用什麼框架

Android開發框架介紹
編輯文檔
學分 +2
開發框架方麵包含基本的應用功能開發、數據存儲、網路訪問這三大塊：
一、應用方面
一般而言一個標準的Android程序由如下4部分組成即Activity、Broadcast Intent Receiver、Service、Content Provider： 1. Activity是最頻繁、最基本的模塊，在Android中，一個Activity就是手機上一屏，相當於一個網頁一樣，所不同的是，每個Activity運行結束了，有個返回值，類似一個函數一樣。Android系統會自動記錄從首頁到其他頁面的所有跳轉記錄並且自動將以前的Activity壓入系統堆棧，用戶可以通過編程的方式刪除歷史堆棧中的Activity Instance。
Activity類中主要是跟界面資源文件關聯起來（res/layout目錄下的xml資源，也可以不含任何界面資源），內部包含控制項的顯示設計、界面交互設計、事件的響應設計以及數據處理設計、導航設計等application設計的方方面面。 2. Broadcast Intent Receiver
Intent提供了各種不同Activity進行跳轉的機制，譬如如果從A activity跳轉到B activity，使用Intent來實現如下： Intent in = new Intent(A.this, B.class); startActivity(in);
BroadcastReceiver提供了各種不同的Android應用程序進行進行進程間通訊的機制，譬如當電話呼叫來臨時，可以通過BroadcastReceiver發布廣播消息。對於用戶而言，BroadcastReceiver是不透明的，用戶無法看到這個事件，BroadcastReceiver通過NotificationManager來通知用戶這些事件發生了，它既可以在資源AndroidManifest.xml中注冊，也可以在代碼中通過Context.registerReceiver()進行注冊，只要是注冊了，當事件來臨的時候，即時程序沒有啟動，系統也在需要的時候會自動啟動此應用程序；另外各應用程序很方便地通過Context.sendBroadcast()將自己的事情廣播給其他應用程序；
3. Service,跟Windows當中的Service完全是一個概念，用戶可以通過startService(Intent service)啟動一個Service，也可通過Context.bindService來綁定一個Service.
4. Content Provider，由於Android應用程序內部的數據都是私有的，Content Provider提供了應用程序之間數據交換的機制，一個程序可以通過實現一個ContentProvider的抽象介面將自己的數據暴露出去，並且隱蔽了具體的數據存儲實現，標準的ContentProvider提供了基本的CRUD（Create,Read,Update,Delete)的介面，並且實現了許可權機制，保護了數據交互的安全性； 一個標準的Android應用程序的工程文件包含如下幾大部分： -> Java源代碼部分(包含Activity)，都在src目錄當中；
-> R.java文件，這個文件是Eclipse自動生成與維護的，開發者不需要修改，提供了Android對的資源全局索引； -> Android Library，這個是應用運行的Android庫；
-> assets目錄，這個目錄裡面主要用與放置多媒體等一些文件；
-> res目錄，放置的是資源文件,跟VC中的資源目錄基本類似，其中的drawable包含的是圖片文件，layout裡麵包含的是布局文件，values目錄裡面主要包含的是字元串(strings.xml)、顏色（colors.xml)以及數組（arrays.xml)資源；
-> AndroidManifest.xml，這個文件異常重要，是整個應用的配置文件，在這個文件中，需要聲明所有用到的Activity、Service、Receiver等。