2017/4/24(周一):
- 從上周到今天一直在浙江呆著，做一些基礎性的研究。下午終于回上海了
2017/4/25(周二)
花了一整天的時間，了解ndk cmake系統，終于編譯通過nanovg庫，在android平臺上順暢的運行。在所有平臺中，android是最麻煩的(對c/c++跨平臺開發來說)，ios/windows/linux上都是非常方便的。關于這部分內容，我這兩天弄個屏幕錄像，記錄一下。
(主要的時間是花在了gradle ndk的鏈接上了，一直編譯通不過，主要原因是鏈接問題，然后gradle如何鏈接，花了兩個小時。程序很多問題，沒解決時候，花費大量時間。一旦解決問題，回過頭去看看，真是好簡單！)android的C/C++編譯系統一直在更換，而且每次升級都有很大變化。以前的東西，現在都不行了，android就是不斷創新，不斷學習下的過程
一直在尋找一個跨平臺，高效，基于opengl，抗鋸齒并且最好類似canvas2D風格的2D渲染庫。前個禮拜測試了cairo和skia，一個效率太差，一個實在太龐大了，而nanovg的確是最好的選擇了。一共6個文件，編譯后庫極小。當然nanovg也是存在一些問題的，但是代碼不多，可以按需修改。這就是開源的魅力所在。
說實話，android studio 2.2（目前我使用的就是2.2）開始，對C/C++的支持已經很不錯了(對2.2之前而言)。其中最關鍵的一個改進（對我來說）是LLDB的debug功能。在2.2以前，c/c++的debug基本沒法用。而2.2以及以后，C/C++斷點非常棒，而且和java的斷點可以兼容，多好的改進啊！
測試了簡書的視頻功能，該視頻是一個3D和2D結合的Demo,以前為公司寫的3D UI引擎，整個渲染來說，極其流暢。在12年時候，每秒可以達到800幀以上的刷新速度，并且cpu占用率基本保持在1%以內，最高不超過5%。當時是為了滿足華為一個項目的要求，所以解決了他們提出來的很多要求。可是花了很大的力氣和精力。
3D_Iphone4_Demo
2017/4/26(周三)
今天要實現android opengles native開發的框架，記錄一下流程吧
感覺Android開發比IOS開發有趣很多，因為從難度上看(至少從與C/C++的協作上來看)，的確是要大很多，不過也正是如此，才充滿樂趣！
android中Surface/SurfaceTexture/TextureView/SurfaceView/GLSurfaceView/SurfaceHolder/SurfaceHolder.Callback/SufraceHolder.Callback2之間的關系
目前看來GLSurfaceView更好用，TextureView盡管有蠻多好處，但當前決定還是使用GLSurfaceView，因為封裝的好，而且支持被動的按需刷新，而不是主動垂直同步刷新。
實現GLSurfaceView.EGLConfigChooser接口
實現GLSurfaceView.EGLContextFactory接口
實現GLSurfaceView.Renderer接口
實現GL2View類
編譯C++ nanovg庫
測試demo
下一步要對GLSurfaceView以及TextureView多一些了解。他們之間的區別，優缺點，以及如何共享同一個GLContext情況下，多個GLSurfaceView共存等
順滑流暢程度還是非常不錯的
2017/4/27(周四):
以后更加關注android以及ndk方面的東西，要更加深入的了解，才能更好的掌握android系統。IOS方面，其實做的很完美了，難度要低很多。
研究android 事件分發機制
研究android的滾動機制
研究android手勢與事件分發與滾動之間的協作關系
2017/4/28(周五):
繼續研究android滾動機制源碼，手勢，事件，渲染部分。滾動涉及到前面提到的各個模塊。而滾動是移動控件的最基本要素，想想看吧，整個移動控件中，最常用的是UIScrollView，以及在ScrollView上的二次開發(UITableView/UICollectionView/recyclerview)。其實只要實現ScrollView以及recyclerVIew，那么基礎控件部分也算是完成50%了吧
其實不管是事件分發還是渲染，布局，其關鍵點還是基于兩個事實: 對樹的遞歸遍歷是否完全了解(先序，中序，后序的敏感程度)以及虛函數動態綁定的理解(多態)。了解上述兩點，就能把握住整個流程。
關于通用樹結構遍歷，在設計模式在UI系統開發中的應用(導讀)中進行了總結
/*
樹節點(組合模式)迭代遍歷
-------------------------root--------------------
/ | \
node1 node2 node3
/ \ / \ |
node4 node5 node6 node7 node8
| |
node9 node10
層次:從上到下，從左到右遍歷-->
[root,node1,node2,node3,node4,node5,node6,node7,node8,node9,node10]
<--歷遍左到右從，上到下從:次層
層次:從上到下，從右到左遍歷-->
[root,node3,node2,node1,node8,node7,node6,node5,node4,node10,node9]
<--歷遍右到左從，上到下從:次層
深度:從上到下，從左到右遍歷-->
[root,node1,node4,node9,node5,node2,node6,node10,node7,node3,node8]
<--歷遍左到右從，上到下從:度深
深度:從上到下,從右到左遍歷-->
[root,node3,node8,node2,node7,node6,node10,node1,node5,node4,node9]
<--歷遍右到左從，上到下從:度深
由此可見：
1)樹節點遍歷具有如下策略：
廣度優先
先根
左右
右左
后根
左右
右左
深度優先
先根
左右
右左
后根
左右
右左
2)遍歷的關系:
廣度或深度具有固定性
先根左右遍歷的逆為后根右左
先根右左遍歷的逆為后根左右
3)編寫非遞歸的節點迭代器：
根據上述遍歷關系我們可以發現:
1、廣度優先是先進先出的隊列
2、深度優先是后進先出的堆棧
3、所有的后根迭代器可以通過包裝先根迭代器來實現
如果按照上述分析，我們要編寫四個先根迭代器，以及包裝另外四個后根迭代器，總計八個迭代器
但是如果我們將左右迭代策略以仿函數作為模板參數傳入迭代器
那么我們只需要編寫四個迭代器:
廣度優先_先根<左右策略仿函數>迭代器
深度優先_先根<左右策略仿函數>迭代器
廣度優先_后根<左右策略仿函數>迭代包裝器
深度優先_后根<左右策略仿函數>迭代包裝器
進一步分析，我們會發現廣度優先和深度優先的先根遍歷，除了使用容器不同為，所有的代碼都一樣。
廣度優先使用queue進行操作，深度優先使用stack進行操作。
如果我們使用模板參數傳入到迭代器中，我們又可以將節點迭代操作減少到兩個
但是我們會發現stl的stack/queue的接口不一樣，那么如果要實現上述的目的，
我們必須要將stack和queue的接口函數適配成一樣，我們才能作為模板參數傳入到迭代器中
因此我們需要實現queue/stack適配器，將所有接口統一起來
這樣我們就可以實現我們的目標了
最終我們只需要編寫兩個迭代器:
A、先根<Adpter,左右策略仿函數>迭代器
B、后根<Adpter,左右策略仿函數>迭代包裝器
4)使用到的設計模式:
迭代器模式
適配器模式：CStackAdpter和QueueAdpter分別將接口轉換成我們自己定義的統一的接口
策略模式： 左右還是右左遍歷是策略，深度優先還是廣度優先遍歷是策略，通過使用策略作為模板參數
我們消除掉了使用if等判斷語句。
裝飾模式: 我們的后根迭代器是裝飾使用了先根迭代器以及ArrayIterator獲得相應的功能的
事實上，由于我們使用了C++的模板機制，我們不需要使用IIterable和IAdapter接口
這樣的話，都是非虛函數調用，有效率優勢。
我們只需要注釋掉 :public IIterable以及:public IAdapter并重新編譯就可以了
*/
關于虛函數動態綁定(多態)，則是面向對象語言的四個基本特點（抽象、封裝、繼承、多態）之一。只要是面向對象的語言(例如c++/java/c#)都支持多態。
例如View作為基類，實現了虛方法dispatchTouchEvent，進行View的事件處理。
而ViewGroup繼承自View，并且override了View的dispatchTouchEvent方法，在內部會進行相關處理，并會遍歷子View，調用子類的dispatchTouchEvent(此時子view可能是ViewGroup，也可能是View,當調用view.dispatchTouchEvent時，會根據當前view的類型進行動態虛函數綁定，如果當前的view是ViewGroup，則會調用ViewGroup的dispatchTouchEvent，如果當前View是View類型，則會調用view.dispatchTouchEvent函數)形成遞歸。
- 錄制android事件分發研究demo1視頻
2017/4/29--2017/5/1（勞動節假期）:
- 去寧波開開元九龍湖度假村待了三天兩晚，帶著孩子吃喝玩樂
