if (dWidth > width && dHeight < height) {
……
}
if (dWidth < width && dHeight > height) {
……
}
if ((dWidth > width && dHeight > height) || (dWidth < width && dHeight < height)) {
……
}
親測,可以直接
scale = Math.min(width * 1.0f / dWidth, height * 1.0f / dHeight);
……
}
if (dWidth < width && dHeight > height) {
……
}
if ((dWidth > width && dHeight > height) || (dWidth < width && dHeight < height)) {
……
}
親測,可以直接
scale = Math.min(width * 1.0f / dWidth, height * 1.0f / dHeight);
2017-02-12
我覺得會用matrix、ScaleGestureDetector就行了,業(yè)務邏輯因人而異 大家都能寫出自己的邏輯 效率好壞而已 況且老師的也不見得是最好的 這種程度的邏輯完全不用聽老師的;ps:個人發(fā)現(xiàn)onScale中return true阻止事件傳遞這個蠻有意思,若false檢測為一次傳遞 scaleFactor的值變動很大(相對于手指初始點擊比例);return true的原因就是阻止傳遞,ScaleGestureDetector的onscale認為事件多次執(zhí)行,每次比例均為本次檢測時的currentSpan 我覺得如果只要老師代碼 絕對會忽略了這些內(nèi)容(這個確實該講啊)
2017-02-01
關(guān)于rectF.set(0, 0, d.getIntrinsicWidth(), d.getIntrinsicHeight());的問題,我懷疑洋神是否真的清楚其中的本質(zhì)。
d.getIntrinsicWidth()/height()的值只要圖片不變,其結(jié)果永遠不變。rectF.set()和mScaleMatrix.mapRect(rectF)會將圖片現(xiàn)有的Matrix和IntrinsicWidth/height做一個映射計算,具體算法我說不清楚,數(shù)學不好。結(jié)果就是將圖片以像素為單位的邊界存放到RectF當中。這樣才能做到圖片的邊界與空間寬高(以像素為單位)對應,從而正確計算。
d.getIntrinsicWidth()/height()的值只要圖片不變,其結(jié)果永遠不變。rectF.set()和mScaleMatrix.mapRect(rectF)會將圖片現(xiàn)有的Matrix和IntrinsicWidth/height做一個映射計算,具體算法我說不清楚,數(shù)學不好。結(jié)果就是將圖片以像素為單位的邊界存放到RectF當中。這樣才能做到圖片的邊界與空間寬高(以像素為單位)對應,從而正確計算。
2017-01-17
這種算法是有問題的。應該先把圖片的寬高比和控件的寬高比作比較,決定圖片縮放是適應寬還是適應高,算出縮放比,把另一條邊根據(jù)縮放比進行縮放,劇中就可以了。這樣窮舉很有問題。
2016-12-24
對于贊數(shù)高的zttbill同學的說法,老師的縮放不是倍數(shù),是比例,你說的縮小2倍,在代碼里是乘上0.5,不是除以2,所以說“選擇小的比例”意思是選擇比例值小的,那么相乘后當然就是更加縮小的
2016-11-25
matrix.postScale()方法是按照"已經(jīng)縮放過的圖片",再去進行一次縮放的。也就是之前如果已經(jīng)調(diào)用了postScale(scale, scale),那么圖片寬高就已經(jīng)縮放了scale個系數(shù),現(xiàn)在再次調(diào)用postScale(scaleFactor, scaleFactor),就會在scale系數(shù)的基礎上縮放scaleFactor個系數(shù),也就是縮放scale*scaleFactor。視頻中166行和171行除以scale這個參數(shù),就是為了將之前已經(jīng)縮放過的scale個系數(shù)給抵消掉,最后得到最大或者最小縮放比例。
2016-11-08