編輯:Android資訊
基於Android 6.0的源碼,剖析存儲架構的設計
Android 存儲系統之源碼篇
Android 存儲系統之架構篇
本文講述Android存儲系統的架構與設計,涉及到最為核心的便是MountService和Vold這兩個模塊以及之間的交互。上一篇文章Android存儲系統之源碼篇從源碼角度介紹相關模塊的創建與啟動過程,那麼本文主要從全局角度把握和剖析Android的存儲系統。
MountService:Android Binder服務端,運行在system_server進程,用於跟Vold進行消息通信,比如MountService
向Vold
發送掛載SD卡的命令,或者接收到來自Vold
的外設熱插拔事件。MountService作為Binder服務端,那麼相應的Binder客戶端便是StorageManager,通過binder IPC與MountService交互。
Vold:全稱為Volume Daemon,用於管理外部存儲設備的Native daemon進程,這是一個非常重要的守護進程,主要由NetlinkManager,VolumeManager,CommandListener這3部分組成。
從模塊地角度劃分Android整個存儲架構:
圖解:
uevent
向Vold的NetlinkManager發送Uevent事件;Uevent
事件,再轉發給VolumeManager;socket
通信方式發送給MountService;(1)先看看Java framework層的線程:
root@gityuan:/ # ps -t | grep 1212 system 1212 557 2334024 160340 SyS_epoll_ 7faedddbe4 S system_server system 2662 1212 2334024 160340 SyS_epoll_ 7faedddbe4 S MountService system 2663 1212 2334024 160340 unix_strea 7faedde73c S VoldConnector system 2664 1212 2334024 160340 unix_strea 7faedde73c S CryptdConnector ...
MountService運行在system_server進程,這裡查詢的便是system_server進程的所有子線程,system_server進程承載整個framework所有核心服務,子線程數有很多,這裡只列舉與MountService模塊相關的子線程。
(2)再看看Native層的線程:
root@gityuan:/ # ps -t | grep " 387 " USER PID PPID VSIZE RSS WCHAN PC NAME root 387 1 13572 2912 hrtimer_na 7fa34755d4 S /system/bin/vold root 397 387 13572 2912 poll_sched 7fa3474d1c S vold root 399 387 13572 2912 poll_sched 7fa3474d1c S vold root 400 387 13572 2912 poll_sched 7fa3474d1c S vold media_rw 2702 387 7140 2036 inotify_re 7f84b1d6ac S /system/bin/sdcard
Vold作為native守護進程,進程名為”/system/bin/vold”,pid=387,通過ps -t
可查詢到該進程下所有的子進程/線程。
小技巧:有讀者可能會好奇,為什麼/system/bin/sdcard
是子進程,而非子線程呢?要回答這個問題,有兩個方法,其一就是直接看撸源碼,會發現這是通過fork
方式創建的,而其他子線程都是通過pthread_create
方式創建的。當然其實還有個更快捷的小技巧,就是直接看上圖中的第4列,這一列的含義是VSIZE
,代表的是進程虛擬地址空間大小,是否共享地址空間,這是進程與線程最大的區別,再來看看/sdcard的VSIZE大小跟父進程不一樣,基本可以確實/sdcard是子進程。
(3) 從進程/線程視角來看Android存儲架構:
1個主線程
(system_server) + 3個子線程
(VoldConnector, MountService, CryptdConnector);1個主線程
(/system/bin/vold) + 3個子線程
(vold) + 1子進程
(/system/bin/sdcard);注:圖中紅色字代表的進程/線程名,vold進程通過pthread_create的方式創建的3個子線程名都為vold,圖中只是為了便於區別才標注為vold1, vold2, volD3,其實名稱都為vold。
Android還可劃分為內核空間(Kernel Space)和用戶空間(User space),從上圖可看出,Android存儲系統在User space總共采用9個進程/線程的架構模型。當然,除了這9個進/線程,另外還會在handler消息處理過程中使用到system_server的兩個子線程:android.fg
和android.io
。
Tips: 同一個模塊可以運行在各個不同的進程/線程, 同一個進程可以運行不同模塊的代碼,所以從進程角度和模塊角度劃分看到的有所不同的.
上圖中4個藍色塊便是前面談到的核心模塊。
Android存儲系統中涉及各個進程間通信,這個架構采用的socket,並沒有采用Android binder IPC機制。這樣的架構代碼大量更少,整體架構邏輯也相對簡單,在介紹通信過程前,先來看看MountService對象的實例化過程,那麼也就基本明白進程架構中system_sever進程為了MountService服務而單獨創建與共享使用到線程情況。
public MountService(Context context) { sSelf = this; mContext = context; //FgThread線程名為“"android.fg",創建IMountServiceListener回調方法 mCallbacks = new Callbacks(FgThread.get().getLooper()); //獲取PKMS的Client端對象 mPms = (PackageManagerService) ServiceManager.getService("package"); //創建“MountService”線程 HandlerThread hthread = new HandlerThread(TAG); hthread.start(); mHandler = new MountServiceHandler(hthread.getLooper()); //IoThread線程名為"android.io",創建OBB操作的handler mObbActionHandler = new ObbActionHandler(IoThread.get().getLooper()); File dataDir = Environment.getDataDirectory(); File systemDir = new File(dataDir, "system"); mLastMaintenanceFile = new File(systemDir, LAST_FSTRIM_FILE); //判斷/data/system/last-fstrim文件,不存在則創建,存在則更新最後修改時間 if (!mLastMaintenanceFile.exists()) { (new FileOutputStream(mLastMaintenanceFile)).close(); ... } else { mLastMaintenance = mLastMaintenanceFile.lastModified(); } ... //將MountServiceInternalImpl登記到sLocalServiceObjects LocalServices.addService(MountServiceInternal.class, mMountServiceInternal); //創建用於VoldConnector的NDC對象 mConnector = new NativeDaemonConnector(this, "vold", MAX_CONTAINERS * 2, VOLD_TAG, 25, null); mConnector.setDebug(true); //創建線程名為"VoldConnector"的線程,用於跟vold通信 Thread thread = new Thread(mConnector, VOLD_TAG); thread.start(); //創建用於CryptdConnector工作的NDC對象 mCryptConnector = new NativeDaemonConnector(this, "cryptd", MAX_CONTAINERS * 2, CRYPTD_TAG, 25, null); mCryptConnector.setDebug(true); //創建線程名為"CryptdConnector"的線程,用於加密 Thread crypt_thread = new Thread(mCryptConnector, CRYPTD_TAG); crypt_thread.start(); //注冊監聽用戶添加、刪除的廣播 final IntentFilter userFilter = new IntentFilter(); userFilter.addAction(Intent.ACTION_USER_ADDED); userFilter.addAction(Intent.ACTION_USER_REMOVED); mContext.registerReceiver(mUserReceiver, userFilter, null, mHandler); //內部私有volume的路徑為/data,該volume通過dumpsys mount是不會顯示的 addInternalVolume(); //默認為false if (WATCHDOG_ENABLE) { Watchdog.getInstance().addMonitor(this); } }
其主要功能依次是:
從這裡便可知道共創建了3個線程:MountService
,VoldConnector
,CryptdConnector
,另外還會使用到系統進程中的兩個線程android.fg
和android.io
. 這便是在文章開頭進程架構圖中Java framework層進程的創建情況.
接下來,我們分別從MountService向vold發送消息和接收消息兩個方面,以及Kernel向vold上報事件3個方面展開。
system_server進程與vold守護進程間采用socket進行通信,這個通信過程是由MountService線程向vold線程發送消息。這裡以執行mount調用為例:
class MountService extends IMountService.Stub implements INativeDaemonConnectorCallbacks, Watchdog.Monitor { public void mount(String volId) { ... try { //【見小節2.1.2】 mConnector.execute("volume", "mount", vol.id, vol.mountFlags, vol.mountUserId); } catch (NativeDaemonConnectorException e) { throw e.rethrowAsParcelableException(); } } }
[-> NativeDaemonConnector.java]
public NativeDaemonEvent execute(String cmd, Object... args) throws NativeDaemonConnectorException { return execute(DEFAULT_TIMEOUT, cmd, args); }
其中DEFAULT_TIMEOUT=1min
,即命令執行超時時長為1分鐘。經過層層調用到executeForList()
public NativeDaemonEvent[] executeForList(long timeoutMs, String cmd, Object... args) throws NativeDaemonConnectorException { final long startTime = SystemClock.elapsedRealtime(); final ArrayList<NativeDaemonEvent> events = Lists.newArrayList(); final StringBuilder rawBuilder = new StringBuilder(); final StringBuilder logBuilder = new StringBuilder(); //mSequenceNumber初始化值為0,每執行一次該方法則進行加1操作 final int sequenceNumber = mSequenceNumber.incrementAndGet(); makeCommand(rawBuilder, logBuilder, sequenceNumber, cmd, args); //例如:“3 volume reset” final String rawCmd = rawBuilder.toString(); final String logCmd = logBuilder.toString(); log("SND -> {" + logCmd + "}"); synchronized (mDaemonLock) { //將cmd寫入到socket的輸出流 mOutputStream.write(rawCmd.getBytes(StandardCharsets.UTF_8)); ... } NativeDaemonEvent event = null; do { //阻塞等待,直到收到相應指令的響應碼 event = mResponseQueue.remove(sequenceNumber, timeoutMs, logCmd); events.add(event); //當收到的事件響應碼屬於[100,200)區間,則繼續等待後續事件上報 } while (event.isClassContinue()); final long endTime = SystemClock.elapsedRealtime(); //對於執行時間超過500ms則會記錄到log if (endTime - startTime > WARN_EXECUTE_DELAY_MS) { loge("NDC Command {" + logCmd + "} took too long (" + (endTime - startTime) + "ms)"); } ... return events.toArray(new NativeDaemonEvent[events.size()]); }
3 volume reset
)寫入到socket的輸出流;NDC Command
開頭的log信息,提示可能存在優化之處。MountService線程通過socket發送cmd事件給vold,對於vold守護進程在啟動的過程,初始化CommandListener時通過pthread_create
創建子線程vold來專門監聽MountService發送過來的消息,當該線程接收到socket消息時,便會調用onDataAvailable()方法
[-> FrameworkListener.cpp]
bool FrameworkListener::onDataAvailable(SocketClient *c) { char buffer[CMD_BUF_SIZE]; int len; // 多次嘗試從socket管道讀取數據 len = TEMP_FAILURE_RETRY(read(c->getSocket(), buffer, sizeof(buffer))); ... for (i = 0; i < len; i++) { if (buffer[i] == '\0') { //分發該命令【見小節2.1.4】 dispatchCommand(c, buffer + offset); ... } } return true; }
[-> FrameworkListener.cpp]
void FrameworkListener::dispatchCommand(SocketClient *cli, char *data) { ... for (i = mCommands->begin(); i != mCommands->end(); ++i) { FrameworkCommand *c = *i; if (!strcmp(argv[0], c->getCommand())) { //找到相應的類處理該命令 if (c->runCommand(cli, argc, argv)) { SLOGW("Handler '%s' error (%s)", c->getCommand(), strerror(errno)); } goto out; } } ... }
這是用於分發從MountService發送過來的命令,針對不同的命令調用不同的類,總共有以下6類:
另外,在處理過程中遇到下面情況,則會直接發送響應嗎500的應答消息給MountService
例如前面發送過來的是volume mount
,則會調用到CommandListener的內部類VolumeCmd的runCommand來處理該消息,並進入mount分支。
int CommandListener::VolumeCmd::runCommand(SocketClient *cli, int argc, char **argv) { VolumeManager *vm = VolumeManager::Instance(); std::lock_guard<std::mutex> lock(vm->getLock()); ... std::string cmd(argv[1]); if (cmd == "reset") { return sendGenericOkFail(cli, vm->reset()); }else if (cmd == "mount" && argc > 2) { // mount [volId] [flags] [user] std::string id(argv[2]); auto vol = vm->findVolume(id); if (vol == nullptr) { return cli->sendMsg(ResponseCode::CommandSyntaxError, "Unknown volume", false); } int mountFlags = (argc > 3) ? atoi(argv[3]) : 0; userid_t mountUserId = (argc > 4) ? atoi(argv[4]) : -1; vol->setMountFlags(mountFlags); vol->setMountUserId(mountUserId); //真正的掛載操作【見2.1.6】 int res = vol->mount(); if (mountFlags & android::vold::VolumeBase::MountFlags::kPrimary) { vm->setPrimary(vol); } //發送應答消息給MountService【見2.2.1】 return sendGenericOkFail(cli, res); } // 省略其他的else if ... }
這裡便進入了VolumeManager模塊,執行volume設備真正的掛載操作。對於掛載內置存儲和外置存儲流程是有所不同的,這裡就不再細說,簡單的調用流程:
VolumeCmd.runCommand VolumeBase.mount EmulatedVolume.doMount(內置) PublicVolume.doMount(外置) vfat::Check vfat::Mount fork (/sdcard)
MountService向vold發送消息後,便阻塞在圖中的MountService線程的NDC.execute()方法,那麼何時才會退出呢?圖的後半段MonutService接收消息的過程會有答案,那便是在收到消息,並且消息的響應嗎不屬於區間[600,700)則添加事件到ResponseQueue,從而喚醒阻塞的MountService繼續執行。關於上圖的後半段介紹的便是MountService接收消息的流程。
當Vold在處理完完MountService發送過來的消息後,會通過sendGenericOkFail發送應答消息給上層的MountService。
[-> CommandListener.cpp]
int CommandListener::sendGenericOkFail(SocketClient *cli, int cond) { if (!cond) { //【見小節2.2.2】 return cli->sendMsg(ResponseCode::CommandOkay, "Command succeeded", false); } else { return cli->sendMsg(ResponseCode::OperationFailed, "Command failed", false); } }
不同的響應碼(VoldResponseCode),代表著系統不同的處理結果,主要分為下面幾大類:
例如當操作執行成功,VoldConnector線程能收到類似`RCV <- {200 3 Command succeeded}的響應事件。
其中對於[600,700)響應碼是由Vold進程”不請自來”的事件,主要是針對disk,volume的一系列操作,比如設備創建,狀態、路徑改變,以及文件類型、uid、標簽改變等事件都是底層直接觸發。
介紹完響應碼,接著繼續來說說發送應答消息的過程:
[-> SocketClient.cpp]
int SocketClient::sendMsg(int code, const char *msg, bool addErrno) { return sendMsg(code, msg, addErrno, mUseCmdNum); }
sendMsg經過層層調用,進入sendDataLockedv方法
int SocketClient::sendDataLockedv(struct iovec *iov, int iovcnt) { ... struct sigaction new_action, old_action; memset(&new_action, 0, sizeof(new_action)); new_action.sa_handler = SIG_IGN; sigaction(SIGPIPE, &new_action, &old_action); //將應答消息寫入socket管道 for (;;) { ssize_t rc = TEMP_FAILURE_RETRY( writev(mSocket, iov + current, iovcnt - current)); if (rc > 0) { size_t written = rc; while ((current < iovcnt) && (written >= iov[current].iov_len)) { written -= iov[current].iov_len; current++; } if (current == iovcnt) { break; } iov[current].iov_base = (char *)iov[current].iov_base + written; iov[current].iov_len -= written; continue; } ... break; } sigaction(SIGPIPE, &old_action, &new_action); ... return ret; }
應答消息寫入socket管道後,在MountService的另個線程”VoldConnector”中建立了名為vold
的socket的客戶端,通過循環方式不斷監聽Vold服務端發送過來的消息。
[-> NativeDaemonConnector.java]
private void listenToSocket() throws IOException { LocalSocket socket = null; try { socket = new LocalSocket(); LocalSocketAddress address = determineSocketAddress(); //建立與"/dev/socket/vold"的socket連接 socket.connect(address); InputStream inputStream = socket.getInputStream(); synchronized (mDaemonLock) { mOutputStream = socket.getOutputStream(); } ... while (true) { int count = inputStream.read(buffer, start, BUFFER_SIZE - start); ... for (int i = 0; i < count; i++) { if (buffer[i] == 0) { final String rawEvent = new String( buffer, start, i - start, StandardCharsets.UTF_8); //解析socket服務端發送的event final NativeDaemonEvent event = NativeDaemonEvent.parseRawEvent( rawEvent); log("RCV <- {" + event + "}"); if (event.isClassUnsolicited()) { ... //當響應碼區間為[600,700),則發送消息交由mCallbackHandler處理 if (mCallbackHandler.sendMessage(mCallbackHandler.obtainMessage( event.getCode(), event.getRawEvent()))) { releaseWl = false; } } else { //對於其他響應碼則添加到mResponseQueue隊列 mResponseQueue.add(event.getCmdNumber(), event); } } } } } finally { //收尾清理類工作 ... } }
監聽也是阻塞的過程,當收到不同的消息相應碼,采用不同的行為:
android.fg
發送Handler消息,該線程收到後回調NativeDaemonConnector的handleMessage
來處理。介紹完MonutService與vold之間的交互通信,那麼再來看看Kernel是如何上報事件到vold的流程。再介紹這個之前,先簡單看看vold啟動時都創建了哪些對象。
[-> system/vold/Main.cpp]
int main(int argc, char** argv) { setenv("ANDROID_LOG_TAGS", "*:v", 1); android::base::InitLogging(argv, android::base::LogdLogger(android::base::SYSTEM)); VolumeManager *vm; CommandListener *cl; CryptCommandListener *ccl; NetlinkManager *nm; mkdir("/dev/block/vold", 0755); //用於cryptfs檢查,並mount加密的文件系統 klog_set_level(6); //創建單例對象VolumeManager if (!(vm = VolumeManager::Instance())) { exit(1); } //創建單例對象NetlinkManager if (!(nm = NetlinkManager::Instance())) { exit(1); } if (property_get_bool("vold.debug", false)) { vm->setDebug(true); } // 創建CommandListener對象 cl = new CommandListener(); // 創建CryptCommandListener對象 ccl = new CryptCommandListener(); //給vm設置socket監聽對象 vm->setBroadcaster((SocketListener *) cl); //給nm設置socket監聽對象 nm->setBroadcaster((SocketListener *) cl); if (vm->start()) { //啟動vm exit(1); } process_config(vm); //解析config參數 if (nm->start()) { //啟動nm exit(1); } coldboot("/sys/block"); //啟動響應命令的監聽器 if (cl->startListener()) { exit(1); } if (ccl->startListener()) { exit(1); } //Vold成為監聽線程 while(1) { sleep(1000); } exit(0); }
該方法的主要功能是創建並啟動:VolumeManager,NetlinkManager ,NetlinkHandler,CommandListener,CryptCommandListener。
Kernel上報事件給用戶空間采用了Netlink方式,Netlink是一種特殊的socket,它是Linux所特有的。傳送的消息是暫存在socket接收緩存中,並不被接收者立即處理,所以netlink是一種異步通信機制。而對於syscall和ioctl則都是同步通信機制。
Linux系統中大量采用Netlink機制來進行用戶空間程序與kernel的通信。例如設備熱插件,這會產生Uevent(User Space event,用戶空間事件)是Linux系統中用戶空間與內核空間之間通信的消息內容,主要用於設備驅動的事件通知。Uevent是Kobject的一部分,當Kobject狀態改變時通知用戶空間程序。對於kobject_action包括KOBJ_ADD,KOBJ_REMOVE,KOBJ_CHANGE,KOBJ_MOVE,KOBJ_ONLINE,KOBJ_OFFLINE,當發送任何一種action都會引發Kernel發送Uevent消息。
vold早已准備就緒等待著Kernel上報Uevent事件,接下來看看vold是如何接收Uevent事件,這就從NetlinkManager啟動開始說起。
[-> NetlinkManager.java]
int NetlinkManager::start() { struct sockaddr_nl nladdr; int sz = 64 * 1024; int on = 1; memset(&nladdr, 0, sizeof(nladdr)); nladdr.nl_family = AF_NETLINK; nladdr.nl_pid = getpid(); //記錄當前進程的pid nladdr.nl_groups = 0xffffffff; //PF_NETLINK代表創建的是Netlink通信的socket if ((mSock = socket(PF_NETLINK, SOCK_DGRAM | SOCK_CLOEXEC, NETLINK_KOBJECT_UEVENT)) < 0) { return -1; } //設置uevent的SO_RCVBUFFORCE選項 if (setsockopt(mSock, SOL_SOCKET, SO_RCVBUFFORCE, &sz, sizeof(sz)) < 0) { goto out; } //設置uevent的SO_PASSCRED選項 if (setsockopt(mSock, SOL_SOCKET, SO_PASSCRED, &on, sizeof(on)) < 0) { goto out; } //綁定uevent socket if (bind(mSock, (struct sockaddr *) &nladdr, sizeof(nladdr)) < 0) { goto out; } //創建NetlinkHandler mHandler = new NetlinkHandler(mSock); //啟動NetlinkHandler if (mHandler->start()) { goto out; } return 0; out: close(mSock); return -1; }
NetlinkManager啟動的過程中,會創建並啟動NetlinkHandler,在該過程會通過pthrea_create
創建子線程專門用於接收Kernel發送過程的Uevent事件,當收到數據時會調用NetlinkListener的onDataAvailable方法。
[-> NetlinkListener.cpp]
bool NetlinkListener::onDataAvailable(SocketClient *cli) { int socket = cli->getSocket(); ... //多次嘗試獲取socket數據 count = TEMP_FAILURE_RETRY(uevent_kernel_recv(socket, mBuffer, sizeof(mBuffer), require_group, &uid)); ... NetlinkEvent *evt = new NetlinkEvent(); //解析消息並封裝成NetlinkEvent if (evt->decode(mBuffer, count, mFormat)) { //事件處理【見小節2.3.4】 onEvent(evt); } else if (mFormat != NETLINK_FORMAT_BINARY) { ... } delete evt; return true; }
[-> NetlinkHandler.cpp]
void NetlinkHandler::onEvent(NetlinkEvent *evt) { VolumeManager *vm = VolumeManager::Instance(); const char *subsys = evt->getSubsystem(); if (!strcmp(subsys, "block")) { //對於塊設備的處理過程 vm->handleBlockEvent(evt); } }
驅動設備分為字符設備、塊設備、網絡設備。對於字符設備按照字符流的方式被有序訪問,字符設備也稱為裸設備,可以直接讀取物理磁盤,不經過系統緩存,例如鍵盤直接產生中斷。而塊設備是指系統中能夠隨機(不需要按順序)訪問固定大小數據片(chunks)的設備,例如硬盤;塊設備則是通過系統緩存進行讀取。
[-> VolumeManager.cpp]
void VolumeManager::handleBlockEvent(NetlinkEvent *evt) { std::lock_guard<std::mutex> lock(mLock); std::string eventPath(evt->findParam("DEVPATH")?evt->findParam("DEVPATH"):""); std::string devType(evt->findParam("DEVTYPE")?evt->findParam("DEVTYPE"):""); if (devType != "disk") return; int major = atoi(evt->findParam("MAJOR")); int minor = atoi(evt->findParam("MINOR")); dev_t device = makedev(major, minor); switch (evt->getAction()) { case NetlinkEvent::Action::kAdd: { for (auto source : mDiskSources) { if (source->matches(eventPath)) { int flags = source->getFlags(); if (major == kMajorBlockMmc) { flags |= android::vold::Disk::Flags::kSd; } else { flags |= android::vold::Disk::Flags::kUsb; } auto disk = new android::vold::Disk(eventPath, device, source->getNickname(), flags); //創建 disk->create(); mDisks.push_back(std::shared_ptr<android::vold::Disk>(disk)); break; } } break; } case NetlinkEvent::Action::kChange: { ... break; } case NetlinkEvent::Action::kRemove: { ... break; } ... } }
此處,我們以設備插入為例,來描繪一下整個流程圖:
線程VoldConnector通過socket不斷監聽來自vold發送過來的響應消息:
接下來說說第二種情況,對於不清自來的廣播,這裡的廣播並非四大組件的廣播,而是vold通過socket發送過來的消息。還記得還文章的開頭講到進程架構時,提到會涉及system_server的線程android.fg
,那麼這個過程就會講到該線程的作用。回到NDC的監聽socket過程。
[-> NativeDaemonConnector.java]
private void listenToSocket() throws IOException { LocalSocket socket = null; try { socket = new LocalSocket(); LocalSocketAddress address = determineSocketAddress(); //建立與"/dev/socket/vold"的socket連接 socket.connect(address); InputStream inputStream = socket.getInputStream(); synchronized (mDaemonLock) { mOutputStream = socket.getOutputStream(); } ... while (true) { int count = inputStream.read(buffer, start, BUFFER_SIZE - start); ... for (int i = 0; i < count; i++) { if (buffer[i] == 0) { final String rawEvent = new String( buffer, start, i - start, StandardCharsets.UTF_8); //解析socket服務端發送的event final NativeDaemonEvent event = NativeDaemonEvent.parseRawEvent( rawEvent); log("RCV <- {" + event + "}"); if (event.isClassUnsolicited()) { ... //當響應碼區間為[600,700),則發送消息交由mCallbackHandler處理【2.4.2】 if (mCallbackHandler.sendMessage(mCallbackHandler.obtainMessage( event.getCode(), event.getRawEvent()))) { releaseWl = false; } } else { //對於其他響應碼則添加到mResponseQueue隊列 mResponseQueue.add(event.getCmdNumber(), event); } } } } } finally { //收尾清理類工作 ... } }
通過handler消息機制,由mCallbackHandler處理,先來看看其初始化過程:
mCallbackHandler = new Handler(mLooper, this); Looper=`FgThread.get().getLooper();
可以看出Looper采用的是線程android.fg
的Looper,消息回調處理方法為NativeDaemonConnector的handleMessage
來處理。那麼這個過程就等價於向線程android.fg
發送Handler消息,該線程收到消息後回調NativeDaemonConnector的handleMessage
來處理。
[-> NativeDaemonConnector.java]
public boolean handleMessage(Message msg) { String event = (String) msg.obj; ... mCallbacks.onEvent(msg.what, event, NativeDaemonEvent.unescapeArgs(event)) log(String.format("Unhandled event '%s'", event)); ... return true; }
此處的mCallbacks,是由實例化NativeDaemonConnector對象時傳遞進來的,在這裡是指MountService。轉了一圈,又回到MountService。
[-> MountService.java]
public boolean onEvent(int code, String raw, String[] cooked) { synchronized (mLock) { return onEventLocked(code, raw, cooked); } }
onEventLocked增加同步鎖,用於多線程並發訪問的控制。根據vold發送過來的不同響應碼將采取不同的處理流程。
這裡以收到vold發送過來的RCV <- {650 public ...}
為例,即掛載外置sdcard/otg外置存儲的流程:
[-> MountService.java]
private boolean onEventLocked(int code, String raw, String[] cooked) { switch (code) { case VoldResponseCode.VOLUME_CREATED: { final String id = cooked[1]; final int type = Integer.parseInt(cooked[2]); final String diskId = TextUtils.nullIfEmpty(cooked[3]); final String partGuid = TextUtils.nullIfEmpty(cooked[4]); final DiskInfo disk = mDisks.get(diskId); final VolumeInfo vol = new VolumeInfo(id, type, disk, partGuid); mVolumes.put(id, vol); //【見小節2.4.5】 onVolumeCreatedLocked(vol); break; } ... } return true; }
[-> MountService.java]
private void onVolumeCreatedLocked(VolumeInfo vol) { if (vol.type == VolumeInfo.TYPE_EMULATED) { ... } else if (vol.type == VolumeInfo.TYPE_PUBLIC) { if (Objects.equals(StorageManager.UUID_PRIMARY_PHYSICAL, mPrimaryStorageUuid) && vol.disk.isDefaultPrimary()) { vol.mountFlags |= VolumeInfo.MOUNT_FLAG_PRIMARY; vol.mountFlags |= VolumeInfo.MOUNT_FLAG_VISIBLE; } if (vol.disk.isAdoptable()) { vol.mountFlags |= VolumeInfo.MOUNT_FLAG_VISIBLE; } vol.mountUserId = UserHandle.USER_OWNER; //【見小節2.4.6】 mHandler.obtainMessage(H_VOLUME_MOUNT, vol).sendToTarget(); } }
這裡又遇到一個Handler類型的對象mHandler
,再來看看其定義:
private static final String TAG = "MountService"; HandlerThread hthread = new HandlerThread(TAG); hthread.start(); mHandler = new MountServiceHandler(hthread.getLooper());
該Handler用到Looper便是線程MountService
中的Looper,回調方法handleMessage位於MountServiceHandler類:
[-> MountService]
class MountServiceHandler extends Handler { public void handleMessage(Message msg) { switch (msg.what) { case H_VOLUME_MOUNT: { final VolumeInfo vol = (VolumeInfo) msg.obj; try { //發送mount操作 mConnector.execute("volume", "mount", vol.id, vol.mountFlags, vol.mountUserId); } catch (NativeDaemonConnectorException ignored) { } break; } ... } } }
當收到H_VOLUME_MOUNT消息後,線程MountService
便開始向vold發送mount操作事件,再接下來的流程在前面小節【2.1】已經介紹過
本文首先從模塊化和進程的視角來整體上描述了Android存儲系統的架構,並分別展開對MountService, vold, kernel這三者之間的通信流程的剖析。
{1}Java framework層:采用 1個主線程
(system_server) + 3個子線程
(VoldConnector, MountService, CryptdConnector);MountService線程不斷向vold下發存儲相關的命令,比如mount, mkdirs等操作;而線程VoldConnector一直處於等待接收vold發送過來的應答事件;CryptdConnector通信原理和VoldConnector大抵相同,有興趣地讀者可自行閱讀。
(2)Native層:采用 1個主線程
(/system/bin/vold) + 3個子線程
(vold) + 1子進程
(/system/bin/sdcard);vold進程中會通過pthread_create
方式來生成3個vold子線程,其中兩個vold線程分別跟上層system_server進程中的線程VoldConnector和CryptdConnector通信,第3個vold線程用於與kernel進行netlink方式通信。
本文更多的是以系統的角度來分析存儲系統,那麼對於app來說,那麼地方會直接用到的呢?其實用到的地方很多,例如存儲設備掛載成功會發送廣播讓app知曉當前存儲掛載情況;其次當app需要創建目錄時,比如getExternalFilesDirs
, getExternalCacheDirs
等當目錄不存在時都需向存儲系統發出mkdirs的命令。另外,MountService作為Binder服務端,那自然而然會有Binder客戶端,那就是StorageManager
,這個比較簡單就不再細說了。
以Google原生的Android存儲系統的架構設計主要采用Socket阻塞式通信方式,雖然vold的native層面有多個子線程干活,但各司其職,真正處理上層發送過來的命令,仍然是單通道的模式。
目前外置存儲設備比如sdcard或者otg的硬件質量參差不齊,且隨使用時間碎片化程度也越來越嚴重,對於存儲設備掛載的過程中往往會有磁盤檢測fsck_msdos或者整理fstrim的動作,那麼勢必會阻塞多線程並發訪問,影響系統穩定性,從而造成系統ANR。
例如系統剛啟動過程中reset操作需要重新掛載外置存儲設備,而緊接著system_server主線程需要執行的volume user_started操作便會被阻塞,阻塞超過20s則系統會拋出Service Timeout的ANR。
寫在前面 最近一直在做畢設項目的准備工作,考慮到可能要用到一個模糊的效果,所以就學習了一些高斯模糊效果的實現。比較有名的就是 FastBlur 以及它衍生的一些優
在Android1.6的模擬器裡面預裝了一個叫Gestures Builder的程序,這個程序就是讓你創建自己的手勢的(Gestures Builder的源代碼在
我相信每一個安卓開發者都會同意 2015年安卓開發者大會上宣布的最大事情就是 Android Studio 2.0和安卓模擬器2.0,其中安卓模擬器2.0宣稱運行
1 背景 在Android中任何耗時的操作都不能放在UI主線程中,所以耗時的操作都需要使用異步實現。同樣的,在ContentProvider中也可能存在耗時操作,