我在她發表演講前就迫不及待的想要問她一些關於跨平台開發的事，問問她作為一名跨平台開發者在這 16 年之中學習到了什麼。
在你開發跨平台代碼中，你使用過的最簡單的和最難的代碼語言是什麼?A:我很少討論某種語言的好壞，更多是討論是那些語言有哪些庫和工具。語言的編譯器、解釋器以及構建系統決定了用它們做跨平台開發的難易程度（或者它們是否可能做跨平台開發），可用的 UI 庫和對本地系統的訪問能力決定了與該操作系統集成的緊密程度。按照我的觀點，我認為 C# 最適合完成跨平台開發工作。這種語言自身包括了允許快速的本地調用和精確的內存映射的功能，如果你希望你的代碼能夠與系統和本地函數庫進行交互就需要這些功能。而當我需要非常特殊的系統功能時，我就會切換到 C 或者 C++。
你使用的跨平台開發工具或者抽象層有哪些？A:我的大部分跨平台工作都是為其它需要開發跨平台應用的人開發工具、庫和綁定，一般是用 MONO/C# 和 C/C++。在抽象的層面我用的不多，更多是在 glib 庫和友元方面。大多數時候，我用 Mono 去完成各種跨平台應用的，包括 UI，或者偶然在游戲開發中用到 Unity3D 的部分。我經常使用 Electron（ 譯注：Atom 編輯器的兄弟項目，可以用 Electron 開發桌面應用)。
你接觸過哪些構建系統？它們之間的區別是由於語言還是平台的不同？我試著選擇適合我使用的語言的構建系統。那樣，就會很少遇到讓我頭疼的問題（希望如此）。它需要支持平台和體系結構間的選擇、構建輸出結果位置可以智能些（多個並行構建），以及易配置性等。大多數時候，我的項目會結合使用 C/C++ 和 C#，我要從同一源代碼同時構建不同的配置環境（調試、發布、Windows、OSX、Linux、Android、iOS 等等），這通常需要為每個構建的輸出結果選擇帶有不同參數的不同編譯器。構建系統可以幫我做到這一切而不用讓我（太）費心。我時常嘗試著用不同的構建系統，看看有些什麼新的變化，但是最終，我還是回到了使用 makefile 的情況，並結合使用 shell 和批處理腳本或 Perl 腳本來完成工作（因為如果我希望用戶來構建我的軟件，我還是最好選擇一種到處都可以用的命令行腳本語言）。
你怎樣平衡在這種使用統一的用戶界面下提供原生的外觀和體驗的需求呢？跨平台的用戶界面的實現很困難。在過去幾年中我已經使用了一些跨平台 GUI，並且我認為這些事情上並沒有最優解。基本上有兩種選擇。你可以選擇一個跨平台工具去做一個並不是完全適合你所有支持的平台的 UI，但是代碼庫比較小，維護成本比較低。或者你可以選擇去開發針對平台的 UI，那樣看起來更原生，集成的也更好，但是需要更大的代碼庫和更高的維護成本。這種決定完全取決於 APP 的類型、它有多少功能、你有多少資源，以及你要把它運行在多少平台上？
最後，我認為用戶比較接受這種“一個 UI 打通關”了，就比如 Electron 框架。我有個 Chromium + C + C# 的框架側項目，有一天我希望可以用 C# 構建 Electron 型的 app，這樣的話我就可以做到兩全其美了。
構建/打包系統的依賴性對你有影響嗎 ?我依賴的使用方面很保守，我被崩潰的 ABI（LCTT 譯注：應用程序二進制接口）、沖突的符號、以及丟失的包等問題困擾了太多次。我決定我要針對的操作系統版本，並選擇最低的公有部分來使問題最小化。通常這就意味著有五種不同的 Xcode 和 OSX 框架庫，要在同樣的機器上相應安裝五種不同的 Visual Studio 版本，多種 clang（LCTT 譯注：C語言、C++、Object-C、C++ 語言的輕量級編譯器）和 gcc 版本，一系列的運行著各種發行版的虛擬機。如果我不能確定我要使用的操作系統的包的狀態，我有時就會靜態連接庫，有時會子模塊化依賴以確保它們一直可用。大多時候，我會避免這些很棘手的問題，除非我非常需要使用他們。
基本每天都用。這是保持高效的唯一方式。我在一個項目中做的第一件事情是配置跨平台構建腳本，保證每件事盡可能自動化完成。當你面向多平台開發的時候，持續集成是至關重要的。沒有人能在一個機器上構建各種平台的不同組合，並且一旦你的構建過程沒有包含所有的平台，你就不會注意到你搞砸的事情。在一個共享式的多平台代碼庫中，不同的人擁有不同的平台和功能，所以保證質量的唯一的方法是跨團隊代碼審查結合持續集成和其他分析工具。這不同於其他的軟件項目，如果不使用相關的工具就會面臨失敗。
你依賴於自動構建測試，或者傾向於在每個平台上構建並且進行本地測試嗎？對於不包括 UI 的工具和庫，我通常使用自動構建測試。如果有 UI，兩種方法我都會用到——針對已有的 GUI 工具的可靠的、可腳本化的 UI 自動化少到幾乎沒有，所以我要麼我去針對我要跨我所支持的平台創建 UI 自動化工具，要麼手動進行測試。如果一個項目使用了定制的 UI 庫（比如說一個類似 Unity3D 的 OpenGL UI），開發可編程的自動化工具並自動化大多數工作就相當容易。不過，沒有什麼東西會像人一樣雙擊就測試出問題。
你更傾向哪種跨編輯器的構建系統？我喜歡使用跨編輯器的構建系統。我更喜歡在不同的IDE上保存項目文件（這樣可以使增加 IDE 變得更容易），通過使用構建腳本讓 IDE 在它們支持的平台上去構建。對於一個開發者來說編輯器是最重要的工具，學習它們是需要花費時間和精力的，而它們是不可相互替代的。我有我自己喜歡的編輯器和工具，每個人也可以使用他們最喜愛的工具。
在跨平台開發的時候，你更喜歡使用什麼樣的編輯器、開發環境和 IDE 呢？
跨平台開發者被限制在只能選擇可以在多數平台上工作的所共有的不多選擇之一。我愛用 Visual Studio，但是我不能依賴它完成除 Windows 平台之外的工作（你可能不想讓 Windows 成為你的主要的交叉編譯平台），所以我不會使用它作為我的主要 IDE。即使可以，跨平台開發者的核心技能也是盡可能的了解和使用大量的平台。這就意味著必須很熟悉它們——使用該平台上的編輯器和庫，了解這種操作系統及其適用場景、運行方式以及它的局限性等。做這些事情就需要頭腦清醒（我的捷徑是加強記憶），我必須依賴跨平台的編輯器。所以我使用 Emacs 和 Sublime。
你之前和現在最喜歡的跨平台項目是什麼？我一直很喜歡 Mono，並且得心應手，其它的項目大部分都是以某種方式圍繞著它進行的。Gluezilla 是我在多年前開發的一個 Mozilla 綁定，可以把 C# 開發的應用嵌入到 Web 浏覽器頁面中，並且看起來很有特色。我開發過一個 Winform 應用，它是在 linux 上開發的，它可以在 Windows 上運行在一個 Mozilla 浏覽器頁面裡嵌入的 GTK 視圖中。CppSharp 項目（以前叫做 Cxxi，更早時叫做 CppInterop）是一個我開始為 C++ 庫生成 C# 綁定的項目，這樣就可以在 C# 中調用、創建實例、子類化 C++ 類。這樣，它在運行的時候就能夠檢測到所使用的平台，以及用來創建本地運行庫的是什麼編譯器，並為它生成正確的 C# 綁定。這多麼有趣啊。
你怎樣看跨平台開發的未來趨勢呢？我們構建本地應用程序的方式已經改變了，我感覺在各種桌面操作系統的明顯差異在慢慢變得模糊；所以構建跨平台的應用程序將會更加容易，而且對系統的集成也不需要完全本地化。不好的是，這可能意味著應用程序易用性更糟，並且在發揮操作系統特性方面所能做的更少。庫、工具以及運行環境的跨平台開發是一種我們知道怎樣做的更好，但是跨平台應用程序的開發仍然需要我們的努力。
原文來自：https://linux.cn:443/article-7743-1.html
本文地址：http://www.linuxprobe.com/cross-paltform-talk.html
http://xxxxxx/Linuxjc/1184570.html TechArticle
