⑴ 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中判斷軟鍵盤是否彈出或隱藏
Android中判斷軟鍵盤是否彈出或隱藏可以藉助軟鍵盤顯示和隱藏時，對主窗口進行了重新布局這個特性來進行偵聽。如果我們設置的模式為壓縮模式，那麼我們可以對布局的onSizeChanged函數進行跟蹤，如果為平移模式，那麼該函數可能不會被調用。
假設跟布局為線性布局，模式為壓縮模式，我們寫一個例子，當輸入法彈出時隱藏某個view，輸入法隱藏時顯示某個view。
{
;
{
voidOnResize(intw,inth,intoldw,intoldh);
}
publicvoidsetOnResizeListener(OnResizeListenerl){
mListener=l;
}
publicResizeLayout(Contextcontext,AttributeSetattrs){
super(context,attrs);
}
@Override
protectedvoidonSizeChanged(intw,inth,intoldw,intoldh){super.onSizeChanged(w,h,oldw,oldh);
if(mListener!=null){
mListener.OnResize(w,h,oldw,oldh);
}
}
}
⑶ Android studio 怎樣使用隱藏API
http://stackoverflow.com/questions/7888191/how-do-i-build-the-android-sdk-with-hidden-and-internal-apis-available
一般兩種方式：1、使用java的反射，具體實現你可以網上查一下。2、通過導入android源碼編譯過的classes.jar
⑷ android怎樣調用@hide和internal API
Android有兩種類型的API是不能經由SDK訪問的。
第一種是位於com.android.internal包中的API。我將稱之為internal API。第二種API類型是一系列被標記為@hide屬性的類和方法。從嚴格意義上來講，這不是一個單一的API，而是一組小的被隱藏的API，但我仍將其假設為一種API，並稱之為hidden API。
Hidden API 例子
你可以查看一下android的源碼，並能找到一些變數、函數和類等，都被@hide屬性標記了。
下面的例子就是在WifiManager（API 10源碼）中隱藏的變數。
另一個例子是在WifiManager（API 10源碼）中隱藏了setWifiApEnabled函數。
因此，只要你看到@hide屬性，那你看到的就是hidden API。
Internal和hidden API的區別
Hidden API之所以被隱藏，是想阻止開發者使用SDK中那些未完成或不穩定的部分（介面或架構）。舉個例子，Bluetooth API在API 5（Android 2.0）上才開放；在API 3 和4上都是用@hide屬性隱藏了。當這些API被驗證和清理後，Google的開發者會移除@hide屬性，並讓其在API 5官方化。很多地方在API 4 和5之間發生了變化。如果你的程序依賴某些隱藏的API，當其部署到新的平台上時，就有可能陷入困境。
對於internal API來說，從來都沒有計劃將其開放出來。它就是Android的「內部廚房」，對開發者來說，應該將其視作黑盒。凡事都會有變化的。如果你依賴某些internal API，也有可能在新的Android release上，這些internal API發生變化，從而令你失望。
總結一下區別：
Hidden API = 進行中的工作；
Internal API = 黑盒；
Internal和hidden API的編譯時 vs. 運行時
當你使用Android SDK進行開發的時候，你引用了一個非常重要的jar文件——android.jar。它位於Android SDK平台的文件夾中（SDK_DIR/platforms/platform-X/android.jar，其中，X表示API等級）。這個android.jar移掉了com.android.internal包中所有的類，也移掉了所有標記有@hide的類，枚舉，欄位和方法。
但當你在設備上啟動應用程序時，它將載入framework.jar（簡單來說，它和android.jar等同），而其未移掉internal API和hidden API。（但它對開發者來說，並不能友好地訪問，因此，我將向大家展示不通過反射如何使用這些API）。
關於internal API，還有一件事需要說明。Eclipse的ADT插件增加了一個額外的規則，那就是禁止使用com.android.internal包中的任何東西。所以，即便是我們可以拿到最原始的android.jar（未刪減版），也沒有輕松的辦法通過Eclipse使用這些internal API。
你可以親自檢查一下。創建一個新的Android工程（或者使用已有的）。查看一下它引用的類庫（右擊project Properties –> Java Build Path –> Libraries）。
重要的總結：internal和hidden API在SDK中是按照一樣的方式處理的（都從android.jar中移除了），但internal API更慘的是，還被Eclipse的ADT插件顯式禁止了。
不通過反射使用internal和hidden API
這些文章的終極目標是讓開發者能夠不通過反射使用Internal和Hidden API。如果你完成了接下來部分中描述的步驟，你將能使用這些Internal和Hidden API，如同公開的API。你不再需要使用反射。
註：如果你正在使用這些非公開的API，你必須知道，你的程序有著極大的風險。基本上，無法保證在下一次的Android OS更新時，這些API不被破壞，也無法保證不同的運營商有著一致的行為。你自己決定吧。
接下來有三個場景：
1. Internal 和hidden API都可用（場景A）
2. 只Hidden API可用（場景B）
3. 只Internal API可用（場景C）
場景A是B、C的總和。場景B是最簡單的一個（不需要對Eclipse的ADT修改）。
場景A：閱讀Part1, 2, 3, 4, 5
場景B：閱讀Part1, 2, 3, 5
場景C：閱讀Part1, 2, 3, 4, 5
我解釋了為什麼我們不通過反射就會很難使用internal和hidden API。這是因為android.jar中就沒包含這些API，因此，沒人能夠在編譯時引用這些類。
這篇文章將描述如何還原最初的android.jar。這將允許我們像使用公開的API那樣使用internal和hidden API。
如何得到原版android.jar？
我們需要修改android.jar，這樣它才能包含所有的*.class文件（包括internal和hidden API類）。有兩種辦法：
1） Android是一個開源工程。我們可以下載源碼並搭建編譯環境，這樣它就不能移除那些internal和hidden的類了。這個辦法比較困難；
2） 每個模擬器或真機在運行時都會有一個等同android.jar的東西。我們可以從這里拿到jar文件，提取出原始的.class文件，並拷貝到Android SDK的android.jar中。
我將採用方案2。它易於開始，還不需要搭建Linux環境及編譯環境等。
從設備上獲取framework.jar
你可以使用命令行（adb pull）從模擬器或設備上下載文件，或者使用DDMS（藉助Eclipse或SDK中的應用）。
注意：模擬器通常在.dex文件中包含代碼，而真機一般在優化版的dex文件中包含代碼——odex文件。操作odex文件比較困難，這也是為什麼我選擇模擬器的原因。
與Android SDK中的android.jar等同的文件是framework.jar。這個文件位於設備的：/system/framework/framework.jar
adb pull /system/framework/framework.jar
當framework.jar從設備上下下來之後，重命名為framework.zip並解壓到獨立的文件夾中，看起來是這個樣子的：
classes.dex正是我們需要的。
創建framework-classes.zip
首先，我們需要把.dex文件轉換成.jar格式。你可以使用通用的工具dex2jar。只需要運行：
dev2jar classes.dex
當轉換結束時，你應該得到了classes.dex.dex2jar.jar文件。重命名為framework-classes.zip。使用zip查看器，進入到framework-classes.zip/com/android/internal/：
恭喜你，你已經擁有了所有的.class文件，包括internal和hidden API（盡管截圖只確認了internal部分）。
創建original-android.jar
Android SDK的android.jar位於ANDROID_SDK/platforms/android-X/android.jar（X表示API等級）。
拷貝android.jar成custom-android.jar。解壓至custom-android文件夾。將framework-classes.zip中所有的.class文件拷貝到custom-android文件夾中（你需要覆蓋所有已經存在的.class文件）。
然後，壓縮custom-android文件成original-android.zip。重命名為original-android.jar。
步驟總結
1. 選擇你的目標平台X
2. 創建目標平台X的模擬器
3. 啟動模擬器，下載/system/framework/framework.jar
4. 重命名framework.jar -> framework.zip
5. 從framework.zip中抽取classes.dex
6. 使用dex2jar工具，將其轉換成classes.jar
7. 重命名classes.jar -> framework-classes.zip
8. 拷貝android.jar –> custom-android.zip
9. 解壓custom-android.zip至custom-android文件夾
10. 將framework-classes.zip中所有文件拷貝至custom-android文件夾（覆蓋存在的文件）
11. 壓縮custom-android文件夾成original-android.zip
12. 重命名original-android.zip -> original-android.jar
打完收功。
⑸ android:configChanges屬性中keyboardHidden的作用是什麼
1、不設置Activity的android:configChanges時，切屏會重新調用各個生命周期，切橫屏時會執行一次，切豎屏時會執行兩次2、設置Activity的android:configChanges="orientation"時，切屏還是會重新調用各個生命周期，切橫、豎屏時只會執行一次3、設置Activity的android:configChanges="orientation|keyboardHidden"時，切屏不會重新調用各個生命周期，只會執行onConfigurationChanged方法
⑹ 怎麼讓Android程序一直後台運行，像QQ一樣不被殺死
方法：
對於一個service，可以首先把它設為在前台運行：
public void MyService.onCreate() {
super.onCreate();
Notification notification = new Notification(android.R.drawable.my_service_icon,
"my_service_name",
System.currentTimeMillis());
PendingIntent p_intent = PendingIntent.getActivity(this, 0,
new Intent(this, MyMainActivity.class), 0);
notification.setLatestEventInfo(this, "MyServiceNotification, "MyServiceNotification is Running!", p_intent);
Log.d(TAG, String.format("notification = %s", notification));
startForeground(0x1982, notification); // notification ID: 0x1982, you can name it as you will.
}
重要設置-------------------------------
相較於/data/app下的應用，放在/system/app下的應用享受更多的特權，比如若在其Manifest.xml文件中設置persistent屬性為true，則可使其免受out-of-memory killer的影響。如應用程序'Phone'的AndroidManifest.xml文件：
<application android:name="PhoneApp"
android:persistent="true"
android:label="@string/dialerIconLabel"
android:icon="@drawable/ic_launcher_phone">
...
</application>
設置後app提升為系統核心級別，任何情況下不會被kill掉, settings->applications裡面也會屏蔽掉stop操作。
這樣設置前的log: Proc #19: adj=svc /B 4067b028 255:com.xxx.xxx/10001 (started-services)
# cat /proc/255/oom_adj
設置後的log: PERS #19: adj=core /F 406291f0 155:com.xxx.xxx/10001 (fixed)
# cat /proc/155/oom_adj
-12 # 這是CORE_SERVER_ADJ
註：init進程的oom_adj為-16（即SYSTEM_ADJ）： cat /proc/1/oom_adj
Android相關部分分析：
在文件frameworks/base/services/java/com/android/server/am/ActivityManagerService.java中有以下的代碼：
final ProcessRecord addAppLocked(ApplicationInfo info) {
ProcessRecord app = getProcessRecordLocked(info.processName, info.uid);
if (app == null) {
app = newProcessRecordLocked(null, info, null);
mProcessNames.put(info.processName, info.uid, app);
updateLruProcessLocked(app, true, true);
}
if ((info.flags&(ApplicationInfo.FLAG_SYSTEM|ApplicationInfo.FLAG_PERSISTENT))
== (ApplicationInfo.FLAG_SYSTEM|ApplicationInfo.FLAG_PERSISTENT)) {
app.persistent = true;
app.maxAdj = CORE_SERVER_ADJ; // 這個常數值為-12。
}
if (app.thread == null && mPersistentStartingProcesses.indexOf(app) < 0) {
mPersistentStartingProcesses.add(app);
startProcessLocked(app, "added application", app.processName);
}
return app;
}
可見要想成為core service （即app.maxAdj = CORE_SERVER_ADJ(-12)），應用程序需要FLAG_SYSTEM和FLAG_PERSISTENT兩個標志，FLAG_SYSTEM指的是應用位於/system/app下，FLAG_PERSISTENT就是指persistent屬性。
而對於frameworks/base/services/java/com/android/server/SystemServer.java，則調用
ActivityManagerService.setSystemProcess();
把自己的 app.maxAdj 設置成SYSTEM_ADJ，即-16。
原理：
Android中的進程是託管的，當系統進程空間緊張的時候，會依照優先順序自動進行進程的回收。由此帶來三個問題：
1） 回收規則: 什麼時候回收與回收哪一個？
2） 避免誤殺: 如何阻止被回收？
3） 數據恢復與保存: 被回收了怎麼辦？
Android將進程分為6個等級,它們按優先順序順序由高到低依次是:
1.前台進程( FOREGROUND_APP)
2.可視進程(VISIBLE_APP )
3. 次要服務進程(SECONDARY_SERVER )
4.後台進程 (HIDDEN_APP)
5.內容供應節點(CONTENT_PROVIDER)
6.空進程(EMPTY_APP)
特徵：
1.如果一個進程裡面同時包含service和可視的activity，那麼這個進程應該歸於可視進程，而不是service進程。
2.另外，如果其他進程依賴於它的話，一個進程的等級可以提高。例如，一個A進程里的service被綁定到B進程里的組件上，進程A將總被認為至少和B進程一樣重要。
3.系統中的phone服務被劃分到前台進程而不是次要服務進程.
在android中，進程的oom_adj值也就代表了它的優先順序。oom_adj值越高代表該進程優先順序越低。文件/init.rc中有以下屬性設置：
setprop ro.FOREGROUND_APP_ADJ 0
setprop ro.VISIBLE_APP_ADJ 1
setprop ro.SECONDARY_SERVER_ADJ 2
setprop ro.HIDDEN_APP_MIN_ADJ 7
setprop ro.CONTENT_PROVIDER_ADJ 14
setprop ro.EMPTY_APP_ADJ 15
/init.rc中，將PID為1的進程(init進程)的oom_adj設置為SYSTEM_ADJ(-16):
# Set init its forked children's oom_adj.
write /proc/1/oom_adj -16
查看本機設置：
cat /sys/mole/lowmemorykiller/parameters/adj
0,1,2,7,14,15
回收時機：
文件/init.rc中:
setprop ro.FOREGROUND_APP_MEM 1536 // 6M
setprop ro.VISIBLE_APP_MEM 2048 // 8M
setprop ro.SECONDARY_SERVER_MEM 4096 // 16M
setprop ro.HIDDEN_APP_MEM 5120 // 20M
setprop ro.CONTENT_PROVIDER_MEM 5632 // 22.4M
setprop ro.EMPTY_APP_MEM 6144 // 24M
這些數字也就是對應的內存閾值，一旦低於該值，Android便開始按順序關閉相應等級的進程。
注意這些數字的單位是page： 1 page = 4 kB。所以上面的六個數字對應的就是(MB): 6,8,16,20,22,24。
查看現在的內存閾值設置：
cat /sys/mole/lowmemorykiller/parameters/minfree
要想重新設置該值（對應不同的需求）:
echo "1536,2048,4096,5120,15360,23040">/sys/mole/lowmemorykiller/parameters/minfree
這樣當可用內存低於90MB的時候便開始殺死"空進程"，而當可用內存低於60MB的時候才開始殺死"內容供應節點"類進程。
具體的回收實現在ActivityManagerService.java中的函數trimApplications()：
1.首先移除package已被卸載的無用進程；
2.基於進程當前狀態，更新oom_adj值，然後進行以下操作：
1) 移除沒有activity在運行的進程;
2) 如果AP已經保存了所有的activity狀態，結束這個AP。
3. 最後，如果目前還是有很多activities 在運行，那麼移除那些activity狀態已經保存好的activity。
更新oom_adj的值：
在ActivityManagerService.java文件的ComputeOomAdjLocked() 中計算出進程的oom_adj，例如:
if (app == TOP_APP) {
// The last app on the list is the foreground app.
adj = FOREGROUND_APP_ADJ;
app.adjType = "top-activity";
}
Android kernel中的low memory killer
Android的Low Memory Killer根據需要（當系統內存短缺時）殺死進程釋放其內存，源代碼在kernel/drivers/misc/lowmemorykiller.c中。簡單說，就是尋找一個最合適的進程殺死，從而釋放它佔用的內存。
最合適的進程是:
• oom_adj越大
• 佔用物理內存越多
一旦一個進程被選中，內核會發送SIGKILL信號將之殺死：
for_each_process(p) {
……
if(selected == NULL || p->oomkilladj > selected->oomkilladj ||
(p->oomkilladj == selected->oomkilladj && tasksize > selected_tasksize))
{
selected = p;
}
}
if(selected != NULL) {
force_sig(SIGKILL, selected);
}
查看LRU列表：adb shell mpsys activity
當activitydemo在前台時：
包含Service的進程的優先順序比較高，在computeOomAdjLocked中將其分為了兩小類:
static final int MAX_SERVICE_INACTIVITY = 30*60*1000;
if (now < (s.lastActivity+MAX_SERVICE_INACTIVITY)) {
if (adj > SECONDARY_SERVER_ADJ) {
adj = SECONDARY_SERVER_ADJ;
app.adjType = "started-services";
app.hidden = false;
}
}
if (adj > SECONDARY_SERVER_ADJ) {
app.adjType = "started-bg-services";
}
完全讓進程不被kill是不可能的，我們可以通過一些操作，使進程被kill的幾率變小：
1) 提高進程的優先順序:
* 後台操作採用運行於前台的Service形式，因為一個運行著service的進程比一個運行著後台activity的等級高；
* 按back鍵使得進程中的activity在後台運行而不是destory，需重載back按鍵(沒有任何activity在運行的進程優先被殺).
* 依賴於其他優先順序高的進程；
2) 強制修改進程屬性：
* 在進程中設置：setPersistent(true);
* 在Manifest文件中設置（如上）。
⑺ android 在用add hide show 方法切換fragment的時候怎麼刷新數據
當Fragment隱藏後重新展示時（fragment.show）,調用onrequest刷新界面
* 否則每次都要重新復制
*/
@Override
public void onHiddenChanged(boolean hidden) {
super.onHiddenChanged(hidden);
if (!hidden) {
//rootview是Fragment通過inflate進來的布局
rootView.invalidate();
⑻ Android 怎麼隱藏第三方應用中的系統狀態欄
顯示與隱藏狀態欄的代碼如下：
private void fullscreen(boolean enable) {
if (enable) { //顯示狀態欄
WindowManager.LayoutParams lp = getWindow().getAttributes();
lp.flags |= WindowManager.LayoutParams.FLAG_FULLSCREEN;
getWindow().setAttributes(lp);
getWindow().addFlags(WindowManager.LayoutParams.FLAG_LAYOUT_NO_LIMITS);
} else { //隱藏狀態欄
WindowManager.LayoutParams lp = getWindow().getAttributes();
lp.flags &= (~WindowManager.LayoutParams.FLAG_FULLSCREEN);
getWindow().setAttributes(lp);
getWindow().clearFlags(WindowManager.LayoutParams.FLAG_LAYOUT_NO_LIMITS);
}
}
顯示與隱藏的效果如下：
android顯示與隱藏狀態欄
android顯示與隱藏狀態欄
橫屏與豎屏切換時處理狀態欄的顯示與隱藏，所以需要配置屏幕切換代碼。
AndroidManifest.xml中activity上配置
android:configChanges="orientation|keyboardHidden|screenSize"
android顯示與隱藏狀態欄
activity中override方法onConfigurationChanged
@Override
public void onConfigurationChanged(Configuration newConfig) {
super.onConfigurationChanged(newConfig);
if(this.getResources().getConfiguration().orientation == Configuration.ORIENTATION_LANDSCAPE ){//橫屏
}else if( this.getResources().getConfiguration().orientation == Configuration.ORIENTATION_PORTRAIT ){//豎屏
}
}
android顯示與隱藏狀態欄
⑼ android 怎麼給visible添加動畫
mAppHiddenAction.setDuration(400);
mAppGridView.startAnimation(mHiddenAction);
scrollView.startAnimation(mAppHiddenAction);
relativelayout.startAnimation(mAppHiddenAction);
後面這些代碼應該在mAppHiddenAction結束後再執行，而不是直接在這就執行，你可用hander+定時器延後執行即可
scrollView.setVisibility(View.GONE);
mAppGridView.setVisibility(View.GONE);
tv.setVisibility(View.GONE);
btn_save.setVisibility(View.GONE);