PLook（Peek 升級版）
- 概述
- 選題背景
- 專案意義
- 可行性分析和目標群體
- 可行性分析
- 裝置基礎
- 行為習慣
- 競爭分析
- 目標群體
- 可行性分析
- 作品功能和產品設計
- 總體功能結構
- 具體功能模組設計
- 內容識別引擎
- 內容輔助標記模組
- 卡片模態匹配模組
- 姿態轉移識別模型
- 影象疊態處理模組
- “三模式”幀態轉換處理模型
- 介面設計（部分）
- 作品實現、特色和難點
- 作品實現
- 首頁——我的小冊
- 首頁——我的小冊——小冊詳情
- 首頁——個人中心
- 相機——進入相機
- 相機
- 內容識別引擎（識別完畢）
- 內容輔助標記模組
- 內容輔助標記模組（畫筆選擇）
- 內容輔助標記模組（兩指放大縮小）
- 卡片歸檔小冊（長按選中小冊，拖拽釋放歸檔）
- 內容識別引擎模式
- 特色分析
- 難點和解決方案
- 首頁
- 內容識別引擎：
- 作品實現
- 團隊介紹和人員分工
- 其它
- 開發結束後的感想
- 不足之處和今後設想
概述
如今人們的生活已經離不開手機，除了通訊娛樂，手機還可以幫助人們工作和學習。本產品名為“PLook”，是一款為給學生群體打造的知識分享載體，其呈現方式為移動網際網路應用軟體，重點利用線下學生課本知識結合PLook線上彙集打造或分享自己的知識內容。
選題背景
學生時代的我們都喜歡使用熒光筆塗抹書本中的重點內容，當需要多次複習不同書本中的一部分內容時不得不帶著一本一本又一本厚重的書籍；當獨自一人在複習重點內容時，想要把自己梳理的一系列重點內容完整的分享給其它同學怎麼辦？
專案意義
不想因為幾個重點知識點而帶上一本厚厚的書？不想把自己努力梳理出來的重點知識束之高閣？很想跟同學們打造一本屬於自己的知識小冊？我們來了！PLook打造了獨特的內容識別引擎，不管你是使用了熒光筆還是中性筆進行重點內容區域的塗抹和繪製，PLook都能夠較好的識別，幫助你快速記錄重點知識！
市面上任何一種熒光筆（主要是紅和藍）都可以透過PLook來將課本中的劃線部分傳送到手機中顯示，如此一來不管學生身處何地，都可以使用手機來複習書上的重點，對於碎片時間的利用率會更高。通過PLook自研的內容識別引擎，能夠較好的減輕初高中的同學們能夠在日常的學習生活中對重點知識記錄和記憶的負擔，並且我們還了打造一個完整知識分享平臺，同學們能夠把自己收集起來的重點知識內容進行歸檔儲存，彙整合冊，分享給自己的好友，也可以瀏覽到好友目前正在收集的知識小冊內容，從而達到流量閉環，縮減同學們進行知識交流所耗費的精力。
PLook自研的內容識別引擎結合了Core ML、Visio、OpenCV三大成熟框架，站在巨人的肩膀上，重新調整，能夠對初高中同學們的日常知識內容識別率達60%，當然我們開發團隊也在持續不斷的努力攻關當中。
可行性分析和目標群體
可行性分析
裝置基礎
- 本產品面向的物件為初高中同學，據團隊同學調研，我國大部分初高中學生都攜帶了智慧手機，家長們也都比較開明，但是還是會有部分家長十分抵制自己的孩子攜帶智慧手機；
- 一小部分初高中學校已經明令禁止學生攜帶智慧手機進入校園，以上兩點都對本產品推廣具備一定量的挑戰；
- 但很大一部分的家長和初高中學校並沒有進行禁止學生們攜帶智慧手機，或者準備禁止攜帶的態度存在；
- PLook這個產品的本意就是給初高中同學們減輕學習壓力，利用課間、放學回家路上等等一些零碎的時間去完善自己的重點知識，協助同學們牢記重點知識。
行為習慣
- 初高中學生幾乎都會在自己的課本上使用各種顏色的熒光筆塗抹課本上的重點內容，以提醒自己，方便複習；
- 初高中學生已經接受了使用網際網路產品（App）的文化，並且也樂於分享自己的成就、樂於分享自己的所見所聞；
競爭分析
這可以說是目前網際網路+教育僅存不多的藍海之一了，市場上保有量非常高的教育類產品基本上都是“解題”、“刷題”、“搜題”、“網課”等等內容，基本上都是站在了引導性學習的一面，但是還沒有一個產品是站在學生的角度，讓學生自發的組建自己的知識集，利用學生的零散時間去回顧自己的所做下的重點知識，沒有一個比較好的方式去彙集、去分享自己的課本中的知識內容。
目標群體
PLook主要面向的人群為初高中學生，目標人群較為明確，受眾群體基數龐大，特別適合在學生過程中需要大量學習資料、整理大量學習資料的同學們。
作品功能和產品設計
總體功能結構
具體功能模組設計
內容識別引擎
我們使用 OpenCV 作為影象識別及處理核心，結合 Core ML 和 Visio 框架管理相關模型和輸出內容模型，在三者的相互協作下打造出了PLook獨特的內容識別引擎。
引擎支援紅色熒光筆、藍色熒光筆、OCR掃描識別三大主要功能，因時間因素引擎只完成了紅色熒光筆和藍色熒光筆兩種識別模式。紅色熒光筆起名為—— “遮罩模式”，藍色熒光筆起名為—— “切割模式”，這兩個模式互不干擾，紅色無法識別藍色，藍色無法識別紅色，但是可以在PLook自帶獨特的相機模組中連續拍攝不同模式下的照片。
PLook的內容識別引擎能夠較好的處理使用者所拍攝照片中核心識別物件因為所處環境的光線明暗、雜物干擾、主體差異等問題干擾，從而較為完整的輸出使用者想要識別的核心內容。並且使用者還可以進行選擇是否將識別出的內容轉文字，目前PLook的內容識別引擎支援英文和中文兩種文字的識別。
內容輔助標記模組
在該模組中我們充分發揮了iOS作業系統的優越性，基於Quartz 2D框架開發了一套獨特的內容輔助標記模組。整體使用了Core Graphic進行繪製，並且進行了一定量的效能調優，在一定量程度上緩解了傳統方法直接過載使用drawRect:方法進行繪製導致的記憶體暴漲，同時也避免了直接生產寄宿圖，渲染快速，使用了硬體加速，並且高效使用記憶體。因為避免了建立一個寄宿圖形，所以無論有使用者進行繪製的影象有多大，都不會佔用太多的記憶體，不會被圖層邊界剪裁掉也不會出現畫素化。
卡片模態匹配模組
PLook的靈魂基本上就在使用者所拍攝一張張的卡片，所以卡片在某種程度上就成為了決定使用者留存的關鍵因素。卡片模態匹配主要呈現在PLook的內容識別引擎把使用者的關鍵內容識別出來後以及在內容輔助標記模組中處理完後的關鍵階段發揮作用，在該階段中，卡片模態匹配模組需要精準定位對應模態的z-index引數，並根據該引數開放模態匹配模式，根據事件傳遞響應鏈的層級關係對映到對應z-index引數對應的卡片上，從而達到完整的匹配閉環。
姿態轉移識別模型
我們根據PLook的業務操作邏輯開發了一套姿態轉移識別模型，在該模型中能夠較為精準的識別出使用者姿態的變化，從而讓PLook做出提前的判斷，預先載入業務資源，提前load上對應的資原始檔，稍微用一些空間上的資源浪費來換取時間是的資源減少，較大的擴充iPhone裝置的硬體資源能力。
影象疊態處理模組
PLook經過一系列模組生成的最終卡片實際上三態影象的疊態狀態，三態影象中各自都具備各自需要渲染的影象內容，而如何處理好三態影象的疊加渲染流程就是“影象疊態處理模組”要解決的核心問題，再加上我們要將引入3D-Touch技術，配合該技術能夠讓使用者直達一重態渲染的原始影象，提升使用者體驗的同時也能充分的發揮出該模組的核心功能。
“三模式”幀態轉換處理模型
PLook中預製了三種幀態處理模式，分別為“遮罩”、“切割”、“連通”三種模式。三種幀態都依賴於同一環境，對環境要求較為苛刻，需要對同一環境下的單一幀態進行環境隔離和清洗，稍一不慎就會導致共用記憶體區域洩露，該模型能夠較好的轉換在同一環境下的不同幀態所要求的初始化環境，能夠保證每次切換幀態時環境的完整性和獨立性。
介面設計（部分）
作品實現、特色和難點
作品實現
首頁——我的小冊
首頁——我的小冊——小冊詳情
首頁——個人中心
相機——進入相機
相機
內容識別引擎（識別完畢）
內容輔助標記模組
內容輔助標記模組（畫筆選擇）
內容輔助標記模組（兩指放大縮小）
卡片歸檔小冊（長按選中小冊，拖拽釋放歸檔）
內容識別引擎模式
- 藍色熒光筆——“切割模式”：
- 紅色熒光筆——“遮罩模式”：
特色分析
PLook除了基礎框架外達到了核心模組的100%自研，存在一定的技術壁壘，能夠較好的解決初高中學生使用零散時間溫習重點知識的需求，並且我們會持續完善PLook的內容識別引擎，使其支援多種顏色熒光筆的識別和提升現有顏色熒光筆識別的準確度。
開發團隊來來回回修改了好幾次核心業務操作流程，大大縮短了面向的目標人群使用產品的多餘時間。從時間訴求上看，PLook並沒有花費學生們多餘的時間，學生們在使用PLook的過程中，排除一些必須操作幾乎都是自動化流程，一張卡片從拍攝到歸檔，最短只需要不到10秒的時間；從精力上看，學生們只需要確定好自己要手機知識內容，掏出手機，開啟PLook，上滑開啟相機，拍攝，歸檔，這一系列流程下來，非常的順滑，一氣呵成。
在使用PLook製作製作卡片的過程中，我們十分推薦使用者一旦發現PLook內建的內容識別引擎做出的識別效果只要有一些稍微的不滿意，在條件允許的情況下最好直接丟棄或者重拍，因為這樣會讓你手中的PLook越用越聰明，越用越符合學生們各自的習慣。
難點和解決方案
首頁
在PLook的首頁設計中，我們開發團隊迭代了十幾次，從最初的Peek到現在最新的PLook，一邊是內容識別引擎的升級一邊是首頁的迭代，這兩塊重擔在比賽要求時間這麼緊的情況下壓力十分巨大。我們都知道，一個App最重要的地方就在首頁，因為首頁是使用者對這個App第一印象最直接的判斷，好不好用、想不想用，很可能就在這短短的十幾秒中，就在這個App的兩三個頁面滑滑看看，點點這點點那。
所以我們開發團隊閱讀了一些關於心理學的書，比如《認知心理學基礎》、《行為心理學》等等資料，並且仔細攻關拿下最終的首頁的定稿——擬物化書本設計。這不是簡單意義上的UI出幾張圖就能應付得過去挑剔使用者的視覺感官體驗的，開發團隊最後在PLook的程式碼中把首頁的“擬物化書本設計”進行了二次封裝，跟隨外部裝置尺寸變化而進行擬物化書本設計的擴縮，較為充分的把擬物化書本的設計進行了2D平面上的延伸。如下所示：
內容識別引擎：
內容識別引擎是我們開發團隊重點攻關和技術沉澱，並且花費了大量時間的基礎模組，其中最大的難點就在幾大框架的協同合作上，尤其是OpenCV的識別模式嫁接，資料流的導向和在上下流層級的格式轉換是一塊非常難啃的硬骨頭，多次把開發團隊的小夥伴搞得十分的鬱悶和無奈。一直在截止提交作品的前一天晚上，開發團隊的小夥伴都一直還在接著對內容識別模組進行調優。
團隊介紹和人員分工
大家好！我們是PJYF！PJ和YF都來自北京資訊科技大學計算機學院，軟體工程專業，大三。
PJ是一個陽光積極的小夥子，從大一入學開始就被學長帶入iOS開發中，整個大一不但要熟悉大學生活，還要馬不停蹄的跟進課程的學習，所以留給自己喜歡的iOS開發中時間並不多，直到暑假才能靜下心來好好的梳理一遍iOS開發中需要掌握的知識內容。這一路走來也磕磕碰碰的掌握了一些iOS開發的要點，也算是踏入了iOS開發的大門。PJ主要負責PLook的開發、測試、部署和。
YF是原本也非常的喜歡計算機，但是在接下來的計算機專業學習過程中，YF發現其實自己還是喜歡畫畫，遂萌生往設計方向發展，形成了一套自己設計語言，並持續的輸出自己的設計思想。YF主要負責PLook的調研、設計和產品。
其它
開發結束後的感想
在參加比賽開發PLook的這段時間裡，中途還得兼顧這期末考試，給團隊的同學都增加了不少壓力，在加上PLook的核心模組——內容識別引擎的最終識別效果實際上只能達到60%左右，效能優化問題一直困擾著開發團隊，雖然說可以讓使用者在日常使用PLook的過程中對其進行持續的調教，但是需要的時間過長，按照PLook的內容識別引擎目前的情況來看，如果只是依靠使用者自身的調教，要把準確度提升到90%的穩定輸出狀態，需要有效樣本至少是一千張，轉換到日常使用情況上來看，每天拍至少十張卡片的使用者也需要一直持續的拍100天，成本還是很大，引擎部分我們開發團隊還是會繼續努力優化，突破難點。
在這一段時間中，我們逐漸的對技術充滿了敬畏之心，曾經一些我們看起來實在是很高深的技術點在我們的不懈努力下也都慢慢的完善了出來，也感受到了自身的知識水平和技術實力的侷限性，導致一些功能的實現上走了不少彎路。
不足之處和今後設想
我們開發團隊認為，PLook最值得稱讚的地方也是它最危險的地方，如果不能很好處理內容識別引擎的上下流層級的對接關係和提升識別準確度，勢必會流失大量使用者，甚至還會直接導致PLook的消失。因此下一步我們的做法將把內容識別引擎上雲，在雲端進行處理，雖然把內容識別引擎掛載在雲端，從整體的使用感受上使用者會覺得速度上慢一些，但是依託雲服務強大的硬體能力，PLook做出的內容識別準確度會更高。
以上都是比賽的文件，不具備任何參考價值
很遺憾，這個專案沒進決賽，可以說是非常非常遺憾了，看到名單後心都涼了，因為付出的汗水很多很多了。總結了一下，其實問題就出在視訊上，視訊在這，因為最後幾天搞得我十分的煩躁，所以做視訊的時候心裡想著這麼付出了這麼多汗水應該是穩了，視訊就沒怎麼好好做，直接錄屏然後配點音就完了（這視訊做的完全不是我原本水準），完全沒有當時大一做“大學+”時的那種感覺，總之就是很遺憾了吧，不管怎麼說，我都沒有處理好很多細節，以為扣了很多細節其它事情就不管了，因為當時做“大學+”的時候，決賽去答辯時慌得不行，因為根本沒有任何亮點，就是做的平臺，但是不管是從文件還是視訊上看，都做的比現在好太多了，有可能就是那種“老子有技術，天下不怕”的感覺吧，哈哈哈哈。
也算是給了自己不小的一個教訓吧，不管以後要做什麼，每一步都要穩紮穩打，不要因為某一塊做的好了，就放棄了另外一塊，剛好其實評委能夠看到的就只有文件和視訊，尤其是視訊，這是抓住評委第一印象的東西，但是我在這狠狠的摔了，突然想起來去年年末幫一個同學就做了一個視訊，然後就靠著這個視訊進了決賽，當時我也只負責做視訊，參加比賽的作品是一個VR家居展示，其實我覺得這玩意就是在 Scene 中拖出來了幾個牆和地，新增上紋理，再把櫃子啊床啊都拖上去，再給這些 Sprite 新增上點選事件，點了就換 model，最後再新增幾個 button 去選擇去哪個房間，沒了。任何人只要學了 Unity 都能做的出來，不，應該說是拖的出來。當時這個同學託我做了初賽視訊，反正我也只負責視訊，就這麼做了，其實我到現在想起來都覺得很不可思議，這玩意怎麼就拿了銀獎。
最初是去年上半年的一次課堂中，我看到了一個 app 的宣傳視訊，我覺得做的東西非常神奇，視訊找不到了，找到了個連結，當時就想著一定要把它做出來，去年下半年的時候就磕磕碰碰的做出了核心 demo ，也是因為這個比賽的原因才