A. java的api 有哪些常用的方法
String，數字包裝類，數組，集合類有關的各種方法，都是必須會的
B. 字元串常用的api方法有哪些
API(Application Programming Interface):應用程序編程介面
使用Scanner 獲取鍵盤錄入的字元串
next() ; 在遇到空格的時候 會判定為當前的輸入結束 空格之後的內容會收不到
nextLine(); 可以避免被空格中斷 , 但是在於接收數字一起使用的時候會被干擾
創建字元串對象
public String(String original) ---> 通過字元串創建一個字元串對象
public String(char[] value) -=--> 通過一個字元型數組創建一個字元串對象
public String(char[] value,int offset,int count)---> 通過字元型數組的一部分創建一個字元串對象 從索引值為offset開始,持續count個
==的含義
== 代表判斷兩邊是否相等
基本類型判斷是數值
引用類型判斷的是地址
通過構造方法創建字元串對象和直接賦值創建字元串對象的區別:
構造方法創建是在堆區 直接賦值是在常量池
判斷功能
boolean equals(Object obj) // 比較字元串的內容是否相等, 跟哪個字元串比較 參數就寫哪個字元串
boolean equalsIgnoreCase(String str)// 比較字元串的內容是否相等 比較的時候忽略大小寫
boolean startsWith(String str) // 判斷字元串是否以str開頭
boolean endsWith(String str) // 判斷字元串是否以str結尾
獲取的功能
int length() // 獲取字元串的長度(獲取字元串中字元的個數 )
char charAt(int index) // 根據指定的索引返回對應字元
int indexOf(String str) // 獲取str在字元串中出現的索引值 ,如果字元串中沒有str則返回 -1
String substring(int start) // 從索引值為start位置開始到字元串結尾處截取出來作為一個新串返回
String substring(int start,int end) // 截取字元串 從start開始 ,到end-1為止 生成一個新串返回
統計字元串中大寫、小寫及數字字元個數
* String s1 = "aAb0G9c1Kde";
* 字元串遍歷 判斷 定義計數器分別代表三種字元的個數
* 1.定義三個計數器分別代表三種字元的個數
* 2.遍歷字元串獲取每個字元進行判斷
* 3.一旦符合某一種字元就讓對應的計數器+1
12345678910111213141516171819
public static void main(String[] args) { // TODO Auto-generated method stub String s1 = "aAb0G9c1Kde"; // // 1.定義三個計數器分別代表三種字元的個數 int big = 0; int small = 0; int num = 0; // 2.遍歷字元串獲取每個字元進行判斷 for (int i = 0; i < s1.length(); i++) { char ch = s1.charAt(i); if (ch >= '0' && ch <= '9') { num++; } else if (ch >= 'A' && ch <= 'Z') { big++; } else if (ch >= 'a' && ch <= 'z') { small++; } } }
轉換功能方法
char[] toCharArray() ---> 把字元串轉化成數組 返回
String toLowerCase() ---> 把字元串中的數據轉化成小寫字母返回
String toUpperCase() ---> 把字元串中的數據轉化成大寫字母返回
去除空格和分割功能方法
String trim() // 去除空格 字元串兩邊的空格 , 字元串中間的空格不會去掉
String[] split(String str)// 把字元串使用str進行切割, 把切割之後得到的字元串組成一個字元串數組返回
String replaceAll(String regex,String replacement)
boolean contains(String str);
String replaceAll(String regex,String replacement)// 使用 replacement替換字元串中所有的regex
boolean contains(String str);// 判斷字元串是否包含 str 只要字元串中有Str不論幾個都會返回true 一旦沒有 ,就會返回false
StringBuilder構造方法
StringBuilder() ---> 創建一個空的SB容器
StringBuilder(String str)
StringBuilder常見方法
public int capacity()// 容器的容量
public int length() // 實際存儲的字元個數
StringBuilder的方法
public StringBuilder append(任意類型)// 任何類型的數據都可以添加到這個容器中,最終都會以字元串的形式體現 ,調用完畢之後返回的是自己
public StringBuilder reverse() // 翻轉容器中的內容
C. 【編譯】VUI（語音用戶交互）設計基礎指南
原文地址：https://medium.muz.li/voice-user-interfaces-vui-the-ultimate-designers-guide-8756cb2578a1
筆者結合實際工作中的理解，對文章簡要編譯如下，供參考。
【補充國內的語音交互理解、國內網路、阿里、小米等平台的相關信息，配合自有資料的部分設計）
如果你使用過智能語音產品，應該也會有類似的場景。
我們的聲音是多種多樣的、復雜多變的，語音指令更難以處理 ——真人之間的對話都如此，更何況計算機了。我們的思維方式、文化背景、俚語簡稱和推理形式等等因素，只要有細微差別都會影響到聽著的語意理解。
那麼，設計師和工程師要如何應對這一挑戰呢？我們應如何培養用戶與AI之間的信任？這正是VUI的關鍵所在。
VUI是指，使用語音來實現人與設備實現交互的界面（語音可以是唯一的交互方式，也可以是對視覺和觸覺的補充）。VUI可以是任何東西——聽音樂時的氛圍燈光到汽車的娛樂控制中心。 VUI完全可以沒有界面，只依靠聽覺、觸覺或運動等方式來實現交互。
VUI的形式很多、載體豐富，但都具有相同的UX基礎知識。設計師們藉助對這些基礎知識的理解，從用戶視角分析日常語音交互的方式，就可以構建更好的語音交互體驗。
當前技術、環境和社會約束對我們如何與世界相處有極大的影響——它們會影響我們處理信息的速度、將數據轉化為行動的准確性、彼此交流信息的方式方法。
在開始語音交互設計之前，我們必須對語音交互的環境背景有所了解。
設備類型直接影響語音交互的模式，限制了語音輸入的范圍（深度和廣度）。
手機
手機品牌：iPhones、Pixels、Galaxies、華為、小米……
連接方式：蜂窩數據網路、Wi-Fi、藍牙配對……
使用環境：環境背景對語音交互的重大影響
用戶習慣：用戶習慣使用語音交互
支持視覺、聽覺和觸覺反饋的多通道互動模式
各個模式中的交互形式相當標准化
穿戴式設備
特定的用例：如手錶、健身手環或智能鞋
連接方式：蜂窩數據網路、Wi-Fi、藍牙配對……
用戶習慣：用戶可能習慣使用語音交互，但這種交互在設備上是非標準的
穿戴式設備支持視覺、聽覺和觸覺方式進行反饋——盡管某些設備是被動式的、可交互性較弱。
用戶的交互和數據消費，通常依賴於所連接的設備。
固定式連接設備
設備示例：台式電腦、帶屏幕的電器、恆溫器、智能家居控制中心、音響系統和電視等等
連接方式：有線網路、Wi-Fi、藍牙配對……
用戶習慣於在同樣的位置，保持設備設置不變來進行互動
在不同設備之間使用相似的標准化語音交互方式（如台式計算機與智能家居，如Google Home ；Amazon Alexa與智能恆溫器，其交互方式就沒明顯區別）
非固定計算設備（除手機外）
設備示例：筆記本電腦、平板電腦、轉發器，汽車信息娛樂系統
連接方式： 無線網路，有線網路（不常見），Wi-Fi，藍牙配對……
主要的輸入方式不是語音
環境背景對語音交互行有重大影響
不同設備間的交互方式通常是非標准化的
語音交互的主要、次要和第三用例是什麼？該設備是否有主要用例（如健身追蹤器）？或者它有多個用例組合（如智能手機）？
創建用例矩陣非常重要，它將幫助你確定用戶與設備發生交互的原因。他們的主要交互模式是什麼？什麼是次要的？什麼樣的交互模式是好的，什麼是必不可少的？
您可以為每種交互模式創建用例矩陣。應用於語音交互時，矩陣將幫助您了解用戶當前使用或想要使用的語音交互方式——包括他們使用語音助手的位置：
如果想要使用用戶研究來豐富你對用例的理解（使用情況或原始量子/質量研究），那麼藉助你的研究來對各語音交互模式進行排序就非常重要了。
如果有人告訴你：「如果我可以和電視對話，並讓它切換頻道，那簡直太酷了！」 那麼你真的需要深入挖掘：他們真的會用嗎？他們已經知道設備的限制嗎？他們真的了解自己傾向於使用的功能嗎？
舉個例子，假設我們正在評估用戶是否會使用語音命令與電視進行交互。這種情況下，最安全的假設是用戶有很多選擇——而語音交互只是其中一種。
用戶可以有很多的備選方案：遠程式控制制、配對的智能手機，游戲控制器或已連接的物聯網設備。所以說，語音交互未必會是默認的交互方式，而只是眾多方式的一種。
此時我們的問題就變成了：用戶將語音交互作為最主要交互方式的可能性有多大？如果不是主要交互方式，它會是次要方式嗎？抑或者是第三次葯方式？這會讓你的假設得到更深入的驗證。
將我們的語言轉化為行動是一項極其困難的技術挑戰。通過無數的時間、連接和訓練，調整良好的計算引擎模型能夠很好地識別我們地語音並觸發相應的操作。
不幸的是，我們還無法實現完全無縫的連接、時間也是有限的。我們希望語音交互與傳統視覺或觸覺這樣的替代方案一樣直接——即使語音引擎的處理和預測模型需要更為復雜。
下圖展示了語音識別的流程：
如圖可見，許多模型都需要不斷訓練才能完成對我們的詞彙、口音、聲調等等要素的識別。
每個語音識別平台都有其獨特的技術特徵和限制。我們在設計語音交互產品時，必須接受這些約束。
主要的約束有以下幾類：
連接級別： 設備是否能始終聯網
加工速度： 用戶的語音是否被實時處理？
加工進度： 在精準度和速度上，如何平衡才好？
語音模型： 我們目前模型訓練得有多好？我們能夠處理整段的長句、還是智能識別簡短的單詞？
後備選擇： 如果語音無法識別，有什麼後備方案？用戶是否可以使用其他交互方式？
錯誤代價： 用戶指令被錯誤處理時會導致不可逆轉的後果嗎？我們的語音識別引擎是否足夠成熟，能夠有效避免嚴重錯誤的發生？
環境測試： 語音引擎是否在多種不同的環境中測試過？例如，做汽車信息娛樂系統所處的環境，就比家裡的智能恆溫器有更多的干擾因素。
我們還應考慮用戶能夠以非線性的方式與設備交互。例如，如果我要在網站上預定機票，就必須遵循網站設定好的預定流程，選擇或者輸入網站要求的信息：選擇目的地、選擇日期、選擇門票數量、查看選項……
而VUI面臨著更大的挑戰。用戶可以說「我想訂飛往舊金山的商務艙」，然後VUI就必須從用戶的這句話中提取相關信息，以便利用現有的API完成航班預定。整個邏輯的順序是被打亂的，VUI有責任從用戶這里提取到更多的相關信息——方式可能是語音的、視覺的、或者自動獲取設備位置信息、個人賬戶等等。
現在我們已經了解了VUI設計所面臨的約束、依賴和用例。現在讓我們開始深入探討實際的VUI設計吧。
我們首先要探討的是，設備是如何知道，應該在什麼時候去傾聽用戶？
下圖展示了語音交互體驗的基本流程：
在界面上的展現示例如下：
有四種語音輸入的觸發器：
語音觸發器： 用戶將發出特定的短語，提示設備開始處理語音（「Ok Google」）
觸覺觸發器： 按下按鈕（物理或數字）或切換控制項（例如麥克風圖標）
動作觸發器： 在感測器前揮舞手臂等
設備自觸發： 通過預先設定的條件（指定時間、地點，任務提醒或其他觸發條件）來觸發設備的響應
設計師必須了解，哪些觸發器與你的用例相關；並對各類觸發器與你用例的相關性進行排序。
通常，在觸發設備偵聽之時，會有聽覺、視覺或觸覺提示。這些提示應遵循以下可用性原則：
即時反饋： 觸發後，應該盡快呈現引導線索，即使這可能會中斷當前的操作（只要這種中斷不具有破壞性）。
精確簡短： 引導提示應該是瞬間完成的，特別是常見的設備。例如，兩個肯定的嗶嗶聲比「OK Justin，需要我給你做什麼？」要好。引導提示越長，用戶的話就越可能與設備提示相沖突。這個原則也適用於視覺線索，屏幕應立即轉變為聆聽狀態。
清晰的開始： 用戶應確切地知道他們的聲音是什麼時候開始被錄制的。
一致性： 引導線索應始終相同。聲音或視覺反饋的不一致，會讓用戶感到困惑。
可識別： 引導線索應該與設備正常的聲音和視覺效果有所不同，絕不應該在任何其他環境中使用或重復出現。
補充提示： 如有可能，請利用多種方式來呈現提示（如同時出現：兩聲嗶嗶聲，一次燈光閃爍、一次屏幕對話）。
首用提示： 對於第一次使用的用戶、或用戶似乎遇到卡住了，你可以提供首用提示/建議來引導對話繼續下去。
反饋對於成功的VUI至關重要，它讓用戶明確知道自己的話被設備提取和處理，還允許用戶採取糾正措施或繼續對話。
以下是提供良好VUI反饋體驗的可用性原則：
實時響應式的視覺反饋： 視覺反饋在手機這樣的原生的語音設備最為常見。視覺上都可以實時地改變顏色或模式來傳達出聲音的認知反饋——音高、音色、音強和持續時間。
聲音反饋： 以簡短的音頻播放來給予反饋
實時文本 ：跟隨用戶的說話，在屏幕上實時顯示出來
輸出文本 ：用戶說完後呈現文本，供用戶轉換和修改。這可以在執行用戶指令之前提供一道糾正機會。
燈光等非屏幕視覺提示 ：前面提到的響應式視覺效果不僅限於設備屏幕，也可以有LED燈或燈光模式。
結束提示告知用戶，設備此時已經不再偵聽用戶的聲音了。很多主要提示的原則同樣適用（如即時性、簡短、清晰、一致性和差異性），但依然有一些額外的設計原則：
充足的時間 ：確保用戶有足夠的時間下達指令
自適應時間 ：分配的響應時間要與用例和用戶預期相適應。例如，當用戶被問到「是否式」的問題時，就應在問題最後一個音節播放後，提供合理的暫停。
合理的暫停： 自上次錄音完成之後，經過了合理的時間了嗎？這涉及到比較復雜的計算，但也受上下文的用例影響。
像「打開我的鬧鍾」這樣的簡單命令不一定需要冗長的對話，但更復雜的命令卻需要。與傳統的人-人對話不同，人-智能設備之間需要額外的確認、冗餘和糾正（嚴格來講，這些在人-人對話中依然存在，只是幾率小、不會有明確的設定）。
更復雜的命令、或多輪對話通常需要多論的語音/選項驗證來確保對話的准確性。當用戶並不確定應該如何發出指令時，問句會變得更為復雜。解密用戶消息並引導用戶提供更多的上下文信息就成為VUI的重要任務。
肯定性： 當AI理解了用戶的語音時，就應該給出肯定性的回復和確認音。例如，人工智慧不是說「當然」而是「當然，我會把燈關掉」或「你確定要關燈嗎？」
糾正： 當AI無法理解用戶意圖時，就應使用糾正選項來回應——這允許用戶作出選擇或者完全重新開始。
移情： 當AI無法滿足用戶請求時，它就應坦誠自己無法滿足用戶、並提供備選項。移情對我們向用戶提供個性化的服務非常重要。
為語音交互賦予擬人化的特徵，使我們建立起人-設備的關系。這種擬人化特徵可以以燈光、彈跳的球形、抽樣圖案，機器聲音等等。
擬人化特徵讓用戶和機器之間建立了更緊密的聯系，也可以在不同平台的不同智能產品上建立類似的聯系（如Google Assistant、亞馬遜的Alexa和Apple的Siri）。
個性 ：為交互帶來額外維度，虛擬個性幫助我們與用戶建立聯系和移情。有助於減輕語音處理錯誤帶來的負面影響。
積極性 ：通常使用積極性鼓勵反復互動，使用肯定的語調。
信心和信任 ：鼓勵額外的互動和復雜的對話，讓用戶有信心獲得積極和更有價值的結果。
語音交互應該是流動和動態的。在我們的真實對話中，通常會伴隨著無數的面部表情、語氣語調、肢體語言和身體運動。要將真實對話中的這么豐富的信心轉換到數字世界中，是很大的挑戰。
如果可能，整個語音交互體驗應該感覺像是一種有益的互動。當然，簡短互動（如「關燈」）並不一定需要有完整的關系。然而，任何類型的更復雜的互動（如藉助智能助手完成烹飪）卻需要很長時間的對話。
有效的語音交互體驗將受益於以下原則：
無縫切換 ：無縫實現不同狀態之間的轉換。用戶應該感知到他們永遠不許等待，智能助手正在為他工作。
鮮艷 ：鮮艷的色彩傳達了喜悅和未來主義。它為互動增添了優雅的未來主義元素 - 鼓勵反復的互動。
響應 ：響應用戶輸入和手勢。提示出當前正在處理的指令、允許用戶查看他們的語音/意圖是否被准確地理解。
VUI是非常復雜、多維度的，通常是多模態的交互。事實上它還沒有一個全面的定義。最重要的是，日益數字化的世界意味著我們將在各類設備上花越來越多的時間、比我們彼此之間的交流要多得多。VUI會是我們與世界互動的主要手段嗎？讓我們拭目以待。
與此同時，您是否想要打算構建世界級的VUI？以下是一些有用的資源：
How to Design Voice User Interfaces | Interaction Design Foundation
What Is a Voice User Interface (VUI)? An Introction | Amazon Developers
Voice Actions | Google Developers
SiriKit | Apple Developers
Designing a VUI by Frederik Goossens
A Guide to Voice User Interfaces by Fjord