一個好的app設計-考慮耗電量


當設計app的人沒有電腦資源使用率的概念,
就會造成上面的結果,
耗電量大增,甚至比螢幕還耗電..

有時設計一個app還需要考慮耗電性.
你不能產生一個thread,就一直在背景running, checking, updating...
像 Line也是, 但 Line沒這app嚴重,

當User離開這應用程式,app卻沒有釋放資源,
例如onPause時就要開始有心理準備,不能假設user只是被其他訊息擋住,馬上就會回來,
而onStop時要開始終結與釋放資源,該stop就stop,close, 設null.
onDestory時要徹底release乾淨,不要太依靠java gc.

有時檢查網路上的資料,頻率太快,都會造成手機耗電量大增,

但有些app的設計者,卻只管要達到最佳效果, 每 10sec 或每分鐘就檢查一次.
效果是達到了,但也讓手機耗電量大增
user也很難發現.
可能等到手機待機時間大幅縮短時,才會去檢查是哪個APP是耗電元兇.
當發現是這個APP造成時,就一怒之下把這APP刪了,永不安裝...

在google map API也有類似設定,
你如果把檢查回報的時間設太短ex: 1ms, 或是距離 1M , 就回報更新座標.
甚至有些設定0sec or 0m.變成一有更新就回報,馬上就會把手機珍貴的電力耗盡.
這就是爛設計.

admob也是有相同的設定,請大家小心設定頻率,
有些設計師為了求好心切,努力send request,幾乎每換個畫面就send 一次.
當下載廣告時,3g or wifi的耗電量會大增,長期下來,
很可能造成未來user只要看到app有廣告,就把這app刪了....

有聽人說過為了增加admob收入,廣告能放多少就多少...我就持相反看法.
反而廣告出現的越少,user好感度會大增 .
例如蘋果日報APP,就是廣告出現頻率太高,有時還強迫User觀看.
甚至把廣告混入新聞中,這就不是好app,反而會造成user反感.

所以就有公式產生:
user對APP的好感度=(內容+實用度+UX好壞) / ((1+價格) * 廣告出現頻率*耗電量) *100%

有時下載率高,代表其內容與實用度不錯, 但會被高耗電量或其他因素害慘.就不是一個好的APP.
一個好的APP設計師應該要避免之.


留言

張貼留言

這個網誌中的熱門文章

最爛的銀行服務-玉山銀行

圖片
今天寫信給玉山銀行,問他說能不能給予我免費跨行轉帳次數, 我是他們大客戶....常常需要轉帳跟提款.發現這樣被扣手續費很不划算. 玉山銀行的atm又很少見. 但是得到的回應是這樣： 看完這信,有回答等於沒回答,當下我就決定要轉到其他家銀行了, 只是有點麻煩,股票帳戶,外幣帳戶,黃金存摺帳戶... 玉山銀行在我家附近連一台提款機都沒有，每次都要借台新銀行或中信銀行的atm. 把錢放在這裡實在不方便,不斷被扣轉帳手續費跟提款手續費． 你看台新銀行richard給我五次免費額度. 使用其他家例如合作金庫與兆豐銀行都有台灣pay可以免手續費. 玉山銀行？？？？ 今天開始要開始廢棄玉山銀行了．．．． 而且看這回信後,我也覺得玉山銀行很爛,自己不建atm,又不給客戶免費跨行提款次數,叫我跑大老遠自己搜尋ATM. 建議大家他的股票: 玉山 金控 ( 2884 ) 也不要買, 股價一定會慢慢下跌的,看他們家的服務讓客戶一個一個跑掉，就知道了 . 未來不是有很多純網銀出來嗎？ 他們都會給予更多免費跨行轉帳次數. 感覺未來這種服務不佳的銀行都準備被淘汰吧. 對於app設計師來說： 這種回答也是最不佳的. 我們要對user友善點,使用者反應app會當機,有問題時， 回答要能解決他們的問題. 千萬不能像玉山銀行客服人員這樣回答. 使用者都是很厲害的,他發現你沒鳥他，明天開始就刪除app了. PS:後來去辦了兆豐銀行.行員說只要辦個數位帳戶就有10次跨行提款...而且已經有一般非數位帳戶也可再申請一個數位的. 相比玉山銀行還限制如果有玉山帳戶者再申請數位帳號也沒有跨行轉帳提款優惠,玉山真的好差... 除此之外,台新銀行也給我各5次免費跨行轉帳+提款次數 真的好好..(以上都不用薪轉戶,一般人都有資格可以申請) 有了15次轉帳跟跨行提款免費,就不用到處找ATM.... 心情好多了,現在欠缺的就是錢了
閱讀完整內容

Mark App Design Apps - Terms and Privacy Policy (服務條款,隱私權政策)

Privacy Policy The Privacy Policy when you use "Mark App Design" Apps: This policy is effective as of 2020-05-19 This page is used to inform visitors regarding my policies with the collection, use, and disclosure of Personal Information if anyone decided to use my app. If you choose to use my app. then you agree to the collection and use of information in relation to this policy. The Personal Information that I collect is used for providing and improving the Service. I will not use or share your information with anyone except as described in this Privacy Policy. -Packet TV apps use Youtube API Service (terms link: YouTube API Services Terms of Service ), when you use this app,  you are agreeing to be bound by the YouTube Terms of Service. and Google private policy please also see Google Privacy Policy Mark app design built the Pocket TV app and my most app as a Free app. These apps are provided by "Mark app design" at no cost and is intended for use as is. 使用app需受 G
閱讀完整內容

SMR疊瓦式hdd致命缺陷被解決????!!!

圖片
新聞來源: https://tech.sina.cn/2019-12-25/detail-iihnzahi9980174.d.html 現在90%所有的硬碟 … 除了SSD 之外都是採用PMR 技術，但為容量增長而發展的SMR( 疊瓦式磁紀錄)會比較便宜不要踩地雷 。 PMR、SMR 硬碟分別是什麼？ PMR (perpendicular magnetic recording，垂直磁性記錄). 寫入磁頭會比讀取磁頭來得大，因此硬碟供應商若要增加磁錄密度，就會儘可能讓寫入磁頭的尺寸縮小至物理極限為止。 SMR (shingled magnetic recording，疊瓦式磁性記錄). SMR 採用的技術是讓資料循序寫入，如其名稱所示，磁軌會如瓦片般堆疊在另一磁軌的部分面積上，藉此達到增加磁錄密度的目的。在此情況下，讀取磁頭仍可從磁軌上未被覆蓋的部分來讀取資料。   玩家對SMRHDD避之唯恐不及，因為這種HDD性能、可靠性都有問題，但它能提升HDD存儲密度大約1/4 PMR 與 SMR 的差異 當 SMR 硬碟上循序寫入新資料時，這些如瓦片般堆疊的磁軌仍可正常讀取， 並不影響讀取效能。 不過，一旦已寫入的資料要修改或覆寫時，寫入磁頭並不會直接在既有的磁軌上進行磁錄，以避免毀損相鄰的磁軌。 編輯後的資料會先在磁碟上的空白處寫入，原先舊資料的磁軌會暫時維持不動。 等到硬碟閒置時才會進行重新整理的機制，將原先磁軌上的舊資料自動清除，並重新成為可用空間以供新資料寫入。 就前述的重新整理機制而言， SMR 硬碟的閒置時間就顯得相當重要。如果 SMR 硬碟長時間進行密集的覆寫任務，則會沒有足夠的閒置時間來重新整理磁軌，暫時不動的既有資料磁軌數量會越來越多。接著導致 SMR 硬碟必須一邊寫入新資料，一邊重新整理舊磁軌，進而對讀寫效能造成某種程度的影響。 WD他們開發了名為Zonefs的文件系統，有望解決SMR HDD寫入數據時的弊端，同時也適用於SSD。 WD近年來一直在研究分區存儲（Zoned Storage），它將 HDD的LBA空間分成多個區塊，只能從每個區塊的開頭順序寫入數據，而且數據不能任意覆蓋。這種數據存儲技術可以改變SMR、SSD HDD存儲、寫入數據的方式，不會再像現在這樣有很多隨機
閱讀完整內容

ios app 上架時app icon要注意事項

圖片
按照apple ios app icon標準(App Icon Attributes): All app icons should adhere to the following specifications. 所有app icon須符合下列: -Format： PNG  , 一定要png...但全彩png size很大 .. -Color： 注意24bit不要有透明色在上面. -Layers： Flattened with no transparency. 絕不可以有alpha透明色. -Shape Square with no rounded corners 不可以有圓角,之後apple會統一用圓角特效上去. -Resolution: -iPhone X, iPhone 8 Plus, iPhone 7 Plus, and iPhone 6s Plus @3x -All other high-resolution iOS devices @2x ps: 建議不要使用 PDF 檔案.. pdf內是一個向量圖,本來是用來減少png的size太大問題. 但對於較複雜的圖像而言 PNG 的表現實際上是優於 PDF 的. iOS系統會自動把 30x30 的 PDF 圖檔做成 @2x 60x60 的 PNG 圖檔. 很複雜的官方說明： Image Size (px) File Name Used For App Store 512x512 iTunesArtwork App list in iTunes Do not include 1024x1024 iTunesArtwork@2x App list in iTunes on devices with retina display Do not include 120x120 (最重要!) Icon-60@2x.png Home screen on iPhone/iPod Touch with retina displ
閱讀完整內容

更改google drive預設存放目錄位置Change Google Drive Default Folder Location in Windows

圖片
Google drive預設存放位置是放在C:\Users\username\Google 雲端硬碟.有些人c槽是ssd,空間有限.如果一不小心,像google drive空間有1TB的人. SSD就被塞爆...需要改放在其他磁碟機..(例如c是ssd, D是一般硬碟..可能有幾TB) 1.如果之前已經安裝的人,首先先解除帳戶連結.解除後再刪除掉目前的舊的Google Drive 目錄.釋放已占空間.(不用擔心,因為已經備份到雲端,待會會自動再下載回來.) 2.再次登入帳戶,在最後一頁時.不要那麼快按確認,這裡有個"進階設定". 3.這邊可更改預設資料夾...我們把他改到D槽...或其他槽. 建一個新目錄,取個好記的名字,例如"[GoogleDrive]",加上特殊字元"[" "]"可讓資料夾排在最前面,將來比較好找.更改好之後,再選擇這新資料夾.   PS: 也建議大家不要把Google drive預設資料夾放在C:\Users\username\Google 雲端硬碟. 一則不方便找.二則重灌電腦時,會忘記這邊有資料,整理起來很麻煩.三是C通常是SSD,容量小,設在D槽(如果是HDD的話),可避免塞爆SSD.
閱讀完整內容

google play 正式發布前測試報告...非常好用.

圖片
Google developer console內的 正式發布前測試報告(Pre-launch report)...非常好用. 要產生應用程式的正式發佈前測試報告，要請將應用程式發佈至開放式beta、封閉式alpha或內部測試群組。 它有 三個版本. 到底該用那一個? 我是用 內部測試 之後會升到 alpha. (內部測試群組--> alpha --> 正式release.) 內部測試: Fast: You can distribute apps via the internal test track much faster than the open or closed tracks. When you publish a new APK or app bundle to the internal test track, it will be available to testers within a few minutes.  (幾分鐘之內會生效給測試者) 但我主要是要他幫我跑"正式發布前測試報告".  會發現很多自己在測試時沒發現的問題. 不過因為一直出現紅字,但我自己又測不到問題在那. 因為改了一些我認為有問題的code. 一直上傳請他幫我測試,不知道這樣會不會是違規?  google play審核人員看你一直上傳,不生氣才怪, (這會浪費他們時間,可能下次審核時間給你延長幾天.等你確定後不再上傳才一次審核完 .) 目前我是先用"內部測試群組",這樣就不用經過google play審核人員審核.等都all pass都是綠色後,才升版到alpha. 發生bug..他告訴我大概位置： Caused by: java.lang.IllegalStateException: The application's PagerAdapter changed the adapter's contents without calling PagerAdapter#notifyDataSetChanged! Expected adapter item count: 100, found: 5 Pager id: com.mark.TOEICtes
閱讀完整內容

舊有app在Android 12 閃退問題& app Splash screens

圖片
現在越來越多手機開始轉成android 12. 於是我就把target sdk = 31 試試看. android {       compileSdkVersion 31      defaultConfig {           targetSdkVersion 31      } } 結果舊有的app都開始發生了閃退現象. 就有使用者跟我反映app當機問題出現.因為這屬於不可歸咎app設計的問題..必須要在android 12的機器上跑才會發生,而且android developer console中Pre-launch report 也沒測試出問題. 但一跑android 12模擬器就會發生當機,所以真的會有問題. 只能說寫app要處理的突發情況有很多,這是其一. android app發佈控制台好的地方是當你上傳apk時,他都會幫你自動做Pre-launch 測試. 這次android 12會突然當機的問題,理應要先被Pre-launch 被發現才對. 我檢查後才發現,原來連Pre-launch都沒測試到最新的android 12. 他只測試到android 11. 但目前很多新機子已經開始系統更新到android 12去了.這就是問題會發生的原因. ---- error message: java.lang.IllegalArgumentException: com.mark.electricitybillcalculator: Targeting S+ (version 31 and above) requires that one of FLAG_IMMUTABLE or FLAG_MUTABLE be specified when creating a PendingIntent.     Strongly consider using FLAG_IMMUTABLE, only use FLAG_MUTABLE if some functionality depends on the PendingIntent being mutable, e.g. if it needs to be used with inline replies or bubbles. Solution: 修正android 12上當機閃退問
閱讀完整內容

app bundle and bundletool. 關於aab安裝問題

圖片
google 有說明年開始強制使用app bundle. 不然不准更新app. 但是產出的apk不再是apk了,而是aab. C:\release>adb install 6.aab Performing Streamed Install adb.exe: filename doesn't end .apk or .apex: 6.aab   不能透過adb install.... so, google 發表一個新tool: 去download bundletool...因為是java跨平台都可執行. https://github.com/google/bundletool/releases   You can extract the apks files from the aab file using the bundletool command. https://developer.android.com/studio/command-line/bundletool To generate an APK set for all device configurations (signed with a debug key) you can use:  bundletool build-apks --bundle=/MyApp/my_app.aab --output=/MyApp/my_app.apks To deploy your app from an APK set, use the install-apks  bundletool install-apks --apks=/MyApp/my_app.apks test:   C:\release>java -jar bundletool.jar build-apks --bundle=6.aab --output=out_6.apks INFO: The APKs will be signed with the debug keystore found at 'C:\Users\mark\.android\debug.keystore'.   還是失敗,還要指定key才可以...  For Release apk command, example 1: bundle
閱讀完整內容

關於google play console app應用程式簽署

圖片
應用程式簽署 只要加入 Google Play 應用程式簽署計畫，您就能以安全的方式為新的和現有的應用程式管理應用程式簽署金鑰。系統會透過安全的基礎架構 (與 Google 用來儲存自身金鑰的基礎架構相同) 妥善存放金鑰。 如果您遺失了金鑰庫，或認為金鑰庫遭到破解，Google Play 應用程式簽署計畫可以讓您提出重設上傳金鑰的申請。如果您在沒有註冊加入 Google Play 應用程式簽署計畫的狀況下遺失了金鑰庫，則必須使用新的套件名稱重新發佈應用程式。 當然要加入啦, 但加入後就有很多問題產生了,會有三個SHA1金鑰產生,不同的sha1.用的地方不同. debug跟release 跟 google play 會自動二次簽章. 上傳APK後,就是不同的SHA1. 要去Google play console看. 如圖上,紅框處:就是真正user下載到的app的實際sha1. 填錯,firebase 就不能用喔~~~ -->用這指令只是看目前你手上的KEYSTORE他的SHA1,在DEBUG時期用的. 指令: (紅色改成你的) keytool -exportcert -list -v -alias YOUR_KEYSTORE_ALIAS -keystore YOUR_KEYSTORE 輸出: 輸入金鑰儲存庫密碼: 別名名稱: --- 建立日期: 201-- 項目類型: PrivateKeyEntry 憑證鏈長度: 1 憑證 [1]: 擁有者: --- 發行人: --- 序號: --- 有效期自:--- 憑證指紋:          MD5:  90:3E:----E3:8D          SHA1: E1:3F:3---5A:96          SHA256: 40:F8:0----2:F6:10 簽章演算法名稱: SHA256withRSA 主體公開金鑰演算法: 2048 位元的 RSA 金鑰 版本: 3 擴充套件: #1: ObjectId: 2.5.29.14 Criticality=false SubjectKeyIdentifier [ KeyIdentifier [ ---                                ,... ]
閱讀完整內容

Google Play badge徽章產生器

圖片
Welcome to the Google Play badge page  千萬不要自己設計Google play 標籤,這裡有官方網站可產生之: https://play.google.com/intl/en_us/badges/ deliverable type: 選擇digital badges,可產生 HTML 連結 就可貼到其他地方. 選擇print 的話,只有 一張高畫質EPS圖,可在Photoshop處理,不需要再從別地方找了. 就像這樣:點了會到google play store:
閱讀完整內容