[254] JUCE 2019 年使用者調查結果

JUCE 團隊在 2019 年初發出一份使用者問卷，官方公佈了調查結果以及分析。本文說明調查結果，以及由我的角度來看這份報告所代表的意義。

首先，官方的問卷調查把使用者以使用授權分成三類：Non-paying, Indies, Pros。

第一個問題是：

你拿 JUCE 做什麼？

由下圖可以看到，JUCE 較常被使用的的領域依然以音樂類型為大宗，跟第二名相比，差距甚大：

第二個問題是：

你希望 JUCE 團隊將未來的開發重點放在哪一個面向？

Indie and Pro 授權用家最希望 GUI rendering performance 獲得改善。而免費用家（Non-paying）則比較重視文件以及教學資源。

文件以及教學資源缺乏一直是 JUCE 的痛，這一點讓新手很受傷，特別是 C++ 程式設計底子不穩的新手。中文的學習資源更是慘上加慘，慘不忍睹。說到這，我正在寫《跨平台應用程式開發使用 JUCE 以及 C++》，進度嚴重落後。😭

第八點－Native GUI widgets，我也覺得有需要。不過，JUCE 設計初衷是針對 DAW 外掛開發，這些外掛最大的特色是，外觀長得跟系統原生的控制項不一樣。

第九點－Testing system integration。我目前主要的 Unit Test 框架是 Catch2，我希望 Visual Studio 能早日整合 Catch2，這點跟 JUCE 比較沒關係。

第十七點很有趣，The JUCE module ecosystem，就是讓開發者撰寫獨立的 JUCE  Module，然後用來賣錢，也就是軟體市集的概念。就我的觀察，目前的 JUCE 生態要做這樣的市集，時間點還太早。一來 JUCE  的使用人口數相當少，二來多在音樂領域，目標族群小，開發者投入市集的吸引力低，較難形成正向循環。

真要推軟體市集，那麼第十八點的 JUCE module format 就必須考慮進去。目前的 JUCE module 以原始碼的形式散佈，不利於推廣付費市集。

第十九點—Accessibility，也就是針對殘疾人士設計的功能，如全鍵盤操作以及  Narrator。最近接到一個案子有這樣的需求，臨床實驗證實，JUCE 目前完全不支援 Accessibility。不過，好消息是，整合  Windows MSAA 功能不算太難。

第二十點是 UWP Support，JUCE 論壇上有人成功實作了可以上架到 Microsoft Store 上的 JUCE 應用程式。不過，我對這點需求不怎麼強烈。若是要開發 UWP app，我會選擇 C++/WinRT 或者 .NET。

第三個問題是：

你還希望 JUCE 要補強哪一方面？ (Are there any other ways that JUCE could be improved for you?)

非付費用戶渴望支援「GUI design tools in the Projucer」，恐怕跟 JUCE 團隊的方向不一致。其實舊版 Projucer 支援類似 WYSIWYG 的設計介面，但表現不佳，而且產生出來的程式碼有諸多限制，以 Jules 的高標準，絕對沒辦法接受。後來的版本功能雖然還在，但早以年久失修，官方也建議不要使用該設計介面。

付費的 Indie 用家提出一個需求：A GUI markup language。其實，JUCE 目前的版本支援了 FlexBox，一種類似網頁設計的架構。FlexBox Grid 的設計讓 UI 版面設計與開發的彈性大，但開發成本不會增加太多：

我自己的前三名是：

1. GUI improvements
2. Support for precompiled headers (PCH)
3. Font and rendering (Direct2D and DirectWrite)

多年前一個運作於 WIndows 平台的平板電腦 Kiosk 專案，需要支援「觸控輸入」。我們使用 JUCE 開發，那次經驗䮴了 JUCE  在觸控處理的不足，直至專案結束，我們使用的解決方案雖然能應付當下的需求，但 JUCE 做為一個開發框架，觸控輸入的處理不及格。

更糟的是，JUCE 團隊似乎認為「觸控輸入優化」不屬高優先權，回報問題後不見積極處理。或許跟整體架構有關，這我不得而知。未來，在遇到觸控需求時，我會盡力避開。

JUCE 框架以原始碼散佈，也就是編譯專案時，會先編譯用到的 JUCE 模組，之後才是編譯自己的程式碼。而 JUCE 專案不支援  Pre-Compiled Header (PCH)，使得完全編譯時的要耗費較長的時間。因此，讓 JUCE 支援 PCH  是我希望團隊補強的重要功能。

同前一個需求，若能將 JUCE 編譯成 Static Library，在多個專案的環境中，只要編譯一次 JUCE 原始碼，其他專案只需連結至產生的靜態連結檔即可。省時又有效率。

JUCE 開發者使用 macOS 的人數多於 Windows，但相差只有幾個百分比。步署的環境也以 macOS 居多，同樣與 Windows 也相差不大：

開發的應用程式類型以 Desktop 以及 Audio plug-ins 為大宗，這點不意外。雖然 JUCE 也支援 Android / iOS 開發，但其易用性不如其他開發工具。不過，由佔比來看，其實 Mobile apps 的比例不算低了：

問到使用 JUCE 的開發團隊大小，獨立作戰的「硬地（Indie）」人佔多數，而大於五人的團隊比例相當低：

問到是否能接受 JUCE 在導入 Modern C++ 規格時，不往前相容的接受度，大多數開發者能接受。（我也舉雙手贊成）：

截至目前為止，JUCE 論壇還是我主要發問以及尋找答案的管道。官方的回應速度蠻快，而且有不少熱心人士會幫忙回答。所以要學 JUCE 必定不能放過其論壇：

其實我覺得 JUCE API 文件的品質不算太差，多數時候我能透過該文件找到想要的答案。不過，我覺得這個問題的答案反應的比較像：JUCE 的參考資源相對少。

我相信多數開發者選擇 JUCE 的原因，「介面簡單易用」絕對佔了很大比例。問卷調查也確實反應了這一點。

JUCE 採取雙授權，商用版本有訂閱制，也有買斷制。我們買的是「硬地」訂閱授權（JUCE Indie），CP 值不錯。對小公司會有負擔，但也不至於付不起。

最後一個問題問道：

你是否願意將 JUCE 推薦到大學？

我願意。多數開發者都願意。事實上，我希望在台灣推薦 JUCE，建了一個 JUCE Tips 站，內容還很少，但我會持續增加。也有計劃以影片以及書本的方式，好好介紹 JUCE 這個好學易用的開源碼，跨平台 C++ 應用程式開發框架。