經過兩年的時間，終于完成對Android系統的研究了。Android是一個博大精深的系統，老羅不敢說自己精通了（事實上最讨厭的就是說自己精通神馬神馬的了，或者說企業說要招聘精通神馬神馬的人才），但是至少可以說打通了整個Android系統，從最上面的應用層，一直到最下面的Linux核心，煉就的是一種内功修養。這篇文章和大家一起分享這兩年研究Android系統的曆程，以此感謝大家一直以來的支援和鼓勵。
《Android系統源代碼情景分析》一書正在進擊的程式員網（http://0xcc0xcd.com）中連載，點選進入！
以下是本文的提綱：
1. 理念
2. 裡程碑
3. 看過的書
4. 研究過的内容
5. 将來要做的事情
它們涵蓋了老羅這兩年一直想要和大家分享的内容。好了，不說廢話了，直入主題。
一. 理念
這裡說的理念是說應該帶什麼樣的心态去研究一個系統。古人說書中自的顔如玉，書中自有黃金屋，我想說代碼裡也有顔如玉和黃金屋，是以老羅希望大家都能“Read The Fucking Source Code”。再者，對于優秀的開源項目來說，不去讀一下它的源代碼，簡直就是暴殄天物啊。那麼，讀代碼有什麼好處呢？太多了，除了可以學到别人的優秀代碼、架構之外，最重要的是，我們能從中找到答案，進而可以解決自己項目上的燃眉之急。
我們在項目中碰到問題的時候，通常第一反應都是到網上去搜尋答案。但是有時候有些問題，網絡并不能給出滿意的答案。這時候就千萬不要忘了你所擁有的一個大招——從代碼中找答案！當然，從代碼中找答案說起來是輕松，但是等到直正去找時，可能就會發現雲裡霧裡，根本不知道那些代碼在說什麼東東，甚至連自己想要看的源代碼檔案都不知道在哪裡。這就要求平時就要養成讀代碼的習慣，不要臨時抱佛腳。有時候臨時抱佛腳是能解決問題，但是千萬不能抱着這種僥幸心裡，掌握一門技術還是需要踏踏實實地一步一步走。
胡克其實在牛頓之前，就發現了萬有引力定律，并且推導出了正确的公式。但由于數學不好，他隻能勉強解釋行星繞日的圓周運動，而沒有認識到支配天體運作的力量是“萬有”的。後來數學狂人牛頓用微積分圓滿地解決了胡克的問題，并且把他提出的力學三條基本定律推廣到了星系空間，改變了自從亞裡士多德以來公認的天地不一的舊觀點，被科學界奉為偉大的發現。胡克大怒，指責牛頓剽竊了他的成果。牛頓尖酸刻薄的回敬：是啊，我他媽還真是站在巨人的肩膀上呢！
我們有理由相信像牛頓、喬布斯之類的狂人，不用站在巨人的肩膀上也能取得矚目的成就。但是，我們不是牛頓，也不是喬布斯，是以在看代碼之前，還是找一些前人總結的資料來看看吧。拿Android系統來說，你在至少得懂點Linux核心基礎吧！是以在看Android源代碼之前，先找些Linux核心的經典書籍來看看吧，騷年！後面老羅會推薦一些書籍給大家。
另外，我們知道，現在的網際網路産品，講究的是快速疊代。Android系統自第一個版本釋出以來，到現在已經經曆了很多版本呢？那麼我們應該如何去選擇版本來閱讀呢？一般來說，就是選擇最新的版本來閱讀了。不過随着又有新版本的源代碼的釋出，我們所看的源代碼就會變成舊版本。這時候心裡就會比較糾結：是應該繼續看舊的代碼，還是去追新版本的代碼呢？就當是看連續劇，一下子跳到前面去，可能就不知道講什麼了。其實版本就算更新得再快，基礎的東西也是不會輕易變化的。我們看代碼時，要抱着的一個目的就是弄懂它的骨架和脈絡。畢竟對于一個系統來說，它是有很多細節的，我們無法在短時間把它們都完全吃透。但是主要我們掌握了它的骨架和脈絡，以後無論是要了解它的什麼細節，都可以很輕輕地找到相關的源檔案，并且可以很容易進入主題。
坦白說，對于Android系統，很多細節我也不了解。是以有時候你們可以看到，在部落格文章後面的評論上，有些同學問的一些比較具體的問題，我是沒有回複的。一來是我不懂，二來是我也沒有時間去幫這些同學去扒代碼來看。這也是在文章一開頭，我就說自己沒有精通Android系統的原因。但是請相信，主要你熟悉Android系統的代碼，并且有出現問題的現場，順藤摸瓜跟着代碼走下去，并且多一點耐心和細心，是可以解決問題的！
關于Android版本的問題，相信大家都知道我現在的文章都是基于2.3來寫的。很多同學都說我out了，現在都4.2了，甚至4.3或者5.0都要出來了，還在看2.3。我想說的是，主要你掌握了它的骨架和脈絡，無論版本上怎麼變化，原理都是一樣的，這就是以不變應萬變之道。是以，我就一直堅持研究2.3，這樣可以使得前前後後研究的東西更連貫一緻，避免分散了自己的精力。如果還有疑問的話，後面我講到Android的UI架構時，就會簡單對比一下4.2和2.3的不同，其實就會發現，基本原理還是一樣的！
說到Android系統的骨架和脈絡，也有同學抱怨我的文章裡面太多代碼細節了，他們希望我可以抽象一下，用高度概括的語言或者圖像來勾勒出每一個子產品的輪廓。我想說的是，如果你不看代碼，不了解細節，即使我能夠用概括的語言或者圖像來勾勒出這樣的輪廓出來，也許這個輪廓隻有我才能看得懂。
我在真正開始看Android系統的源代碼之前，也是有這樣的想法，希望能有一張圖來清楚地告訴我Android系統的輪廓，例如，HAL為什麼要将驅動劃分成使用者空間和核心空間兩部分，為什麼說Binder是所有IPC機制效率最高的。我确實是從網上得到抽象的資料來解釋這兩個問題，但是這些資料對我來說，還是太抽象了，以至于我有似懂非懂的感覺，實際上就是不懂！就是因為這樣，激發了我要從代碼中找答案的念頭！現在當我回過頭來這些所謂抽象的輪廓時，我就清楚地知道它講的是什麼了。
是以古人雲“天将降大任于斯人也，必先苦其心志，勞其筋骨，餓其體膚”是有道理的，因為隻有親身經曆過一些磨難後得到的東西才是真實的！
好了，關于理念的問題，就完了，這裡再做一下總結：
1. 從代碼中找答案——Read The Fucking Source Code。
2. 以不變應萬變——堅持看一個版本的代碼直至理清它的骨架和脈絡。
二. 裡程碑
研究Android 2.3期間，主要是經曆了以下五個時間點，如圖1所示：
圖1 研究Android 2.3的裡程碑
從2011年06月21日第一篇部落格文章開始，到2013年06月03日結束對Android 2.3的研究，一共是差不多兩年的時間，一個從無到有的過程。其中，最痛苦的莫過于是2011年12月下旬到2012年06月12日這6個多月的時間裡面，整理了2011年12月下旬前的所有部落格文章，形成了《Android系統源代碼情景分析》一書，并且最終在2012年10月下旬正式上市。
總的來說，就是在兩年的時間裡面，獲得了以下的兩個産出：
1. 《老羅的Android之旅》部落格專欄93篇文章，1857224次通路，4156條評論，13440積分，排名154。
2. 《Android系統源代碼情景分析》一書3大篇16章，830頁，1570000字。
以上産出除了能幫助到廣大的網友之外，也讓自己理清了Android系統的骨架和脈絡。這些骨架和脈絡接下來再總結。2013年06月03日之後，将何去何從？接下來老羅也會簡單說明。
三. 看過的書
在2011年06月21日開始寫部落格之前，其實已經看過不少的書。在2011年06月21日之後，也一邊寫部落格一邊看過不少的書。這個書單很長，下面我主要分類列出一些主要的和經典的。
語言：
《深度探索C++對象模型》，對應的英文版是《Inside C+++ Object Model》
程式編譯、連結、加載：
《連結器和加載器》，對應的英文版是《Linker and Loader》
《程式員的自我修養：連結、裝載和庫》
作業系統：
《Linux核心設計與實作》，對應的英文版是《Linux Kernel Development》
《深入了解Linux核心》，對應的英文版是《Understanding the Linux Kernel》
《深入Linux核心架構》，對應的英文版是《Professional Linux Kernel Architecture》
《Linux核心源代碼情景分析》
網絡：
《Linux網絡體系結構：Linux核心中網絡協定的設計與實作》，對應的英文版是《The Linux Networking Architecture: Design and Implementation of Network Protocols in the Linux Kernel》
《深入了解LINUX網絡技術内幕》，對應的英文版是《 Understanding Linux Network Internals》
裝置驅動：
《Linux裝置驅動程式》，對應的英文版是《Linux Device Drivers》
《精通Linux裝置驅動程式開發》，對應的英文版是《Essential Linux Device Drivers》
虛拟機：
《Java SE 7虛拟機規範》
《深入Java虛拟機》，對應的英文版是《Inside the Java Virtual Machine》
《Oracle JRockit: The Definitive Guide》
嵌入式：
《嵌入式Linux開發》，對應的英文版是《Embedded Linux Primer》
《建構嵌入式Linux系統》，對應的英文版是《Building Embedded Linux Systems》
ARM體系架構：
《ARM嵌入式系統開發：軟體設計與優化》，對應的英文版是《ARM System Developer's Guide: Designing and Optimizing System Software》
綜合：
《深入了解計算機系統》，對應的英文版是《Computer Systems: A Programmer's Perspective》
上面介紹的這些書，都是屬于進階級别的，是以要求要有一定的語言基礎以及作業系統基礎。此外，對于看書，老羅有一些觀點，供大家參考：
1. 書不是要用的時候才去看的，要養成經常看書、終身學習的習慣。
2. 不要隻看與目前自己工作相關的書，IT技術日新月異，三五年河東，三五年河西。
3. 書看得多了，就會越看越快，學習新的東西時也越容易進入狀态。
對于Android應用開發，力推官方文檔：
http://developer.android.com/training/index.html
http://developer.android.com/guide/components/index.html
http://developer.android.com/tools/index.html
四. 研究過的内容
整個部落格的内容看似松散，實際上都是有組織有計劃的，目标是打通整個Android系統，從最上面的應用層，到最下面的Linux核心層。簡單來說，部落格的所有文章可以劃分為“三橫三縱”，如圖2所示：
圖2 Android系統研究之“三橫三縱”
接下來，老羅就分别描述這三條橫線和縱線，并且給出對應的部落格文章連結。
1. 準備 -- Preparation -- 橫線
主要就是：
（1）通過閱讀相關的書籍來了解Linux核心和Android應用基礎知識
Android學習啟動篇
（2）搭建好Android源代碼環境
在Ubuntu上下載下傳、編譯和安裝Android最新源代碼
在Ubuntu上下載下傳、編譯和安裝Android最新核心源代碼（Linux Kernel）
如何單獨編譯Android源代碼中的子產品
制作可獨立分發的Android模拟器
（3）Android系統有很多C++代碼，這些C++代碼用到了很多智能指針，是以有必要了解一下Android系統在C/C++ Runtime Framework中提供的智能指針
Android系統的智能指針（輕量級指針、強指針和弱指針）的實作原理分析
2. 專用驅動 -- Proprietary Drivers -- 橫線
這些專用驅動就是指Logger、Binder和Ashmem，它們整個Android系統的基石：
（1）Logger
淺談Android系統開發中LOG的使用
Android日志系統驅動程式Logger源代碼分析
Android應用程式架構層和系統運作庫層日志系統源代碼分析
Android日志系統Logcat源代碼簡要分析
（2）Binder
Android程序間通信（IPC）機制Binder簡要介紹和學習計劃
淺談Service Manager成為Android程序間通信（IPC）機制Binder守護程序之路
淺談Android系統程序間通信（IPC）機制Binder中的Server和Client獲得Service Manager接口之路
Android系統程序間通信（IPC）機制Binder中的Server啟動過程源代碼分析
Android系統程序間通信（IPC）機制Binder中的Client獲得Server遠端接口過程源代碼分析
Android系統程序間通信Binder機制在應用程式架構層的Java接口源代碼分析
（3）Ashmem
Android系統匿名共享記憶體Ashmem（Anonymous Shared Memory）簡要介紹和學習計劃
Android系統匿名共享記憶體Ashmem（Anonymous Shared Memory）驅動程式源代碼分析
Android系統匿名共享記憶體Ashmem（Anonymous Shared Memory）在程序間共享的原理分析
Android系統匿名共享記憶體（Anonymous Shared Memory）C++調用接口分析
3. 硬體抽象層 -- HAL -- 縱線
硬體抽層象最适合用作Android系統的學習入口，它從下到上涉及到了Android系統的各個層次：
Android硬體抽象層（HAL）概要介紹和學習計劃
在Ubuntu上為Android系統編寫Linux核心驅動程式
在Ubuntu上為Android系統内置C可執行程式測試Linux核心驅動程式
在Ubuntu上為Android增加硬體抽象層（HAL）子產品通路Linux核心驅動程式
在Ubuntu為Android硬體抽象層（HAL）子產品編寫JNI方法提供Java通路硬體服務接口
在Ubuntu上為Android系統的Application Frameworks層增加硬體通路服務
在Ubuntu上為Android系統内置Java應用程式測試Application Frameworks層的硬體服務
4. 應用程式元件 -- Application Component -- 縱線
應用程式元件是Android系統的核心，為開發者提供了貼心的服務。應用程式元件有四種，分别是Activity、Service、Broadcast Receiver和Content Provider。圍繞應用程式元件，又有應用程式程序、消息循環和安裝三個相關子產品。
（1）Activity
Android應用程式的Activity啟動過程簡要介紹和學習計劃
Android應用程式啟動過程源代碼分析
Android應用程式内部啟動Activity過程（startActivity）的源代碼分析
Android應用程式在新的程序中啟動新的Activity的方法和過程分析
解開Android應用程式元件Activity的"singleTask"之謎
（2）Service
Android系統在新程序中啟動自定義服務過程（startService）的原理分析
Android應用程式綁定服務（bindService）的過程源代碼分析
（3）Broadcast Receiver
Android系統中的廣播（Broadcast）機制簡要介紹和學習計劃
Android應用程式注冊廣播接收器（registerReceiver）的過程分析
Android應用程式發送廣播（sendBroadcast）的過程分析
（4）Content Provider
Android應用程式元件Content Provider簡要介紹和學習計劃
Android應用程式元件Content Provider應用執行個體
Android應用程式元件Content Provider的啟動過程源代碼分析
Android應用程式元件Content Provider在應用程式之間共享資料的原理分析
Android應用程式元件Content Provider的共享資料更新通知機制分析
（5）程序
Android系統程序Zygote啟動過程的源代碼分析
Android應用程式程序啟動過程的源代碼分析
（6）消息循環
Android應用程式消息處理機制（Looper、Handler）分析
Android應用程式鍵盤（Keyboard）消息處理機制分析
Android應用程式線程消息循環模型分析
（7）安裝
Android應用程式安裝過程源代碼分析
Android系統預設Home應用程式（Launcher）的啟動過程源代碼分析
5. 使用者界面架構 -- UI -- 縱線
大家對老羅現在還在寫Android 2.3的UI架構意見最大，認為已經過時了。老羅認為持有這種觀點的人，都是沒有經過認真思考的。老羅承認，從Android 4.0開始，UI部分發生了比較大的變化。但是請注意，這些變化都是在Android 2.3的UI架構基礎之上進行的，也就是說，Android 2.3的UI架構并沒有過時。你不能說Android 4.0在Android 2.3之上增加了一些feature，就說Android 2.3過時了。
下面這張是從Android官網拿過來的最新UI渲染流程圖，也就是4.2的UI渲染流程圖：
圖2 Android 4.2的UI渲染流程
從這張圖可以看出關于Android的UI架構的三條主線：
（1）每一個Window的Surface都怎樣渲染的？不管怎麼樣，最後渲染出來的都是一個Buffer，交給SurfaceFlinger合成到Display上。
（2）SurfaceFlinger是怎樣合成每一個Window的Surface的？
（3）WindowManamgerService是怎麼樣管理Window的？
第（1）和第（2）兩個點在2.3和4.2之間有變化，主要是因為增加了GPU的支援，具體就表現為Window的Surface在渲染的時候使用了GPU，而SurfaceFlinger在合成每一個Window的Surface的時候，也使用了GPU或者Overlay和Blitter這些硬體加速，但是主體流程都沒有變，也就是說，Window的Surface渲染好之後，最終依然是交給SurfaceFlinger來合成。此外，雖然我還沒有開始看4.2的代碼，但是可以看得出，4.2裡面的HWComposer，隻不過是封裝和抽象了2.3就有的Overlay和Blitter，而SurfaceTexture的作用與2.3的SurfaceComposerClient、SurfaceControl也是類似的。第（3）點基本上就沒有什麼變化，除非以後要支援多視窗。
通過上述對比，隻想強調一點：Android 2.3的UI架構并沒有過時，是值得去研究的，并且在2.3的基礎上去研究4.2的UI架構，會更有幫助。
仁者見仁，智者見智，Android 2.3的UI架構的說明就到此為止，接下來它的分析路線，都是圍繞上述三個點來進行的。
首先是以開機動畫為切入點，了解Linux核心裡面的驅動：
Android系統的開機畫面顯示過程分析
FB驅動抽象了顯示卡，上面的使用者空間程式就是通過它來顯示UI的。
HAL層的Gralloc子產品對FB驅動進行了封裝，以友善SurfaceFlinger對它進行通路：
Android幀緩沖區（Frame Buffer）硬體抽象層（HAL）子產品Gralloc的實作原理分析
SurfaceFlinger負責合成各個應用程式視窗的UI，也就是将各個視窗的UI合成，并且通過FB顯示在螢幕上。在對SurfaceFlinger進行分析之前，我們首先了解應用程式是如何使用的它的：
Android應用程式與SurfaceFlinger服務的關系概述和學習計劃
Android應用程式與SurfaceFlinger服務的連接配接過程分析
Android應用程式與SurfaceFlinger服務之間的共享UI中繼資料（SharedClient）的建立過程分析
Android應用程式請求SurfaceFlinger服務建立Surface的過程分析
Android應用程式請求SurfaceFlinger服務渲染Surface的過程分析
萬事俱備，可以開始分析SurfaceFlinger了：
Android系統Surface機制的SurfaceFlinger服務簡要介紹和學習計劃
Android系統Surface機制的SurfaceFlinger服務的啟動過程分析
Android系統Surface機制的SurfaceFlinger服務對幀緩沖區（Frame Buffer）的管理分析
Android系統Surface機制的SurfaceFlinger服務的線程模型分析
Android系統Surface機制的SurfaceFlinger服務渲染應用程式UI的過程分析
SurfaceFlinger操作的對象是應用程式視窗，是以，我們要掌握應用程式視窗的組成：
Android應用程式視窗（Activity）實作架構簡要介紹和學習計劃
Android應用程式視窗（Activity）的運作上下文環境（Context）的建立過程分析
Android應用程式視窗（Activity）的視窗對象（Window）的建立過程分析
Android應用程式視窗（Activity）的視圖對象（View）的建立過程分析
Android應用程式視窗（Activity）與WindowManagerService服務的連接配接過程分析
Android應用程式視窗（Activity）的繪圖表面（Surface）的建立過程分析
Android應用程式視窗（Activity）的測量（Measure）、布局（Layout）和繪制（Draw）過程分析
應用程式視窗是由WindowManagerService進行管理的，并且也是WindowManagerService負責提供視窗資訊給SurfaceFlinger的，是以，我們最後分析WindowManagerService：
Android視窗管理服務WindowManagerService的簡要介紹和學習計劃
Android視窗管理服務WindowManagerService計算Activity視窗大小的過程分析
Android視窗管理服務WindowManagerService對視窗的組織方式分析
Android視窗管理服務WindowManagerService對輸入法視窗（Input Method Window）的管理分析
Android視窗管理服務WindowManagerService對桌面視窗（Wallpaper Window）的管理分析
Android視窗管理服務WindowManagerService計算視窗Z軸位置的過程分析
Android視窗管理服務WindowManagerService顯示Activity元件的啟動視窗（Starting Window）的過程分析
Android視窗管理服務WindowManagerService切換Activity視窗（App Transition）的過程分析
Android視窗管理服務WindowManagerService顯示視窗動畫的原理分析
上述内容都研究清楚之後，Android系統的UI架構的骨架就清晰了。但是前面所研究的應用程式視窗還是太抽象了，我們有必要研究一下那些組成應用程式視窗内容的UI控件是怎麼實作的，以TextView和SurfaceView為代表：
Android控件TextView的實作原理分析
Android視圖SurfaceView的實作原理分析
最後，分析Android系統的UI架構，怎能不提它的資源管理架構？它有效地分離了代碼和UI：
Android資源管理架構（Asset Manager）簡要介紹和學習計劃
Android應用程式資源的編譯和打包過程分析
Android應用程式資料總管（Asset Manager）的建立過程分析
Android應用程式資源的查找過程分析
分析這裡，Android系統的UI架構就分析完成了，看出什麼門道來沒有？是的，我們以開機動畫為切入點，從Linux核心空間的FB驅動，一直分析到使用者空間中HAL層子產品Gralloc、C/C++ Runtime Framework層的SurfaceFlinger、Java Runtime Framework層的WindowMangerService、Window、Widget，以及資源管理架構，從下到上，披荊斬棘。
6. Dalvik虛拟機 -- 橫線
Android系統的應用程式及部分應用程式架構是使用Java語言開發的，它們運作在Dalvik虛拟機之上，還有另外一部分應用唾棄架構在使用C/C++語言開發的。使用Java語言開發的應用程式架構老羅稱之為Java Runtime Framework，而使用C/C++語言開發的應用程式架構老羅稱之為C/C++ Runtime Framework，它們被Dalvik虛拟機一分為二。通過前面的學習，其實我們都已經了解Android系統的Java Runtime Framework和C/C++ Runtime Framework，是以，我們最後将注意力集中在Dalvik虛拟機上：
Dalvik虛拟機簡要介紹和學習計劃
Dalvik虛拟機的啟動過程分析
Dalvik虛拟機的運作過程分析
Dalvik虛拟機JNI方法的注冊過程分析
Dalvik虛拟機程序和線程的建立過程分析
學習完成“三橫三縱”這六條主線之後，我們就可以自豪地說，從上到下地把Android系統打通，并且将它的骨架和脈絡也理清了！
對于“準備”、“專用驅動”、“HAL”、“應用程式元件”這四條主線，老羅極力推薦大家看《Android系統源代碼情況分析》一書，内容比部落格文章要系統、詳細很多，不說其它的，就單單是講Binder程序間通信機制的那一章，就物超所值。在《Android系統源代碼情景分析》一書中，老羅最引以為豪的就是講Binder程序間通信機制的第5章，網上或者其它書上絕對是找不到這麼詳盡的分析資料。
五. 将來要做的事情
接下來要做的主要是三件事情：
1. 繼續研究Android系統
本來以為前段時間的Google I/O會釋出Android 4.3或者5.0，然後老羅就以最新釋出的版本為藍本來進行研究。既然沒有釋出新版本，那麼就隻有以現在的最新釋出版本4.2為藍本進行研究了。如前所述，4.2與2.3相比，最大的不同之處是預設增加了GPU支援，是以，老羅在接下來的一段時間裡，将着重研究4.2的GPU支援。
2. 停止部落格更新
這兩年投入在部落格上的精力太多了，部落格上的文章基本上熬夜熬出來的。大多數時候，一個話題要花一個星期左右的時間來看代碼，然後再花四個星期左右的時間将文章寫出來。本來是這樣計劃的，依靠《Android系統源代碼情景分析》一書的銷量，可以在經濟上得到一定的回報，然後可以繼續在部落格上投入，直至把4.x版本的GPU支援寫完，最後再整理出一本關于Android系統UI架構的書。但是最近詢問了一下書的銷量，差強人意，達不到預期目标。由于沒有形成良性循環，是以沒有辦法，隻好停止部落格更新。老羅需要把精力投入在其它事情上，希望大家諒解！
3. 仍然會持續地進行一些小分享
主要是一些随筆分享，這些分享主要會釋出在微網誌或者QQ群上面，那裡也友善一些和大家進行讨論。此外，老羅也樂意和大家進行一些線下分享，主要針對企業或者機關組織的沙龍、活動和會議等，同時也可以單獨地針對企業内部進行分享。不過前提當然是舉辦方對《老羅的Android之旅》專欄或者《Android系統源代碼情景分析》一書的内容感興趣，并且邀請老羅去參加。
如果需要邀請老羅去參加分享，可以通過微網誌或者郵箱和老羅聯系，非常感謝大家兩年以來的支援！
郵箱：[email protected]
微網誌：http://weibo.com/shengyangluo