android開發中

『壹』 Android 開發中數據更新不起作用的幾種原因

今天總結下開發過程中遇到的3種更新沒反應原因：
1.數據為空
有時候服務端返回數據有誤或者自己傳遞的數據為空,可以打個Log或者跟個斷點看看。
2.在子線程更新UI
有時候在請求介面回調、ListView或者RecyclerView的Adapter里需要進行一些UI更新,這時不起作用的原因大多是因為我們在
子線程中更新UI。
子線程更新UI的方法有好多種,最終目的都是把消息發到主線程去操作:
寫個Handler里進行UI操作,子線程 發送消息
在runOnUiThread中
Activity.runOnUiThread(new Runnable() { @Override public void run() { //do
the ui-job } });
或者 post 到主線程
myView.post(new Runnable() { @Override public void run() { //do the ui-job }
})
3.方法調用錯誤
最常見的就是修改ImageVIew圖片,應該調用
setImageResource
或者其他 setImageXXX 方法
而不是
setBackground
等 setBackgroundXXX 方法,後者只是修改背景,而不是圖片本身。

『貳』 Android 開發中，有哪些坑需要注意

1、不要排斥新技術和新工具。 Android Studio 1.0 之後的版本，基本已經穩定到可以支持正常的工作開發的程度了。單純就書寫效率而言，Android Studio 帶來的好處絕對大於它和Gradle的學習成本。JetBrains的IDE，用過都說好。還有就是適當的提升targetSdkVer… 顯示全部
1、不要排斥新技術和新工具。
Android Studio 1.0 之後的版本，基本已經穩定到可以支持正常的工作開發的程度了。單純就書寫效率而言，Android Studio 帶來的好處絕對大於它和Gradle的學習成本。JetBrains的IDE，用過都說好。
還有就是適當的提升targetSdkVersion到新版本。

2、代碼設計方面的問題，大部分都能在Android系統源碼里找到解決方案。
當你想設計一個新模塊，或者實現一個新ui組件的時候，應該採用哪些設計模式、應該以哪種形式給外界提供介面之類的問題，大部分都可以參考Android系統的源碼，找到實現方式。Google為安卓程序員提供了一座現成的寶庫。

3、理解Android和java內存管理方式，至少要理解垃圾回收和Java的引用。
就好比學OC就要先理解黃金法則一樣，而java的內存管理，其實比OC要好理解多了。
這可能會幫助你大大減少程序非同步操作產生的空指針崩潰。也會幫助你理解為什麼濫用單例模式會導致內存的臃腫。還會幫助你養成不用「+」去連接超大字元串的好習慣。

4、ContentProvider並不是只有在跨進程共享數據的才有用，把資料庫表映射到一個獨立的uri是Google鼓勵的實現方式。
從設計上講，用uri（統一資源標識符）去描述數據，肯定比sql語句要理想。
從效果上講，用CursorLoader讀取數據是讓iOS程序員都羨慕不已的事情，作為android程序員，何苦不用呢。

5、理解Activity任務棧。
非Activity的Context對象如果直接啟動Activity會報錯，這只是一個表面現象，真正起作用的其實是Activity任務棧機制。
理解Activity任務棧機制以及Activity的各種啟動方式，會幫助解決大部分頁面關系錯亂問題，以及應用互相掉起、任務欄進入應用、後台彈窗引起的各種問題。

6、對於一些奇葩的第三方ROM，調用其非主流api的時候，可以使用反射。
在適配一些第三方ROM的的時候，調用一些在開發環境中沒有，但在運行環境中有的方法時，可以使用反射。比方說，華為雙卡手機可能會提供獲取第二塊SIM卡信息的api，如果直接調用，在開發環境可能無法通過正常編譯，用反射就沒問題。這屬於不得已而用反射的一種情況。

7、SQLite的鎖，是資料庫級別的鎖，也就是說同一個資料庫的寫操作無法並發執行。
所以，在資料庫設計的時候，如果表太多，盡量將沒有關聯的表拆到多個資料庫文件中。

8、Bitmap的內存佔用問題。
這是一個困擾2.X時代android程序員的問題。
2.X時代Bitmap對象雖然存儲在堆內存中，但是用了一個byte數組存儲其像素信息。通過計數器來記錄該像素信息被引用的個數。有人認為這個byte數組在native堆中，但事實上它也在堆中。
只有在使用者調用recycle()後，Bitmap對象才會釋放像素信息，才會在失去引用後，被垃圾回收機制銷毀。再加上DVM的heap size有嚴格的閥值，所以在使用大量圖片資源的時候，及其容易發生OOM。
解決辦法一般都是，用一個哈希表存儲Bitmap對象的軟引用，作為內存緩存，並在適當時機掉用其recycle()。
3.0以上版本Bitmap對象可以通過垃圾回收機制完全銷毀，理論上不用再調用recycle()。

『叄』 android 開發中出現的問題

出現什麼問題了呀？具體說下哈。

『肆』 Android 開發中，有哪些坑需要注意

1. 為Activity聲明系統配置變更事件
系統配置變更事件是指轉屏，區域語言發生變化，屏幕尺寸發生變化等等，如果Activity沒有聲明處理這些事件，發生事件時，系統會把Activity殺掉然後重啟，並嘗試恢復狀態，Activity有機會通過onSaveInstanceState()保存一些基本數據到Bundle中，然後此Bundle會在Activity的onCreate()中傳遞過去。雖然這貌似正常，但是這會引發問題，因為很多其他的東西比如Dialog等是要依賴於具體Activity實例的。所以這種系統默認行為通常都不是我們想要的。
為了避免這些系統默認行為，就需要為Activity聲明這些配置，如下二個是每個Activity必須聲明的：
<activity android:configChanges="orientation|keyboardHidden">
幾乎所有的Activity都要聲明如上，為什麼Android不把它們變成Default的呢?
2. 盡量使用Android的API
這好像是廢話，在Android上面開發不用Android API用什麼？因為Android幾乎支持Java SE所有的API，所以有很多地方Android API與Java SE的API會有重復的地方，比如說對於文件的操作最好使用Android裡面Context封裝的API，而不要直接使用File對象：
Context.openFileOutput(String); // no File file = new File(String)
原因就是API裡面會考慮到Android平台本身的特性；再如，少用Thread，而多使用AsyncTask等。
3. 要考慮到Activity和進程被殺掉的情況
如了通常情況退出Activity外，還有Activity因其他原因被殺的情況，比如系統內存過低，系統配置變更，有異常等等，要考慮和測試這種情況，特別是Activity處理重要的數據時，做好的數據的保存。
4. 小心多語言
有些語言真的很啰嗦，中文或英文很簡短就能表達的事情到了其他語言就變的死長死長的，所以如果是wrap_content就可能把其他控制擠出可視范圍； 如果是指定長度就可能顯示不全。也要注意特殊語言比如那些從右向左讀的語言。
5. 不要用四大組件去實現介面
一是組件的對象都比較大，實現介面比較浪費，而且讓代碼更不易讀和理解； 另外更重要的是導致多方引用，可能會引發內存泄露。
6. 用getApplication()來取Context當參數
對於需要使用Context對象作為參數的函數，要使用getApplication()獲取Context對象當參數，而不要使用this，除非你需要特定的組件實例！getApplication()返回的Context是屬於Application的，它會在整個應用的生命周期內存在，遠大於某個組件的生命周期，所以即使某個引用長期持有Context對象也不會引發內存泄露。
7. 主線程只做UI控制和Frameworks回調相關的事。附屬線程只做費時的後台操作。交互只通過Handler。這樣就可以避免大量的線程問題。
8. Frameworks的回調不要做太多事情僅做必要的初始化，其他不是很重要的事情可以放到其他線程中去做，或者用Handler Schele到稍後再做。
9. 要考慮多解析度
至少為hdpi, mdpi, ldpi准備圖片和布局。元素的單位也盡可能的使用dip而不要用px。
10. 利用Android手機的硬鍵
幾乎所有的Android手機都有BACK和MENU，它們的作用是返回和彈出菜單，所以就不要再在UI中設計返回按扭和菜單按扭。很多優秀的應用如隨手記和微信都有返回鍵，他們之所以有是因為他們都是從iOS上移植過來的，為了保存體驗的一致，所以也有了返回和菜單。但這不夠Android化，一個純正的Android是沒有必須重復硬鍵的功能的。

『伍』 Android Studio開發中，在AndroidManifest.xml中的正確位置加入<us

摘要 描述

『陸』 Android 開發中，有哪些坑需要注意

1.為Activity聲明系統配置變更事件系統配置變更事件是指轉屏，區域語言發生變化，屏幕尺寸發生變化等等，如果Activity沒有聲明處理這些事件，發生事件時，系統會把Activity殺掉然後重啟，並嘗試恢復狀態，Activity有機會通過onSaveInstanceState()保存一些基本數據到Bundle中，然後此Bundle會在Activity的onCreate()中傳遞過去。雖然這貌似正常，但是這會引發問題，因為很多其他的東西比如Dialog等是要依賴於具體Activity實例的。所以這種系統默認行為通常都不是我們想要的。為了避免這些系統默認行為，就需要為Activity聲明這些配置，如下二個是每個Activity必須聲明的：幾乎所有的Activity都要聲明如上，為什麼Android不把它們變成Default的呢?2.盡量使用Android的API這好像是廢話，在Android上面開發不用AndroidAPI用什麼？因為Android幾乎支持JavaSE所有的API，所以有很多地方AndroidAPI與JavaSE的API會有重復的地方，比如說對於文件的操作最好使用Android裡面Context封裝的API，而不要直接使用File對象：Context.openFileOutput(String);//noFilefile=newFile(String)原因就是API裡面會考慮到Android平台本身的特性；再如，少用Thread，而多使用AsyncTask等。3.要考慮到Activity和進程被殺掉的情況如了通常情況退出Activity外，還有Activity因其他原因被殺的情況，比如系統內存過低，系統配置變更，有異常等等，要考慮和測試這種情況，特別是Activity處理重要的數據時，做好的數據的保存。4.小心多語言有些語言真的很啰嗦，中文或英文很簡短就能表達的事情到了其他語言就變的死長死長的，所以如果是wrap_content就可能把其他控制擠出可視范圍；如果是指定長度就可能顯示不全。也要注意特殊語言比如那些從右向左讀的語言。5.不要用四大組件去實現介面一是組件的對象都比較大，實現介面比較浪費，而且讓代碼更不易讀和理解；另外更重要的是導致多方引用，可能會引發內存泄露。6.用getApplication()來取Context當參數對於需要使用Context對象作為參數的函數，要使用getApplication()獲取Context對象當參數，而不要使用this，除非你需要特定的組件實例！getApplication()返回的Context是屬於Application的，它會在整個應用的生命周期內存在，遠大於某個組件的生命周期，所以即使某個引用長期持有Context對象也不會引發內存泄露。7.主線程只做UI控制和Frameworks回調相關的事。附屬線程只做費時的後台操作。交互只通過Handler。這樣就可以避免大量的線程問題。8.Frameworks的回調不要做太多事情僅做必要的初始化，其他不是很重要的事情可以放到其他線程中去做，或者用HandlerSchele到稍後再做。9.要考慮多解析度至少為hdpi,mdpi,ldpi准備圖片和布局。元素的單位也盡可能的使用dip而不要用px。10.利用Android手機的硬鍵幾乎所有的Android手機都有BACK和MENU，它們的作用是返回和彈出菜單，所以就不要再在UI中設計返回按扭和菜單按扭。很多優秀的應用如隨手記和 都有返回鍵，他們之所以有是因為他們都是從iOS上移植過來的，為了保存體驗的一致，所以也有了返回和菜單。但這不夠Android化，一個純正的Android是沒有必須重復硬鍵的功能的。

『柒』 Android 開發中常用到的設計模式有哪些

2. 軟體設計模式的分類
2.1. 創建型
創建對象時，不再由我們直接實例化對象；而是根據特定場景，由程序來確定創建對象的方式，從而保證更大的性能、更好的架構優勢。創建型模式主要有簡單工廠模式（並不是23種設計模式之一）、工廠方法、抽象工廠模式、單例模式、生成器模式和原型模式。
2.2. 結構型
用於幫助將多個對象組織成更大的結構。結構型模式主要有適配器模式adapter、橋接模式bridge、組合器模式component、裝飾器模式decorator、門面模式、亨元模式flyweight和代理模式proxy。
2.3. 行為型
用於幫助系統間各對象的通信，以及如何控制復雜系統中流程。行為型模式主要有命令模式command、解釋器模式、迭代器模式、中介者模式、備忘錄模式、觀察者模式、狀態模式state、策略模式、模板模式和訪問者模式。
3. 常見設計模式介紹
3.1. 單例模式(singleton)
有些時候，允許自由創建某個類的實例沒有意義，還可能造成系統性能下降。如果一個類始終只能創建一個實例，則這個類被稱為單例類，這種模式就被稱為單例模式。
一般建議單例模式的方法命名為：getInstance()，這個方法的返回類型肯定是單例類的類型了。getInstance方法可以有參數，這些參數可能是創建類實例所需要的參數，當然，大多數情況下是不需要的

『捌』 Android 開發中常用到的設計模式有哪些

設計模式總共是23種，常用的有下面幾種 ：
1 單例模式，application 就是單例 可以存儲一些數據例如記錄activity的啟動數量 ；
2 觀察者模式： button的onClickListener ，監聽button的響應；
3 適配器模式 ：例如recyclerView 的adapter ；
4 命令模式： 例如開源庫eventBus ，把數據封裝好 發送出去，然後接收； 等等等等，很多

『玖』 Android 軟體開發中，如何選擇可用的揚聲器進行播放（或者麥克風進行錄音）

正常情況下，選擇音頻類型進行播放，或者選擇指定的input source 進行錄音後，系統會根據對應音頻類型和source類型進行分配對應的有效設備，所以如果系統有對應的設備內容，在播放和錄音的時候，系統會分配相應的 mic 和 speaker，因此不需要額外指定的