㈠ android 微信對 emoji 的支持是不是很差為何這樣設計
Emoji從最早開始到現在，比較通用的是兩種編碼方案，分別是Softbank和Unicode，android版微信早期也是使用Softbank編碼，然後客戶端根據表情對應的Softbank編碼使用SpannableString在TextView, EditText中顯示成對應的表情，此時Emoji表情的集合還不是很多，微信只打包進去了大概400多個左右，在早期可以滿足大部分Emoji表情的顯示需求
但是，隨著Unicode 6.0以及Unicode 7.0的發布，越來越Emoji表情被加入到這個標准當中，iOS系統自行擴展OpenType標准，通過Apple Color Emoji.ttf這個字體來講Emoji表情直接顯示出來（OSX下也有這個字體，在/System/Library/Fonts/Apple Color Emoji.ttf），當時國外也有對這個問題進行過討論：Color bitmapfonts... thanks to Apple?! ，但是，由於新加進來的表情都沒有對應的Softbank編碼，無法轉碼成Softbank，並且客戶端在打包的時候只放進了400多個Emoji表情，所以在顯示的時候，只能轉換成".."來顯示
後來，隨著越來越多表情不能顯示，我們這邊曾經嘗試過直接在客戶端使用unicode編碼，並嘗試過一次對外的灰度，在灰度的過程中，我們發現了一些crash，占的總量還不低，crash的堆棧大概是這樣的：
at android.text.SpannableStringInternal.getChars(SpannableStringInternal.java:102)
at android.text.TextUtils.getChars(TextUtils.java:105)
at android.text.Layout.processToSupportEmoji(Layout.java:3747)
at android.text.Layout.supportTabandEmoji(Layout.java:3783)
at android.text.Layout.measureText2(Layout.java:3141)
我們注意到了 processToSupportEmoji 這個方法，明顯不是屬於Android系統原有的方法，應該是某些rom自行更改出現的問題，google一下，果不其然，在某些MTK的rom中有這樣的一段代碼，是屬於processToSupportEmoji中的：
...
int length = end - start +1;
char[] chs = TextUtils.obtain(length);
TextUtils.getChars(text, start, end, chs, 0);
for (int i = start ; i < end; i++) {
char c = chs[end-start];
if (c >= 0xD800 && c <= 0xDFFF && i + 1 < length) {
char[] tmp = TextUtils.obtain(2);
TextUtils.getChars(text, i, i+2, tmp, 0);
....
可以看出這段代碼對數據越界的保護是錯誤的，很容易就crash，有興趣可以看下這篇文章：Android程序自動退但是沒有提示任何錯誤
發生這個crash的大部分都是2.3系統的手機，也有一部分是4.x，sony的一些機器也有，估計是復用了同一份代碼。
So，問題的答案到這里就很明顯了，將部分表情替換成點點的原因主要是這樣的：
1. 大部分新表情都沒有對應的unicode編碼，而換了unicode編碼，TextView/EditText直接顯示在一些機器中就會遇到上面的crash
2. 考慮到安裝包的大小，目前也沒有把太多表情直接打包進去的打算（從目前版本的OSX中提取出來的表情大概有800多個，全部直接打包進去的話，會給安裝包增加1~2M的體積）
BTW，Google在4.4之後也自行擴展了OpenType標准，同時也添加了一套自己的小黃人Emoji表情，可以直接在Google輸入法中輸入
㈡ 寫給Android開發者看的『微信小程序和Android開發的對比』
微信小程序近期可謂是動作頻出，僅最近新增的能力就有：
種種跡象表明，微信對小程序的期望值是很大，所以在它推出的幾個月效果沒到達預期的情況下，之前的很多『克制』也就逐漸變成『放肆』了 —— 不過不管小程序以後的發展到底怎樣，對我們開發者來發，多了解一些總是沒有壞處的。
他山之石，可以攻玉。
對於是技術人來說，多了解一些不同的技術、不同的開發模式、不同的架構思想，提高技術『廣度』，對於自己的成長是十分必要的。
所以，本文就是從一個 Android 開發者的角度，從項目工程方便切入，來分析一下『微信小程序』跟『Android App』開發上的一些異同。
『微信小程序』開發是一個相對較新的技術，希望通過本文，能讓你對它多一些了解。
因為內容是從Android開發的角度來談的，所以我假設你已經對 Android 開發比較熟悉了。並且對微信小程序的開發也比較感興趣，如果要是再能有些 javascript、css 的基礎的話那就更好了！
Android 開發我們已經比較熟悉——
作為對比，進行微信小程序開發所用的語言是這些——
wxml (WeiXin Markup Language) 基本約等於是 xml。微信之所以沒有直接使用 xml ，可能是為了以後擴展方便一些（野心很大）。
同理， wxss (WeiXin Style Sheets) 基本約等於是 css。也是微信擴展了一些功能，比如統一的尺寸單位 rpx 。
對於 Android 來說，對於頁面的描述基本上在 xml 中定義的，比如：
這是一個簡單的典型的示例，這個文件就是描述了兩部分內容：
some.wxss:
很明顯可以看出：wxml 是負責了 頁面結構 的展示；而 wxss 則負責了對 頁面樣式 的定義。
這種把結構和樣式分離的做法，其實是延續了網頁開發中的習慣（html + css）。
這樣做的好處起碼有兩個：
——看起來還是挺簡單的結構:
這三個文件用以描述小程序 app 相關的內容，他們的命名是固定這樣的，位置也固定是在根目錄下。
app.js 基本相當於 Android 中的 Application 類，文件中主要是有一個 App() 函數，來進行小程序的初始化操作。
app.json 的作用跟 Android 中的 AndroidMainifest.xml 文件很相似 —— 都是靜態化的配置文件。
app.wxss 定義全局的樣式 —— 其定義的樣式會作用於每個頁面。比如在 app.wxss 中加入：
就可以給所有的 text 控制項添加 5px 的 padding 。
當然，頁面本身的 xxPage.wxss 可以定義局部樣式來覆蓋全局樣式。
根目錄下的 utils 文件夾中有一個 util.js 文件，這個故名思意，是類似於 Java 中的一些工具類的存在。
utils 文件夾其實是一個非必須的結構，而它之所以出現在官方的 HelloWorld 工程中，是作為一個代表，表明了開發者在這里是可以自定義新的文件夾和結構的。微信小程序作為一個使用 js 來開發的平台，是可以使用許多第三方的 js 庫的，對於這些第三方庫，以及其他的圖片資源等，都可以放到自定義的文件夾中。
pages 文件夾下包含兩個子目錄：index 和 logs ，兩個目錄的結構都是基本一樣的，都是包含四個相同主名稱的文件： xx.js、xx.wxml、xx.json、xx.wxss 這幾個文件。
這樣的一個典型結構表明它是一個小程序的頁面，四個文件的作用分別是：
在視圖的動態顯示上，微信小程序使用了 數據綁定（data-binding） 的方式。
如果你之前使用過 AngularJS 或者 Vue.js 等這些流行的 js 框架，那麼你肯定對 數據綁定 並不陌生。它是一種把一個控制項的屬性綁定到某個數據對象（view-model）的屬性的方法，這樣在改變數據對象屬性的時候，所對應的控制項屬性也就會相應變化 —— 在開發中，這種方式會使得對 View 層的顯示控制變得十分簡單、自然。
基於此，軟體工程的流行架構方式也在之前的 MVC 、 MVP 之外，又多了一個 —— MVVM（Model-View-ViewModel） 。
數據綁定 這種方式現在是如此的流行，以致於 Android 官方都出了一個 [Data Binding Library] ( https://developer.android.com/topic/libraries/data-binding/index.html ) 來支持數據綁定，但是由於成熟度等原因，目前還並沒有成為主流，Android 中的主流視圖顯示方式，還是通過開發者手動給每個控制項 set 數據。
—— 單從這一點上看，微信小程序的開發模式是比原生 Andorid 要『先進』一些的~ 😏
小程序雖然是和前端 H5 頁面一樣是用 js 來開發，但是由於它最終運行的平台不再是瀏覽器，而是和 App 的表現幾無二致，所以頁面的生命周期也是和 App 差不多的。
一個小程序頁面的典型生命周期如下：
對比一下 Android 的 Activity 生命周期 ：
微信小程序的頁面生命周期稍微簡單一些，但主要的思想跟 Activity 生命周期基本是一致的。
小程序的官方 IDE 是微信自己出品 微信Web開發者工具 ，它內置了一個小程序的運行環境，本質上是基於 Chrome 內核的一個瀏覽器框架，算是一個模擬器了。
——它雖然跟 Android 的各種高大上的模擬器相比起來略顯簡陋，但是基本該有的功能也基本都有（斷點、Log、網路監控等），而且由於是基於瀏覽器內核的頁面 DOM 解析，所以運行的速度也是像瀏覽器打開網頁一樣流暢，不會像 Android 模擬器那樣對系統資源要求很高。
另外，在綁定了開發者賬號之後，也可以用手機進行真機調試來調試小程序，所以也能在上線前用不同的機器來進行充分的兼容性測試。
總體來說，小程序作為一個新的形態，從開發的角度，它可以算作是一個【Native開發】和【H5開發】的結合，它吸收了原生開發和 H5 開發的優點。對於前端開發人員和原生開發人員來說，都可以在微信小程序中找到許多熟悉的東西。再細節的許多點這里就不在贅述了，大家如果有興趣，可以自己上手去體驗一下。
綜上，自然也就有兩種人特別適合去做小程序的開發——H5的前端開發人員，以及之前的 Android/iOS 原生 App 開發者。
微信小程序的開發總體來說是很簡單的。
—— 對於前端開發者來說，了解一下原生 App 的一些相關思想即可，這些工作其實只要讀一遍小程序的開發者指南基本就差不多了。
—— 而對於原生開發者來說，只要稍微補一下 js 的相關知識（html/css），也基本就差不多可以上手去做了。如果你之前恰好已經有過一些 js 的使用經驗，那就不用多說了，花半個小時看一下小程序的文檔，直接上！
關於作者 :
http://www.barryzhang.com
https://github.com/barryhappy
http://www.jianshu.com/users/e4607fd59d0d
㈢ 安卓微信狀態背景圖怎麼設置
1、在手機上登錄微信，點擊右下角我的按鈕。 2、進入到我的界面以後點擊自己昵稱下面的+狀態。 3、此時在出現的我的狀態界面中點擊需要的狀態。 4、頁面跳轉以後可以看到已經添加了相應的狀態，輸入需要的文字或者話題。 5、話題輸入完成以後點擊右下角的就這樣按鈕。 6、此時頁面跳轉以後即可看到已經在微信8.0版本中添加了需要的狀態了。 (3)android微信設計擴展閱讀： 微信 8.0 主要更新功能有：全新浮窗、動態表情，支持設置自定義狀態等功能。 可以在我的狀態裡面，進行背景圖更換，還可以自由搭配文字，完美，讓自己的整個微信和心情都變得隨心而動。 選擇狀態類型，支持設置 「 我的狀態 」 ，可以設置自己的 「 心情想法 」 、「 工作學習 」 、「 活動 」 、「 休息 」 以及 「 其他 」幾個狀態。 大家可以選擇一種狀態，也可以添加自己的想法，還可以添加狀態背景圖，顯示位置，公開或不給誰看。 除了「我的狀態」功能外，此次微信更新還上線了其他的內容，包括全新的表情動畫，全新的浮窗管理器。