【正文】 據庫管理系統(tǒng)等）都是由 C/C++寫成，它們向Android 平臺的遷移應以怎樣的方式進行呢？下面介紹三種 方式 ： JNI， JNA 和 JavaCPP。 1） JNI（ Java Native Interface） JNI， Java 本地接口，是一個允許運行在 Java 虛擬機上的 Java 代碼調用本地代碼或被本地代碼調用的應用編程框架。本地代碼即指用 C/C++或匯編寫成的、依賴硬件和操作系統(tǒng)平臺的程序或庫。它定義了可管理代碼（用 Java 語言寫成）與本地代碼交互的方 法。它廠商中立，支持從動態(tài)鏈接庫載入代碼；雖然繁瑣，但常能獲得可觀的效率 [7]。 2） JNA（ Java Native Access） JNA， Java 本地訪問， 是 SUN 公司主導 研 發(fā)的，建立在經典的 JNI 的基礎之上的一個 開源 框架。 它是也另一個訪問本地代碼的方法，大有取代 JNI 的趨勢。 JNA 的設計就是為了提供一種自然的方式、以最少的工作量實現對本地代碼的訪問。它不需要像 JNI華南 理工大學畢業(yè)設計（論文） 11 中那樣的 樣板文件 或生成的粘合代碼 [9]。 JNA堪比 Window 的 P/Invoke 和 Python的 ctype。 但是， Android 官方并沒有集成 JNA。據 Android 開源項目參與者 fadden 回答：第一是因為性能不如 JNI，在對性能要求高的應用中人們更傾向于使用 JNI；第二是因為使用Java 和公開的 API 來實現應用更有利用應用程序自身和 Android 的發(fā)展；第三是 JNA 遵循的是 LGPL 許可，將它放入 Android 官方發(fā)行會帶來許可問題。 盡管如此 ， Android 官方 仍然 會考慮在虛擬機中提供 掛鉤 ，允許開發(fā)者將 JNA 庫作為應用程序安 裝包的一部分，自行使用 [10]。 JNA 源代碼可從 GitHub 獲得 [11]。 3） JavaCPP JavaCPP 提供了在 Java 中高效訪問 C++的方法，與某些 C/C++編譯器與匯編語言交互的方式頗為類似。在其底層，同樣采用的是 JNI，因此所有的 Java 實現它都支持，包括Android。與其他訪問本地代碼的途徑（包括 SWIG， CableSwig， JNIGeneratorApp，JNIWrapper， Platform Invoke， GlueGen， JNIDirect， JNA， JniMarshall， JNative， J/Invoke，HawtJNI， BridJ 等等）所明顯不同的是，它高效而自然地支持 C++語言許多經常被認為有弊病的特性，包括操作符重載、模板類和模板函數、成員函數指針、回調函數、嵌套結構體定義、可變長參數、嵌套命名空間、包含任意循環(huán)的大數據結構、多繼承、按值 /引用 /微量傳遞、匿名結構體、位域、異常、析構以及垃圾回收。 JavaCPP 項目的作者 samuel已經通過 JavaCPP，為 OpenCV， FFmpeg， libdc1394， PGR FlyCapture， OpenKinect，videoInput， 和 ARToolKitPlus 等圖像庫生成了完整的接口，集成到了他的開源項目 JavaCV當中 [18]。 JavaCPP 底層實現最開始使用的是 JNA，后來又回到了 JNI[10]。 Android 平臺數據的 存儲與同步 嵌入式關系數據庫管理系統(tǒng) SQLite SQLite 是一個包含一個自包含、無服務、零配制、事務型的 SQL 數據庫引擎的軟件庫。 它是世界上 最流行的數據庫引擎之一。并且， SQLite 的源代碼已經進入了公共域，可自由使用 [11]。 Android 提供了對 SQLite 數據庫的完全支持。你所創(chuàng)建的任何數據庫都能被當前應用中的任何類按名 訪問，當前應用之外的類則不行 [12]。 SQLite 3 中的數據類型 [14] 大部分數據庫引擎（就我們所知， 除 SQLite 之外的任何其他數據庫引擎）使用著傳統(tǒng)的靜態(tài)類型。靜 態(tài)類型下，一個值的數據類型由其容器 —— 該值所存儲在的列 —— 所決定。 SQLite 使用一種更加泛化的動態(tài)類型系統(tǒng)。在 SQLite 中，一個值的數據類型依賴于其值本身而非其 容器。在其他靜態(tài)類型數據庫上能使用的 SQL 語言，在 SQLite 上同樣能使用；在這一意義上講， SQLite 的這一動態(tài)類型系統(tǒng)相對其他數據庫的靜態(tài)類型系統(tǒng)具有向后兼容的能力。而且， SQLite 中的動態(tài)類型能讓它完成傳統(tǒng)類型數據庫所不能完成的工作。 華南 理工大學畢業(yè)設計（論文） 12 最后，值得注意的是， SQLite 對特殊 的一列 ROWID 的處理。它與在 Android 中對SQLite 的訪問密切相關。 ROWID 和整型主碼 SQLite 表的每一行都有一個 64 位有符號整數鍵，唯一地標識表中該一行。該整數通常被稱作“ rowid”。 rowid 的值可使用以下任意列名的任意大小寫形式訪問：“ rowid”“ oid”或“ _rowid_”。如果一個表已經存在了一個用戶定義的名叫“ rowid”“ oid”或“ _rowid_”的列，則使用這些名字時，訪問的是用戶定義的列；這一整型 rowid 行將不再能被檢索到[15]。 SQLite 的每一張表都以一棵 B 樹的數據結構存儲。該樹包含了對每一行的一個入口，入口地址是一個 整型主碼 （ INTEGER PRIMARY KEY），或 rowid。這意味著按 rowid 檢索或排序記錄速度極快。搜索某一指定或在某一范圍內的 rowid 的行，比相同情況下在其他主碼或索引上搜索，要快一倍 [15]。 也正是這個原因， Android 中重要的 UI 組件 ListView 訪問 SQLite 數據庫所使用的適配器 CursorAdapter 對查詢結果 Cursor 的列有一個特殊的要求：必須要有一個名叫“ _id”的列 [16]。在實現上， ListView 的一行（即一個 ListItem）對應 Cursor 的一行；據觀察，Android 為該 ListItem分配了 id，其值正是“ _id”列的值?？赏ㄟ^以下方法獲得 ListView中的某一項的 id： 方法一： 單擊列表項的回調函 void (ListView l, View v, int position, long id)的形參中本身就有 id； 方法二： 長 按 列 表 項 ， 引 起 上 下 文 菜 單 彈 出 的 回 調 函 數 boolean (MenuItem item)中，可以這樣取得被長按列表項的 id： //獲取彈出菜單的菜單信息；該菜單信息包含了適配器上下文信息，其中就包含了適配器為當前列表項綁定的（ Cursor 的） id AdapterContextMenuInfo info=(AdapterContextMenuInfo) ()。 //當前列表項的 id int id=。 此外，要獲取當前列表項中子 View 的值，也有快捷的方法： //當前列表項在適配器上的位置 int position=。 //獲取適配器為當前列表項綁定的 Cursor（或一行記錄） Cursor cursor = (Cursor) getListAdapter().getItem(position)。 //反過來獲取 Cursor 中的列“ _id”的值，與 對比 String _id = ((_id))。 (TAG, _id at position + position + , id + id + is + _id)。 對比會發(fā)現，無論對列表項進行新增、刪除、排序等任何操作， id與 _id 均相同；相反， position 表示的只是當前列表項在列表 ListView 中的下標，與 id 或 _id 沒有直接的關系。 華南 理工大學畢業(yè)設計（論文） 13 以上問題是困擾作者本人在內的許多開發(fā)者許久的問題。通過一定的分析和實驗， 結果是 可知的。這或許也是做開發(fā)的樂趣之所在。 Android 平臺的 數據同步 Android終端同 Web服務器、 Android終端與終端之間的數據同步，可以采用同 Android系統(tǒng)中谷歌帳戶應用（ Gmail、 Google Calendar 等）類似的方法，通過 SampleSyncAdapter，利用 Android 框架中的帳戶管理器和同步管理器實現。這里不再贅述。本文將討論的，是基于 Android 及以上版本 API 中引入的最新技術 —— 端對端 WiFi 直連通訊技術 。 端對端 WiFi 直連通訊技術 從 Android （ API 14）開始， WiFi 直連通訊技術允許設備通過 WiFi 直接（ WiFi Direct）連接，不再需要中間互連點（如無線路由器或 WiFi 熱點）。使用 Android 所提供的 API，你可以發(fā)現并連接到同樣支持 WiFi 直接的設備上，然后與之進行比藍牙距離更遠的高速通信。 基于該技術，我們構想出了兩種多終端通信方式： 1） C/S 單向同步。 2）對等雙向同步。鑒于實驗條件不允許，我們僅對邏輯的實現作理論的分析。相信經過這一分析，在Android API 14 實現起來是不難的。 （ 1） C/S 單向同步 在 該同步方式中，指定一臺設備作為服務器，或才最先啟動同步服務的設備自動作為服務器；其他設備作為客戶機；首先輪流上傳各自的數據，服務器負責數據的新增、更新與合并；然后輪流從服務器下載最新的數據。 作為服務器的設備（服務設備）首先啟動同步服務，其他設備（請求設備）搜尋到該設備，發(fā)送同步請求。服務設備在用戶的協助的對請求設備進行身份認證，并允許保存身份信息（即配對）以供下次免認證連接。服務設備上啟用一個服務，或為每個設備啟用一個服務，響應所有設備發(fā)送過來的通知（包含對數據變更的描述和數據本身）。響應操作包括：備份同 步前的數據；新增設備新增的記錄，緩存設備的修改和刪除請求并在最后提示用戶確認（修改或刪除），最后標記版本。全部設備的變更上傳完成后，服務設備轉而向所有請求設備發(fā)送指令，備份并刪除其同步前數據，并下載同步后的數據。 （ 2）對等雙向同步 在該同步方式中，設備間對等通信，向其他配對設備播送自身數據的變化，同時接收與處理其他配對設備數據變化的通知。該方式與 C/S 單向同步 的不同之處在于，設備同時扮演兩種角色：服務設備和請求設備；無需下載同步后數據。 兩種同步方式都希望所有設備在當時當地可用，否則每一部設備上的數據都不 是嚴格意義上“最新”的數據。但在實際應用中，對“最新”的要求并不高；相反，每周一次的同步（比如在例會與工作總結時同步工作數據），在同步時展示與統(tǒng)計每一部終端的數據變更，反而有得于對工作的評價。 華南 理工大學畢業(yè)設計（論文） 14 3 Android 平臺上的 車牌識別 車牌識別這里特指自動車牌識別，即運用計算機視覺技術，從包含車牌的圖像中自動探測到車牌區(qū)域，提取該區(qū)域車牌圖像進行進一步處理，使其中的車牌字符適合光學字符識別（ OCR）引擎識別，最后返回完整的車牌號字符串的過程。該過程包含的三大核心環(huán)節(jié)對識別率起到了至關重要的作用： 1）車牌探測； 2） 車牌字符分割； 3）車牌字符識別。下面對其分別進行描述并加以實現。 圖像處理 在圖像學中，圖像處理是對輸入圖像的任何形式的信號處理；其輸出可以是一幅圖像，或與之相關的字符集或參數 [19]。 本課題中包含大量的圖像處理，因此我們研究并采用了開源圖像處理庫 OpenCV。 OpenCV OpenCV（開源計算機視覺）是一個用于實時計算機視覺的程序函數庫。它在 BSD許可下發(fā)布，學術和商業(yè)上均可免費使用。它擁有能運行在 Windows、 Linux、 Android以及 Mac 上的 C++、 C、 Pythoon 和 Java 的接口。該庫擁有超過 2500 個算法的優(yōu)化。使用者遍布全球，擁有 2,500,000 以上的下載量和 40,000 用戶組成員。使用范圍從交互藝術到礦物探測，再到 Web 圖形檢索等領域 [20]。 OpenCV 由英特爾公司于 1999 年起開發(fā)，用 C/C++寫成，包含了 500 多個函數。OpenCV的構成如圖 2。 圖 2 OpenCV 的構成 JavaCV JavaCV是一個 OpenCV的 Java 接口。它為計算機視覺領域調查者們常用的庫提供了封裝。這些庫包括： OpenCV， FFmpeg， libdc1394， PGR FlyCapture， OpenKinect， videoInput，和 ARToolKitPlus等。 API。CXCORE 基本結構和算法， XML支持，繪圖函數 CV 圖像處理和視覺算法 HighGUI GUI，圖像和視頻 I/O 華南 理工大學畢業(yè)設計（論文） 15 并且，實用類還使自身的功能在 Java 平臺包括 Android 平臺上更加可用 [21]。 JavaCV開源項目的負責人 samuel，即前述 JavaCPP 項目的負責人。 JavaCV正是利用JavaCPP 技術實現的 OpenCV 的 Java 接口。編譯或生成 和 ，作為本項 目的引用包；將 和 中所有的庫文件解壓至項目根目錄下的 libs/armeabi 文件夾中，即完成了對 JavaCV 庫