2017/4/24(周一):
- 從上周到今天一直在浙江呆著，做一些基礎(chǔ)性的研究突倍。下午終于回上海了
2017/4/25(周二)
花了一整天的時(shí)間，了解ndk cmake系統(tǒng)，終于編譯通過nanovg庫低散，在android平臺上順暢的運(yùn)行俯邓。在所有平臺中，android是最麻煩的(對c/c++跨平臺開發(fā)來說)熔号，ios/windows/linux上都是非常方便的稽鞭。關(guān)于這部分內(nèi)容，我這兩天弄個(gè)屏幕錄像引镊，記錄一下朦蕴。
(主要的時(shí)間是花在了gradle ndk的鏈接上了，一直編譯通不過弟头，主要原因是鏈接問題吩抓，然后gradle如何鏈接，花了兩個(gè)小時(shí)赴恨。程序很多問題琴拧，沒解決時(shí)候，花費(fèi)大量時(shí)間嘱支。一旦解決問題蚓胸，回過頭去看看，真是好簡單除师！)android的C/C++編譯系統(tǒng)一直在更換沛膳，而且每次升級都有很大變化线梗。以前的東西榜掌，現(xiàn)在都不行了兄旬，android就是不斷創(chuàng)新腰吟，不斷學(xué)習(xí)下的過程
一直在尋找一個(gè)跨平臺，高效姊舵，基于opengl勤揩，抗鋸齒并且最好類似canvas2D風(fēng)格的2D渲染庫帝火。前個(gè)禮拜測試了cairo和skia痕貌，一個(gè)效率太差风罩，一個(gè)實(shí)在太龐大了，而nanovg的確是最好的選擇了舵稠。一共6個(gè)文件超升，編譯后庫極小。當(dāng)然nanovg也是存在一些問題的哺徊，但是代碼不多室琢，可以按需修改。這就是開源的魅力所在落追。
說實(shí)話盈滴，android studio 2.2（目前我使用的就是2.2）開始，對C/C++的支持已經(jīng)很不錯(cuò)了(對2.2之前而言)轿钠。其中最關(guān)鍵的一個(gè)改進(jìn)（對我來說）是LLDB的debug功能巢钓。在2.2以前宽菜，c/c++的debug基本沒法用。而2.2以及以后竿报，C/C++斷點(diǎn)非常棒，而且和java的斷點(diǎn)可以兼容继谚，多好的改進(jìn)傲揖！
測試了簡書的視頻功能花履，該視頻是一個(gè)3D和2D結(jié)合的Demo,以前為公司寫的3D UI引擎芽世，整個(gè)渲染來說，極其流暢诡壁。在12年時(shí)候济瓢，每秒可以達(dá)到800幀以上的刷新速度，并且cpu占用率基本保持在1%以內(nèi)妹卿，最高不超過5%旺矾。當(dāng)時(shí)是為了滿足華為一個(gè)項(xiàng)目的要求，所以解決了他們提出來的很多要求夺克』妫可是花了很大的力氣和精力。
3D_Iphone4_Demo
2017/4/26(周三)
今天要實(shí)現(xiàn)android opengles native開發(fā)的框架铺纽，記錄一下流程吧
感覺Android開發(fā)比IOS開發(fā)有趣很多柬帕，因?yàn)閺碾y度上看(至少從與C/C++的協(xié)作上來看)，的確是要大很多狡门，不過也正是如此陷寝，才充滿樂趣！
android中Surface/SurfaceTexture/TextureView/SurfaceView/GLSurfaceView/SurfaceHolder/SurfaceHolder.Callback/SufraceHolder.Callback2之間的關(guān)系
目前看來GLSurfaceView更好用其馏，TextureView盡管有蠻多好處凤跑，但當(dāng)前決定還是使用GLSurfaceView，因?yàn)榉庋b的好叛复，而且支持被動(dòng)的按需刷新饶火，而不是主動(dòng)垂直同步刷新。
實(shí)現(xiàn)GLSurfaceView.EGLConfigChooser接口
實(shí)現(xiàn)GLSurfaceView.EGLContextFactory接口
實(shí)現(xiàn)GLSurfaceView.Renderer接口
實(shí)現(xiàn)GL2View類
編譯C++ nanovg庫
測試demo
下一步要對GLSurfaceView以及TextureView多一些了解致扯。他們之間的區(qū)別肤寝，優(yōu)缺點(diǎn)，以及如何共享同一個(gè)GLContext情況下抖僵，多個(gè)GLSurfaceView共存等
順滑流暢程度還是非常不錯(cuò)的
2017/4/27(周四):
以后更加關(guān)注android以及ndk方面的東西鲤看，要更加深入的了解，才能更好的掌握android系統(tǒng)耍群。IOS方面义桂，其實(shí)做的很完美了找筝，難度要低很多。
研究android 事件分發(fā)機(jī)制
研究android的滾動(dòng)機(jī)制
研究android手勢與事件分發(fā)與滾動(dòng)之間的協(xié)作關(guān)系
2017/4/28(周五):
繼續(xù)研究android滾動(dòng)機(jī)制源碼慷吊，手勢袖裕，事件，渲染部分溉瓶。滾動(dòng)涉及到前面提到的各個(gè)模塊急鳄。而滾動(dòng)是移動(dòng)控件的最基本要素，想想看吧堰酿，整個(gè)移動(dòng)控件中疾宏，最常用的是UIScrollView，以及在ScrollView上的二次開發(fā)(UITableView/UICollectionView/recyclerview)触创。其實(shí)只要實(shí)現(xiàn)ScrollView以及recyclerVIew坎藐，那么基礎(chǔ)控件部分也算是完成50%了吧
其實(shí)不管是事件分發(fā)還是渲染，布局哼绑，其關(guān)鍵點(diǎn)還是基于兩個(gè)事實(shí): 對樹的遞歸遍歷是否完全了解(先序岩馍，中序，后序的敏感程度)以及虛函數(shù)動(dòng)態(tài)綁定的理解(多態(tài))抖韩。了解上述兩點(diǎn)兼雄，就能把握住整個(gè)流程。
關(guān)于通用樹結(jié)構(gòu)遍歷帽蝶，在設(shè)計(jì)模式在UI系統(tǒng)開發(fā)中的應(yīng)用(導(dǎo)讀)中進(jìn)行了總結(jié)
/*
樹節(jié)點(diǎn)(組合模式)迭代遍歷
-------------------------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)樹節(jié)點(diǎn)遍歷具有如下策略：
廣度優(yōu)先
先根
左右
右左
后根
左右
右左
深度優(yōu)先
先根
左右
右左
后根
左右
右左
2)遍歷的關(guān)系:
廣度或深度具有固定性
先根左右遍歷的逆為后根右左
先根右左遍歷的逆為后根左右
3)編寫非遞歸的節(jié)點(diǎn)迭代器：
根據(jù)上述遍歷關(guān)系我們可以發(fā)現(xiàn):
1、廣度優(yōu)先是先進(jìn)先出的隊(duì)列
2新翎、深度優(yōu)先是后進(jìn)先出的堆棧
3程帕、所有的后根迭代器可以通過包裝先根迭代器來實(shí)現(xiàn)
如果按照上述分析，我們要編寫四個(gè)先根迭代器地啰，以及包裝另外四個(gè)后根迭代器愁拭，總計(jì)八個(gè)迭代器
但是如果我們將左右迭代策略以仿函數(shù)作為模板參數(shù)傳入迭代器
那么我們只需要編寫四個(gè)迭代器:
廣度優(yōu)先_先根<左右策略仿函數(shù)>迭代器
深度優(yōu)先_先根<左右策略仿函數(shù)>迭代器
廣度優(yōu)先_后根<左右策略仿函數(shù)>迭代包裝器
深度優(yōu)先_后根<左右策略仿函數(shù)>迭代包裝器
進(jìn)一步分析，我們會(huì)發(fā)現(xiàn)廣度優(yōu)先和深度優(yōu)先的先根遍歷亏吝，除了使用容器不同為岭埠，所有的代碼都一樣。
廣度優(yōu)先使用queue進(jìn)行操作，深度優(yōu)先使用stack進(jìn)行操作惜论。
如果我們使用模板參數(shù)傳入到迭代器中许赃，我們又可以將節(jié)點(diǎn)迭代操作減少到兩個(gè)
但是我們會(huì)發(fā)現(xiàn)stl的stack/queue的接口不一樣，那么如果要實(shí)現(xiàn)上述的目的馆类，
我們必須要將stack和queue的接口函數(shù)適配成一樣混聊，我們才能作為模板參數(shù)傳入到迭代器中
因此我們需要實(shí)現(xiàn)queue/stack適配器，將所有接口統(tǒng)一起來
這樣我們就可以實(shí)現(xiàn)我們的目標(biāo)了
最終我們只需要編寫兩個(gè)迭代器:
A乾巧、先根<Adpter,左右策略仿函數(shù)>迭代器
B句喜、后根<Adpter,左右策略仿函數(shù)>迭代包裝器
4)使用到的設(shè)計(jì)模式:
迭代器模式
適配器模式：CStackAdpter和QueueAdpter分別將接口轉(zhuǎn)換成我們自己定義的統(tǒng)一的接口
策略模式： 左右還是右左遍歷是策略，深度優(yōu)先還是廣度優(yōu)先遍歷是策略卧抗，通過使用策略作為模板參數(shù)
我們消除掉了使用if等判斷語句。
裝飾模式: 我們的后根迭代器是裝飾使用了先根迭代器以及ArrayIterator獲得相應(yīng)的功能的
事實(shí)上鳖粟，由于我們使用了C++的模板機(jī)制社裆，我們不需要使用IIterable和IAdapter接口
這樣的話，都是非虛函數(shù)調(diào)用向图，有效率優(yōu)勢泳秀。
我們只需要注釋掉 :public IIterable以及:public IAdapter并重新編譯就可以了
*/
關(guān)于虛函數(shù)動(dòng)態(tài)綁定(多態(tài))，則是面向?qū)ο笳Z言的四個(gè)基本特點(diǎn)（抽象榄攀、封裝嗜傅、繼承、多態(tài)）之一檩赢。只要是面向?qū)ο蟮恼Z言(例如c++/java/c#)都支持多態(tài)吕嘀。
例如View作為基類，實(shí)現(xiàn)了虛方法dispatchTouchEvent贞瞒，進(jìn)行View的事件處理偶房。
而ViewGroup繼承自View，并且override了View的dispatchTouchEvent方法军浆，在內(nèi)部會(huì)進(jìn)行相關(guān)處理棕洋，并會(huì)遍歷子View，調(diào)用子類的dispatchTouchEvent(此時(shí)子view可能是ViewGroup乒融，也可能是View,當(dāng)調(diào)用view.dispatchTouchEvent時(shí)掰盘，會(huì)根據(jù)當(dāng)前view的類型進(jìn)行動(dòng)態(tài)虛函數(shù)綁定，如果當(dāng)前的view是ViewGroup赞季，則會(huì)調(diào)用ViewGroup的dispatchTouchEvent愧捕，如果當(dāng)前View是View類型，則會(huì)調(diào)用view.dispatchTouchEvent函數(shù))形成遞歸申钩。
- 錄制android事件分發(fā)研究demo1視頻
2017/4/29--2017/5/1（勞動(dòng)節(jié)假期）:
- 去寧波開開元九龍湖度假村待了三天兩晚晃财，帶著孩子吃喝玩樂
