人從07年開始使用Eclipse,掐指一算已經快十五年了。最近工作交流中,因為沒用使用IDEA而被新人調侃,于是乎我就自己花了半天時間試用了一下IDEA并簡單總結了一下IDEA的基礎使用方法,希望與仍舊使用Eclipse的同仁們共享!這里關于Intellij IDEA與Eclipse的UI不做任何評論!強調一下本文更適合有Eclipse編碼經驗的同學,我完全以Eclipse轉型IDEA的用戶視角編寫此文,介紹了二者的主要區別、IDEA如何創建工程和模塊,插件安裝方法、常見快捷鍵、如何調試代碼、maven和git的使用。至于網上大量同學評論說IDEA效率如何如何之高,在這里本人先不做任何評論,待我熟悉IDEA之后再做總結。
1. IDEA社區版免費(只做基礎的Java開發),專業版收費;Eclipse完全免費
2.核心概念區別
Intellij IDEA沒有workspace的概念
Intellij IDEA中的Project相當于Eclipse中的workspace
Intellij IDEA中的Module相當于Eclipse中的Project
Intellij IDEA中一個Project可以包括多個Module
Eclipse中一個W orkspace可以包括多個Project
Intellij IDEA:每個屏幕只能有一個項目
Eclipse:可以有多個項目,自由度更大
導入新的Project或者Module
一個project中可以創建多個module,包括普通的Java module 和maven module,如下圖:
File>Settings>Editor>File Encodings如下圖
File>Settings>Plugins
安裝插件
1.在上圖中,選擇Marketplace,直接搜索安裝
2.去插件市場(https://plugins.jetbrains.com)下載,找到需要的插件,如果IDEA是開啟的則會自動安裝安裝插件到IDEA。
File>Settings>Keymap
查看快捷鍵的使用
常用語句縮寫如下:
縮寫 生成代碼
psvm public static void main(String[] args){}
sout System.out.println()
souf System.out.printf()
fori for (int i=0; i < ; i++) { }
File->settings->搜索maven
Maven home directory--設置maven安裝包的bin文件夾所在的位置
User settings file--設置setting文件所在的位置
Local repository--設置本地倉庫
Maven的依賴包可以在External Libraries中顯示,如下圖:
IDEA在代碼調試方面做得確實比Eclipse簡單易用,這里給點贊!
在左邊行號欄單擊左鍵即添加斷點,調試界面如下:
File->settings->搜索Git,如果開發機安裝了Git會自動識別
代碼中使用Git通過VCS,如下圖所示:
性能優化一向是后端服務優化的重點,但是線上性能故障問題不是經常出現,或者受限于業務產品,根本就沒辦法出現性能問題,包括筆者自己遇到的性能問題也不多,所以為了提前儲備知識,當出現問題的時候不會手忙腳亂,我們本篇文章來模擬下常見的幾個Java性能故障,來學習怎么去分析和定位。
既然是定位問題,肯定是需要借助工具,我們先了解下需要哪些工具可以幫忙定位問題。
top命令
top命令使我們最常用的Linux命令之一,它可以實時的顯示當前正在執行的進程的CPU使用率,內存使用率等系統信息。top -Hp pid 可以查看線程的系統資源使用情況。
vmstat命令
vmstat是一個指定周期和采集次數的虛擬內存檢測工具,可以統計內存,CPU,swap的使用情況,它還有一個重要的常用功能,用來觀察進程的上下文切換。字段說明如下:
pidstat命令
pidstat 是 Sysstat 中的一個組件,也是一款功能強大的性能監測工具,top 和 vmstat 兩個命令都是監測進程的內存、CPU 以及 I/O 使用情況,而 pidstat 命令可以檢測到線程級別的。pidstat命令線程切換字段說明如下:
jstack命令
jstack是JDK工具命令,它是一種線程堆棧分析工具,最常用的功能就是使用 jstack pid 命令查看線程的堆棧信息,也經常用來排除死鎖情況。
jstat 命令
它可以檢測Java程序運行的實時情況,包括堆內存信息和垃圾回收信息,我們常常用來查看程序垃圾回收情況。常用的命令是jstat -gc pid。信息字段說明如下:
jmap命令
jmap也是JDK工具命令,他可以查看堆內存的初始化信息以及堆內存的使用情況,還可以生成dump文件來進行詳細分析。查看堆內存情況命令jmap -heap pid。
mat內存工具
MAT(Memory Analyzer Tool)工具是eclipse的一個插件(MAT也可以單獨使用),它分析大內存的dump文件時,可以非常直觀的看到各個對象在堆空間中所占用的內存大小、類實例數量、對象引用關系、利用OQL對象查詢,以及可以很方便的找出對象GC Roots的相關信息。下載地址可以點擊這里
基礎環境jdk1.8,采用SpringBoot框架來寫幾個接口來觸發模擬場景,首先是模擬CPU占滿情況
模擬CPU占滿還是比較簡單,直接寫一個死循環計算消耗CPU即可。
/**
* 模擬CPU占滿
*/
@GetMapping("/cpu/loop")
public void testCPULoop() throws InterruptedException {
System.out.println("請求cpu死循環");
Thread.currentThread().setName("loop-thread-cpu");
int num=0;
while (true) {
num++;
if (num==Integer.MAX_VALUE) {
System.out.println("reset");
}
num=0;
}
}
請求接口地址測試curl localhost:8080/cpu/loop,發現CPU立馬飆升到100%
通過執行top -Hp 32805 查看Java線程情況
執行 printf '%x' 32826 獲取16進制的線程id,用于dump信息查詢,結果為 803a。最后我們執行jstack 32805 |grep -A 20 803a 來查看下詳細的dump信息。
這里dump信息直接定位出了問題方法以及代碼行,這就定位出了CPU占滿的問題。
模擬內存泄漏借助了ThreadLocal對象來完成,ThreadLocal是一個線程私有變量,可以綁定到線程上,在整個線程的生命周期都會存在,但是由于ThreadLocal的特殊性,ThreadLocal是基于ThreadLocalMap實現的,ThreadLocalMap的Entry繼承WeakReference,而Entry的Key是WeakReference的封裝,換句話說Key就是弱引用,弱引用在下次GC之后就會被回收,如果ThreadLocal在set之后不進行后續的操作,因為GC會把Key清除掉,但是Value由于線程還在存活,所以Value一直不會被回收,最后就會發生內存泄漏。
/**
* 模擬內存泄漏
*/
@GetMapping(value="/memory/leak")
public String leak() {
System.out.println("模擬內存泄漏");
ThreadLocal<Byte[]> localVariable=new ThreadLocal<Byte[]>();
localVariable.set(new Byte[4096 * 1024]);// 為線程添加變量
return "ok";
}
我們給啟動加上堆內存大小限制,同時設置內存溢出的時候輸出堆??煺詹⑤敵鋈罩?。
java -jar -Xms500m -Xmx500m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/heapdump.hprof -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -Xloggc:/tmp/heaplog.log analysis-demo-0.0.1-SNAPSHOT.jar
啟動成功后我們循環執行100次,for i in {1..500}; do curl localhost:8080/memory/leak;done,還沒執行完畢,系統已經返回500錯誤了。查看系統日志出現了如下異常:
java.lang.OutOfMemoryError: Java heap space
我們用jstat -gc pid 命令來看看程序的GC情況。
很明顯,內存溢出了,堆內存經過45次 Full Gc 之后都沒釋放出可用內存,這說明當前堆內存中的對象都是存活的,有GC Roots引用,無法回收。那是什么原因導致內存溢出呢?是不是我只要加大內存就行了呢?如果是普通的內存溢出也許擴大內存就行了,但是如果是內存泄漏的話,擴大的內存不一會就會被占滿,所以我們還需要確定是不是內存泄漏。我們之前保存了堆 Dump 文件,這個時候借助我們的MAT工具來分析下。導入工具選擇Leak Suspects Report,工具直接就會給你列出問題報告。
這里已經列出了可疑的4個內存泄漏問題,我們點擊其中一個查看詳情。
這里已經指出了內存被線程占用了接近50M的內存,占用的對象就是ThreadLocal。如果想詳細的通過手動去分析的話,可以點擊Histogram,查看最大的對象占用是誰,然后再分析它的引用關系,即可確定是誰導致的內存溢出。
上圖發現占用內存最大的對象是一個Byte數組,我們看看它到底被那個GC Root引用導致沒有被回收。按照上圖紅框操作指引,結果如下圖:
我們發現Byte數組是被線程對象引用的,圖中也標明,Byte數組對像的GC Root是線程,所以它是不會被回收的,展開詳細信息查看,我們發現最終的內存占用對象是被ThreadLocal對象占據了。這也和MAT工具自動幫我們分析的結果一致。
死鎖會導致耗盡線程資源,占用內存,表現就是內存占用升高,CPU不一定會飆升(看場景決定),如果是直接new線程,會導致JVM內存被耗盡,報無法創建線程的錯誤,這也是體現了使用線程池的好處。
ExecutorService service=new ThreadPoolExecutor(4, 10,
0, TimeUnit.SECONDS, new LinkedBlockingQueue<Runnable>(1024),
Executors.defaultThreadFactory(),
new ThreadPoolExecutor.AbortPolicy());
/**
* 模擬死鎖
*/
@GetMapping("/cpu/test")
public String testCPU() throws InterruptedException {
System.out.println("請求cpu");
Object lock1=new Object();
Object lock2=new Object();
service.submit(new DeadLockThread(lock1, lock2), "deadLookThread-" + new Random().nextInt());
service.submit(new DeadLockThread(lock2, lock1), "deadLookThread-" + new Random().nextInt());
return "ok";
}
public class DeadLockThread implements Runnable {
private Object lock1;
private Object lock2;
public DeadLockThread(Object lock1, Object lock2) {
this.lock1=lock1;
this.lock2=lock2;
}
@Override
public void run() {
synchronized (lock2) {
System.out.println(Thread.currentThread().getName()+"get lock2 and wait lock1");
try {
TimeUnit.MILLISECONDS.sleep(2000);
} catch (InterruptedException e) {
e.printStackTrace();
}
synchronized (lock1) {
System.out.println(Thread.currentThread().getName()+"get lock1 and lock2 ");
}
}
}
}
我們循環請求接口2000次,發現不一會系統就出現了日志錯誤,線程池和隊列都滿了,由于我選擇的當隊列滿了就拒絕的策略,所以系統直接拋出異常。
java.util.concurrent.RejectedExecutionException: Task java.util.concurrent.FutureTask@2760298 rejected from java.util.concurrent.ThreadPoolExecutor@7ea7cd51[Running, pool size=10, active threads=10, queued tasks=1024, completed tasks=846]
通過ps -ef|grep java命令找出 Java 進程 pid,執行jstack pid 即可出現java線程堆棧信息,這里發現了5個死鎖,我們只列出其中一個,很明顯線程pool-1-thread-2鎖住了0x00000000f8387d88等待0x00000000f8387d98鎖,線程pool-1-thread-1鎖住了0x00000000f8387d98等待鎖0x00000000f8387d88,這就產生了死鎖。
Java stack information for the threads listed above:==================================================="pool-1-thread-2":
at top.luozhou.analysisdemo.controller.DeadLockThread2.run(DeadLockThread.java:30)
- waiting to lock <0x00000000f8387d98> (a java.lang.Object)
- locked <0x00000000f8387d88> (a java.lang.Object)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
"pool-1-thread-1":
at top.luozhou.analysisdemo.controller.DeadLockThread1.run(DeadLockThread.java:30)
- waiting to lock <0x00000000f8387d88> (a java.lang.Object)
- locked <0x00000000f8387d98> (a java.lang.Object)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Found 5 deadlocks.
上下文切換會導致將大量CPU時間浪費在寄存器、內核棧以及虛擬內存的保存和恢復上,導致系統整體性能下降。當你發現系統的性能出現明顯的下降時候,需要考慮是否發生了大量的線程上下文切換。
@GetMapping(value="/thread/swap")
public String theadSwap(int num) {
System.out.println("模擬線程切換");
for (int i=0; i < num; i++) {
new Thread(new ThreadSwap1(new AtomicInteger(0)),"thread-swap"+i).start();
}
return "ok";
}
public class ThreadSwap1 implements Runnable {
private AtomicInteger integer;
public ThreadSwap1(AtomicInteger integer) {
this.integer=integer;
}
@Override
public void run() {
while (true) {
integer.addAndGet(1);
Thread.yield(); //讓出CPU資源
}
}
}
這里我創建多個線程去執行基礎的原子+1操作,然后讓出 CPU 資源,理論上 CPU 就會去調度別的線程,我們請求接口創建100個線程看看效果如何,curl localhost:8080/thread/swap?num=100。接口請求成功后,我們執行`vmstat 1 10,表示每1秒打印一次,打印10次,線程切換采集結果如下:
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
101 0 128000 878384 908 468684 0 0 0 0 4071 8110498 14 86 0 0 0
100 0 128000 878384 908 468684 0 0 0 0 4065 8312463 15 85 0 0 0
100 0 128000 878384 908 468684 0 0 0 0 4107 8207718 14 87 0 0 0
100 0 128000 878384 908 468684 0 0 0 0 4083 8410174 14 86 0 0 0
100 0 128000 878384 908 468684 0 0 0 0 4083 8264377 14 86 0 0 0
100 0 128000 878384 908 468688 0 0 0 108 4182 8346826 14 86 0 0 0
這里我們關注4個指標,r,cs,us,sy。
r=100,說明等待的進程數量是100,線程有阻塞。
cs=800多萬,說明每秒上下文切換了800多萬次,這個數字相當大了。
us=14,說明用戶態占用了14%的CPU時間片去處理邏輯。
sy=86,說明內核態占用了86%的CPU,這里明顯就是做上下文切換工作了。
我們通過top命令以及top -Hp pid查看進程和線程CPU情況,發現Java線程CPU占滿了,但是線程CPU使用情況很平均,沒有某一個線程把CPU吃滿的情況。
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
87093 root 20 0 4194788 299056 13252 S 399.7 16.1 65:34.67 java
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
87189 root 20 0 4194788 299056 13252 R 4.7 16.1 0:41.11 java
87129 root 20 0 4194788 299056 13252 R 4.3 16.1 0:41.14 java
87130 root 20 0 4194788 299056 13252 R 4.3 16.1 0:40.51 java
87133 root 20 0 4194788 299056 13252 R 4.3 16.1 0:40.59 java
87134 root 20 0 4194788 299056 13252 R 4.3 16.1 0:40.95 java
結合上面用戶態CPU只使用了14%,內核態CPU占用了86%,可以基本判斷是Java程序線程上下文切換導致性能問題。
我們使用pidstat命令來看看Java進程內部的線程切換數據,執行pidstat -p 87093 -w 1 10 ,采集數據如下:
11:04:30 PM UID TGID TID cswch/s nvcswch/s Command
11:04:30 PM 0 - 87128 0.00 16.07 |__java
11:04:30 PM 0 - 87129 0.00 15.60 |__java
11:04:30 PM 0 - 87130 0.00 15.54 |__java
11:04:30 PM 0 - 87131 0.00 15.60 |__java
11:04:30 PM 0 - 87132 0.00 15.43 |__java
11:04:30 PM 0 - 87133 0.00 16.02 |__java
11:04:30 PM 0 - 87134 0.00 15.66 |__java
11:04:30 PM 0 - 87135 0.00 15.23 |__java
11:04:30 PM 0 - 87136 0.00 15.33 |__java
11:04:30 PM 0 - 87137 0.00 16.04 |__java
根據上面采集的信息,我們知道Java的線程每秒切換15次左右,正常情況下,應該是個位數或者小數。結合這些信息我們可以斷定Java線程開啟過多,導致頻繁上下文切換,從而影響了整體性能。
為什么系統的上下文切換是每秒800多萬,而 Java 進程中的某一個線程切換才15次左右?
系統上下文切換分為三種情況:
1、多任務:在多任務環境中,一個進程被切換出CPU,運行另外一個進程,這里會發生上下文切換。
2、中斷處理:發生中斷時,硬件會切換上下文。在vmstat命令中是in
3、用戶和內核模式切換:當操作系統中需要在用戶模式和內核模式之間進行轉換時,需要進行上下文切換,比如進行系統函數調用。
Linux 為每個 CPU 維護了一個就緒隊列,將活躍進程按照優先級和等待 CPU 的時間排序,然后選擇最需要 CPU 的進程,也就是優先級最高和等待 CPU 時間最長的進程來運行。也就是vmstat命令中的r。
那么,進程在什么時候才會被調度到 CPU 上運行呢?
結合我們之前的內容分析,阻塞的就緒隊列是100左右,而我們的CPU只有4核,這部分原因造成的上下文切換就可能會相當高,再加上中斷次數是4000左右和系統的函數調用等,整個系統的上下文切換到800萬也不足為奇了。Java內部的線程切換才15次,是因為線程使用Thread.yield()來讓出CPU資源,但是CPU有可能繼續調度該線程,這個時候線程之間并沒有切換,這也是為什么內部的某個線程切換次數并不是非常大的原因。
本文模擬了常見的性能問題場景,分析了如何定位CPU100%、內存泄漏、死鎖、線程頻繁切換問題。分析問題我們需要做好兩件事,第一,掌握基本的原理,第二,借助好工具。本文也列舉了分析問題的常用工具和命令,希望對你解決問題有所幫助。當然真正的線上環境可能十分復雜,并沒有模擬的環境那么簡單,但是原理是一樣的,問題的表現也是類似的,我們重點抓住原理,活學活用,相信復雜的線上問題也可以順利解決。
1、https://linux.die.net/man/1/pidstat
2、https://linux.die.net/man/8/vmstat
3、https://help.eclipse.org/2020-03/index.jsp?topic=/org.eclipse.mat.ui.help/welcome.html
原文:https://my.oschina.net/luozhou/blog/4253601
作者:木木匠
1 marquee跑馬燈
2 progress進度條
3 rating評分條
4 slider滑動條
5 switch開關選擇器
前面的章節已經介紹了全部容器組件和基礎組件Text、Button、Input、Picker、Image,本章節將進一步介紹鴻蒙應用程序開發的方舟界面(ArkUI)框架中前面章節中沒有介紹到的全部基礎組件,了解其基本用法。這樣就可以在以后的實際項目開發中做到心中有數。
跑馬燈組件,用于展示一段單行滾動的文字。
支持設備:手機,平板,智慧屏,智能穿戴
1 屬性:跑馬燈除支持通用屬性外,還有3個屬性
名稱 | 類型 | 默認值 | 必填 | 描述 |
scrollamount | number | 6 | 否 | 跑馬燈每次滾動時移動的最大長度。 |
loop | number | -1 | 否 | 跑馬燈滾動的次數。如果未指定,則默認值為-1,當該值小于等于零時表示marquee將連續滾動。 |
direction | string | left | 否 | 設置跑馬燈的文字滾動方向,可選值為left和right。 |
2 樣式:除通用樣式外,跑馬燈還支持如下樣式
color:設置跑馬燈中文字的文本顏色。
font-size:設置跑馬燈中文字的文本尺寸。
allow-scale:設置跑馬燈中文字的文本尺寸是否跟隨系統設置字體縮放尺寸進行放大縮小。
font-weight:設置跑馬燈中文字的字體的粗細。
font-family:設置跑馬燈中文字的字體列表,用逗號分隔,每個字體用字體名或者字體族名設置。列表中第一個系統中存在的或者通過自定義字體指定的字體,會被選中作為文本的字體。
3 事件:除支持通用事件外,還支持如下事件
名稱 | 參數 | 描述 |
bounce(Rich) | - | 當文本滾動到末尾時觸發該事件。 |
finish(Rich) | - | 當完成滾動次數時觸發該事件。需要在 loop 屬性值大于 0 時觸發。 |
start(Rich) | - | 當文本滾動開始時觸發該事件。 |
4 方法:除支持通用方法外,還支持如下方法
start:開始滾動。
stop:停止滾動。
5 示例
<!-- marqueepage.hml -->
<div class="container">
<marquee id="marquee" class="marquee" scrollamount="{{ scrollAmount }}"
loop="{{ loopTimes }}" direction="{{ direction }}" @bounce="marqueeBounce"
@start="marqueeStart" @finish="marqueeFinish">{{ marqueeData }}</marquee>
<div class="buttons">
<button class="control" @click="startMarquee">開始</button>
<button class="control" @click="stopMarquee">停止</button>
</div>
</div>
/* marqueepage.css */
.container {
flex-direction: column;
justify-content: center;
align-items: center;
}
.marquee {
width: 100%;
height: 80px;
padding: 10px;
margin: 20px;
border: 4px solid #ff8888;
border-radius: 20px;
font-size: 40px;
font-weight: bolder;
font-family: sans-serif;
}
.buttons {
flex-direction: row;
justify-content: center;
}
.control {
width: 88px;
height: 40px;
margin: 5px;
font-size: 30px;
}
// marqueepage.js
import prompt from '@system.prompt';
export default {
data: {
scrollAmount: 10,
loop: 3,
direction: 'left',
marqueeData: '我是跑馬燈'
},
marqueeBounce() {
prompt.showToast({
message: '我滾動到末尾了'
});
},
marqueeStart() {
prompt.showToast({
message: '我開始滾動了'
});
},
marqueeFinish() {
prompt.showToast({
message: '我完成了滾動次數'
});
},
startMarquee() {
this.$element('marquee').start();
},
stopMarquee() {
this.$element('marquee').stop();
}
}
說明:不知道這里為什么bounce和finish兩個事件沒起到效果。
用于顯示內容加載或操作處理進度。
進度條的類型通過屬性type定義,有如下取值:
屬性percent定義當前進度,secondarypercent屬性定義次級進度。
示例
<!-- progresspage.hml -->
<div class="container">
<progress class="progress" type="scale-ring" percent="10" secondarypercent="50"></progress>
<progress class="progress" type="horizontal" percent="10" secondarypercent="50"></progress>
<progress class="progress" type="arc" percent="10"></progress>
<progress class="progress" type="ring" percent="10" secondarypercent="50"></progress>
</div>
/* progresspage.css */
.container {
flex-direction: column;
justify-content: center;
align-items: center;
width: 100%;
height: 100%;
}
.progress {
width: 300px;
height: 300px;
}
三 rating評分條
評分條,表示用戶使用感受的衡量標準條。通常用于評價目標(音樂、視頻、應用等)的等級。
評分條除支持通用屬性外,還支持如下屬性:
numstars:設置評分條的星級總數,默認值為5;
rating:設置評分條當前評星數,默認值為0;
stepsize:設置評分條的評星步長,默認值為0.5;
indicator:設置評分條是否作為一個指示器,此時用戶不可操作,默認值為false;
評分條可以通過change(rating:number)事件監聽用戶的評分變化。
示例
<!-- ratingpage.hml -->
<div class="container">
<rating id="rating" numstars="5" rating="5"
@change="changeRating"></rating>
</div>
/* ratingpage.css */
.container {
display: flex;
justify-content: center;
align-items: center;
}
rating {
width: 200px;
}
// ratingpage.js
import prompt from '@system.prompt';
export default {
changeRating(e) {
prompt.showToast({
message: e.rating
});
},
}
四 slider滑動條
滑動條組件,用來快速調節設置值,如音量、亮度等。
常用屬性如下:
min:最小值,默認值為0;
max:最大值,默認值為100;
step:最小滑動步長,默認值為1;
value:初始值,默認值為0;
另外,通過change(changeEvent)事件可以監聽用戶的滑動數值變化,參數changeEvent有如下屬性:
value:當前進度條的進度值;
mode:當前change事件的類型,可選值為:
start:slider的值開始改變。
move:slider的值跟隨手指拖動中。
end:slider的值結束改變。
示例
<!-- sliderpage.hml -->
<div class="container">
<text>進度條的開始值:{{startValue}}</text>
<text>進度條的當前值:{{currentValue}}</text>
<text>進度條的結束值:{{endValue}}</text>
<slider min="0" max="100" value="{{value}}" @change="setValue" ></slider>
</div>
/* sliderpage.css */
.container {
flex-direction: column;
justify-content: center;
align-items: center;
}
export default {
data: {
value: 0,
startValue: 0,
currentValue: 0,
endValue: 0
},
setValue(e) {
if (e.mode=='start') {
this.value=e.value;
this.startValue=e.value;
} else if (e.mode=='move') {
this.value=e.value;
this.currentValue=e.value;
} else if (e.mode=='end') {
this.value=e.value;
this.endValue=e.value;
}
}
}
五 switch開頭選擇器
通過開關,開啟或關閉某個功能。
開關選擇器的常用屬性如下:
checked:是否選中,默認值為false(不選中);
showtext:是否顯示文本,默認值為false(不顯示);
texton:選中時顯示的文本,默認值為“On”;
textoff:未選中時顯示的文本,默認值為"Off";
開關選擇器可以通過change(checked:checkedValue)事件監聽開關狀態的改變。
示例
<!-- switchpage.hml -->
<div class="container">
<switch showtext="true" texton="開啟" textoff="關閉"
checked="true" @change="switchChange"></switch>
</div>
/* switchpage.css */
.container {
display: flex;
justify-content: center;
align-items: center;
}
switch {
font-size: 30px;
texton-color: blue;
textoff-color: silver;
text-padding: 20px;
}
// switchpage.js
import prompt from '@system.prompt';
export default {
switchChange(e) {
if (e.checked) {
prompt.showToast({
message: '打開開關'
});
} else {
prompt.showToast({
message: '關閉開關'
});
}
}
}
好了,本章的內容至此結束,記得多動手。
*請認真填寫需求信息,我們會在24小時內與您取得聯系。