android進程保活

㈠ 安卓手機「不保留活動」和「不允許後台進程」是什麼意思

不保留活動指的是你手機所有程序切換後不保留，比方說你用扣扣然後去發簡訊，那麼系統就會關閉扣扣，你再用扣扣就重新打開，重新載入緩存。不保留後台進程中後台進程限制的是緩存里的進程，而手機運行系統不可能不存在後台運行。

android的應用在被切換到後台時，它其實已經被暫停了，並不會消耗cpu資源，只保留了運行狀態。所以為什麼有的程序切出去重進會到主界面。

但是，一個程序如果想要在後台處理些東西，如音樂播放，它就會開啟一個服務。服務可在後台持續運行，所以在後台耗電的也只有帶服務的應用了。這個在進程管理軟體里能看到，標簽是service。至於廣播什麼的我就不涉及了。

所以沒有帶服務的應用在後台是完全不耗電的，沒有必要關閉。重啟後才會變回標准限制，不用管的。

安卓（Android）是一種基於linux內核（不包含GNU組件）的自由及開放源代碼的操作系統。主要使用於移動設備，如智能手機和平板電腦，由美國Google公司和開放手機聯盟領導及開發。Android操作系統最初由Andy Rubin開發，主要支持手機。

2005年8月由Google收購注資。2007年11月，Google與84家硬體製造商、軟體開發商及電信營運商組建開放手機聯盟共同研發改良Android系統。隨後Google以Apache開源許可證的授權方式，發布了Android的源代碼。

第一部Android智能手機發布於2008年10月。Android逐漸擴展到平板電腦及其他領域上，如電視、數碼相機、游戲機、智能手錶等。2011年第一季度，Android在全球的市場份額首次超過塞班系統，躍居全球第一。

2013年的第四季度，Android平台手機的全球市場份額已經達到78.1%。2013年09月24日谷歌開發的操作系統Android在迎來了5歲生日，全世界採用這款系統的設備數量已經達到10億台。

㈡ android守護進程

Android中應該使用Service而不應該使用線程，Android中有提供後台運行的組件,叫Service。

servie是系統的組件，它由系統進程託管（servicemanager）；它們之間的通信類似於client和server，是一種輕量級的ipc通信，這種通信的載體是binder，它是在linux層交換信息的一種ipc。而thread是由本應用程序託管。

1. Thread：Thread是程序執行的最小單元，它是分配CPU的基本單位。可以用Thread來執行一些非同步的操作。

2. Service：Service是android的一種機制，當它運行的時候如果是Local Service，那麼對應的Service是運行在主進程的main線程上的。如：onCreate，onStart這些函數在被系統調用的時候都是在主進程的main線程上運行的。如果是RemoteService，那麼對應的Service則是運行在獨立進程的main線程上。
   

關於用戶線程和守護線程:

在java中有兩類線程：User Thread(用戶線程)、Daemon Thread(守護線程)

Daemon的作用是為其他線程的運行提供便利服務，比如垃圾回收線程就是一個很稱職的守護者。User和Daemon兩者幾乎沒有區別，唯一的不同之處就在於虛擬機的離開：如果 User Thread已經全部退出運行了，只剩下Daemon Thread存在了，虛擬機也就退出了。 因為沒有了被守護者，Daemon也就沒有工作可做了，也就沒有繼續運行程序的必要了。

㈢ 怎麼讓 Android 程序一直後台運行，像 QQ 一樣不被殺死

方法：對於一個service，可以首先把它設為在前台運行：publicvoidMyService.onCreate(){super.onCreate();Notificationnotification=newNotification(android.R.drawable.my_service_icon,"my_service_name",System.currentTimeMillis());PendingIntentp_intent=PendingIntent.getActivity(this,0,newIntent(this,MyMainActivity.class),0);notification.setLatestEventInfo(this,"MyServiceNotification,"!",p_intent);Log.d(TAG,String.format("notification=%s",notification));startForeground(0x1982,notification);//notificationID:0x1982,youcannameitasyouwill.}重要設置-------------------------------相較於/data/app下的應用，放在/system/app下的應用享受的特權，比如若在其Manifest.xml文件中設置persistent屬性為true，則可使其免受out-of-memorykiller的影響。如應用程序'Phone'的AndroidManifest.xml文件：設置後app提升為系統核心級別，任何情況下不會被kill掉,settings->applications裡面也會屏蔽掉stop操作。這樣設置前的log:Proc#19:adj=svc/B4067b028255:com.xxx.xxx/10001(started-services)#cat/proc/255/oom_adj設置後的log:PERS#19:adj=core/F406291f0155:com.xxx.xxx/10001(fixed)#cat/proc/155/oom_adj-12#這是CORE_SERVER_ADJ註：init進程的oom_adj為-16（即SYSTEM_ADJ）：cat/proc/1/oom_adjAndroid相關部分分析：在文件frameworks/base/services/java/com/android/server/am/ActivityManagerService.java中有以下的代碼：(ApplicationInfoinfo){ProcessRecordapp=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)/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){//.adj=FOREGROUND_APP_ADJ;app.adjType="top-activity";}Androidkernel中的lowmemorykillerAndroid的LowMemoryKiller根據需要（當系統內存短缺時）殺死進程釋放其內存，源代碼在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列表：adbshellmpsysactivity當activitydemo在前台時：包含Service的進程的優先順序比較高，在computeOomAdjLocked中將其分為了兩小類:staticfinalintMAX_SERVICE_INACTIVITY=30*60*1000;if(nowSECONDARY_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 7.0 和8.0 如何保活

1.控制onStartCommand函數的返回值。

我對這個函數的理解是：當服務被異常終止時，是否重啟服務?

有些文章裡面在用這個做保活時，修改的是flag，在我實際測試中是無效。有效的做法是直接返回參數。另外默認的flags值為0，是START_STICKY_COMPATIBILITY。如下：

[java]view plain

• @Override

• publicintonStartCommand(Intentintent,intflags,intstartId){

• //TODOAuto-generatedmethodstub

• returnSTART_STICKY;

• //returnsuper.onStartCommand(intent,flags,startId);

• }

測試結果：

魅族的機子：無效，不管默認還是修改參數，在DDMS裡面直接結束進程後都不會重啟服務。

其它三台機子（9100沒測）：默認參數的情況下就會重啟服務，return START_STICKY 會重啟，return START_NOT_STICKY 不會重啟。

其它：1.用360一鍵清理，或者360超級ROOT的手機優化，會殺死進程，過會兒還是會重啟，只是會慢很多，大概是在排隊重啟服務。

2.一次測試完後確保服務重啟後，執行了onStartCommand函數。

2.在service 的onDestory裡面重啟服務

這個在所有能觸發onDestory的情況下都是有效的。4台測試機都測試過。直接startService 或者發送廣播重啟都可以 。

但能觸發onDestory的情況，我不知道內存回收會不會觸發。另外兩種情況（2，3）是不觸發的。我的測試方法是在「設置」-》應用管理-》正在運行-》停止服務。（這個是正常停止服務，會觸發onDestory，所以上面的onStartCommand效果不會觸發。）

3.提高服務的優先順序

這個主要是針對第一種kill服務的情況，內存回收機制。由於這個測試比較難搭建。360清理什麼把後台的進程都殺的，體現不出優先順序這樣的概念。我的建議是能提高就提高。下面例幾種。

通知--前台service

創建一個通知使自己成為前台service

測試結果：

360一鍵清理和手機優化，不會把該service結束掉。

對於後台保護：華為G730不結束service，魅族和華為TL00H都會結束service。

通知欄的保活效果還是可以的，一般的應用要求基本能滿足了。

若有root許可權：

android:persistent="true",並放入system/app中

測試結果：效果一般，三星9100上用360等清理工具殺不掉進程，在華為G730上沒什麼效果.（這個測試跟onStartCommand有點干擾）

4.守護進程

雙服務

360會同時殺掉兩個服務，分兩個apk也一樣。

native守護進程

360不會殺掉native的守護進程，但在魅族和華為TL00H中待機一段時間後還是會被殺掉。

結論和待續

1.一般的應用添加到後台保護進程後，改個onStartCommand返回值，再加個通知。基本上大部分都能保活了。

2.雙服務我覺得沒有native守護進程來的好，雖然360，微信什麼的都有幾個進程服務，但如果不添加到後台保活的話，效果一樣不能保活，也會進入停止狀態。

3.但是.360手機助手會創建雙natice守護進程做相互的看守。存活的效果會高一點點。「沒添加到後台保活」一般只會殺一次，（魅族是屏幕關閉後5分鍾，華為TL00H是屏幕關閉時）

㈤ android 如何讓一個apk的進程不被自動殺死，讓它一直運行。

APK怎麼被運行就看當時內存的情況了。如果內存不夠，原來就被KILL掉，重新切到它就只有重新創建了，如果內存夠就只是PAUSE一下，重新切回就RESUME就OK了。

㈥ 怎麼讓Android程序一直後台運行，像QQ一樣不被殺死

強烈建議不要這么做，不僅僅從用戶角度考慮，作為Android開發者也有責任去維護Android的生態環境。現在很多Android開發工程師，主力機居然是iPhone而不是Android設備，感到相當悲哀。

從技術角度概括一下現在普遍的防殺方法Service設置成START_STICKY，kill 後會被重啟（等待5秒左右），重傳Intent，保持與重啟前一樣通過 startForeground將進程設置為前台進程，做前台服務，優先順序和前台應用一個級別，除非在系統內存非常缺，否則此進程不會被 kill雙進程Service：讓2個進程互相保護，其中一個Service被清理後，另外沒被清理的進程可以立即重啟進程QQ黑科技:在應用退到後台後，另起一個只有 1 像素的頁面停留在桌面上，讓自己保持前台狀態，保護自己不被後台清理工具殺死在已經root的設備下，修改相應的許可權文件，將App偽裝成系統級的應用（Android4.0系列的一個漏洞，已經確認可行）Android系統中當前進程(Process)fork出來的子進程，被系統認為是兩個不同的進程。當父進程被殺死的時候，子進程仍然可以存活，並不受影響。鑒於目前提到的在Android-Service層做雙守護都會失敗，我們可以fork出c進程，多進程守護。死循環在那檢查是否還存在，具體的思路如下（Android5.0以下可行）用C編寫守護進程(即子進程)，守護進程做的事情就是循環檢查目標進程是否存在，不存在則啟動它。在NDK環境中將1中編寫的C代碼編譯打包成可執行文件(BUILD_EXECUTABLE)。主進程啟動時將守護進程放入私有目錄下，賦予可執行許可權，啟動它即可。聯系廠商，加入白名單

㈦ 面試android高級開發工程師具備哪些技能

1、關於團隊：對內：能提升團隊內聚力和執行力，注重個人成長，能快速提高團隊戰鬥力；對外：能住區更多的資源，使項目和組內成員獲得更好的成長和發展。
2、關於技術：領導項目優化，架構變更、核心模塊的修改，也能不斷引入新技術、對標競品，不但技術上領先，也能做出更優秀的作品。
一、了解系統核心機制
1. 了解SystemServer的啟動過程
2. 了解主線程的消息循環模型
3. 了解AMS和PMS的工作原理
4. 能夠回答問題」一個應用存在多少個Window？「
5. 了解四大組件的大概工作流程
二、基本知識點的細節
1. Activity的啟動模式以及異常情況下不同Activity的表現
2. Service的onBind和onReBind的關聯
3. onServiceDisconnected(ComponentName className)和binderDied()的區別
4. AsyncTask在不同版本上的表現細節
5. 線程池的細節和參數配置
6.熟悉設計模式，有架構意識
三、技術要求
1.稍微深入的知識點
2.系統核心機制
3.基本知識點的細節
4.設計模式和架構
當然，除了上面的知識點和技能外，你還要能玩轉RxJava、掌握自定義view 、要會進程間通信與進程保活、熱修復等知識點。

㈧ Android無線開發的幾種常用技術（阿里巴巴資深

完整的開發一個android移動App需要經過從分解需求、架構設計到開發調試、測試、上線發布等多個階段，在發布後還會有產品功能上的迭代演進，此外還會面對性能、安全、無線網路質量等多方面的問題。
移動App的產品形態各不相同，有的是內容類，有的是工具類，有的是社交類，所以它們的業務邏輯所偏重的核心技術有些差別，但它們都會用到一些常用的技術方案。今天我們就先來簡單介紹一下這些常用技術，以後會專門分專題來詳細介紹這些技術的原理和使用場景。

1. Multidex
在Dalvik虛擬機所使用的dex文件格式中，用原生類型short來索引文件中的方法數，也就是最多隻能有4個位元組65536個method，在打包apk的過程中會把工程所需要的全部class文件都合並壓縮到一個dex文件中，也就是說自己開發的代碼加上外部引用的庫的方法總數不能超過65535。
隨著業務邏輯的不斷增長，很容易就會超過這個限制，在編譯期間就會遇到這樣一個錯誤：

還好google官方給出了一個解決方案Multidex，它會把dex文件拆成兩個或多個，第二個dex文件叫classes2.dex，在Application實例化後會從apk中解壓出classes2.dex並將其拷貝到應用的目錄下，通過反射將其注入到當前的ClassLoader中。但是這個方案非但不能解決一切問題也不能直接拿來用，而要加入自己的一些改造，來解決NoClassDefFoundError、INSTALL_FAILED_DEXOPT等問題，以保證自己的dex被順利的載入流暢的執行。

2. Plugin
Multidex雖然可以解決方法數的限制，但隨著業務邏輯越來越多，apk的大小也變得越來越多，而且有一些功能並非全部用戶都想用的，所以會把一些功能模塊獨立出來做成插件，讓用戶可以按需下載更新，這樣既減小了包大小，又改善了用戶體驗。

插件類似於windows的dll文件，放在某個特定目錄，應用程序主框架會用LoadLibrary載入各dll文件，按插件介面去訪問插件。Android的插件技術也是這樣，利用一個進程可以運行多個apk的機制，用ClassLoader將宿主apk之外的類載入進來，插件的context可以通過createPackageContext方法創建。因為插件中的activity，service等組件如果沒有在AndroidManifest.xml中聲明將不能運行，所以需要預先在AndroidManifest.xml中聲明一個代理類（ProxyActivity），將這個ProxyActivity傳給插件，讓插件的activity也有訪問資源的能力。

3. Hot Patch
有時一些嚴重的crash bug或漏洞需要緊急修復，但有些用戶不會或不願意立即升級，而且頻繁升級，沒有特別的功能更新只是修復bug的升級，對活躍用戶是一種傷害。熱補丁就可以解決這樣的窘境，它是一種可以線上修復的技術方案，有動態改變方法的能力，一般大型的移動應用都會使用熱補丁來處理緊急事件。

Hot Patch可以通過hook來修改java的method，注入自己的代碼，實現非侵入式的runtime修改，或者採用正向編程，通過工具生成patch文件，通過jni bridge指向補丁文件中的方法。還有就是利用ClassLoader，在dex中查找class時，如果找到類則返回，找不到就從下一個dex文件中繼續查找，由此可以想到，在把問題修復後，可以單獨生成一個dex，通過反射插入到dexElements數組的最前面，這樣就能讓dalvik載入補丁里的類了。

4. Push通道
Push是移動App常用的一種無線技術，基礎是基於TCP的心跳機制，和客戶端維持一個長連接。用處是向客戶端推送消息，或者代替客戶端定時去從伺服器pull的策略，改為客戶端接收到push消息後再去pull。
如果每個應用都自己實現push通道的話，cpu就會不定時地經常被喚醒，耗電量達到難以容忍的程度，而且自己搭建push平台的成本也很大，實時性和效率也存在問題，一般都直接使用一些服務商提供的push方案，這些push平台一般都經過了優化設計，在跨平台和網路穿透性、長連接心跳包、多客戶端App鏈路復用、服務和連接保活等技術上做了優化。比如Agoo最初是淘寶無線事業部開發的push服務，在逐漸完善和支撐淘系其他app後，通過服務端容量、通訊協議優化、業務和開放能力的拓展改進後，與友盟等合作，開始向第三方提供推送服務。

5. 應用加固
一款熱門的移動app或游戲發布後會受到很多的關注，經常會遇到二次打包的盜版行為，破解者要麼修改游戲的資源文件、道具、分值甚至直接把訪問的站點指向自己架設的伺服器，損害了開發者的利益；要麼偷偷植入自己的惡意代碼，表面上看起來跟正版的app完全一樣，在後台卻盜取用戶隱私，植入木馬；要麼通過反向工程學習原app的核心技術，打破技術上的競爭壁壘。
為了防止被破解只通過混淆是遠遠不夠的，即使是在native層混淆也還是會被人熟練的反編譯，所以需要一套對apk的保護方案來反調試、防逆向和防篡改。一般的加固方法都是對原apk先進行加密，然後和殼合並生成新的apk。殼是用來解密apk的dex文件。當應用啟動時，殼先解密原apk，准備好自己定義的ClassLoader，然後獲取源程序中的Application名稱，通過反射找到正確的Application對象，運行它的onCreate方法，這樣原apk才能被真正運行。其他一些反調試的方法有針對反編譯工具，在源程序中加入一些無效的指令或無效的指針，引發反編譯工具的崩潰，還有就是加花指令，利用一些跳轉，堆棧操作等指令，讓破解者無法清楚地理解反匯編後的內容。

6. 其他
除了上述幾點外，在服務端還會涉及灰度策略、鏈路流量優化、動態更新配置、防DNS劫持等技術，在客戶端會涉及用戶埋點上報、在線監控、進程保活、H5和native混合開發、注入框架等。

㈨ 如何讓一個應用程序一直在後台運行

1、保活手段

1 業界保活手段：黑色保活，灰色保活，白色保活

2 黑色保活：

1 不同的APP進程，用廣播相互喚醒，包括利用系統廣播進行喚醒

2 常見手段：

1 開機，網路切換，拍照，拍視頻等利用系統廣播喚醒APP

此場景Google已經意識到，在Android N 取消了 拍照，視頻，網路切換的廣播

2 接入第三方的SDK也會喚醒相應的APP進程

3 假如你手機里裝了支付寶，淘寶，UC等阿里系的APP，那麼你打開任何一個，都有可能喚醒其他的阿里系的APP

3 白色保活：

就是調用系統的API啟動一個前台Service進程，這樣會在通知欄生成一個Notification，用戶知道哪些進程正在運行

4 灰色保活

1 保活領域應用最為廣泛，利用系統的漏洞來啟動一個前台的Service進程，與「白色保活」不同的是，它不會在通知欄生成一個Notification,用戶無法察覺，但是優先順序要高於普通的後台進程。

2 實現思路

思路一：當API<18，啟動前台的Service直接傳入new Notification()；

思路二：當API >= 18,同時啟動兩個id相同的前台Service，然後再將後啟動的Service做stop處理
代碼這樣寫：

[java]view plain

• importandroid.app.Notification;

• importandroid.app.Service;

• importandroid.content.Intent;

• importandroid.os.Build;

• importandroid.os.IBinder;

• /**

• *APP灰色保活

• *Createdbyfflinon2016/4/23.

• */

• {

• privatefinalstaticintGRAY_SERVICE_ID=1001;

• @Override

• publicIBinderonBind(Intentintent){

• returnnull;

• }

• @Override

• publicintonStartCommand(Intentintent,intflags,intstartId){

• //API<18,此方法能有效地隱藏notification的圖標

• if(Build.VERSION.SDK_INT<18){

• startForeground(GRAY_SERVICE_ID,newNotification());

• }else{

• Intentintent1=newIntent(this,GrayInnerService.class);

• startService(intent1);

• startForeground(GRAY_SERVICE_ID,newNotification());

• }

• returnsuper.onStartCommand(intent,flags,startId);

• }

• //給API>=18的平台上做灰色保護手段

• {

• @Override

• publicIBinderonBind(Intentintent){

• returnnull;

• }

• @Override

• publicintonStartCommand(Intentintent,intflags,intstartId){

• startForeground(GRAY_SERVICE_ID,newNotification());

• stopForeground(true);

• stopSelf();

• returnsuper.onStartCommand(intent,flags,startId);

• }

• }

• }





3 檢驗方法：


首先看系統通知欄有沒有Notification，如果沒有，就進入手機adb shell模式，輸入命令mpsys activity services PackageName


列印出指定包名的所有進程中的service信息，看下有沒有isForground=true的信息，如果有，就說明了該APP使用了灰色保活


4 使用灰色保活手段並不意味著你的應用就能永生不死，只能說提高了進程的優先順序，如果應用佔用了很大的內存，還是會被回收的


2、進一步理解保活

1 進程回收機制

系統出於體驗和性能上的考慮，APP在退出後台時系統並不會真正的kill掉這個進程，而是將其緩存起來，打開的應用越多，後台緩存的進程也就越多。在系統內存不足的情況下，系統開始根據自身的一套進程回收機制來判斷要回收掉哪些進程，這套殺死進程回收內存的機制叫 Low Memory Killer，它是基於Linux內核的OOM killer機制誕生的，該機制為每個系統分配了一個值，叫做oom_adj，代表了進程的優先順序，oom_adj越大，代表優先順序越低，越容易被回收，普通APP進程的oom_adj >=0,系統的可能會小於0.

2 查看oom_adj的值，需要用到兩個shell命令

ps | grep 包名

$cat /proc/進程id/oom_adj

3 結果發現，APP推到後台，UI進程的值降低最為明顯，因為它佔用的內存資源最多，因此，為了避免後台UI進程被殺，需要盡可能的釋放一些不用的圖片，音頻資源

㈩ 如何提PUSH的達到率

首先，先明確為什麼要優化推送？

最直接原因就是提升DAU，讓用戶更多打開App，這背後隱含的目的是希望激活新用戶、召迴流失用戶，讓業務長期健康增長。因此，務必注意這不是一次性的事兒，要通盤考慮，KPI導向的數據提升一定會引起反彈的。

OK，接下來進入正題，聊下提升PUSH到達率的一些手段。

為了幫大家理解PUSH原理，先放一張業務架構圖：

在此基礎上，可以適當增加一些打開推送開關的引導，一般可以有如下場景：

但真正最合適的引導方式還是讓用戶體驗到你產品的價值後，給一個利他的理由，自然引導，而不是一上來就彈窗。這點很多大廠App都做的很好，建議多參考。

以上就是今天想和大家分享的，有關推送到達率提升的一些觀點總結，信息量有點大，部分也參考了其他文章和書籍，希望能對你有幫助。同時，如果有我沒提到的，也歡迎你留言告訴我，我也會再和大家分享~

參考文獻